harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Thu, 26 Oct 2006 09:10:26 GMT
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? Not: the
memory footprint is the number of objects (not classes) created.
Performance: not again.

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.

> 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?

> 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.

This is the reason I asked Aleksey to be careful if he decides to unpin
vtables someday.


> 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.



-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message