RFR: Implementation of JEP 387: Elastic Metaspace (round two)
Leo Korinth
leo.korinth at oracle.com
Tue Sep 22 21:40:41 UTC 2020
On 22/09/2020 19:20, Thomas Stüfe wrote:
> Hi Leo,
>
> On Tue, Sep 22, 2020 at 5:13 PM Leo Korinth <leo.korinth at oracle.com <mailto:leo.korinth at oracle.com>> wrote:
>
> Hi!
>
> I have a question regarding ChunkManager::purge().
>
> In part: 1) purge virtual space list
>
> We try to purge empty VirtualSpaceNodes. We also remove the free chunks
> from the free list (_chunks) if we are successful. I can not see that
> we ever uncommit these chunks.
>
> Later, in part: 2) uncommit free chunks
>
> We iterate the free list and uncommits the free chunks, the problem is
> that we might have removed chunks from the free list in part 1 even though
> we did no uncommit.
>
> To me, it seems we are missing to uncommit memory here, I am probably missing something, but what?
>
>
> Good spotting. Yes, you do miss something, but it is obscure and I should comment this better.
>
> When we purge the vslist, we remove and delete all nodes which are purgeable (all chunks are free, and the node owns the underlying space). Deleting a node includes unmapping the underlying memory (ReservedSpace::release(), see ~VirtualSpaceNode()). So the underlying memory is gone, no need to individually uncommit each chunk.
>
> Note that (1) and (2) are completely independent from each other. (1) takes care of the rare chance of completely unmapping whole nodes. (2) takes care of uncommitting free chunks in nodes which had been unpurgeable. Arguably, (2) may be redundant since we uncommit chunks >= commit granule size already before, when returning them to the ChunkManager (see Chunkmanager::return_chunk_locked()). I left it in as a safeguard.
>
> Side node, (1) we did before in the old Metaspace, that purge mechanism is mostly unchanged. The problem with that approach is that we only rarely have the chance of purging a whole node, since all chunks in the node have to be free together.
>
I see, thanks for the explanation!
/Leo
More information about the hotspot-runtime-dev
mailing list