This is the mail archive of the
mailing list for the Java project.
GC and static data (Was: Projects)
> <li>If an object or array is allocated in static code that is
> executed at most once (i.e. not in a loop or in a non-private
> method), then we have the option of pre-allocating the object
> or array in the static data or bss segment. This is most
> obviously the right thing to do when the expression is an array
> brace initializer whose elements are compile-time constants, since
> then we can initialize the array statically. (This is already
This actually makes sense for our current GC scheme, but someone I
know working on an incremental collector considers this a big lose.
The incremental collector has to finish a full scan of the root set
and then handle any newly created objects in one pass (with all the
mutators blocked). Putting a lot of data into static memory (root
set) slows this down a lot, especially if the data is not changing (as
would be the case in Class objects, for instance).
In this scenario, I believe dynamically allocating as much as possible
would make sense. Perhaps we should introduce a compiler flag to
Jon - I'm curious if this your experience as well.
Hmm... now that I think about it, I believe you're already dynamically
allocating everything from some kind of compressed pickled state.
Anthony Green Red Hat