Add options to bypass JITServer AOT cache per method

[AlexeyKhrabrov]

As a debugging/diagnostic feature, we should to have a way of bypassing the JITServer AOT cache on a per method basis, similar to excluding methods from JIT or AOT compilation/load. This can be useful, e.g., to determine whether a problem with a given method is caused by an AOT compiler issue or an AOT cache method serialization/deserialization issue. For completeness, there should be two separate options to forbid storing and loading a method to/from the JITServer AOT cache, e.g. -Xaot:{method}(jitserverAOTCacheNoStore) and -Xaot:{method}(jitserverAOTCacheNoLoad). These options should be specified on the client side.

[mpirvu]

FYI @cjjdespres This would be useful to implement for diagnosing #16232

[cjjdespres]

Should these method names be sent to the server and stored in the client data so that it can decide what should or should not be stored/loaded, or would it be easier for the client to send those details along in its compilation request? I only see an aotCacheLoad bool transmitted in the request, so I suppose an aotCacheStore would need to be added as well.

The exclusion would happen, say, using the name in the method details of the entry being compiled in remoteCompile. We'd need to keep around a set of excluded methods for this purpose.

Should there be a limit-type option for methods as well, so that only particular methods will be loaded or stored?

Is the {method}(option) form a recognized option form for -Xaot, or should it be something like -Xaot:jitserverAOTCacheNoLoad={method}?

[AlexeyKhrabrov]

Should these method names be sent to the server and stored in the client data so that it can decide what should or should not be stored/loaded, or would it be easier for the client to send those details along in its compilation request?

The latter.

I only see an aotCacheLoad bool transmitted in the request, so I suppose an aotCacheStore would need to be added as well.

Look at the code in remoteCompile() and TR::CompilationInfoPerThreadRemote::processEntry(), there is already a way to communicate "do not store" to the server (setting the classChain field in the compilation request to NULL IIRC).

[cjjdespres]

At the moment the two relevant variables are set with

      _aotCacheStore = classChain && aotCache && JITServerAOTCacheMap::cacheHasSpace();
      aotCacheLoad = aotCacheLoad && classChain && aotCache;

I suppose it doesn't make too much sense to forbid storing and not forbid loading.

[AlexeyKhrabrov]

I suppose it doesn't make too much sense to forbid storing and not forbid loading.

Good point. I agree that allowing loads but not stores for a specific method is probably not too useful because a store cannot happen after a successful load anyway. I'm fine if NoStore implies NoLoad. We can also reflect that in the option name (e.g. NoStoreLoad).

[cjjdespres]

Would it be worth it to repurpose the existing regex/search tree infrastructure from the exclude= and limit= family of options, or is a simple list of method names most of what we need? For #16232 a list would suffice, at least.

[mpirvu]

It may be more flexible to use our existing infrastructure.
LimitFile.cpp contains relevant code.
There might be some dup work with this requirement: #16364

[cjjdespres]

It looks like the existing filters use

   TR::CompilationFilters    * _compilationFilters;
   TR::CompilationFilters    * _relocationFilters;
   TR::CompilationFilters    * _inlineFilters;

in TR_Debug. The filter itself is added by the appropriate addFilter call in LimitFile. We could add new fields for the new restrictions we want to add, populate them with a TR::Option option processor, then query them when constructing the compilation request at the client.

[AlexeyKhrabrov]

I think this was closed unintentionally (by eclipse/omr#6842).