Review of JEP draft

[David Lloyd]

The proposal seems to imply that the only alternative would be to pad all
existing opcodes. But at the same time, it indicates that having the
`ExtendedOpcodes` attribute be present - on a per-Code-attribute basis -
would require not only the extra bytes for the attribute but that the code
attribute itself must be padded.

What about alternatives such as reserving one (or more) bytecode(s) to mean
"extended instruction"?  This would be similar to how `WIDE` modifies the
next bytecode, and would immediately make another 256 bytecodes available
without impacting the size of any other bytecode in the method, nor
requiring any extra attributes.

This idea could be extended as far as one is willing to add prefix
bytecodes. For example one could reserve 16 aligned and consecutive
bytecodes for this purpose, creating a 12 bit space for up to 4096 more
bytecodes with a minimum of impact on space or on producers or consumers of
bytecodes, at the cost of 16 "small" bytecodes.

While there might (or might not) be good reasons to not pursue this
approach, if you're talking about extending the bytecode space in a JEP,
you should probably at least explain why such a scheme should not be
considered or else list it under the "Alternatives" heading.


On Thu, Mar 17, 2022 at 7:19 AM Julian Waters <tanksherman27 at gmail.com>
wrote:

> Hi everyone,
>
> If you don't mind a little reading, can I get a review of the following JEP
> draft at
>
> https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8283291?filter=allissues&orderby=created+DESC%2C+priority+DESC%2C+updated+DESC
> ?
> Apologies if this is not the proper way to submit a JEP, I'm a little new
> to this.
>
> Have a great day!
>
> best regards,
> Julian
>
>

-- 
- DML • he/him