This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

GC and static data (Was: Projects)

Per wrote:
>	  <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
>	  implemented.)

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
                                                       Sunnyvale, California

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]