oracle
Detect cold CallTarget invalidation and reset its profile
Closes: #11045
Please review this patch that modifies Truffle to:
-
Reset a CallTarget's profile when the
nmethodassociated with it was invalidated by HotSpot because the Code Cache's method flushing heuristics deemed the nmethod to be cold. -
Limit the number of compilations that a CallTarget can have within a time period. This doesn't change the current behavior, instead it just makes the constraint more flexible. I added a new parameter,
MaximumCompilationsWindow, that the user can set to specify a time window within which the number of compilations will be limited (currently the window is whole duration of application execution).
Tests:
- OSX AArch64 with LabsJDK "tip" using "mx gate"
- Linux x65 with LabsJDK "tip" using "mx gate"
- GitHub Actions
- We have been running an internal system with similar changes for months and we didn't notice any regression.
Looks reasonable to me but a more detailed review should be done by @tzezula or @chumer.
@chumer, I did a refactoring of the code following your suggestions. Basically, I changed two things:
- I dropped the changes related to resetting number of compilations based on time. The approach now is to reset
successfullRecompilationCountwhen the method was invalidated because it was cold. - I reverted the changes in
HotspotOptimizedCallTargetto detect that the method was invalidated. I implemented the idea that you suggested: verifying the invalidation reason of the call target when it's about to be recompiled.
I tested the latest changes using the approach described in the issue ticket and everything worked fine. mx unittest and mx gate also didn't raise any issue.
@chumer - I believe I addressed all your comments. Please, take a look again when you can.
@jchalou please give this another pair of eyes. If its fine feel free to integrate.
@JohnTortugo any chance we could have a smoke test for this behavior? That is reasonably complex? Would be great to be notified if this breaks.