RFR: 8008243: Zero: Implement fast bytecodes [v2]

Aleksey Shipilev shade at openjdk.java.net
Tue Oct 19 15:57:53 UTC 2021

On Tue, 19 Oct 2021 13:23:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
>>  - Remove shadowing "obj" to fix JVMTI tests
>>  - Comment _fast_zputfield LSB
>>  - MAYBE_POST_FIELD_MODIFICATION should check _putstatic
> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 394:
>> 392:         }
>> 393: 
>> 394: #define MAYBE_POST_FIELD_ACCESS(obj) {                              \
> I wonder if making these functions would reduce the size of the code in the big case statement and improve the compiler's ability to optimize it?

I actually look through the machine code for that file very often (as `perf record` / `perf report` for understanding where the bottlenecks are), and there seem to be little to gain w.r.t. code quality. I suspect out-of-line service functions would improve code density, but I also suspect the `BytecodeInterpreter::run` is so large, most non-trivial inlining fails. I'd need to do a much larger investigation if we can re-massage the code to maybe optimize it.

Meanwhile, I would like to keep these defines, as they fit the current style of helper "methods".

> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 2719:
>> 2717: 
>> 2718:         int field_offset = cache->f2_as_index();
>> 2719:         obj->byte_field_put(field_offset, (STACK_INT(-1) & 1)); // only store LSB
> Good!

LSB part? Yes, one of those things that we need to remember adjusting :)


PR: https://git.openjdk.java.net/jdk/pull/1938

More information about the hotspot-runtime-dev mailing list