RFR: 8311648: Refactor the Arena/Chunk/ChunkPool interface [v6]

[Johan Sjölen]

On Wed, 19 Jul 2023 13:02:14 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR refactors the Arena code without introducing any changes in behavior. I believe that this leads to a much clearer API and that this will in turn simplify the maintenance of this code. `Chunk` is now much more "dumb", mainly acting as a way of interrogating the chunk of data that it is holding. The `ChunkPool` gains a more prominent role, being entirely responsible for the memory allocation strategy used. `Arena` is basically unchanged, as it orchestrates the usage of these two APIs. The `chop` and `next_chop` methods are re-defined to be static inside of `Chunk`, having an object `delete` itself  is very surprising, so I'm happy to get rid of that.
>> 
>> I hope that you agree with me on these changes!
>> 
>> Cheers,
>> Johan
>
> Johan Sjölen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into rework-arena
>  - Swap around argument
>  - Move stuff around to make diffs smaller
>  - Remove comments
>  - Hide ChunkPool, make ChunkPoolCleaner be started from Arena
>  - One more comment
>  - Remove comment sections
>  - Missed two small issues
>  - Move allocation responsibilities to ChunkPool
>  - Remove operator new/delete
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e8f66bf8...d8196bab

Hi,

@tstuefe , @coleenp, I found the bug. The issue was that `Chunk::operator new` would implicitly call the constructor of `Chunk` and thus overwrite previous content of chunks taken from the pool. I forgot to call the constructor for chunks taken from the pool. I've rewritten `allocate_chunk` so that there are two allocation branches that both end with the constructor being called via placement new.

I also merged in the new `clean` method. We'll see what CI says now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14803#issuecomment-1668453826