-
Enhancement
-
Resolution: Fixed
-
P4
-
7
-
b06
-
generic
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8045705 | 8u25 | Sergey Bylokhov | P4 | Resolved | Fixed | b01 |
| JDK-8040679 | 8u20 | Sergey Bylokhov | P4 | Resolved | Fixed | b11 |
| JDK-8053536 | emb-8u26 | Sergey Bylokhov | P4 | Resolved | Fixed | b17 |
getDefulatToolkit() has following code:
// We disable the JIT during toolkit initialization. This
// tends to touch lots of classes that aren't needed again
// later and therefore JITing is counter-productiive.
java.lang.Compiler.disable();
It might be legacy code and because JIT seems to be diabled globally it might affect code working in other threads.
I've checked couple tests with -XX:+PrintCompilation and observe exactly same set of compiled methods with
and without this code. It is still possible that tracing what is accessed during toolkit initialization
is waste of resources but i am not sure that diabling compilation does disable tracing too.
// We disable the JIT during toolkit initialization. This
// tends to touch lots of classes that aren't needed again
// later and therefore JITing is counter-productiive.
java.lang.Compiler.disable();
It might be legacy code and because JIT seems to be diabled globally it might affect code working in other threads.
I've checked couple tests with -XX:+PrintCompilation and observe exactly same set of compiled methods with
and without this code. It is still possible that tracing what is accessed during toolkit initialization
is waste of resources but i am not sure that diabling compilation does disable tracing too.
- backported by
-
JDK-8040679 Consider removal of code disabling JIT in Toolkit.getDefaultToolkit
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- duplicates
-
JDK-8034855 Toolkit class should not disable JIT compiler
-
- Closed
-
- relates to
-
-
- Closed
-