heap fragmentation?

Thu Jun 6 19:48:00 GMT 2002

Jeff Sturm wrote:
>On Wed, 5 Jun 2002, Boehm, Hans wrote:
>>>>If we can identify what shouldn't be scanned, it should be fairly easy
>>to avoid doing so. Reducing that number by 5 MB should reduce the heap
>>size by about 7MB, while leaving the time spent in the GC roughly
>>unchanged.
>>>>>>.eh_frame isn't needed in the root set. That takes care of ~1MB.
>>Uninitialized classes shouldn't be scanned. That'll be much of the rest
>of the data segment. It's not clear what the easiest/best way to go about
>that is. If, for example, we could arrange for no class objects to be in
>the root set, then we could hook into GC_push_other_roots() to walk the
>initialized classes and push their static members.
>
Part of my grand binary compatibility plan is to not have static class 
data. Instead, class metadata would be entirely symbolic (no pointers 
except to local utf8consts), and java.lang.Class objects would be 
created at runtime as classes are initialized. This would reduce binary 
size and linker startup time. Static class fields would be "inlined" 
into the class object. In this case there would be no static data at all 
for the GC to scan (presuming we place restrictions on static references 
in CNI), everything would be reachable from the stack.
A potential disadvantage (or an advantage depending on which way you 
look at it) of this approach is that it pushes link errors like missing 
classes to runtime.
regards
Bryce.