Egor, Object->VTable will still exist so no changes in devirtualizer are needed.
Thanks, Pavel On 26 Oct 2006 15:46:13 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x20E day of Apache Harmony Mikhail Fursov wrote: > Egor, > I would rather disagree in most of the details. :( Thanks for that, but I do not see any significant disagreement :) > 1) "1/10 of the whole heap is probably very much :)" > > No. You can't measure performance in method/class numbers and proportions at > all. It's normal situation when only 1% of methods consume 90% of CPU ticks. > Not all of them depends on devirtualization or classes unloaded. So you > can't say that 1 class unloaded is OK but 100% is bad. It's a lottery. I do not quite understand with what I disagree here :) I meant, increasing footprint by 1/10 due to class unloading support seems too much for a big application. Of course, it's a personal impression, application-dependant, etc. Just want to know the real number. They say, it would be much less than that. > 2) "hm, keeping VTable pointers on operands (and reporting them in root > sets) solves the problem. That slightly increases register pressure, > but I think is a better solution than pinning VTables (and rather > straightforward)." > > The Alexey's solution does not affect devirtualizer at all. How can we do without devirtualizer changes here? We need to replace Object->Vtable with Object->class->vtable. Am I missing something? > Unpinning vtables you have to include them into enumeration. I'm not > sure that moving vtables to opnds as object-type is a simple task > and think that it l will affect GC-enumeration part in JIT too. You think, GC enumeration would be difficult here? why? It's an ordinary object. > Another cons: type profiling we will have soon. You have to include it into > enumeration. why not? I see no extra complication here. -- Egor Pasko, Intel Managed Runtime Division
