On Sep 18, 2011, at 7:16 PM, Mark Roos wrote: > In looking at my code. > > In general 98% of the callsites are < 3 targets. > > Those that are larger I can catch and use a different lookup. I also believe > that Charles Nutter limits his > depth to 5. > > So the general case I see will not exceed the < 10. > > But I do have some cases where 10 is not the right number
You can adjust that number in your runtime startup script since the switch that drives that number is a product switch: -XX:PerCallSiteSetTargetTrapLimit=50 > > Part of my app is a compiler so some of its callsites see 20 or 30 > classes ( AST node types). > And part is a data flow evaluator where the data has about 30 types > > And as I watch the jit work it attacks these sites pretty fast so I could > image exceeding the > 10. > > I would like both or these to jit as they are used a lot > > And my final use case which is dynamic method replacement. Here I have to > reset the callsites so they > get the correct code. In our system this happens doing feature loading ( > small dynamic patches) and for > changing math operations ( dataflow) and finally during edit. Both easily > exceed the >10 during the execution > life of the app (hopefully months). > > I would be fine if there was a way to tell the jitter to reset its counts on > a callsite as all of my use cases > can absorb time at that instance. I really would have issues with losing the > jitting when the app is expected > to be running at full speed and would have to find some clever hack around > it. Tom suggested in a pre-review of the patch that we could (a) have a rate instead of a counter or (b) only count actual deoptimizations (which might be a simple fix for now and decide later if that's good or we need something else). As Remi mentioned we need throttling like this but we don't have enough data yet to tell what is the best approach. Mark, could you try that patch with your implementation? -- Christian > > Another point is that the classes callsites see during startup can be quite > different than during normal operation. > This is another reason we do the bulk invalidation > > mark_______________________________________________ > 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
