Marius Pirvu

I'll have a look as the failure looks related to my changes.

I talked to Irwin and he doesn't see how the pointer we get from `rememberClass()` can be outside the SCC bounds. I speculated that this may somehow happen in CRIU...

Tried to reproduce this problem here: https://openj9-jenkins.osuosl.org/job/Grinder/1240/ but tests passed

50 runs of the problematic test passed (https://openj9-jenkins.osuosl.org/job/Grinder/1243/). Irwin also pointed out that the address flagged by the assert is actually within SCC bounds, so at this point we cannot...

This existing method is very handy at covering both cases specified above (count=0 and disableAsyncCompilation) ``` bool TR::CompilationInfo::asynchronousCompilation() { static bool answer = (!TR::Options::getJITCmdLineOptions()->getOption(TR_DisableAsyncCompilation) && TR::Options::getJITCmdLineOptions()->getInitialBCount() && TR::Options::getJITCmdLineOptions()->getInitialCount() && TR::Options::getAOTCmdLineOptions()->getInitialSCount()...

Currently, we set localSyncCompiles in preProcess() which may be too early for the other options to have been parsed. We need to move this code in fePostProcess() when we know...

@cjjdespres Could you please implement this feature? Thanks.

LatePostProcess comes after PostProcess

From some tracing I did a long time ago: ``` This is the order seen in tr.open (Java9) processOptionsAOT creates _aotCmdLineOptions=0000000002CC38D0 fePreProcess this=0000000002CC38D0 jitPreProcess this=0000000002CC38D0 processOptions for 0000000002CC38D0 jitPostProcess this=0000000002CC38D0...

Great!