On the 0x20E day of Apache Harmony Mikhail Fursov wrote: > On 26 Oct 2006 15:46:13 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > > 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. > > What numbers do you mean when you say "too much"? Memory footprint?
yes, I did mean that > Not: the memory footprint is the number of objects (not classes) > created. I was afraid of more references kept in total. That could have increased the footprint. Aleksey clarified that no extra pointers are introduced (VTable ptr -> VTable ref in each object) ptrs and refs have the same size (refs can be even less space-consuming on x86_64 due to common compression). Aleksey also pointed out that some extra refs appear -- pointers to VTable from VTable objects. So, we are loosing extra (4 * <number_of_VTables>) bytes more with this approach (on IA32). But it is "not much", IMHO :) I cannot clarify more :) > Performance: not again. Mikhail, sorry if I lead it into confusion :( > > 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. > > > The real number depends on a real application and application type. With AS > that runs for months without reboot you can have almost every class reloaded > thousands of times. A big and configured client application can use multiple > classloaders only to load classes and never unload it. Surely, I agree here. > > 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? > > Before and after Alexey's solution you have a constant in object header. Why > to change devirtualizer here? OK. Rereading the thread helped me now. Sorry. object->vtable stays the same. Now I see your point. Sure, VTables should be pinned in this case! Anyway, improving devirtualizer to report VTables seems useful. Not obvious, need to make specific performance measurements, but.. > > 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. > > I have no exact estimation right now. It's not an easy task even to estimate > all of the places where we have to change the design if vtable are unpinned. I see no places except devirtualizer and CG (implementing a special ldfield instruction to load VTable by offset). Oh, yes, Translator inlining. Collecting the places started :) > This is the reason I asked Aleksey to be careful if he decides to unpin > vtables someday. OK, let it be. (I just do not like these pinned objects due to such a "minor" issue) > > Another cons: type profiling we will have soon. You have to include it > > into > > > enumeration. > > > > why not? I see no extra complication here. > > Yes. The complication is enumeration from inside of profile collector > itself. It's possible, but, again, let's be careful. Oh, yes, value profile collector should be an interesting piece of code. -- Egor Pasko, Intel Managed Runtime Division
