Re: Question on GCJ/Boehm Memory Utilization, Part II

[Hans Boehm <Hans dot Boehm at hp dot com>]

As Martin pointed out, adjusting GC_free_space_divisor should help.

That aside, I still don't understand this 100%.  The large block allocator
does keep separate free lists for separate block sizes.  (This changed a
while ago, but it has now done so for quite a long time.)  Thus it should
not break up the 16K blocks used to hold 12932 byte objects until it has
used up the smaller ones.  If this is not happening, there's a bug here.
(GC_dump() prints the large block free lists for each size, so this should
be fairly easy to check.)

If this is working correctly, garbage collections are simply being
triggered too late.  A GC_free_space_divisor increase should compensate.
(I think that 7.0 will behave better in this respect, once it's
integerated into gcj.)

Hans

On Tue, 21 Feb 2006, Craig A. Vanderborgh wrote:

> Hello Again!
>
> First of all, thanks for the constructive replies to my previous
> "installment" from David and Rutger.
>
> I have done a whole lot more testing and "dump diving" since then, and I
> have at least determined what is happening with our GCJ/Boehm
> "leaking".  There is no leaking - or at least no leaking that I am
> concerned about in what I can see.
>
> I believe the correct word for what is happening is "fragmentation".
> Hans also calls it "unexpectedly large heap growth".  Maybe this latter
> term is the most appropriate.  What is happening is pretty clear:
>
> 1. For processing a large-ish DOM element containing text, the
> application requests and receives a (say) 12932 block from GC.
> 2. This large-ish block is used to do the job, and then dereferenced.
> 3. Garbage collection happens, and the 12932-byte block is put back on
> the free list
> 4. The application requests a small block for a short string, and the
> collector decides to allocate the unused 12932 byte block, even though
> it's way too big.
> 5. Goto (1)
>
> I have done enough logging and Daney-dumping to know that this how the
> heap becomes large.  It does asymoptotically stabilize at a large value,
> but the value is too large for us to live with.
>
> And so - what to do?  Is it possible to instruct Boehm not to allocate
> block sizes above a certain threshold for short string char[]'s?  Should
> the large-ish blocks be unmapped, so that this can't happen?  Should I
> write some special-purpose classes that make use of CNI to use malloc()
> allocations so that these large-ish (12932) blocks are not requested
> from Boehm GC?
>
> I also want to point out that I do have a "control" test now.  On a test
> that does not have JS tags <script> with large texts in them, but is
> exactly the same otherwise, I get a steady-state heapsize of 1.5 MB
> instead of 13 MB, with all other things being equal.  This shows that if
> my application does not ever request the 12932 blocks, things really
> work quite well with GCJ/Boehm allocation.
>
> Please, if possible, help me reach a clue about how to proceed in the
> most constructive direction.  This would be greatly appreciated.
>
> 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.
>