harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Thu, 26 Oct 2006 10:32:34 GMT
On the 0x20E day of Apache Harmony Mikhail Fursov wrote:
> On 26 Oct 2006 15:46:13 +0700, Egor Pasko <egor.pasko@gmail.com> 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


Mime
View raw message