On the 0x217 day of Apache Harmony Ivan Volosyuk wrote: > 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.
Ivan, thank you for making it clear! > I already have one idea how to benefit from movable vtables. in GCV4.1? :) > -- > 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 > > > > :-) > -- Egor Pasko
