-
Enhancement
-
Resolution: Fixed
-
P3
-
None
-
b81
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8142231 | emb-9 | Maurizio Cimadamore | P3 | Resolved | Fixed | team |
Execution of combo tests in langtools is not as efficient as it should be; profiling the execution of our heaviest combo test - StructuralMostSpecificTest - reveals that javac is spending a considerable amount of time (i.e. ~80%) in JavacTaskImpl.enter() - which is surprising - there are two main reasons for that:
1) each time we fork a new javac task, we need to do a lookup with service API for available anno processors
2) ClassFinder.scanPlatformPath is also spending a lot of time re-accessing JDK packages over and over
Those issues could be avoided if combo instances kept reusing the same javac context over and over (pretty much as annotation processors do in JDK 9).
1) each time we fork a new javac task, we need to do a lookup with service API for available anno processors
2) ClassFinder.scanPlatformPath is also spending a lot of time re-accessing JDK packages over and over
Those issues could be avoided if combo instances kept reusing the same javac context over and over (pretty much as annotation processors do in JDK 9).
- backported by
-
JDK-8142231 Investigate performance improvements in langtools combo tests
-
- Resolved
-
- relates to
-
JDK-8135246 CheckAttributedTree silently generates spurious compiler error
-
- Closed
-