This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question on GCJ/Boehm Memory Utilization


Craig A. Vanderborgh wrote:

The character arrays created by GCJ/Boehm for storing the java.lang.String tokens that result from XML processing are where I believe there is a problem. These are short strings, typically around 10 or so characters in length. GCJ/Boehm seems to be allocating 2048-byte heap blocks, and in many cases - even 12932-byte heap blocks, and then putting only one or two of the tokens resulting from XML parsing into them. Just a few characters. In some cases, 2 of these short tokens share a 2048-byte or 12932-byte block, but very often they don't.

The end result is that the limited amount of memory that we do have on our target device is largely squandered. Is there a good reason why the character arrays for java.lang.String's are always stored within large (2048/12932 byte) PTRFREE Boehm heap allocations? Are there things we could do to coax Boehm GC into using smaller allocations in these situations, say 128 bytes instead of 2048?


You don't say how you are generating the Strings. Some applications build the string using a StringBuffer object. When it is complete the String is obtained with StringBuffer.toString().


If this is how you are creating Strings, then the GC and GCJ have nothing to do with the size of the char[] associated with the String. The sizing is done in libgcj, specifically in the String, and StringBuffer classes.

And finally, is there anything that was changed in later versions (than 3.3/6.2) of GCJ/Boehm to mitigate this problem?

Yes. In 3.3.1 the char[] is always shared, so if you do:


StringBuffer sb = new StringBuffer(2048);
sb.append('j');
String s = sb.toString();

I think you will get a one character String that has a 2048 byte backing char[].

In 3.4.3 the char[] is not shared unless it is more than 25% full. So the pathalogical case above is handled in an optimal manner.

David Daney.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]