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 <fo...@univ-mlv.fr> To: mlvm-dev@openjdk.java.net Date: 05/02/2011 08:59 AM Subject: Re: Unusually high polymorphic dispatch costs? Sent by: mlvm-dev-boun...@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@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
