RFR: Implementation of JEP 387: Elastic Metaspace (round two)

Thomas Stüfe thomas.stuefe at gmail.com
Tue Sep 22 17:20:11 UTC 2020


Hi Leo,

On Tue, Sep 22, 2020 at 5:13 PM Leo Korinth <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.

Thanks,
> Leo
>

Thanks, Thomas


More information about the hotspot-runtime-dev mailing list