8265423: [lworld] Provide experimental support for generating a single class file per primitive class #394

sadayapalam · 2021-04-27T08:45:18Z

Use -XDunifiedValRefClass option to javac to get unified class file generation for primitive classes. Note: Javac will require some tweaks to consume such files, this is WIP.

Progress

Change must not contain extraneous whitespace

Issue

JDK-8265423: [lworld] Provide experimental support for generating a single class file per primitive class

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/valhalla pull/394/head:pull/394
$ git checkout pull/394

Update a local copy of the PR:
$ git checkout pull/394
$ git pull https://git.openjdk.java.net/valhalla pull/394/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 394

View PR using the GUI difftool:
$ git pr show -t 394

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/valhalla/pull/394.diff

…e class file per primitive class

bridgekeeper · 2021-04-27T08:46:34Z

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

openjdk · 2021-04-27T08:47:58Z

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

8265423: [lworld] Provide experimental support for generating a single class file per primitive class

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 2 new commits pushed to the lworld branch:

a7ab3bb: 8266086: [lworld][lw3] C1 produces incorrect code when GlobalValueNumbering is used
8dc4430: 8265726: [lworld] C2 compilation fails with assert "uses must be dominated by definitions"

Please see this link for an up-to-date comparison between the source branch of this pull request and the lworld branch.
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 lworld branch, type /integrate in a new comment.

mlbridge · 2021-04-27T08:52:08Z

Webrevs

mcimadamore · 2021-04-27T12:22:17Z

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java

@@ -845,7 +845,7 @@ void writeInnerClasses() {
                !inner.name.isEmpty() ? poolWriter.putName(inner.name) : 0);
            databuf.appendChar(flags);
            icCount++;
-            if (inner.isPrimitiveClass()) {
+            if (inner.isPrimitiveClass() && types.splitPrimitiveClass) {


the test sym.isPrimitiveClass() && types.splitPrimitiveClass is so common which I think would be better refactored into a separate predicate, to make the code clearer.

e.g. Symbol.isSplitPrimitiveClass(Types)

Thanks, I will take a look

mcimadamore · 2021-04-27T12:22:17Z

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java

@@ -2687,7 +2687,7 @@ public void readClassFile(ClassSymbol c) {
            ClassSymbol referenceProjection = syms.getClass(currentModule, flatname);
            if (referenceProjection != null) {
                if (referenceProjection.name != names.ref && referenceProjection.owner.kind == PCK) {
-                    readClassFileInternal(referenceProjection);
+                    referenceProjection.complete();


This change seems sneaky - what caused it?

Indeed. I should push this as a separate change set. I discovered this bug while working on the now aborted attempt to evolve the code generation scheme to match SoV4. The right way to internalize the class is by calling complete() on the symbol and not by directly calling readClassFileInternal(). Doing the latter, could result in com.sun.tools.javac.code.ClassFinder#fillIn(com.sun.tools.javac.code.Symbol.ClassSymbol) from being re-entered resulting in an assertion failure.

This change is not required for the present feature, but is a crucial fix that should be made independently.

(As I was studying the code that merges the projections back to see what changes I should make for the unified class model, I remembered that bug fix from that aborted work)

I'm fine with keeping the change here if that's easier - I just wanted to make sure I understood where this was coming from as it looked an odd change given what of the rest of the code is doing. Thanks for the explanation.

…y method

…asses

sadayapalam · 2021-05-03T12:36:56Z

/integrate

openjdk · 2021-05-03T12:38:37Z

@sadayapalam Since your change was applied there have been 2 commits pushed to the lworld branch:

a7ab3bb: 8266086: [lworld][lw3] C1 produces incorrect code when GlobalValueNumbering is used
8dc4430: 8265726: [lworld] C2 compilation fails with assert "uses must be dominated by definitions"

Your commit was automatically rebased without conflicts.

Pushed as commit 17b12ac.

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

8265423: [lworld] Provide experimental support for generating a singl…

d5bae7d

…e class file per primitive class

openjdk bot added ready rfr labels Apr 27, 2021

mcimadamore reviewed Apr 27, 2021

View changes

sadayapalam added 2 commits May 3, 2021

Address review comments to refactor common code pattern into a utilit…

75632dc

…y method

Tests for experimental unified mode class generation for primitive cl…

5443d48

…asses

openjdk bot closed this May 3, 2021

openjdk bot added integrated and removed ready rfr labels May 3, 2021

sadayapalam deleted the JDK-8265423 branch May 3, 2021

8265423: [lworld] Provide experimental support for generating a single class file per primitive class #394

8265423: [lworld] Provide experimental support for generating a single class file per primitive class #394

sadayapalam commented Apr 27, 2021 •

edited by openjdk[bot] bot

bridgekeeper bot commented Apr 27, 2021

openjdk bot commented Apr 27, 2021 •

edited

mlbridge bot commented Apr 27, 2021 •

edited

mcimadamore Apr 27, 2021

sadayapalam Apr 27, 2021

mcimadamore Apr 27, 2021

sadayapalam Apr 27, 2021 •

edited

sadayapalam Apr 27, 2021

mcimadamore Apr 27, 2021

sadayapalam commented May 3, 2021

openjdk bot commented May 3, 2021

8265423: [lworld] Provide experimental support for generating a single class file per primitive class #394

8265423: [lworld] Provide experimental support for generating a single class file per primitive class #394

Conversation

sadayapalam commented Apr 27, 2021 • edited by openjdk[bot] bot

Progress

Issue

Reviewing

bridgekeeper bot commented Apr 27, 2021

openjdk bot commented Apr 27, 2021 • edited

mlbridge bot commented Apr 27, 2021 • edited

Webrevs

mcimadamore Apr 27, 2021

Choose a reason for hiding this comment

sadayapalam Apr 27, 2021

Choose a reason for hiding this comment

mcimadamore Apr 27, 2021

Choose a reason for hiding this comment

sadayapalam Apr 27, 2021 • edited

Choose a reason for hiding this comment

sadayapalam Apr 27, 2021

Choose a reason for hiding this comment

mcimadamore Apr 27, 2021

Choose a reason for hiding this comment

sadayapalam commented May 3, 2021

openjdk bot commented May 3, 2021

sadayapalam commented Apr 27, 2021 •

edited by openjdk[bot] bot

openjdk bot commented Apr 27, 2021 •

edited

mlbridge bot commented Apr 27, 2021 •

edited

sadayapalam Apr 27, 2021 •

edited