In current GCv4.1 implementation there is an assumption that vtables will not move. It is used in compaction algorithm. Strictly speaking, the only thing I need is to distinguish objects and vtables during allocation. If so, one of GC algorithms may treat vtables as pinned objects, while another could make use of the ability to move the vtables. I already have one idea how to benefit from movable vtables. -- Ivan
On 03 Nov 2006 14:34:41 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x214 day of Apache Harmony Aleksey Ignatenko wrote: > 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. Sorry, but I am not aware of places, where pinning is required other than for JIT. If you menttion one or two, that would be great for understanding and the next step to beat my ignorance in this subject :) > 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 > > :-)
