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
8273301: [lworld] Bootstrap of instance-capturing lambda fails for reference favoring primitive types. #545
Conversation
…avoring primitive types. Adjust bootstrap parameters, like it was fixed in JDK-8271583.
|
Looks good to me - However, I would like to ask Mandy whether we are working around a problem in the runtime that should really be fixed there. @mlchung Could you please take a look at the code generated with and without fix and see if the change in javac emitted code is the proper way for this to be fixed ? The failure mode is
The failing code being:
and the patch here alters the generated code to be:
|
Still says title mismatch - Not sure why |
A reference to a primitive object can be converted to a primitive value and vice versa. So I think the runtime should allow the receiver type of |
I'm not sure if the javac fix is needed. The |
The Java 17 version of LambdaMetafactory requires that the parameter types of I'm not sure whether there have been modifications in Valhalla. We could conceivably make some changes if it's useful. Eventually, we'd like to align the conversions supported by LambdaMetafactory for all parameters/returns with those supported by |
The change to the runtime in JDK-8174983 will allow boxing and unboxing: In lworld terms, I suppose this would map to turning a QFoo (primitive class on-stack) into an LFoo (reference to primitive class), and vice versa (although I'm not sure how null references would be handled). There are obvious reasons why this is a useful feature for LambdaMetafactory. However, I find it odd for javac not to generate identical code for a callsite depending on whether or not the enclosing class is "reference-favoring" or not. This should only influence uses of the type, not the type itself. Primitive class instance methods should still "operate on" instances (QFoo), not references to instance (LFoo). So, I think that the javac should be consistent regarding the emitting of receiver-types, even if for the sake of the conceptual consistency itself. |
I discussed with Dan offline to follow up my question in what cases javac should emit For a method reference
In short, it's good to fix javac to emit |
Based on @mlchung 's comment from last week, it would be correct to integrate this. /integrate |
@jespersm This PR has not yet been marked as ready for integration. |
@mlchung : I've tested, and can confirm that both your fix on the lambda side of things and my fix on the compiler side (this PR) will make the attached test case pass. However, from your comments above, quoting a discussion with Dan, I'm suggesting that javac is tightened up, as the smaller fix, so to speak, i.e. that we integrate this PR. I then suggest that your fix should be brought under the JDK-8174983 umbrella, since the L->Q and Q->L conversions are conceptually similar, and thus useful for other users of LambdaMetafactory. If you agree, @sadayapalam can review this bug as it. |
Thanks for confirming it. I also create JDK-8274399 to fix the runtime.
Yes, we agree that it's good to fix javac as well. You need @sadayapalam to review your PR before integration. I recalled Srikanath was on vacation and I'm not sure whether he's back.
It's related to JDK-8174983. We can fix JDK-8274399 in lworld branch while JDK-8174983 can be fixed separately in the main line.
Yes I agree. |
@jespersm this pull request can not be integrated into git checkout 8273301-ref-lambda
git fetch https://git.openjdk.java.net/valhalla lworld
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge lworld"
git push |
Jesper, I think this PR may be abandoned and the related JBS ticket closed as Not an Issue. The whole inlining/flattening thing is an "optimization" - so these classes are reference classes for |
Abandoning this, no longer relevant. |
Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.
Progress
Integration blocker
Issue
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/valhalla pull/545/head:pull/545
$ git checkout pull/545
Update a local copy of the PR:
$ git checkout pull/545
$ git pull https://git.openjdk.java.net/valhalla pull/545/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 545
View PR using the GUI difftool:
$ git pr show -t 545
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/valhalla/pull/545.diff