Egor, Vtable objects pinning is required not only by JIT, this is also required by GC, which relies on that VTables are non movable. So this not a way to disable guarded devirtualization. Pinning is required anyway.
Aleksey. On 01 Nov 2006 10:37:41 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x214 day of Apache Harmony Rana Dasgupta 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. > 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, an alternative: JIT can disable guarded devirtualization via an option. Commit the unloading, use/tune GCV5 with that opion until it supports pinning. No branch required. > tune and test it , wait for GCV5 to start supporting pinning, try with MMTk, > and then integrate. 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 :-) -- Egor Pasko, Intel Managed Runtime Division
