harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm] Class unloading support - tested one approach
Date Thu, 02 Nov 2006 05:40:34 GMT
Weldon Washburn wrote:
> 
>                     Its probably in the noise but it might be possible to
> even reduce the overhead of clearing the vtable "mark" by using a epoch
> number instead of a boolean.  The idea is that after every major GC,
> increment the value used for the mark.  When sweeping the vtables, the 
> stale
> mark values are the unreachable classes.
> 
> cheers

Right.  I'm assuming we're all on the same page here, but I'll spell it 
out anyway:  The number of objects is orders of magnitude higher than 
the number of classes, so any operation on a 'per-class' basis can 
afford to be expensive, whereas per-object operations need to be fast.

Just looking at my stats for SpecJVM98, JBB 2000 and DaCapo 2006-10, the 
ratio of live objects to classes loaded is ~500:1 (geometric mean).  The 
extremes are 11:1 (jython) to 24000:1 (hsqldb).  These are probably also 
  very small heaps compared to enterprise workloads, which would drive 
the number of objects/class up.

The other consideration is that you are not going to want to check for 
unloadable classloaders at every GC.

Therefore, within reason, I don't think the efficiency of per-class 
operations is much of a consideration.

 >                  Its probably in the noise but it might be possible to
 > even reduce the overhead of clearing the vtable "mark" by using a epoch
 > number instead of a boolean.

Under the circumstances, requiring an additional register during GC to 
hold the class epoch number probably loses more than it gains.

cheers

Mime
View raw message