Class files in ByteBuffer

[David Lloyd]

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> 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> on behalf
> of David Lloyd <david.lloyd at redhat.com>
> *Date: *Thursday, 20 March 2025 at 21:11
> *To: *classfile-api-dev at openjdk.org <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
>
>
>
> On Mon, Mar 10, 2025 at 12:38 PM David Lloyd <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/1bb9ea83/attachment.htm>