Longjumps considered inexpensive...until they aren't

[John Rose]

On Jun 5, 2008, at 12:11 AM, Rémi Forax wrote:

> It allows wildcards (prefix or suffix)  so all entries are matched
> each time the runtime want to know if it can inline a method.

Yes.  This has not been a problem, since the compiler does not  
perform such queries very often.  It does not consume a significant  
fraction of CPU cycles, compared to the running application.

If it were a problem, or if it did not scale well to many marked  
methods, we would want to index the oracle.  At that point it would  
make sense to add a bit to the methodOop layout, saying whether the  
method was known to the oracle's index.

> Futhermore, compilerOracle only offers a hint
> at least with c1, INLINE_LEVEL, INLINE_SIZE etc have a
> higher priority than compilerOracle inline directive (should_inline).

We could add a must_inline or force_inline command to the oracle,  
then, unless there is some performance problem I've missed.

Actually, it is best to change the semantics of the existing inline  
command.  Let's try that first.  If a question arises about  
compatibility, we can make new tuning variables which will govern  
methods hand-marked for inlining, instead of the existing variables:

InlineSmallCodeWhenRequested
MaxInlineSizeWhenRequested
MaxInlineLevelWhenRequested

The inline command in the oracle is a new feature, not yet in wide  
use, so this is a reasonable change.

I see your point about adding a programmatic API.  (The oracle is  
currently a flat file.)  So let's add an Unsafe method, but have it  
take a string and pass it to the oracle to parse.  Take the incoming  
Java string, comvert to utf8 (there's a function in javaClasses.cpp)  
and pass the resulting C string to CompilerOracle::parse_from_line.

What do you think?

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20080605/2cb62592/attachment.html