-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8342469: Improve API documentation for java.lang.classfile.instruction #21625
Conversation
👋 Welcome back liach! A progress list of the required criteria for merging this PR into |
@liach This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 99 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
/csr needed Proofread a little bit. Since this is huge and there may be mistakes, I will only create a CSR after some typos and problems have been fixed to reduce repeated updates to the CSR. |
@liach has indicated that a compatibility and specification (CSR) request is needed for this pull request. @liach please create a CSR request for issue JDK-8342469 with the correct fix version. This pull request cannot be integrated until the CSR request is approved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job done!
It would be good to have another pair of eyes to read the new doc, however it looks good to me.
LCONST_1(RawBytecodeHelper.LCONST_1, 1, Kind.CONSTANT), | ||
|
||
/** Push float constant 0 */ | ||
/** | ||
* Push {@link TypeKind#FLOAT float} constant {@code 0}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the float and double constants, it would be a small improvement to write them out as floating-point literals, "0.0f" for a float zero, etc.
After offline discussions, I believe it is necessary to also include the data models of instructions in the javadoc; they will be removed from the I am pleased with the current state of the documentation, and have submitted a CSR. API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html (Omitted the constant rendering changes; committed locally, will push with other review fixes later) |
* } | ||
* <p> | ||
* Physically, a character range has the same structure; it is modeled by a | ||
* {@link CharacterRangeInfo}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to explain "Physically" and "it is modeled by".
If "Physically" means specific byte serialization, then it is an entry in a CRT attribute with BCIs instead of labels.
"it is modeled by a CharacterRangeInfo" seems to me very confusing as this class (CharacterRange) is the primary model class.
Maybe we should explain the duplicity of some classfile structures accessible as attributes internal raw structures (CharacterRangeInfo) versus preferred primary models as labeled pseudo instructions (CharacterRange).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. I have simplified the record model and added dedicated info about CRI being independent from Code so it's used in the attribute. Same for LineNumber etc.
* ConstantDesc}. | ||
* <p> | ||
* Physically, a constant-load instruction is polymorphic; nested interfaces in | ||
* this interface model different constant instructions as records. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what the sentence "nested interfaces in this interface model different constant instructions as records" gives to users and on the other side what obligation does it mean from the JCK perspective?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed this confusing and meaningless sentence.
My personal feeling is that sentences like "Conceptually, Xy is a record..." and "Physically, Xy is a record..." are more confusing than explaining. My understanding of "Conceptually" is that the particular sealed interface xyInstruction represents the model concept. My understanding of "Physically" is that the particular chapter 6. paragraph of the JVMS describes the mechanics. And I don't see there any records (in particular Java meaning) . |
… also the labelless info models
I used the term "record" because they are something that may be pattern-matchable in the future; they are plain data objects. Similar representation is used in data model section of the java.lang.classfile package-level documentation. Pushed another iteration (also updated CR) that solved some of the issues, including the constant format problems. I still think it is meaningful to move the huge data model from root package doc to individual model classes. |
* the {@link ClassFile.ShortJumpsOption} controls how an invalid {@code jsr} | ||
* instruction model is written by a {@link CodeBuilder}. | ||
* <p> | ||
* Jump subroutine instructions push a {@link TypeKind##returnAddress |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have a TypeKind##returnAddress.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This links to the index tag on returnAddress.
* where {@code slot} must be within {@code [0, 65535]}. | ||
* <p> | ||
* {@link StoreInstruction astore} series of instructions store a {@link | ||
* TypeKind##returnAddress returnAddress} value to a local variable slot, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And the same here.
* have a {@linkplain Opcode#kind() kind} of {@link Opcode.Kind#CONVERT}. | ||
* Delivered as a {@link CodeElement} when traversing the elements of a {@link CodeModel}. | ||
* <p> | ||
* Conceptually, a primitive conversion instruction is a record: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here remains "Conceptually, ... is a record"
* Corresponding opcodes have a {@linkplain Opcode#kind() kind} of {@link Opcode.Kind#INVOKE}. | ||
* Delivered as a {@link CodeElement} when traversing the elements of a {@link CodeModel}. | ||
* <p> | ||
* Conceptually, a method invocation instruction is a record: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here
* {@return the type of the value to be stored} | ||
* {@return the {@linkplain TypeKind##computational-type computational type} | ||
* of the value to be stored} The {@link TypeKind#REFERENCE reference} | ||
* type store instructions also operate on the {@code returnAddress} type, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do we expose a TypeKind related to a return address?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do not. This just notes astore can store jsr addresses (see jvms). This is intended to be similar to the array load/store boolean note.
It looks better to me now, much easier to understand. @jddarcy what do you think about general formulations "Xy instruction can be viewed as a record..." describing code elements exposed as sealed interfaces in the API? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks.
Thanks for the reviews! /integrate |
Going to push as commit 0f03554.
Your commit was automatically rebased without conflicts. |
/backport :jdk24 |
@liach the backport was successfully created on the branch backport-liach-0f035545-jdk24 in my personal fork of openjdk/jdk. To create a pull request with this backport targeting openjdk/jdk:jdk24, just click the following link: The title of the pull request is automatically filled in correctly and below you find a suggestion for the pull request body:
If you need to update the source branch of the pull then run the following commands in a local clone of your personal fork of openjdk/jdk:
|
Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
Please review the associated CSR as well.
Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21625/head:pull/21625
$ git checkout pull/21625
Update a local copy of the PR:
$ git checkout pull/21625
$ git pull https://git.openjdk.org/jdk.git pull/21625/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 21625
View PR using the GUI difftool:
$ git pr show -t 21625
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21625.diff
Using Webrev
Link to Webrev Comment