Re: Generational GC Automatic Heap Sizing : Runtime parameters

Carl Lebsack wrote:
> On Sun, 3 Oct 2004, Chris Pickett wrote:
>>Essentially, implementing "runtime selection" would require us to:
>>
>>   a) convert your #ifdef's to if (env->vm->sablevm_ggc == JNI_TRUE){...}
> 
> 
> Since the WB are executed frequently wrapping them in an if wouldn't be 
> any good.  Actually, the implementation I have is the equivalent as the WB 
> is just an if(conditions){save-reference} that will fail on the first 
> condition if there is no nursery.

Okay.  Can you get some numbers on the overhead of these conditions on 
the "simulated" (nursery size zero) copying GC vs. actual copying GC 
that doesn't have these conditions?  If it's almost zero, then it's not 
worth optimizing ...

>>   b) convert these tests back to #ifdef's using m4 if overhead exists.
> 
> 
> I'm not sure how this would be done as I have very limited familiarity 
> with m4, but it would require m4 processing of several files that do not 
> require it currently.

If we did this, it would be a global kind of thing (many runtime 
selectable properties could become static).  Etienne and Greg and to 
some extent myself have experience with m4, so we could figure something 
out eventually -- it wouldn't be on your shoulders.

>>2) Is there any cloned (duplicated) code from copying GC in GGC?  If so, 
>>can it be pushed into shared functions or m4 macros?
> 
> 
> GGC is largely derivative of the copying GC and shares a lot of code.  I 
> could have implemented GGC by simply injecting into the copying collector, 
> but with the large number of small changes that were necessary, I thought 
> it would be cleaner to simply create a separate file.
> 
> The GGC implementation is a code superset of the original collector and as 
> I mentioned can be configured to behave as the original collector by 
> setting the nursery size to 0.
> 
> I'm not sure what the future goals for SableVM are and how they relate to 
> decisions of what to do with the GC structure.  As I see it SableVM now 
> has 2 functioning GC implementations that a GC researcher might be 
> interested in.  GGC is not simply some minor implementation tweaks but 
> a separate algorithm and thus having both distinguishable implementations 
> might be of interest to others such as myself working on memory 
> management research.  From the user standpoint, GGC can act as either 
> implementation and generally should outperform the standard semi-space 
> collector.  So most people probably will not need to compile the original 
> collector.
> 
> As far as m4, I learned just what I needed to include write barriers where 
> needed, and really don't have the expertise, nor the understanding of its 
> general application to this project to really offer input as to whether it 
> should be used here.

Basically m4 reduces duplication and makes the tree easier to maintain. 
  We have three separate interpreters for example, but they're all 
derived from the same code base using m4.  In my opinion all duplication 
is bad.

However, I haven't looked at your code, and you said many changes were 
necessary.  I will look sometime after the middle of October and discuss 
with Greg and/or Etienne.

Cheers,
Chris

P.S.  That was helpful.  It's not white noise at all.

P.P.S.  If you publish tech reports or papers or theses on this, we'd 
love to know about them so we can link from the web site.