On Mon, 4 May 2026 12:15:53 GMT, Johan Sjölen <[email protected]> wrote:
> Hi,
>
> The `zero` interpreter has fast paths for basic getters and setters, but
> these fail to take into account how flattened fields work. This causes
> flattened fields to be copied onto the stack directly, instead of wrapped in
> an oop (for getters), and flattened fields to be transformed into oops (for
> setters). Instead of adapting the fast paths, we bail to the slow path.
>
> To convince you, this is `getter_entry`:
>
> ```c++
> switch (entry->tos_state()) {
> // SNIP!
> case atos: SET_STACK_OBJECT(object->obj_field(offset), 0); break;
>
>
> and this is the basic bytecode dispatch (slow path):
>
> ```c++
> switch (tos_type) {
> // SNIP!
> case atos:
> oop val;
> if (entry->is_flat()) {
> CALL_VM(InterpreterRuntime::read_flat_field(THREAD, obj,
> entry), handle_exception);
> val = THREAD->vm_result_oop();
> THREAD->set_vm_result_oop(nullptr);
> } else {
> val = obj->obj_field(field_offset);
> }
>
>
>
> I added a test in order to coax the getter/setter pattern optimization to run
> consistently and re-ran the previously disabled test along with the new one
> on linux-x64-zero, and they both pass. Running the new test with lworld -Xint
> linux-x64-zero crashes similarly to the reported bug.
>
> ## Everything below this header is bonus info for the curious
>
> We fail within `init` of `TestSuite` which has a flattened field:
>
>
> - private value 'skipFailedInvocationCounts' 'Ljava/lang/Boolean;' @12 Flat
> inline type field 'java/lang/Boolean':
> - private final value 'value' 'Z' @12 false (0x00)
> - [null_marker] @13 Field marked as non-null
> ```
>
> and in `SuiteRunner.java:183` we can see this:
>
>
> skipFailedInvocationCounts = suite.skipFailedInvocationCounts(); //
> (suite has type XmlSuite)
>
>
> and `XmlSuite` has the following getter
>
>
> public Boolean skipFailedInvocationCounts() {
> return m_skipFailedInvocationCounts;
> }
>
>
> This is probably triggering the buggy zero code.
>
> Just some more discovery stuff:
>
> Let's look at `si_addr` which is `0x0000000001000108`. Alright, we're running
> with compressed klass pointers but without `UseCompactObjectHeaders`, so when
> doing the `write_flat_field` we finally reach `return
> CompressedKlassPointers::decode_not_null(_compressed_klass);` and
> `_compressed_klass` has offset 8. So, the actual "oop" is at `0x1000100`. OK,
> I dunno, that could be a flattened Boolean I guess?
>
> ---------
> - [X] I confirm that I make this contribution i...
This makes sense.
-------------
Marked as reviewed by coleenp (Committer).
PR Review:
https://git.openjdk.org/valhalla/pull/2382#pullrequestreview-4238901915
