RFR: 8329665: fatal error: memory leak: allocating without ResourceMark

Dean Long dlong at openjdk.org
Fri Apr 5 22:02:19 UTC 2024


On Fri, 5 Apr 2024 20:36:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are two places in Loom code that call f.oops_interpreted_do() to process oops in the stackChunk. Although not obvious this method seem to require to have a ResourceMark on scope and there are several contexts where these two are call where we don't have one. The reason why a ResourceMark is needed is because OopMapCache::compute_one_oop_map() might allocate from the resource area if _mask_size is > 4 * BitsPerWord, which depends on the amount of locals + expression stack of the corresponding method. But ~InterpreterOopMap already checks if the _bit_mask was allocated in the resource area and in that case it will free it. So the ResourceMark is not strictly needed except that in debug mode we will actually hit the assert if there is not one in scope when trying to allocate the _bit_mask.
>> 
>> Thanks,
>> Patricio
>
> src/hotspot/share/runtime/frame.cpp line 888:
> 
>> 886:   assert(is_interpreted_frame(), "Not an interpreted frame");
>> 887:   Thread *thread = Thread::current();
>> 888:   DEBUG_ONLY(ResourceMark rm(thread);) // ~InterpreterOopMap already handles possible deallocation of bitmask
> 
> I don't like that this is in debug mode only either.  We have the current thread so that's a part of the cost of ResourceMark (or historically been the cost).  I wonder if this "optimization" can be observed.  I'd rather the explicit resource allocation deletion be removed also, since this is surprising.

I'm guessing the explicit resource array deletion was an attempt to save memory if the ResourceMark was outside a loop iterating frames.  But if the ResourceMark is inside the loop, it seems pointless.  I think uses of other frame iterators like vframes have the ResourceMark on the outside, and that apparently hasn't caused memory footprint issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18632#discussion_r1554348880


More information about the hotspot-dev mailing list