Checklist of features for new JIT backends

[0xdaryl]

I'm compiling a list of features that a new OpenJ9 JIT backend would need to implement to be reasonably "feature complete" with the others. These features are typically performance features above and beyond a basic, functional OpenJ9 JIT.

This could also serve a secondary purpose as a cross checklist for existing platforms to determine if they are missing any opportunities.

At the moment, I am particularly interested in the work that has been done to support features in Java 9, 11, 12, ... to be sure we don't miss any of that work in the AArch64 implementation.

This is a bit of a brain dump, but I hope to provide some structure to it once everyone has provided their input. I would appreciate it if those that are familiar with a particular backend could review this list and add anything you think is relevant. You don't necessarily have to go into great detail here: it will either be enough for me to track down the feature myself, or I can ask you about it.

FYI @andrewcraik @fjeremic @gita-omr, but input from anyone is welcome.

• software concurrent scavenge

• constant dynamic

• nestmates

• read barriers

• write barriers

• field watch

  • support AOT + fieldwatch (e.g., Implement AOT support with Field Watch on Power #6256)

• JNI dispatch

• lock reservation

• recompilation

• on-stack replacement? (@andrewcraik)

• AOT / SVM? (@dsouzai)

• per code-cache helpers

• JSR292?

• DLT?

  • no specific support seems needed, but DLT symbols are excluded in some situations

• JProfiling?

• J9-specific IL opcodes, including:

  • ArrayStoreCHK
  • ArrayCHK
  • SpineCHKs and variants, arraylets in general
  • loadFence, storeFence, fullFence

• Platform-specific inlining

  • unsafe natives
  • juc methods
  • optimized String hashcode
  • String.indexof
  • String case conversions (UTF16 & Latin1)
  • String compression
  • currentTimeMillis/nanoTime inlining

• inlined helpers

  • monitor enter/exit
  • checkcast
  • instanceof
  • new/newarray/anewarray

• implicit NULLCHK (via signal handler)

• implicit DIVCHK (via signal handler)

• transactional memory (tstart/tfinish/tabort/tcommit)

• what is "asyncCheckGCMapPatching" @0dvictor ?

[DanHeidinga]

nestmates

This should be handled by the VM's resolve helpers. I'm not aware of any JIT surface to this feature.

VarHandles

New in Java 9, similar to JSR 292's MethodHandles but for field access under different modes.

JNI Dispatch

In additional to DirectToJNI, there's also the recentish work on atomic free vmaccess.

[andrewcraik]

VarHandles are just like MethodHandles by the time you get to codegen. Nestmates are only seen as part of the resolve paths and not really for perf.

[andrewcraik]

No special support needed for JProfiling - it is all done in trees.

[andrewcraik]

Constant dynamic is transparent in codegen

[dsouzai]

AOT / SVM?

Validation (SVM): common code

Codegen: This is where the majority of the work would need to be done. The addMetaDataForCode* method of the various instructions would handle adding the external relocations necessary. However, those are't the only locations; the various snippets are going to have to make sure they add the necessarily external relocations. I'm sure there are lots of other places as well, which could be gleaned by looking at the other existing codegens. The codegen would also need to know when to generate different instructions under AOT (for example, if an address isn't guaranteed to fit in 32 bits, even though it happens to do so during compilation). At the moment there would be the need for yet another J9AheadOfCompile.cpp file; however, once the consolidation work is done (#4803) that won't be necessary.

Relocation: TR_RelocationTarget would need to be extended to handle circumstances like POWER, where there are different ways a pointer can be patched (ie different ways to patch a 5 instruction sequence).

Any other considerations @mstoodle ?

EDIT

For other SVM changes, also see #15121 (comment)

[0xdaryl]

Complete atomicCompareAndSwapReturn support on Z, Power, and AArch64: eclipse-omr/omr#3759

[0xdaryl]

Field watch: AArch64 (#8038), AArch32 (#8040)

[0xdaryl]

DLT for AArch64. #5917 tracks the work to enable. Disabled in AArch64 by #5919.

[0xdaryl]

OSR for AArch64 #5921

[0xdaryl]

Lock reservation: AArch64 (#12097)
Lock reservation optimization: #2344

[0xdaryl]

CompactLocals (ability to map compacted stack in some linkage) : #5910

[0xdaryl]

JITaaS relocations

[0xdaryl]

Quad recognized methods (hopefully not required for long!)

[0xdaryl]

Interface PICs (e.g., #6325)

[0xdaryl]

Hardware transactional memory support. Enable CodeGenerator getSupportsTM(). Implement evaluators for tstart, tfinish, tabort.

[fjeremic]

LoadExtensions codegen optimization [1].

[1] https://github.com/eclipse/omr/blob/ff2e532dbbb27fa4fef597c1977cb7b62093e72b/compiler/optimizer/LoadExtensions.hpp#L37-L103

[jdmpapin]

I'd like to clarify a few points about nestmates here.

nestmates

This should be handled by the VM's resolve helpers. I'm not aware of any JIT surface to this feature.

The JIT interaction is that with nestmates, invokevirtual and invokeinterface no longer necessarily do virtual and interface dispatch (respectively). They might instead call a private method directly, and because private methods are not in the vtable, direct dispatch is the only possible implementation. The JIT compiler recognizes this situation in the resolved case during both IL generation and inlining so that it can treat it as a direct call as required. In the unresolved case, the resolution path has to detect this situation at runtime.

Nestmates are only seen as part of the resolve paths and not really for perf.

This is true, but I want to emphasize that code generator support is required for nestmates to work correctly. The runtime resolution path must be capable of carrying out a direct dispatch when indicated by the VM. The current design for doing so requires a pointer to the "virtual" J2I thunk in the PIC data, which needs a relocation for AOT. In the case of invokeinterface, we also need to do a type check.

(It was technically possible for invokeinterface to require direct dispatch before nestmates for final methods of Object, which are also not kept in the vtable. However, calling those through invokeinterface is unusual bytecode, and the JIT compiler would simply refuse to compile methods containing such calls. Only with nestmates did it become important to conditionally do direct dispatch based on the result of resolution at runtime.)

[0xdaryl]

Internal pointers. AArch64 (#6367), ARM (#6368)

[0xdaryl]

Arraycopy transformations from value propagation (TR::arraycopy and TR::ArrayCHK node support). Disabled via TR_DisableArrayCopyOpts.

AArch64 (#12122)

[0xdaryl]

Inline dynamic cast class evaluation for checkcast : #5291

[0xdaryl]

Inlining support of MultiANewArray for 2 dimensional arrays: x86 (#2408), P (#2424), Z (#11088), AArch64 (#12367).

[0xdaryl]

CodeGenerator SupportsProfiledInlining. Currently enabled for X,P,Z. AArch64 (#6451) and ARM32 (#6452).

[0xdaryl]

CodeGenerator SupportsAutoSIMD. Currently enabled on X,P,Z. AArch64 (#6453) and ARM32 (#6454).

[gita-omr]

Please note that autoSIMD is supported only to the degree vector opcodes implemented in a particular codegen. Optimizer attempts to vectorize a loop and then asks codegen if particular opcode has vector version (there is a codegen method for that, takes opcode as a parameter). I am pretty sure only x,z,p have some number of opcodes that are supported.

[0xdaryl]

Exception Directed Optimization (EDO)

• AArch64 (Enable EDO for AArch64 #6538 )
• ARM32 (Enable EDO for ARM #6540)

[0xdaryl]

CodeGenerator support for GlRegDeps:

setSupportsGlRegDeps();
setSupportsGlRegDepOnFirstBlock();

And by extension, global register allocation.

For AArch64 (#6606).

[0xdaryl]

Method recompilation

• AArch64 (Enable recompilation for AArch64 #6607)

[0xdaryl]

Support atomic free JNI. #2576, AArch64 (#6608), ARM32 (#6609)

By extension, enable directToJNI in the JIT.

[0xdaryl]

A code generator must set setSupportsDivCheck() if it provides an implementation for the DIVCHK IL Opcode. This is needed before Walker will create trees for integer type division and remainder operations. Otherwise, the compilation will fail with an unimplemented opcode for any division or remainder operations.

[0xdaryl]

Enable prefetchInsertion optimization. Requires backend support for prefetch instructions. AArch64 eclipse-omr/omr#4494, ARM32 eclipse-omr/omr#4495

[0xdaryl]

Enable support for compressed references.

• AArch64 (Enable compressed references with AArch64 JIT #8026)

[0xdaryl]

Implement lock reservation. AArch64 (#8032), AArch32 (#8033)

[0xdaryl]

Implement support for balanced GC: AArch64 (#8034), AArch32 (#8035)

[0xdaryl]

Implicit NULLCHKs: AArch64 (#8036)

[0xdaryl]

Implicit DIVCHKs: AArch64 (#8037)

[0xdaryl]

Support ternary (soon-to-be-renamed-to select) opcodes. eclipse-omr/omr#4682

[0xdaryl]

Exploit cached lastITable in JIT interface dispatch (#8390) : AArch64 (#8400), Z (#8399), ARM (#8401)

[0xdaryl]

Live registers: eclipse-omr/omr#4843

[0xdaryl]

Support for value types: #9105

[0xdaryl]

Support for inlined monitor cache for monent/monexit: #9240

[0xdaryl]

Guarded devirtualization: AArch64 (#9334), AArch32 (#9335), common solution (#9333)

[0xdaryl]

ASSOCREG pseudo-instruction: AArch64 (#9350)

[0xdaryl]

Patchable GCR guards: Epic: #9730

[0xdaryl]

Support newInstanceImpl optimization: AArch64 (#11790)

[0xdaryl]

Support mixed references: AArch64 (#11977), general issue (#8847)

[0xdaryl]

Allocation TLH prefetching (via CodeGen enableTLHPrefetching): AArch64 (#12068)

[0xdaryl]

JIT Server support: AArch64 (#12121)

[0xdaryl]

Implement supportsPassThroughCopyToNewVirtualRegister to enable RegDepCopyRemoval optimization. AArch64 (#12188)

[0xdaryl]

Enable CodeGenerator supportsInliningOfIsInstance: AArch64 (#12518)

[0xdaryl]

Enable CodeGenerator supportsByteswap capability when evaluators are available for that opcode. This is really something that needs to happen in OMR, but is being tracked here for convenience. AArch64 (eclipse-omr/omr#5971)

[0xdaryl]

Ensure CodeGenerator getSupportsAlignedAccessOnly() returns the correct answer for the target processor. SequentialStoreSimplifier may do the wrong thing otherwise.

[fjeremic]

Ensure CodeGenerator getSupportsAlignedAccessOnly() returns the correct answer for the target processor. SequentialStoreSimplifier may do the wrong thing otherwise.

Does this mean if a CodeGenerator doesn't do anything w.r.t. this API we may have functional bugs?

[0xdaryl]

Does this mean if a CodeGenerator doesn't do anything w.r.t. this API we may have functional bugs?

Yes. Mis-aligned data accesses were being generated on AArch64, and there was no means of encoding instructions to access that data.

I believe this API defaults to "false", so if a processor can (for example) access 4-bytes on a mis-aligned boundary then it should be fine. We have a PR coming on AArch64 that sets this flag to fix its problem.

[fjeremic]

Yes. Mis-aligned data accesses were being generated on AArch64, and there was no means of encoding instructions to access that data.

Should we be making such APIs pure virtual functions to force concrete CodeGenerators to implement them correctly and not rely on a default value?

[0xdaryl]

Support bit IL opcodes: ihbit, ilbit, inolz, inotz, ipopcnt, lhbit, llbit, lnolz, lnotz, lpopcnt

Make Java API methods (e.g., LowestOneBit) intrinsics that map to them.

[0xdaryl]

Profile guarded devirtualization: Z (#13606)

[0xdaryl]

Implement supportsDirectJNICallsForAOT(). Prior to enabling, ensure the direct JNI sequence has proper relocations added.

[0xdaryl]

Counting recompilation: AArch64 (#17543)