On 10/31/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
On 10/31/06, Etienne Gagnon <[EMAIL PROTECTED] > wrote: > >Yet: > > >1- You do need pinning, so you rule out some of the simplest GCs (e.g. > >simple, non-generational copying without pinning.) [Apparently, for > >some very large heaps, simple copying a can be quite difficult to beat, > >efficiency wise, if you believe some relatively recent JikesRVM related > >paper...] Yes, this was one of my concerns about the vtable object approach. This is limiting, but this is one specific GC requirement. (Maybe for GC's that don't support pinning, the JIT can compare object->vtable->class for guarded devirtiualization, or even not do guarded devirtualization, sort of support the GC in downlevel mode). For the refcounting method we need to hand off between GC and VM before and after processing weak references, update the generational or semispace related CL flags, and also use the GC to undo or rescue CL instances that may come alive due to the generational flag processing.
>2- You do have overhead even on minor collections. With my approach, > >you could limit the (quite similar to yours, if you put a > >class-loader/NULL pointer in the vtable) overhead only to selected GC > >cycles. I think the main advantage of the vtable object approach is that it is somewhat elegant and natural, if one can get past the idea of non C vtables :-). Special casing to avoid object->vtable scans during minor collections etc. just breaks that. Relying on GC all the way forces a class unloading overhead to every GC cycle( even for the young generation collections ). There is also a space overhead that I can't really estimate( proportional to class ....etc. etc.). As I understood it, there is no impact on MMTk based GC's, but I may be wrong.
Actually Robin Garner in the other class unloading thread ([drlvm] classs unloading support) said minor mods to MMTk might be required. If class unloading is done at specific moments only, the refcounting
approach does not add a perf overhead to each GC cycle, there is no heap overhead of the method either. But the former implies yet another secondary heuristic to optimally choose the class unloading triggers, this depends on the application profile and is not really once an hour/day etc. My guess( humbly ) would be that the refcounting method "may" be somewhat more time/space efficient, but that's probably not the only issue. There is the issue of implementation correctness, existing code, etc. And I don't know what's the best way to go to the next step. A suggestion could be to take Harmony-2000, review it, put it in a branch, tune and test it , wait for GCV5 to start supporting pinning, try with MMTk, and then integrate.
+1 I can't really visualize the changes to 40 files by looking at a diff file. It seems inefficient for all of us to battle applying the patch simply to be able to look at the code and set break points with the debugger. If we do this, the refcounting approach would be a
fallback for DRLVM. We need to decide on next steps, we cannot debate the algorithm forever :-)
-- Weldon Washburn Intel Enterprise Solutions Software Division
