[Gc] PRINT_STATS kind, and free_space_divisor

[Rutger Ovidius]

Monday, November 22, 2004, 10:37:10 AM, you wrote:

BH> A large free_space_divisor setting will have the effect you describe.
BH> The gcj root size really needs to get fixed.  You might try adjusting
BH> it dynamically, if you know that you will be going through a phase
BH> during which very little memory is dropped.

I can't really do this from standard java AFAIK. (without patching and
making gcj specific calls, which I'm trying to avoid)

BH> (If you want to understand more about where the 15MB of roots are
BH> coming from, check whether your version of the GC checks
BH> DEBUG_VIRTUALQUERY in dyn_load.c.  If so, you can turn that on,
BH> which will produce tons of output.  It looks like the collector
BH> might be able to ignore segments of type MEM_MAPPED(0x40000).
BH> If you see a large number of those, it's easy to patch the
BH> collector to get rid of them.  That will either improve matters,
BH> or cause a crash.  I would guess it will improve matters, but it
BH> would be great to find out either way.  Unless I hear complaints,
BH> gc7.0alpha2 and later will start to ignore MEM_MAPPED segments.)

The full gc.log (gc1.zip, 47k):
http://tinyurl.com/4n3qe

Here is what I see for Type=40000:

BaseAddress = 360000, AllocationBase = 360000, RegionSize = 1000(4096)          AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 1790000, AllocationBase = 1790000, RegionSize = 1ea000(2007040)   AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 1980000, AllocationBase = 1980000, RegionSize = 1000(4096)        AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 1990000, AllocationBase = 1990000, RegionSize = 10000(65536)      AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 2500000, AllocationBase = 2500000, RegionSize = 10000(65536)      AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 2550000, AllocationBase = 2550000, RegionSize = 5000(20480)       AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 30d0000, AllocationBase = 30d0000, RegionSize = 4000(16384)       AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 3150000, AllocationBase = 3150000, RegionSize = 1000(4096)        AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 3160000, AllocationBase = 3160000, RegionSize = 8000(32768)       AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 3230000, AllocationBase = 3230000, RegionSize = 6000(24576)       AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 3630000, AllocationBase = 3630000, RegionSize = 3e4000(4079616)   AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 3a20000, AllocationBase = 3a20000, RegionSize = 2d8000(2981888)   AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 4410000, AllocationBase = 4410000, RegionSize = 1000(4096)        AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 5ff0000, AllocationBase = 5ff0000, RegionSize = 2000(8192)        AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 6260000, AllocationBase = 6260000, RegionSize = 14000(81920)      AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000
BaseAddress = 6380000, AllocationBase = 6380000, RegionSize = 4000(16384)       AllocationProtect = 4, State = 1000, Protect = 4, Type = 40000


Whereabouts in the source is the correct place to try to get the gc to
get rid of them? I use a relatively recent cvs head version of gcc.

This will be saving gc time/cpu by not having to scan these roots, correct?
It won't have any (dramatic) effect on memory use?

BH> The rest of this is gcj-specific:

BH> Kind=6 probably refers to Java arrays with more than 16K elements.
BH> Kinds can be created dynamically by the client (through an interface
BH> that's slowly getting less obscure).  This gives Java a way to register
BH> it's own tracing procedure for such arrays, which skips the initial
BH> size field.  (For smaller arrays, we cheat, since we assume that
BH> such sizes can't look like addresses anyway.  Thus the default
BH> conservative scan costs nothing and is faster.)  See _Jv_AllocArray
BH> in gcc/boehm.cc.

Thanks, found it.

Regards,
Rutger Ovidius