Unusually high polymorphic dispatch costs?

[Mark Roos]

The system I am porting redoes its compilation based on code size 
generated not
objects generated.  So if the object code in active execution is less than 
1 meg no flushes/redux
occur.  So the examples you gave would not cause a code cache flush.  I 
could see where a
system based on objects created or total object size would have issues.

The closest metric I will have in the jvm version will be active call 
sites.  As I need to
keep a collection of them in order to perform an invalidate on code 
replacement my thought was to
dump them all at some point.  Perhaps when it reaches the 2-5K range.

By the way a code cache flush is pretty fast today,   adds about 25 ms to 
rebuild 500 call sites.  Once I
add the invalidate I'll see how it fares in java 

regards
mark





From:
Rémi Forax <forax at univ-mlv.fr>
To:
mlvm-dev at openjdk.java.net
Date:
05/02/2011 08:59 AM
Subject:
Re: Unusually high polymorphic dispatch costs?
Sent by:
mlvm-dev-bounces at openjdk.java.net



On 05/01/2011 11:01 PM, Mark Roos wrote: 
In the Smalltalk I am porting the solution they use is to just drop the 
entire chain and let it 
reform.  The assumption would be that for any short time period in the 
life of a program no sites 
are megamorphic.  the metric they use is the total amount of active code. 
Since they actually 
drop all compiled code when it hits 1 meg they have an easy way of 
determining the active 
code amount. 

There are some well known API in which this assumption is not true.
GUI API like Swing (think setVisible) or parser AST visitor (think 
accept).

I don't know if it's still the case but V8 (google javascript engine) was 
using
a similar idea, it flush all callsites when a full GC occurs. 


What I was thinking of was just dropping the gwt chain when it reached 
some depth.  The 
question is what depth.  I think I'll add a counter to the call site just 
to see what happens. 

It would be nice to have a way to walk the chain but I don't see an method 
to get the original 
mh from a mh adapter. 

MethodHandle reflection is one item of the issue list for JSR 292 the 
return.


regards 
mark

cheers,
Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110502/aa8fd0c3/attachment.html