On Wed, 4 Sep 2024 22:41:38 GMT, Chen Liang <li...@openjdk.org> wrote:
> Currently, raw bytecode access goes through multiple wrappers, include one
> from ClassFile API and another ByteBuffer for merged big endian value reads.
> We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper)
> for safer access.
>
> RawBytecodeHelper is also restructured so we avoid allocating it on the heap.
> Large `rawNext` method is now also inlined into the smaller `next` method.
>
> Current benchmark results show this significantly speeds up
> `jdk.classfile.Write` and some degree of speedup for simple lambda startup.
> The impact on general application workloads is minuscule, but this doesn't
> seem to bring any regression.
>
> Pinging @wenshao and @cl4es for review.
src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java
line 235:
> 233: * we have a valid opcode.
> 234: */
> 235: public boolean next() {
In C1, this cannot be inlined. See if you need to add ForceInline
src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java
line 242:
> 240: bci = nextBci;
> 241: int code = getU1Unchecked(bci);
> 242: int len = LENGTHS[code];
Adding `& 0xFF` here can eliminate array out-of-bounds detection
int len = LENGTHS[code & 0xFF];
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1744871326
PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1744872686
