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
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
