RE: [Gc] PRINT_STATS kind, and free_space_divisor

["Boehm, Hans" <hans dot boehm at hp dot com>]

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
> 
>