RFR: 8290464: Optimize ResourceArea zapping on ResourceMark release

[Thomas Stuefe]

On Mon, 18 Jul 2022 18:29:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have `ResourceMark` scopes where we either do not resource-allocate at all (see the bug for the example), or we do not allocate a lot in the arena. Still, in debug builds, we are zapping the entirety of `ResourceArea` chunk in those cases. This wastes testing cycles unnecessarily. Doing this in a bit smarter way -- zapping only the parts that were actually allocated in the chunk -- makes testing significantly faster.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `FieldSetAccessibleTest` (~10% faster)
>  - [x] Linux x86_64 release, `FieldSetAccessibleTest` (no regressions)
>  - [x] Linux x86_64 fastdebug, `hotspot:tier1` (~5% faster)
>  - [x] Linux x86_64 release, `hotspot:tier1` (no regressions)
>  - [x] Linux x86_64 fastdebug, `tier1` (~2% faster)
>  - [x] Linux x86_64 release, `tier1` (no regressions)

src/hotspot/share/memory/resourceArea.hpp line 126:

> 124:     }
> 125: 
> 126:     if (have_more_chunks || (_hwm != state._hwm)) {

If we started another chunk, _hwm must have been changed. So I would shorten this to `if  (_hwm != state._hwm)`. You can add an assert that the hwm should be different if we have follow up chunks.

src/hotspot/share/memory/resourceArea.hpp line 140:

> 138:       // up to replaced hwm.
> 139:       if (ZapResourceArea) {
> 140:         char* limit = have_more_chunks ? _max : replaced_hwm;

I'd feel better if we instead did a range check on _hwm with the chunks boundaries. Zap the whole chunk if replaced hwm falls outside the current chunk.


limit = (_chunk->contains(replaced_hwm)) ? replaced_hwm : max;

That's at least clearer intent and possibly safer.

Also means you don't need your new "have_more_chunks" variable.

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

PR: https://git.openjdk.org/jdk/pull/9543