You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
assert !updateStatesForMaterialized(state, virtual, state.getObjectState(object).getMaterializedValue()) : "method must already have been called before";
576
575
returntrue;
@@ -593,7 +592,7 @@ private boolean ensureMaterialized(PartialEscapeBlockState<?> state, int object,
593
592
* }
594
593
* }
595
594
* </pre>
596
-
*
595
+
* <p>
597
596
* PEA may emit:
598
597
*
599
598
* <pre>
@@ -605,14 +604,14 @@ private boolean ensureMaterialized(PartialEscapeBlockState<?> state, int object,
605
604
* monitorexit otherObj
606
605
* monitorexit obj
607
606
* </pre>
608
-
*
607
+
* <p>
609
608
* On HotSpot, unstructured locking is acceptable for stack locking (LM_LEGACY) and heavy
610
609
* monitor (LM_MONITOR). This is because locks under these locking modes are referenced by
611
610
* pointers stored in the object mark word, and are not necessary contiguous in memory. There is
612
611
* no way to observe a lock disorder from outside, as long as PEA guarantee that a virtual lock
613
612
* is materialized and held before it escapes or before the runtime deoptimizes and transfers to
614
613
* interpreter.
615
-
*
614
+
* <p>
616
615
* Lightweight locking (LM_LIGHTWEIGHT), however, maintains locks in a thread-local lock stack.
617
616
* The more inner lock occupies the closer slot to the lock stack top. Unstructured locking code
618
617
* will disrupt the lock stack and result in an inconsistent state. For instance, the lock stack
@@ -625,56 +624,37 @@ private boolean ensureMaterialized(PartialEscapeBlockState<?> state, int object,
625
624
* | otherObj |
626
625
* ------------
627
626
* </pre>
628
-
*
627
+
* <p>
629
628
* and is
630
629
*
631
630
* <pre>
632
631
* ------------
633
632
* | otherObj | <-- stack top
634
633
* ------------
635
634
* </pre>
636
-
*
635
+
* <p>
637
636
* after the first {code monitorexit} instruction. At this point, the still-locked object
638
637
* {@code obj} is not maintained in the lock stack, while the lock stack top points to
639
638
* {@code otherObj}, which is with an unlocked mark word. Such inconsistent state can be
640
639
* observed from outside by scanning a thread's lock stack.
641
-
*
640
+
* <p>
642
641
* To avoid such scenario, we disallow PEA to emit unstructured locking code when using
643
642
* lightweight locking. We materialize all virtual objects that potentially get materialized in
644
643
* subsequent control flow point and hold locks with lock depth smaller than {@code lockDepth}.
645
-
* For those will not get materialized (see {@link #mayBeMaterialized}), we keep them virtual
646
-
* and effectively apply lock elimination. The runtime deoptimization code will take care of
647
-
* rematerialization of these virtual locks (see JDK-8318895).
0 commit comments