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

8244414: [lworld] Migrate Valhalla micro benchmarks suite to not use V? syntax #35

Closed
wants to merge 3 commits into from

Conversation

sadayapalam
Copy link
Collaborator

@sadayapalam sadayapalam commented May 6, 2020

Description of changes:

Hi Maruizio,

Could you please review these assorted changes that block the build of Valhalla micro

benchmarks ? This is a culumative fix for JDK-8244414 and JDK-8244458

You could skip a review of the benchmark source files themselves - these have only mechanical changes from V? to V.ref except for one case where there was a usage of Node?<K,V> with Node actually being an identity class. We don't support the transformed Node.ref<K,V> for identity classes, so I had to drop the '?'

Problems fixed:

(i) Resolve.java: Diamond inference did not work for inline type constructors: Basically, the (static factory method equivalent) constructors synthesized during diamond inference did not have their reference projection counterparts and had to be paired up with them.

(ii) Types.java: LUB computation in the presence of mixed values and non-values should first apply widening conversion.

(iii) Enter.java: When we recompile files due to annotation processing rounds, discard

any prior state carried on by the reference projection so as to keep it in sync with its peer.
(A separate test will be added separately - for now building microbenchmarks is the test for this)


Progress

  • Change must not contain extraneous whitespace

Issue

  • JDK-8244414: [lworld] Migrate Valhalla micro benchmarks suite to not use V? syntax

Reviewers

Download

$ git fetch https://git.openjdk.java.net/valhalla pull/35/head:pull/35
$ git checkout pull/35

@bridgekeeper
Copy link

bridgekeeper bot commented May 6, 2020

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

@openjdk
Copy link

openjdk bot commented May 6, 2020

@sadayapalam This change now passes all automated pre-integration checks, type /integrate in a new comment to proceed. After integration, the commit message will be:

8244414: [lworld] Migrate Valhalla micro benchmarks suite to not use V? syntax

Reviewed-by: mcimadamore
  • If you would like to add a summary, use the /summary command.
  • To credit additional contributors, use the /contributor command.
  • To add additional solved issues, use the /solves command.

There are currently no new commits on the lworld branch since the last update of the source branch of this PR. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you would like to avoid potential automatic rebasing, specify the current head hash when integrating, like this: /integrate 08bfa8fe76ffd22b1a8afe93b5f221bec624dc4c.

➡️ To integrate this PR with the above commit message to the lworld branch, type /integrate in a new comment.

@mlbridge
Copy link

mlbridge bot commented May 6, 2020

Webrevs

Copy link
Collaborator

@mcimadamore mcimadamore left a comment

Added a couple of comments.

* @run main InlineDiamondTest
*/

public class InlineDiamondTest<E> {
Copy link
Collaborator

@mcimadamore mcimadamore May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test seems the same as InlineDiamondTest...

Copy link
Collaborator Author

@sadayapalam sadayapalam May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm. I have no idea how this garbling came about. It did exist in proper form some point as I can see from my backups! Anyway thanks for catching this.!

@@ -4000,6 +4000,22 @@ public Type lub(Type... ts) {

int[] kinds = new int[ts.length];

boolean haveValues = false;
Copy link
Collaborator

@mcimadamore mcimadamore May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the goal is to fix the behavior of conditional expression typing, I think the fix should happen outside lub(), more specifically in Attr::condType

Copy link
Collaborator Author

@sadayapalam sadayapalam May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. - to me it looks more natural to push this down to the service. But I am open to bubbling this up to the client. With your consent, I will combine this with the fix for JDK-8244513

Copy link
Collaborator

@mcimadamore mcimadamore left a comment

Looks good

@sadayapalam
Copy link
Collaborator Author

sadayapalam commented May 6, 2020

/integrate

@openjdk openjdk bot closed this May 6, 2020
@openjdk openjdk bot added the integrated label May 6, 2020
@openjdk
Copy link

openjdk bot commented May 6, 2020

@sadayapalam
Pushed as commit 72aa43e.

@openjdk openjdk bot removed ready rfr labels May 6, 2020
@sadayapalam sadayapalam deleted the JDK-8244414 branch May 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants