From duke at openjdk.org  Mon Aug  1 12:47:44 2022
From: duke at openjdk.org (Joe)
Date: Mon, 1 Aug 2022 12:47:44 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
Message-ID: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>

8289562: Change bugs.java.com and bugreport.java.com URL's to https

-------------

Commit messages:
 - Merge branch 'openjdk:master' into master
 - changed the hrl from http to https JDK-8289562

Changes: https://git.openjdk.org/jdk/pull/9445/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9445&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289562
  Stats: 18 lines in 17 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9445/head:pull/9445

PR: https://git.openjdk.org/jdk/pull/9445

From fmatte at openjdk.org  Mon Aug  1 14:32:47 2022
From: fmatte at openjdk.org (Fairoz Matte)
Date: Mon, 1 Aug 2022 14:32:47 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <yKAWQeCCkJiO3lvHnWLvEKVuWTt9R3JEkxgnIiEWW8E=.e48cfdf8-8fa0-47a1-bfb3-874bcffaadd7@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

It is a trivial change and looks good to me (I am not a reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9445

From naoto at openjdk.org  Mon Aug  1 16:46:01 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 Aug 2022 16:46:01 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
Message-ID: <O9yRN6jY9EjtvHp7fHIG81kU_uHr4nFmFs2tviKvJ5k=.a3ff6f40-de36-4f0c-af35-e1adf2c4bf55@github.com>

On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/154

From prr at openjdk.org  Mon Aug  1 22:52:52 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Aug 2022 22:52:52 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <RzARYHG0jJJZm-EExZ4T_eITO9lJTQXAJWi9vidinjA=.2b597369-2406-43ad-a611-5d8eb8860193@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Looks fine to me. However the langtools / javadoc folks seem like they should be primary reviewers since it is mostly messages from the tools.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9445

From vromero at openjdk.org  Tue Aug  2 00:02:30 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 2 Aug 2022 00:02:30 GMT
Subject: RFR: 8260892: Compilation fails: lambda parameter not visible in body
 when generics involved
Message-ID: <PC8-SgHh4s-d_qpfRpZsav13FCU_9S-d4EatM422HVQ=.d7daf2c9-19c8-4d52-bf99-b97bf9633194@github.com>

This bug is being produced because as the diamond expression can't be attributed until the inference has been done. A listener is registered in the corresponding inference context but the way the current environment is being copied into `dupLocalEnv` produces a copy that shares info with the outer lambda expression. The lambda expression removes the argument from the shared scope before the listener is fired and thus the error. The proposal is to use a different way to copy the environment into `dupLocalEnv` by producing a brand new scope.

TIA

-------------

Commit messages:
 - 8260892: Compilation fails: lambda parameter not visible in body when generics involved

Changes: https://git.openjdk.org/jdk/pull/9710/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9710&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8260892
  Stats: 52 lines in 2 files changed: 51 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9710.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9710/head:pull/9710

PR: https://git.openjdk.org/jdk/pull/9710

From turbanoff at gmail.com  Mon Aug  1 07:29:07 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Mon, 1 Aug 2022 10:29:07 +0300
Subject: package-info.java compiled name
Message-ID: <CAF+DQ5fG1gvygjKeFe=4PC927N9wpJbyfOFtGF+-sfDLDRQceQ@mail.gmail.com>

Hello.
We found confusing behaviour of javac, when it compiles package-info.java
On Windows name of compiled _inteface_ contains backslashes:

client>javap package-info.class
Compiled from "package-info.java"
interface some\org\client\package-info {
}

On Linux it looks ok:

client$ javap  package-info.class
Compiled from "package-info.java"
interface some.org.client.package-info {
}

It turns out, such behaviour breaks AspectJ code -
https://github.com/eclipse/org.aspectj/issues/176 (sample maven
project - https://github.com/eclipse/org.aspectj/files/9188154/dxcore-temp.zip)
I believe content of class file shouldn't not depend on compilation platform.
Is there a reason why javac behaves like this?


Best regards,
Andrey Turbanov

From jonathan.gibbons at oracle.com  Tue Aug  2 20:16:18 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 2 Aug 2022 13:16:18 -0700
Subject: package-info.java compiled name
In-Reply-To: <CAF+DQ5fG1gvygjKeFe=4PC927N9wpJbyfOFtGF+-sfDLDRQceQ@mail.gmail.com>
References: <CAF+DQ5fG1gvygjKeFe=4PC927N9wpJbyfOFtGF+-sfDLDRQceQ@mail.gmail.com>
Message-ID: <5531d15f-31bd-8062-5f6c-16072bfd7780@oracle.com>

That's definitely a bug in either javac or javap.

-- Jon

On 8/1/22 12:29 AM, Andrey Turbanov wrote:
> Hello.
> We found confusing behaviour of javac, when it compiles package-info.java
> On Windows name of compiled _inteface_ contains backslashes:
>
> client>javap package-info.class
> Compiled from "package-info.java"
> interface some\org\client\package-info {
> }
>
> On Linux it looks ok:
>
> client$ javap  package-info.class
> Compiled from "package-info.java"
> interface some.org.client.package-info {
> }
>
> It turns out, such behaviour breaks AspectJ code -
> https://github.com/eclipse/org.aspectj/issues/176 (sample maven
> project - https://github.com/eclipse/org.aspectj/files/9188154/dxcore-temp.zip)
> I believe content of class file shouldn't not depend on compilation platform.
> Is there a reason why javac behaves like this?
>
>
> Best regards,
> Andrey Turbanov

From darcy at openjdk.org  Wed Aug  3 03:42:26 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Aug 2022 03:42:26 GMT
Subject: RFR: JDK-8289249: Add methods to Elements for record constructors
Message-ID: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>

Please review the addition of two predicates to better support records in the javax.lang.model API.

Please also review the CSR https://bugs.openjdk.org/browse/JDK-8291594

-------------

Commit messages:
 - Appease jcheck.
 - Respond to CSR review feedback.
 - Include regression tests.
 - JDK-8289249: Add methods to Elements for record constructors

Changes: https://git.openjdk.org/jdk/pull/9694/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9694&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289249
  Stats: 224 lines in 3 files changed: 224 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9694.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9694/head:pull/9694

PR: https://git.openjdk.org/jdk/pull/9694

From fweimer at redhat.com  Wed Aug  3 07:31:44 2022
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 03 Aug 2022 09:31:44 +0200
Subject: package-info.java compiled name
In-Reply-To: <CAF+DQ5fG1gvygjKeFe=4PC927N9wpJbyfOFtGF+-sfDLDRQceQ@mail.gmail.com>
 (Andrey Turbanov's message of "Mon, 1 Aug 2022 10:29:07 +0300")
References: <CAF+DQ5fG1gvygjKeFe=4PC927N9wpJbyfOFtGF+-sfDLDRQceQ@mail.gmail.com>
Message-ID: <87r11xdbq7.fsf@oldenburg.str.redhat.com>

* Andrey Turbanov:

> Hello.
> We found confusing behaviour of javac, when it compiles package-info.java
> On Windows name of compiled _inteface_ contains backslashes:
>
> client>javap package-info.class
> Compiled from "package-info.java"
> interface some\org\client\package-info {
> }

It seems that the class file is not generated by javac:

  Incorrect internal string format in generated package-info.class files
  on Windows
  <https://issues.apache.org/jira/browse/MCOMPILER-485>

  ?Unfortunately, the binary class file is incorrectly generated using
  Java's file toString() which uses a platform dependent file separator
  character: on Windows, these Strings contain a backslash.  See this
  line[1] which passes the platform-dependent file name (minus the root
  path and .java extension) to the ClassWriter.?

  [1]https://github.com/gnodet/maven-compiler-plugin/blob/8521ef8fdd12cc0b85c1ace17114ed3d3ffd0b0c/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1356

Thanks,
Florian


From abimpoudis at openjdk.org  Wed Aug  3 16:18:18 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 3 Aug 2022 16:18:18 GMT
Subject: RFR: 8290709: Incorrect dominance error for unconditional pattern vs.
 null
Message-ID: <Ir3ff4HHm4rCDRPYIuc-EfmQ1_RQ6dnYDDOnjLJVA38=.cca6a3f6-f30d-4c80-b99f-c0b05594b38b@github.com>

The corresponding JLS rule (3rd preview feature of pattern switch) on unconditional patterns & null does not exist anymore:

Check:

- 2nd preview: https://cr.openjdk.java.net/~gbierman/jep420/jep420-20211208/specs/patterns-switch-jls.html#jls-14.11.1
- 3rd preview: https://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-14.11.1

Effectively, the following restriction was lifted:

A switch label that has a pattern case label element p that is total for the type of the selector expression of the enclosing switch statement or switch expression dominates a switch label that has a null case label element.


The corresponding neg-tests where now promoted as pos-tests.

-------------

Commit messages:
 - 8290709: Incorrect dominance error for unconditional pattern vs. null

Changes: https://git.openjdk.org/jdk/pull/9732/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9732&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290709
  Stats: 66 lines in 6 files changed: 25 ins; 20 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/9732.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9732/head:pull/9732

PR: https://git.openjdk.org/jdk/pull/9732

From jlahoda at openjdk.org  Wed Aug  3 18:28:47 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 3 Aug 2022 18:28:47 GMT
Subject: RFR: 8260892: Compilation fails: lambda parameter not visible in
 body when generics involved
In-Reply-To: <PC8-SgHh4s-d_qpfRpZsav13FCU_9S-d4EatM422HVQ=.d7daf2c9-19c8-4d52-bf99-b97bf9633194@github.com>
References: <PC8-SgHh4s-d_qpfRpZsav13FCU_9S-d4EatM422HVQ=.d7daf2c9-19c8-4d52-bf99-b97bf9633194@github.com>
Message-ID: <Zhx0FJ0ASFHvgm9Pog3_JKujJalkMr4ooO4vbszXr94=.0008c633-68e5-4bf5-a742-45c46c8391f4@github.com>

On Mon, 1 Aug 2022 23:37:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This bug is being produced because as the diamond expression can't be attributed until the inference has been done. A listener is registered in the corresponding inference context but the way the current environment is being copied into `dupLocalEnv` produces a copy that shares info with the outer lambda expression. The lambda expression removes the argument from the shared scope before the listener is fired and thus the error. The proposal is to use a different way to copy the environment into `dupLocalEnv` by producing a brand new scope.
> 
> TIA

Looks reasonable to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9710

From vromero at openjdk.org  Wed Aug  3 19:38:29 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Aug 2022 19:38:29 GMT
Subject: RFR: 8285935: Spurious lint warning for static method accessed
 through instance qualifier [v2]
In-Reply-To: <qYH89lnOxAYYDxfbftLTopYv69Uf7l-w_KglLORzgeM=.33e96f4e-e9a9-4b9c-bea9-65665ede25df@github.com>
References: <qYH89lnOxAYYDxfbftLTopYv69Uf7l-w_KglLORzgeM=.33e96f4e-e9a9-4b9c-bea9-65665ede25df@github.com>
Message-ID: <vLfaWPILKl1h_2X3RBuc24SrUMrHeuleg8LuQMEZniQ=.37a6631c-4ea5-480f-8dbb-8b3ad7e51da8@github.com>

> Please review this simple fix which is adding a more precise, I hope, warning for the case when a static method or field is being accessed using an anonymous class instance.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  updating the warning message text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9521/files
  - new: https://git.openjdk.org/jdk/pull/9521/files/1cff3326..265a478e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9521&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9521&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9521.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9521/head:pull/9521

PR: https://git.openjdk.org/jdk/pull/9521

From vromero at openjdk.org  Wed Aug  3 19:48:06 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Aug 2022 19:48:06 GMT
Subject: RFR: 8260892: Compilation fails: lambda parameter not visible in
 body when generics involved
In-Reply-To: <Zhx0FJ0ASFHvgm9Pog3_JKujJalkMr4ooO4vbszXr94=.0008c633-68e5-4bf5-a742-45c46c8391f4@github.com>
References: <PC8-SgHh4s-d_qpfRpZsav13FCU_9S-d4EatM422HVQ=.d7daf2c9-19c8-4d52-bf99-b97bf9633194@github.com>
 <Zhx0FJ0ASFHvgm9Pog3_JKujJalkMr4ooO4vbszXr94=.0008c633-68e5-4bf5-a742-45c46c8391f4@github.com>
Message-ID: <X_KECktt546X32fPGXAAIEflPZOLJ2S0Y8rODWGxO9g=.e23f0e64-b6b0-45f6-b063-6917a36f135d@github.com>

On Wed, 3 Aug 2022 18:25:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This bug is being produced because as the diamond expression can't be attributed until the inference has been done. A listener is registered in the corresponding inference context but the way the current environment is being copied into `dupLocalEnv` produces a copy that shares info with the outer lambda expression. The lambda expression removes the argument from the shared scope before the listener is fired and thus the error. The proposal is to use a different way to copy the environment into `dupLocalEnv` by producing a brand new scope.
>> 
>> TIA
>
> Looks reasonable to me.

thanks for the review @lahodaj

-------------

PR: https://git.openjdk.org/jdk/pull/9710

From vromero at openjdk.org  Wed Aug  3 19:48:19 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Aug 2022 19:48:19 GMT
Subject: Integrated: 8260892: Compilation fails: lambda parameter not visible
 in body when generics involved
In-Reply-To: <PC8-SgHh4s-d_qpfRpZsav13FCU_9S-d4EatM422HVQ=.d7daf2c9-19c8-4d52-bf99-b97bf9633194@github.com>
References: <PC8-SgHh4s-d_qpfRpZsav13FCU_9S-d4EatM422HVQ=.d7daf2c9-19c8-4d52-bf99-b97bf9633194@github.com>
Message-ID: <l6YmqEqEfh0Bd2rCzzbzTvfvAVFJ5V-RtzCerYZmQ4M=.5d27aea2-90d9-4f7e-928a-440fe19a1b0a@github.com>

On Mon, 1 Aug 2022 23:37:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This bug is being produced because as the diamond expression can't be attributed until the inference has been done. A listener is registered in the corresponding inference context but the way the current environment is being copied into `dupLocalEnv` produces a copy that shares info with the outer lambda expression. The lambda expression removes the argument from the shared scope before the listener is fired and thus the error. The proposal is to use a different way to copy the environment into `dupLocalEnv` by producing a brand new scope.
> 
> TIA

This pull request has now been integrated.

Changeset: 67f00118
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67f001186b66b9fcbc9156012d1eec2ae5d45d8b
Stats:     52 lines in 2 files changed: 51 ins; 0 del; 1 mod

8260892: Compilation fails: lambda parameter not visible in body when generics involved

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/9710

From jlahoda at openjdk.org  Thu Aug  4 13:31:11 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Aug 2022 13:31:11 GMT
Subject: RFR: 8285935: Spurious lint warning for static method accessed
 through instance qualifier [v2]
In-Reply-To: <vLfaWPILKl1h_2X3RBuc24SrUMrHeuleg8LuQMEZniQ=.37a6631c-4ea5-480f-8dbb-8b3ad7e51da8@github.com>
References: <qYH89lnOxAYYDxfbftLTopYv69Uf7l-w_KglLORzgeM=.33e96f4e-e9a9-4b9c-bea9-65665ede25df@github.com>
 <vLfaWPILKl1h_2X3RBuc24SrUMrHeuleg8LuQMEZniQ=.37a6631c-4ea5-480f-8dbb-8b3ad7e51da8@github.com>
Message-ID: <_qni1Q1r5WdEXqv31AWqRxTZ14lxDl2wLQY0bhWRTt8=.a96d063e-58a0-41d5-bd5e-11d36f22d1d8@github.com>

On Wed, 3 Aug 2022 19:38:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this simple fix which is adding a more precise, I hope, warning for the case when a static method or field is being accessed using an anonymous class instance.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating the warning message text

Seems OK to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9521

From jlahoda at openjdk.org  Thu Aug  4 15:04:52 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Aug 2022 15:04:52 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved
Message-ID: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>

This is an attempt to improve the performance and scalability of switches with record patterns.

There are two main parts of this patch:
1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:

switch (obj) {
     case Box(String s) -> {}
     case Box(Integer i) -> {}
     case Box(Number n) -> {}
     ...
}
=>
switch (obj) {
     case Box b ->
          switch (b.o()) {
              case String s -> {}
              case Integer i -> {}
              case Number n -> {}
              default -> continue-with-outer-switch;
          };
    ...
}


This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.

2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.

I ran the new code through a JMH benchmark:
[PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)

The results are:
 - for "long" testcase (a switch with many cases):

PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s

 - for "short" testcase (a switch with no so many cases):

PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s


So, the performance seems to be improved, at least in these cases.

As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).

-------------

Commit messages:
 - 8291769: Translation of switch with record patterns could be improved

Changes: https://git.openjdk.org/jdk/pull/9746/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291769
  Stats: 1327 lines in 12 files changed: 1157 ins; 74 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/9746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9746/head:pull/9746

PR: https://git.openjdk.org/jdk/pull/9746

From forax at univ-mlv.fr  Thu Aug  4 15:43:37 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 4 Aug 2022 17:43:37 +0200 (CEST)
Subject: RFR: 8291769: Translation of switch with record patterns could
 be improved
In-Reply-To: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
Message-ID: <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>



----- Original Message -----
> From: "Jan Lahoda" <jlahoda at openjdk.org>
> To: compiler-dev at openjdk.org
> Sent: Thursday, August 4, 2022 5:04:52 PM
> Subject: RFR: 8291769: Translation of switch with record patterns could be improved

> This is an attempt to improve the performance and scalability of switches with
> record patterns.
> 
> There are two main parts of this patch:
> 1. for cases of consecutive runs of cases with the same record pattern, these
> are replaced with a single case and a nested switch. E.g.:
> 
> switch (obj) {
>     case Box(String s) -> {}
>     case Box(Integer i) -> {}
>     case Box(Number n) -> {}
>     ...
> }
> =>
> switch (obj) {
>     case Box b ->
>          switch (b.o()) {
>              case String s -> {}
>              case Integer i -> {}
>              case Number n -> {}
>              default -> continue-with-outer-switch;
>          };
>    ...
> }
> 
> 
> This is done by first unrolling the record patterns into simple binding patterns
> a guards, and then by finding cases with the common binding pattern as a label
> and a viable guard. Binding patterns are reused as much as possibly,
> eliminating specialized handling of record patterns as much as possible.

How it works when you have a record pattern followed by a type pattern with the same type ?
Something like:

  switch (obj) {
    case Box(String s) -> {}
    case Box(Integer i) -> {}
    
    case Box b -> {}
  }

because you now have twice the same type pattern on the outer switch but the first one should not NPE.


> 
> 2. When a record accessor method fails with an exception, we need to wrap this
> exception with a `MatchException`. Currently this is being done by introducing
> a special proxy method which catches the exception and re-throws. The proposed
> patch here eliminates the need for the accessor methods by producing an
> appropriate `ExceptionTable` in the classfile, and a separate catch handler.
> This handler is attached to the innermost usable block, which is either the
> method block, lambda body, (static or non-static) initializer or a try block.
> This should ensure correct semantics, while not producing too many unnecessary
> catch handlers.

Yes !

As said above, the semantics for null is slightly changed, because now you may throw a NPE instead of a MatchException.
You can add explicit nullchecks to throw a MatchException instead but i think we can do better for our users.

I believe that with this transformation, we can now make the difference between the 3 kinds of errors,
- the call to the accessor / destructor fails throwing an error similar to ExceptionInTheInitializerError (ExceptionInTheDestructorError ?)
- the tested value is null throwing a NPE because most of them are implicit when b.o() is called. This means that the compiler has to insert a requireNonNull if the nullcheck is not implicit.
- when there are more permitted subtypes at runtime throwing an IncompatibleClassChangeError (like with an switch expression on an enum)

for the last one, the idea is that if there is a sealed type, instead of generating an if instanceof for all cases, the last one should not be an instanceof but just a cast with a cacth handler that catch the ClassCastException and throw an IncompatibleClassChangeError wrapping the CCE instead.

R?mi

From vromero at openjdk.org  Thu Aug  4 16:17:05 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Aug 2022 16:17:05 GMT
Subject: RFR: JDK-8289249: Add methods to Elements for record constructors
In-Reply-To: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>
References: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>
Message-ID: <FHT_KX8D2jd0d3ZJkWpF9o0h35O4B1bIqR_m3g01YTw=.e53c1152-886b-4158-b505-fbae0f4e28d5@github.com>

On Sun, 31 Jul 2022 02:43:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the addition of two predicates to better support records in the javax.lang.model API.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8291594

looks good to me

test/langtools/tools/javac/processing/model/util/elements/TestRecordPredicates.java line 110:

> 108:     }
> 109: 
> 110:     @ExpectedPredicates(isCompact=true, isCanonical=true)

side: this is uncovering a bug in the compiler, isCanonical should be false in this case. I have filed JDK-8291914 to address this issue

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9694

From jlahoda at openjdk.org  Thu Aug  4 16:21:26 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Aug 2022 16:21:26 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v2]
In-Reply-To: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
Message-ID: <F-00Crb3_hSpiqLH_AN6q944axxoXhFw3ldxSj8lbN4=.54272bb6-752c-4f70-a6e0-a43de64aa38e@github.com>

> This is an attempt to improve the performance and scalability of switches with record patterns.
> 
> There are two main parts of this patch:
> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
> 
> switch (obj) {
>      case Box(String s) -> {}
>      case Box(Integer i) -> {}
>      case Box(Number n) -> {}
>      ...
> }
> =>
> switch (obj) {
>      case Box b ->
>           switch (b.o()) {
>               case String s -> {}
>               case Integer i -> {}
>               case Number n -> {}
>               default -> continue-with-outer-switch;
>           };
>     ...
> }
> 
> 
> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
> 
> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
> 
> I ran the new code through a JMH benchmark:
> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
> 
> The results are:
>  - for "long" testcase (a switch with many cases):
> 
> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
> 
>  - for "short" testcase (a switch with no so many cases):
> 
> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
> 
> 
> So, the performance seems to be improved, at least in these cases.
> 
> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Properly handle null record components.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9746/files
  - new: https://git.openjdk.org/jdk/pull/9746/files/9633a128..7ddeafab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=00-01

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9746/head:pull/9746

PR: https://git.openjdk.org/jdk/pull/9746

From jan.lahoda at oracle.com  Thu Aug  4 16:35:18 2022
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 4 Aug 2022 18:35:18 +0200
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved
In-Reply-To: <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
Message-ID: <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>

On 04. 08. 22 17:43, Remi Forax wrote:

>
> ----- Original Message -----
>> From: "Jan Lahoda" <jlahoda at openjdk.org>
>> To: compiler-dev at openjdk.org
>> Sent: Thursday, August 4, 2022 5:04:52 PM
>> Subject: RFR: 8291769: Translation of switch with record patterns could be improved
>> This is an attempt to improve the performance and scalability of switches with
>> record patterns.
>>
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these
>> are replaced with a single case and a nested switch. E.g.:
>>
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>>
>>
>> This is done by first unrolling the record patterns into simple binding patterns
>> a guards, and then by finding cases with the common binding pattern as a label
>> and a viable guard. Binding patterns are reused as much as possibly,
>> eliminating specialized handling of record patterns as much as possible.
> How it works when you have a record pattern followed by a type pattern with the same type ?
> Something like:
>
>    switch (obj) {
>      case Box(String s) -> {}
>      case Box(Integer i) -> {}
>      
>      case Box b -> {}
>    }
>
> because you now have twice the same type pattern on the outer switch but the first one should not NPE.


Currently the `case Box b -> {}` is kept separate. It would be possible 
to merge (it would simply be a default in the nested switch), but it is 
an additional complexity in a fairly complex code already.


>
>
>> 2. When a record accessor method fails with an exception, we need to wrap this
>> exception with a `MatchException`. Currently this is being done by introducing
>> a special proxy method which catches the exception and re-throws. The proposed
>> patch here eliminates the need for the accessor methods by producing an
>> appropriate `ExceptionTable` in the classfile, and a separate catch handler.
>> This handler is attached to the innermost usable block, which is either the
>> method block, lambda body, (static or non-static) initializer or a try block.
>> This should ensure correct semantics, while not producing too many unnecessary
>> catch handlers.
> Yes !
>
> As said above, the semantics for null is slightly changed, because now you may throw a NPE instead of a MatchException.


The idea here is that the semantics should not be changed, and changes 
to semantics are bugs. But thanks to your comment, I realized null 
record components are not handled properly, so I've attempted to fix that:

https://github.com/openjdk/jdk/pull/9746/commits/7ddeafab1d1ea23285e60765ec0e61d7a509e442


> You can add explicit nullchecks to throw a MatchException instead but i think we can do better for our users.
>
> I believe that with this transformation, we can now make the difference between the 3 kinds of errors,
> - the call to the accessor / destructor fails throwing an error similar to ExceptionInTheInitializerError (ExceptionInTheDestructorError ?)
> - the tested value is null throwing a NPE because most of them are implicit when b.o() is called. This means that the compiler has to insert a requireNonNull if the nullcheck is not implicit.
> - when there are more permitted subtypes at runtime throwing an IncompatibleClassChangeError (like with an switch expression on an enum)


(FWIW, I believe the spec is saying what should happen in specific 
cases, so I don't think this is something javac should decide on its 
own. javac can decide on how the behavior is implemented, but not the 
behavior.)


>
> for the last one, the idea is that if there is a sealed type, instead of generating an if instanceof for all cases, the last one should not be an instanceof but just a cast with a cacth handler that catch the ClassCastException and throw an IncompatibleClassChangeError wrapping the CCE instead.


Note that when switching over a type we don't generate instanceof for 
the subtypes of that type. The typeSwitch bootstrap/indy does the 
checks, and the bytecode produced by javac only produces checkcasts. (It 
may produce instanceofs for the nested patterns, though.) It would be 
possible to use a default instead of the last case, and add catch 
handler for the checkcast, but generating cases for all the checked 
types, and adding a default which throws (which I believe is the current 
implementation) feels much easier and cleaner to implement, and I don't 
really see a significant disadvantage in that.


Thanks,

 ??? Jan


>
> R?mi

From forax at univ-mlv.fr  Thu Aug  4 17:13:41 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 4 Aug 2022 19:13:41 +0200 (CEST)
Subject: RFR: 8291769: Translation of switch with record patterns could
 be improved
In-Reply-To: <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
Message-ID: <1613563570.18665378.1659633221821.JavaMail.zimbra@u-pem.fr>



----- Original Message -----
> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Thursday, August 4, 2022 6:35:18 PM
> Subject: Re: RFR: 8291769: Translation of switch with record patterns could be improved

> On 04. 08. 22 17:43, Remi Forax wrote:
> 
>>
>> ----- Original Message -----
>>> From: "Jan Lahoda" <jlahoda at openjdk.org>
>>> To: compiler-dev at openjdk.org
>>> Sent: Thursday, August 4, 2022 5:04:52 PM
>>> Subject: RFR: 8291769: Translation of switch with record patterns could be
>>> improved
>>> This is an attempt to improve the performance and scalability of switches with
>>> record patterns.
>>>
>>> There are two main parts of this patch:
>>> 1. for cases of consecutive runs of cases with the same record pattern, these
>>> are replaced with a single case and a nested switch. E.g.:
>>>
>>> switch (obj) {
>>>      case Box(String s) -> {}
>>>      case Box(Integer i) -> {}
>>>      case Box(Number n) -> {}
>>>      ...
>>> }
>>> =>
>>> switch (obj) {
>>>      case Box b ->
>>>           switch (b.o()) {
>>>               case String s -> {}
>>>               case Integer i -> {}
>>>               case Number n -> {}
>>>               default -> continue-with-outer-switch;
>>>           };
>>>     ...
>>> }
>>>
>>>
>>> This is done by first unrolling the record patterns into simple binding patterns
>>> a guards, and then by finding cases with the common binding pattern as a label
>>> and a viable guard. Binding patterns are reused as much as possibly,
>>> eliminating specialized handling of record patterns as much as possible.
>> How it works when you have a record pattern followed by a type pattern with the
>> same type ?
>> Something like:
>>
>>    switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      
>>      case Box b -> {}
>>    }
>>
>> because you now have twice the same type pattern on the outer switch but the
>> first one should not NPE.
> 
> 
> Currently the `case Box b -> {}` is kept separate. It would be possible
> to merge (it would simply be a default in the nested switch), but it is
> an additional complexity in a fairly complex code already.

so depending on how a user write a switch, performance are different,
for example, with I a sealed type and A and B to subtype storing a field of type I

    switch (i) {
      case A(A a) -> {}
      case A(B b) -> {}
      case B(A a) -> {}
      case B(B b) -> {}
    }

vs

    switch (i) {
      case A(A a) -> {}
      case B(A a) -> {}
      case A(B b) -> {}
      case B(B b) -> {}
    }

that does not seem to be a good property for a desugaring, or i miss something ?

R?mi

From forax at univ-mlv.fr  Thu Aug  4 17:23:07 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 4 Aug 2022 19:23:07 +0200 (CEST)
Subject: RFR: 8291769: Translation of switch with record patterns could
 be improved
In-Reply-To: <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
Message-ID: <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>



----- Original Message -----
> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Thursday, August 4, 2022 6:35:18 PM
> Subject: Re: RFR: 8291769: Translation of switch with record patterns could be improved

> On 04. 08. 22 17:43, Remi Forax wrote:
> 
>>
>> ----- Original Message -----
>>> From: "Jan Lahoda" <jlahoda at openjdk.org>
>>> To: compiler-dev at openjdk.org
>>> Sent: Thursday, August 4, 2022 5:04:52 PM
>>> Subject: RFR: 8291769: Translation of switch with record patterns could be
>>> improved
>>> This is an attempt to improve the performance and scalability of switches with
>>> record patterns.
>>>
>>> There are two main parts of this patch:
>>> 1. for cases of consecutive runs of cases with the same record pattern, these
>>> are replaced with a single case and a nested switch. E.g.:
>>>
>>> switch (obj) {
>>>      case Box(String s) -> {}
>>>      case Box(Integer i) -> {}
>>>      case Box(Number n) -> {}
>>>      ...
>>> }
>>> =>
>>> switch (obj) {
>>>      case Box b ->
>>>           switch (b.o()) {
>>>               case String s -> {}
>>>               case Integer i -> {}
>>>               case Number n -> {}
>>>               default -> continue-with-outer-switch;
>>>           };
>>>     ...
>>> }
>>>
>>>
>>> This is done by first unrolling the record patterns into simple binding patterns
>>> a guards, and then by finding cases with the common binding pattern as a label
>>> and a viable guard. Binding patterns are reused as much as possibly,
>>> eliminating specialized handling of record patterns as much as possible.
>> How it works when you have a record pattern followed by a type pattern with the
>> same type ?
>> Something like:
>>
>>    switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      
>>      case Box b -> {}
>>    }
>>
>> because you now have twice the same type pattern on the outer switch but the
>> first one should not NPE.
> 
> 
> Currently the `case Box b -> {}` is kept separate. It would be possible
> to merge (it would simply be a default in the nested switch), but it is
> an additional complexity in a fairly complex code already.
> 
> 
>>
>>
>>> 2. When a record accessor method fails with an exception, we need to wrap this
>>> exception with a `MatchException`. Currently this is being done by introducing
>>> a special proxy method which catches the exception and re-throws. The proposed
>>> patch here eliminates the need for the accessor methods by producing an
>>> appropriate `ExceptionTable` in the classfile, and a separate catch handler.
>>> This handler is attached to the innermost usable block, which is either the
>>> method block, lambda body, (static or non-static) initializer or a try block.
>>> This should ensure correct semantics, while not producing too many unnecessary
>>> catch handlers.
>> Yes !
>>
>> As said above, the semantics for null is slightly changed, because now you may
>> throw a NPE instead of a MatchException.
> 
> 
> The idea here is that the semantics should not be changed, and changes
> to semantics are bugs. But thanks to your comment, I realized null
> record components are not handled properly, so I've attempted to fix that:
> 
> https://github.com/openjdk/jdk/pull/9746/commits/7ddeafab1d1ea23285e60765ec0e61d7a509e442
> 
> 
>> You can add explicit nullchecks to throw a MatchException instead but i think we
>> can do better for our users.
>>
>> I believe that with this transformation, we can now make the difference between
>> the 3 kinds of errors,
>> - the call to the accessor / destructor fails throwing an error similar to
>> ExceptionInTheInitializerError (ExceptionInTheDestructorError ?)
>> - the tested value is null throwing a NPE because most of them are implicit when
>> b.o() is called. This means that the compiler has to insert a requireNonNull if
>> the nullcheck is not implicit.
>> - when there are more permitted subtypes at runtime throwing an
>> IncompatibleClassChangeError (like with an switch expression on an enum)
> 
> 
> (FWIW, I believe the spec is saying what should happen in specific
> cases, so I don't think this is something javac should decide on its
> own. javac can decide on how the behavior is implemented, but not the
> behavior.)

yes, i want to change the spec because as a user it's hard to know how to fix the code when a MatchException is thrown.

> 
> 
>>
>> for the last one, the idea is that if there is a sealed type, instead of
>> generating an if instanceof for all cases, the last one should not be an
>> instanceof but just a cast with a cacth handler that catch the
>> ClassCastException and throw an IncompatibleClassChangeError wrapping the CCE
>> instead.
> 
> 
> Note that when switching over a type we don't generate instanceof for
> the subtypes of that type. The typeSwitch bootstrap/indy does the
> checks, and the bytecode produced by javac only produces checkcasts. (It
> may produce instanceofs for the nested patterns, though.) It would be
> possible to use a default instead of the last case, and add catch
> handler for the checkcast, but generating cases for all the checked
> types, and adding a default which throws (which I believe is the current
> implementation) feels much easier and cleaner to implement, and I don't
> really see a significant disadvantage in that.

It's a performance issue because you need to recheck the same type pattern multiple times if the switch alternate a record pattern followed by a type pattern followed by a record pattern ...

> 
> 
> Thanks,
> 
> ??? Jan
> 
> 

R?mi


From vromero at openjdk.org  Thu Aug  4 18:13:12 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Aug 2022 18:13:12 GMT
Subject: RFR: 8285935: Spurious lint warning for static method accessed
 through instance qualifier [v2]
In-Reply-To: <_qni1Q1r5WdEXqv31AWqRxTZ14lxDl2wLQY0bhWRTt8=.a96d063e-58a0-41d5-bd5e-11d36f22d1d8@github.com>
References: <qYH89lnOxAYYDxfbftLTopYv69Uf7l-w_KglLORzgeM=.33e96f4e-e9a9-4b9c-bea9-65665ede25df@github.com>
 <vLfaWPILKl1h_2X3RBuc24SrUMrHeuleg8LuQMEZniQ=.37a6631c-4ea5-480f-8dbb-8b3ad7e51da8@github.com>
 <_qni1Q1r5WdEXqv31AWqRxTZ14lxDl2wLQY0bhWRTt8=.a96d063e-58a0-41d5-bd5e-11d36f22d1d8@github.com>
Message-ID: <Kw3uooVwZsB_afjVBjsW4dOLwqcYtdcY205Y1-u3AXk=.d1eea76e-952f-4e7c-bbe6-ca51a9879bad@github.com>

On Thu, 4 Aug 2022 13:28:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updating the warning message text
>
> Seems OK to me.

@lahodaj thanks for the review

-------------

PR: https://git.openjdk.org/jdk/pull/9521

From vromero at openjdk.org  Thu Aug  4 18:13:13 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Aug 2022 18:13:13 GMT
Subject: Integrated: 8285935: Spurious lint warning for static method accessed
 through instance qualifier
In-Reply-To: <qYH89lnOxAYYDxfbftLTopYv69Uf7l-w_KglLORzgeM=.33e96f4e-e9a9-4b9c-bea9-65665ede25df@github.com>
References: <qYH89lnOxAYYDxfbftLTopYv69Uf7l-w_KglLORzgeM=.33e96f4e-e9a9-4b9c-bea9-65665ede25df@github.com>
Message-ID: <8Sotox6vtOu0FeZwsbMpxZ9iRhbOgK0kc8cKvzSMfsw=.1ff2c29c-fd41-4f03-b658-f71ac61b5c74@github.com>

On Fri, 15 Jul 2022 17:10:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix which is adding a more precise, I hope, warning for the case when a static method or field is being accessed using an anonymous class instance.
> 
> TIA

This pull request has now been integrated.

Changeset: 3ba31716
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ba317167d24b6ed478418a2abae9042ab2764f1
Stats:     33 lines in 6 files changed: 29 ins; 0 del; 4 mod

8285935: Spurious lint warning for static method accessed through instance qualifier

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/9521

From jan.lahoda at oracle.com  Thu Aug  4 20:10:06 2022
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 4 Aug 2022 22:10:06 +0200
Subject: [External] : Re: RFR: 8291769: Translation of switch with record
 patterns could be improved
In-Reply-To: <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
Message-ID: <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>

On 04. 08. 22 19:23, forax at univ-mlv.fr wrote:

>
> ----- Original Message -----
>> From: "jan lahoda" <jan.lahoda at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>, "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>
>> Cc: "compiler-dev" <compiler-dev at openjdk.org>
>> Sent: Thursday, August 4, 2022 6:35:18 PM
>> Subject: Re: RFR: 8291769: Translation of switch with record patterns could be improved
>> On 04. 08. 22 17:43, Remi Forax wrote:
>>
>>> ----- Original Message -----
>>>> From: "Jan Lahoda" <jlahoda at openjdk.org>
>>>> To: compiler-dev at openjdk.org
>>>> Sent: Thursday, August 4, 2022 5:04:52 PM
>>>> Subject: RFR: 8291769: Translation of switch with record patterns could be
>>>> improved
>>>> This is an attempt to improve the performance and scalability of switches with
>>>> record patterns.
>>>>
>>>> There are two main parts of this patch:
>>>> 1. for cases of consecutive runs of cases with the same record pattern, these
>>>> are replaced with a single case and a nested switch. E.g.:
>>>>
>>>> switch (obj) {
>>>>       case Box(String s) -> {}
>>>>       case Box(Integer i) -> {}
>>>>       case Box(Number n) -> {}
>>>>       ...
>>>> }
>>>> =>
>>>> switch (obj) {
>>>>       case Box b ->
>>>>            switch (b.o()) {
>>>>                case String s -> {}
>>>>                case Integer i -> {}
>>>>                case Number n -> {}
>>>>                default -> continue-with-outer-switch;
>>>>            };
>>>>      ...
>>>> }
>>>>
>>>>
>>>> This is done by first unrolling the record patterns into simple binding patterns
>>>> a guards, and then by finding cases with the common binding pattern as a label
>>>> and a viable guard. Binding patterns are reused as much as possibly,
>>>> eliminating specialized handling of record patterns as much as possible.
>>> How it works when you have a record pattern followed by a type pattern with the
>>> same type ?
>>> Something like:
>>>
>>>     switch (obj) {
>>>       case Box(String s) -> {}
>>>       case Box(Integer i) -> {}
>>>       
>>>       case Box b -> {}
>>>     }
>>>
>>> because you now have twice the same type pattern on the outer switch but the
>>> first one should not NPE.
>>
>> Currently the `case Box b -> {}` is kept separate. It would be possible
>> to merge (it would simply be a default in the nested switch), but it is
>> an additional complexity in a fairly complex code already.
>>
>>
>>>
>>>> 2. When a record accessor method fails with an exception, we need to wrap this
>>>> exception with a `MatchException`. Currently this is being done by introducing
>>>> a special proxy method which catches the exception and re-throws. The proposed
>>>> patch here eliminates the need for the accessor methods by producing an
>>>> appropriate `ExceptionTable` in the classfile, and a separate catch handler.
>>>> This handler is attached to the innermost usable block, which is either the
>>>> method block, lambda body, (static or non-static) initializer or a try block.
>>>> This should ensure correct semantics, while not producing too many unnecessary
>>>> catch handlers.
>>> Yes !
>>>
>>> As said above, the semantics for null is slightly changed, because now you may
>>> throw a NPE instead of a MatchException.
>>
>> The idea here is that the semantics should not be changed, and changes
>> to semantics are bugs. But thanks to your comment, I realized null
>> record components are not handled properly, so I've attempted to fix that:
>>
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9746/commits/7ddeafab1d1ea23285e60765ec0e61d7a509e442__;!!ACWV5N9M2RV99hQ!ILgm-CykKXhL7fJ8n8zqHYDrHshMWU9tnE836sT6jAqJVoQZnExXgSxUax5NhJvl3XzSqgJzPPzm_1SYQYk$
>>
>>
>>> You can add explicit nullchecks to throw a MatchException instead but i think we
>>> can do better for our users.
>>>
>>> I believe that with this transformation, we can now make the difference between
>>> the 3 kinds of errors,
>>> - the call to the accessor / destructor fails throwing an error similar to
>>> ExceptionInTheInitializerError (ExceptionInTheDestructorError ?)
>>> - the tested value is null throwing a NPE because most of them are implicit when
>>> b.o() is called. This means that the compiler has to insert a requireNonNull if
>>> the nullcheck is not implicit.
>>> - when there are more permitted subtypes at runtime throwing an
>>> IncompatibleClassChangeError (like with an switch expression on an enum)
>>
>> (FWIW, I believe the spec is saying what should happen in specific
>> cases, so I don't think this is something javac should decide on its
>> own. javac can decide on how the behavior is implemented, but not the
>> behavior.)
> yes, i want to change the spec because as a user it's hard to know how to fix the code when a MatchException is thrown.

Sure - but I am not quite sure if this PR is a place to discuss that.


>
>>
>>> for the last one, the idea is that if there is a sealed type, instead of
>>> generating an if instanceof for all cases, the last one should not be an
>>> instanceof but just a cast with a cacth handler that catch the
>>> ClassCastException and throw an IncompatibleClassChangeError wrapping the CCE
>>> instead.
>>
>> Note that when switching over a type we don't generate instanceof for
>> the subtypes of that type. The typeSwitch bootstrap/indy does the
>> checks, and the bytecode produced by javac only produces checkcasts. (It
>> may produce instanceofs for the nested patterns, though.) It would be
>> possible to use a default instead of the last case, and add catch
>> handler for the checkcast, but generating cases for all the checked
>> types, and adding a default which throws (which I believe is the current
>> implementation) feels much easier and cleaner to implement, and I don't
>> really see a significant disadvantage in that.
> It's a performance issue because you need to recheck the same type pattern multiple times if the switch alternate a record pattern followed by a type pattern followed by a record pattern ...


I assume you are referring to the following case, not to a case where we 
would be catching ClassCastExceptions:

case Box(String s) -> {}

case Box b -> {}


It is true there will (likely) be one more instanceof at runtime, and we 
could avoid this at the cost of an additional complexity in javac.


If the record pattern and type pattern would alternate multiple times, 
that would (I think) require the type patterns to have guards. Like:

case Box(String s) -> {}

case Box b when guard1(b) -> {}

case Box(Integer i) -> {}

case Box b when guard2(b) -> {}

...


Optimizing this is even more challenging, as we would need to preserve 
the order.


In any case, I'm a bit afraid that we could enhance a translation patch 
forever, always adding new cases that can be optimized. So, I think we 
need to draw a line somewhere where the patch provides a benefit while 
still being testable and reviewable. With a possible separate 
improvements, if they prove to be useful. It is possible I haven't drawn 
the line far enough, but looking at the patch, it seems complex enough.


Thanks,

 ??? Jan


>
>>
>> Thanks,
>>
>>  ??? Jan
>>
>>
> R?mi
>

From jlahoda at openjdk.org  Fri Aug  5 13:51:51 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Aug 2022 13:51:51 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v3]
In-Reply-To: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
Message-ID: <aoBpIxW7ZSErqezUcfyVhwFLKxvg_Kj8-xSzEro8lBg=.b585ff3e-a769-4751-8325-87979ac2a766@github.com>

> This is an attempt to improve the performance and scalability of switches with record patterns.
> 
> There are two main parts of this patch:
> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
> 
> switch (obj) {
>      case Box(String s) -> {}
>      case Box(Integer i) -> {}
>      case Box(Number n) -> {}
>      ...
> }
> =>
> switch (obj) {
>      case Box b ->
>           switch (b.o()) {
>               case String s -> {}
>               case Integer i -> {}
>               case Number n -> {}
>               default -> continue-with-outer-switch;
>           };
>     ...
> }
> 
> 
> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
> 
> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
> 
> I ran the new code through a JMH benchmark:
> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
> 
> The results are:
>  - for "long" testcase (a switch with many cases):
> 
> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
> 
>  - for "short" testcase (a switch with no so many cases):
> 
> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
> 
> 
> So, the performance seems to be improved, at least in these cases.
> 
> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9746/files
  - new: https://git.openjdk.org/jdk/pull/9746/files/7ddeafab..e842486d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=01-02

  Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9746/head:pull/9746

PR: https://git.openjdk.org/jdk/pull/9746

From jjg at openjdk.org  Fri Aug  5 16:47:03 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 Aug 2022 16:47:03 GMT
Subject: RFR: JDK-8289249: Add methods to Elements for record constructors
In-Reply-To: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>
References: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>
Message-ID: <5W9ug9wRkmGjv9fvKxbDvHd9FqpL3LRiILRBODVMKQs=.f9373998-4b07-4177-b76e-2061647ea683@github.com>

On Sun, 31 Jul 2022 02:43:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the addition of two predicates to better support records in the javax.lang.model API.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8291594

Generally, when we specify an `@implNote` for a default method that is a "do-nothing-helpful" method, we should find a place or way to document the useful implementation of the method.

-------------

PR: https://git.openjdk.org/jdk/pull/9694

From forax at univ-mlv.fr  Fri Aug  5 17:24:01 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 5 Aug 2022 19:24:01 +0200 (CEST)
Subject: [External] : Re: RFR: 8291769: Translation of switch with
 record patterns could be improved
In-Reply-To: <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
Message-ID: <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>



----- Original Message -----
> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>, "compiler-dev"
> <compiler-dev at openjdk.org>
> Sent: Thursday, August 4, 2022 10:10:06 PM
> Subject: Re: [External] : Re: RFR: 8291769: Translation of switch with record patterns could be improved

> On 04. 08. 22 19:23, forax at univ-mlv.fr wrote:
> 
>>
>> ----- Original Message -----
>>> From: "jan lahoda" <jan.lahoda at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>, "Jan Lahoda" <jlahoda at openjdk.org>, "Brian
>>> Goetz" <brian.goetz at oracle.com>
>>> Cc: "compiler-dev" <compiler-dev at openjdk.org>
>>> Sent: Thursday, August 4, 2022 6:35:18 PM
>>> Subject: Re: RFR: 8291769: Translation of switch with record patterns could be
>>> improved
>>> On 04. 08. 22 17:43, Remi Forax wrote:
>>>
>>>> ----- Original Message -----
>>>>> From: "Jan Lahoda" <jlahoda at openjdk.org>
>>>>> To: compiler-dev at openjdk.org
>>>>> Sent: Thursday, August 4, 2022 5:04:52 PM
>>>>> Subject: RFR: 8291769: Translation of switch with record patterns could be
>>>>> improved
>>>>> This is an attempt to improve the performance and scalability of switches with
>>>>> record patterns.
>>>>>
>>>>> There are two main parts of this patch:
>>>>> 1. for cases of consecutive runs of cases with the same record pattern, these
>>>>> are replaced with a single case and a nested switch. E.g.:
>>>>>
>>>>> switch (obj) {
>>>>>       case Box(String s) -> {}
>>>>>       case Box(Integer i) -> {}
>>>>>       case Box(Number n) -> {}
>>>>>       ...
>>>>> }
>>>>> =>
>>>>> switch (obj) {
>>>>>       case Box b ->
>>>>>            switch (b.o()) {
>>>>>                case String s -> {}
>>>>>                case Integer i -> {}
>>>>>                case Number n -> {}
>>>>>                default -> continue-with-outer-switch;
>>>>>            };
>>>>>      ...
>>>>> }
>>>>>
>>>>>
>>>>> This is done by first unrolling the record patterns into simple binding patterns
>>>>> a guards, and then by finding cases with the common binding pattern as a label
>>>>> and a viable guard. Binding patterns are reused as much as possibly,
>>>>> eliminating specialized handling of record patterns as much as possible.
>>>> How it works when you have a record pattern followed by a type pattern with the
>>>> same type ?
>>>> Something like:
>>>>
>>>>     switch (obj) {
>>>>       case Box(String s) -> {}
>>>>       case Box(Integer i) -> {}
>>>>       
>>>>       case Box b -> {}
>>>>     }
>>>>
>>>> because you now have twice the same type pattern on the outer switch but the
>>>> first one should not NPE.
>>>
>>> Currently the `case Box b -> {}` is kept separate. It would be possible
>>> to merge (it would simply be a default in the nested switch), but it is
>>> an additional complexity in a fairly complex code already.
>>>
>>>
>>>>
>>>>> 2. When a record accessor method fails with an exception, we need to wrap this
>>>>> exception with a `MatchException`. Currently this is being done by introducing
>>>>> a special proxy method which catches the exception and re-throws. The proposed
>>>>> patch here eliminates the need for the accessor methods by producing an
>>>>> appropriate `ExceptionTable` in the classfile, and a separate catch handler.
>>>>> This handler is attached to the innermost usable block, which is either the
>>>>> method block, lambda body, (static or non-static) initializer or a try block.
>>>>> This should ensure correct semantics, while not producing too many unnecessary
>>>>> catch handlers.
>>>> Yes !
>>>>
>>>> As said above, the semantics for null is slightly changed, because now you may
>>>> throw a NPE instead of a MatchException.
>>>
>>> The idea here is that the semantics should not be changed, and changes
>>> to semantics are bugs. But thanks to your comment, I realized null
>>> record components are not handled properly, so I've attempted to fix that:
>>>
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9746/commits/7ddeafab1d1ea23285e60765ec0e61d7a509e442__;!!ACWV5N9M2RV99hQ!ILgm-CykKXhL7fJ8n8zqHYDrHshMWU9tnE836sT6jAqJVoQZnExXgSxUax5NhJvl3XzSqgJzPPzm_1SYQYk$
>>>
>>>
>>>> You can add explicit nullchecks to throw a MatchException instead but i think we
>>>> can do better for our users.
>>>>
>>>> I believe that with this transformation, we can now make the difference between
>>>> the 3 kinds of errors,
>>>> - the call to the accessor / destructor fails throwing an error similar to
>>>> ExceptionInTheInitializerError (ExceptionInTheDestructorError ?)
>>>> - the tested value is null throwing a NPE because most of them are implicit when
>>>> b.o() is called. This means that the compiler has to insert a requireNonNull if
>>>> the nullcheck is not implicit.
>>>> - when there are more permitted subtypes at runtime throwing an
>>>> IncompatibleClassChangeError (like with an switch expression on an enum)
>>>
>>> (FWIW, I believe the spec is saying what should happen in specific
>>> cases, so I don't think this is something javac should decide on its
>>> own. javac can decide on how the behavior is implemented, but not the
>>> behavior.)
>> yes, i want to change the spec because as a user it's hard to know how to fix
>> the code when a MatchException is thrown.
> 
> Sure - but I am not quite sure if this PR is a place to discuss that.
> 
> 
>>
>>>
>>>> for the last one, the idea is that if there is a sealed type, instead of
>>>> generating an if instanceof for all cases, the last one should not be an
>>>> instanceof but just a cast with a cacth handler that catch the
>>>> ClassCastException and throw an IncompatibleClassChangeError wrapping the CCE
>>>> instead.
>>>
>>> Note that when switching over a type we don't generate instanceof for
>>> the subtypes of that type. The typeSwitch bootstrap/indy does the
>>> checks, and the bytecode produced by javac only produces checkcasts. (It
>>> may produce instanceofs for the nested patterns, though.) It would be
>>> possible to use a default instead of the last case, and add catch
>>> handler for the checkcast, but generating cases for all the checked
>>> types, and adding a default which throws (which I believe is the current
>>> implementation) feels much easier and cleaner to implement, and I don't
>>> really see a significant disadvantage in that.
>> It's a performance issue because you need to recheck the same type pattern
>> multiple times if the switch alternate a record pattern followed by a type
>> pattern followed by a record pattern ...
> 
> 
> I assume you are referring to the following case, not to a case where we
> would be catching ClassCastExceptions:
> 
> case Box(String s) -> {}
> 
> case Box b -> {}
> 
> 
> It is true there will (likely) be one more instanceof at runtime, and we
> could avoid this at the cost of an additional complexity in javac.

yes, i think that in the end we will need to build a decision tree, in can be done in javac or inside a bootstrap method (like the lambda proxy is generated),
the later having the advantage to not requirering recompilation to enjoy more performance.

> 
> 
> If the record pattern and type pattern would alternate multiple times,
> that would (I think) require the type patterns to have guards. Like:
> 
> case Box(String s) -> {}
> 
> case Box b when guard1(b) -> {}
> 
> case Box(Integer i) -> {}
> 
> case Box b when guard2(b) -> {}
> 
> ...
> 
> 
> Optimizing this is even more challenging, as we would need to preserve
> the order.

You only need to preserve the order of the "when", not the order of the full pattern matching.

and i was thinking to a pattern matching like that:
switch(o) {
  case A(String s) -> ...
  case A a -> ...
  case B(String s) -> ...
  case B b ->
}

which alternate a record pattern and a type pattern.

> 
> 
> In any case, I'm a bit afraid that we could enhance a translation patch
> forever, always adding new cases that can be optimized. So, I think we
> need to draw a line somewhere where the patch provides a benefit while
> still being testable and reviewable. With a possible separate
> improvements, if they prove to be useful. It is possible I haven't drawn
> the line far enough, but looking at the patch, it seems complex enough.

I think the issue is that a list of pattern is not the right intermediary structure to try to optimize the pattern matching, a decision tree is a better intermediary representation (this is how pattern matching is usually optimized, i've not invented something new :) )

Here is an example of such decision tree:
https://github.com/forax/switch-pattern-combinator

regards,
R?mi


From jan.lahoda at oracle.com  Fri Aug  5 19:35:14 2022
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 5 Aug 2022 21:35:14 +0200
Subject: [External] : Re: RFR: 8291769: Translation of switch with record
 patterns could be improved
In-Reply-To: <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
Message-ID: <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>

On 05. 08. 22 19:24, forax at univ-mlv.fr wrote:

>
> ----- Original Message -----
>> From: "jan lahoda" <jan.lahoda at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>, "compiler-dev"
>> <compiler-dev at openjdk.org>
>> Sent: Thursday, August 4, 2022 10:10:06 PM
>> Subject: Re: [External] : Re: RFR: 8291769: Translation of switch with record patterns could be improved
>> On 04. 08. 22 19:23, forax at univ-mlv.fr wrote:
>>
>>> ----- Original Message -----
>>>> From: "jan lahoda" <jan.lahoda at oracle.com>
>>>> To: "Remi Forax" <forax at univ-mlv.fr>, "Jan Lahoda" <jlahoda at openjdk.org>, "Brian
>>>> Goetz" <brian.goetz at oracle.com>
>>>> Cc: "compiler-dev" <compiler-dev at openjdk.org>
>>>> Sent: Thursday, August 4, 2022 6:35:18 PM
>>>> Subject: Re: RFR: 8291769: Translation of switch with record patterns could be
>>>> improved
>>>> On 04. 08. 22 17:43, Remi Forax wrote:
>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Jan Lahoda" <jlahoda at openjdk.org>
>>>>>> To: compiler-dev at openjdk.org
>>>>>> Sent: Thursday, August 4, 2022 5:04:52 PM
>>>>>> Subject: RFR: 8291769: Translation of switch with record patterns could be
>>>>>> improved
>>>>>> This is an attempt to improve the performance and scalability of switches with
>>>>>> record patterns.
>>>>>>
>>>>>> There are two main parts of this patch:
>>>>>> 1. for cases of consecutive runs of cases with the same record pattern, these
>>>>>> are replaced with a single case and a nested switch. E.g.:
>>>>>>
>>>>>> switch (obj) {
>>>>>>        case Box(String s) -> {}
>>>>>>        case Box(Integer i) -> {}
>>>>>>        case Box(Number n) -> {}
>>>>>>        ...
>>>>>> }
>>>>>> =>
>>>>>> switch (obj) {
>>>>>>        case Box b ->
>>>>>>             switch (b.o()) {
>>>>>>                 case String s -> {}
>>>>>>                 case Integer i -> {}
>>>>>>                 case Number n -> {}
>>>>>>                 default -> continue-with-outer-switch;
>>>>>>             };
>>>>>>       ...
>>>>>> }
>>>>>>
>>>>>>
>>>>>> This is done by first unrolling the record patterns into simple binding patterns
>>>>>> a guards, and then by finding cases with the common binding pattern as a label
>>>>>> and a viable guard. Binding patterns are reused as much as possibly,
>>>>>> eliminating specialized handling of record patterns as much as possible.
>>>>> How it works when you have a record pattern followed by a type pattern with the
>>>>> same type ?
>>>>> Something like:
>>>>>
>>>>>      switch (obj) {
>>>>>        case Box(String s) -> {}
>>>>>        case Box(Integer i) -> {}
>>>>>        
>>>>>        case Box b -> {}
>>>>>      }
>>>>>
>>>>> because you now have twice the same type pattern on the outer switch but the
>>>>> first one should not NPE.
>>>> Currently the `case Box b -> {}` is kept separate. It would be possible
>>>> to merge (it would simply be a default in the nested switch), but it is
>>>> an additional complexity in a fairly complex code already.
>>>>
>>>>
>>>>>> 2. When a record accessor method fails with an exception, we need to wrap this
>>>>>> exception with a `MatchException`. Currently this is being done by introducing
>>>>>> a special proxy method which catches the exception and re-throws. The proposed
>>>>>> patch here eliminates the need for the accessor methods by producing an
>>>>>> appropriate `ExceptionTable` in the classfile, and a separate catch handler.

>>>>>> This handler is attached to the innermost usable block, which is either the
>>>>>> method block, lambda body, (static or non-static) initializer or a try block.
>>>>>> This should ensure correct semantics, while not producing too many unnecessary
>>>>>> catch handlers.
>>>>> Yes !
>>>>>
>>>>> As said above, the semantics for null is slightly changed, because now you may
>>>>> throw a NPE instead of a MatchException.
>>>> The idea here is that the semantics should not be changed, and changes
>>>> to semantics are bugs. But thanks to your comment, I realized null
>>>> record components are not handled properly, so I've attempted to fix that:
>>>>
>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9746/commits/7ddeafab1d1ea23285e60765ec0e61d7a509e442__;!!ACWV5N9M2RV99hQ!ILgm-CykKXhL7fJ8n8zqHYDrHshMWU9tnE836sT6jAqJVoQZnExXgSxUax5NhJvl3XzSqgJzPPzm_1SYQYk$
>>>>
>>>>
>>>>> You can add explicit nullchecks to throw a MatchException instead but i think we
>>>>> can do better for our users.
>>>>>
>>>>> I believe that with this transformation, we can now make the difference between
>>>>> the 3 kinds of errors,
>>>>> - the call to the accessor / destructor fails throwing an error similar to
>>>>> ExceptionInTheInitializerError (ExceptionInTheDestructorError ?)
>>>>> - the tested value is null throwing a NPE because most of them are implicit when
>>>>> b.o() is called. This means that the compiler has to insert a requireNonNull if
>>>>> the nullcheck is not implicit.
>>>>> - when there are more permitted subtypes at runtime throwing an
>>>>> IncompatibleClassChangeError (like with an switch expression on an enum)
>>>> (FWIW, I believe the spec is saying what should happen in specific
>>>> cases, so I don't think this is something javac should decide on its
>>>> own. javac can decide on how the behavior is implemented, but not the
>>>> behavior.)
>>> yes, i want to change the spec because as a user it's hard to know how to fix
>>> the code when a MatchException is thrown.
>> Sure - but I am not quite sure if this PR is a place to discuss that.
>>
>>
>>>>> for the last one, the idea is that if there is a sealed type, instead of
>>>>> generating an if instanceof for all cases, the last one should not be an
>>>>> instanceof but just a cast with a cacth handler that catch the
>>>>> ClassCastException and throw an IncompatibleClassChangeError wrapping the CCE
>>>>> instead.
>>>> Note that when switching over a type we don't generate instanceof for
>>>> the subtypes of that type. The typeSwitch bootstrap/indy does the
>>>> checks, and the bytecode produced by javac only produces checkcasts. (It
>>>> may produce instanceofs for the nested patterns, though.) It would be
>>>> possible to use a default instead of the last case, and add catch
>>>> handler for the checkcast, but generating cases for all the checked
>>>> types, and adding a default which throws (which I believe is the current
>>>> implementation) feels much easier and cleaner to implement, and I don't
>>>> really see a significant disadvantage in that.
>>> It's a performance issue because you need to recheck the same type pattern
>>> multiple times if the switch alternate a record pattern followed by a type
>>> pattern followed by a record pattern ...
>>
>> I assume you are referring to the following case, not to a case where we
>> would be catching ClassCastExceptions:
>>
>> case Box(String s) -> {}
>>
>> case Box b -> {}
>>
>>
>> It is true there will (likely) be one more instanceof at runtime, and we
>> could avoid this at the cost of an additional complexity in javac.
> yes, i think that in the end we will need to build a decision tree, in can be done in javac or inside a bootstrap method (like the lambda proxy is generated),
> the later having the advantage to not requirering recompilation to enjoy more performance.
>
>>
>> If the record pattern and type pattern would alternate multiple times,
>> that would (I think) require the type patterns to have guards. Like:
>>
>> case Box(String s) -> {}
>>
>> case Box b when guard1(b) -> {}
>>
>> case Box(Integer i) -> {}
>>
>> case Box b when guard2(b) -> {}
>>
>> ...
>>
>>
>> Optimizing this is even more challenging, as we would need to preserve
>> the order.
> You only need to preserve the order of the "when", not the order of the full pattern matching.


Yes, some re-orderings may be possible, but the guard will very severely 
limit the reoderings possible. In the above case, I doubt we could 
reorder the cases/patterns in any way.


>
> and i was thinking to a pattern matching like that:
> switch(o) {
>    case A(String s) -> ...
>    case A a -> ...
>    case B(String s) -> ...
>    case B b ->
> }
>
> which alternate a record pattern and a type pattern.
>
>>
>> In any case, I'm a bit afraid that we could enhance a translation patch
>> forever, always adding new cases that can be optimized. So, I think we
>> need to draw a line somewhere where the patch provides a benefit while
>> still being testable and reviewable. With a possible separate
>> improvements, if they prove to be useful. It is possible I haven't drawn
>> the line far enough, but looking at the patch, it seems complex enough.
> I think the issue is that a list of pattern is not the right intermediary structure to try to optimize the pattern matching, a decision tree is a better intermediary representation (this is how pattern matching is usually optimized, i've not invented something new :) )
>
> Here is an example of such decision tree:
> https://urldefense.com/v3/__https://github.com/forax/switch-pattern-combinator__;!!ACWV5N9M2RV99hQ!JevAQE8IkRf4n-BMKA2sMTNFfJ5sAyJ1xopR2O9rq_45-xqaHOgirecR8E4zIGB_RgMb27G3tlcHEuGADjk$


I am not really opposed to having an intermediate structure, but I think 
the overall cost of the structure is likely to be significant, and it 
should provide significantly better code to offset that.


Looking at the page, I see:

The advantage of a decision tree is that if two patterns have a common 
prefix, the code for the common prefix is generated only once.


I wonder if there's a *conceptual* difference between what this PR is 
doing and what your code is doing. The PR here is trying to take common 
prefixes (of viable cases) and generate code for them only once. I don't 
think that not optimizing

case A(String s) -> {}

case A a -> {}

is a conceptual difference, but if this is something that is seen as 
critical, I am fairly sure I can implement that without creating a brand 
new structure and code to convert the AST into it and back.


It is also true the current code does not reoder the cases. I am not 
sure if your code does reordering, but I didn't see a set of rules for 
safe reorderings, which I think is the biggest problem here. My thinking 
of safe rules for reordering was limited so far, and the ability to 
reorder cases may be limited due to guards and separate compilation 
considerations (we can also have new pattern types which may limit our 
ability to reorder cases). But even though this PR does not reorder 
cases, it is in principle doable.


Situation would, of course, be different if we tried to optimize not 
only prefixes of the patterns - but this does not seem to be the 
proposal in switch-pattern-combinator.


As for casting to the last permitted type - I don't see how this relates 
to decision trees.? While casting and catching might look interesting 
from the bytecode perspective, it is something that is likely to be 
relatively complex to implement in javac, and using an (effective) 
instanceof and an explicit fallback does not really sound terrible. 
There is also a question on when this is safe to do - if there's a `case 
Object o` at the end of the switch, then probably this is not correct to 
do anyway, etc.


Regarding deferring all this to runtime, that has definitely a lot of 
desirable properties. And there were multiple experiments with that. 
But, the API for that is fairly complex - probably easier to do now when 
we have guards on cases, not guarded patterns, but still likely 
significant. (Overall, guard are really tough, because they a) capture; 
b) provide new bindings.)


Thanks,

 ??? Jan


>
> regards,
> R?mi
>

From forax at univ-mlv.fr  Fri Aug  5 20:28:21 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 5 Aug 2022 22:28:21 +0200 (CEST)
Subject: [External] : Re: RFR: 8291769: Translation of switch with
 record patterns could be improved
In-Reply-To: <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
Message-ID: <1381630924.19076324.1659731301000.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>, "compiler-dev"
> <compiler-dev at openjdk.org>
> Sent: Friday, August 5, 2022 9:35:14 PM
> Subject: Re: [External] : Re: RFR: 8291769: Translation of switch with record patterns could be improved

> On 05. 08. 22 19:24, forax at univ-mlv.fr wrote:
> 
>>
>> ----- Original Message -----
>>> From: "jan lahoda" <jan.lahoda at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>,
>>> "compiler-dev"
>>> <compiler-dev at openjdk.org>
>>> Sent: Thursday, August 4, 2022 10:10:06 PM
>>> Subject: Re: [External] : Re: RFR: 8291769: Translation of switch with record
>>> patterns could be improved
>>> On 04. 08. 22 19:23, forax at univ-mlv.fr wrote:
>>>
>>>> ----- Original Message -----
>>>>> From: "jan lahoda" <jan.lahoda at oracle.com>
>>>>> To: "Remi Forax" <forax at univ-mlv.fr>, "Jan Lahoda" <jlahoda at openjdk.org>, "Brian
>>>>> Goetz" <brian.goetz at oracle.com>
>>>>> Cc: "compiler-dev" <compiler-dev at openjdk.org>
>>>>> Sent: Thursday, August 4, 2022 6:35:18 PM
>>>>> Subject: Re: RFR: 8291769: Translation of switch with record patterns could be
>>>>> improved
>>>>> On 04. 08. 22 17:43, Remi Forax wrote:
>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Jan Lahoda" <jlahoda at openjdk.org>
>>>>>>> To: compiler-dev at openjdk.org
>>>>>>> Sent: Thursday, August 4, 2022 5:04:52 PM
>>>>>>> Subject: RFR: 8291769: Translation of switch with record patterns could be
>>>>>>> improved
>>>>>>> This is an attempt to improve the performance and scalability of switches with
>>>>>>> record patterns.
>>>>>>>
>>>>>>> There are two main parts of this patch:
>>>>>>> 1. for cases of consecutive runs of cases with the same record pattern, these
>>>>>>> are replaced with a single case and a nested switch. E.g.:
>>>>>>>
>>>>>>> switch (obj) {
>>>>>>>        case Box(String s) -> {}
>>>>>>>        case Box(Integer i) -> {}
>>>>>>>        case Box(Number n) -> {}
>>>>>>>        ...
>>>>>>> }
>>>>>>> =>
>>>>>>> switch (obj) {
>>>>>>>        case Box b ->
>>>>>>>             switch (b.o()) {
>>>>>>>                 case String s -> {}
>>>>>>>                 case Integer i -> {}
>>>>>>>                 case Number n -> {}
>>>>>>>                 default -> continue-with-outer-switch;
>>>>>>>             };
>>>>>>>       ...
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> This is done by first unrolling the record patterns into simple binding patterns
>>>>>>> a guards, and then by finding cases with the common binding pattern as a label
>>>>>>> and a viable guard. Binding patterns are reused as much as possibly,
>>>>>>> eliminating specialized handling of record patterns as much as possible.
>>>>>> How it works when you have a record pattern followed by a type pattern with the
>>>>>> same type ?
>>>>>> Something like:
>>>>>>
>>>>>>      switch (obj) {
>>>>>>        case Box(String s) -> {}
>>>>>>        case Box(Integer i) -> {}
>>>>>>        
>>>>>>        case Box b -> {}
>>>>>>      }
>>>>>>
>>>>>> because you now have twice the same type pattern on the outer switch but the
>>>>>> first one should not NPE.
>>>>> Currently the `case Box b -> {}` is kept separate. It would be possible
>>>>> to merge (it would simply be a default in the nested switch), but it is
>>>>> an additional complexity in a fairly complex code already.
>>>>>
>>>>>
>>>>>>> 2. When a record accessor method fails with an exception, we need to wrap this
>>>>>>> exception with a `MatchException`. Currently this is being done by introducing
>>>>>>> a special proxy method which catches the exception and re-throws. The proposed
>>>>>>> patch here eliminates the need for the accessor methods by producing an
>>>>>>> appropriate `ExceptionTable` in the classfile, and a separate catch handler.
> 
>>>>>>> This handler is attached to the innermost usable block, which is either the
>>>>>>> method block, lambda body, (static or non-static) initializer or a try block.
>>>>>>> This should ensure correct semantics, while not producing too many unnecessary
>>>>>>> catch handlers.
>>>>>> Yes !
>>>>>>
>>>>>> As said above, the semantics for null is slightly changed, because now you may
>>>>>> throw a NPE instead of a MatchException.
>>>>> The idea here is that the semantics should not be changed, and changes
>>>>> to semantics are bugs. But thanks to your comment, I realized null
>>>>> record components are not handled properly, so I've attempted to fix that:
>>>>>
>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9746/commits/7ddeafab1d1ea23285e60765ec0e61d7a509e442__;!!ACWV5N9M2RV99hQ!ILgm-CykKXhL7fJ8n8zqHYDrHshMWU9tnE836sT6jAqJVoQZnExXgSxUax5NhJvl3XzSqgJzPPzm_1SYQYk$
>>>>>
>>>>>
>>>>>> You can add explicit nullchecks to throw a MatchException instead but i think we
>>>>>> can do better for our users.
>>>>>>
>>>>>> I believe that with this transformation, we can now make the difference between
>>>>>> the 3 kinds of errors,
>>>>>> - the call to the accessor / destructor fails throwing an error similar to
>>>>>> ExceptionInTheInitializerError (ExceptionInTheDestructorError ?)
>>>>>> - the tested value is null throwing a NPE because most of them are implicit when
>>>>>> b.o() is called. This means that the compiler has to insert a requireNonNull if
>>>>>> the nullcheck is not implicit.
>>>>>> - when there are more permitted subtypes at runtime throwing an
>>>>>> IncompatibleClassChangeError (like with an switch expression on an enum)
>>>>> (FWIW, I believe the spec is saying what should happen in specific
>>>>> cases, so I don't think this is something javac should decide on its
>>>>> own. javac can decide on how the behavior is implemented, but not the
>>>>> behavior.)
>>>> yes, i want to change the spec because as a user it's hard to know how to fix
>>>> the code when a MatchException is thrown.
>>> Sure - but I am not quite sure if this PR is a place to discuss that.
>>>
>>>
>>>>>> for the last one, the idea is that if there is a sealed type, instead of
>>>>>> generating an if instanceof for all cases, the last one should not be an
>>>>>> instanceof but just a cast with a cacth handler that catch the
>>>>>> ClassCastException and throw an IncompatibleClassChangeError wrapping the CCE
>>>>>> instead.
>>>>> Note that when switching over a type we don't generate instanceof for
>>>>> the subtypes of that type. The typeSwitch bootstrap/indy does the
>>>>> checks, and the bytecode produced by javac only produces checkcasts. (It
>>>>> may produce instanceofs for the nested patterns, though.) It would be
>>>>> possible to use a default instead of the last case, and add catch
>>>>> handler for the checkcast, but generating cases for all the checked
>>>>> types, and adding a default which throws (which I believe is the current
>>>>> implementation) feels much easier and cleaner to implement, and I don't
>>>>> really see a significant disadvantage in that.
>>>> It's a performance issue because you need to recheck the same type pattern
>>>> multiple times if the switch alternate a record pattern followed by a type
>>>> pattern followed by a record pattern ...
>>>
>>> I assume you are referring to the following case, not to a case where we
>>> would be catching ClassCastExceptions:
>>>
>>> case Box(String s) -> {}
>>>
>>> case Box b -> {}
>>>
>>>
>>> It is true there will (likely) be one more instanceof at runtime, and we
>>> could avoid this at the cost of an additional complexity in javac.
>> yes, i think that in the end we will need to build a decision tree, in can be
>> done in javac or inside a bootstrap method (like the lambda proxy is
>> generated),
>> the later having the advantage to not requirering recompilation to enjoy more
>> performance.
>>
>>>
>>> If the record pattern and type pattern would alternate multiple times,
>>> that would (I think) require the type patterns to have guards. Like:
>>>
>>> case Box(String s) -> {}
>>>
>>> case Box b when guard1(b) -> {}
>>>
>>> case Box(Integer i) -> {}
>>>
>>> case Box b when guard2(b) -> {}
>>>
>>> ...
>>>
>>>
>>> Optimizing this is even more challenging, as we would need to preserve
>>> the order.
>> You only need to preserve the order of the "when", not the order of the full
>> pattern matching.
> 
> 
> Yes, some re-orderings may be possible, but the guard will very severely
> limit the reorderings possible. In the above case, I doubt we could
> reorder the cases/patterns in any way.

I wonder if this example shows that there is a missing rule when computing the dominance relationships,
if we want to make those patterns easy to read, i believe that having the guard at the end is more readable

case Box(String s) -> {}
case Box(Integer i) -> {}
case Box b when guard1(b) -> {}
case Box b when guard2(b) -> {}

Having a guard should not a be a free from the dominance relationships card.

The dominance algorithm should be more something like we checks first without the guards and then we add the guards.

We already have a dominance between "case Box b when ..." and "case Box b" and between case Box(..) and case Box b so it seems quite logical to have one between case Box(...) and case Box b when ...


R?mi

From vromero at openjdk.org  Fri Aug  5 20:31:35 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Aug 2022 20:31:35 GMT
Subject: RFR: 8029633: Raw inner class constructor ref should not perform
 diamond inference
Message-ID: <ei3biAfb_e9f9J2KqZ8Mm-O4clkpgZyMrM5SOkL4qu0=.95a3eb29-006d-478d-b9b2-1cf736426627@github.com>

This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`:


? If the method reference expression has the form ClassType ::
  [TypeArguments] new , then the potentially applicable methods are a set of
  notional methods corresponding to the constructors of ClassType.
  If ClassType is a raw type, but is not a non- static member type of a raw type,
  the candidate notional member methods are those specified in ?15.9.3 for a
  class instance creation expression that uses <> to elide the type arguments to a
  class. Otherwise, the candidate notional member methods are the constructors
  of ClassType, treated as if they were methods with return type ClassType.

so javac should treat the code below as a raw constructor invocation:


class Outer<T> {
    class Inner<U> {}

    Supplier<Outer<T>.Inner<String>> s = Outer.Inner::new;
}

currently javac is rejecting this code

-------------

Commit messages:
 - 8029633: Raw inner class constructor ref should not perform diamond inference

Changes: https://git.openjdk.org/jdk/pull/9784/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9784&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8029633
  Stats: 25 lines in 3 files changed: 24 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9784.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9784/head:pull/9784

PR: https://git.openjdk.org/jdk/pull/9784

From vromero at openjdk.org  Fri Aug  5 20:31:36 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Aug 2022 20:31:36 GMT
Subject: RFR: 8029633: Raw inner class constructor ref should not perform
 diamond inference
In-Reply-To: <ei3biAfb_e9f9J2KqZ8Mm-O4clkpgZyMrM5SOkL4qu0=.95a3eb29-006d-478d-b9b2-1cf736426627@github.com>
References: <ei3biAfb_e9f9J2KqZ8Mm-O4clkpgZyMrM5SOkL4qu0=.95a3eb29-006d-478d-b9b2-1cf736426627@github.com>
Message-ID: <0Ffw5wEUdGJdprLqSTSMbCmop5wu-ioubWiloZT5b5o=.c397d7d3-160a-4ba7-aca5-55ec5c905832@github.com>

On Fri, 5 Aug 2022 20:20:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`:
> 
> 
> ? If the method reference expression has the form ClassType ::
>   [TypeArguments] new , then the potentially applicable methods are a set of
>   notional methods corresponding to the constructors of ClassType.
>   If ClassType is a raw type, but is not a non- static member type of a raw type,
>   the candidate notional member methods are those specified in ?15.9.3 for a
>   class instance creation expression that uses <> to elide the type arguments to a
>   class. Otherwise, the candidate notional member methods are the constructors
>   of ClassType, treated as if they were methods with return type ClassType.
> 
> so javac should treat the code below as a raw constructor invocation:
> 
> 
> class Outer<T> {
>     class Inner<U> {}
> 
>     Supplier<Outer<T>.Inner<String>> s = Outer.Inner::new;
> }
> 
> currently javac is rejecting this code

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3691:

> 3689:                 this.site = new ClassType(site.getEnclosingType(),
> 3690:                         !site.tsym.isInner() ? site.tsym.type.getTypeArguments() : List.nil(), site.tsym, site.getMetadata());
> 3691:                 needsInference = true;

Note: so here it seems like we are still doing diamond inference but check that we are creating a new class type with no arguments so no inference will be done in this case (site is an inner class), but we are still setting `needsInference` to true in order to reuse the code in `Resolve::findDiamond` that creates a new `MethodSymbol` for the constructor with the right result type instead of `void`

-------------

PR: https://git.openjdk.org/jdk/pull/9784

From forax at univ-mlv.fr  Fri Aug  5 20:52:35 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 5 Aug 2022 22:52:35 +0200 (CEST)
Subject: [External] : Re: RFR: 8291769: Translation of switch with
 record patterns could be improved
In-Reply-To: <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
Message-ID: <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>

[...]

>>> In any case, I'm a bit afraid that we could enhance a translation patch
>>> forever, always adding new cases that can be optimized. So, I think we
>>> need to draw a line somewhere where the patch provides a benefit while
>>> still being testable and reviewable. With a possible separate
>>> improvements, if they prove to be useful. It is possible I haven't drawn
>>> the line far enough, but looking at the patch, it seems complex enough.
>> I think the issue is that a list of pattern is not the right intermediary
>> structure to try to optimize the pattern matching, a decision tree is a better
>> intermediary representation (this is how pattern matching is usually optimized,
>> i've not invented something new :) )
>>
>> Here is an example of such decision tree:
>> https://urldefense.com/v3/__https://github.com/forax/switch-pattern-combinator__;!!ACWV5N9M2RV99hQ!JevAQE8IkRf4n-BMKA2sMTNFfJ5sAyJ1xopR2O9rq_45-xqaHOgirecR8E4zIGB_RgMb27G3tlcHEuGADjk$
> 
> 
> I am not really opposed to having an intermediate structure, but I think
> the overall cost of the structure is likely to be significant, and it
> should provide significantly better code to offset that.

I agree.

> 
> 
> Looking at the page, I see:
> 
> The advantage of a decision tree is that if two patterns have a common
> prefix, the code for the common prefix is generated only once.
> 
> 
> I wonder if there's a *conceptual* difference between what this PR is
> doing and what your code is doing. The PR here is trying to take common
> prefixes (of viable cases) and generate code for them only once. I don't
> think that not optimizing
> 
> case A(String s) -> {}
> 
> case A a -> {}
> 
> is a conceptual difference, but if this is something that is seen as
> critical, I am fairly sure I can implement that without creating a brand
> new structure and code to convert the AST into it and back.

You need the intermediary structure when the common prefix are not subsequent

case A(B b) ->
case B(A a) ->
case A(C c) ->

Here the first and the last case shares a common prefix.  

> 
> 
> It is also true the current code does not reorder the cases. I am not
> sure if your code does reordering, but I didn't see a set of rules for
> safe reorderings, which I think is the biggest problem here. My thinking
> of safe rules for reordering was limited so far, and the ability to
> reorder cases may be limited due to guards and separate compilation
> considerations (we can also have new pattern types which may limit our
> ability to reorder cases). But even though this PR does not reorder
> cases, it is in principle doable.

One of the reason to backpedal on the idea of guarded patterns is to try to cleanly separate what can do side effects thus limit the reordering and what should not do side effects.
A guard can do side effect thus it's not a pattern. A deconstructing pattern using a deconstructor should not do side effect ("should not" like in a stream, if you do it, you are on your own) because it's a pattern.

> 
> 
> Situation would, of course, be different if we tried to optimize not
> only prefixes of the patterns - but this does not seem to be the
> proposal in switch-pattern-combinator.
> 
> 
> As for casting to the last permitted type - I don't see how this relates
> to decision trees.? While casting and catching might look interesting
> from the bytecode perspective, it is something that is likely to be
> relatively complex to implement in javac, and using an (effective)
> instanceof and an explicit fallback does not really sound terrible.

The idea of using a cast is that you provide a good error message to the users because the ClassCastException stores the class that is not handled by the pattern matching.
You loose that information if you use an explicit fallback.

> There is also a question on when this is safe to do - if there's a `case
> Object o` at the end of the switch, then probably this is not correct to
> do anyway, etc.

It is safe to do if the compiler has type-checked the patterns before, the cast is only done in case of a sealed type, not if there is a common supertype at the end.

> 
> 
> Regarding deferring all this to runtime, that has definitely a lot of
> desirable properties. And there were multiple experiments with that.
> But, the API for that is fairly complex - probably easier to do now when
> we have guards on cases, not guarded patterns, but still likely
> significant. (Overall, guard are really tough, because they a) capture;
> b) provide new bindings.)

"provide new bindings" => do you have an example of that ?
I don't think a guard should be allowed to do that. It looks like a big gunfoot to me.

> 
> 
> Thanks,
> 
> ??? Jan
> 
> 

regards,
R?mi


From jan.lahoda at oracle.com  Fri Aug  5 21:54:05 2022
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 5 Aug 2022 23:54:05 +0200
Subject: [External] : Re: RFR: 8291769: Translation of switch with record
 patterns could be improved
In-Reply-To: <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <1925281120.18653140.1659627817664.JavaMail.zimbra@u-pem.fr>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
 <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
Message-ID: <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>

On 05. 08. 22 22:52, forax at univ-mlv.fr wrote:

> [...]
>
>>>> In any case, I'm a bit afraid that we could enhance a translation patch
>>>> forever, always adding new cases that can be optimized. So, I think we
>>>> need to draw a line somewhere where the patch provides a benefit while
>>>> still being testable and reviewable. With a possible separate
>>>> improvements, if they prove to be useful. It is possible I haven't drawn
>>>> the line far enough, but looking at the patch, it seems complex enough.
>>> I think the issue is that a list of pattern is not the right intermediary
>>> structure to try to optimize the pattern matching, a decision tree is a better
>>> intermediary representation (this is how pattern matching is usually optimized,
>>> i've not invented something new :) )
>>>
>>> Here is an example of such decision tree:
>>> https://urldefense.com/v3/__https://github.com/forax/switch-pattern-combinator__;!!ACWV5N9M2RV99hQ!JevAQE8IkRf4n-BMKA2sMTNFfJ5sAyJ1xopR2O9rq_45-xqaHOgirecR8E4zIGB_RgMb27G3tlcHEuGADjk$
>>
>> I am not really opposed to having an intermediate structure, but I think
>> the overall cost of the structure is likely to be significant, and it
>> should provide significantly better code to offset that.
> I agree.
>
>>
>> Looking at the page, I see:
>>
>> The advantage of a decision tree is that if two patterns have a common
>> prefix, the code for the common prefix is generated only once.
>>
>>
>> I wonder if there's a *conceptual* difference between what this PR is
>> doing and what your code is doing. The PR here is trying to take common
>> prefixes (of viable cases) and generate code for them only once. I don't
>> think that not optimizing
>>
>> case A(String s) -> {}
>>
>> case A a -> {}
>>
>> is a conceptual difference, but if this is something that is seen as
>> critical, I am fairly sure I can implement that without creating a brand
>> new structure and code to convert the AST into it and back.
> You need the intermediary structure when the common prefix are not subsequent
>
> case A(B b) ->
> case B(A a) ->
> case A(C c) ->
>
> Here the first and the last case shares a common prefix.


Sorry, but I don't see why I can't do this particular thing without a 
specialized intermediate representation. A bigger question, I think, is 
when it is safe to do so, and when not.


>
>>
>> It is also true the current code does not reorder the cases. I am not
>> sure if your code does reordering, but I didn't see a set of rules for
>> safe reorderings, which I think is the biggest problem here. My thinking
>> of safe rules for reordering was limited so far, and the ability to
>> reorder cases may be limited due to guards and separate compilation
>> considerations (we can also have new pattern types which may limit our
>> ability to reorder cases). But even though this PR does not reorder
>> cases, it is in principle doable.
> One of the reason to backpedal on the idea of guarded patterns is to try to cleanly separate what can do side effects thus limit the reordering and what should not do side effects.
> A guard can do side effect thus it's not a pattern. A deconstructing pattern using a deconstructor should not do side effect ("should not" like in a stream, if you do it, you are on your own) because it's a pattern.
>
>>
>> Situation would, of course, be different if we tried to optimize not
>> only prefixes of the patterns - but this does not seem to be the
>> proposal in switch-pattern-combinator.
>>
>>
>> As for casting to the last permitted type - I don't see how this relates
>> to decision trees.? While casting and catching might look interesting
>> from the bytecode perspective, it is something that is likely to be
>> relatively complex to implement in javac, and using an (effective)
>> instanceof and an explicit fallback does not really sound terrible.
> The idea of using a cast is that you provide a good error message to the users because the ClassCastException stores the class that is not handled by the pattern matching.
> You loose that information if you use an explicit fallback.


Sorry, but if I understand what you are proposing is:

B b = (B) obj; //magical catch handler somewhere handling the CCE

$rest$;


what I am saying is that this can be achieved by an analog of:

if (obj instanceof B b) {

 ??? $rest$;

} else {

 ???? throw <an-exception-we-want>(obj.getClass());

}


What information is lost?


>
>> There is also a question on when this is safe to do - if there's a `case
>> Object o` at the end of the switch, then probably this is not correct to
>> do anyway, etc.
> It is safe to do if the compiler has type-checked the patterns before, the cast is only done in case of a sealed type, not if there is a common supertype at the end.


I mean - consider:

sealed interface I {}

final class OnlySubtypeAtCompileTime implements I {}

record Box(I i) {}


Object b = new Box(<a-new-subtype-not-known-at-compile-time>);

switch (b) {

 ???? case Box(OnlySubtypeAtCompileTime t) -> System.err.println("Should 
probably not fail here,");

 ???? case Object obj -> System.err.println("but should end up here.");

}


>
>>
>> Regarding deferring all this to runtime, that has definitely a lot of
>> desirable properties. And there were multiple experiments with that.
>> But, the API for that is fairly complex - probably easier to do now when
>> we have guards on cases, not guarded patterns, but still likely
>> significant. (Overall, guard are really tough, because they a) capture;
>> b) provide new bindings.)
> "provide new bindings" => do you have an example of that ?


Sure:

public class TA {
 ???public static void main(String... args) {
 ???????Object o = new Box("");
 ???????switch (o) {
 ???????????case Box b when b.o() instanceof String s -> 
System.err.println(s);
 ???????????default -> {}
 ???????}
 ???}
 ???record Box(Object o) {}
}


(There can be any number of new bindings from the guard, of course.)


> I don't think a guard should be allowed to do that. It looks like a big gunfoot to me.


I believe the current specification supports guards that introduce new 
bindings:

http://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-6.3.4


To me, it seems desirable. In any case, an implementation PR is probably 
not very well suited to discuss opinions on what should be specced. In 
particular (but not only) a PR that is not expected to change the semantics.


Jan


>
>>
>> Thanks,
>>
>>  ??? Jan
>>
>>
> regards,
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220805/93c245e7/attachment-0001.htm>

From darcy at openjdk.org  Fri Aug  5 22:20:08 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Aug 2022 22:20:08 GMT
Subject: RFR: JDK-8289249: Add methods to Elements for record constructors
In-Reply-To: <5W9ug9wRkmGjv9fvKxbDvHd9FqpL3LRiILRBODVMKQs=.f9373998-4b07-4177-b76e-2061647ea683@github.com>
References: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>
 <5W9ug9wRkmGjv9fvKxbDvHd9FqpL3LRiILRBODVMKQs=.f9373998-4b07-4177-b76e-2061647ea683@github.com>
Message-ID: <xYGFCbKOLj5QfaqHxzcLLJlreZ0e1HctQUigkr4mf5I=.35ebf948-c0d3-49e9-8b77-d816ed7b2f83@github.com>

On Fri, 5 Aug 2022 16:43:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Generally, when we specify an `@implNote` for a default method that is a "do-nothing-helpful" method, we should find a place or way to document the useful implementation of the method.

I think we could look to improve the docs on that point for future work.

-------------

PR: https://git.openjdk.org/jdk/pull/9694

From darcy at openjdk.org  Fri Aug  5 22:21:35 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Aug 2022 22:21:35 GMT
Subject: Integrated: JDK-8289249: Add methods to Elements for record
 constructors
In-Reply-To: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>
References: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>
Message-ID: <sa6SEpP3bRXDbFR5wuSBHB-kEsiBjRvfhdcnoWOoTss=.e00515b5-5561-47d9-8f18-6c12550209d5@github.com>

On Sun, 31 Jul 2022 02:43:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the addition of two predicates to better support records in the javax.lang.model API.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8291594

This pull request has now been integrated.

Changeset: 0657acf5
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0657acf534b0200b13a7535598d69ad4532cd97e
Stats:     224 lines in 3 files changed: 224 ins; 0 del; 0 mod

8289249: Add methods to Elements for record constructors

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/9694

From darcy at openjdk.org  Fri Aug  5 22:47:06 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Aug 2022 22:47:06 GMT
Subject: RFR: JDK-8289249: Add methods to Elements for record constructors
In-Reply-To: <FHT_KX8D2jd0d3ZJkWpF9o0h35O4B1bIqR_m3g01YTw=.e53c1152-886b-4158-b505-fbae0f4e28d5@github.com>
References: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>
 <FHT_KX8D2jd0d3ZJkWpF9o0h35O4B1bIqR_m3g01YTw=.e53c1152-886b-4158-b505-fbae0f4e28d5@github.com>
Message-ID: <lc70CZBBBbg-xY3rUXA3YBiqh4npeROdgSTfZLBZDPs=.65cc40a8-5931-4948-9df6-ed89b14aeab8@github.com>

On Thu, 4 Aug 2022 16:13:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review the addition of two predicates to better support records in the javax.lang.model API.
>> 
>> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8291594
>
> test/langtools/tools/javac/processing/model/util/elements/TestRecordPredicates.java line 110:
> 
>> 108:     }
>> 109: 
>> 110:     @ExpectedPredicates(isCompact=true, isCanonical=true)
> 
> side: this is uncovering a bug in the compiler, isCanonical should be false in this case. I have filed JDK-8291914 to address this issue

Part of the regression tests for  JDK-8291914 already written then :-)

-------------

PR: https://git.openjdk.org/jdk/pull/9694

From duke at openjdk.org  Sat Aug  6 09:05:12 2022
From: duke at openjdk.org (Patrick Pfeifer)
Date: Sat, 6 Aug 2022 09:05:12 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
Message-ID: <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>

On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
>> 
>> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
>> 
>> The Java manpage was missing updates from:
>> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
>> 
>> The Java manpage has slight formatting differences from:
>> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
>> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
>> 
>> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
>> 
>> 
>> The keytool manpage was missing updates from:
>> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The jar manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jarsigner manpage was missing updates from:
>> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The javadoc manpage was missing updates from:
>> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
>> 
>> The jmod manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jpackage manpage was missing updates from:
>> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
>> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
>> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
>> 
>> The jshell manpage was missing updates from:
>> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.
>
> src/java.base/share/man/keytool.1 line 456:
> 
>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>> 455: keystore.
>> 456: This option is used to sign the certificate with the signer?s private
> 
> Not a problem with this PR as such, but we still have a `?` character in the output.

Hello @jonathan-gibbons

Excuse my hijacking / piggy-backing on this conversation!

When you say

> Not a problem with this PR as such, but we still have a `?` character in the output.

This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo?

Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build.

I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web?

-------------

PR: https://git.openjdk.org/jdk19/pull/145

From duke at openjdk.org  Sat Aug  6 13:54:20 2022
From: duke at openjdk.org (Patrick Pfeifer)
Date: Sat, 6 Aug 2022 13:54:20 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
 <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
Message-ID: <_53Ro95x3TDbVcRUoOr4L0HiWCyepU8CgcyPCwLwKLA=.6ce49e6c-9b4b-4c8e-b0b8-7ec76b0f3d85@github.com>

On Sat, 6 Aug 2022 09:01:39 GMT, Patrick Pfeifer <duke at openjdk.org> wrote:

>> src/java.base/share/man/keytool.1 line 456:
>> 
>>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>>> 455: keystore.
>>> 456: This option is used to sign the certificate with the signer?s private
>> 
>> Not a problem with this PR as such, but we still have a `?` character in the output.
>
> Hello @jonathan-gibbons
> 
> Excuse my hijacking / piggy-backing on this conversation!
> 
> When you say
> 
>> Not a problem with this PR as such, but we still have a `?` character in the output.
> 
> This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo?
> 
> Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build.
> 
> I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web?

It did not take much effort to answer the last of the above question myself.

> Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web?

Obviously "yes". HTML renderings can be found by following the, e.g. "[Java Development Kit Version 18 Tool Specifications](https://docs.oracle.com/en/java/javase/18/docs/specs/man/index.html)" Link on the "Specifications Overview" page at, e.g. "https://docs.oracle.com/en/java/javase/18/docs/specs/".

Still hunting for the sources.

-------------

PR: https://git.openjdk.org/jdk19/pull/145

From forax at univ-mlv.fr  Sun Aug  7 08:02:32 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 7 Aug 2022 10:02:32 +0200 (CEST)
Subject: [External] : Re: RFR: 8291769: Translation of switch with
 record patterns could be improved
In-Reply-To: <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
 <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
 <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
Message-ID: <36794892.19552004.1659859352180.JavaMail.zimbra@u-pem.fr>

> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>,
> "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Friday, August 5, 2022 11:54:05 PM
> Subject: Re: [External] : Re: RFR: 8291769: Translation of switch with record
> patterns could be improved

> On 05. 08. 22 22:52, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> [...]

>>>>> In any case, I'm a bit afraid that we could enhance a translation patch
>>>>> forever, always adding new cases that can be optimized. So, I think we
>>>>> need to draw a line somewhere where the patch provides a benefit while
>>>>> still being testable and reviewable. With a possible separate
>>>>> improvements, if they prove to be useful. It is possible I haven't drawn
>>>>> the line far enough, but looking at the patch, it seems complex enough.

>>>> I think the issue is that a list of pattern is not the right intermediary
>>>> structure to try to optimize the pattern matching, a decision tree is a better
>>>> intermediary representation (this is how pattern matching is usually optimized,
>>>> i've not invented something new :) )

>>>> Here is an example of such decision tree: [
>>>> https://urldefense.com/v3/__https://github.com/forax/switch-pattern-combinator__;!!ACWV5N9M2RV99hQ!JevAQE8IkRf4n-BMKA2sMTNFfJ5sAyJ1xopR2O9rq_45-xqaHOgirecR8E4zIGB_RgMb27G3tlcHEuGADjk$
>>>> |
>>>> https://urldefense.com/v3/__https://github.com/forax/switch-pattern-combinator__;!!ACWV5N9M2RV99hQ!JevAQE8IkRf4n-BMKA2sMTNFfJ5sAyJ1xopR2O9rq_45-xqaHOgirecR8E4zIGB_RgMb27G3tlcHEuGADjk$
>>>> ]

>>> I am not really opposed to having an intermediate structure, but I think
>>> the overall cost of the structure is likely to be significant, and it
>>> should provide significantly better code to offset that.

>> I agree.

>>> Looking at the page, I see:

>>> The advantage of a decision tree is that if two patterns have a common
>>> prefix, the code for the common prefix is generated only once.

>>> I wonder if there's a *conceptual* difference between what this PR is
>>> doing and what your code is doing. The PR here is trying to take common
>>> prefixes (of viable cases) and generate code for them only once. I don't
>>> think that not optimizing

>>> case A(String s) -> {}

>>> case A a -> {}

>>> is a conceptual difference, but if this is something that is seen as
>>> critical, I am fairly sure I can implement that without creating a brand
>>> new structure and code to convert the AST into it and back.

>> You need the intermediary structure when the common prefix are not subsequent

>> case A(B b) ->
>> case B(A a) ->
>> case A(C c) ->

>> Here the first and the last case shares a common prefix.

> Sorry, but I don't see why I can't do this particular thing without a
> specialized intermediate representation.
The patterns are a partial orders, because we can optimize the ones with a common prefix, we need a sort, a decision tree is equivalent to a sort. 
There are several advantages to use a decision tree instead of a sort, 
- it's easier to visualize 
- it mimics the the usual hand-written code (you don't repeat the instanceofs, you enclose them) 
- i believe that for the code generation, doing local decisions on each node is good enough, we do not need to propagate information in between nodes. 

> A bigger question, I think, is when it is safe to do so, and when not.
yes, not all re-ordering are safe, we need to keep some constraints. Fortunately, the ordering problems only arise when there are guards. 
The idea is that for each node of the decision tree, you should generate the code in that order, first for the record pattern, then the code for the guards then the code for the type pattern, in that order. 
If the guards are recorded in the same order as in the pattern matching (this is equivalent to say that the sort should be stable in term of guards), we should be ok. 

As you said, the current spec allows to freely mix type patterns and type pattern + guard pattern with the same type, this has to be fixed at the spec level. 
I think it's reasonable to introduce an order between the type pattern + guard pattern and the type pattern on the same type, because it's more readable and because we do not want users to care to much about the order of the patterns to get good performance. You should get good performance by default, and not have to crawle StackOverflow to learn the arcane of finding the "right order" for patterns. 

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220807/f31904fe/attachment.htm>

From forax at univ-mlv.fr  Sun Aug  7 08:14:20 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 7 Aug 2022 10:14:20 +0200 (CEST)
Subject: [External] : Re: RFR: 8291769: Translation of switch with
 record patterns could be improved
In-Reply-To: <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
 <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
 <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
Message-ID: <1188740890.19552808.1659860060752.JavaMail.zimbra@u-pem.fr>

[...] 

>>> Situation would, of course, be different if we tried to optimize not
>>> only prefixes of the patterns - but this does not seem to be the
>>> proposal in switch-pattern-combinator.

>>> As for casting to the last permitted type - I don't see how this relates
>>> to decision trees.? While casting and catching might look interesting
>>> from the bytecode perspective, it is something that is likely to be
>>> relatively complex to implement in javac, and using an (effective)
>>> instanceof and an explicit fallback does not really sound terrible.

>> The idea of using a cast is that you provide a good error message to the users
>> because the ClassCastException stores the class that is not handled by the
>> pattern matching.
>> You loose that information if you use an explicit fallback.

> Sorry, but if I understand what you are proposing is:

> B b = (B) obj; //magical catch handler somewhere handling the CCE

> $rest$;

> what I am saying is that this can be achieved by an analog of:

> if (obj instanceof B b) {

> $rest$;

> } else {

> throw <an-exception-we-want>(obj.getClass());

> }

> What information is lost?
sorry I misunderstood you. 
There is no information lost in this case, the generated bytecodes is just bigger which one one reason cited by Brian to only throw once in the fallback case. 

Nitpicking, "null" is treated differently so the code should be 

if (obj == null) { 
throw NPE; 
} 

if (obj instanceof B b) { 

$rest$; 

} else { 

throw <an-exception-we-want>(obj.getClass()); 

} 

Using a cast also has an issue with null but the NPE can be thrown implicitly if the sub-pattern is a record (something you know locally for each node of the decision tree). 

>>> There is also a question on when this is safe to do - if there's a `case
>>> Object o` at the end of the switch, then probably this is not correct to
>>> do anyway, etc.

>> It is safe to do if the compiler has type-checked the patterns before, the cast
>> is only done in case of a sealed type, not if there is a common supertype at
>> the end.

> I mean - consider:

> sealed interface I {}

> final class OnlySubtypeAtCompileTime implements I {}

> record Box(I i) {}

> Object b = new Box(<a-new-subtype-not-known-at-compile-time>);

> switch (b) {

> case Box(OnlySubtypeAtCompileTime t) -> System.err.println("Should probably not
> fail here,");

> case Object obj -> System.err.println("but should end up here.");

> }
I think we are agreeing here that in this case, using a cast instead of an instanceof is a mistake. We only need the cast in case if there is a sealed type and no fallback, this information has flow from the type-ckecking. 

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220807/924682c3/attachment-0001.htm>

From forax at univ-mlv.fr  Sun Aug  7 08:19:05 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 7 Aug 2022 10:19:05 +0200 (CEST)
Subject: [External] : Re: RFR: 8291769: Translation of switch with
 record patterns could be improved
In-Reply-To: <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
 <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
 <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
Message-ID: <787533739.19552932.1659860345551.JavaMail.zimbra@u-pem.fr>

[...] 

>> "provide new bindings" => do you have an example of that ?

> Sure:

> public class TA {
> public static void main(String... args) {
> Object o = new Box("");
> switch (o) {
> case Box b when b.o() instanceof String s -> System.err.println(s);
> default -> {}
> }
> }
> record Box(Object o) {}
> }

> (There can be any number of new bindings from the guard, of course.)

>> I don't think a guard should be allowed to do that. It looks like a big gunfoot
>> to me.

> I believe the current specification supports guards that introduce new bindings:

> [
> http://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-6.3.4
> |
> http://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-6.3.4
> ]

> To me, it seems desirable. In any case, an implementation PR is probably not
> very well suited to discuss opinions on what should be specced. In particular
> (but not only) a PR that is not expected to change the semantics.
Ok, thanks for the example, it means we should lift the when expression not has a static method but as a static pattern method, something which will be more clear when we will have a better idea about how to do that once user defined pattern method like Optional.of(value -> ...) will be introduced. 

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220807/df609ccf/attachment.htm>

From jan.lahoda at oracle.com  Sun Aug  7 09:17:16 2022
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 7 Aug 2022 11:17:16 +0200
Subject: [External] : Re: RFR: 8291769: Translation of switch with record
 patterns could be improved
In-Reply-To: <36794892.19552004.1659859352180.JavaMail.zimbra@u-pem.fr>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
 <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
 <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
 <36794892.19552004.1659859352180.JavaMail.zimbra@u-pem.fr>
Message-ID: <a44d15fc-e124-fe63-ef3d-e69ce71b7d06@oracle.com>

On 07. 08. 22 10:02, forax at univ-mlv.fr wrote:

>
>
> ------------------------------------------------------------------------
>
>     *From: *"jan lahoda" <jan.lahoda at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>
>     *Cc: *"Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz"
>     <brian.goetz at oracle.com>, "compiler-dev" <compiler-dev at openjdk.org>
>     *Sent: *Friday, August 5, 2022 11:54:05 PM
>     *Subject: *Re: [External] : Re: RFR: 8291769: Translation of
>     switch with record patterns could be improved
>
>     On 05. 08. 22 22:52, forax at univ-mlv.fr wrote:
>
>         [...]
>
>                     In any case, I'm a bit afraid that we could enhance a translation patch
>                     forever, always adding new cases that can be optimized. So, I think we
>                     need to draw a line somewhere where the patch provides a benefit while
>                     still being testable and reviewable. With a possible separate
>                     improvements, if they prove to be useful. It is possible I haven't drawn
>                     the line far enough, but looking at the patch, it seems complex enough.
>
>                 I think the issue is that a list of pattern is not the right intermediary
>                 structure to try to optimize the pattern matching, a decision tree is a better
>                 intermediary representation (this is how pattern matching is usually optimized,
>                 i've not invented something new :) )
>
>                 Here is an example of such decision tree:
>                 https://urldefense.com/v3/__https://github.com/forax/switch-pattern-combinator__;!!ACWV5N9M2RV99hQ!JevAQE8IkRf4n-BMKA2sMTNFfJ5sAyJ1xopR2O9rq_45-xqaHOgirecR8E4zIGB_RgMb27G3tlcHEuGADjk$
>
>             I am not really opposed to having an intermediate structure, but I think
>             the overall cost of the structure is likely to be significant, and it
>             should provide significantly better code to offset that.
>
>         I agree.
>
>             Looking at the page, I see:
>
>             The advantage of a decision tree is that if two patterns have a common
>             prefix, the code for the common prefix is generated only once.
>
>
>             I wonder if there's a *conceptual* difference between what this PR is
>             doing and what your code is doing. The PR here is trying to take common
>             prefixes (of viable cases) and generate code for them only once. I don't
>             think that not optimizing
>
>             case A(String s) -> {}
>
>             case A a -> {}
>
>             is a conceptual difference, but if this is something that is seen as
>             critical, I am fairly sure I can implement that without creating a brand
>             new structure and code to convert the AST into it and back.
>
>         You need the intermediary structure when the common prefix are not subsequent
>
>         case A(B b) ->
>         case B(A a) ->
>         case A(C c) ->
>
>         Here the first and the last case shares a common prefix.
>
>
>     Sorry, but I don't see why I can't do this particular thing
>     without a specialized intermediate representation.
>
>
> The patterns are a partial orders, because we can optimize the ones 
> with a common prefix, we need a sort, a decision tree is equivalent to 
> a sort.
> There are several advantages to use a decision tree instead of a sort,
> - it's easier to visualize
> - it mimics the the usual hand-written code (you don't repeat the 
> instanceofs, you enclose them)
> - i believe that for the code generation, doing local decisions on 
> each node is good enough, we do not need to propagate information in 
> between nodes.


Yes, the current PR does not do reordering of cases. It could, I just 
didn't think of the rules too much in principle, and didn't want to make 
the patch overly complex or break something.


I guess I can visualize the AST nodes quite fine.


>
>     A bigger question, I think, is when it is safe to do so, and when not.
>
>
> yes, not all re-ordering are safe, we need to keep some constraints. 
> Fortunately, the ordering problems only arise when there are guards.


I think it is much more than (complex) guards. Like, for example:

record R(Object o) {}

interface I {}


case R(String s) -> {}

case I i -> {}

case R(Integer i) -> {}


Now, can we change the order of "I" and "R(Integer i)"? If we do and if 
we don't, the runtime behavior can differ in case of separate 
compilation when "R" is changed to implement "I".


But, even for:

final class A {}

final class B {}


case A a when ... -> {}

case B b -> {}

case A a -> {}


Can we change the order of the cases? I am not sure, because, again, 
with separate compilation, this can lead to a different outcome.


And maybe the answer is that we can do reordering in these cases. Or 
maybe we can in some of these cases, and can't in orders. I don't think 
this was ever discussed in depth.


Some of these decisions would be easier if we did the decision at 
runtime, of course. Which brings its own problems, as discussed elsewhere.


> The idea is that for each node of the decision tree, you should 
> generate the code in that order, first for the record pattern, then 
> the code for the guards then the code for the type pattern, in that order.


The current PR first generates (an analog of) the instanceof of the 
record type, then code for the nested patterns, and then the guard of 
the case. Which allows to join the cases into nested switches (or ifs, 
if we go there). Not sure what is wrong with that?


Jan


> If the guards are recorded in the same order as in the pattern 
> matching (this is equivalent to say that the sort should be stable in 
> term of guards), we should be ok.
>
> As you said, the current spec allows to freely mix type patterns and 
> type pattern + guard pattern with the same type, this has to be fixed 
> at the spec level.
> I think it's reasonable to introduce an order between the type pattern 
> + guard pattern and the type pattern on the same type, because it's 
> more readable and because we do not want users to care to much about 
> the order of the patterns to get good performance. You should get good 
> performance by default, and not have to crawle StackOverflow to learn 
> the arcane of finding the "right order" for patterns.
>
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220807/2a71ec82/attachment-0001.htm>

From jan.lahoda at oracle.com  Sun Aug  7 09:22:28 2022
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 7 Aug 2022 11:22:28 +0200
Subject: [External] : Re: RFR: 8291769: Translation of switch with record
 patterns could be improved
In-Reply-To: <787533739.19552932.1659860345551.JavaMail.zimbra@u-pem.fr>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <a17ec060-92f3-b026-9a28-931100668ddc@oracle.com>
 <2116430605.18666388.1659633787861.JavaMail.zimbra@u-pem.fr>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
 <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
 <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
 <787533739.19552932.1659860345551.JavaMail.zimbra@u-pem.fr>
Message-ID: <24396b95-7750-5fd2-a784-fe3d78423d2a@oracle.com>

On 07. 08. 22 10:19, forax at univ-mlv.fr wrote:

> [...]
>
>         "provide new bindings" => do you have an example of that ?
>
>
>     Sure:
>
>     public class TA {
>     ???public static void main(String... args) {
>     ???????Object o = new Box("");
>     ???????switch (o) {
>     ???????????case Box b when b.o() instanceof String s ->
>     System.err.println(s);
>     ???????????default -> {}
>     ???????}
>     ???}
>     ???record Box(Object o) {}
>     }
>
>
>     (There can be any number of new bindings from the guard, of course.)
>
>
>         I don't think a guard should be allowed to do that. It looks like a big gunfoot to me.
>
>
>     I believe the current specification supports guards that introduce
>     new bindings:
>
>     http://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-6.3.4
>
>
>     To me, it seems desirable. In any case, an implementation PR is
>     probably not very well suited to discuss opinions on what should
>     be specced. In particular (but not only) a PR that is not expected
>     to change the semantics.
>
>
> Ok, thanks for the example, it means we should lift the when 
> expression not has a static method but as a static pattern method, 
> something which will be more clear when we will have a better idea 
> about how to do that once user defined pattern method like 
> Optional.of(value -> ...) will be introduced.


Which I guess leaves as with a question: what are we going to do until 
user patterns are defined. Do we keep the current slow code, or do we 
try to improve that (which is that this PR is trying to do)? (And maybe 
learn something in the process.)


Jan


>
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220807/7326a6cc/attachment.htm>

From david.holmes at oracle.com  Sun Aug  7 23:59:08 2022
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 8 Aug 2022 09:59:08 +1000
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
 <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
Message-ID: <161d24ca-ff52-b2fe-0874-461e98900e28@oracle.com>

Hi Patrick,

On 6/08/2022 7:05 pm, Patrick Pfeifer wrote:
> On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
> 
>>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
>>
>> Not a problem with this PR as such, but we still have a `?` character in the output.
> 
> Hello @jonathan-gibbons
> 
> Excuse my hijacking / piggy-backing on this conversation!
> 
> When you say
> 
>> Not a problem with this PR as such, but we still have a `?` character in the output.
> 
> This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo?

The sources to the manpages are not currently open sourced and so are 
held in Oracle's internal repository. Making them open-sourced has been 
a goal for some time now but has to overcome legal obstacles, but we are 
hopeful it will be "soon".

> Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build.
> 
> I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web?

As you found, Oracle does provide these in html format.

Cheers,
David


> -------------
> 
> PR: https://git.openjdk.org/jdk19/pull/145

From duke at openjdk.org  Mon Aug  8 06:30:36 2022
From: duke at openjdk.org (GGGGGHT)
Date: Mon, 8 Aug 2022 06:30:36 GMT
Subject: RFR: 8292022: Unary Plus Operator + and Shift Operators priority
Message-ID: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>

(capacity + capacity>>1) The result of this expression is still capacity. So I guess what the author thought at the time might be (capacity + (capacity >> 1)), see https://bugs.openjdk.org/projects/JDK/issues/JDK-8292022

-------------

Commit messages:
 - fix: modify bytebuffer object allocate capacity

Changes: https://git.openjdk.org/jdk/pull/9698/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9698&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292022
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9698.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9698/head:pull/9698

PR: https://git.openjdk.org/jdk/pull/9698

From robilad at openjdk.org  Mon Aug  8 06:30:36 2022
From: robilad at openjdk.org (Dalibor Topic)
Date: Mon, 8 Aug 2022 06:30:36 GMT
Subject: RFR: 8292022: Unary Plus Operator + and Shift Operators priority
In-Reply-To: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
References: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
Message-ID: <npvil9WSqmo1t-NeKKATR7mNqQltPrpX5Fb8DwcA8as=.ec5a7668-c2f4-49bd-a70f-a9aacb803347@github.com>

On Mon, 1 Aug 2022 07:07:18 GMT, GGGGGHT <duke at openjdk.org> wrote:

> (capacity + capacity>>1) The result of this expression is still capacity. So I guess what the author thought at the time might be (capacity + (capacity >> 1)), see https://bugs.openjdk.org/projects/JDK/issues/JDK-8292022

Hi, please send me an e-mail at Dalibor.topic at oracle.com so that I can verify your account's OCA.

-------------

PR: https://git.openjdk.org/jdk/pull/9698

From duke at openjdk.org  Mon Aug  8 06:30:36 2022
From: duke at openjdk.org (GGGGGHT)
Date: Mon, 8 Aug 2022 06:30:36 GMT
Subject: RFR: 8292022: Unary Plus Operator + and Shift Operators priority
In-Reply-To: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
References: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
Message-ID: <UvjDwAyjfyMZAbUV8BSuOPn0M6ouZsCkTTFif1m0I3A=.e65d4300-e86a-4e35-af28-c6a32b34758b@github.com>

On Mon, 1 Aug 2022 07:07:18 GMT, GGGGGHT <duke at openjdk.org> wrote:

> (capacity + capacity>>1) The result of this expression is still capacity. So I guess what the author thought at the time might be (capacity + (capacity >> 1)), see https://bugs.openjdk.org/projects/JDK/issues/JDK-8292022

> Hi, please send me an e-mail at [Dalibor.topic at oracle.com](mailto:Dalibor.topic at oracle.com) so that I can verify your account's OCA.

I have sent the mail

-------------

PR: https://git.openjdk.org/jdk/pull/9698

From vromero at openjdk.org  Mon Aug  8 16:24:13 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 8 Aug 2022 16:24:13 GMT
Subject: RFR: JDK-8289249: Add methods to Elements for record constructors
In-Reply-To: <lc70CZBBBbg-xY3rUXA3YBiqh4npeROdgSTfZLBZDPs=.65cc40a8-5931-4948-9df6-ed89b14aeab8@github.com>
References: <JZR71kWBbKEyEI8aEnqzFNyBeB-w-of6WEOkobyCtkM=.cc7a6c2e-ae09-4a62-b3a2-58e10bc3161e@github.com>
 <FHT_KX8D2jd0d3ZJkWpF9o0h35O4B1bIqR_m3g01YTw=.e53c1152-886b-4158-b505-fbae0f4e28d5@github.com>
 <lc70CZBBBbg-xY3rUXA3YBiqh4npeROdgSTfZLBZDPs=.65cc40a8-5931-4948-9df6-ed89b14aeab8@github.com>
Message-ID: <spuS5q4093xsN7wPRcGW5TXNram9GN3XVSAjJIWCf_k=.ec098f9f-0776-47a4-89d8-dab6fec2be40@github.com>

On Fri, 5 Aug 2022 22:43:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/langtools/tools/javac/processing/model/util/elements/TestRecordPredicates.java line 110:
>> 
>>> 108:     }
>>> 109: 
>>> 110:     @ExpectedPredicates(isCompact=true, isCanonical=true)
>> 
>> side: this is uncovering a bug in the compiler, isCanonical should be false in this case. I have filed JDK-8291914 to address this issue
>
> Part of the regression tests for  JDK-8291914 already written then :-)

:)

-------------

PR: https://git.openjdk.org/jdk/pull/9694

From hannesgreule at outlook.de  Mon Aug  8 19:21:29 2022
From: hannesgreule at outlook.de (Hannes Greule)
Date: Mon, 8 Aug 2022 21:21:29 +0200
Subject: Fwd: Mandated/implicit parameters
In-Reply-To: <AM0PR03MB4577C7150B97F6DB14849729AFA79@AM0PR03MB4577.eurprd03.prod.outlook.com>
References: <AM0PR03MB457746B3A0FE7D594A26E452AFD69@AM0PR03MB4577.eurprd03.prod.outlook.com>
 <CABe8uE2gMRi8AjSEjJ0dARo0VFmOfVsZgKPJCWNVdvSN=i5B-Q@mail.gmail.com>
 <CABe8uE0LFFFmR9hqYLsaahAeOeaO-MVSjY8C6Q5zF2-qS_EVAQ@mail.gmail.com>
 <AM0PR03MB4577F94DC0D765573242D1DDAFA59@AM0PR03MB4577.eurprd03.prod.outlook.com>
 <CABe8uE1BWkoG0iKMH3Aw-p=XNc1jF_Zz3E3HRs9BcbDJwPNOPA@mail.gmail.com>
 <AM0PR03MB4577C7150B97F6DB14849729AFA79@AM0PR03MB4577.eurprd03.prod.outlook.com>
Message-ID: <AM0PR03MB457773EF7A9D6E09889A961CAF639@AM0PR03MB4577.eurprd03.prod.outlook.com>

I finally found some time to come back to this.

I applied changes to also include the attribute if synthetic parameters 
are present. I only have tests for the mandated flag for now, as I don't 
know all the cases where synthetic parameters are emitted (and as that 
might change at any time, such tests would be hard to maintain probably).

I also wrote a test for annotated parameter types in core reflection, 
however it seems like my code does not fix it in the case of enum ctors. 
Therefore I did not include it, as I think that should be addressed 
separately.

The ClassReader now also works with unnamed parameters in the 
MethodParameter attribute, and reads from the LVT instead if present.

I submitted a report on https://bugs.java.com/ and awaiting response 
there. Once it's added to the bug tracker, I'll open a PR as I think my 
changes are ready for review.

Greetings
Hannes

On 09.06.2022 18:09, Hannes Greule wrote:
>  > Your patch looks nice. I suggest, in addition, to write the attribute
>  > when any synthetic parameter is present as well (such as the first two
>  > String and int of enum constructors).
> 
> Thank you. I'll look into synthetic parameters too.
> 
>  > In addition, I would recommend a
>  > test for core reflection to ensure the newly emitted attributes allow
>  > core reflection to correctly describe the parameterized types of inner
>  > class constructors, etc.
> 
> I think I also need a test for the compiler output. I'll start working 
> on that.
> 
>  > Once you can find a related issue on the bug tracker (or report one at
>  > https://bugs.java.com/ if you can't find a fitting one), you can
>  > submit this patch for that bug tracker issue.
> 
> I found JDK-8213329: Normalize inclusion of non-explicit parameters in 
> JVM attributes[1] but that doesn't really fit the issue. I'll report a 
> new one.
> 
>  > For the ClassReader, I think you may need a `index++;` before the
>  > `continue;`, as that would better match the behavior of
>  > LocalVariableTable register-based index assigning.
> 
> I looked into that a bit more. It seems more complicated as the 
> ClassReader reads names from both the LocalVariableTable and the 
> MethodParameters attribute if both are present. However, if the 
> MethodParameters attribute is read after the LocalVariableTable, it will 
> replace names from the LocalVariableTable. This causes issues if no 
> names are written to the MethodParameters attribute.
> I'm not sure what the best approach would be here, especially as 
> indexing is different (due to the slot for `this` in non-static 
> methods/ctors).
> 
> [1] https://bugs.openjdk.org/browse/JDK-8213329

From forax at univ-mlv.fr  Mon Aug  8 21:51:37 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 8 Aug 2022 23:51:37 +0200 (CEST)
Subject: [External] : Re: RFR: 8291769: Translation of switch with
 record patterns could be improved
In-Reply-To: <24396b95-7750-5fd2-a784-fe3d78423d2a@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
 <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
 <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
 <787533739.19552932.1659860345551.JavaMail.zimbra@u-pem.fr>
 <24396b95-7750-5fd2-a784-fe3d78423d2a@oracle.com>
Message-ID: <75179720.19940169.1659995497309.JavaMail.zimbra@u-pem.fr>

> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>,
> "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, August 7, 2022 11:22:28 AM
> Subject: Re: [External] : Re: RFR: 8291769: Translation of switch with record
> patterns could be improved

> On 07. 08. 22 10:19, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> [...]

>>>> "provide new bindings" => do you have an example of that ?

>>> Sure:

>>> public class TA {
>>> public static void main(String... args) {
>>> Object o = new Box("");
>>> switch (o) {
>>> case Box b when b.o() instanceof String s -> System.err.println(s);
>>> default -> {}
>>> }
>>> }
>>> record Box(Object o) {}
>>> }

>>> (There can be any number of new bindings from the guard, of course.)

>>>> I don't think a guard should be allowed to do that. It looks like a big gunfoot
>>>> to me.

>>> I believe the current specification supports guards that introduce new bindings:

>>> [
>>> http://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-6.3.4
>>> |
>>> http://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-6.3.4
>>> ]

>>> To me, it seems desirable. In any case, an implementation PR is probably not
>>> very well suited to discuss opinions on what should be specced. In particular
>>> (but not only) a PR that is not expected to change the semantics.
>> Ok, thanks for the example, it means we should lift the when expression not has
>> a static method but as a static pattern method, something which will be more
>> clear when we will have a better idea about how to do that once user defined
>> pattern method like Optional.of(value -> ...) will be introduced.

> Which I guess leaves as with a question: what are we going to do until user
> patterns are defined. Do we keep the current slow code, or do we try to improve
> that (which is that this PR is trying to do)? (And maybe learn something in the
> process.)
I'm ok with this PR but in the long term i hope we can make a better job. 
I still fear people re-organizing their patterns to get more performance instead of getting good performance out of the box. 

> Jan
R?mi 

>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220808/a1ddf45d/attachment.htm>

From forax at univ-mlv.fr  Mon Aug  8 22:05:42 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 9 Aug 2022 00:05:42 +0200 (CEST)
Subject: [External] : Re: RFR: 8291769: Translation of switch with
 record patterns could be improved
In-Reply-To: <a44d15fc-e124-fe63-ef3d-e69ce71b7d06@oracle.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
 <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
 <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
 <36794892.19552004.1659859352180.JavaMail.zimbra@u-pem.fr>
 <a44d15fc-e124-fe63-ef3d-e69ce71b7d06@oracle.com>
Message-ID: <1709510871.19940633.1659996342020.JavaMail.zimbra@u-pem.fr>

> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>,
> "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, August 7, 2022 11:17:16 AM
> Subject: Re: [External] : Re: RFR: 8291769: Translation of switch with record
> patterns could be improved

> On 07. 08. 22 10:02, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>> From: "jan lahoda" [ mailto:jan.lahoda at oracle.com | <jan.lahoda at oracle.com> ]
>>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ]
>>> Cc: "Jan Lahoda" [ mailto:jlahoda at openjdk.org | <jlahoda at openjdk.org> ] , "Brian
>>> Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ] ,
>>> "compiler-dev" [ mailto:compiler-dev at openjdk.org | <compiler-dev at openjdk.org> ]
>>> Sent: Friday, August 5, 2022 11:54:05 PM
>>> Subject: Re: [External] : Re: RFR: 8291769: Translation of switch with record
>>> patterns could be improved

>>> On 05. 08. 22 22:52, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>>> [...]

>>>>>>> In any case, I'm a bit afraid that we could enhance a translation patch
>>>>>>> forever, always adding new cases that can be optimized. So, I think we
>>>>>>> need to draw a line somewhere where the patch provides a benefit while
>>>>>>> still being testable and reviewable. With a possible separate
>>>>>>> improvements, if they prove to be useful. It is possible I haven't drawn
>>>>>>> the line far enough, but looking at the patch, it seems complex enough.

>>>>>> I think the issue is that a list of pattern is not the right intermediary
>>>>>> structure to try to optimize the pattern matching, a decision tree is a better
>>>>>> intermediary representation (this is how pattern matching is usually optimized,
>>>>>> i've not invented something new :) )

>>>>>> Here is an example of such decision tree: [
>>>>>> https://urldefense.com/v3/__https://github.com/forax/switch-pattern-combinator__;!!ACWV5N9M2RV99hQ!JevAQE8IkRf4n-BMKA2sMTNFfJ5sAyJ1xopR2O9rq_45-xqaHOgirecR8E4zIGB_RgMb27G3tlcHEuGADjk$
>>>>>> |
>>>>>> https://urldefense.com/v3/__https://github.com/forax/switch-pattern-combinator__;!!ACWV5N9M2RV99hQ!JevAQE8IkRf4n-BMKA2sMTNFfJ5sAyJ1xopR2O9rq_45-xqaHOgirecR8E4zIGB_RgMb27G3tlcHEuGADjk$
>>>>>> ]

>>>>> I am not really opposed to having an intermediate structure, but I think
>>>>> the overall cost of the structure is likely to be significant, and it
>>>>> should provide significantly better code to offset that.

>>>> I agree.

>>>>> Looking at the page, I see:

>>>>> The advantage of a decision tree is that if two patterns have a common
>>>>> prefix, the code for the common prefix is generated only once.

>>>>> I wonder if there's a *conceptual* difference between what this PR is
>>>>> doing and what your code is doing. The PR here is trying to take common
>>>>> prefixes (of viable cases) and generate code for them only once. I don't
>>>>> think that not optimizing

>>>>> case A(String s) -> {}

>>>>> case A a -> {}

>>>>> is a conceptual difference, but if this is something that is seen as
>>>>> critical, I am fairly sure I can implement that without creating a brand
>>>>> new structure and code to convert the AST into it and back.

>>>> You need the intermediary structure when the common prefix are not subsequent

>>>> case A(B b) ->
>>>> case B(A a) ->
>>>> case A(C c) ->

>>>> Here the first and the last case shares a common prefix.

>>> Sorry, but I don't see why I can't do this particular thing without a
>>> specialized intermediate representation.
>> The patterns are a partial orders, because we can optimize the ones with a
>> common prefix, we need a sort, a decision tree is equivalent to a sort.
>> There are several advantages to use a decision tree instead of a sort,
>> - it's easier to visualize
>> - it mimics the the usual hand-written code (you don't repeat the instanceofs,
>> you enclose them)
>> - i believe that for the code generation, doing local decisions on each node is
>> good enough, we do not need to propagate information in between nodes.

> Yes, the current PR does not do reordering of cases. It could, I just didn't
> think of the rules too much in principle, and didn't want to make the patch
> overly complex or break something.

> I guess I can visualize the AST nodes quite fine.

>>> A bigger question, I think, is when it is safe to do so, and when not.
>> yes, not all re-ordering are safe, we need to keep some constraints.
>> Fortunately, the ordering problems only arise when there are guards.

> I think it is much more than (complex) guards. Like, for example:

> record R(Object o) {}

> interface I {}

> case R(String s) -> {}

> case I i -> {}

> case R(Integer i) -> {}

> Now, can we change the order of "I" and "R(Integer i)"? If we do and if we
> don't, the runtime behavior can differ in case of separate compilation when "R"
> is changed to implement "I".

> But, even for:

> final class A {}

> final class B {}

> case A a when ... -> {}

> case B b -> {}

> case A a -> {}

> Can we change the order of the cases? I am not sure, because, again, with
> separate compilation, this can lead to a different outcome.
I think we are switching subject and entering into the "what guarantee we should provide to user with respect to separate compilation ?". 

One problem i see is that in practice it is likely that the definition of the data have changed but the patterns have not be recompiled so the patterns are now wrongs. 
(Pattern Matching is about data oriented programming, where data definition are more important than the algorithms/computation on the data) 

So perfectly executing a stale list of patterns is not that useful in my opinion. 

> And maybe the answer is that we can do reordering in these cases. Or maybe we
> can in some of these cases, and can't in orders. I don't think this was ever
> discussed in depth.
i agree it should be discussed more. 

> Some of these decisions would be easier if we did the decision at runtime, of
> course. Which brings its own problems, as discussed elsewhere.
I'm not even sure that it's easier at runtime because of erasure, patterns are correctly typecked or not depending on the types, but at runtime we only have class with the generic information erased, 
so apart if we decide to fully duplicate the whole typechecking done at compile time to redo it at runtime, the information we have at runtime does not help us that much. 

>> The idea is that for each node of the decision tree, you should generate the
>> code in that order, first for the record pattern, then the code for the guards
>> then the code for the type pattern, in that order.

> The current PR first generates (an analog of) the instanceof of the record type,
> then code for the nested patterns, and then the guard of the case. Which allows
> to join the cases into nested switches (or ifs, if we go there). Not sure what
> is wrong with that?
It's not wrong, but by only merging subsequent patterns you are creating an arcane knowledge of writing the patterns "the right way" to get more performance. 
It's not really an issue now because record patterns are still a preview feature but it's a serious issue in the long run. 

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220809/dcd910f6/attachment-0001.htm>

From jan.lahoda at oracle.com  Tue Aug  9 06:53:45 2022
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 9 Aug 2022 08:53:45 +0200
Subject: [External] : Re: RFR: 8291769: Translation of switch with record
 patterns could be improved
In-Reply-To: <1709510871.19940633.1659996342020.JavaMail.zimbra@u-pem.fr>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <d3e539d8-7b1c-6065-9bcf-679cb9b590e8@oracle.com>
 <492883987.19041312.1659720241793.JavaMail.zimbra@u-pem.fr>
 <883b8aa0-341e-dfee-5a6a-cc4c29b84d25@oracle.com>
 <1724934379.19079517.1659732755546.JavaMail.zimbra@u-pem.fr>
 <cc3f8932-1961-4352-af3a-f47e60d872db@oracle.com>
 <36794892.19552004.1659859352180.JavaMail.zimbra@u-pem.fr>
 <a44d15fc-e124-fe63-ef3d-e69ce71b7d06@oracle.com>
 <1709510871.19940633.1659996342020.JavaMail.zimbra@u-pem.fr>
Message-ID: <d5114986-e373-ef7a-6771-192663ddba2b@oracle.com>

On 09. 08. 22 0:05, forax at univ-mlv.fr wrote:

>
>
> ------------------------------------------------------------------------
>
>     *From: *"jan lahoda" <jan.lahoda at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>
>     *Cc: *"Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz"
>     <brian.goetz at oracle.com>, "compiler-dev" <compiler-dev at openjdk.org>
>     *Sent: *Sunday, August 7, 2022 11:17:16 AM
>     *Subject: *Re: [External] : Re: RFR: 8291769: Translation of
>     switch with record patterns could be improved
>
>     On 07. 08. 22 10:02, forax at univ-mlv.fr wrote:
>
>
>
>         ------------------------------------------------------------------------
>
>             *From: *"jan lahoda" <jan.lahoda at oracle.com>
>             *To: *"Remi Forax" <forax at univ-mlv.fr>
>             *Cc: *"Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz"
>             <brian.goetz at oracle.com>, "compiler-dev"
>             <compiler-dev at openjdk.org>
>             *Sent: *Friday, August 5, 2022 11:54:05 PM
>             *Subject: *Re: [External] : Re: RFR: 8291769: Translation
>             of switch with record patterns could be improved
>
>             On 05. 08. 22 22:52, forax at univ-mlv.fr wrote:
>
>                 [...]
>
>                             In any case, I'm a bit afraid that we could enhance a translation patch
>                             forever, always adding new cases that can be optimized. So, I think we
>                             need to draw a line somewhere where the patch provides a benefit while
>                             still being testable and reviewable. With a possible separate
>                             improvements, if they prove to be useful. It is possible I haven't drawn
>                             the line far enough, but looking at the patch, it seems complex enough.
>
>                         I think the issue is that a list of pattern is not the right intermediary
>                         structure to try to optimize the pattern matching, a decision tree is a better
>                         intermediary representation (this is how pattern matching is usually optimized,
>                         i've not invented something new :) )
>
>                         Here is an example of such decision tree:
>                         https://urldefense.com/v3/__https://github.com/forax/switch-pattern-combinator__;!!ACWV5N9M2RV99hQ!JevAQE8IkRf4n-BMKA2sMTNFfJ5sAyJ1xopR2O9rq_45-xqaHOgirecR8E4zIGB_RgMb27G3tlcHEuGADjk$
>
>                     I am not really opposed to having an intermediate structure, but I think
>                     the overall cost of the structure is likely to be significant, and it
>                     should provide significantly better code to offset that.
>
>                 I agree.
>
>                     Looking at the page, I see:
>
>                     The advantage of a decision tree is that if two patterns have a common
>                     prefix, the code for the common prefix is generated only once.
>
>
>                     I wonder if there's a *conceptual* difference between what this PR is
>                     doing and what your code is doing. The PR here is trying to take common
>                     prefixes (of viable cases) and generate code for them only once. I don't
>                     think that not optimizing
>
>                     case A(String s) -> {}
>
>                     case A a -> {}
>
>                     is a conceptual difference, but if this is something that is seen as
>                     critical, I am fairly sure I can implement that without creating a brand
>                     new structure and code to convert the AST into it and back.
>
>                 You need the intermediary structure when the common prefix are not subsequent
>
>                 case A(B b) ->
>                 case B(A a) ->
>                 case A(C c) ->
>
>                 Here the first and the last case shares a common prefix.
>
>
>             Sorry, but I don't see why I can't do this particular
>             thing without a specialized intermediate representation.
>
>
>         The patterns are a partial orders, because we can optimize the
>         ones with a common prefix, we need a sort, a decision tree is
>         equivalent to a sort.
>         There are several advantages to use a decision tree instead of
>         a sort,
>         - it's easier to visualize
>         - it mimics the the usual hand-written code (you don't repeat
>         the instanceofs, you enclose them)
>         - i believe that for the code generation, doing local
>         decisions on each node is good enough, we do not need to
>         propagate information in between nodes.
>
>
>     Yes, the current PR does not do reordering of cases. It could, I
>     just didn't think of the rules too much in principle, and didn't
>     want to make the patch overly complex or break something.
>
>
>     I guess I can visualize the AST nodes quite fine.
>
>
>
>             A bigger question, I think, is when it is safe to do so,
>             and when not.
>
>
>         yes, not all re-ordering are safe, we need to keep some
>         constraints. Fortunately, the ordering problems only arise
>         when there are guards.
>
>
>     I think it is much more than (complex) guards. Like, for example:
>
>     record R(Object o) {}
>
>     interface I {}
>
>
>     case R(String s) -> {}
>
>     case I i -> {}
>
>     case R(Integer i) -> {}
>
>
>     Now, can we change the order of "I" and "R(Integer i)"? If we do
>     and if we don't, the runtime behavior can differ in case of
>     separate compilation when "R" is changed to implement "I".
>
>
>     But, even for:
>
>     final class A {}
>
>     final class B {}
>
>
>     case A a when ... -> {}
>
>     case B b -> {}
>
>     case A a -> {}
>
>
>     Can we change the order of the cases? I am not sure, because,
>     again, with separate compilation, this can lead to a different
>     outcome.
>
>
> I think we are switching subject and entering into the "what guarantee 
> we should provide to user with respect to separate compilation ?".


I don't think this is switching subject. This is still the same 
question: when it is safe to change the order the cases.


>
> One problem i see is that in practice it is likely that the definition 
> of the data have changed but the patterns have not be recompiled so 
> the patterns are now wrongs.
> (Pattern Matching is about data oriented programming, where data 
> definition are more important than the algorithms/computation on the data)
>
> So perfectly executing a stale list of patterns is not that useful in 
> my opinion.


As I said - it is possible the answer is that we can reorder the cases 
in situations like this. But that's not a decision that should be made 
in an implementation PR.


>
>
>     And maybe the answer is that we can do reordering in these cases.
>     Or maybe we can in some of these cases, and can't in orders. I
>     don't think this was ever discussed in depth.
>
>
> i agree it should be discussed more.
>
>
>
>     Some of these decisions would be easier if we did the decision at
>     runtime, of course. Which brings its own problems, as discussed
>     elsewhere.
>
>
> I'm not even sure that it's easier at runtime because of erasure, 
> patterns are correctly typecked or not depending on the types, but at 
> runtime we only have class with the generic information erased,
> so apart if we decide to fully duplicate the whole typechecking done 
> at compile time to redo it at runtime, the information we have at 
> runtime does not help us that much.
>
>
>
>         The idea is that for each node of the decision tree, you
>         should generate the code in that order, first for the record
>         pattern, then the code for the guards then the code for the
>         type pattern, in that order.
>
>
>     The current PR first generates (an analog of) the instanceof of
>     the record type, then code for the nested patterns, and then the
>     guard of the case. Which allows to join the cases into nested
>     switches (or ifs, if we go there). Not sure what is wrong with that?
>
>
> It's not wrong, but by only merging subsequent patterns you are 
> creating an arcane knowledge of writing the patterns "the right way" 
> to get more performance.


As I've said several times, the current patch allows case reordering, 
but it is not clear which reorderings are safe, so it is not doing them. 
The implementation wouldn't be too difficult, I believe: while 
accummulating cases for a primary type X, when looking at case for a 
different primary type Y, we can evaluate whether it is fine to skip the 
current case, and if yes, we would continue and evaluate the next case. 
The most difficult part here is to decide which reordering is safe and 
which is not.


Overall, I am much more worried about not introducing a wrong behavior. 
We've been changing translations of various constructs in the past, 
while keeping behavior, and while that is not ideal, it was not that 
much problematic either. We've made changes to String concatenation and 
try-with-resources, for example. Fixing broken behavior is likely to be 
much more difficult.


Jan


> It's not really an issue now because record patterns are still a 
> preview feature but it's a serious issue in the long run.
>
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220809/08805cb6/attachment-0001.htm>

From jlahoda at openjdk.org  Tue Aug  9 09:37:14 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Aug 2022 09:37:14 GMT
Subject: RFR: 7194212: NPE in Flow.visitIdent [v2]
In-Reply-To: <ata8yNXB-KSWpLrfUUS2_W4__kQCxkBYK-j8itCCR0s=.0fd12b0b-f2c6-49a7-a107-da29779a097c@github.com>
References: <ata8yNXB-KSWpLrfUUS2_W4__kQCxkBYK-j8itCCR0s=.0fd12b0b-f2c6-49a7-a107-da29779a097c@github.com>
Message-ID: <_rQyHWncNzYt7rSeyBsimQDX0pDwfaoFRpSG8oP1FSQ=.967af9be-d9bf-473e-8295-92f24d911435@github.com>

> A somewhat corner-case issue, but consider a case where classfiles for:
> 
> 
> public class Outer {
>     public class Inner { }
> }
> 
> 
> Are on a classpath while compiling:
> 
> 
> public class Outer$Inner extends Outer { }
> 
> 
> This leads to a crash in javac (in Flow), because when Outer is completed, its InnerClasses attribute is read, and, based on it, the flags_field of Outer$Inner is (re)set (and it is put as an nested class to Outer, although that is not correct). But the flags_field used to contain UNATTRIBUTED flag. As this flag is cleared, the method bodies for Outer$Inner are never attributed (its default constructor in this case), which ultimately leads to the crash in Flow.
> 
> The proposed patch is to ensure the InnerClasses entry is ignored if we are compiling a same-named class from source. The cost is yet another Flag bit.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Fixing years.
 - Adding comment.
 - Fixing test.
 - Merge branch 'master' into JDK-7194212
 - Fixing FlagsTest.
 - 7194212: NPE in Flow.visitIdent

-------------

Changes: https://git.openjdk.org/jdk/pull/1326/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=1326&range=01
  Stats: 120 lines in 6 files changed: 110 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/1326.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/1326/head:pull/1326

PR: https://git.openjdk.org/jdk/pull/1326

From asemenyuk at openjdk.org  Tue Aug  9 17:53:36 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 9 Aug 2022 17:53:36 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
Message-ID: <k6yuO7WWfo6sUSzqiUmIpuktBZjIi1IlHrmDkULvDvY=.bd053666-f50f-4777-9377-0df00efd5fa5@github.com>

On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good. Approved that part.

-------------

PR: https://git.openjdk.org/jdk19/pull/154

From achung at openjdk.org  Tue Aug  9 22:30:54 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 9 Aug 2022 22:30:54 GMT
Subject: [jdk19] Integrated: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <q3eKnCK-mTAP42I8K9ifRoP0RBS0nLNwsGoZpEt_e0A=.5da69e5f-4232-40e4-8f69-ccae924fcd3a@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

This pull request has now been integrated.

Changeset: 0def5316
Author:    Alisen Chung <achung at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/0def5316cd2ec7699c649bf67bf58e6315c3010b
Stats:     684 lines in 42 files changed: 87 ins; 540 del; 57 mod

8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10

Reviewed-by: naoto, asemenyuk

-------------

PR: https://git.openjdk.org/jdk19/pull/154

From dholmes at openjdk.org  Thu Aug 11 05:26:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Aug 2022 05:26:56 GMT
Subject: Integrated: Merge jdk19
Message-ID: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>

Forward port JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8288769: Revert unintentional change to deflate.c
 - 8291496: Allocating card table before heap causes underflow asserts in CardTable::addr_for()
 - 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9828/files
  Stats: 686 lines in 44 files changed: 89 ins; 540 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/9828.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9828/head:pull/9828

PR: https://git.openjdk.org/jdk/pull/9828

From dholmes at openjdk.org  Thu Aug 11 05:26:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Aug 2022 05:26:56 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>
References: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>
Message-ID: <tDsmxM0i7TDUsE501WbVPMDEMsZb2_d1PaZb84pVJQI=.4b33399d-425a-44ee-a1b3-ea91f25f487e@github.com>

On Thu, 11 Aug 2022 00:06:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 85a60235
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85a602355ff6e92bb468135d712e0b0b41753db4
Stats:     686 lines in 44 files changed: 89 ins; 540 del; 57 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9828

From vromero at openjdk.org  Thu Aug 11 18:03:25 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Aug 2022 18:03:25 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v3]
In-Reply-To: <aoBpIxW7ZSErqezUcfyVhwFLKxvg_Kj8-xSzEro8lBg=.b585ff3e-a769-4751-8325-87979ac2a766@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <aoBpIxW7ZSErqezUcfyVhwFLKxvg_Kj8-xSzEro8lBg=.b585ff3e-a769-4751-8325-87979ac2a766@github.com>
Message-ID: <MsxNfq9jh-r6s7syEYN_fscbVRCxtKZ5F7m21h4u0-w=.214c0eb0-5b5d-47c3-b753-f685f1c8073c@github.com>

On Fri, 5 Aug 2022 13:51:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 209:

> 207:             JCExpression extraConditions = null;
> 208:             if (pattern instanceof JCRecordPattern recordPattern) {
> 209:                 Pair<JCBindingPattern, JCExpression> unrolledRecordPattern = unrollRecordPattern(recordPattern);

nit: `unrollRecordPattern` could return a record

-------------

PR: https://git.openjdk.org/jdk/pull/9746

From vromero at openjdk.org  Thu Aug 11 18:16:24 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Aug 2022 18:16:24 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v3]
In-Reply-To: <aoBpIxW7ZSErqezUcfyVhwFLKxvg_Kj8-xSzEro8lBg=.b585ff3e-a769-4751-8325-87979ac2a766@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <aoBpIxW7ZSErqezUcfyVhwFLKxvg_Kj8-xSzEro8lBg=.b585ff3e-a769-4751-8325-87979ac2a766@github.com>
Message-ID: <GCkS4kQOMDfZ20xXqDskrhh07Zex36FyxpljKbfqFZY=.43c0e616-42ee-4813-897f-6a0e5b7b3a22@github.com>

On Fri, 5 Aug 2022 13:51:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test.

just curious: is there any performance degradation in the compilation time while compiling `long` test cases?

-------------

PR: https://git.openjdk.org/jdk/pull/9746

From jlahoda at openjdk.org  Fri Aug 12 08:16:13 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 12 Aug 2022 08:16:13 GMT
Subject: Integrated: 7194212: NPE in Flow.visitIdent
In-Reply-To: <ata8yNXB-KSWpLrfUUS2_W4__kQCxkBYK-j8itCCR0s=.0fd12b0b-f2c6-49a7-a107-da29779a097c@github.com>
References: <ata8yNXB-KSWpLrfUUS2_W4__kQCxkBYK-j8itCCR0s=.0fd12b0b-f2c6-49a7-a107-da29779a097c@github.com>
Message-ID: <2_D5C1WNaFf2c4DS17lovqWBKBj90dkXCXu6tMkcy20=.1c5f841f-d819-465e-a376-0bd8d9e9dac5@github.com>

On Thu, 19 Nov 2020 18:24:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A somewhat corner-case issue, but consider a case where classfiles for:
> 
> 
> public class Outer {
>     public class Inner { }
> }
> 
> 
> Are on a classpath while compiling:
> 
> 
> public class Outer$Inner extends Outer { }
> 
> 
> This leads to a crash in javac (in Flow), because when Outer is completed, its InnerClasses attribute is read, and, based on it, the flags_field of Outer$Inner is (re)set (and it is put as an nested class to Outer, although that is not correct). But the flags_field used to contain UNATTRIBUTED flag. As this flag is cleared, the method bodies for Outer$Inner are never attributed (its default constructor in this case), which ultimately leads to the crash in Flow.
> 
> The proposed patch is to ensure the InnerClasses entry is ignored if we are compiling a same-named class from source. The cost is yet another Flag bit.

This pull request has now been integrated.

Changeset: 0c40128f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c40128fec41cf69821dbf7f1b19600560e8ac12
Stats:     120 lines in 6 files changed: 110 ins; 1 del; 9 mod

7194212: NPE in Flow.visitIdent

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/1326

From jlahoda at openjdk.org  Fri Aug 12 09:00:17 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 12 Aug 2022 09:00:17 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v3]
In-Reply-To: <GCkS4kQOMDfZ20xXqDskrhh07Zex36FyxpljKbfqFZY=.43c0e616-42ee-4813-897f-6a0e5b7b3a22@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <aoBpIxW7ZSErqezUcfyVhwFLKxvg_Kj8-xSzEro8lBg=.b585ff3e-a769-4751-8325-87979ac2a766@github.com>
 <GCkS4kQOMDfZ20xXqDskrhh07Zex36FyxpljKbfqFZY=.43c0e616-42ee-4813-897f-6a0e5b7b3a22@github.com>
Message-ID: <AJESo0rnXwDQ58SI34l3SLCuoVBehnCDqLiPsp36LDE=.88e22301-f83f-464d-9410-417a6eda3a1d@github.com>

On Thu, 11 Aug 2022 18:12:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> just curious: is there any performance degradation in the compilation time while compiling `long` test cases?

I tried with a switch with 512+1 cases (record pattern for triplet, with nested record patterns for triplets), and on an informal test, the time seems to be roughly the same with and without this patch. (The switch is too big for a classfile without this patch, so the compilation fails during code generation without this patch.)

-------------

PR: https://git.openjdk.org/jdk/pull/9746

From jlahoda at openjdk.org  Fri Aug 12 12:09:11 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 12 Aug 2022 12:09:11 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v4]
In-Reply-To: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
Message-ID: <9EyfJQRNLhKu2mqV7gEi7CJbYBSaD3Jno8Sd5MpjWQA=.b0c34a00-e0c0-4653-ba29-59319612f369@github.com>

> This is an attempt to improve the performance and scalability of switches with record patterns.
> 
> There are two main parts of this patch:
> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
> 
> switch (obj) {
>      case Box(String s) -> {}
>      case Box(Integer i) -> {}
>      case Box(Number n) -> {}
>      ...
> }
> =>
> switch (obj) {
>      case Box b ->
>           switch (b.o()) {
>               case String s -> {}
>               case Integer i -> {}
>               case Number n -> {}
>               default -> continue-with-outer-switch;
>           };
>     ...
> }
> 
> 
> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
> 
> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
> 
> I ran the new code through a JMH benchmark:
> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
> 
> The results are:
>  - for "long" testcase (a switch with many cases):
> 
> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
> 
>  - for "short" testcase (a switch with no so many cases):
> 
> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
> 
> 
> So, the performance seems to be improved, at least in these cases.
> 
> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Using a custom record instead of a generic Pair.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9746/files
  - new: https://git.openjdk.org/jdk/pull/9746/files/e842486d..1ff63342

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=02-03

  Stats: 19 lines in 1 file changed: 3 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/9746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9746/head:pull/9746

PR: https://git.openjdk.org/jdk/pull/9746

From vromero at openjdk.org  Fri Aug 12 13:29:11 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Aug 2022 13:29:11 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v3]
In-Reply-To: <AJESo0rnXwDQ58SI34l3SLCuoVBehnCDqLiPsp36LDE=.88e22301-f83f-464d-9410-417a6eda3a1d@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <aoBpIxW7ZSErqezUcfyVhwFLKxvg_Kj8-xSzEro8lBg=.b585ff3e-a769-4751-8325-87979ac2a766@github.com>
 <GCkS4kQOMDfZ20xXqDskrhh07Zex36FyxpljKbfqFZY=.43c0e616-42ee-4813-897f-6a0e5b7b3a22@github.com>
 <AJESo0rnXwDQ58SI34l3SLCuoVBehnCDqLiPsp36LDE=.88e22301-f83f-464d-9410-417a6eda3a1d@github.com>
Message-ID: <ikj0Yc4cO9hDhSRij0NtKl0QPWKv7Nesc0gy9j3SdDg=.bdeac17b-1f6e-44d4-bf0e-5dea5b05918f@github.com>

On Fri, 12 Aug 2022 08:56:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > just curious: is there any performance degradation in the compilation time while compiling `long` test cases?
> 
> I tried with a switch with 512+1 cases (record pattern for triplet, with nested record patterns for triplets), and on an informal test, the time seems to be roughly the same with and without this patch. (The switch is too big for a classfile without this patch, so the compilation fails during code generation without this patch.)

nice, thanks

-------------

PR: https://git.openjdk.org/jdk/pull/9746

From vromero at openjdk.org  Fri Aug 12 19:37:17 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Aug 2022 19:37:17 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v4]
In-Reply-To: <9EyfJQRNLhKu2mqV7gEi7CJbYBSaD3Jno8Sd5MpjWQA=.b0c34a00-e0c0-4653-ba29-59319612f369@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <9EyfJQRNLhKu2mqV7gEi7CJbYBSaD3Jno8Sd5MpjWQA=.b0c34a00-e0c0-4653-ba29-59319612f369@github.com>
Message-ID: <r8vswKCrVyekhcsqKnulzOgImYdQXoFYWPEIMGKN1Xs=.c68d84bc-3c6a-424d-a9c4-3f7073bee183@github.com>

On Fri, 12 Aug 2022 12:09:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using a custom record instead of a generic Pair.

test/langtools/tools/javac/patterns/DeconstructionDesugaring.java line 78:

> 76:     private int runCheckExpression(Object o) {
> 77:         return switch (o) {
> 78:             case (((R1((((R2((((String s))))))))))) -> 1;

general notes on the tests, they are very complete, but I think that we need to add records with varargs components as in:

record R(int... indices) {}

and records with annotations on their components that are also preprocessed with annotation processors.

-------------

PR: https://git.openjdk.org/jdk/pull/9746

From duke at openjdk.org  Fri Aug 12 20:22:17 2022
From: duke at openjdk.org (Hannes Greule)
Date: Fri, 12 Aug 2022 20:22:17 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default
Message-ID: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>

With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
Parameter names are *not* emitted unless the `-parameter` flag is set.

The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.

The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
I also had to update some tests as they got a new constant pool entry.

Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
Please let me know if you want tests for specific appearances of synthetic parameters.

-------------

Commit messages:
 - remove spaces from empty lines in text block
 - add bug number to test
 - copyright
 - update constant pool indexes in AnnoTest
 - set mandated flag for parameters of compact constructor
 - add javac testcase for implicit parameters
 - combine parameter names from LVT and MethodParameters
 - also require flags for synthetic
 - revert valueOf hack
 - adapt change to constant pool in test
 - ... and 4 more: https://git.openjdk.org/jdk/compare/9f8cc421...c9ba84c7

Changes: https://git.openjdk.org/jdk/pull/9862/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292275
  Stats: 316 lines in 7 files changed: 210 ins; 23 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/9862.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9862/head:pull/9862

PR: https://git.openjdk.org/jdk/pull/9862

From vromero at openjdk.org  Fri Aug 12 20:27:17 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Aug 2022 20:27:17 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v4]
In-Reply-To: <9EyfJQRNLhKu2mqV7gEi7CJbYBSaD3Jno8Sd5MpjWQA=.b0c34a00-e0c0-4653-ba29-59319612f369@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <9EyfJQRNLhKu2mqV7gEi7CJbYBSaD3Jno8Sd5MpjWQA=.b0c34a00-e0c0-4653-ba29-59319612f369@github.com>
Message-ID: <VSkqo9EggGybVRyZeI866-L9HQuwtFP7U_FFYwJBER4=.cb2ca7a2-69dc-4db3-92f0-88753afd3ca9@github.com>

On Fri, 12 Aug 2022 12:09:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using a custom record instead of a generic Pair.

side, although not related to this patch I think that the parser generated error messages the compiler issues for code like:


record Box(Object... o) {}

class Test {

    private int test(Object obj) {
        return switch (obj) {
            case Box(String... s) -> 0;
            default -> -1;
        };
    }
}

could be improved. I'm not suggesting this to be fixed as part of this patch though.

-------------

PR: https://git.openjdk.org/jdk/pull/9746

From vromero at openjdk.org  Fri Aug 12 20:54:14 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Aug 2022 20:54:14 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v4]
In-Reply-To: <9EyfJQRNLhKu2mqV7gEi7CJbYBSaD3Jno8Sd5MpjWQA=.b0c34a00-e0c0-4653-ba29-59319612f369@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <9EyfJQRNLhKu2mqV7gEi7CJbYBSaD3Jno8Sd5MpjWQA=.b0c34a00-e0c0-4653-ba29-59319612f369@github.com>
Message-ID: <G5NzitA5PYa_fRJ7l4j4YmoMvApSXgqGRMv8BKNYCyw=.859dcc14-183d-4ee7-ae76-6c466b21bc10@github.com>

On Fri, 12 Aug 2022 12:09:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using a custom record instead of a generic Pair.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 356:

> 354:             deconstructorCalls.add(componentAccessor);
> 355:             JCExpression accessedComponentValue =
> 356:                     convert(componentAccessor, componentType);//TODO - cast only when needed

I think this `TODO` comment can be removed

test/langtools/tools/javac/patterns/TypedDeconstructionPatternExc.java line 136:

> 134:     static final String EXCEPTION_MESSAGE = "exception-message";
> 135: 
> 136:     record Pair<L, R>(L l, R r) {

I think that for completeness we need records with generic record components, unless those are not accepted yet as record patterns

-------------

PR: https://git.openjdk.org/jdk/pull/9746

From darcy at openjdk.org  Fri Aug 12 22:41:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Aug 2022 22:41:30 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default
In-Reply-To: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
Message-ID: <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>

On Fri, 12 Aug 2022 19:54:59 GMT, Hannes Greule <duke at openjdk.org> wrote:

> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
> Parameter names are *not* emitted unless the `-parameter` flag is set.
> 
> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
> 
> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
> I also had to update some tests as they got a new constant pool entry.
> 
> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
> Please let me know if you want tests for specific appearances of synthetic parameters.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4023:

> 4021:                         tmpParams.add(F.at(param)
> 4022:                                 // we will get flags plus annotations from the record component
> 4023:                                 .VarDef(F.Modifiers(Flags.PARAMETER | Flags.GENERATED_MEMBER | Flags.MANDATED | param.mods.flags & Flags.VARARGS,

Should the use of MANDATED be conditional on the target class file version?

test/langtools/tools/javac/RequiredParameterFlags/ImplicitParameters.java line 52:

> 50: import toolbox.ToolBox;
> 51: 
> 52: public class ImplicitParameters extends TestRunner {

In addition to this test, an annotation processing-based test could also be attempted here.

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From darcy at openjdk.org  Fri Aug 12 22:41:31 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Aug 2022 22:41:31 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default
In-Reply-To: <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
Message-ID: <hh6s55_qsnNjQv8KnmA0s8W75Jd0MSPMqUkDoidg9UM=.be8927aa-b530-41b5-b24a-4f311b982236@github.com>

On Fri, 12 Aug 2022 22:36:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4023:
> 
>> 4021:                         tmpParams.add(F.at(param)
>> 4022:                                 // we will get flags plus annotations from the record component
>> 4023:                                 .VarDef(F.Modifiers(Flags.PARAMETER | Flags.GENERATED_MEMBER | Flags.MANDATED | param.mods.flags & Flags.VARARGS,
> 
> Should the use of MANDATED be conditional on the target class file version?

I advise also writing a core reflection test that uses access flags (java.lang.reflect.AccessFlag).

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From duke at openjdk.org  Sat Aug 13 17:03:57 2022
From: duke at openjdk.org (Hannes Greule)
Date: Sat, 13 Aug 2022 17:03:57 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default
In-Reply-To: <hh6s55_qsnNjQv8KnmA0s8W75Jd0MSPMqUkDoidg9UM=.be8927aa-b530-41b5-b24a-4f311b982236@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
 <hh6s55_qsnNjQv8KnmA0s8W75Jd0MSPMqUkDoidg9UM=.be8927aa-b530-41b5-b24a-4f311b982236@github.com>
Message-ID: <T9a_9ZLDNqvgQ8UGwe2etMxW8JbNR4U1Tvic-AoIVCA=.dec93355-bef2-40e7-a33e-f16b565a7243@github.com>

On Fri, 12 Aug 2022 22:38:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4023:
>> 
>>> 4021:                         tmpParams.add(F.at(param)
>>> 4022:                                 // we will get flags plus annotations from the record component
>>> 4023:                                 .VarDef(F.Modifiers(Flags.PARAMETER | Flags.GENERATED_MEMBER | Flags.MANDATED | param.mods.flags & Flags.VARARGS,
>> 
>> Should the use of MANDATED be conditional on the target class file version?
>
> I advise also writing a core reflection test that uses access flags (java.lang.reflect.AccessFlag).

> Should the use of MANDATED be conditional on the target class file version?

I don't think this is needed. The JLS mentions the parameters of canonical record constructors in Java 14 already. Previous versions don't have records and shouldn't enter that method at all.

> I advise also writing a core reflection test that uses access flags (java.lang.reflect.AccessFlag).

Will do. I assume the `jdk/java/lang/reflect/AccessFlag` folder is a good place for that?

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From darcy at openjdk.org  Sat Aug 13 17:16:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 13 Aug 2022 17:16:21 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default
In-Reply-To: <T9a_9ZLDNqvgQ8UGwe2etMxW8JbNR4U1Tvic-AoIVCA=.dec93355-bef2-40e7-a33e-f16b565a7243@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
 <hh6s55_qsnNjQv8KnmA0s8W75Jd0MSPMqUkDoidg9UM=.be8927aa-b530-41b5-b24a-4f311b982236@github.com>
 <T9a_9ZLDNqvgQ8UGwe2etMxW8JbNR4U1Tvic-AoIVCA=.dec93355-bef2-40e7-a33e-f16b565a7243@github.com>
Message-ID: <bSLmxmAx9CzWJ1dmHegTsXOb18yYTlgpQDfD_scTMSk=.f13fe0fb-4ec5-4db1-8513-fbcc4603be78@github.com>

On Sat, 13 Aug 2022 17:00:30 GMT, Hannes Greule <duke at openjdk.org> wrote:

> > Should the use of MANDATED be conditional on the target class file version?
> 
> I don't think this is needed. The JLS mentions the parameters of canonical record constructors in Java 14 already. Previous versions don't have records and shouldn't enter that method at all.

Agreed; I double-checked and the ACC_MANDATED flag was defined in that location since before JDK 14's format.

> 
> > I advise also writing a core reflection test that uses access flags (java.lang.reflect.AccessFlag).
> 
> Will do. I assume the `jdk/java/lang/reflect/AccessFlag` folder is a good place for that?

Yes; that an appropriate  home for such tests.

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From duke at openjdk.org  Sat Aug 13 19:13:23 2022
From: duke at openjdk.org (Hannes Greule)
Date: Sat, 13 Aug 2022 19:13:23 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default
In-Reply-To: <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
Message-ID: <84DuxyosYhVC7THUv2xQ_td8jc7oU83kVgmDvRFlKO8=.2e498e08-7027-4969-ba01-0ef7fe721cfc@github.com>

On Fri, 12 Aug 2022 22:35:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> test/langtools/tools/javac/RequiredParameterFlags/ImplicitParameters.java line 52:
> 
>> 50: import toolbox.ToolBox;
>> 51: 
>> 52: public class ImplicitParameters extends TestRunner {
> 
> In addition to this test, an annotation processing-based test could also be attempted here.

Could you elaborate on that? Should I add a processor to the JavacTask in this test or write a separate one? (Maybe there is a similar test I can use as reference?)
Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From duke at openjdk.org  Sat Aug 13 19:49:31 2022
From: duke at openjdk.org (Hannes Greule)
Date: Sat, 13 Aug 2022 19:49:31 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
Message-ID: <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>

> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
> Parameter names are *not* emitted unless the `-parameter` flag is set.
> 
> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
> 
> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
> I also had to update some tests as they got a new constant pool entry.
> 
> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
> Please let me know if you want tests for specific appearances of synthetic parameters.

Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:

  add access flag based test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9862/files
  - new: https://git.openjdk.org/jdk/pull/9862/files/c9ba84c7..e453380b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=00-01

  Stats: 103 lines in 1 file changed: 103 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9862.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9862/head:pull/9862

PR: https://git.openjdk.org/jdk/pull/9862

From vromero at openjdk.org  Mon Aug 15 17:37:21 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Aug 2022 17:37:21 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>
Message-ID: <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>

On Sat, 13 Aug 2022 19:49:31 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add access flag based test

CSR needed I guess

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From darcy at openjdk.org  Mon Aug 15 18:08:23 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 Aug 2022 18:08:23 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <84DuxyosYhVC7THUv2xQ_td8jc7oU83kVgmDvRFlKO8=.2e498e08-7027-4969-ba01-0ef7fe721cfc@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
 <84DuxyosYhVC7THUv2xQ_td8jc7oU83kVgmDvRFlKO8=.2e498e08-7027-4969-ba01-0ef7fe721cfc@github.com>
Message-ID: <AYWNAfx8YBzHjXp-tH3s_-nL0ZA0BtsF-bWRqsXhWTw=.77367285-8ddf-49de-9ee7-4f805acd506b@github.com>

On Sat, 13 Aug 2022 19:09:31 GMT, Hannes Greule <duke at openjdk.org> wrote:

> Could you elaborate on that? Should I add a processor to the JavacTask in this test or write a separate one? (Maybe there is a similar test I can use as reference?) Thank you.

There are tests that can be used as a model around

test/langtools/tools/javac/processing/model/util/elements 

HTH

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From duke at openjdk.org  Tue Aug 16 07:22:53 2022
From: duke at openjdk.org (Hannes Greule)
Date: Tue, 16 Aug 2022 07:22:53 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v3]
In-Reply-To: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
Message-ID: <6S0hnCy6S8FzcX9ZZASXSrGyJfSzyDti14ofDFdU6RA=.90e568a8-edab-4338-a39c-3da76c35767a@github.com>

> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
> Parameter names are *not* emitted unless the `-parameter` flag is set.
> 
> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
> 
> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
> I also had to update some tests as they got a new constant pool entry.
> 
> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
> Please let me know if you want tests for specific appearances of synthetic parameters.

Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:

  fix line breaks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9862/files
  - new: https://git.openjdk.org/jdk/pull/9862/files/e453380b..b3931507

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=01-02

  Stats: 103 lines in 1 file changed: 0 ins; 0 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/9862.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9862/head:pull/9862

PR: https://git.openjdk.org/jdk/pull/9862

From duke at openjdk.org  Tue Aug 16 07:22:53 2022
From: duke at openjdk.org (Hannes Greule)
Date: Tue, 16 Aug 2022 07:22:53 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>
 <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
Message-ID: <U0DWUJcvgaP63IXHBZdamu_L41TZ1xu13m-seTrqhPQ=.b5f6faa2-0b68-4f30-adaa-f261e938c12c@github.com>

On Mon, 15 Aug 2022 17:33:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> CSR needed I guess

I don't have access to the JBS. Could you help me with this?

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From duke at openjdk.org  Tue Aug 16 07:22:53 2022
From: duke at openjdk.org (Hannes Greule)
Date: Tue, 16 Aug 2022 07:22:53 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v3]
In-Reply-To: <AYWNAfx8YBzHjXp-tH3s_-nL0ZA0BtsF-bWRqsXhWTw=.77367285-8ddf-49de-9ee7-4f805acd506b@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
 <84DuxyosYhVC7THUv2xQ_td8jc7oU83kVgmDvRFlKO8=.2e498e08-7027-4969-ba01-0ef7fe721cfc@github.com>
 <AYWNAfx8YBzHjXp-tH3s_-nL0ZA0BtsF-bWRqsXhWTw=.77367285-8ddf-49de-9ee7-4f805acd506b@github.com>
Message-ID: <NH16tB4eqqAYrDDxaS1cCENCAXlXtr0Wk7ckhew3vGc=.0a97f03a-f5d4-482e-8883-5bc082805e19@github.com>

On Mon, 15 Aug 2022 18:06:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Could you elaborate on that? Should I add a processor to the JavacTask in this test or write a separate one? (Maybe there is a similar test I can use as reference?)
>> Thank you.
>
>> Could you elaborate on that? Should I add a processor to the JavacTask in this test or write a separate one? (Maybe there is a similar test I can use as reference?) Thank you.
> 
> There are tests that can be used as a model around
> 
> test/langtools/tools/javac/processing/model/util/elements 
> 
> HTH

Sorry, it looks like there is no way to access the synthetic/mandated information using the annotation processing API. Am I missing something?

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From thomas.stuefe at gmail.com  Tue Aug 16 07:42:06 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 16 Aug 2022 09:42:06 +0200
Subject: Why is ReplayCompiles a develop switch?
Message-ID: <CAA-vtUxGZRmWuc+f9VFpH0tsDqMeiuh545rG3aEyDFnVmUHSZw@mail.gmail.com>

Hi,

Is there a particular reason why ReplayCompiles needs to be a develop
switch? Could it be made diagnostic or product?

I had several cases where it would have been useful to reproduce Compiler
errors in release VMs, even in the absence of asserts.

Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220816/bcaaaf9a/attachment.htm>

From jwaters at openjdk.org  Tue Aug 16 10:25:17 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 16 Aug 2022 10:25:17 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <U0DWUJcvgaP63IXHBZdamu_L41TZ1xu13m-seTrqhPQ=.b5f6faa2-0b68-4f30-adaa-f261e938c12c@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>
 <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
 <U0DWUJcvgaP63IXHBZdamu_L41TZ1xu13m-seTrqhPQ=.b5f6faa2-0b68-4f30-adaa-f261e938c12c@github.com>
Message-ID: <8oTTLbr96G6vFrn63ruIQmc7cuTnuUze62tiM1X7jkU=.39323587-58ef-4a57-b1a4-e7575c7caada@github.com>

On Tue, 16 Aug 2022 07:19:26 GMT, Hannes Greule <duke at openjdk.org> wrote:

> > CSR needed I guess
> 
> I don't have access to the JBS. Could you help me with this?

No problem!

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From thomas.stuefe at gmail.com  Tue Aug 16 17:06:17 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 16 Aug 2022 19:06:17 +0200
Subject: Why is ReplayCompiles a develop switch?
In-Reply-To: <CAA-vtUxGZRmWuc+f9VFpH0tsDqMeiuh545rG3aEyDFnVmUHSZw@mail.gmail.com>
References: <CAA-vtUxGZRmWuc+f9VFpH0tsDqMeiuh545rG3aEyDFnVmUHSZw@mail.gmail.com>
Message-ID: <CAA-vtUzvU50nSk+Fs6dQ6mK7cTXt8k+rsu6-K3HC-6s6os63=g@mail.gmail.com>

Please disregard my previous email, it was meant for hotspot compiler dev.

On Tue 16. Aug 2022 at 09:42, Thomas St?fe <thomas.stuefe at gmail.com> wrote:

> Hi,
>
> Is there a particular reason why ReplayCompiles needs to be a develop
> switch? Could it be made diagnostic or product?
>
> I had several cases where it would have been useful to reproduce Compiler
> errors in release VMs, even in the absence of asserts.
>
> Thanks, Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220816/81b26f7b/attachment.htm>

From darcy at openjdk.org  Tue Aug 16 17:34:19 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Aug 2022 17:34:19 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v3]
In-Reply-To: <NH16tB4eqqAYrDDxaS1cCENCAXlXtr0Wk7ckhew3vGc=.0a97f03a-f5d4-482e-8883-5bc082805e19@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
 <84DuxyosYhVC7THUv2xQ_td8jc7oU83kVgmDvRFlKO8=.2e498e08-7027-4969-ba01-0ef7fe721cfc@github.com>
 <AYWNAfx8YBzHjXp-tH3s_-nL0ZA0BtsF-bWRqsXhWTw=.77367285-8ddf-49de-9ee7-4f805acd506b@github.com>
 <NH16tB4eqqAYrDDxaS1cCENCAXlXtr0Wk7ckhew3vGc=.0a97f03a-f5d4-482e-8883-5bc082805e19@github.com>
Message-ID: <lTqwptGfyMuClmxKYOMAXeNret28xh6AwbwKsGJtl4U=.f31e872e-38d6-4be9-88fe-134942a0491b@github.com>

On Tue, 16 Aug 2022 07:17:41 GMT, Hannes Greule <duke at openjdk.org> wrote:

> Sorry, it looks like there is no way to access the synthetic/mandated information using the annotation processing API. Am I missing something?

For reasons of providing a minimal core language model that could be reused, less essential functionality is split in the language model API to be provided by an implementation of javax.lang.model.util.Elements.

So if you subclass JavacTestingAbstractProcessor files that test directory, you could use

eltUtils.getOrigin(elementForParameter)

to see if an element is marked as javax.lang.model.util.Enum Elements.Origin.{MANDATED, SYNTHETIC}.

Many of the annotation processing tests use a pattern of using a runtime-retention annotation to encode what the expected answer is. In this case, I'd recommend a method/constructor annotation to hold the expected origin of the parameters.

(The annotation processing API does filter out some SYNTHETIC constructs, but I don't recall if that is done at a parameter level.)

HTH

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From jjg at openjdk.org  Tue Aug 16 17:37:29 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 16 Aug 2022 17:37:29 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <mY_ICKm2YiPrsuAYYYJbJCpX3dSMDD3WpUxp5KnR_Mg=.8d1bce53-7139-4986-be60-a9445fe12745@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

`jdk.compiler` and `jdk.javadoc` changes look OK

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9445

From naoto at openjdk.org  Tue Aug 16 17:48:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Aug 2022 17:48:39 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <xzJJkvV1oqcon8KDl5Z8u4KJlP6Udn77VaNko0wHbxA=.83d42205-be39-43b0-be36-17fb59192479@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Those `.properties` bundle changes look good.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9445

From iris at openjdk.org  Tue Aug 16 18:26:17 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 16 Aug 2022 18:26:17 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <RHDfWJb7R7zhWFU08KXiXDqIvgJTkdn3fXSazBi58HE=.dfd63f3c-0ae8-45b4-a43d-5d48a17c6337@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9445

From jjg at openjdk.org  Wed Aug 17 18:23:07 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 17 Aug 2022 18:23:07 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v13]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <j8gfJb3JLmF7RvWZho4nRJ4Ta2SrHG77yumEnlgmYbk=.5129c4b4-bc22-44d0-897d-a4be2ae8e812@github.com>

> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge with upstream/master
 - Fix typo and merge error
 - Merge with upstream/master
 - Update @since tags
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Updates for latest repo
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge with upstream/master
 - ... and 10 more: https://git.openjdk.org/jdk/compare/0fc92637...e8fe51b0

-------------

Changes: https://git.openjdk.org/jdk/pull/8439/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=12
  Stats: 1502 lines in 41 files changed: 1474 ins; 6 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8439/head:pull/8439

PR: https://git.openjdk.org/jdk/pull/8439

From darcy at openjdk.org  Thu Aug 18 21:05:31 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Aug 2022 21:05:31 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v3]
In-Reply-To: <Jgc5EA7cuFBOsU9ggereueQHq1y7GuVfAiNim2Raq6I=.bd389220-c921-4376-82b0-d00e99f1c783@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Q53uk786rBdwdXgUVa8II5eawxcKRKsoMUunqw8_Z0g=.c854b3cb-87e9-47d0-9a54-959e85f73552@github.com>
 <84DuxyosYhVC7THUv2xQ_td8jc7oU83kVgmDvRFlKO8=.2e498e08-7027-4969-ba01-0ef7fe721cfc@github.com>
 <AYWNAfx8YBzHjXp-tH3s_-nL0ZA0BtsF-bWRqsXhWTw=.77367285-8ddf-49de-9ee7-4f805acd506b@github.com>
 <NH16tB4eqqAYrDDxaS1cCENCAXlXtr0Wk7ckhew3vGc=.0a97f03a-f5d4-482e-8883-5bc082805e19@github.com>
 <lTqwptGfyMuClmxKYOMAXeNret28xh6AwbwKsGJtl4U=.f31e872e-38d6-4be9-88fe-134942a0491b@github.com>
 <Jgc5EA7cuFBOsU9ggereueQHq1y7GuVfAiNim2Raq6I=.bd389220-c921-4376-82b0-d00e99f1c783@github.com>
Message-ID: <Mw9sn4MLGwWr_m4N_dFS9L0rXODuKXBrPIJ6XJpxu2c=.a8065e96-df60-45c4-91cd-188d95fc2fad@github.com>

On Thu, 18 Aug 2022 16:19:31 GMT, Hannes Greule <duke at openjdk.org> wrote:

> Thanks, I started working on a test, but the results are somewhat inconsistent (no implicit parameter is present for inner class ctors, no synthetic parameters for enum ctors, parameter of valueOf is MANDATED, implicit parameters in compact record ctor are MANDATED). I'm not sure how we want to proceed with that or if there are known issues about that, but it might be better to tackle that separately. What do you think?

At least some of that behavior is expected/not surprising given the current state of javac's implementation. I linked the existing bug related bug

    JDK-8250919: Mark compiler-generated elements as mandated

to JDK-8292275 in JBS. When possible, arguably javac should present the "source view" of a construct, so it would omit, say, the synthetic parameters javac chooses to add to enum constructors.

I suggest including a test for the mandated structures that "work" and the test could be expanded as that property is tracked and used more uniformly.

Thanks and HTH

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From duke at openjdk.org  Fri Aug 19 06:56:38 2022
From: duke at openjdk.org (Joe)
Date: Fri, 19 Aug 2022 06:56:38 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https [v2]
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <SNHwtcq72zY7FsKGHrue2rTaexjNxMUZ4EhdP4GPP2k=.b2171fb9-b781-4f9c-afca-f8f1832ba844@github.com>

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Joe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - changed the hrl from http to https JDK-8289562

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9445/files
  - new: https://git.openjdk.org/jdk/pull/9445/files/324f877c..07b7be0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9445&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9445&range=00-01

  Stats: 142897 lines in 2088 files changed: 75388 ins; 52973 del; 14536 mod
  Patch: https://git.openjdk.org/jdk/pull/9445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9445/head:pull/9445

PR: https://git.openjdk.org/jdk/pull/9445

From duke at openjdk.org  Fri Aug 19 08:58:59 2022
From: duke at openjdk.org (Joe)
Date: Fri, 19 Aug 2022 08:58:59 GMT
Subject: Integrated: 8289562: Change bugs.java.com and bugreport.java.com URL's
 to https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <3PKzwl7RxEVyWEBTVdySoL1eKjal-7IRGDANL2ABqG8=.7dc34842-62c6-40a5-8ce3-1bf0e9f58852@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

This pull request has now been integrated.

Changeset: 1f484dae
Author:    Joe <joe.cherian at oracle.com>
Committer: Fairoz Matte <fmatte at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f484dae4efaa60cf18a3d4df947c05f1497bd5b
Stats:     18 lines in 17 files changed: 0 ins; 0 del; 18 mod

8289562: Change bugs.java.com and bugreport.java.com URL's to https

Co-authored-by: Joe Cherian <joe.cherian at oracle.com>
Reviewed-by: prr, jjg, naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/9445

From duke at openjdk.org  Fri Aug 19 13:05:10 2022
From: duke at openjdk.org (Hannes Greule)
Date: Fri, 19 Aug 2022 13:05:10 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v4]
In-Reply-To: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
Message-ID: <KkrC4SYgbYLIol_huYfEM3LjOQNYG-UDqbM2BDHGK8s=.4bbd5557-0d29-4ee4-a26f-9f76002c07f4@github.com>

> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
> Parameter names are *not* emitted unless the `-parameter` flag is set.
> 
> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
> 
> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
> I also had to update some tests as they got a new constant pool entry.
> 
> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
> Please let me know if you want tests for specific appearances of synthetic parameters.

Hannes Greule has updated the pull request incrementally with two additional commits since the last revision:

 - cleanup
 - add annotation processing test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9862/files
  - new: https://git.openjdk.org/jdk/pull/9862/files/b3931507..ebb09f8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=02-03

  Stats: 127 lines in 3 files changed: 115 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9862.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9862/head:pull/9862

PR: https://git.openjdk.org/jdk/pull/9862

From shade at openjdk.org  Fri Aug 19 13:23:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 19 Aug 2022 13:23:33 GMT
Subject: RFR: 8292022: Issues caused by Unary Plus Operator + and Shift
 Operators priority
In-Reply-To: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
References: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
Message-ID: <87MpJ1N2Ip8aozQtmStMQ_26l7wUT5m_8qpkEZuxjCM=.22b7d3a8-3e64-4b24-8628-955bb10f38be@github.com>

On Mon, 1 Aug 2022 07:07:18 GMT, GGGGGHT <duke at openjdk.org> wrote:

> (capacity + capacity>>1) The result of this expression is still capacity. So I guess what the author thought at the time might be (capacity + (capacity >> 1)), see https://bugs.openjdk.org/projects/JDK/issues/JDK-8292022

I don't see a reason to over-allocate the 1.5x sized ByteBuffer here. So, if we just drop to ` `ByteBuffer.allocate(capacity)`, it would still resolve the problem, leave the current behavior as it is (obviates the need for deeper testing), and would make more sense anyway. Right?

-------------

PR: https://git.openjdk.org/jdk/pull/9698

From duke at openjdk.org  Sat Aug 20 01:17:21 2022
From: duke at openjdk.org (SUN Guoyun)
Date: Sat, 20 Aug 2022 01:17:21 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with StackOverflowError
 when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
Message-ID: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>

make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.

-------------

Commit messages:
 - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

Changes: https://git.openjdk.org/jdk/pull/9934/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9934&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292647
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9934.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9934/head:pull/9934

PR: https://git.openjdk.org/jdk/pull/9934

From duke at openjdk.org  Sat Aug 20 01:17:22 2022
From: duke at openjdk.org (SUN Guoyun)
Date: Sat, 20 Aug 2022 01:17:22 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
In-Reply-To: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
Message-ID: <JuQxIJ1OSBh7d0KpeSpXLELOYULOJqXbEIk4nk_T3Zg=.584a544a-cb36-4565-b74c-bf0ce9bcd9bc@github.com>

On Fri, 19 Aug 2022 03:08:31 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.

RFR

-------------

PR: https://git.openjdk.org/jdk/pull/9934

From duke at openjdk.org  Sat Aug 20 07:18:28 2022
From: duke at openjdk.org (GGGGGHT)
Date: Sat, 20 Aug 2022 07:18:28 GMT
Subject: RFR: 8292022: Issues caused by Unary Plus Operator + and Shift
 Operators priority
In-Reply-To: <87MpJ1N2Ip8aozQtmStMQ_26l7wUT5m_8qpkEZuxjCM=.22b7d3a8-3e64-4b24-8628-955bb10f38be@github.com>
References: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
 <87MpJ1N2Ip8aozQtmStMQ_26l7wUT5m_8qpkEZuxjCM=.22b7d3a8-3e64-4b24-8628-955bb10f38be@github.com>
Message-ID: <mEEma7Qyv_nBoLTN-3dvr9-OGz5yD7Qw5xNcb1otxyA=.3387dcd9-03b9-4f87-a8e5-8bae98da28eb@github.com>

On Fri, 19 Aug 2022 13:20:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I don't see a reason to over-allocate the 1.5x sized ByteBuffer here. So, if we just drop to ` `ByteBuffer.allocate(capacity)`, it would still resolve the problem, leave the current behavior as it is (obviates the need for deeper testing), and would make more sense anyway. Right?

Maybe so, but I think direct allocation of 1.5x size may reduce the number of allocations in some extreme cases.

-------------

PR: https://git.openjdk.org/jdk/pull/9698

From aph at openjdk.org  Sat Aug 20 08:39:30 2022
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 20 Aug 2022 08:39:30 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
In-Reply-To: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
Message-ID: <2QdKMzJakUEcPEFRUtzeDtDo35ew4G-fN8gQ7YnFLA8=.c56f7817-cae8-434d-b76b-19f013dab34a@github.com>

On Fri, 19 Aug 2022 03:08:31 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.

I'm not at all sure about this one.
It may be a bug. Before committing this patch we should find out why AArch64 and LoongArch are consuming more stack than others. 10M of stack is huge.

-------------

PR: https://git.openjdk.org/jdk/pull/9934

From cstein at openjdk.org  Sat Aug 20 16:15:13 2022
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 20 Aug 2022 16:15:13 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
Message-ID: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>

Please review the change to update to using jtreg 7.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update github-actions.conf
 - JDK-8289798: Update to use jtreg 7

Changes: https://git.openjdk.org/jdk/pull/9393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289798
  Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From alanb at openjdk.org  Sat Aug 20 16:15:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 20 Aug 2022 16:15:13 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <sXUbEwrue0OPm3iF8acsWON7e3Tmtcqk4nF9XgqYmhw=.eb5a6999-aeb7-4605-b324-fbfb0153047f@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Have you run all the tiers to make sure there aren't any issues?

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From cstein at openjdk.org  Sat Aug 20 16:15:13 2022
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 20 Aug 2022 16:15:13 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <oE1p8IenuQxtSD2DphLcuXbGqzMddEmLX1ql7mS7jC0=.4bf15112-af50-4cec-9de6-9cd6205276d3@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

No. I'll mark this PR ready for review when all tiers ran successfully.

Besides the usual bug fixes, updates, and minor improvements (see [changes since jtreg 6.2](https://github.com/openjdk/jtreg/compare/jtreg-6.2+1...jtreg-7+1)) the sole major new feature of jtreg 7 is:
- Run tests annotated with `@run junit` via JUnit Platform's Launcher (version `1.8.2`). This enables writing tests using the Jupiter API (version `5.8.2`) in addition to writing and running JUnit 4-based tests.

The change in `junit.java` will be superseded by https://github.com/openjdk/jdk/pull/9944 which deletes that file.

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From jpai at openjdk.org  Sat Aug 20 16:15:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Aug 2022 16:15:13 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <9wOkjC3Cf252C2NCyfb32M5czLcyBK7lqHlKGD_qtaA=.5337fe86-04d6-4e8f-82e5-0e0b074210c3@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Hello Christian, more out of curiosity - what are some of the changes that jtreg 7 brings in?

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From duke at openjdk.org  Mon Aug 22 03:26:11 2022
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 22 Aug 2022 03:26:11 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
In-Reply-To: <2QdKMzJakUEcPEFRUtzeDtDo35ew4G-fN8gQ7YnFLA8=.c56f7817-cae8-434d-b76b-19f013dab34a@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <2QdKMzJakUEcPEFRUtzeDtDo35ew4G-fN8gQ7YnFLA8=.c56f7817-cae8-434d-b76b-19f013dab34a@github.com>
Message-ID: <20nOuTrdhVz3ikgxbOy3JTS5aH8So5tKA8QiR08oCj4=.23dc3532-19a2-4169-ab43-d336a2564e90@github.com>

On Sat, 20 Aug 2022 08:36:00 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I'm not at all sure about this one. It may be a bug. Before committing this patch we should find out why AArch64 and LoongArch are consuming more stack than others. 10M of stack is huge.

I do not have a particularly good idear to locate this problem `find out why AArch64 and LoongArch are consuming more stack than others` at present. From the test results, AArch64 require more stack space than X86_64. And  on the same platform, tier3 `-XX:TieredStopAtLevel=3` consumes more stack space than tier4`-XX:TieredStopAtLevel=4`. 

On the x64 platform, tier4 needs at least set `-Xss700k` and tier3 needs at least set `-Xss1m`. On the aarch64 platform, tier4 needs at least set `-Xss900k` and tier3 needs at least set `-Xss1228k`. 

For safety, I set to `-Xss10m`. Maybe it's more reasonable to change it to `-Xss2m`?

-------------

PR: https://git.openjdk.org/jdk/pull/9934

From shade at openjdk.org  Mon Aug 22 07:38:27 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Aug 2022 07:38:27 GMT
Subject: RFR: 8292022: Issues caused by Unary Plus Operator + and Shift
 Operators priority
In-Reply-To: <mEEma7Qyv_nBoLTN-3dvr9-OGz5yD7Qw5xNcb1otxyA=.3387dcd9-03b9-4f87-a8e5-8bae98da28eb@github.com>
References: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
 <87MpJ1N2Ip8aozQtmStMQ_26l7wUT5m_8qpkEZuxjCM=.22b7d3a8-3e64-4b24-8628-955bb10f38be@github.com>
 <mEEma7Qyv_nBoLTN-3dvr9-OGz5yD7Qw5xNcb1otxyA=.3387dcd9-03b9-4f87-a8e5-8bae98da28eb@github.com>
Message-ID: <Ge2bre8k-0k0GtQqRB2XLn8KQdqZbCR4ssIdSo09OOI=.fa1d796c-b43f-476d-99e2-7401778274f8@github.com>

On Sat, 20 Aug 2022 07:14:49 GMT, GGGGGHT <duke at openjdk.org> wrote:

> Maybe so, but I think direct allocation of 1.5x size may reduce the number of allocations in some extreme cases.

On the other hand, it might also waste memory in general case? I think status quo behavior is okay, and we can just change the code to match it.

-------------

PR: https://git.openjdk.org/jdk/pull/9698

From duke at openjdk.org  Mon Aug 22 07:47:37 2022
From: duke at openjdk.org (GGGGGHT)
Date: Mon, 22 Aug 2022 07:47:37 GMT
Subject: RFR: 8292022: Issues caused by Unary Plus Operator + and Shift
 Operators priority [v2]
In-Reply-To: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
References: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
Message-ID: <vbOvkJABSU0XAR3gugkl6LFzjMMPce0_kRVCnFJMydg=.d51df332-4949-425e-8941-656dbdd731ac@github.com>

> (capacity + capacity>>1) The result of this expression is still capacity. So I guess what the author thought at the time might be (capacity + (capacity >> 1)), see https://bugs.openjdk.org/projects/JDK/issues/JDK-8292022

GGGGGHT has updated the pull request incrementally with one additional commit since the last revision:

  modify the capacity

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9698/files
  - new: https://git.openjdk.org/jdk/pull/9698/files/27e124bd..a46e51fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9698&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9698&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9698.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9698/head:pull/9698

PR: https://git.openjdk.org/jdk/pull/9698

From duke at openjdk.org  Mon Aug 22 07:47:38 2022
From: duke at openjdk.org (GGGGGHT)
Date: Mon, 22 Aug 2022 07:47:38 GMT
Subject: RFR: 8292022: Issues caused by Unary Plus Operator + and Shift
 Operators priority [v2]
In-Reply-To: <Ge2bre8k-0k0GtQqRB2XLn8KQdqZbCR4ssIdSo09OOI=.fa1d796c-b43f-476d-99e2-7401778274f8@github.com>
References: <BTk-IWcFEpNTT70l2paRXA6bg_Qx41cxgenAHc5Lnbw=.b9f7f069-85de-404c-a47a-08af8d8313ff@github.com>
 <87MpJ1N2Ip8aozQtmStMQ_26l7wUT5m_8qpkEZuxjCM=.22b7d3a8-3e64-4b24-8628-955bb10f38be@github.com>
 <mEEma7Qyv_nBoLTN-3dvr9-OGz5yD7Qw5xNcb1otxyA=.3387dcd9-03b9-4f87-a8e5-8bae98da28eb@github.com>
 <Ge2bre8k-0k0GtQqRB2XLn8KQdqZbCR4ssIdSo09OOI=.fa1d796c-b43f-476d-99e2-7401778274f8@github.com>
Message-ID: <mNJLVpUQCPeebJjjdAZ5ZHFeSJUkxdoQU4gMuG1XE6s=.a1545884-cdaf-43fe-a577-75cef202322e@github.com>

On Mon, 22 Aug 2022 07:34:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Maybe so, but I think direct allocation of 1.5x size may reduce the number of allocations in some extreme cases.
> 
> On the other hand, it might also waste memory in general case? I think status quo behavior is okay, and we can just change the code to match it.

You are right, I have re-modified this code.

-------------

PR: https://git.openjdk.org/jdk/pull/9698

From ngasson at openjdk.org  Mon Aug 22 08:33:34 2022
From: ngasson at openjdk.org (Nick Gasson)
Date: Mon, 22 Aug 2022 08:33:34 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
In-Reply-To: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
Message-ID: <3KjPeO16VZ-9FnFi4-4eu2yNoEEv69H7imKrF9Y8w6o=.9ad42a5b-8298-4a22-9264-7ec9ef679279@github.com>

On Fri, 19 Aug 2022 03:08:31 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.

Have you tried with `-XX:+AdjustStackSizeForTLS` to see how that affects it? Glibc will subtract an unknown amount of memory from your thread's stack to use for static TLS so the usable stack size will actually be slightly less than the `-Xss` value, and that amount varies between platforms. See here https://bugs.openjdk.org/browse/JDK-8227417 and here https://sourceware.org/bugzilla/show_bug.cgi?id=11787

-------------

PR: https://git.openjdk.org/jdk/pull/9934

From aph at openjdk.org  Mon Aug 22 08:41:27 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 22 Aug 2022 08:41:27 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
In-Reply-To: <20nOuTrdhVz3ikgxbOy3JTS5aH8So5tKA8QiR08oCj4=.23dc3532-19a2-4169-ab43-d336a2564e90@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <2QdKMzJakUEcPEFRUtzeDtDo35ew4G-fN8gQ7YnFLA8=.c56f7817-cae8-434d-b76b-19f013dab34a@github.com>
 <20nOuTrdhVz3ikgxbOy3JTS5aH8So5tKA8QiR08oCj4=.23dc3532-19a2-4169-ab43-d336a2564e90@github.com>
Message-ID: <xTCP2VuQkz7pN9JrQtH6OUEvrBGY5KJX1bfwtK4PtkI=.9a1a8542-90f0-47f2-a517-caee2d81b05c@github.com>

On Mon, 22 Aug 2022 03:21:46 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> For safety, I set to `-Xss10m`. Maybe it's more reasonable to change it to `-Xss2m`?

I don't think so. If we were making automobiles and our model consumed 40% more fuel than our competitor's, our response would  not be to solve the problem by fitting a larger fuel tank. The stack layout of AArch64 is, as close as we can make it, identical to that of x86-64. So, this difference in memory use is not expected and should be investigated.

-------------

PR: https://git.openjdk.org/jdk/pull/9934

From ihse at openjdk.org  Mon Aug 22 09:46:29 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Aug 2022 09:46:29 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <pjZuqauBESo1K8V4r6qdA6QH5dTgTPW7SXXRo-HupZg=.8c05fc7c-ad31-4448-a792-3f99cfe01e69@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

I think the configure script should verify that we got the minimum jtreg needed. This is not really related to the change, but seeing this PR got me thinking about it. I also think a change such as this might bite people who have local setups with older jtreg installations, and then it would be nice for it to fail early in configure.

If you are interested in including such a check, I could contribute the code for the configure script.

I just want to check one thing: I see there are multiple `requiredVersion` in different TEST.ROOT files. Does this new requirement apply to *all* our jtreg tests?

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From ihse at openjdk.org  Mon Aug 22 11:36:31 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Aug 2022 11:36:31 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <84r0tcH3qGIH6INXsFU0NSEe1cpkrs4SucSnj5WNtkA=.f02c5997-449c-4302-aaaa-ae3a4b5b3c02@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Actually, lets do that separately. I opened https://bugs.openjdk.org/browse/JDK-8292716.

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From cstein at openjdk.org  Mon Aug 22 16:39:17 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 22 Aug 2022 16:39:17 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v2]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <8gFr6V8k4vF-3cJt34Vp_6F-MtOb2TyMwJNjhgUveoU=.535be13e-459c-4cd3-8bca-5eb66587a084@github.com>

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Revert junit.java
   
   Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
   
   With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
   This change updates the hard-coded library tag value to the new JUnit JAR file.
   Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
   in order to unblock the "Update to use jtreg 7" PR 9393:
   https://github.com/openjdk/jdk/pull/9393
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update github-actions.conf
 - JDK-8289798: Update to use jtreg 7

-------------

Changes: https://git.openjdk.org/jdk/pull/9393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=01
  Stats: 10 lines in 7 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From darcy at openjdk.org  Mon Aug 22 21:14:41 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 Aug 2022 21:14:41 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v4]
In-Reply-To: <KkrC4SYgbYLIol_huYfEM3LjOQNYG-UDqbM2BDHGK8s=.4bbd5557-0d29-4ee4-a26f-9f76002c07f4@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <KkrC4SYgbYLIol_huYfEM3LjOQNYG-UDqbM2BDHGK8s=.4bbd5557-0d29-4ee4-a26f-9f76002c07f4@github.com>
Message-ID: <kTJ7znFUGi6tjUMBUdpvbQ0HNLE5VtrTW0CMS8N16Xg=.219f8cdb-9316-4c8c-afd8-3ef85345b45a@github.com>

On Fri, 19 Aug 2022 13:05:10 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup
>  - add annotation processing test

test/langtools/tools/javac/processing/model/util/elements/MethodParameters/ClassContainer.java line 1:

> 1: /*

I recommend folding the enum being processed into the source of ImplicitParametersProcessor.java. The jtreg tags can then first compile the source of the processor and then secondly run the processor on itself. This technique is commonly used in annotation processing tests.

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From darcy at openjdk.org  Mon Aug 22 21:21:35 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 Aug 2022 21:21:35 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v4]
In-Reply-To: <KkrC4SYgbYLIol_huYfEM3LjOQNYG-UDqbM2BDHGK8s=.4bbd5557-0d29-4ee4-a26f-9f76002c07f4@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <KkrC4SYgbYLIol_huYfEM3LjOQNYG-UDqbM2BDHGK8s=.4bbd5557-0d29-4ee4-a26f-9f76002c07f4@github.com>
Message-ID: <qOgPZjus0O24rLTGIVnjvXC3NmabvKNK4Zn6wTqrtLU=.e54fbb51-b950-4f64-a419-0e5fd66e8d47@github.com>

On Fri, 19 Aug 2022 13:05:10 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup
>  - add annotation processing test

test/langtools/tools/javac/processing/model/util/elements/MethodParameters/ImplicitParametersProcessor.java line 33:

> 31:  * @build   JavacTestingAbstractProcessor ImplicitParametersProcessor
> 32:  * @compile -processor ImplicitParametersProcessor -proc:only ClassContainer.java
> 33:  */

Good start on the annotation processor. From personal experience writing such tests and then looking at them months later, I recommend adding some kind of brief comment describing the intended semantics of the test, e.g.

"Verify enum classes and record classes have expected mandated executables."

To make the test more extensible, the expected information could be encoded in annotations; e.g. something like

@interface ExpectedInfo {
    String methodName();
    Elements.Origin origin();
}

where the record and enum were annotated in turn:

@ExpectedInfo(name="<init>", origin=MANDATED)
MyEnum {..}

etc.

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From darcy at openjdk.org  Mon Aug 22 23:19:34 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 Aug 2022 23:19:34 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
Message-ID: <oFu5tFXsnfVGyQvruKiaYkefvAeeTVTUo_S8m6VRxpo=.0b70cda4-06e6-4ef7-ac79-5c1823d134e9@github.com>

On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update visitor; all langtools regression tests pass.
>  - Merge branch 'master' into JDK-8042981
>  - JDK-8042981: Strip type annotations in Types' utility methods

Keep alive.

-------------

PR: https://git.openjdk.org/jdk/pull/8984

From duke at openjdk.org  Tue Aug 23 03:06:32 2022
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 23 Aug 2022 03:06:32 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
In-Reply-To: <3KjPeO16VZ-9FnFi4-4eu2yNoEEv69H7imKrF9Y8w6o=.9ad42a5b-8298-4a22-9264-7ec9ef679279@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <3KjPeO16VZ-9FnFi4-4eu2yNoEEv69H7imKrF9Y8w6o=.9ad42a5b-8298-4a22-9264-7ec9ef679279@github.com>
Message-ID: <Gp2EGBZ1FSCYDqhUYpbZdDGtY132xvY2bW2f_Luvw-k=.c53810f8-36f2-4054-b605-b056abf43e55@github.com>

On Mon, 22 Aug 2022 08:29:48 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Have you tried with `-XX:+AdjustStackSizeForTLS` to see how that affects it? Glibc will subtract an unknown amount of memory from your thread's stack to use for static TLS so the usable stack size will actually be slightly less than the `-Xss` value, and that amount varies between platforms. See here https://bugs.openjdk.org/browse/JDK-8227417 and here https://sourceware.org/bugzilla/show_bug.cgi?id=11787

Thanks. I had tried with `-XX:+AdjustStackSizeForTLS`, but test result is FAILED also. As theRealAph said?it may be necessary to find out why aarch64 needs more stack space than x64.

-------------

PR: https://git.openjdk.org/jdk/pull/9934

From duke at openjdk.org  Tue Aug 23 03:13:14 2022
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 23 Aug 2022 03:13:14 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
In-Reply-To: <xTCP2VuQkz7pN9JrQtH6OUEvrBGY5KJX1bfwtK4PtkI=.9a1a8542-90f0-47f2-a517-caee2d81b05c@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <2QdKMzJakUEcPEFRUtzeDtDo35ew4G-fN8gQ7YnFLA8=.c56f7817-cae8-434d-b76b-19f013dab34a@github.com>
 <20nOuTrdhVz3ikgxbOy3JTS5aH8So5tKA8QiR08oCj4=.23dc3532-19a2-4169-ab43-d336a2564e90@github.com>
 <xTCP2VuQkz7pN9JrQtH6OUEvrBGY5KJX1bfwtK4PtkI=.9a1a8542-90f0-47f2-a517-caee2d81b05c@github.com>
Message-ID: <_sZ1_RpcxTWMaQbg4aVLxhwcQIrXyDPGd5zu0XTxy7k=.5a4f9d98-650b-417b-b416-3c273a1ab776@github.com>

On Mon, 22 Aug 2022 08:37:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> I'm not at all sure about this one. It may be a bug. Before committing this patch we should find out why AArch64 and LoongArch are consuming more stack than others. 10M of stack is huge.
>> 
>> I do not have a particularly good idear to locate this problem `find out why AArch64 and LoongArch are consuming more stack than others` at present. From the test results, AArch64 require more stack space than X86_64. And  on the same platform, tier3 `-XX:TieredStopAtLevel=3` consumes more stack space than tier4`-XX:TieredStopAtLevel=4`. 
>> 
>> On the x64 platform, tier4 needs at least set `-Xss700k` and tier3 needs at least set `-Xss1m`. On the aarch64 platform, tier4 needs at least set `-Xss900k` and tier3 needs at least set `-Xss1228k`. 
>> 
>> For safety, I set to `-Xss10m`. Maybe it's more reasonable to change it to `-Xss2m`?
>
>> For safety, I set to `-Xss10m`. Maybe it's more reasonable to change it to `-Xss2m`?
> 
> I don't think so. If we were making automobiles and our model consumed 40% more fuel than our competitor's, our response would  not be to solve the problem by fitting a larger fuel tank. The stack layout of AArch64 is, as close as we can make it, identical to that of x86-64. So, this difference in memory use is not expected and should be investigated.

@theRealAph Do you have any good ways to observe the use of X86 and AArch64 stack space?

-------------

PR: https://git.openjdk.org/jdk/pull/9934

From cstein at openjdk.org  Tue Aug 23 07:56:03 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 23 Aug 2022 07:56:03 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v3]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <NPKRpVVHDHwfB2kvOc_MTp6sHVt5Mu4FVZm_GAV7Z4c=.de6bf26c-a53e-4eba-a57c-72de78c1cecf@github.com>

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Revert junit.java
   
   Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
   
   With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
   This change updates the hard-coded library tag value to the new JUnit JAR file.
   Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
   in order to unblock the "Update to use jtreg 7" PR 9393:
   https://github.com/openjdk/jdk/pull/9393
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update github-actions.conf
 - ... and 1 more: https://git.openjdk.org/jdk/compare/486f90c1...468f0bd3

-------------

Changes: https://git.openjdk.org/jdk/pull/9393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=02
  Stats: 10 lines in 7 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From cstein at openjdk.org  Tue Aug 23 07:58:20 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 23 Aug 2022 07:58:20 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v4]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <20AQsJGMltW6Z6Ml-SDdXFJ81F83MnHmCl524jLvECA=.5f72fc0c-e973-45d1-92e4-e3f383d727ad@github.com>

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update configure to check for jtreg 7 or later

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9393/files
  - new: https://git.openjdk.org/jdk/pull/9393/files/468f0bd3..1f6f4a7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From aph at openjdk.org  Tue Aug 23 08:57:31 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 23 Aug 2022 08:57:31 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
In-Reply-To: <xTCP2VuQkz7pN9JrQtH6OUEvrBGY5KJX1bfwtK4PtkI=.9a1a8542-90f0-47f2-a517-caee2d81b05c@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <2QdKMzJakUEcPEFRUtzeDtDo35ew4G-fN8gQ7YnFLA8=.c56f7817-cae8-434d-b76b-19f013dab34a@github.com>
 <20nOuTrdhVz3ikgxbOy3JTS5aH8So5tKA8QiR08oCj4=.23dc3532-19a2-4169-ab43-d336a2564e90@github.com>
 <xTCP2VuQkz7pN9JrQtH6OUEvrBGY5KJX1bfwtK4PtkI=.9a1a8542-90f0-47f2-a517-caee2d81b05c@github.com>
Message-ID: <vVmuprItYfYAIJsR7UUPAXaJRPtEpUpWqfgQFaw6WWQ=.5ee3f9e8-af39-42d1-87a2-37b71e1a8950@github.com>

On Mon, 22 Aug 2022 08:37:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> I'm not at all sure about this one. It may be a bug. Before committing this patch we should find out why AArch64 and LoongArch are consuming more stack than others. 10M of stack is huge.
>> 
>> I do not have a particularly good idear to locate this problem `find out why AArch64 and LoongArch are consuming more stack than others` at present. From the test results, AArch64 require more stack space than X86_64. And  on the same platform, tier3 `-XX:TieredStopAtLevel=3` consumes more stack space than tier4`-XX:TieredStopAtLevel=4`. 
>> 
>> On the x64 platform, tier4 needs at least set `-Xss700k` and tier3 needs at least set `-Xss1m`. On the aarch64 platform, tier4 needs at least set `-Xss900k` and tier3 needs at least set `-Xss1228k`. 
>> 
>> For safety, I set to `-Xss10m`. Maybe it's more reasonable to change it to `-Xss2m`?
>
>> For safety, I set to `-Xss10m`. Maybe it's more reasonable to change it to `-Xss2m`?
> 
> I don't think so. If we were making automobiles and our model consumed 40% more fuel than our competitor's, our response would  not be to solve the problem by fitting a larger fuel tank. The stack layout of AArch64 is, as close as we can make it, identical to that of x86-64. So, this difference in memory use is not expected and should be investigated.

> @theRealAph Do you have any good ways to observe the use of X86 and AArch64 stack space?

If it were me:
I'd run the test case in GDB. At the point the StackOverflowException happened, I'd trigger an infinite loop, then dump the stack using the `pfl()` call. I'd also use GDB's `bt` to view information about the native stack. I'd do that for both x86 and AArch64, to see what's causing the difference, and to see how significant it is.

-------------

PR: https://git.openjdk.org/jdk/pull/9934

From cstein at openjdk.org  Tue Aug 23 11:22:55 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 23 Aug 2022 11:22:55 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update configure to check for jtreg 7 or later
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Revert junit.java
   
   Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
   
   With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
   This change updates the hard-coded library tag value to the new JUnit JAR file.
   Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
   in order to unblock the "Update to use jtreg 7" PR 9393:
   https://github.com/openjdk/jdk/pull/9393
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448

-------------

Changes: https://git.openjdk.org/jdk/pull/9393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=04
  Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From ihse at openjdk.org  Tue Aug 23 19:00:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Aug 2022 19:00:38 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
Message-ID: <MMwEFrKFcaeMSW8w40l9U-UxdtcyHKFMO0Lh9L9k6AI=.f0ec8801-9b38-430a-a62c-b1d90d16fb86@github.com>

On Tue, 23 Aug 2022 11:22:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update configure to check for jtreg 7 or later
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Revert junit.java
>    
>    Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update to new JUnit JAR file
>    
>    With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
>    This change updates the hard-coded library tag value to the new JUnit JAR file.
>    Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
>    in order to unblock the "Update to use jtreg 7" PR 9393:
>    https://github.com/openjdk/jdk/pull/9393
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From duke at openjdk.org  Tue Aug 23 19:39:48 2022
From: duke at openjdk.org (Hannes Greule)
Date: Tue, 23 Aug 2022 19:39:48 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v5]
In-Reply-To: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
Message-ID: <6e64srLbjHyJ8Ub60mBRjPJzPaNNYcWm-MI5ETketgo=.68200038-aaa7-4a91-b023-3526e1449cca@github.com>

> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
> Parameter names are *not* emitted unless the `-parameter` flag is set.
> 
> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
> 
> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
> I also had to update some tests as they got a new constant pool entry.
> 
> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
> Please let me know if you want tests for specific appearances of synthetic parameters.

Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:

  address comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9862/files
  - new: https://git.openjdk.org/jdk/pull/9862/files/ebb09f8d..883a2dc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=03-04

  Stats: 64 lines in 2 files changed: 17 ins; 36 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9862.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9862/head:pull/9862

PR: https://git.openjdk.org/jdk/pull/9862

From duke at openjdk.org  Tue Aug 23 19:39:48 2022
From: duke at openjdk.org (Hannes Greule)
Date: Tue, 23 Aug 2022 19:39:48 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v4]
In-Reply-To: <KkrC4SYgbYLIol_huYfEM3LjOQNYG-UDqbM2BDHGK8s=.4bbd5557-0d29-4ee4-a26f-9f76002c07f4@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <KkrC4SYgbYLIol_huYfEM3LjOQNYG-UDqbM2BDHGK8s=.4bbd5557-0d29-4ee4-a26f-9f76002c07f4@github.com>
Message-ID: <oZnFxJ0f4LQElbvw_aakbbjB_zVUe2w1Cm-bx5bVBCc=.5fc5ce82-dae0-4488-9520-1200f3f5df0e@github.com>

On Fri, 19 Aug 2022 13:05:10 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup
>  - add annotation processing test

Hi, I addressed your comments. The annotation is definitely a cleaner solution, thank you for that suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From imkiva at islovely.icu  Fri Aug 26 09:04:19 2022
From: imkiva at islovely.icu (Kiva)
Date: Fri, 26 Aug 2022 17:04:19 +0800
Subject: Possible compiler bug causing LambdaConversionException
Message-ID: <3j6t0grqme-1@m0246573.ppops.net>

Hi all,

I am not sure whether this should be reported to amber-dev or compiler-dev so I am reporting it here (sorry!)
A minimal repro was attached below or you can visit here: https://gist.github.com/imkiva/8db13b6e578e473c1c9b977086bfe898

import java.util.function.BiFunction;

public class Bug {
  sealed interface Term {
    record Lit() implements Term {}
    record Lam(String x, Term a) implements Term {}
  }

  public static <X, T> void call(BiFunction<X, T, T> op, X x, T t) {
    op.apply(x, t);
  }

  public static void main(String[] args) {
    // this code works
    call(Term.Lam::new, "x", (Term) new Term.Lit());

    // this does not
    call(Term.Lam::new, "x", new Term.Lit());
    // java.lang.invoke.LambdaConversionException: Type mismatch for lambda argument 1: 
    // class java.lang.Record is not convertible to interface Term
  }
}

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220826/c5456df9/attachment.htm>

From forax at univ-mlv.fr  Fri Aug 26 09:52:56 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 26 Aug 2022 11:52:56 +0200 (CEST)
Subject: Possible compiler bug causing LambdaConversionException
In-Reply-To: <3j6t0grqme-1@m0246573.ppops.net>
References: <3j6t0grqme-1@m0246573.ppops.net>
Message-ID: <778285585.174679.1661507576604.JavaMail.zimbra@u-pem.fr>

Thanks, this is clearly a bug. 

The second call infer T as the intersection type Record & Term, which is erased to Record. 
Term.Lam::new is translated to an invokedynamic 
Method arguments: 
#49 (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; 
#50 REF_newInvokeSpecial Bug$Term$Lam."<init>":(Ljava/lang/String;LBug$Term;)V 
#56 (Ljava/lang/String;Ljava/lang/Record;)Ljava/lang/Record; 

This is a case where the compiler should desugar the method reference to a lambda with an upcast from Record to Term 
call ((String x, Record t) -> new Lam(x, (Term) t), "x" , new Term.Lit()); 

but tries to directly reference the constructor thus fails at runtime because the upcast is missing. 

regards, 
R?mi 

> From: "Kiva" <imkiva at islovely.icu>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Friday, August 26, 2022 11:04:19 AM
> Subject: Possible compiler bug causing LambdaConversionException

> Hi all,

> I am not sure whether this should be reported to amber-dev or compiler-dev so I
> am reporting it here (sorry!)

> A minimal repro was attached below or you can visit here:
> https://gist.github.com/imkiva/8db13b6e578e473c1c9b977086bfe898

> import java.util.function.BiFunction;

> public class Bug {

> sealed interface Term {

> record Lit() implements Term {}

> record Lam(String x, Term a) implements Term {}

> }

> public static <X, T> void call(BiFunction<X, T, T> op, X x, T t) {

> op.apply(x, t);

> }

> public static void main(String[] args) {

> // this code works

> call(Term.Lam::new, "x", (Term) new Term.Lit());

> // this does not

> call(Term.Lam::new, "x", new Term.Lit());

> // java.lang.invoke.LambdaConversionException: Type mismatch for lambda argument
> 1:

> // class java.lang.Record is not convertible to interface Term

> }

> }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220826/a922f3d8/attachment.htm>

From sundararajan.athijegannathan at oracle.com  Fri Aug 26 10:24:26 2022
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 26 Aug 2022 10:24:26 +0000
Subject: Possible compiler bug causing LambdaConversionException
Message-ID: <DM6PR10MB2954C31A57CC16261A714F33EA759@DM6PR10MB2954.namprd10.prod.outlook.com>

Thanks for reporting this bug. Filed: https://bugs.openjdk.org/browse/JDK-8292975

-Sundar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220826/00f49a85/attachment-0001.htm>

From dcubed at openjdk.org  Fri Aug 26 19:44:36 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 26 Aug 2022 19:44:36 GMT
Subject: RFR: 8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java -
 launch timeout
Message-ID: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>

A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor.
Also cleaned up an incorrect comment.

-------------

Commit messages:
 - 8207166: langtools/jdk/jshell/JdiHangingLaunchExecutionControlTest.java - launch timeout

Changes: https://git.openjdk.org/jdk/pull/10049/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10049&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8207166
  Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10049.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10049/head:pull/10049

PR: https://git.openjdk.org/jdk/pull/10049

From dcubed at openjdk.org  Fri Aug 26 19:44:36 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 26 Aug 2022 19:44:36 GMT
Subject: RFR: 8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java
 - launch timeout
In-Reply-To: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
References: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
Message-ID: <C3vu9qSquiHJqdpVTeNwSfRrDKBV_eoDVqM0YWH9uRQ=.07c3460a-bba1-47ab-9da6-1c008d5ac8bb@github.com>

On Fri, 26 Aug 2022 19:30:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor.
> Also cleaned up an incorrect comment.

Gory details:
JdiHangingLaunchExecutionControlTest.java uses
HangingRemoteAgent.java to test that a launcher
timeout is properly detected.

HangingRemoteAgent.java uses two hardcoded delay values:

private static final long DELAY = 4000L;
private static final int TIMEOUT = 2000;

The TIMEOUT value is passed to the launcher mechanism
so the launcher mechanism is given 2 seconds to issue:

    Launching JShell execution engine threw: Accept timed out

and the DELAY value is how long the HangingRemoteAgent
main() will loop in order to give the launcher time to fail.

There is also an incorrect comment in HangingRemoteAgent.java:

    * Hang for three minutes (long enough to cause a timeout).

I went back to the original integration of HangingRemoteAgent.java
and that comment has been there since the initial integration on
 2016.11.22.

It looks like the intended algorithm is for the HangingRemoteAgent
main() to loop for 2X the timeout value. The timeout value itself
should be scaled by the JTREG timeoutFactor.

-------------

PR: https://git.openjdk.org/jdk/pull/10049

From vromero at openjdk.org  Sat Aug 27 19:51:12 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 27 Aug 2022 19:51:12 GMT
Subject: RFR: 8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java
 - launch timeout
In-Reply-To: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
References: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
Message-ID: <Hxc6BZvzrujISR0IqxhlsrxI2oDGas8jkul_geQVo80=.60d2c107-084b-44c9-b59b-b49e1b60b659@github.com>

On Fri, 26 Aug 2022 19:30:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor.
> Also cleaned up an incorrect comment.

looks good to me

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10049

From dcubed at openjdk.org  Sun Aug 28 02:41:10 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sun, 28 Aug 2022 02:41:10 GMT
Subject: RFR: 8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java
 - launch timeout
In-Reply-To: <Hxc6BZvzrujISR0IqxhlsrxI2oDGas8jkul_geQVo80=.60d2c107-084b-44c9-b59b-b49e1b60b659@github.com>
References: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
 <Hxc6BZvzrujISR0IqxhlsrxI2oDGas8jkul_geQVo80=.60d2c107-084b-44c9-b59b-b49e1b60b659@github.com>
Message-ID: <35hOxpieGEXK8asGv5FBadLb7ngLTL8P6FFhcU_KXYE=.722c5c63-476f-4b5a-af51-990971b5c50a@github.com>

On Sat, 27 Aug 2022 19:47:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor.
>> Also cleaned up an incorrect comment.
>
> looks good to me

@vicente-romero-oracle - Thanks for the review!

-------------

PR: https://git.openjdk.org/jdk/pull/10049

From darcy at openjdk.org  Tue Aug 30 00:12:33 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Aug 2022 00:12:33 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in
 javac
Message-ID: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>

Update to remove support for -source/-target/--release 7 from javac.

As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

-------------

Commit messages:
 - Small refactoring to remove more stale code.
 - Remove effectively dead code.
 - Adjust data for CheckExamples test.
 - Partial restore of DEFAULT_METHODS Source.Feature for test java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java.
 - Merge branch 'master' into JDK-8173605
 - Fix MultiReleaseJars.java.
 - Test fixes.
 - Clean langtools test run.
 - CheckExamples passes.
 - Type annotations.
 - ... and 13 more: https://git.openjdk.org/jdk/compare/76ee5495...f3095350

Changes: https://git.openjdk.org/jdk/pull/10074/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10074&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8173605
  Stats: 4514 lines in 156 files changed: 25 ins; 4362 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/10074.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10074/head:pull/10074

PR: https://git.openjdk.org/jdk/pull/10074

From darcy at openjdk.org  Tue Aug 30 00:20:09 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Aug 2022 00:20:09 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <J2LDFqwlrsQBl2SWnpEOGHYpoA7T_Yj4EMhXEUBgnxg=.8181060a-e72b-4cf9-872f-db022962d948@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

Please also review the accompanying CSR:

https://bugs.openjdk.org/browse/JDK-8293047

Note that the DEFAULT_METHODS enum constant is used indirectly by a test to force a class file's minor version bits to be set as if a preview feature were used. If some other idiom is available, the DEFAULT_METHOD constant could be removed.

Tier 1 and tier 2 test results were clean with this changes.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From darcy at openjdk.org  Tue Aug 30 01:05:23 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Aug 2022 01:05:23 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <J2LDFqwlrsQBl2SWnpEOGHYpoA7T_Yj4EMhXEUBgnxg=.8181060a-e72b-4cf9-872f-db022962d948@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
 <J2LDFqwlrsQBl2SWnpEOGHYpoA7T_Yj4EMhXEUBgnxg=.8181060a-e72b-4cf9-872f-db022962d948@github.com>
Message-ID: <7caOzUK-O_rtHE24lEnLDODLPj_gvixrSSFI-Is5zS0=.78f37a82-868c-4719-9145-cb2bd8df0588@github.com>

On Tue, 30 Aug 2022 00:16:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please also review the accompanying CSR:
> 
> https://bugs.openjdk.org/browse/JDK-8293047
> 
> Note that the DEFAULT_METHODS enum constant is used indirectly by a test to force a class file's minor version bits to be set as if a preview feature were used. If some other idiom is available, the DEFAULT_METHOD constant could be removed.
> 
> Tier 1 and tier 2 test results were clean with this changes.

PS I'll run a copyright update script before any push.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From alanb at openjdk.org  Tue Aug 30 06:29:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Aug 2022 06:29:52 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <D5aefTnEewXyKU1G-uga7fyU4_v9mYxW-n4JC8iwJOk=.0be3f8fe-cf38-4032-b39a-40312b620277@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

test/jdk/java/lang/reflect/OldenCompilingWithDefaults.java line 28:

> 26:  * @bug 8009267
> 27:  * @summary Verify uses of isAnnotationPresent compile under older source versions
> 28:  * @compile OldenCompilingWithDefaults.java

I skimmed through the description of JDK-8009267 and I'm wondering if this test is of any value now.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From jpai at openjdk.org  Tue Aug 30 09:16:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Aug 2022 09:16:16 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
Message-ID: <8NfRtLx-sAEoJqvDeVwo9SFSASKzMN6w7ul9yw-7C98=.d41ee1ea-efa1-498f-9b5a-ca0acf738921@github.com>

On Tue, 23 Aug 2022 11:22:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update configure to check for jtreg 7 or later
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Revert junit.java
>    
>    Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update to new JUnit JAR file
>    
>    With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
>    This change updates the hard-coded library tag value to the new JUnit JAR file.
>    Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
>    in order to unblock the "Update to use jtreg 7" PR 9393:
>    https://github.com/openjdk/jdk/pull/9393
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448

Hello Christian, is it intentional that in some file the minimum required jtreg version is represented as `7` (`lib-tests.m4`) and in some other files as `7+1` (GitHub actions config file, then the TEST.ROOT files)?

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From cstein at openjdk.org  Tue Aug 30 09:33:05 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 30 Aug 2022 09:33:05 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <8NfRtLx-sAEoJqvDeVwo9SFSASKzMN6w7ul9yw-7C98=.d41ee1ea-efa1-498f-9b5a-ca0acf738921@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
 <8NfRtLx-sAEoJqvDeVwo9SFSASKzMN6w7ul9yw-7C98=.d41ee1ea-efa1-498f-9b5a-ca0acf738921@github.com>
Message-ID: <6A9Z9oXjfXGmi9_LWIF_TMtJtS483A98QA0rJPuzus0=.ab5a3a72-7877-4bbf-8c39-5663476ac5e1@github.com>

On Tue, 30 Aug 2022 09:14:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Christian, is it intentional that in some file the minimum required jtreg version is represented as `7` (`lib-tests.m4`) and in some other files as `7+1` (GitHub actions config file, then the TEST.ROOT files)?

Yes. Some systems require the exact version tag `7+1` others only the short version string `7`.

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From jpai at openjdk.org  Tue Aug 30 09:36:15 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Aug 2022 09:36:15 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
Message-ID: <RQ9Vo_kj5eYgQQAoKI7l7tJVurWIydpC_Bn4VyyVqY4=.3f8fe78e-b4f7-4853-ba51-9654a8477686@github.com>

On Tue, 23 Aug 2022 11:22:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update configure to check for jtreg 7 or later
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Revert junit.java
>    
>    Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update to new JUnit JAR file
>    
>    With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
>    This change updates the hard-coded library tag value to the new JUnit JAR file.
>    Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
>    in order to unblock the "Update to use jtreg 7" PR 9393:
>    https://github.com/openjdk/jdk/pull/9393
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From darcy at openjdk.org  Tue Aug 30 21:59:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Aug 2022 21:59:10 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <D5aefTnEewXyKU1G-uga7fyU4_v9mYxW-n4JC8iwJOk=.0be3f8fe-cf38-4032-b39a-40312b620277@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
 <D5aefTnEewXyKU1G-uga7fyU4_v9mYxW-n4JC8iwJOk=.0be3f8fe-cf38-4032-b39a-40312b620277@github.com>
Message-ID: <nXgp52vhSkJctHnSl33uPP1F0kDJERU4-7QRZRZX_UI=.957ce4e7-7793-46d5-a62d-cc1cea80b9cc@github.com>

On Tue, 30 Aug 2022 06:26:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Update to remove support for -source/-target/--release 7 from javac.
>> 
>> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.
>
> test/jdk/java/lang/reflect/OldenCompilingWithDefaults.java line 28:
> 
>> 26:  * @bug 8009267
>> 27:  * @summary Verify uses of isAnnotationPresent compile under older source versions
>> 28:  * @compile OldenCompilingWithDefaults.java
> 
> I skimmed through the description of JDK-8009267 and I'm wondering if this test is of any value now.

Certainly less useful than it once was!

I can remove it in the next push.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From vromero at openjdk.org  Wed Aug 31 17:17:07 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 31 Aug 2022 17:17:07 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <LhYwbXuOrtQEJvkqlQNR3t-_BLDv8DpUgdsw6vzQ54w=.f5ee0ac8-fe04-4f17-9393-158580c87a37@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

looks good to me

the PR looks good to me. You have mentioned that further refactorings could be done later on, I agree but you are already removing a lot of code, although that could have been forced to make some tests pass. I would recommend removing some support for 7 at `com.sun.tools.javac.comp.Infer` particularly the one guarded by `allowGraphInference`. I can also help with that later on if you prefer. If so please assign a follow-up for this issue to myself

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10074

From darcy at openjdk.org  Wed Aug 31 17:25:09 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 31 Aug 2022 17:25:09 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <LhYwbXuOrtQEJvkqlQNR3t-_BLDv8DpUgdsw6vzQ54w=.f5ee0ac8-fe04-4f17-9393-158580c87a37@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
 <LhYwbXuOrtQEJvkqlQNR3t-_BLDv8DpUgdsw6vzQ54w=.f5ee0ac8-fe04-4f17-9393-158580c87a37@github.com>
Message-ID: <HWqiwIzAeBCWpReez9PDRGQuEq0yk2sniFjbWvisOPo=.24b59d46-b238-46d4-8cba-79d5a8dcc4ee@github.com>

On Wed, 31 Aug 2022 17:13:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> the PR looks good to me. You have mentioned that further refactorings could be done later on, I agree but you are already removing a lot of code, although that could have been forced to make some tests pass. I would recommend removing some support for 7 at `com.sun.tools.javac.comp.Infer` particularly the one guarded by `allowGraphInference`. I can also help with that later on if you prefer. If so please assign a follow-up for this issue to myself

Thanks Vicente; I assigned

    JDK-8293051: Further refactor javac after removal of -source/-target/--release 7

to you.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From jlahoda at openjdk.org  Wed Aug 31 17:59:45 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 31 Aug 2022 17:59:45 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up
Message-ID: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>

Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.

But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
-parsing only sources that were modified first,
-computing an "API" hash for them,
-if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before

There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.

Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.

On my laptop, doing:

touch src/java.base/share/classes/java/lang/Object.java ; time make

can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.

The caveats of this patch include:
-it is more involved than the existing plugin
-it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
-for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
-as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
-it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently

-------------

Commit messages:
 - 8293116: Incremental JDK build could be sped up

Changes: https://git.openjdk.org/jdk/pull/10104/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293116
  Stats: 543 lines in 6 files changed: 513 ins; 6 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/10104.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10104/head:pull/10104

PR: https://git.openjdk.org/jdk/pull/10104

From erikj at openjdk.org  Wed Aug 31 20:14:10 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 31 Aug 2022 20:14:10 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up
In-Reply-To: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
Message-ID: <XqlECNe_yQWkz0useWv3mru_6Wb26we54omiI2-DSSQ=.f83f6788-8f54-4e5e-b1bd-99ab59c79ed4@github.com>

On Wed, 31 Aug 2022 17:51:31 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
> 
> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
> -parsing only sources that were modified first,
> -computing an "API" hash for them,
> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
> 
> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
> 
> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
> 
> On my laptop, doing:
> 
> touch src/java.base/share/classes/java/lang/Object.java ; time make
> 
> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
> 
> The caveats of this patch include:
> -it is more involved than the existing plugin
> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently

This is a really cool feature, thanks for doing it!

make/common/JavaCompilation.gmk line 451:

> 449:     # $$($1_VARDEPS_FILE) is used as dependency to track changes in set of
> 450:     # list of files.
> 451:     $$($1_COMPILE_TARGET): $$($1_SRCS) $$($1_DEPENDS) \

What's the reason for inlining this recipe into the main compilation recipe? I would think generating the modfiles file in the FILELIST rule would help reduce the noise from non source files in the prerequisites list (as the old FILELIST rule had a lot less prerequisites listed). Keeping this recipe separate also limits regeneration of the FILELIST.

make/common/JavaCompilation.gmk line 456:

> 454: 		$$(call LogWarn, Compiling up to $$(words $$($1_SRCS)) files for $1)
> 455: 		$$(eval $$(call ListPathsSafely, $1_SRCS, $$($1_FILELIST)))
> 456: 		$$(call WriteFile, "-XDmodifiedInputs=$$? ", $$@.modfiles)

I'm not sure WriteFile is safe to use here. `$?` could potentially contain all files in `$1_SRCS`, which is why we use ListPathsSafely in the first place. This is only a problem if using make <4.0, but as long as that's not prohibited, we need to keep it working without the file function.

-------------

PR: https://git.openjdk.org/jdk/pull/10104