[Gc] PRINT_STATS kind, and free_space_divisor

Wed Nov 24 18:13:00 GMT 2004

Based on Jeroen's answer, it should be OK to ignore everything
but MEM_IMAGE. It would be nice to confirm that this works on
98/ME. (Even if it didn't we should do it where it works.)
This is very good news, since this has been a longstanding issue
on Windows. We probably want to fix this in 4.0.
The HBLKSIZE dependency is surprising to me. I will look more closely.
Hans
> -----Original Message-----
> From: Rutger Ovidius [mailto:r_ovidius@eml.cc]
> Sent: Tuesday, November 23, 2004 11:37 PM
> To: Boehm, Hans
> Cc: gc@napali.hpl.hp.com; java@gcc.gnu.org
> Subject: Re: [Gc] PRINT_STATS kind, and free_space_divisor
>>> Tuesday, November 23, 2004, 12:09:53 PM, you wrote:
>> BH> That's somewhat encouraging. At least that seems to be an
> BH> improvement.
>> BH> Re: new regions.
> BH> Unfortunately, it's hard to figure out what those are. They have
> BH> type MEM_PRIVATE. It would be wonderful if we could discard those
> BH> as well, and trace only from MEM_IMAGE sections. I'm pretty sure
> BH> that dll initialized data is mapped as MEM_IMAGE. Does anyone
> BH> know how win32 handles uninitialized data?
>> For fun I have skipped MEM_PRIVATE types as well (in the same way as
> your previous patch for MEM_MAPPED), and my app still works with a
> static root set staying constant at 2.5 megs (still big I guess, but
> better than 15).
>> I have no concept of what is in MEM_PRIVATE, nor if skipping these
> will cause any problems on any other type of OS, nor if there are
> problems that I can't see (would all problems reveal themselves in a
> crash, or are there more insidious possibilities?) Is it ok to skip
> MEM_MAPPED and MEM_PRIVATE on linux? I've only tried XP thus far and I
> don't know what would occur on NT/2K or 95/ME.
>> BH> My guess is that these regions result from memory 
> allocation outside
> BH> the GC. One other question would be whether there is a 
> leak outside the
> BH> GC, which would cause the root set to grow, which would cause the
> BH> GC heap to grow.
>> I don't know what this would be. The app uses SWT, which is jni. But,
> I'm not sure how to monitor its mem allocation.
>> BH> The GC tries to discard sections used by malloc. But it only
> BH> knows how to do this by periodically calling malloc, discarding
> BH> the region containing the resulting pointer, and the
> BH> deallocating the memory it got. This is a rather primitive
> BH> heuristic, and we know how to do much better under Linux.
>> BH> Re: total heap size
> BH> Did you multiply the size by the number of marks? Objects of
> BH> size smaller than 4K are allocated on 4K pages. The printed
> BH> block list contains one entry for each such page.
>> Some nmarks are 0, but I counted the byte_size once anyway in the
> total. The rest I have now multiplied by nmarks and still result in a
> total of ~3.5 megs, in a heap of 21 megs. This still seems excessive
> to me. Since most java objects are small, for fun I have tried making
> the HBLKSIZE = 512. This was much better. I've also tried 256 
> and my heap
> is now 7 megs. Since there are more heap blocks (blocks = 22992, bytes
> = 7068672), I guess this places a heavier burden on the CPU during
> each collection, but are there any other problems with manually
> setting this?
>> Most of my objects (~90%) seem to be less than 256 bytes. A few are
> 16k-70k and two are 580k & 680k. Is manually tweaking HBLKSIZE the
> best way to find the sweet spot? (reminds me of a certain file system)
>>> Regards,
> Rutger Ovidius
>>