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