[15] RFR(S): 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?"

[Vladimir Kozlov]

Hi Christian,

compileBroker.hpp and other places - when you have only one line you can use DEBUG_ONLY( ) macro.
I think dump() method should print only duplicated tasks to avoid search duplicates in 5000 lines.

Can you use TieredThresholdPolicy::compare_methods() in compare_by_weight()? It would be nice to have the same logic 
which determines which method should be compiled first or removed from queue.

May be we should mark methods which are removed from queue or use counters decay or use other mechanisms to prevent 
methods be put back into queue immediately because their counters are high. You may not need to remove half of queue in 
such case.

Thanks,
Vladimir

On 4/24/20 7:37 AM, Christian Hagedorn wrote:
> Hi
> 
> Please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8230402
> 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.
> 
> Thank you!
> 
> Best regards,
> Christian
>