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]

Question on GCJ/Boehm Memory Utilization


Hello!

We're running GCJ 3.3 w/Boehm GC 6.2 on the arm-wince-pe platform (please don't laugh!)

Our Windows CE embedded devices are pretty memory-challenged, as they have only 128 MB of RAM, and about 35 MB of this is consumed by the CE "operating system" itself.

Our application (on the CE target device) is regularly running out of memory, and we're trying to figure out what we can do to improve the situation.

Using the Avtrex GC dumping tool, I have observed that GCJ and Boehm are making extremely inefficient use of the available memory in our most important use case. The use case involves parsing and tokenizing XML, and then storing those results in a DOM tree. The implementation makes use of the Xerces DOM classes and it's all pretty straight ahead stuff and it all seems to work correctly.

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?

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

Please advise. We are trying hard to find a little bit more breathing room...

Thanks in advance,
craig vanderborgh
voxware incorporated



Confidentiality Note: This message may contain information which is privileged or confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee responsible for delivering the message to the intended recipient, you are hereby NOTIFIED that any dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you received this email in error, please notify Voxware immediately by return email to the sender.


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