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.