Detect cold CallTarget invalidation and reset its profile; Limit number of recompilations within a time period

[JohnTortugo]

Closes: #11045

Please review this patch that modifies Truffle to:

1. Reset a CallTarget's profile when the nmethod associated with it was invalidated by HotSpot because the Code Cache's method flushing heuristics deemed the nmethod to be cold.

2. 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.

[JohnTortugo]

Can someone please take a look? /cc @chumer @dougxc ?

[dougxc]

Looks reasonable to me but a more detailed review should be done by @tzezula or @chumer.

[JohnTortugo]

@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 successfullRecompilationCount when the method was invalidated because it was cold.
• I reverted the changes in HotspotOptimizedCallTarget to 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.