Add extra logging when compilationHeapLimitExceeded occurs

[KavinSatheeskumar]

Fixes #22627

[KavinSatheeskumar]

Tested on prestoDB, error messages correctly print when scratch memory is limited to 128KB

[mpirvu]

LGTM. As discussed, please post a message sample.

[mpirvu]

jenkins compile all jdk8,jdk21

[mpirvu]

jenkins test sanity.functional xlinux jdk21

[KavinSatheeskumar]

Examples of error messages
warm) java/lang/invoke/DirectHandle.invokeExact_thunkArchetype_I(Ljava/lang/Object;IILjava/lang/Object;)I Q_SZ=0 Q_SZI=0 QW=1 j9m=00007F579C1A30D0 time=1596us compilationHeapLimitExceeded VmState=0x00050080 OptIdx=16 OptName=loopReduction memLimit=1024 KB compThreadID=0

java/lang/invoke/ConstantObjectHandle.invokeExact_thunkArchetype_L()Ljava/lang/Object; Q_SZ=4 Q_SZI=2 QW=10 j9m=00007FD44416E1D8 time=740us compilationHeapLimitExceeded VmState=0x0005ffff memLimit=128 KB compThreadID=0

[mpirvu]

jenkins compile all jdk8,jdk25

[mpirvu]

jenkins test sanity.functional all jdk21

[mpirvu]

Requirements have changed slightly. The failure line should also include the name of the optimization.

[mpirvu]

LGTM

[mpirvu]

jenkins compile all jdk25

[mpirvu]

jenkins test sanity.functional zlinux jdk21

[mpirvu]

Tests have passed. Ready to merge.
@KavinSatheeskumar Please change the output from comment #22639 (comment) to match the new implementation.

[mpirvu]

Current version of the code always shows the vmState as 0x50080 which is ILgen (instead of an optimization). This happens because on this line: https://github.com/eclipse-omr/omr/blob/master/compiler/optimizer/OMROptimizer.cpp#L1012 we create an object of type CompilationPhaseScope which remembers the previous vmstate (in this case Ilgen). Before each optimization we call J9::Compilation::reportOptimizationPhase(OMR::Optimizations opts) to adjust the vmState accordingly. However, if an exception is thrown, the stack is unwound, the CompilationPhaseScope object is destroyed and the destructor restores the vmState to ILgen. Eliminating the aforementioned line keeps the vmState that produced the compilation failure.
@vijaysun-omr Do you know the purpose of the CompilationPhaseScope object? Can it be eliminated safely?

Note that there are other CompilationPhaseScope objects for scopes that build aliases, structure, useDefs, valueNumbers, etc. While those do not affect the implementation of this PR, I think they should be replaced with code that saves and restores the vmState at the start and end of the scope. This would keep the information in case of an exception.

[vijaysun-omr]

I'm not aware of that CompilationPhaseScope and its purpose. It may have been created around the time we went open source or some other refactoring in the last decade, but I may be mistaken. Maybe @hzongaro knows the history ?

[mpirvu]

jenkins compile xlinux jdk25

[hzongaro]

I'm not aware of that CompilationPhaseScope and its purpose. It may have been created around the time we went open source or some other refactoring in the last decade, but I may be mistaken. Maybe @hzongaro knows the history ?

I wasn't sure of the reason for CompilationPhaseScope either. I found changes from 2015 that introduced the class, but the comments are very brief

Improve optimizer vmStates - vmState work: CompilationPhaseScope, analysis phases

and

Improve optimizer vmStates - Fix CompilationPhaseScope to properly guard phase changes during ilgen, and other minor cleanup

The associated work item says this:

1. Save vmState before running ILGen opts, and restore it afterward. That will stop inliner crashes from being misreported as an ILGen opt.
2. Assign numbers to the various supplemental analyses the optimizer does (structure, use-def, value numbers, various dataflows, block frequencies, etc.) and other activities. Then use a vmState of the form 5xxyy where xx is the optimization and yy is the supplemental analysis (ff meaning the opt itself is running).

So it seems like the first point was the primary reason for being able to push and pop the vmState.

[0xdaryl]

What is the next step for this PR?

[mpirvu]

What is the next step for this PR?

During testing we discovered that the reported compilation phases were wrong due to stack unwinding as explained in omr PR eclipse-omr/omr#7959 After that omr PR is delivered, this will be delivered as well.

[mpirvu]

This fix in eclipse-omr/omr#7959 has been promoted, so this PR can be merged.