RFR: 8290464: Optimize ResourceArea zapping on ResourceMark release

[Thomas Stuefe]

On Tue, 19 Jul 2022 13:33:18 GMT, Thomas Stuefe <stuefe 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 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.

Oh, and an assert would be nice that if we rollback inside the same chunk that the new hwm is smaller than the old one.

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

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