Add support to disable JITServer and AOT post restore

[dsouzai]

Since JITServer is enabled implicitly in Non Portable Mode, specifying -XX:-UseJITServer should disable it post-restore.

Additionally, if -Xshareclasses:disableOnRestore is specified, disable AOT (see #16868).

[dsouzai]

@mpirvu could you please review?

[dsouzai]

Converting to draft so I can also add the change to support disabling the SCC post restore in this PR (to minimize the amount of double delivering needed before Friday).

[dsouzai]

At the moment, running with -Xshareclasses:disableOnRestore will fail on restore (unless I change this to FIND_AND_CONSUME_RESTORE_ARG). I'm expecting the VM to use the FIND_AND_CONSUME variant when they process this option.

fyi @hangshao0

[dsouzai]

@mpirvu ready for review now.

[mpirvu]

LGTM
I wonder if we should reverse the logic for JITServer: run in client mode before checkpoint (as we do now), but by default disable client-mode post restore, unless the user specifies -XX:+UseJITServer in which case we let the JVM in client mode.
This would be more in line with current behavior where the user has to opt-in to use JITServer.

[mpirvu]

jenkins test sanity all jdk17

[dsouzai]

I wonder if we should reverse the logic for JITServer: run in client mode before checkpoint (as we do now), but by default disable client-mode post restore, unless the user specifies -XX:+UseJITServer in which case we let the JVM in client mode.
This would be more in line with current behavior where the user has to opt-in to use JITServer.

It's something we can look into for post 0.38; I have a task in #16853 under the JITServer section to support -XX:+UseJITServer post restore in Portable mode which maybe could make use of this same idea.

That said, I believe having JITServer enabled implicitly in Non-Portable mode was a deliberate decision, though it was made before we had the ability to specify options post-restore, so it could be something to revisit. @vijaysun-omr @ymanton what are your thoughts on Marius' suggestion (since you guys made the decision to implicitly enable JITServer).

[vijaysun-omr]

Yes I think the prior decision was driven by a desire to perhaps attempt a demo with both JIT server and CRIU support, but in a world where we were unable to specify new JVM command line options on the restore side. Now that that has changed, I agree that we could consider a different design.