harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Thu, 26 Oct 2006 09:06:49 GMT
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 <egor.pasko@gmail.com> 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
>
>

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