This is a problem in mainline, but it would be more important for Leyden. CompileTask are never destructed. Freed CompileTasks are queued in the free list, and stay there indefinitely.

So, if we have a compilation spike where many compile tasks are created, all these tasks would end up on free list once compilation is finished. In Leyden, is it "normal" to have thousands of CompileTasks during the initial AOT load.

Each CompileTask is not small, about 160+ bytes. This means 1K of these tasks would take 160KB worth of native memory, forever. Every time we add another field to CompileTask, it would make this loss even greater. I found this when doing JDK-8231269, that added some padding around hot fields, greatly increasing CompileTask footprint. The additional RSS was closer to +1 MB on my Leyden experiments. This is... sub-optimal.

There are two ways out of this:
 1. Put a cap on the number of CompileTasks we maintain in the free list.
 2. Ditch the free list completely, and rely on new/delete on demand.

It is tempting to go (2), because CompileTask creation should be rare enough, and the associated AOT/JIT costs are large in comparison with native allocs. It would also help Leyden, since we would not have to take the CompileTaskAlloc_lock to manage the free list.

The two pecularities are: a) each CompileTask also has Mutex associated with it, and so we likely want to avoid too much churn on them (see also JDK-8357481); b) current Leyden uses CompileTasks free list coding to check if all created CompileTasks have competed during assembly. It would require some light re-engineering to fit.

So if (2) is insurmountable, we can go (1).