Implement patchable GCR guards on all architectures

[0xdaryl]

Patchable GCR guards are only implemented on x86, and are believed to realize a non-negligible performance improvement when enabled.

The performance impact should be measured, and they should be implemented on

• Power
• Z
• AArch64
• ARM

if they are beneficial.

[fjeremic]

Could we get a description of what patchable Guarded Counting Recompilations are and what types of workload they benefit?

[0xdaryl]

Seems like a reasonable request. @mpirvu , would you mind providing a short summary of the purpose and benefit of GCR?

I will summarize the info you provided in our Slack discussion on when this is enabled:

GCR trees are inserted in the following circumstances:

• Cold compilations
• AOT compilations
• JIT warm compilations that happen during startup. We cut a few expensive optimizations to improve startup time, but insert GCR trees to upgrade these bodies to full-warm optimizations

A tweak we do is to avoid inserting GCR trees in very small methods without loops. The thinking is that for simpler methods the optimizer at "warm" opt level cannot do much more than the optimizer at "cold" opt level.

[Akira1Saitoh]

According to the slides I received from @mpirvu, the patchable GCRs patch the compare instruction for the guard to avoid branching to the GCR snippet after a recompilation decision is taken. They solve the performance problem caused by the branch misprediction which occurs until the recompilation finishes. The GCRs use a count-for-recompile control variable which has either 0 or 1. When it is 1, the branch to the GCR snippet is taken. The patching changes the immediate field of the compare instruction from 1 to 2, so that the comparison is never successful after the recompilation is triggered.
Unlike other types of patching, the GCR patching is done by the instruction generated from GCR trees. If the patchable GCRs are enabled, a bstore node with GCRPatchPoint symbol ref is inserted in the trees and the instruction generated for this bstore node patches the immediate field of the compare instruction.

openj9/runtime/compiler/ilgen/IlGenerator.cpp

Lines 1235 to 1242 in 4b21d82

	// Create the instruction that will patch my cmp
	if (comp()->getOption(TR_EnableGCRPatching))
	{
	TR::Node *constNode = TR::Node::create(node, TR::bconst, 0);
	constNode->setByte(2);
	callRecompileBlock->append(TR::TreeTop::create(comp(), TR::Node::createWithSymRef(TR::bstore, 1, 1, constNode,
	comp()->getSymRefTab()->findOrCreateGCRPatchPointSymbolRef())));
	}

I find the following 2 concerns about this way of patching on aarch64:

• We need to flush icache after patching the instruction.
• The immediate field of cmp instruction on aarch64 is not at byte boundaries. It spans from bit 10 to bit 21, so the bstore would overwrite other fields of the instruction.

I spoke @knn-k and @0xdaryl about this and @0xdaryl suggested that we should call out to a helper for patching the instruction at least on aarch64.