Openj9: Purpose of the TR::monexitfence opcode?

[0xdaryl]

What is the purpose of the JIT's TR::monexitfence IL opcode? I believe it is related to the live monitor metadata support. Is it just a placeholder for use by the optimizer? All of the backends simply return NULL when evaluating it.

Can someone shed some light on what this is for please? @andrewcraik @cathyzhyi

(I'm not trying to get rid of it, just trying to understand :-) )

[andrewcraik]

Yes so the idea of a monexitfence is that we need to keep track of which objects a program has locked over a given range from a semantic perspective. This is required because there is a ThreadMXBean API and a non-debug JVMTI API where the user can query for the set of monitors held by a given thread. The JIT is required to preserve the mutual exclusion intent of the programmer when optimizing the program, but can change actual lock operations - for example if you lock and unlock then lock and unlock the same lock close together in the code (eg separated by a few trivial instructions) we can boost performance by increasing the size of the critical section and merging the two mutual exclusion regions. When the JIT performs such an optimization we still have to be able to report the lock state the user intended and the monexitfence is used to record where a lock would have been released. So taking the lock coarsening example above when we eliminate the monexit we would leave its monexitfence in place to know that the referenced slot is unlocked. You can see the basics of this in the Walker.cpp when you look how we represent the monitorenter and monitorexit operations with Live Monitor Metadata is enabled.

When we gen a moment with live monitor metadata tracking we generate a store to a temp to hold the locked object and we mark the temp as holding a monitored object. The reassociation of entries to exits is done in the codegen and is based on nested entry/exit. It is possible for entry/exit to not be properly nested and that then results in some conservative backoffs in the JIT code to produce the monitor metadata which is a weakness of the current design and something to improve going forward.

@cathyzhyi please correct anything I got wrong - this is my recollection of how this whole thing is put together.

[fjeremic]

Excellent explanation. I feel like this should be documented whenever we get to the IL documentation step as it is certainly non-obvious.

[0xdaryl]

Thanks for the detailed answer @andrewcraik. It is helpful. I will make sure this is captured either in the code or in the IL specification.