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
8265423: [lworld] Provide experimental support for generating a single class file per primitive class #394
Conversation
…e class file per primitive class
|
@sadayapalam This change now passes all automated pre-integration checks. 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 2 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the
|
Webrevs
|
@@ -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) { |
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.
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)
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.
Thanks, I will take a look
@@ -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(); |
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 change seems sneaky - what caused it?
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.
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.
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.
(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)
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 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.
/integrate |
@sadayapalam Since your change was applied there have been 2 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 17b12ac. |
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
Issue
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