When an object has inflated a monitor, the locking system stores the address of the monitor in the markWord and displaces the hash code and other flags.  With Lilliput, the klass pointer is also kept in the markWord, so the displacement makes it error prone to access the class.  Now [~eosterlund] words:

The Concurrent Hash Table idea for object → objectMonitor mapping would solve the Klass accessing problem

Yes. There are two problems, relating to interactions between GC, concurrent deflation, and Liliput. To understand it, let’s remind ourselves the basic idea of concurrent deflation:

1) Reach linearization point that the OM is deflating
2) Unlink the OM from the markWord
3) Rendezvous all threads using the OM
4) Delete the OM

== Problem One ==
The first problem is that step 3) so far is implemented with a thread-local handshake with all JavaThreads, because surely only JavaThreads use the OM right?!
Well suddenly anyone reading the klass(), size() or doing oop_iterate() also uses the OM because with Liliput, the klass pointer doesn’t fit into the object when the monitor is inflated. So any concurrent GC needs to hook in to the rendezvous operation somehow.
That’s doable for generational ZGC because it uses the STS mechanism when processing objects. But it is not possible in original ZGC without major rewrites.

== Problem Two ==
I believe there is also at least a second problem impacting original ZGC and generational ZGC, and probably Shenandoah.
The unlinking in step 2) only applies to the to-space object. The OM looks up the object through a WeakHandle, which gives you the to-space object. There will however still be a link to the OM left behind in the from-space object, which isn’t visible to the application.
The OM link of the from-space object is visible from the GC, and it will crash when it tries to for example read the size() of the from-space object. In fact Roman has a crash with generational ZGC during relocation, and I think this is why.