JITServer AOT caching failing

[cjjdespres]

Attn @mpirvu, @AlexeyKhrabrov. While testing #15949 with acmeair, I noticed a lot of messages in the log like:

#JITServer: clientUID 293357720754206506 failed to get defining class chain record for 0000000000050300 due to the AOT cache size limit; method 000000000004F7E0 won't be loaded from or stored in AOT cache

without any "AOT cache allocations exceeded maximum..." message earlier in the log. That means that at some point loading the class chain record fails for some reason unrelated to the cache limit, but the missingLoaderInfo flag is not updated properly.

[cjjdespres]

I think this issue might be interfering with AOT caching in my testing of #15949; after applying an acmeair load I get these statistics for the cache:

JITServer AOT cache  statistics:
        stored methods: 0
        class loader records: 52
        class records: 1725
        method records: 0
        class chain records: 0
        well-known classes records: 0
        AOT header records: 1
        cache bypasses: 807
        cache hits: 0
        cache misses: 7111
        deserialized methods: 0
        deserialization failures: 0

and that seems implausible to me.

[AlexeyKhrabrov]

Yeah this looks pretty bad, class chain record creation is broken. What exact version of the code are there results for?

[cjjdespres]

I tested it with the version of master that the persistence PR is based on, which is commit 628e9db.

[AlexeyKhrabrov]

I think the bug is here:

openj9/runtime/compiler/runtime/JITClientSession.cpp

Lines 972 to 988 in e8abb75

	bool missingLoaderRecord = false;
	bool uncachedClass = false;
	classRecords[i] = getClassRecord(ramClassChain[i], missingLoaderRecord, uncachedClass);
	if (missingLoaderRecord)
	{
	missingLoaderRecordIndexes[numMissingLoaderRecords++] = i;
	}
	else if (uncachedClass)
	{
	uncachedIndexes[uncachedRAMClasses.size()] = i;
	uncachedRAMClasses.push_back(ramClassChain[i]);
	}
	else
	{
	// There must have been an allocation failure.
	return NULL;
	}

If the getClassRecord() succeeds and classRecords[i] is non-null, it returns null as if this was an allocation failure. Somehow we missed this in code review for the cache size limit PR. That's why we need tests for the AOT cache (#15401).