-
Enhancement
-
Resolution: Fixed
-
P2
-
8
-
None
-
b04
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8045577 | 8u25 | Vladimir Ivanov | P2 | Resolved | Fixed | b01 |
JDK-8038400 | 8u20 | Vladimir Ivanov | P2 | Closed | Fixed | b09 |
JDK-8053805 | emb-8u26 | Vladimir Ivanov | P2 | Resolved | Fixed | b17 |
We're currently working on an OSR (on stack replacement) compilation framework for Nashorn. We're compiling functions to bytecode with optimistic assumptions, and when they're invalidated during execution, we jump out of the function, recompile it without the invalidated optimistic assumption, and then resume it.
(The mechanism of resumption is not important for the purposes of discussion here).
The "jump out of the function" part is important though, and we can only implement it by throwing an exception in the executing method, and by linking all such methods using a catchException combinator which does the recompilation/resume magic in its exception handler.
However, since all of our optimistically compiled functions are linked using catchException, we absolutely need it to be fast, so we need some fast, non-boxing hot paths for it.
Optimistic compilation gets most performance when we can force all arguments to be ints, so an educated guess is that Nashorn would benefit most from hot paths of the form (Object, int, int, ..., int) and (Object, Object, int, int, ..., int) (first one or two object arguments are either "this", or "callee, this" in Nashorn's case).
(The mechanism of resumption is not important for the purposes of discussion here).
The "jump out of the function" part is important though, and we can only implement it by throwing an exception in the executing method, and by linking all such methods using a catchException combinator which does the recompilation/resume magic in its exception handler.
However, since all of our optimistically compiled functions are linked using catchException, we absolutely need it to be fast, so we need some fast, non-boxing hot paths for it.
Optimistic compilation gets most performance when we can force all arguments to be ints, so an educated guess is that Nashorn would benefit most from hot paths of the form (Object, int, int, ..., int) and (Object, Object, int, int, ..., int) (first one or two object arguments are either "this", or "callee, this" in Nashorn's case).
- backported by
-
JDK-8045577 Improve performance of catchException combinator
-
- Resolved
-
-
JDK-8053805 Improve performance of catchException combinator
-
- Resolved
-
-
JDK-8038400 Improve performance of catchException combinator
-
- Closed
-
- relates to
-
JDK-8036732 Fix raw warning in java.lang.invoke.MethodHandleImpl.java
-
- Resolved
-
-
JDK-8038186 [TESTBUG] improvements of test j.l.i.MethodHandles
-
- Resolved
-