[Gc] PRINT_STATS kind, and free_space_divisor
r_ovidius at eml.cc
Tue Nov 23 23:36:58 PST 2004
Tuesday, November 23, 2004, 12:09:53 PM, you wrote:
BH> That's somewhat encouraging. At least that seems to be an
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
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)
More information about the Gc