JDK-8230402 : Allocation of compile task fails with assert: "Leaking compilation tasks?"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13,14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-08-30
  • Updated: 2020-12-01
  • Resolved: 2020-05-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 15
11.0.9-oracleFixed 13.0.6Fixed 15 b22Fixed
Related Reports
Relates :  
JDK-8163511 - Allocation of compile task fails with assert: "Leaking compilation tasks?"
Description
Even after JDK-8163511 has been resolved, in mach5 testing, we are still seeing the following failure occasionally.

Crash: Internal Error ...compileTask.cpp...assert(WhiteBoxAPI || UseJVMCICompiler || _num_allocated_tasks < ...) failed: Leaking compilation tasks?
Crash: V ...[libjvm.so+...] CompileTask::allocate()+...

Most of the failures are in the valhalla repo (which has the JDK-8163511 fix), but two failures are from JDK 13 after Jun 2019, which should also have the JDK-8163511 fix
Comments
Fix request (13u) I'd like to downport it, too, as it is in both 15 and 11. Patch applies clean.
01-12-2020
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.9-oracle. I had to do a simple resolve: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003225.html
03-06-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/2ca886fd1d52 User: chagedorn Date: 2020-05-04 09:40:18 +0000
04-05-2020
After discussions in the RFR [1], we decided to just remove the assert: http://cr.openjdk.java.net/~chagedorn/8230402/webrev.02/ [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/038027.html
04-05-2020
http://cr.openjdk.java.net/~chagedorn/8230402/webrev.00/ This assert was hit very intermittently in an internal test until jdk-14+19. The test was changed afterwards and the assert was not observed to fail anymore. However, the problem of having too many tasks in the queue is still present (i.e. the compile queue is growing too quickly and the compiler(s) too slow to catch up). This assert can easily be hit by creating many class loaders which load many methods which are immediately compiled by setting a low compilation threshold as used in runA() in the testcase. Therefore, I suggest to tackle this problem with a general solution to drop half of the compilation tasks in CompileQueue::add() when a queue size of 10000 is reached and none of the other conditions of this assert hold (no Whitebox or JVMCI compiler). For tiered compilation, the tasks with the lowest method weight() or which are unloaded are removed from the queue (without altering the order of the remaining tasks in the queue). Without tiered compilation (i.e. SimpleCompPolicy), the tasks from the tail of the queue are removed. An additional verification in debug builds should ensure that there are no duplicated tasks. I assume that part of the reason of the original assert was to detect such duplicates.
24-04-2020
ILW = Same as JDK-8163511 = P3
02-09-2019