Re: [Gc] PRINT_STATS kind, and free_space_divisor

[Rutger Ovidius <r_ovidius at eml dot cc>]

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