[External] : Re: Class files in ByteBuffer

[Adam Sotona]

I’m more thinking that the API already provides all the important entries and conversion from and to `MemorySegment` can be done by simple call of `MemorySegment::toArray` and `MemorySegment::ofArray`.

From: David Lloyd <david.lloyd at redhat.com>
Date: Friday, 21 March 2025 at 13:37
To: Adam Sotona <adam.sotona at oracle.com>
Cc: classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
Subject: [External] : Re: Class files in ByteBuffer
Please have a look at the PR. If you feel the API surface has grown too much, maybe removing the `ByteBuffer` variants is a logical step, since users can always wrap a `ByteBuffer` with a `MemorySegment`? If you could comment on the PR if you feel that to be the case, I would appreciate it.

Thanks.

On Thu, Mar 20, 2025 at 4:09 PM Adam Sotona <adam.sotona at oracle.com<mailto:adam.sotona at oracle.com>> wrote:
I’m sorry to join the discussion a bit late.

Here are the points to consider:

  *   Class-File API is implementation is after many rounds of performance optimizations purely based on byte arrays.
  *   Internal use of ByteBuffer has been removed from the implementation, as it caused significant JDK bootstrap performance regression.
  *   Enormous amount of work has been spent on the API surface reduction and removal of all unnecessary “conveniences”.

Adam



From: classfile-api-dev <classfile-api-dev-retn at openjdk.org<mailto:classfile-api-dev-retn at openjdk.org>> on behalf of David Lloyd <david.lloyd at redhat.com<mailto:david.lloyd at redhat.com>>
Date: Thursday, 20 March 2025 at 21:11
To: classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org> <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Subject: Re: Class files in ByteBuffer
I've opened a bug [1] and pull request [2] incorporating this discussion (more or less). I've implemented support for both `MemorySegment` and `ByteBuffer`, but this could be revisited if it doesn't look OK. The implementation is not terribly invasive for now, only grabbing a few low-hanging optimizations.

[1] https://bugs.openjdk.org/browse/JDK-8352536
[2] https://github.com/openjdk/jdk/pull/24139<https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/24139__;!!ACWV5N9M2RV99hQ!MNdgtt56CgKWQQak5PkwC2t1L1q0tTZrT2fqzVPHYo3jer5CUfysIIx9uMuCoLb27YGoQWuUDgu3s_h8ZhlN-w$>

On Mon, Mar 10, 2025 at 12:38 PM David Lloyd <david.lloyd at redhat.com<mailto:david.lloyd at redhat.com>> wrote:
When defining a class in the JDK, one may either use a byte array or a byte buffer to hold the contents of the class. The latter is useful when (for example) a JAR file containing uncompressed classes is mapped into memory. Thus, some class loaders depend on this form of the API for class definition.

If I were to supplement such a class loader with a class transformation step based on the class file API, I would have to copy the bytes of each class on to the heap as a byte[] before I could begin parsing it. This is potentially expensive, and definitely awkward.

After transformation, it doesn't really matter if you have a byte[] or ByteBuffer because either way, the class can be defined directly.

It would be nice if the class file parser could accept either a byte[] or a ByteBuffer. I did a quick bit of exploratory work and it looks like porting the code to read from a ByteBuffer instead of a byte[]  (using ByteBuffer.wrap() for the array case) would be largely straightforward *except* for the code which parses UTF-8 constants into strings. Also there could be some small performance differences (maybe positive, maybe negative) depending on how the buffer is accessed.

Is this something that might be considered?

--
- DML • he/him


--
- DML • he/him


--
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250321/ab313606/attachment-0001.htm>