RFR: 8339576: Speed up raw bytecode processing in ClassFile API

Shaojin Wen swen at openjdk.org
Thu Sep 5 06:28:49 UTC 2024


On Wed, 4 Sep 2024 22:41:38 GMT, Chen Liang <liach at 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


More information about the core-libs-dev mailing list