Memory Errors / "Java heap space error"

While using the Eclipse environment, it is particularly easy to run out of room; if you've got a decent machine, it is easy to assume that the available RAM on the machine will automatically transfer to available build ram. This is not the case; thus, you may occasionally get errors that state Java heap space error or an Error that offers to close Eclipse.

Documentation exists in various locations; thus this post is intended to capture the notes I found useful from various sites. Where applicable I intend to link to the location I found the information (in case some further piece of information is of value to you).

=================================================

Setting the java heap size is fairly simple - it can be done in a number places.
The first (and potentially most obvious) is via command line; simply type them out.

example: java -Xmx128m

I am not terribly familiar with the command line interface for Eclipse, so I won't be documenting particulars; below, however, are some guidelines about how to set the parameters and what to watch out for when asserting them.

The second, and more obvious to me, is through the use of the initialization file, entitled "eclipse.ini". It is located in the directory in which you installed eclipse ... the one that has the "dropins" folder. Opening it up reveals several settings - the one you will be interested in is under "-vmargs".

The third is through the Eclipse interface proper.
I snagged the steps from here.

1. From the Eclipse main menu, choose "Window" then "Preferences".

2. On the Preferences dialog

Expand "Java" in the left-hand column
Under Java, click "Installed JREs"
You will now see your installed JREs with the one currently used being ticked
Select the "default" JRE and click the "Edit" button to the right of it.

3. Part way down the "Edit JRE" dialog, you'll see a field labeled "Default VM Arguments".

Go to this and put in your -X memory arguments.
I used "-Xms128M -Xmx512M".

Regardless of your preferred method, the two attributes are "-Xms80m" and "-Xmx256".
Xms refers to the start heap size, Xmx to the max heap size.

You need enough initial heap size to start building and you need enough maximum heap size to allow Eclipse/java to finish whatever tasks you've intended it to complete.

Several potential errors (link) in setting them include

• missing units or inappropriate units
• extra spaces, incorrect syntax, or non-whole units when assigning the amount of memory
• assigning unreasonable memory sizes

Missing / inappropriate units

examples of missing a unit: "-Xms42" or "-Xmx100"
valid options for units are "m" or "g"; "mb" and "gb" are wrong
units are case insensitive; thus "m", "M", "g", and "G" are all valid units

Extra spaces, incorrect syntax, or non-whole units when assigning the amount of memory

parsing of the command requires no spacing or operator (like an equals sign)

correct ...  "-Xms75m"
incorrect ..."-Xms 75m"; "-Xms=75m"; "-Xms:75m"

in addition, separation of separate commands (like setting Xms and Xmx) is simple

if using the .ini, place each on a separate line
if setting the Xms and Xmx within Eclipse, put on the same line, one space apart

Ensure the amount of memory that you set aside is a whole number

correct ... -Xms101m
incorrect ... -Xms1.3m

Assigning unreasonable memory requests

Note: The default heap range is from 0 to 64 mb.
Setting the Xms in excess of 64 mb will likely net you:

Incompatible initial and maximum heap sizes specified

Setting either Xms or Xmx in excess of your computer's available RAM will show

Could not reserve enough space for object heap

Could not create the Java virtual machine

Setting either Xms or Xmx in excess of current anticipated use

-Xmx1g is reasonable (though high)

-Xmx512g is not reasonable

As you can see, setting the initial and maximum heap sizes is simple.  This is also implicit as most of this post was about how to properly format the values to which you set requested memory.  If you find anything wrong with these directions or think a particular aspect of clarity should be included, please comment.


Thanks.

EdgeRenderer - a model of hidden capability

EdgeSprites { doc / class } show up a great deal in flare; they're used to track, update, and organize rendering of relationships between NodeSprites { doc / class }.  EdgeSprites are rendered (drawn, shaped) based upon their corresponding EdgeRenderer { doc / class}.  The *interesting* thing, like so many other tools available through flare, is that there is no simple way that I've found in the documentation to identify the list of available values for the various methods.

Here is the source: [link]

To explain what I mean, here is an example.

The EdgeRenderer has the following
public properties
caps : String = "null"; The caps style for line rendering. 
instance : EdgeRenderer; Static EdgeRenderer instance. 
joints : String = "null"; The joint style for line rendering. 
miterLimit : int = 3; The miter limit for line rendering.
pixelHinting : Boolean = false; Pixel hinting flag for line rendering.
scaleMode : String = "normal"; Scale mode for line rendering

public methods
render (d : DataSprite ) : void; Renders drawing content for the input DataSprite.

protected methods
setLineStyle ( e:EdgeSprite, g:Graphics ): void{}; Sets the line style for edge rendering.

So I know that scaleMode is a string whose default value is "normal";
what does this mean and what other values are valid?

I've attached EdgeRenderer to the "Classes" portion of this blog.
It may be evaluated here.

Searching through the class, one stumbles across something of interest - "caps" is an attribute of a graphics object; further research indicates this to be used in setting the lineStyle, which specifies a line style that Flash uses for subsequent calls to other Graphics methods (such as lineTo() or drawCircle()) for the object.

Here are valid values for each of those attributes (ref)
caps: Type of caps at the end of lines
values: CapsStyle.NONE; CapsStyle.ROUND; CapsStyle.SQUARE

The other attributes have similar variety and not all make use of lineStyle; caps does ... so does scaleMode, miterLimit, and pixelHinting.

NodeLinkTreeLayout - scaling an n-tree from the child up

I have been looking into revamping the Actionscript 3.0 layout named "NodeLinkTreeLayout".  It is simply given a DataList of nodes, identifies the root node, and populates the tree based upon the order of the children of the root, recursively adding children as it paints.

Recently I realized it doesn't paint from the root "down", but paints from the root node's first child "out".
So I'm sharing this and documenting my struggles; perhaps I'll find ways in which my own mental inefficiencies will be documented and captured.  There is certainly an element of hubris in posting at all - I'm hoping that it will be balanced by the fact that these posts will tend to document my failures as well as discoveries I make.

Here are things I've discovered in the class:

1. The edge DataList is only used in setting the rendering of the edges (directed).

It does not affect the order or position of the parent-child relationship in the tree.
I am keeping a separate array of the edges, as well as the edge's inversion state.
The edges are accessible through the visualization.data.edges DataList object.

2. Depth is an unsigned integer.

The depth of the root node is 0.
The depth of a child of the root node is 1.
The depth of a parent of the root node is -1 ... a problem for unsigned integers.

3. Node positions are based upon their effective distance from the first child of the root node.

This node's breadth doesn't really change.
Adding another child to the root node moves the root node the "_dspace".
It also moves the new child node two "_dspaces" away from the first root node.

4. Prelim is distance from the reference wall to where the node "ought" to be.

The reference wall is the wall against which you're painting.
If your using the default orientation (Top to Bottom) this is the left wall
Thus the prelim in this case would be the distance from the left wall.

5. Mod is distance between the prelim and the assumed midpoint of the parent node.

Prelim effectively points to the middle between all children of the parent
Mod is the offset from that middle.