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 08:46:13 GMT
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
View raw message