Skip to content
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

Closed
wants to merge 14 commits into from

Conversation

liach
Copy link
Member

@liach liach commented Oct 21, 2024

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

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change requires CSR request JDK-8344373 to be approved

Issues

  • JDK-8342469: Improve API documentation for java.lang.classfile.instruction (Sub-task - P4)
  • JDK-8344373: Improve API documentation for java.lang.classfile.instruction (CSR)

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

@bridgekeeper
Copy link

bridgekeeper bot commented Oct 21, 2024

👋 Welcome back liach! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Oct 21, 2024

@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:

8342469: Improve API documentation for java.lang.classfile.instruction

Reviewed-by: asotona, darcy

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 master branch:

  • 9bd70ec: 8345888: Broken links in the JDK 24 JavaDoc API documentation, build 27
  • 1def2d8: 8345700: tier{1,2,3}_compiler don't cover all compiler tests
  • d6b5264: 8345746: Remove :resourcehogs/compiler from :hotspot_slow_compiler
  • 4f855d1: 8345818: Fix SM cleanup of parsing of System property resource.bundle.debug
  • a24b08f: 8345669: RISC-V: fix client build failure due to AlignVector after JDK-8343827
  • 25d9deb: 8335367: [s390] Add support for load immediate on condition instructions.
  • a6277bb: 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
  • 165fd84: 8342987: Update --release 24 symbol information for JDK 24 build 27
  • 06c44dd: 8345465: Fix performance regression on x64 after JDK-8345120
  • 2979806: 8345795: Update copyright year to 2024 for hotspot in files where it was missed
  • ... and 89 more: https://git.openjdk.org/jdk/compare/79eb77b782bd0c3cecee6c66b86f6f3e17054498...master

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 master branch, type /integrate in a new comment.

@openjdk
Copy link

openjdk bot commented Oct 21, 2024

@liach The following label will be automatically applied to this pull request:

  • core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the core-libs core-libs-dev@openjdk.org label Oct 21, 2024
@liach
Copy link
Member Author

liach commented Oct 22, 2024

/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 liach marked this pull request as ready for review October 22, 2024 04:25
@openjdk openjdk bot added rfr Pull request is ready for review csr Pull request needs approved CSR before integration labels Oct 22, 2024
@openjdk
Copy link

openjdk bot commented Oct 22, 2024

@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.

@mlbridge
Copy link

mlbridge bot commented Oct 22, 2024

Webrevs

Copy link
Member

@asotona asotona left a 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}.
Copy link
Member

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.

@liach
Copy link
Member Author

liach commented Nov 18, 2024

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 java.lang.classfile top-level documentation later.

I am pleased with the current state of the documentation, and have submitted a CSR.
Please review the renderings:

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

(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}.
Copy link
Member

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).

Copy link
Member Author

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.
Copy link
Member

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?

Copy link
Member Author

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.

@asotona
Copy link
Member

asotona commented Nov 19, 2024

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) .

@liach
Copy link
Member Author

liach commented Nov 20, 2024

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
Copy link
Member

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.

Copy link
Member Author

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,
Copy link
Member

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:
Copy link
Member

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:
Copy link
Member

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,
Copy link
Member

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?

Copy link
Member Author

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.

@asotona
Copy link
Member

asotona commented Nov 21, 2024

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?

Copy link
Member

@asotona asotona left a 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.

@openjdk openjdk bot added ready Pull request is ready to be integrated and removed csr Pull request needs approved CSR before integration labels Dec 10, 2024
@liach
Copy link
Member Author

liach commented Dec 10, 2024

Thanks for the reviews!

/integrate

@openjdk
Copy link

openjdk bot commented Dec 10, 2024

Going to push as commit 0f03554.
Since your change was applied there have been 99 commits pushed to the master branch:

  • 9bd70ec: 8345888: Broken links in the JDK 24 JavaDoc API documentation, build 27
  • 1def2d8: 8345700: tier{1,2,3}_compiler don't cover all compiler tests
  • d6b5264: 8345746: Remove :resourcehogs/compiler from :hotspot_slow_compiler
  • 4f855d1: 8345818: Fix SM cleanup of parsing of System property resource.bundle.debug
  • a24b08f: 8345669: RISC-V: fix client build failure due to AlignVector after JDK-8343827
  • 25d9deb: 8335367: [s390] Add support for load immediate on condition instructions.
  • a6277bb: 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
  • 165fd84: 8342987: Update --release 24 symbol information for JDK 24 build 27
  • 06c44dd: 8345465: Fix performance regression on x64 after JDK-8345120
  • 2979806: 8345795: Update copyright year to 2024 for hotspot in files where it was missed
  • ... and 89 more: https://git.openjdk.org/jdk/compare/79eb77b782bd0c3cecee6c66b86f6f3e17054498...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Dec 10, 2024
@openjdk openjdk bot closed this Dec 10, 2024
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Dec 10, 2024
@openjdk
Copy link

openjdk bot commented Dec 10, 2024

@liach Pushed as commit 0f03554.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@liach
Copy link
Member Author

liach commented Dec 10, 2024

/backport :jdk24

@openjdk
Copy link

openjdk bot commented Dec 10, 2024

@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:

➡️ Create pull request

The title of the pull request is automatically filled in correctly and below you find a suggestion for the pull request body:

Hi all,

This pull request contains a backport of commit 0f035545 from the openjdk/jdk repository.

The commit being backported was authored by Chen Liang on 10 Dec 2024 and was reviewed by Adam Sotona and Joe Darcy.

Thanks!

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:

$ git fetch https://github.com/openjdk-bots/jdk.git backport-liach-0f035545-jdk24:backport-liach-0f035545-jdk24
$ git checkout backport-liach-0f035545-jdk24
# make changes
$ git add paths/to/changed/files
$ git commit --message 'Describe additional changes made'
$ git push https://github.com/openjdk-bots/jdk.git backport-liach-0f035545-jdk24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

3 participants