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