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.
## 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 in accordance with the [OpenJDK
Interim AI Policy](https://openjdk.org/legal/ai).
-------------
Commit messages:
- [lworld] Fix zero accessor
Changes: https://git.openjdk.org/valhalla/pull/2382/files
Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2382&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8380059
Stats: 123 lines in 3 files changed: 120 ins; 2 del; 1 mod
Patch: https://git.openjdk.org/valhalla/pull/2382.diff
Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2382/head:pull/2382
PR: https://git.openjdk.org/valhalla/pull/2382
