RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v3]
Emanuel Peter
epeter at openjdk.org
Thu Dec 11 12:15:23 UTC 2025
On Thu, 11 Dec 2025 10:32:34 GMT, Roland Westrelin <roland at openjdk.org> wrote:
>> src/hotspot/share/opto/loopnode.hpp line 1217:
>>
>>> 1215: PhaseTransform(Ideal_Loop),
>>> 1216: _arena(mtCompiler, Arena::Tag::tag_idealloop),
>>> 1217: _loop_or_ctrl(&_arena),
>>
>> How about some of the other data structures? For example `_idom`?
>
> They are allocated in the thread's resource area. So there's no leak and while for `_loop_or_ctrl` and `_body` there were issues that were solved by moving them to the compile arena, there hasn't been any so far with other data structures such as `_idom`. So, sure, we could pro actively move them to the new arena but do we gain anything from doing that?
Yes, I think we would! Keeping `_idom` on the thread resource area means we often cannot use `ResourceMark` for other data structures, if possibly `_idom` is modified in the same scope.
@iwanowww could not place `ResourceMark`s in some of this current PR:
https://github.com/openjdk/jdk/pull/25315
For example:
+bool PhaseIdealLoop::optimize_reachability_fences() {
+ Compile::TracePhase tp(_t_reachability_optimize);
+
+ assert(OptimizeReachabilityFences, "required");
+
+ // ResourceMark rm; // NB! not safe because insert_rf may trigger _idom reallocation
+ Unique_Node_List redundant_rfs;
+ GrowableArray<Pair<Node*,Node*>> worklist;
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2610352515
More information about the hotspot-dev
mailing list