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
