Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations

[Mark Roos]

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

        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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110918/cc9c4b03/attachment.html