From darcy at openjdk.org Thu Sep 1 05:23:25 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Sep 2022 05:23:25 GMT Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in javac [v2] In-Reply-To: References: Message-ID: > 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. 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 27 additional commits since the last revision: - Update copyrights. - Delete unneeded test. - Merge branch 'master' into JDK-8173605 - Merge branch 'master' into JDK-8173605 - 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. - ... and 17 more: https://git.openjdk.org/jdk/compare/a81a20ee...b2039d68 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10074/files - new: https://git.openjdk.org/jdk/pull/10074/files/f3095350..b2039d68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10074&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10074&range=00-01 Stats: 14641 lines in 536 files changed: 4475 ins; 7382 del; 2784 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 jlahoda at openjdk.org Thu Sep 1 12:28:15 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 Sep 2022 12:28:15 GMT Subject: RFR: 8290709: Incorrect dominance error for unconditional pattern vs. null In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 16:12:55 GMT, Aggelos Biboudis wrote: > 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. Looks good. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.org/jdk/pull/9732 From jlahoda at openjdk.org Thu Sep 1 12:49:09 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 Sep 2022 12:49:09 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v2] In-Reply-To: References: Message-ID: > 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 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10104/files - new: https://git.openjdk.org/jdk/pull/10104/files/778a6719..f1e19e8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=00-01 Stats: 14 lines in 1 file changed: 6 ins; 2 del; 6 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 jlahoda at openjdk.org Thu Sep 1 12:49:11 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 Sep 2022 12:49:11 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v2] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 20:02:46 GMT, Erik Joelsson wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflecting review feedback. > > 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. I've tried to fix this in: https://github.com/openjdk/jdk/pull/10104/commits/f1e19e8b636ddf08500a6401ce1488265f7b9446 > 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. Is there some recommendation on how to generate what is needed? Which is: "-XDmodifiedFiles= " I was looking at the `WriteFile` rule, and it is not clear to be what is the problem there, but I'm not very knowledgeable of the build system. I was trying to use `ListPathsSafely`, but wasn't able to find a way that would be working. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10104 From erikj at openjdk.org Thu Sep 1 13:15:11 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 Sep 2022 13:15:11 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 12:49:09 GMT, Jan Lahoda 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 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. Sorry, I was so focused on JavaCompilation.gmk yesterday so I forgot about the rest of the build changes. make/CompileInterimLangtools.gmk line 56: > 54: $(call MakeDir, $(@D)) > 55: $(SED) $(INTERIM_TOOL_PROVIDER_PATTERN) $< > $@ > 56: Could you introduce a new section here with a comment header briefly describing what this is doing and why? It's currently under a section describing module-info.java. Let the last line of each section be the `TARGETS += ...` line. make/CompileInterimLangtools.gmk line 92: > 90: Standard.java, \ > 91: EXTRA_FILES := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java \ > 92: $($1.interim_EXTRA_FILES), \ Style nit. We try to avoid aligning broken up lines like this. Please just use 4 space continuation indent. (See https://openjdk.org/groups/build/doc/code-conventions.html) ------------- PR: https://git.openjdk.org/jdk/pull/10104 From erikj at openjdk.org Thu Sep 1 13:31:20 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 Sep 2022 13:31:20 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 12:43:12 GMT, Jan Lahoda wrote: >> 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. > > Is there some recommendation on how to generate what is needed? Which is: > > "-XDmodifiedFiles= " > > > I was looking at the `WriteFile` rule, and it is not clear to be what is the problem there, but I'm not very knowledgeable of the build system. > > I was trying to use `ListPathsSafely`, but wasn't able to find a way that would be working. > > Thanks! Before make 4.0, there was no `$(file ...)` function in make. That meant that if you needed to write something to a file directly from the makefile, you had to do something like `$(shell echo "foo" > /my/file)`. This works ok as long as the amount of text you need to write is small enough, but when writing long lists of filenames, you will eventually hit OS limits on command line length (which are different on different OSes, most notably much shorter on Windows). Our solution to this was ListPathsSafely, which breaks up long lists of path names into manageable chunks (and also compresses parts of the path using sed). In make 4.0, the $(file) function was introduced, which makes this so much easier. Since it was also more performant, I implemented a 4.0 version of ListPathsSafely. However, we haven't changed the build to require make >4.0, so we have to keep both implementations around. The WriteFile macro was only intended writing smaller files, so doesn't have any of the command splitting functionality of ListPathsSafely. So to answer your question, no there isn't a good way to achieve what you are asking for today, not without modifying or extending the macros. One could imagine adding a flag to ListPathsSafely that made it use space instead of newline as separator. Another solution could be to have Depend.java accept something like "-XDmodifiedFilesFile=/path/to/file" where the file is a list as ListPathsSafely would create it. We could also consider requiring make 4.0, but that will need some socializing first. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From abimpoudis at openjdk.org Thu Sep 1 16:13:21 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 1 Sep 2022 16:13:21 GMT Subject: Integrated: 8290709: Incorrect dominance error for unconditional pattern vs. null In-Reply-To: References: Message-ID: <748jy-tASvKQ077DSPXOplQziJF3TeGhWD04dMCB1tI=.a249f975-75fc-4b81-84a6-baa46bbc500b@github.com> On Wed, 3 Aug 2022 16:12:55 GMT, Aggelos Biboudis wrote: > 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. This pull request has now been integrated. Changeset: 9444a081 Author: Aggelos Biboudis Committer: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1 Stats: 66 lines in 6 files changed: 25 ins; 20 del; 21 mod 8290709: Incorrect dominance error for unconditional pattern vs. null Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/9732 From jlahoda at openjdk.org Thu Sep 1 16:39:11 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 Sep 2022 16:39:11 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 13:25:19 GMT, Erik Joelsson wrote: >> Is there some recommendation on how to generate what is needed? Which is: >> >> "-XDmodifiedFiles= " >> >> >> I was looking at the `WriteFile` rule, and it is not clear to be what is the problem there, but I'm not very knowledgeable of the build system. >> >> I was trying to use `ListPathsSafely`, but wasn't able to find a way that would be working. >> >> Thanks! > > Before make 4.0, there was no `$(file ...)` function in make. That meant that if you needed to write something to a file directly from the makefile, you had to do something like `$(shell echo "foo" > /my/file)`. This works ok as long as the amount of text you need to write is small enough, but when writing long lists of filenames, you will eventually hit OS limits on command line length (which are different on different OSes, most notably much shorter on Windows). Our solution to this was ListPathsSafely, which breaks up long lists of path names into manageable chunks (and also compresses parts of the path using sed). > > In make 4.0, the $(file) function was introduced, which makes this so much easier. Since it was also more performant, I implemented a 4.0 version of ListPathsSafely. However, we haven't changed the build to require make >4.0, so we have to keep both implementations around. > > The WriteFile macro was only intended writing smaller files, so doesn't have any of the command splitting functionality of ListPathsSafely. > > So to answer your question, no there isn't a good way to achieve what you are asking for today, not without modifying or extending the macros. One could imagine adding a flag to ListPathsSafely that made it use space instead of newline as separator. Another solution could be to have Depend.java accept something like > > "-XDmodifiedFilesFile=/path/to/file" > > where the file is a list as ListPathsSafely would create it. > > We could also consider requiring make 4.0, but that will need some socializing first. I can change `Depend` for this, that is easy, but it is not clear how to write the file. I've tried the naive `$$(eval $$(call ListPathsSafely, $$?, $$($1_MODFILES)))` at the end of `$$($1_FILELIST):` but that does not seem to write the modified files into the file - it produces an empty file. Is there a way for me to write the modified files into the file? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From darcy at openjdk.org Thu Sep 1 16:46:21 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Sep 2022 16:46:21 GMT Subject: Integrated: JDK-8173605: Remove support for source and target 1.7 option in javac In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy 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. This pull request has now been integrated. Changeset: 2d18dda3 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/2d18dda3f2074a4f8b9a0c62ece9ac6d5284e93b Stats: 4595 lines in 156 files changed: 25 ins; 4413 del; 157 mod 8173605: Remove support for source and target 1.7 option in javac Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10074 From erikj at openjdk.org Thu Sep 1 16:51:30 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 Sep 2022 16:51:30 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:36:55 GMT, Jan Lahoda wrote: >> Before make 4.0, there was no `$(file ...)` function in make. That meant that if you needed to write something to a file directly from the makefile, you had to do something like `$(shell echo "foo" > /my/file)`. This works ok as long as the amount of text you need to write is small enough, but when writing long lists of filenames, you will eventually hit OS limits on command line length (which are different on different OSes, most notably much shorter on Windows). Our solution to this was ListPathsSafely, which breaks up long lists of path names into manageable chunks (and also compresses parts of the path using sed). >> >> In make 4.0, the $(file) function was introduced, which makes this so much easier. Since it was also more performant, I implemented a 4.0 version of ListPathsSafely. However, we haven't changed the build to require make >4.0, so we have to keep both implementations around. >> >> The WriteFile macro was only intended writing smaller files, so doesn't have any of the command splitting functionality of ListPathsSafely. >> >> So to answer your question, no there isn't a good way to achieve what you are asking for today, not without modifying or extending the macros. One could imagine adding a flag to ListPathsSafely that made it use space instead of newline as separator. Another solution could be to have Depend.java accept something like >> >> "-XDmodifiedFilesFile=/path/to/file" >> >> where the file is a list as ListPathsSafely would create it. >> >> We could also consider requiring make 4.0, but that will need some socializing first. > > I can change `Depend` for this, that is easy, but it is not clear how to write the file. I've tried the naive `$$(eval $$(call ListPathsSafely, $$?, $$($1_MODFILES)))` at the end of `$$($1_FILELIST):` but that does not seem to write the modified files into the file - it produces an empty file. Is there a way for me to write the modified files into the file? Thanks. Oh right, ListPathsSafely takes the data to write by reference, not by value (as in you supply the name of a variable that contains the data, not the data itself). I doubt `?` can be sent into an eval as a variable name, but I may be wrong. Perhaps you could extract the value into another variable first in a separate line in the recipe, something like this: $$(eval $1_MODFILES := $$?) $$(eval $$(call ListPathsSafely, $1_MODFILES, $$($1_MODFILELIST))) (note that I redefined $1_MODFILES to be the list of modified files and introduced a new variable $1_MODFILELIST for the filename where we print it) ------------- PR: https://git.openjdk.org/jdk/pull/10104 From jlahoda at openjdk.org Thu Sep 1 18:35:24 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 Sep 2022 18:35:24 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: > 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 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10104/files - new: https://git.openjdk.org/jdk/pull/10104/files/f1e19e8b..23e3b756 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=01-02 Stats: 26 lines in 3 files changed: 16 ins; 4 del; 6 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 jlahoda at openjdk.org Thu Sep 1 18:35:25 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 Sep 2022 18:35:25 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: <0ZqiRmvOUllIClJmDVR20sLJhIj1_Kjwvzpj7A-we7I=.d3324291-142a-4854-bd73-fce7803ba8ec@github.com> On Thu, 1 Sep 2022 16:48:48 GMT, Erik Joelsson wrote: > Oh right, ListPathsSafely takes the data to write by reference, not by value (as in you supply the name of a variable that contains the data, not the data itself). I doubt `?` can be sent into an eval as a variable name, but I may be wrong. Perhaps you could extract the value into another variable first in a separate line in the recipe, something like this: > > ``` > $$(eval $1_MODFILES := $$?) > $$(eval $$(call ListPathsSafely, $1_MODFILES, $$($1_MODFILELIST))) > ``` > > (note that I redefined $1_MODFILES to be the list of modified files and introduced a new variable $1_MODFILELIST for the filename where we print it) Thanks! Done in: https://github.com/openjdk/jdk/pull/10104/commits/23e3b75679908d26b76cc291a8efba06879c0d83 ------------- PR: https://git.openjdk.org/jdk/pull/10104 From jlahoda at openjdk.org Thu Sep 1 18:39:42 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 Sep 2022 18:39:42 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v5] In-Reply-To: References: Message-ID: > 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 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 six additional commits since the last revision: - Reflecting review feedback. - Merge branch 'master' into JDK-8291769 - Using a custom record instead of a generic Pair. - Fixing test. - Properly handle null record components. - 8291769: Translation of switch with record patterns could be improved ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9746/files - new: https://git.openjdk.org/jdk/pull/9746/files/1ff63342..f880c156 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=03-04 Stats: 79351 lines in 1546 files changed: 36286 ins; 34192 del; 8873 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 erikj at openjdk.org Thu Sep 1 20:48:11 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 Sep 2022 20:48:11 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: <0lRYvHfl8Dc4zxlrQJA0Y5n5eDoIovimmMm9Ph9BES0=.e1380b14-b098-4c9f-a0ad-6f0d794bc252@github.com> On Thu, 1 Sep 2022 18:35:24 GMT, Jan Lahoda 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 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. Build changes look good! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/10104 From darcy at openjdk.org Thu Sep 1 21:52:57 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Sep 2022 21:52:57 GMT Subject: RFR: JDK-8293003: Review running time of Warn5 regression test Message-ID: Refactoring of the Warn5 regression test to reduce its running time by more than 50%. Included a small refactoring in Warn4 to use text blocks too. ------------- Commit messages: - JDK-8293003: Review running time of Warn5 regression test Changes: https://git.openjdk.org/jdk/pull/10130/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10130&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293003 Stats: 28 lines in 2 files changed: 9 ins; 1 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/10130.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10130/head:pull/10130 PR: https://git.openjdk.org/jdk/pull/10130 From vromero at openjdk.org Fri Sep 2 02:40:38 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 Sep 2022 02:40:38 GMT Subject: RFR: JDK-8293003: Review running time of Warn5 regression test In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 20:50:50 GMT, Joe Darcy wrote: > Refactoring of the Warn5 regression test to reduce its running time by more than 50%. > > Included a small refactoring in Warn4 to use text blocks too. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10130 From darcy at openjdk.org Fri Sep 2 02:57:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 Sep 2022 02:57:45 GMT Subject: Integrated: JDK-8293003: Review running time of Warn5 regression test In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 20:50:50 GMT, Joe Darcy wrote: > Refactoring of the Warn5 regression test to reduce its running time by more than 50%. > > Included a small refactoring in Warn4 to use text blocks too. This pull request has now been integrated. Changeset: 3ac91b08 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/3ac91b08cbe16bc1a347178f853513f930ffeaf3 Stats: 28 lines in 2 files changed: 9 ins; 1 del; 18 mod 8293003: Review running time of Warn5 regression test Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10130 From vromero at openjdk.org Fri Sep 2 15:54:41 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 Sep 2022 15:54:41 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 18:35:24 GMT, Jan Lahoda 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 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. javac changes looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10104 From vromero at openjdk.org Fri Sep 2 21:19:11 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 Sep 2022 21:19:11 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 Message-ID: This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing? TIA [1] https://github.com/openjdk/jdk/pull/10074 ------------- Commit messages: - 8293051: Further refactor javac after removal of -source/-target/--release 7 Changes: https://git.openjdk.org/jdk/pull/10150/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10150&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293051 Stats: 255 lines in 21 files changed: 10 ins; 198 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/10150.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10150/head:pull/10150 PR: https://git.openjdk.org/jdk/pull/10150 From vromero at openjdk.org Fri Sep 2 21:35:46 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 Sep 2022 21:35:46 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: > This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing? > > TIA > > [1] https://github.com/openjdk/jdk/pull/10074 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: fixing additional test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10150/files - new: https://git.openjdk.org/jdk/pull/10150/files/331e4392..29f0b8a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10150&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10150&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10150.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10150/head:pull/10150 PR: https://git.openjdk.org/jdk/pull/10150 From darcy at openjdk.org Fri Sep 2 21:46:00 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 Sep 2022 21:46:00 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero wrote: >> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing? >> >> TIA >> >> [1] https://github.com/openjdk/jdk/pull/10074 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing additional test src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 216: > 214: POLY(JDK8), > 215: LAMBDA(JDK8, Fragments.FeatureLambda, DiagKind.PLURAL), > 216: DEFAULT_METHODS(JDK8, Fragments.FeatureDefaultMethods, DiagKind.PLURAL), As noted in https://github.com/openjdk/jdk/pull/10074#issuecomment-1230998246, if DEFAULT_METHODS is removed, there is a core libs test that will fail. I believe the functionality request is a standard idiom for forcing a source file to be compiled as Preview. Merely setting -XDpreview (however that hidden option is spelled) is not sufficient. A feature that triggers a checkSourceLevel call is needed too. ------------- PR: https://git.openjdk.org/jdk/pull/10150 From vromero at openjdk.org Fri Sep 2 21:54:43 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 Sep 2022 21:54:43 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 21:42:16 GMT, Joe Darcy wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing additional test > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 216: > >> 214: POLY(JDK8), >> 215: LAMBDA(JDK8, Fragments.FeatureLambda, DiagKind.PLURAL), >> 216: DEFAULT_METHODS(JDK8, Fragments.FeatureDefaultMethods, DiagKind.PLURAL), > > As noted in https://github.com/openjdk/jdk/pull/10074#issuecomment-1230998246, if DEFAULT_METHODS is removed, there is a core libs test that will fail. > > I believe the functionality request is a standard idiom for forcing a source file to be compiled as Preview. Merely setting -XDpreview (however that hidden option is spelled) is not sufficient. A feature that triggers a checkSourceLevel call is needed too. that can be worked out I think as I did with other tests, it should show up in the mach5 run, are you referring to: `PreviewHiddenClass.java`? ------------- PR: https://git.openjdk.org/jdk/pull/10150 From darcy at openjdk.org Fri Sep 2 23:24:53 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 Sep 2022 23:24:53 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 21:47:19 GMT, Vicente Romero wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 216: >> >>> 214: POLY(JDK8), >>> 215: LAMBDA(JDK8, Fragments.FeatureLambda, DiagKind.PLURAL), >>> 216: DEFAULT_METHODS(JDK8, Fragments.FeatureDefaultMethods, DiagKind.PLURAL), >> >> As noted in https://github.com/openjdk/jdk/pull/10074#issuecomment-1230998246, if DEFAULT_METHODS is removed, there is a core libs test that will fail. >> >> I believe the functionality request is a standard idiom for forcing a source file to be compiled as Preview. Merely setting -XDpreview (however that hidden option is spelled) is not sufficient. A feature that triggers a checkSourceLevel call is needed too. > > that can be worked out I think as I did with other tests, it should show up in the mach5 run, are you referring to: `PreviewHiddenClass.java`? Pretty sure the test in question was under java.lang.invoke in the libraries (i.e. test/jdk vs test/langtools) area. If we come up for a supported idiom for this, there is at least one other test I'd want to update to use it; that can be done as future work. ------------- PR: https://git.openjdk.org/jdk/pull/10150 From vromero at openjdk.org Sat Sep 3 02:51:34 2022 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 3 Sep 2022 02:51:34 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 23:20:59 GMT, Joe Darcy wrote: >> that can be worked out I think as I did with other tests, it should show up in the mach5 run, are you referring to: `PreviewHiddenClass.java`? > > Pretty sure the test in question was under java.lang.invoke in the libraries (i.e. test/jdk vs test/langtools) area. > > If we come up for a supported idiom for this, there is at least one other test I'd want to update to use it; that can be done as future work. all tier1-3 tests are passing in mach5 ------------- PR: https://git.openjdk.org/jdk/pull/10150 From darcy at openjdk.org Sat Sep 3 16:34:31 2022 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 3 Sep 2022 16:34:31 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero wrote: >> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing? >> >> TIA >> >> [1] https://github.com/openjdk/jdk/pull/10074 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing additional test Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10150 From darcy at openjdk.org Sat Sep 3 16:34:32 2022 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 3 Sep 2022 16:34:32 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 02:47:50 GMT, Vicente Romero wrote: >> Pretty sure the test in question was under java.lang.invoke in the libraries (i.e. test/jdk vs test/langtools) area. >> >> If we come up for a supported idiom for this, there is at least one other test I'd want to update to use it; that can be done as future work. > > all tier1-3 tests are passing in mach5, I guess you were referring to: `test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java` which I have modified to play with records. Sounds good. ------------- PR: https://git.openjdk.org/jdk/pull/10150 From vromero at openjdk.org Sat Sep 3 18:02:50 2022 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 3 Sep 2022 18:02:50 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 16:30:56 GMT, Joe Darcy wrote: >> all tier1-3 tests are passing in mach5, I guess you were referring to: `test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java` which I have modified to play with records. > > Sounds good. thanks for the review ------------- PR: https://git.openjdk.org/jdk/pull/10150 From cstein at openjdk.org Mon Sep 5 06:12:18 2022 From: cstein at openjdk.org (Christian Stein) Date: Mon, 5 Sep 2022 06:12:18 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: References: Message-ID: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@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 14 commits: - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - 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 - ... and 4 more: https://git.openjdk.org/jdk/compare/3464019d...16b140ab ------------- Changes: https://git.openjdk.org/jdk/pull/9393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=05 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 stuefe at openjdk.org Mon Sep 5 06:39:21 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 5 Sep 2022 06:39:21 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> References: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> Message-ID: On Mon, 5 Sep 2022 06:12:18 GMT, Christian Stein 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 14 commits: > > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - 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 > - ... and 4 more: https://git.openjdk.org/jdk/compare/3464019d...16b140ab Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9393 From cstein at openjdk.org Mon Sep 5 07:21:41 2022 From: cstein at openjdk.org (Christian Stein) Date: Mon, 5 Sep 2022 07:21:41 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: References: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> Message-ID: <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com> On Mon, 5 Sep 2022 06:36:04 GMT, Thomas Stuefe wrote: > Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version? Yes, down to JDK 11. Quote from [Coming soon: jtreg 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html) > Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it. And it should have said more correctly: _...requires a recent release of JDK 11 **or later** to run it._ ------------- PR: https://git.openjdk.org/jdk/pull/9393 From stuefe at openjdk.org Mon Sep 5 07:42:41 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 5 Sep 2022 07:42:41 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com> References: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com> Message-ID: On Mon, 5 Sep 2022 07:18:09 GMT, Christian Stein wrote: > > Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version? > > Yes, down to JDK 11. > > Quote from [Coming soon: jtreg 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html) > > > Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it. I read this to mean JT_JAVA, so the JVM running jtreg, not the testee VM. But you are saying that the testee VM (`-jdk` option) can be JDK11 or later? I wonder whether I can use jtreg7 to test downport JDKs, especially since you wrote "This did affect some existing JDK tests, but those tests that relied on specific jar file names have already been updated." So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right? ------------- PR: https://git.openjdk.org/jdk/pull/9393 From cstein at openjdk.org Mon Sep 5 07:50:33 2022 From: cstein at openjdk.org (Christian Stein) Date: Mon, 5 Sep 2022 07:50:33 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: References: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com> Message-ID: On Mon, 5 Sep 2022 07:38:33 GMT, Thomas Stuefe wrote: > So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right? Yes. Otherwise those tests will fail as they still do depend on hard-coded names of 3rd-party JAR files. Find backport candidates listed as Sub-Tasks number 3 to 5 at https://bugs.openjdk.org/browse/JDK-8289798 (Sub-Tasks number 1 and 2 were closed without changes.) ------------- PR: https://git.openjdk.org/jdk/pull/9393 From mcimadamore at openjdk.org Mon Sep 5 08:50:46 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Sep 2022 08:50:46 GMT Subject: RFR: 8290561: Coalesce incubator-module warnings for single-file source-code programs In-Reply-To: References: Message-ID: <6Em_3PiMnnhcQgk6QkaVX_lzNMSQZeR6IVXDjJQy2lc=.32c24caf-d6f1-4f2c-a098-e04f8f15c2e9@github.com> On Fri, 22 Jul 2022 06:58:03 GMT, Jan Lahoda wrote: > Consider a trivial code like: > > public class Main { > public static void main(String... args) {} > } > > > And an execution like: > > $ java --add-modules jdk.incubator.concurrent Main.java > WARNING: Using incubator modules: jdk.incubator.concurrent > warning: using incubating module(s): jdk.incubator.concurrent > 1 warning > > > Having two warnings (one from runtime, one from javac) seems unnecessary. The patch proposed herein tries to avoid the javac warning, keeping only the runtime one. The conditions under which an incubator module is ignored w.r.t. this warning are: > > * the boot Module layer has the module (hence, presumably, the runtime already provided the warning) > * the javac run is (likely) from the source launcher. This is being done using a custom javac option, `-XDsourceLauncher` (which can possibly be used in other cases). > > This is to avoid cases where we would incorrectly suppress the incubator warning, e.g. when `-XDsourceLauncher` would be passed on the command line. > > There are other ways to attempt to detect javac invocations from the source launcher - a distinct file manager is used by the source launcher (but detection of the specific file manager does not feel in line with general javac approach); or use of the `jdk.internal.javac.source` system property set by the native launcher (but this is only set when `--source` option is used, as far as I know, and javac also typically does not check system properties). > > Note that there is JDK-8290563 to improve the text of the javac warning. Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9607 From ihse at openjdk.org Mon Sep 5 12:23:25 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Sep 2022 12:23:25 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 18:35:24 GMT, Jan Lahoda 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 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. make/common/JavaCompilation.gmk line 455: > 453: $$(call LogWarn, Compiling up to $$(words $$($1_SRCS)) files for $1) > 454: $$(eval $$(call ListPathsSafely, $1_SRCS, $$($1_FILELIST))) > 455: $$(eval $1_MODFILES := $$?) I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From mcimadamore at openjdk.org Mon Sep 5 15:10:45 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Sep 2022 15:10:45 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero wrote: >> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing? >> >> TIA >> >> [1] https://github.com/openjdk/jdk/pull/10074 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing additional test Great cleanup - few test changes were not 100% clear to me, probably I'm missing some context. test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java line 31: > 29: public interface HiddenInterface { > 30: default void test() { > 31: record R() {} surprised to see this change test/langtools/jdk/jshell/ToolEnablePreviewTest.java line 76: > 74: public void testCompilerTestFlagEnv() { > 75: test(new String[] {"-C", "-XDforcePreview"}, > 76: (a) -> assertCommandOutputContains(a, "Function f = (var i) -> i + i", surprised to see these changes ------------- PR: https://git.openjdk.org/jdk/pull/10150 From jlahoda at openjdk.org Mon Sep 5 16:22:59 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 5 Sep 2022 16:22:59 GMT Subject: RFR: 8293348: A false cyclic inheritance error reported Message-ID: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com> Consider these two classes: non-sealed interface T2 extends T {} sealed interface T permits T2 {} With a bit non-standard set-up, it may happen that: - as part of `TypeEnter.HierarchyPhase`, `Check.checkNonCyclicInternal` is called for `T2`, - that will mark T2 as LOCKED, and call `checkNonCyclicInternal` for its supertype `T`, which is uncompleted, - `T` will be completed, so `TypeEnter.HierarchyPhase` will be called for it, - `TypeEnter.HierarchyPhase` for `T` will try to attribute the permitted types of `T`, - that will invoke `Check.checkNonCyclicInternal` for `T2` again, - but the class is already locked, and hence a cycle error is produced. The proposed solution is to defer permitted type handling to a later point in time, specifically to the `HeaderPhase`. The `HierarchyPhase` should only handle the type hierarchy (i.e. the supertypes of a given type), and should not handle cycles. Hence the `HeaderPhase` seems like a better place to handle the permitted types, similarly to type variable bounds handling. Setting `isPermittedExplicit` is moved to `Enter` - seems the value of the flag can be inferred easily from the AST node, and can simply be used later. ------------- Commit messages: - 8293348: A false cyclic inheritance error reported Changes: https://git.openjdk.org/jdk/pull/10171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293348 Stats: 110 lines in 3 files changed: 64 ins; 44 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10171.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10171/head:pull/10171 PR: https://git.openjdk.org/jdk/pull/10171 From jlahoda at openjdk.org Mon Sep 5 16:36:42 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 5 Sep 2022 16:36:42 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 12:19:38 GMT, Magnus Ihse Bursie wrote: > I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't. Hm, but `$$($1_SRCS)` contains all the source files of the given module, modified and unmodified, correct? The point of this patch is that we send the list of modified files to the `Depend` plugin (all sources are still passed to the javac invocation), and the plugin decides whether or not all files should be compiled, or only the modified files should be compiled. The plugin could theoretically do the timestamp check from the sources, but it is more difficult to do, and the make has (presumably) already done that in a predictable way. The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources. Note that the modfiles are not sent to javac as such - all sources are still sent to javac. The modfiles are sent to the `Depend` plugin using a side channel. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From vromero at openjdk.org Mon Sep 5 18:22:36 2022 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 5 Sep 2022 18:22:36 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com> On Mon, 5 Sep 2022 15:04:30 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing additional test > > test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java line 31: > >> 29: public interface HiddenInterface { >> 30: default void test() { >> 31: record R() {} > > surprised to see this change this is was done because test: `test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java` is compiling this code with options `--enable-preview -source [latestSource] -XDforcePreview` and then checking that the obtained class file has 65535 as its minor version. This was working so far as `DEFAULT_METHODS` was one member of `com.sun.tools.javac.code.Source.Feature` but as this PR is removing `DEFAULT_METHODS` we are obtaining the same effect defining a record as `RECORDS` are still defined in `com.sun.tools.javac.code.Source.Feature` > test/langtools/jdk/jshell/ToolEnablePreviewTest.java line 76: > >> 74: public void testCompilerTestFlagEnv() { >> 75: test(new String[] {"-C", "-XDforcePreview"}, >> 76: (a) -> assertCommandOutputContains(a, "Function f = (var i) -> i + i", > > surprised to see these changes similar as comment before `LAMBDA` is being removed but `VAR_SYNTAX_IMPLICIT_LAMBDAS` is still there ------------- PR: https://git.openjdk.org/jdk/pull/10150 From ihse at openjdk.org Mon Sep 5 19:03:43 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Sep 2022 19:03:43 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 18:35:24 GMT, Jan Lahoda 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 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10104 From ihse at openjdk.org Mon Sep 5 19:03:44 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Sep 2022 19:03:44 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 16:33:08 GMT, Jan Lahoda wrote: >> make/common/JavaCompilation.gmk line 455: >> >>> 453: $$(call LogWarn, Compiling up to $$(words $$($1_SRCS)) files for $1) >>> 454: $$(eval $$(call ListPathsSafely, $1_SRCS, $$($1_FILELIST))) >>> 455: $$(eval $1_MODFILES := $$?) >> >> I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't. > >> I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't. > > Hm, but `$$($1_SRCS)` contains all the source files of the given module, modified and unmodified, correct? The point of this patch is that we send the list of modified files to the `Depend` plugin (all sources are still passed to the javac invocation), and the plugin decides whether or not all files should be compiled, or only the modified files should be compiled. > > The plugin could theoretically do the timestamp check from the sources, but it is more difficult to do, and the make has (presumably) already done that in a predictable way. > > The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources. > > Note that the modfiles are not sent to javac as such - all sources are still sent to javac. The modfiles are sent to the `Depend` plugin using a side channel. Right, I confused `$?` and `$+`. You are of course correct, this is the way to get the changed targets. I had a bit of bad luck when I though about this. ? (Theoretically, we could filter out anything that is not in `$1_SRCS` from `$?` but that seems to more work than is reasonable.) ------------- PR: https://git.openjdk.org/jdk/pull/10104 From jlahoda at openjdk.org Tue Sep 6 09:31:51 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 6 Sep 2022 09:31:51 GMT Subject: Integrated: 8290561: Coalesce incubator-module warnings for single-file source-code programs In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 06:58:03 GMT, Jan Lahoda wrote: > Consider a trivial code like: > > public class Main { > public static void main(String... args) {} > } > > > And an execution like: > > $ java --add-modules jdk.incubator.concurrent Main.java > WARNING: Using incubator modules: jdk.incubator.concurrent > warning: using incubating module(s): jdk.incubator.concurrent > 1 warning > > > Having two warnings (one from runtime, one from javac) seems unnecessary. The patch proposed herein tries to avoid the javac warning, keeping only the runtime one. The conditions under which an incubator module is ignored w.r.t. this warning are: > > * the boot Module layer has the module (hence, presumably, the runtime already provided the warning) > * the javac run is (likely) from the source launcher. This is being done using a custom javac option, `-XDsourceLauncher` (which can possibly be used in other cases). > > This is to avoid cases where we would incorrectly suppress the incubator warning, e.g. when `-XDsourceLauncher` would be passed on the command line. > > There are other ways to attempt to detect javac invocations from the source launcher - a distinct file manager is used by the source launcher (but detection of the specific file manager does not feel in line with general javac approach); or use of the `jdk.internal.javac.source` system property set by the native launcher (but this is only set when `--source` option is used, as far as I know, and javac also typically does not check system properties). > > Note that there is JDK-8290563 to improve the text of the javac warning. This pull request has now been integrated. Changeset: 26f2a978 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/26f2a978f6c601e677a236054be4ddc39d9b6e55 Stats: 102 lines in 3 files changed: 100 ins; 0 del; 2 mod 8290561: Coalesce incubator-module warnings for single-file source-code programs Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/9607 From asotona at openjdk.org Tue Sep 6 12:25:24 2022 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 6 Sep 2022 12:25:24 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v15] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module - Added man-page line about lossy-conversion lint - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio - Merge branch 'openjdk:master' into JDK-8244681 - ... and 9 more: https://git.openjdk.org/jdk/compare/6a1e98cb...4a7ce942 ------------- Changes: https://git.openjdk.org/jdk/pull/8599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=14 Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.org/jdk/pull/8599 From erikj at openjdk.org Tue Sep 6 13:21:58 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 6 Sep 2022 13:21:58 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 19:00:56 GMT, Magnus Ihse Bursie wrote: >>> I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't. >> >> Hm, but `$$($1_SRCS)` contains all the source files of the given module, modified and unmodified, correct? The point of this patch is that we send the list of modified files to the `Depend` plugin (all sources are still passed to the javac invocation), and the plugin decides whether or not all files should be compiled, or only the modified files should be compiled. >> >> The plugin could theoretically do the timestamp check from the sources, but it is more difficult to do, and the make has (presumably) already done that in a predictable way. >> >> The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources. >> >> Note that the modfiles are not sent to javac as such - all sources are still sent to javac. The modfiles are sent to the `Depend` plugin using a side channel. > > Right, I confused `$?` and `$+`. You are of course correct, this is the way to get the changed targets. I had a bit of bad luck when I though about this. ? (Theoretically, we could filter out anything that is not in `$1_SRCS` from `$?` but that seems to more work than is reasonable.) > The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources. Ah, I had missed that and that's clever! That also means there is a reason to generate MODFILES in the actual compile recipe instead of the separate rule as I suggested earlier. For this to be "safe" we need `$$?` to really contain all the updated prereqs, otherwise we may miss compiling everything when something external actually should make us do just that. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From ihse at openjdk.org Tue Sep 6 14:36:47 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Sep 2022 14:36:47 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: Message-ID: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com> On Tue, 6 Sep 2022 13:19:48 GMT, Erik Joelsson wrote: >> Right, I confused `$?` and `$+`. You are of course correct, this is the way to get the changed targets. I had a bit of bad luck when I though about this. ? (Theoretically, we could filter out anything that is not in `$1_SRCS` from `$?` but that seems to more work than is reasonable.) > >> The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources. > > Ah, I had missed that and that's clever! That also means there is a reason to generate MODFILES in the actual compile recipe instead of the separate rule as I suggested earlier. For this to be "safe" we need `$$?` to really contain all the updated prereqs, otherwise we may miss compiling everything when something external actually should make us do just that. ... and also that we *must* include the vardeps file, since any change there should trigger a complete rebuild. The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing? ------------- PR: https://git.openjdk.org/jdk/pull/10104 From jlahoda at openjdk.org Wed Sep 7 14:01:05 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 7 Sep 2022 14:01:05 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v4] In-Reply-To: References: Message-ID: <3Ql6LJMb5h5W9Cgu2zN7P1Vs1uxgw2wZ2YiLUXb1YME=.77a52ef2-ba28-401b-b672-8d0830e4246e@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 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adding comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10104/files - new: https://git.openjdk.org/jdk/pull/10104/files/23e3b756..6c1a83b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=02-03 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 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 jlahoda at openjdk.org Wed Sep 7 14:01:05 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 7 Sep 2022 14:01:05 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com> References: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com> Message-ID: <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com> On Tue, 6 Sep 2022 14:33:10 GMT, Magnus Ihse Bursie wrote: >>> The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources. >> >> Ah, I had missed that and that's clever! That also means there is a reason to generate MODFILES in the actual compile recipe instead of the separate rule as I suggested earlier. For this to be "safe" we need `$$?` to really contain all the updated prereqs, otherwise we may miss compiling everything when something external actually should make us do just that. > > ... and also that we *must* include the vardeps file, since any change there should trigger a complete rebuild. > > The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing? > ... and also that we _must_ include the vardeps file, since any change there should trigger a complete rebuild. > > The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing? How about: https://github.com/openjdk/jdk/pull/10104/commits/6c1a83b28ee72a99bf24e7f66c96d1294ad485dd Thanks, Jan ------------- PR: https://git.openjdk.org/jdk/pull/10104 From cstein at openjdk.org Wed Sep 7 15:17:53 2022 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 Sep 2022 15:17:53 GMT Subject: Integrated: JDK-8289798: Update to use jtreg 7 In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein 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. This pull request has now been integrated. Changeset: 1ee59adc Author: Christian Stein Committer: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/1ee59adcfead2128316556121c1711d308c7ea01 Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod 8289798: Update to use jtreg 7 Reviewed-by: ihse, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9393 From erikj at openjdk.org Wed Sep 7 16:34:41 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 Sep 2022 16:34:41 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com> References: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com> <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com> Message-ID: On Wed, 7 Sep 2022 13:57:45 GMT, Jan Lahoda wrote: >> ... and also that we *must* include the vardeps file, since any change there should trigger a complete rebuild. >> >> The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing? > >> ... and also that we _must_ include the vardeps file, since any change there should trigger a complete rebuild. >> >> The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing? > > How about: > https://github.com/openjdk/jdk/pull/10104/commits/6c1a83b28ee72a99bf24e7f66c96d1294ad485dd > > Thanks, > Jan To clarify my last post. The Main compile rule has this prereq declaration: $$($1_COMPILE_TARGET): $$($1_SRCS) $$($1_FILELIST) $$($1_DEPENDS) \ $$($1_VARDEPS_FILE) $$($1_EXTRA_DEPS) $$($1_JAVAC_SERVER_CONFIG) The `$$($1_DEPENDS)` and `$$($1_EXTRA_DEPS)` may contain prereqs/dependencies that we probably should always recompile everything for. The EXTRA_DEPS is where we get the API changes from other modules. The DEPENDS variable is set by the caller and can be anything. Both of these are (deliberately) missing from the FILELIST generation rule, but I think MODFILES generation needs them. Because of this, I think the new MODFILES logic needs to move to the main compilation rule (like in your original patch) but the FILELIST rule should still be left alone. We need to verify that this still gives us the expected speedup in the common case though. I'm not sure in what situations other dependencies may be included in `$?` here. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From vromero at openjdk.org Wed Sep 7 18:25:45 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Sep 2022 18:25:45 GMT Subject: RFR: 8293348: A false cyclic inheritance error reported In-Reply-To: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com> References: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com> Message-ID: <_WV9pihNcGLyTCGDd-iKbV7MdXGfKUObEOl_YTnsHM0=.56169e84-37da-47cf-9374-240710eba9f5@github.com> On Mon, 5 Sep 2022 16:10:54 GMT, Jan Lahoda wrote: > Consider these two classes: > > non-sealed interface T2 extends T {} > sealed interface T permits T2 {} > > > With a bit non-standard set-up, it may happen that: > - as part of `TypeEnter.HierarchyPhase`, `Check.checkNonCyclicInternal` is called for `T2`, > - that will mark T2 as LOCKED, and call `checkNonCyclicInternal` for its supertype `T`, which is uncompleted, > - `T` will be completed, so `TypeEnter.HierarchyPhase` will be called for it, > - `TypeEnter.HierarchyPhase` for `T` will try to attribute the permitted types of `T`, > - that will invoke `Check.checkNonCyclicInternal` for `T2` again, > - but the class is already locked, and hence a cycle error is produced. > > The proposed solution is to defer permitted type handling to a later point in time, specifically to the `HeaderPhase`. The `HierarchyPhase` should only handle the type hierarchy (i.e. the supertypes of a given type), and should not handle cycles. Hence the `HeaderPhase` seems like a better place to handle the permitted types, similarly to type variable bounds handling. > > Setting `isPermittedExplicit` is moved to `Enter` - seems the value of the flag can be inferred easily from the AST node, and can simply be used later. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10171 From dcubed at openjdk.org Wed Sep 7 18:33:48 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Sep 2022 18:33:48 GMT Subject: RFR: 8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java - launch timeout In-Reply-To: References: Message-ID: <5xzd8QAs_3F876p7P8wYCFRmcN1_3PHE5imqj0u4df0=.a97d2a13-3edd-4b61-81ad-1e552cb15601@github.com> On Fri, 26 Aug 2022 19:30:02 GMT, Daniel D. Daugherty wrote: > A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor. > Also cleaned up an incorrect comment. Used the latest patch in my jdk-20+13 stress runs on linux-x64 and macosx-aarch64 and there were no failures. ------------- PR: https://git.openjdk.org/jdk/pull/10049 From dcubed at openjdk.org Wed Sep 7 18:33:49 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Sep 2022 18:33:49 GMT Subject: Integrated: 8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java - launch timeout In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 19:30:02 GMT, Daniel D. Daugherty wrote: > A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor. > Also cleaned up an incorrect comment. This pull request has now been integrated. Changeset: 02dce24b Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/02dce24b59ab53f00309a71ee94f45067c880b5c Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod 8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java - launch timeout Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10049 From ihse at openjdk.org Thu Sep 8 09:43:44 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Sep 2022 09:43:44 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com> <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com> Message-ID: On Wed, 7 Sep 2022 16:30:33 GMT, Erik Joelsson wrote: >>> ... and also that we _must_ include the vardeps file, since any change there should trigger a complete rebuild. >>> >>> The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing? >> >> How about: >> https://github.com/openjdk/jdk/pull/10104/commits/6c1a83b28ee72a99bf24e7f66c96d1294ad485dd >> >> Thanks, >> Jan > > To clarify my last post. The Main compile rule has this prereq declaration: > > > $$($1_COMPILE_TARGET): $$($1_SRCS) $$($1_FILELIST) $$($1_DEPENDS) \ > $$($1_VARDEPS_FILE) $$($1_EXTRA_DEPS) $$($1_JAVAC_SERVER_CONFIG) > > The `$$($1_DEPENDS)` and `$$($1_EXTRA_DEPS)` may contain prereqs/dependencies that we probably should always recompile everything for. The EXTRA_DEPS is where we get the API changes from other modules. The DEPENDS variable is set by the caller and can be anything. Both of these are (deliberately) missing from the FILELIST generation rule, but I think MODFILES generation needs them. Because of this, I think the new MODFILES logic needs to move to the main compilation rule (like in your original patch) but the FILELIST rule should still be left alone. > > We need to verify that this still gives us the expected speedup in the common case though. I'm not sure in what situations other dependencies may be included in `$?` here. Actually, this is not an entirely correct description. EXTRA_DEPS points to the `depend` javac plugin itself in buildtools. Once built, this is unlikely to change. Dependency on the API changes themselves happen on a higher level, in `CompileJavaModules.gmk`, where we add a dependency of the outputted `pubapi` file for modules we depend on. (I did have to look this up, though) ------------- PR: https://git.openjdk.org/jdk/pull/10104 From ihse at openjdk.org Thu Sep 8 09:48:41 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Sep 2022 09:48:41 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com> <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com> Message-ID: On Thu, 8 Sep 2022 09:40:13 GMT, Magnus Ihse Bursie wrote: >> To clarify my last post. The Main compile rule has this prereq declaration: >> >> >> $$($1_COMPILE_TARGET): $$($1_SRCS) $$($1_FILELIST) $$($1_DEPENDS) \ >> $$($1_VARDEPS_FILE) $$($1_EXTRA_DEPS) $$($1_JAVAC_SERVER_CONFIG) >> >> The `$$($1_DEPENDS)` and `$$($1_EXTRA_DEPS)` may contain prereqs/dependencies that we probably should always recompile everything for. The EXTRA_DEPS is where we get the API changes from other modules. The DEPENDS variable is set by the caller and can be anything. Both of these are (deliberately) missing from the FILELIST generation rule, but I think MODFILES generation needs them. Because of this, I think the new MODFILES logic needs to move to the main compilation rule (like in your original patch) but the FILELIST rule should still be left alone. >> >> We need to verify that this still gives us the expected speedup in the common case though. I'm not sure in what situations other dependencies may be included in `$?` here. > > Actually, this is not an entirely correct description. EXTRA_DEPS points to the `depend` javac plugin itself in buildtools. Once built, this is unlikely to change. Dependency on the API changes themselves happen on a higher level, in `CompileJavaModules.gmk`, where we add a dependency of the outputted `pubapi` file for modules we depend on. > > (I did have to look this up, though) I looked up what kind of dependencies we are passing in through `DEPEND`. None, it turns out. It is not used. So that is not a worry. We might consider removing it. Sending in exceptional dependencies like that is never a good design decision. If it ever happens again that this would be the only acceptable solution, we can re-add the `DEPEND` argument. But that basically mean that Jan's patch might be okay, after all. `DEPENDS` does not exist, and I want to remove it. `EXTRA_DEPS` is only modified if we change the `depend` javac plugin. I am willing to sacrifice automatic recompilation of all Java classes if that is changed. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From mcimadamore at openjdk.org Thu Sep 8 13:04:48 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Sep 2022 13:04:48 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero wrote: >> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing? >> >> TIA >> >> [1] https://github.com/openjdk/jdk/pull/10074 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing additional test Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10150 From mcimadamore at openjdk.org Thu Sep 8 13:04:49 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Sep 2022 13:04:49 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com> References: <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com> Message-ID: On Mon, 5 Sep 2022 18:19:35 GMT, Vicente Romero wrote: >> test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java line 31: >> >>> 29: public interface HiddenInterface { >>> 30: default void test() { >>> 31: record R() {} >> >> surprised to see this change > > this is was done because test: `test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java` is compiling this code with options `--enable-preview -source [latestSource] -XDforcePreview` and then checking that the obtained class file has 65535 as its minor version. This was working so far as `DEFAULT_METHODS` was one member of `com.sun.tools.javac.code.Source.Feature` but as this PR is removing `DEFAULT_METHODS` we are obtaining the same effect defining a record as `RECORDS` are still defined in `com.sun.tools.javac.code.Source.Feature` I see. I understand what the fix does then. I wonder if, moving forward, it wouldn't be better to tweak the semantics of forcePreview so that it always pollutes the classfile not matter what (which seems to be what some of the tests want). Otherwise we're stuck with these fragile tricks of using this or that feature to force javac's preview system into submission. ------------- PR: https://git.openjdk.org/jdk/pull/10150 From erikj at openjdk.org Thu Sep 8 13:58:51 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 8 Sep 2022 13:58:51 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: References: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com> <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com> Message-ID: <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com> On Thu, 8 Sep 2022 09:45:03 GMT, Magnus Ihse Bursie wrote: >> Actually, this is not an entirely correct description. EXTRA_DEPS points to the `depend` javac plugin itself in buildtools. Once built, this is unlikely to change. Dependency on the API changes themselves happen on a higher level, in `CompileJavaModules.gmk`, where we add a dependency of the outputted `pubapi` file for modules we depend on. >> >> (I did have to look this up, though) > > I looked up what kind of dependencies we are passing in through `DEPEND`. None, it turns out. It is not used. So that is not a worry. We might consider removing it. Sending in exceptional dependencies like that is never a good design decision. If it ever happens again that this would be the only acceptable solution, we can re-add the `DEPEND` argument. > > But that basically mean that Jan's patch might be okay, after all. `DEPENDS` does not exist, and I want to remove it. `EXTRA_DEPS` is only modified if we change the `depend` javac plugin. I am willing to sacrifice automatic recompilation of all Java classes if that is changed. Ok I was wrong about what EXTRA_DEPS was used for, I read the code too hastily. However, the dependency declaration for the pubapi files from other modules is added in make/CompileJavaModules.gmk like this: $($(MODULE)_COMPILE_TARGET): $(foreach d, $(call FindDepsForModule, $(MODULE)), \ $(call SetupJavaCompilationApiTarget, $d, \ $(if $($d_BIN), $($d_BIN), $(JDK_OUTPUTDIR)/modules/$d))) So this still doesn't change my main point. The pubapi files only appear on the dependency declaration for `$($(MODULE)_COMPILE_TARGET)`. This means that with the current patch, we will not recompile the full module when a parent module has a change to the pubapi. The Depend plugin needs to see the pubapi files in `$$?` for that to happen. One could also make the case for using DEPEND when adding such a dependency instead of referencing `$($(MODULE)_COMPILE_TARGET)` in explicit rules. It would be more inline with more recent design patterns. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From jlahoda at openjdk.org Thu Sep 8 14:14:28 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 8 Sep 2022 14:14:28 GMT Subject: Integrated: 8293348: A false cyclic inheritance error reported In-Reply-To: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com> References: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com> Message-ID: On Mon, 5 Sep 2022 16:10:54 GMT, Jan Lahoda wrote: > Consider these two classes: > > non-sealed interface T2 extends T {} > sealed interface T permits T2 {} > > > With a bit non-standard set-up, it may happen that: > - as part of `TypeEnter.HierarchyPhase`, `Check.checkNonCyclicInternal` is called for `T2`, > - that will mark T2 as LOCKED, and call `checkNonCyclicInternal` for its supertype `T`, which is uncompleted, > - `T` will be completed, so `TypeEnter.HierarchyPhase` will be called for it, > - `TypeEnter.HierarchyPhase` for `T` will try to attribute the permitted types of `T`, > - that will invoke `Check.checkNonCyclicInternal` for `T2` again, > - but the class is already locked, and hence a cycle error is produced. > > The proposed solution is to defer permitted type handling to a later point in time, specifically to the `HeaderPhase`. The `HierarchyPhase` should only handle the type hierarchy (i.e. the supertypes of a given type), and should not handle cycles. Hence the `HeaderPhase` seems like a better place to handle the permitted types, similarly to type variable bounds handling. > > Setting `isPermittedExplicit` is moved to `Enter` - seems the value of the flag can be inferred easily from the AST node, and can simply be used later. This pull request has now been integrated. Changeset: c0ee30a2 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/c0ee30a25abda2f93806bbfaf940ba8638b864bf Stats: 110 lines in 3 files changed: 64 ins; 44 del; 2 mod 8293348: A false cyclic inheritance error reported Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10171 From vromero at openjdk.org Thu Sep 8 14:24:52 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 8 Sep 2022 14:24:52 GMT Subject: RFR: 8293051: Further refactor javac after removal of -source/-target/--release 7 [v2] In-Reply-To: References: <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com> Message-ID: On Thu, 8 Sep 2022 13:02:29 GMT, Maurizio Cimadamore wrote: >> this is was done because test: `test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java` is compiling this code with options `--enable-preview -source [latestSource] -XDforcePreview` and then checking that the obtained class file has 65535 as its minor version. This was working so far as `DEFAULT_METHODS` was one member of `com.sun.tools.javac.code.Source.Feature` but as this PR is removing `DEFAULT_METHODS` we are obtaining the same effect defining a record as `RECORDS` are still defined in `com.sun.tools.javac.code.Source.Feature` > > I see. I understand what the fix does then. > I wonder if, moving forward, it wouldn't be better to tweak the semantics of forcePreview so that it always pollutes the classfile not matter what (which seems to be what some of the tests want). Otherwise we're stuck with these fragile tricks of using this or that feature to force javac's preview system into submission. yes that would be a sensible change going forward. Thanks for the review ------------- PR: https://git.openjdk.org/jdk/pull/10150 From vromero at openjdk.org Thu Sep 8 14:39:05 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 8 Sep 2022 14:39:05 GMT Subject: Integrated: 8293051: Further refactor javac after removal of -source/-target/--release 7 In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 21:11:27 GMT, Vicente Romero wrote: > This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing? > > TIA > > [1] https://github.com/openjdk/jdk/pull/10074 This pull request has now been integrated. Changeset: 46e6e41b Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/46e6e41b9a35c8665eb31be2f8c36bbdcc90564a Stats: 256 lines in 22 files changed: 11 ins; 198 del; 47 mod 8293051: Further refactor javac after removal of -source/-target/--release 7 Reviewed-by: darcy, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/10150 From jlahoda at openjdk.org Thu Sep 8 16:54:16 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 8 Sep 2022 16:54:16 GMT Subject: RFR: 8292755: Non-default method in interface leads to a stack overflow in JShell Message-ID: Consider this snippet sent to JShell: interface I { void test() { try { } catch (IllegalStateException ex) { throw new RuntimeException(ex); } } } This leads to a crash: Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415) at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.(TaskFactory.java:406) at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178) at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213) at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193) at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206) at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175) at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161) at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060) at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893) at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140) at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000) at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383) at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412) ... 18 more Caused by: java.lang.StackOverflowError at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) ... The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions. The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body. ------------- Commit messages: - 8292755: Non-default method in interface leads to a stack overflow in JShell Changes: https://git.openjdk.org/jdk/pull/10221/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10221&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292755 Stats: 194 lines in 3 files changed: 185 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10221.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10221/head:pull/10221 PR: https://git.openjdk.org/jdk/pull/10221 From jlahoda at openjdk.org Fri Sep 9 11:41:08 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 9 Sep 2022 11:41:08 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v5] In-Reply-To: References: Message-ID: > 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 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Regenerating modfiles as necessary. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10104/files - new: https://git.openjdk.org/jdk/pull/10104/files/6c1a83b2..c3455660 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=03-04 Stats: 26 lines in 2 files changed: 14 ins; 9 del; 3 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 jlahoda at openjdk.org Fri Sep 9 11:41:08 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 9 Sep 2022 11:41:08 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com> References: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com> <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com> <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com> Message-ID: On Thu, 8 Sep 2022 13:54:02 GMT, Erik Joelsson wrote: >> I looked up what kind of dependencies we are passing in through `DEPEND`. None, it turns out. It is not used. So that is not a worry. We might consider removing it. Sending in exceptional dependencies like that is never a good design decision. If it ever happens again that this would be the only acceptable solution, we can re-add the `DEPEND` argument. >> >> But that basically mean that Jan's patch might be okay, after all. `DEPENDS` does not exist, and I want to remove it. `EXTRA_DEPS` is only modified if we change the `depend` javac plugin. I am willing to sacrifice automatic recompilation of all Java classes if that is changed. > > Ok I was wrong about what EXTRA_DEPS was used for, I read the code too hastily. However, the dependency declaration for the pubapi files from other modules is added in make/CompileJavaModules.gmk like this: > > > $($(MODULE)_COMPILE_TARGET): $(foreach d, $(call FindDepsForModule, $(MODULE)), \ > $(call SetupJavaCompilationApiTarget, $d, \ > $(if $($d_BIN), $($d_BIN), $(JDK_OUTPUTDIR)/modules/$d))) > > > So this still doesn't change my main point. The pubapi files only appear on the dependency declaration for `$($(MODULE)_COMPILE_TARGET)`. This means that with the current patch, we will not recompile the full module when a parent module has a change to the pubapi. The Depend plugin needs to see the pubapi files in `$$?` for that to happen. > > One could also make the case for using DEPEND when adding such a dependency instead of referencing `$($(MODULE)_COMPILE_TARGET)` in explicit rules. It would be more inline with more recent design patterns. Hmm, how about this? https://github.com/openjdk/jdk/pull/10104/commits/c3455660310bea8a33b1b5b5cb05c792f5d825a2 that seems to work (hopefully), although I am not sure if that is not breaking some overall concept in the build. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From ihse at openjdk.org Fri Sep 9 11:54:59 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 Sep 2022 11:54:59 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda 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 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Regenerating modfiles as necessary. I think this looks good now. But this is apparently tricky business, with the three of us taking turns of thinking wrongly about this. :-) Let's hear what Erik has to say, too. Have you verified that it still does the correct things in cases like: 1) only non-visible changes in individual files 2) visible-changes in individual files 3) changes in a dependent module 4) changes in javac setup, like an added Xlint option 5) and some combinations, where I think 1+3 is most relevant ? ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/jdk/pull/10104 From ihse at openjdk.org Fri Sep 9 11:57:24 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 Sep 2022 11:57:24 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v3] In-Reply-To: <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com> References: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com> <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com> <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com> Message-ID: On Thu, 8 Sep 2022 13:54:02 GMT, Erik Joelsson wrote: >> I looked up what kind of dependencies we are passing in through `DEPEND`. None, it turns out. It is not used. So that is not a worry. We might consider removing it. Sending in exceptional dependencies like that is never a good design decision. If it ever happens again that this would be the only acceptable solution, we can re-add the `DEPEND` argument. >> >> But that basically mean that Jan's patch might be okay, after all. `DEPENDS` does not exist, and I want to remove it. `EXTRA_DEPS` is only modified if we change the `depend` javac plugin. I am willing to sacrifice automatic recompilation of all Java classes if that is changed. > > Ok I was wrong about what EXTRA_DEPS was used for, I read the code too hastily. However, the dependency declaration for the pubapi files from other modules is added in make/CompileJavaModules.gmk like this: > > > $($(MODULE)_COMPILE_TARGET): $(foreach d, $(call FindDepsForModule, $(MODULE)), \ > $(call SetupJavaCompilationApiTarget, $d, \ > $(if $($d_BIN), $($d_BIN), $(JDK_OUTPUTDIR)/modules/$d))) > > > So this still doesn't change my main point. The pubapi files only appear on the dependency declaration for `$($(MODULE)_COMPILE_TARGET)`. This means that with the current patch, we will not recompile the full module when a parent module has a change to the pubapi. The Depend plugin needs to see the pubapi files in `$$?` for that to happen. > > One could also make the case for using DEPEND when adding such a dependency instead of referencing `$($(MODULE)_COMPILE_TARGET)` in explicit rules. It would be more inline with more recent design patterns. @erikj79 I agree that setting DEPEND would be better. I hate those weird "injection attacks" where we fake arguments to functions, they make the code hopeless to understand (and I'd like to forbid them in `NamedParamsMacroTemplate`, but I can't just now since we still use it in so many places). But can we really do that? I don't think we have that dependency information available when setting up the module java compilation. (In any case, that is a separate cleanup) ------------- PR: https://git.openjdk.org/jdk/pull/10104 From erikj at openjdk.org Fri Sep 9 12:54:58 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Sep 2022 12:54:58 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v5] In-Reply-To: References: Message-ID: <2klNmfZaHNi5XGjGR5tMYM2IQK7QjCNxDve9TkH28JE=.3348ee36-5172-4b7e-8a6d-57a146f76039@github.com> On Fri, 9 Sep 2022 11:51:55 GMT, Magnus Ihse Bursie wrote: > I think this looks good now. But this is apparently tricky business, with the three of us taking turns of thinking wrongly about this. :-) Let's hear what Erik has to say, too. > > Have you verified that it still does the correct things in cases like: > > 1. only non-visible changes in individual files > 2. visible-changes in individual files > 3. changes in a dependent module > 4. changes in javac setup, like an added Xlint option > 5. and some combinations, where I think 1+3 is most relevant > > ? This is indeed tricky business, and I thank you for hanging in there while we figure it out. It's certainly much better to discover and rethink at the review stage than in followup bugs. I think this solution is good, pending confirmation that you tried all the cases Magnus listed. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From erikj at openjdk.org Fri Sep 9 12:54:59 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Sep 2022 12:54:59 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda 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 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Regenerating modfiles as necessary. make/common/JavaCompilation.gmk line 466: > 464: # it will be considered to be a significant change, and all module source will > 465: # be recompiled > 466: $$($1_MODFILELIST): $$($1_SRCS) $$($1_DEPENDS) \ Looks like an extra space snuck in, otherwise this seems good. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From abimpoudis at openjdk.org Fri Sep 9 15:11:14 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 9 Sep 2022 15:11:14 GMT Subject: RFR: 8291657: Javac assertion when compiling a method call with switch expression as argument Message-ID: The following crashes on `Gen` when emitting code at `visitYield`. return (B) switch (o) { default -> new A(); }; Why? Because the `yield` is retyped in `TransTypes` to `(B) new A()` and during `visitYield` in `Gen.java`, there is a check that essentially says: check the last type and assert if its a super-type of the current type. That retype in `TransTypes` is exercised in one test regarding intersection types. Now, if I write a redundant cast: return (B) (A) switch (o) { default -> new A(); }; it works. because the `Yield` is not retyped. This PR translates the cases with the correct prototype (of the type of the switch itself -- `A` in the aforementioned examples). WDYT? ------------- Commit messages: - 8291657: Javac assertion when compiling a method call with switch expression as argument Changes: https://git.openjdk.org/jdk/pull/10232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10232&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291657 Stats: 46 lines in 2 files changed: 45 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10232.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10232/head:pull/10232 PR: https://git.openjdk.org/jdk/pull/10232 From vromero at openjdk.org Mon Sep 12 15:17:50 2022 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Sep 2022 15:17:50 GMT Subject: RFR: 8292755: Non-default method in interface leads to a stack overflow in JShell In-Reply-To: References: Message-ID: <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com> On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda wrote: > Consider this snippet sent to JShell: > > interface I { > void test() { > try { > } catch (IllegalStateException ex) { > throw new RuntimeException(ex); > } > } > } > > > This leads to a crash: > > Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415) > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.(TaskFactory.java:406) > at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178) > at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213) > at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193) > at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206) > at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175) > at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161) > at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060) > at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893) > at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140) > at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383) > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412) > ... 18 more > Caused by: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > ... > > > The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions. > > The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body. question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output ------------- PR: https://git.openjdk.org/jdk/pull/10221 From jlahoda at openjdk.org Mon Sep 12 20:37:51 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 12 Sep 2022 20:37:51 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v5] In-Reply-To: References: Message-ID: <1_kz64sRf3r7tV6hbGwag-ytgM_HJJ0nZn1XFP5rFJE=.4a60b3c4-6f62-4a73-9793-cac777f4a2a9@github.com> On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda 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 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Regenerating modfiles as necessary. I ran some tests (in a semi-automated fashion), results seem reasonable: ## Non-API change in java.base: sed -e 's/^}//* */}/' src/java.base/share/classes/java/lang/Object.java time make result: Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' Compiling up to 3192 files for java.base [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: false, non-Java modified files: Stopping sjavac server Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' real 0m3,414s user 0m5,188s sys 0m1,328s ## Non-API change in java.compiler: sed -e 's/^}//* */}/' src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java time make result: Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' Compiling up to 127 files for BUILD_java.compiler.interim Compiling up to 127 files for java.compiler [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: false, non-Java modified files: Stopping sjavac server Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' real 0m15,530s user 0m22,948s sys 0m2,337s ## Package-private method added to java.base: sed -e 's/^}/static void testMethod() {} }/' src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java time make result: Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' Compiling up to 3192 files for java.base [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: Optimizing the exploded image Stopping sjavac server Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' real 0m30,190s user 0m6,852s sys 0m1,548s ## Package-private method added to java.compiler: sed -e 's/^}/static void testMethod() {} }/' src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java time make | tee -a test-output result: Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' Compiling up to 127 files for BUILD_java.compiler.interim Compiling up to 127 files for java.compiler [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: Optimizing the exploded image Stopping sjavac server Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' real 0m17,368s user 0m23,831s sys 0m2,328s ## Public method added to java.base: sed -e 's/^}//** test. */public static void testMethod() {} }/' src/java.base/share/classes/java/lang/Object.java time make result: Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' Compiling up to 3192 files for java.base [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: [stderr] compiling module: java.datatransfer, all Java inputs: 18, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.instrument, all Java inputs: 10, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.logging, all Java inputs: 35, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.scripting, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.net.http, all Java inputs: 142, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.management, all Java inputs: 330, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.transaction.xa, all Java inputs: 5, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.smartcardio, all Java inputs: 22, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.internal.jvmstat, all Java inputs: 61, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.zipfs, all Java inputs: 14, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.charsets, all Java inputs: 120, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.crypto.ec, all Java inputs: 35, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.xml, all Java inputs: 1848, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.internal.ed, all Java inputs: 3, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.dynalink, all Java inputs: 68, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.httpserver, all Java inputs: 60, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.incubator.concurrent, all Java inputs: 4, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.internal.opt, all Java inputs: 51, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.incubator.vector, all Java inputs: 50, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.internal.le, all Java inputs: 103, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jartool, all Java inputs: 31, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.internal.vm.ci, all Java inputs: 203, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.management, all Java inputs: 24, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jdwp.agent, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jfr, all Java inputs: 260, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jsobject, all Java inputs: 4, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.net, all Java inputs: 9, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.nio.mapmode, all Java inputs: 2, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.random, all Java inputs: 11, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.sctp, all Java inputs: 33, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.unsupported, all Java inputs: 9, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.security.sasl, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.rmi, all Java inputs: 106, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.attach, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.crypto.cryptoki, all Java inputs: 76, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.internal.vm.compiler, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.localedata, all Java inputs: 1838, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.internal.vm.compiler.management, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jcmd, all Java inputs: 40, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.compiler, all Java inputs: 413, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jstatd, all Java inputs: 11, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jdi, all Java inputs: 254, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.management.jfr, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.naming, all Java inputs: 198, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.naming.dns, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.naming.rmi, all Java inputs: 8, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.management.rmi, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.security.jgss, all Java inputs: 212, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.sql, all Java inputs: 77, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.prefs, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.xml.dom, all Java inputs: 94, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.xml.crypto, all Java inputs: 271, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.management.agent, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.sql.rowset, all Java inputs: 56, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.security.jgss, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.security.auth, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jdeps, all Java inputs: 139, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jshell, all Java inputs: 97, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.javadoc, all Java inputs: 243, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jlink, all Java inputs: 90, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.desktop, all Java inputs: 2769, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: java.se, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.unsupported.desktop, all Java inputs: 8, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.editpad, all Java inputs: 3, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.accessibility, all Java inputs: 18, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jconsole, all Java inputs: 64, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.jpackage, all Java inputs: 57, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi [stderr] compiling module: jdk.hotspot.agent, all Java inputs: 940, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi Optimizing the exploded image Stopping sjavac server Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' real 1m27,775s user 0m52,536s sys 0m7,856s ## Public method added to java.compiler: sed -e 's/^}//** test. */public static void testMethod() {} }/' src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java time make result: Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' Compiling up to 127 files for BUILD_java.compiler.interim Compiling up to 127 files for java.compiler [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: [stderr] compiling module: java.se, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi [stderr] compiling module: jdk.compiler, all Java inputs: 413, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi [stderr] compiling module: jdk.jdeps, all Java inputs: 139, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi [stderr] compiling module: jdk.jshell, all Java inputs: 97, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi [stderr] compiling module: jdk.javadoc, all Java inputs: 243, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi Optimizing the exploded image Stopping sjavac server Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' real 0m36,685s user 0m30,044s sys 0m3,273s ## Error in a newly added added public method to java.base: sed -e 's/^}/public static void testMethod() {} }/' src/java.base/share/classes/java/lang/Object.java time make git diff src/java.base/share/classes/java/lang/Object.java | patch -R -p1 sed -e 's/^}//** test. */public static void testMethod() {} }/' src/java.base/share/classes/java/lang/Object.java echo Fixed: time make result: Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' Compiling up to 3192 files for java.base [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: ------------- PR: https://git.openjdk.org/jdk/pull/10104 From erikj at openjdk.org Mon Sep 12 21:03:44 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 Sep 2022 21:03:44 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda 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 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Regenerating modfiles as necessary. This looks good to me now. Thank you for fixing this! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/10104 From jlahoda at openjdk.org Tue Sep 13 09:31:12 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 13 Sep 2022 09:31:12 GMT Subject: RFR: 8292755: Non-default method in interface leads to a stack overflow in JShell In-Reply-To: <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com> References: <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com> Message-ID: On Mon, 12 Sep 2022 15:15:24 GMT, Vicente Romero wrote: > question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output Yes, there may be some more error generated (if the body is erroneous), but I don't see it as a big problem: the errors are there, and when the user adds the `default` keyword (or removes a wrong keyword), the errors will show anyway. To me, it is not clear that a broken modifier is a problem big enough to stop attributing the body - there are many other problems that we find during the attribution of the method header that will not stop method body attribution. Like: $ cat Test.java public interface Test { default void test(Unknown1 t) { Unknown2 tt; } } $ javac Test.java Test.java:2: error: cannot find symbol default void test(Unknown1 t) { ^ symbol: class Unknown1 location: interface Test Test.java:3: error: cannot find symbol Unknown2 tt; ^ symbol: class Unknown2 location: interface Test 2 errors I am a bit worried that generating more stub data will lead only to a whack-a-mole trying to cover all corner cases where the stub data are not good enough, while simply letting the attribution proceed should cover the cases as it does for normal methods. ------------- PR: https://git.openjdk.org/jdk/pull/10221 From ihse at openjdk.org Tue Sep 13 11:23:47 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 13 Sep 2022 11:23:47 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v5] In-Reply-To: <1_kz64sRf3r7tV6hbGwag-ytgM_HJJ0nZn1XFP5rFJE=.4a60b3c4-6f62-4a73-9793-cac777f4a2a9@github.com> References: <1_kz64sRf3r7tV6hbGwag-ytgM_HJJ0nZn1XFP5rFJE=.4a60b3c4-6f62-4a73-9793-cac777f4a2a9@github.com> Message-ID: On Mon, 12 Sep 2022 20:35:27 GMT, Jan Lahoda wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Regenerating modfiles as necessary. > > I ran some tests (in a semi-automated fashion), results seem reasonable: > > ## Non-API change in java.base: > > sed -e 's/^}//* */}/' src/java.base/share/classes/java/lang/Object.java > time make > > > result: > > Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > Compiling up to 3192 files for java.base > [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: false, non-Java modified files: > Stopping sjavac server > Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > > real 0m3,414s > user 0m5,188s > sys 0m1,328s > > > ## Non-API change in java.compiler: > > sed -e 's/^}//* */}/' src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java > time make > > > result: > > Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > Compiling up to 127 files for BUILD_java.compiler.interim > Compiling up to 127 files for java.compiler > [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: false, non-Java modified files: > Stopping sjavac server > Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > > real 0m15,530s > user 0m22,948s > sys 0m2,337s > > > ## Package-private method added to java.base: > > sed -e 's/^}/static void testMethod() {} }/' src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java > time make > > > result: > > Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > Compiling up to 3192 files for java.base > [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: > Optimizing the exploded image > Stopping sjavac server > Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > > real 0m30,190s > user 0m6,852s > sys 0m1,548s > > > ## Package-private method added to java.compiler: > > sed -e 's/^}/static void testMethod() {} }/' src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java > time make | tee -a test-output > > > result: > > Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > Compiling up to 127 files for BUILD_java.compiler.interim > Compiling up to 127 files for java.compiler > [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: > Optimizing the exploded image > Stopping sjavac server > Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > > real 0m17,368s > user 0m23,831s > sys 0m2,328s > > > ## Public method added to java.base: > > > sed -e 's/^}//** test. */public static void testMethod() {} }/' src/java.base/share/classes/java/lang/Object.java > time make > > > result: > > Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > Compiling up to 3192 files for java.base > [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: > [stderr] compiling module: java.datatransfer, all Java inputs: 18, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.instrument, all Java inputs: 10, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.logging, all Java inputs: 35, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.scripting, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.net.http, all Java inputs: 142, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.management, all Java inputs: 330, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.transaction.xa, all Java inputs: 5, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.smartcardio, all Java inputs: 22, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.internal.jvmstat, all Java inputs: 61, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.zipfs, all Java inputs: 14, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.charsets, all Java inputs: 120, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.crypto.ec, all Java inputs: 35, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.xml, all Java inputs: 1848, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.internal.ed, all Java inputs: 3, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.dynalink, all Java inputs: 68, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.httpserver, all Java inputs: 60, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.incubator.concurrent, all Java inputs: 4, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.internal.opt, all Java inputs: 51, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.incubator.vector, all Java inputs: 50, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.internal.le, all Java inputs: 103, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jartool, all Java inputs: 31, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.internal.vm.ci, all Java inputs: 203, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.management, all Java inputs: 24, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jdwp.agent, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jfr, all Java inputs: 260, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jsobject, all Java inputs: 4, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.net, all Java inputs: 9, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.nio.mapmode, all Java inputs: 2, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.random, all Java inputs: 11, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.sctp, all Java inputs: 33, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.unsupported, all Java inputs: 9, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.security.sasl, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.rmi, all Java inputs: 106, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.attach, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.crypto.cryptoki, all Java inputs: 76, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.internal.vm.compiler, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.localedata, all Java inputs: 1838, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.internal.vm.compiler.management, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jcmd, all Java inputs: 40, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.compiler, all Java inputs: 413, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jstatd, all Java inputs: 11, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jdi, all Java inputs: 254, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.management.jfr, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.naming, all Java inputs: 198, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.naming.dns, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.naming.rmi, all Java inputs: 8, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.management.rmi, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.security.jgss, all Java inputs: 212, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.sql, all Java inputs: 77, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.prefs, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.xml.dom, all Java inputs: 94, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.xml.crypto, all Java inputs: 271, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.management.agent, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.sql.rowset, all Java inputs: 56, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.security.jgss, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.security.auth, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jdeps, all Java inputs: 139, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jshell, all Java inputs: 97, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.javadoc, all Java inputs: 243, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jlink, all Java inputs: 90, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.desktop, all Java inputs: 2769, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: java.se, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.unsupported.desktop, all Java inputs: 8, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.editpad, all Java inputs: 3, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.accessibility, all Java inputs: 18, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jconsole, all Java inputs: 64, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.jpackage, all Java inputs: 57, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > [stderr] compiling module: jdk.hotspot.agent, all Java inputs: 940, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi > Optimizing the exploded image > Stopping sjavac server > Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > > real 1m27,775s > user 0m52,536s > sys 0m7,856s > > > ## Public method added to java.compiler: > > > sed -e 's/^}//** test. */public static void testMethod() {} }/' src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java > time make > > > result: > > Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > Compiling up to 127 files for BUILD_java.compiler.interim > Compiling up to 127 files for java.compiler > [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: > [stderr] compiling module: java.se, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi > [stderr] compiling module: jdk.compiler, all Java inputs: 413, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi > [stderr] compiling module: jdk.jdeps, all Java inputs: 139, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi > [stderr] compiling module: jdk.jshell, all Java inputs: 97, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi > [stderr] compiling module: jdk.javadoc, all Java inputs: 243, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi > Optimizing the exploded image > Stopping sjavac server > Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > > real 0m36,685s > user 0m30,044s > sys 0m3,273s > > > ## Error in a newly added added public method to java.base: > > > sed -e 's/^}/public static void testMethod() {} }/' src/java.base/share/classes/java/lang/Object.java > time make > git diff src/java.base/share/classes/java/lang/Object.java | patch -R -p1 > sed -e 's/^}//** test. */public static void testMethod() {} }/' src/java.base/share/classes/java/lang/Object.java > echo Fixed: > time make > > > result: > > Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release' > Compiling up to 3192 files for java.base > [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: @lahodaj The `[stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: ` lines look very nice for debugging. How did you get these? Could you make it so that they are always turned on if `$LOG_LEVEL` is `DEBUG` or `TRACE`? Otherwise, I'm satisfied with your results. ------------- PR: https://git.openjdk.org/jdk/pull/10104 From jlahoda at openjdk.org Tue Sep 13 13:09:50 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 13 Sep 2022 13:09:50 GMT Subject: RFR: 8291657: Javac assertion when compiling a method call with switch expression as argument In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 15:04:13 GMT, Aggelos Biboudis wrote: > The following crashes on `Gen` when emitting code at `visitYield`. > > return (B) switch (o) { > default -> new A(); > }; > > Why? Because the `yield` is retyped in `TransTypes` to `(B) new A()` and during `visitYield` in `Gen.java`, there is a check that essentially says: check the last type and assert if its a super-type of the current type. > > That retype in `TransTypes` is exercised in one test regarding intersection types. > > Now, if I write a redundant cast: > > return (B) (A) switch (o) { > default -> new A(); > }; > > it works. because the `Yield` is not retyped. This PR translates the cases with the correct prototype (of the type of the switch itself -- `A` in the aforementioned examples). > > WDYT? Seems reasonable to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.org/jdk/pull/10232 From vromero at openjdk.org Tue Sep 13 13:44:00 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 Sep 2022 13:44:00 GMT Subject: RFR: 8292755: Non-default method in interface leads to a stack overflow in JShell In-Reply-To: References: Message-ID: <6_eEE5ZIEpezCdN-BuYozkoq9B-Hl8cNKYmSj_LX6Z0=.43ad170e-854f-4c7a-addf-c3f21344a766@github.com> On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda wrote: > Consider this snippet sent to JShell: > > interface I { > void test() { > try { > } catch (IllegalStateException ex) { > throw new RuntimeException(ex); > } > } > } > > > This leads to a crash: > > Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415) > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.(TaskFactory.java:406) > at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178) > at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213) > at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193) > at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206) > at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175) > at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161) > at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060) > at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893) > at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140) > at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383) > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412) > ... 18 more > Caused by: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > ... > > > The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions. > > The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10221 From vromero at openjdk.org Tue Sep 13 13:44:00 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 Sep 2022 13:44:00 GMT Subject: RFR: 8292755: Non-default method in interface leads to a stack overflow in JShell In-Reply-To: References: <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com> Message-ID: On Tue, 13 Sep 2022 09:27:20 GMT, Jan Lahoda wrote: > > question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output > > Yes, there may be some more error generated (if the body is erroneous), but I don't see it as a big problem: the errors are there, and when the user adds the `default` keyword (or removes a wrong keyword), the errors will show anyway. To me, it is not clear that a broken modifier is a problem big enough to stop attributing the body - there are many other problems that we find during the attribution of the method header that will not stop method body attribution. Like: > > ``` > $ cat Test.java > public interface Test { > default void test(Unknown1 t) { > Unknown2 tt; > } > } > $ javac Test.java > Test.java:2: error: cannot find symbol > default void test(Unknown1 t) { > ^ > symbol: class Unknown1 > location: interface Test > Test.java:3: error: cannot find symbol > Unknown2 tt; > ^ > symbol: class Unknown2 > location: interface Test > 2 errors > ``` > > I am a bit worried that generating more stub data will lead only to a whack-a-mole trying to cover all corner cases where the stub data are not good enough, while simply letting the attribution proceed should cover the cases as it does for normal methods. I see your point, totally agree ------------- PR: https://git.openjdk.org/jdk/pull/10221 From darcy at openjdk.org Wed Sep 14 01:33:02 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 14 Sep 2022 01:33:02 GMT Subject: RFR: JDK-8293768: Add links to JLS 19 and 20 from SourceVersion enum constants Message-ID: Originally, I was only going to add a link to JLS 19 for when the docs for Java SE 19 went live, but at time of writing the JLS 19 link goes to the specifications landing page rather than giving a 404. Therefore, adding links to both JLS 19 and 20 know aren't dead links per se and will become better links as the JLS 19 and 20 pages are published in the future. When the resolved JLS-version-specific links resolving the specification home page, the future I'll add the link to the specific JLS version when I add a new SourceVersion constant. ------------- Commit messages: - JDK-8293768: Add links to JLS 19 and 20 from SourceVersion enum constants Changes: https://git.openjdk.org/jdk/pull/10257/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10257&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293768 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10257.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10257/head:pull/10257 PR: https://git.openjdk.org/jdk/pull/10257 From iris at openjdk.org Wed Sep 14 03:33:19 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 14 Sep 2022 03:33:19 GMT Subject: RFR: JDK-8293768: Add links to JLS 19 and 20 from SourceVersion enum constants In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 01:24:05 GMT, Joe Darcy wrote: > Originally, I was only going to add a link to JLS 19 for when the docs for Java SE 19 went live, but at time of writing the JLS 19 link goes to the specifications landing page rather than giving a 404. Therefore, adding links to both JLS 19 and 20 know aren't dead links per se and will become better links as the JLS 19 and 20 pages are published in the future. > > When the resolved JLS-version-specific links resolving the specification home page, the future I'll add the link to the specific JLS version when I add a new SourceVersion constant. Links look good assuming current pattern of link names. Specification landing page rather than 404 verified. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.org/jdk/pull/10257 From abimpoudis at openjdk.org Wed Sep 14 06:51:11 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 14 Sep 2022 06:51:11 GMT Subject: Integrated: 8291657: Javac assertion when compiling a method call with switch expression as argument In-Reply-To: References: Message-ID: <-qRwj7KzoqifZsoPPSY9y9aG-4UtuT51K7p6DC6OJjs=.ea676483-08de-4646-a4a3-010d964866ee@github.com> On Fri, 9 Sep 2022 15:04:13 GMT, Aggelos Biboudis wrote: > The following crashes on `Gen` when emitting code at `visitYield`. > > return (B) switch (o) { > default -> new A(); > }; > > Why? Because the `yield` is retyped in `TransTypes` to `(B) new A()` and during `visitYield` in `Gen.java`, there is a check that essentially says: check the last type and assert if its a super-type of the current type. > > That retype in `TransTypes` is exercised in one test regarding intersection types. > > Now, if I write a redundant cast: > > return (B) (A) switch (o) { > default -> new A(); > }; > > it works. because the `Yield` is not retyped. This PR translates the cases with the correct prototype (of the type of the switch itself -- `A` in the aforementioned examples). > > WDYT? This pull request has now been integrated. Changeset: 1169a159 Author: Aggelos Biboudis Committer: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/1169a1593660242375400e9d6b9ca11a872cdf02 Stats: 46 lines in 2 files changed: 45 ins; 0 del; 1 mod 8291657: Javac assertion when compiling a method call with switch expression as argument Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/10232 From jlahoda at openjdk.org Wed Sep 14 08:53:32 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 Sep 2022 08:53:32 GMT Subject: RFR: 8292755: Non-default method in interface leads to a stack overflow in JShell In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda wrote: > Consider this snippet sent to JShell: > > interface I { > void test() { > try { > } catch (IllegalStateException ex) { > throw new RuntimeException(ex); > } > } > } > > > This leads to a crash: > > Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415) > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.(TaskFactory.java:406) > at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178) > at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213) > at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193) > at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206) > at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175) > at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161) > at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060) > at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893) > at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140) > at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383) > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412) > ... 18 more > Caused by: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > ... > > > The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions. > > The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body. Thanks, Vicente! ------------- PR: https://git.openjdk.org/jdk/pull/10221 From jlahoda at openjdk.org Wed Sep 14 08:53:33 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 Sep 2022 08:53:33 GMT Subject: Integrated: 8292755: Non-default method in interface leads to a stack overflow in JShell In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda wrote: > Consider this snippet sent to JShell: > > interface I { > void test() { > try { > } catch (IllegalStateException ex) { > throw new RuntimeException(ex); > } > } > } > > > This leads to a crash: > > Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415) > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.(TaskFactory.java:406) > at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178) > at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213) > at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193) > at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206) > at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175) > at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161) > at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060) > at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893) > at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140) > at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383) > at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412) > ... 18 more > Caused by: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086) > at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077) > ... > > > The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions. > > The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body. This pull request has now been integrated. Changeset: 2a387918 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/2a3879180e63aa0a7a19479f061fe78d7885da7b Stats: 194 lines in 3 files changed: 185 ins; 8 del; 1 mod 8292755: Non-default method in interface leads to a stack overflow in JShell Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10221 From asotona at openjdk.org Wed Sep 14 11:10:15 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 14 Sep 2022 11:10:15 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v16] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona 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 branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module - Added man-page line about lossy-conversion lint - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5 ------------- Changes: https://git.openjdk.org/jdk/pull/8599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15 Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.org/jdk/pull/8599 From asotona at openjdk.org Wed Sep 14 11:25:38 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 14 Sep 2022 11:25:38 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v16] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <7HAZTQI9U8tr8hrc3uRhkeAnZU4yjyjVDhTB2vXd00E=.69ffd410-c37e-45ec-b812-69bf4a2782ea@github.com> On Wed, 14 Sep 2022 11:10:15 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona 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 branch 'openjdk:master' into JDK-8244681 > - Merge branch 'openjdk:master' into JDK-8244681 > - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le > - Merge branch 'openjdk:master' into JDK-8244681 > - Merge branch 'openjdk:master' into JDK-8244681 > - Merge branch 'openjdk:master' into JDK-8244681 > - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module > - Added man-page line about lossy-conversion lint > - Merge branch 'openjdk:master' into JDK-8244681 > - 8244681: Add a warning for possibly lossy conversion in compound assignments > re-enabled warnings for java.base, java.rmi and java.smartcardio > - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5 Please review also linked Release Note issue. Thanks, Adam ------------- PR: https://git.openjdk.org/jdk/pull/8599 From asotona at openjdk.org Wed Sep 14 11:35:03 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 14 Sep 2022 11:35:03 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v17] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: re-enabled lossy-conversions warnings for jdk.hotspot.agent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8599/files - new: https://git.openjdk.org/jdk/pull/8599/files/4b78b1c5..0b93c284 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.org/jdk/pull/8599 From jlahoda at openjdk.org Wed Sep 14 17:26:28 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 Sep 2022 17:26:28 GMT Subject: RFR: 8293578: Duplicate ldc generated by javac Message-ID: Consider code like: var testC = "incorrect".getClass(); var testV = testC.getConstructor(String.class) .newInstance("correct"); System.err.println(testV); javac has a concept of types with attached constants (to support proper behavior of constant expressions). Normally, these constants are cleared as specific places. But, in the above case, the type of `testC` is actually `Class`, the constant then gets propagated, and eventually the type of `testV` is `String["incorrect"]`, and the code generator will then replace reads from `testV` with a ldc for the constant, so the code above prints "incorrect" instead of "correct". The solution is to invoke `.baseType()` to remove the constant value when constructing the synthetic `.getClass()`'s type (so the type of `testC` is `Class`), and also a tweak to `checkLocalVarType`, as suggested in the bug. ------------- Commit messages: - 8293578: Duplicate ldc generated by javac Changes: https://git.openjdk.org/jdk/pull/10272/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10272&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293578 Stats: 103 lines in 3 files changed: 99 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10272.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10272/head:pull/10272 PR: https://git.openjdk.org/jdk/pull/10272 From jjg at openjdk.org Wed Sep 14 21:02:00 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 14 Sep 2022 21:02:00 GMT Subject: RFR: JDK-8293768: Add links to JLS 19 and 20 from SourceVersion enum constants In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 01:24:05 GMT, Joe Darcy wrote: > Originally, I was only going to add a link to JLS 19 for when the docs for Java SE 19 went live, but at time of writing the JLS 19 link goes to the specifications landing page rather than giving a 404. Therefore, adding links to both JLS 19 and 20 know aren't dead links per se and will become better links as the JLS 19 and 20 pages are published in the future. > > When the resolved JLS-version-specific links resolving the specification home page, the future I'll add the link to the specific JLS version when I add a new SourceVersion constant. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10257 From darcy at openjdk.org Wed Sep 14 21:06:59 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 14 Sep 2022 21:06:59 GMT Subject: Integrated: JDK-8293768: Add links to JLS 19 and 20 from SourceVersion enum constants In-Reply-To: References: Message-ID: <3ckzOTvwx6_q1oKmLoTUtSozvHb0gxgo9nxEth4tVic=.7c37aa65-0e0e-4b05-8de5-6e714e3445e7@github.com> On Wed, 14 Sep 2022 01:24:05 GMT, Joe Darcy wrote: > Originally, I was only going to add a link to JLS 19 for when the docs for Java SE 19 went live, but at time of writing the JLS 19 link goes to the specifications landing page rather than giving a 404. Therefore, adding links to both JLS 19 and 20 know aren't dead links per se and will become better links as the JLS 19 and 20 pages are published in the future. > > When the resolved JLS-version-specific links resolving the specification home page, the future I'll add the link to the specific JLS version when I add a new SourceVersion constant. This pull request has now been integrated. Changeset: d191e475 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/d191e475168f203bb448c4977f8d6d77b8658d25 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod 8293768: Add links to JLS 19 and 20 from SourceVersion enum constants Reviewed-by: iris, jjg ------------- PR: https://git.openjdk.org/jdk/pull/10257 From asotona at openjdk.org Thu Sep 15 10:12:53 2022 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 15 Sep 2022 10:12:53 GMT Subject: Integrated: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam This pull request has now been integrated. Changeset: aff5ff14 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/aff5ff14b208b3c2be93d7b4fab8b07c5be12f3e Stats: 438 lines in 13 files changed: 437 ins; 0 del; 1 mod 8244681: Add a warning for possibly lossy conversion in compound assignments 8293797: Release Note: Javac warns about type casts in compound assignments with possible lossy conversions Reviewed-by: erikj, prr ------------- PR: https://git.openjdk.org/jdk/pull/8599 From mcimadamore at openjdk.org Thu Sep 15 15:14:45 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Sep 2022 15:14:45 GMT Subject: RFR: 8293578: Duplicate ldc generated by javac In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 17:15:30 GMT, Jan Lahoda wrote: > Consider code like: > > var testC = "incorrect".getClass(); > var testV = testC.getConstructor(String.class) > .newInstance("correct"); > System.err.println(testV); > > > javac has a concept of types with attached constants (to support proper behavior of constant expressions). Normally, these constants are cleared as specific places. But, in the above case, the type of `testC` is actually `Class`, the constant then gets propagated, and eventually the type of `testV` is `String["incorrect"]`, and the code generator will then replace reads from `testV` with a ldc for the constant, so the code above prints "incorrect" instead of "correct". > > The solution is to invoke `.baseType()` to remove the constant value when constructing the synthetic `.getClass()`'s type (so the type of `testC` is `Class`), and also a tweak to `checkLocalVarType`, as suggested in the bug. Looks good test/langtools/tools/javac/lvti/ConstantTypes.java line 99: > 97: } > 98: > 99: } watch out for newline ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/10272 From jlahoda at openjdk.org Fri Sep 16 11:40:54 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 Sep 2022 11:40:54 GMT Subject: Integrated: 8293578: Duplicate ldc generated by javac In-Reply-To: References: Message-ID: <11S5hoLQKE-AseV4bFiL_X9SLeTgF4Hvf3Zv0dPmFBM=.f8f471a8-f336-4fcd-88c5-c517accdda9a@github.com> On Wed, 14 Sep 2022 17:15:30 GMT, Jan Lahoda wrote: > Consider code like: > > var testC = "incorrect".getClass(); > var testV = testC.getConstructor(String.class) > .newInstance("correct"); > System.err.println(testV); > > > javac has a concept of types with attached constants (to support proper behavior of constant expressions). Normally, these constants are cleared as specific places. But, in the above case, the type of `testC` is actually `Class`, the constant then gets propagated, and eventually the type of `testV` is `String["incorrect"]`, and the code generator will then replace reads from `testV` with a ldc for the constant, so the code above prints "incorrect" instead of "correct". > > The solution is to invoke `.baseType()` to remove the constant value when constructing the synthetic `.getClass()`'s type (so the type of `testC` is `Class`), and also a tweak to `checkLocalVarType`, as suggested in the bug. This pull request has now been integrated. Changeset: 39cd1635 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/39cd1635bf07f42857e1a704734db66b2c2fa882 Stats: 103 lines in 3 files changed: 99 ins; 0 del; 4 mod 8293578: Duplicate ldc generated by javac Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/10272 From jai.forums2013 at gmail.com Mon Sep 19 13:44:59 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 19 Sep 2022 19:14:59 +0530 Subject: Better error message instead of "record header expected"? Message-ID: Please consider this trivial code: public record Record { } Trying to compile this results in: javac Record.java Record.java:1: error: record header expected public record Record { ????????? ^ 1 error It isn't too clear what that error message means. It took me a while to realize that I had missed using the () after the record's name. Changing the source to: public record Record() { } is what the error was trying to convey. Could this error message be improved? By the way, notice that the error message was pointing to the "r" letter of the "record" keyword with the ^ sign. Is that right place for this error or should it have been after the "d" of the "Record" name, similar to what appears to be reported for constructors of classes, for example: public class Event { ?? ?public Event { ?? ?} } javac Event.java Event.java:2: error: expected ?? ?public Event { ????????????????????? ^ 1 error (not sure if mail clients will preserve the spacing - that ^ appears between the "t" and the "{") -Jaikiran From vicente.romero at oracle.com Mon Sep 19 14:28:07 2022 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 19 Sep 2022 10:28:07 -0400 Subject: Better error message instead of "record header expected"? In-Reply-To: References: Message-ID: Hi Jaikiran, Thanks for the report, I have filed [1] to track this issue, Thanks, Vicente [1] https://bugs.openjdk.org/browse/JDK-8294020 On 9/19/22 09:44, Jaikiran Pai wrote: > Please consider this trivial code: > > public record Record { > > } > > Trying to compile this results in: > > javac Record.java > > Record.java:1: error: record header expected > > public record Record { > ????????? ^ > > 1 error > > It isn't too clear what that error message means. It took me a while > to realize that I had missed using the () after the record's name. > Changing the source to: > > public record Record() { > > } > > is what the error was trying to convey. Could this error message be > improved? > > By the way, notice that the error message was pointing to the "r" > letter of the "record" keyword with the ^ sign. Is that right place > for this error or should it have been after the "d" of the "Record" > name, similar to what appears to be reported for constructors of > classes, for example: > > public class Event { > ?? ?public Event { > > ?? ?} > } > > javac Event.java > > Event.java:2: error: expected > ?? ?public Event { > ????????????????????? ^ > 1 error > > (not sure if mail clients will preserve the spacing - that ^ appears > between the "t" and the "{") > > -Jaikiran > From ethan at mccue.dev Mon Sep 19 16:58:40 2022 From: ethan at mccue.dev (Ethan McCue) Date: Mon, 19 Sep 2022 12:58:40 -0400 Subject: Better error message instead of "record header expected"? In-Reply-To: References: Message-ID: Ideally, the error message could be something like error[E0123]: record header expected --> src/Record.java:1:20 | 1 | public record Record { | ^ record header required here | help: to make a record with no components, use an empty header | 1 | public record Record() { | For more information about this error, try `javac --explain E0123`. I'm sorry that I haven't had my life in enough of a line to make that full proposal though. On Mon, Sep 19, 2022 at 10:29 AM Vicente Romero wrote: > Hi Jaikiran, > > Thanks for the report, I have filed [1] to track this issue, > > Thanks, > Vicente > > [1] https://bugs.openjdk.org/browse/JDK-8294020 > > On 9/19/22 09:44, Jaikiran Pai wrote: > > Please consider this trivial code: > > > > public record Record { > > > > } > > > > Trying to compile this results in: > > > > javac Record.java > > > > Record.java:1: error: record header expected > > > > public record Record { > > ^ > > > > 1 error > > > > It isn't too clear what that error message means. It took me a while > > to realize that I had missed using the () after the record's name. > > Changing the source to: > > > > public record Record() { > > > > } > > > > is what the error was trying to convey. Could this error message be > > improved? > > > > By the way, notice that the error message was pointing to the "r" > > letter of the "record" keyword with the ^ sign. Is that right place > > for this error or should it have been after the "d" of the "Record" > > name, similar to what appears to be reported for constructors of > > classes, for example: > > > > public class Event { > > public Event { > > > > } > > } > > > > javac Event.java > > > > Event.java:2: error: expected > > public Event { > > ^ > > 1 error > > > > (not sure if mail clients will preserve the spacing - that ^ appears > > between the "t" and the "{") > > > > -Jaikiran > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Mon Sep 19 18:20:34 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 Sep 2022 18:20:34 GMT Subject: RFR: 8292756: java.lang.AssertionError at at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) Message-ID: Consider code like: public class JDK_8292756 { private int test(Object o) { int i1, i2, i3, i4, i5, i6, i7; return switch(o) { case Object oo when oo != null -> 0; default -> 0; }; } } Compiling this leads to a crash: $ javac --enable-preview -source 19 /tmp/JDK_8292756.java Note: /tmp/JDK_8292756.java uses preview features of Java SE 19. Note: Recompile with -Xlint:preview for details. An exception has occurred in the compiler (19-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5621) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5512) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5336) at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5275) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64) at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50) printing javac parameters to: /tmp/javac.20220919_200140.args The reason for the failure is this: in `Attr.handleSwitch`, there is an input scope `env`, and a sub-scope of it, `switchEnv`, is created for the switch. Eventually, another (shared) sub-scope is created for the guard expression, `bodyEnv`. All `env`, `switchEnv` and `bodyEnv` share an internal table. But, the `bodyEnv` sub-scope is created from `env`, not from `switchEnv` (as it should). Which mostly works, but if the internal table for `bodyEnv` is resized, it will correctly fix only `env`, but not `switchEnv`. The solution to this problem is to simply base the `bodyEnv` on `switchEnv`, not on `env`. But, in addition to that, it does not seem right the scopes don't protect from an accident like this. So the proposed patch here is enhancing the assertions in `Scope` so that a shared duplicate of a Scope can only be done from a leaf Scope. ------------- Commit messages: - 8292756: java.lang.AssertionError at at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) Changes: https://git.openjdk.org/jdk/pull/10347/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10347&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292756 Stats: 119 lines in 3 files changed: 106 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10347.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10347/head:pull/10347 PR: https://git.openjdk.org/jdk/pull/10347 From jlahoda at openjdk.org Mon Sep 19 18:37:20 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 Sep 2022 18:37:20 GMT Subject: RFR: 8293897: Synthetic final modifier is part of the AST for a try-with-resource resource Message-ID: The resources in try-with-resource are implicitly final (unless they are marked as final in the source code). But, in javac, the `FINAL` modifier is part of the modifiers on the AST, which is in contrary to the usual direction of having the AST closely model the source code. The proposal here is to not add the synthetic `FINAL` modifier to the AST, but add it to the given `VarSymbol`. The positions of the `ModifiersTree` are also tweaked, so that for a synthetic tree, the positions are `NOPOS`. ------------- Commit messages: - 8293897: Final modifier auto inserted as part of try with resources statement Changes: https://git.openjdk.org/jdk/pull/10348/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10348&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293897 Stats: 71 lines in 3 files changed: 67 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10348.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10348/head:pull/10348 PR: https://git.openjdk.org/jdk/pull/10348 From vicente.romero at oracle.com Mon Sep 19 19:12:45 2022 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 19 Sep 2022 15:12:45 -0400 Subject: [External] : Re: Better error message instead of "record header expected"? In-Reply-To: References: Message-ID: <9b7d70b9-46fe-158c-3e84-4fee031e3add@oracle.com> thanks for your proposal, the final version will probably be a bit shorter but this one could be a good start Vicente On 9/19/22 12:58, Ethan McCue wrote: > Ideally, the error message could be something like > > ? ? error[E0123]: record header expected > ? ? ?--> src/Record.java:1:20 > ? ? ? | > ? ? 1 | ? ? public record Record { > ? ? ? | ? ?^ record header required here > ? ? ? | > ? ? help: to make a record with no components, use an empty header > ? ? ? | > ? ? 1 | public record Record() { > ? ? ? | > > ? ? For more information about this error, try `javac --explain E0123`. > > I'm sorry that I haven't had my life in enough of a line to make that > full proposal though. > > On Mon, Sep 19, 2022 at 10:29 AM Vicente Romero > wrote: > > Hi Jaikiran, > > Thanks for the report, I have filed [1] to track this issue, > > Thanks, > Vicente > > [1] https://bugs.openjdk.org/browse/JDK-8294020 > > On 9/19/22 09:44, Jaikiran Pai wrote: > > Please consider this trivial code: > > > > public record Record { > > > > } > > > > Trying to compile this results in: > > > > javac Record.java > > > > Record.java:1: error: record header expected > > > > public record Record { > > ????????? ^ > > > > 1 error > > > > It isn't too clear what that error message means. It took me a > while > > to realize that I had missed using the () after the record's name. > > Changing the source to: > > > > public record Record() { > > > > } > > > > is what the error was trying to convey. Could this error message be > > improved? > > > > By the way, notice that the error message was pointing to the "r" > > letter of the "record" keyword with the ^ sign. Is that right place > > for this error or should it have been after the "d" of the "Record" > > name, similar to what appears to be reported for constructors of > > classes, for example: > > > > public class Event { > > ?? ?public Event { > > > > ?? ?} > > } > > > > javac Event.java > > > > Event.java:2: error: expected > > ?? ?public Event { > > ????????????????????? ^ > > 1 error > > > > (not sure if mail clients will preserve the spacing - that ^ > appears > > between the "t" and the "{") > > > > -Jaikiran > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Tue Sep 20 09:50:00 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 20 Sep 2022 09:50:00 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v6] In-Reply-To: References: Message-ID: > 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 Jan Lahoda 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 eight additional commits since the last revision: - Adding LOG_LEVEL based debugging to the Depend Plugin. - Merge branch 'master' into JDK-8293116 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293116 - Regenerating modfiles as necessary. - Adding comment. - Reflecting review feedback. - Reflecting review feedback. - 8293116: Incremental JDK build could be sped up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10104/files - new: https://git.openjdk.org/jdk/pull/10104/files/c3455660..661f9072 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10104&range=04-05 Stats: 75927 lines in 1333 files changed: 36116 ins; 31717 del; 8094 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 jlahoda at openjdk.org Tue Sep 20 10:07:35 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 20 Sep 2022 10:07:35 GMT Subject: RFR: 8293897: Synthetic final modifier is part of the AST for a try-with-resource resource [v2] In-Reply-To: References: Message-ID: > The resources in try-with-resource are implicitly final (unless they are marked as final in the source code). But, in javac, the `FINAL` modifier is part of the modifiers on the AST, which is in contrary to the usual direction of having the AST closely model the source code. > > The proposal here is to not add the synthetic `FINAL` modifier to the AST, but add it to the given `VarSymbol`. The positions of the `ModifiersTree` are also tweaked, so that for a synthetic tree, the positions are `NOPOS`. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adding a test with explicit final modifier. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10348/files - new: https://git.openjdk.org/jdk/pull/10348/files/a719a34f..4a2459b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10348&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10348&range=00-01 Stats: 20 lines in 1 file changed: 17 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10348.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10348/head:pull/10348 PR: https://git.openjdk.org/jdk/pull/10348 From sundar at openjdk.org Tue Sep 20 10:17:40 2022 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Tue, 20 Sep 2022 10:17:40 GMT Subject: RFR: 8293897: Synthetic final modifier is part of the AST for a try-with-resource resource [v2] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 10:07:35 GMT, Jan Lahoda wrote: >> The resources in try-with-resource are implicitly final (unless they are marked as final in the source code). But, in javac, the `FINAL` modifier is part of the modifiers on the AST, which is in contrary to the usual direction of having the AST closely model the source code. >> >> The proposal here is to not add the synthetic `FINAL` modifier to the AST, but add it to the given `VarSymbol`. The positions of the `ModifiersTree` are also tweaked, so that for a synthetic tree, the positions are `NOPOS`. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adding a test with explicit final modifier. LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.org/jdk/pull/10348 From jlahoda at openjdk.org Tue Sep 20 13:33:14 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 20 Sep 2022 13:33:14 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: References: Message-ID: > 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into JDK-8291769 - Merge branch 'master' into JDK-8291769 - Reflecting review feedback. - Merge branch 'master' into JDK-8291769 - Using a custom record instead of a generic Pair. - Fixing test. - Properly handle null record components. - 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=05 Stats: 1368 lines in 12 files changed: 1199 ins; 78 del; 91 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 ihse at openjdk.org Tue Sep 20 17:27:48 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 20 Sep 2022 17:27:48 GMT Subject: RFR: 8293116: Incremental JDK build could be sped up [v6] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 09:50:00 GMT, Jan Lahoda 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 > > Jan Lahoda 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 eight additional commits since the last revision: > > - Adding LOG_LEVEL based debugging to the Depend Plugin. > - Merge branch 'master' into JDK-8293116 > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293116 > - Regenerating modfiles as necessary. > - Adding comment. > - Reflecting review feedback. > - Reflecting review feedback. > - 8293116: Incremental JDK build could be sped up Thanks for adding the logging! And thank you for hanging in there. Javac/build integration is a minefield of unstated assumptions. :-/ I am very eager to see this go in now. I hope everyone doing incremental Java development will see nice benefits. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/jdk/pull/10104 From jjg at openjdk.org Wed Sep 21 01:06:31 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 21 Sep 2022 01:06:31 GMT Subject: RFR: JDK-8293877: Rewrite MineField test Message-ID: Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. ------------- Commit messages: - JDK-8293877: Rewrite MineField test Changes: https://git.openjdk.org/jdk/pull/10366/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10366&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293877 Stats: 3256 lines in 15 files changed: 1979 ins; 1276 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10366.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10366/head:pull/10366 PR: https://git.openjdk.org/jdk/pull/10366 From darcy at openjdk.org Wed Sep 21 03:08:51 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 21 Sep 2022 03:08:51 GMT Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods [v2] In-Reply-To: References: Message-ID: <9KFOfO_3tQ2qn9IxVRqnX1XLSATF0mP322Vd4UFLWqo=.188afd04-1f93-4304-99ee-dd136ecfaef6@github.com> On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy 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 again. ------------- PR: https://git.openjdk.org/jdk/pull/8984 From duke at openjdk.org Wed Sep 21 06:14:46 2022 From: duke at openjdk.org (Hannes Greule) Date: Wed, 21 Sep 2022 06:14:46 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v5] In-Reply-To: <6e64srLbjHyJ8Ub60mBRjPJzPaNNYcWm-MI5ETketgo=.68200038-aaa7-4a91-b023-3526e1449cca@github.com> References: <6e64srLbjHyJ8Ub60mBRjPJzPaNNYcWm-MI5ETketgo=.68200038-aaa7-4a91-b023-3526e1449cca@github.com> Message-ID: On Tue, 23 Aug 2022 19:39:48 GMT, Hannes Greule 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: > > address comments Hi, is there anything else that needs to be done from my side? ------------- PR: https://git.openjdk.org/jdk/pull/9862 From jlahoda at openjdk.org Wed Sep 21 10:31:16 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 21 Sep 2022 10:31:16 GMT Subject: Integrated: 8293116: Incremental JDK build could be sped up In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 17:51:31 GMT, Jan Lahoda 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 pull request has now been integrated. Changeset: cd1cdcdb Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/cd1cdcdb0d56131d1ad1bdc453c7e261afa73a3a Stats: 590 lines in 7 files changed: 566 ins; 0 del; 24 mod 8293116: Incremental JDK build could be sped up Reviewed-by: erikj, vromero, ihse ------------- PR: https://git.openjdk.org/jdk/pull/10104 From jlahoda at openjdk.org Wed Sep 21 11:32:52 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 21 Sep 2022 11:32:52 GMT Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods [v2] In-Reply-To: References: Message-ID: On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy 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 src/java.compiler/share/classes/javax/lang/model/util/Types.java line 241: > 239: * @param extendsBound the extends (upper) bound, or {@code null} if none > 240: * @param superBound the super (lower) bound, or {@code null} if none > 241: * @throws IllegalArgumentException if bounds are not valid Should annotation also be preserved (and also documented to be preserved) for `getDeclaredType`? test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java line 137: > 135: // public static @TypeAnnotation("foo4") java.util.Set foo4() {return null;} > 136: > 137: // public static @TypeAnnotation("foo4") String[] foo4() {return null;} It would be good to have a test verifying the annotation on the array component is removed by `erasure`. ------------- PR: https://git.openjdk.org/jdk/pull/8984 From jlahoda at openjdk.org Wed Sep 21 12:33:50 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 21 Sep 2022 12:33:50 GMT Subject: Integrated: 8293897: Synthetic final modifier is part of the AST for a try-with-resource resource In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 18:28:32 GMT, Jan Lahoda wrote: > The resources in try-with-resource are implicitly final (unless they are marked as final in the source code). But, in javac, the `FINAL` modifier is part of the modifiers on the AST, which is in contrary to the usual direction of having the AST closely model the source code. > > The proposal here is to not add the synthetic `FINAL` modifier to the AST, but add it to the given `VarSymbol`. The positions of the `ModifiersTree` are also tweaked, so that for a synthetic tree, the positions are `NOPOS`. This pull request has now been integrated. Changeset: 95ec2eac Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/95ec2eaca3845bc971d3e711e5f61052c2951fa8 Stats: 88 lines in 3 files changed: 84 ins; 1 del; 3 mod 8293897: Synthetic final modifier is part of the AST for a try-with-resource resource Reviewed-by: sundar ------------- PR: https://git.openjdk.org/jdk/pull/10348 From vromero at openjdk.org Wed Sep 21 14:55:17 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 Sep 2022 14:55:17 GMT Subject: RFR: 8292756: java.lang.AssertionError at at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 18:13:27 GMT, Jan Lahoda wrote: > Consider code like: > > public class JDK_8292756 { > private int test(Object o) { > int i1, i2, i3, i4, i5, i6, i7; > return switch(o) { > case Object oo when oo != null -> 0; > default -> 0; > }; > } > } > > > Compiling this leads to a crash: > > $ javac --enable-preview -source 19 /tmp/JDK_8292756.java > Note: /tmp/JDK_8292756.java uses preview features of Java SE 19. > Note: Recompile with -Xlint:preview for details. > An exception has occurred in the compiler (19-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.AssertionError > at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) > at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5621) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5512) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5336) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5275) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50) > printing javac parameters to: /tmp/javac.20220919_200140.args > > > The reason for the failure is this: in `Attr.handleSwitch`, there is an input scope `env`, and a sub-scope of it, `switchEnv`, is created for the switch. Eventually, another (shared) sub-scope is created for the guard expression, `bodyEnv`. All `env`, `switchEnv` and `bodyEnv` share an internal table. But, the `bodyEnv` sub-scope is created from `env`, not from `switchEnv` (as it should). Which mostly works, but if the internal table for `bodyEnv` is resized, it will correctly fix only `env`, but not `switchEnv`. > > The solution to this problem is to simply base the `bodyEnv` on `switchEnv`, not on `env`. But, in addition to that, it does not seem right the scopes don't protect from an accident like this. So the proposed patch here is enhancing the assertions in `Scope` so that a shared duplicate of a Scope can only be done from a leaf Scope. looks good src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java line 277: > 275: /** true if this scope's hash table is shared with a nested scope. > 276: */ > 277: private boolean shared; great! ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10347 From duke at openjdk.org Wed Sep 21 23:12:52 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 21 Sep 2022 23:12:52 GMT Subject: RFR: 8043179: Lambda expression can mutate final field. Message-ID: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`. This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this: LambdaFieldInit.java:6: error: variable x might already have been assigned Runnable r1 = () -> x = "hi"; ^ This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins). ------------- Commit messages: - 8043179: Lambda expression can mutate final field. Changes: https://git.openjdk.org/jdk/pull/10381/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8043179 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From jjg at openjdk.org Thu Sep 22 03:41:23 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 22 Sep 2022 03:41:23 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v14] In-Reply-To: References: Message-ID: > 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 22 commits: - Fix merge issue - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2 - 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 - ... and 12 more: https://git.openjdk.org/jdk/compare/2283c324...be7510e5 ------------- Changes: https://git.openjdk.org/jdk/pull/8439/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=13 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 iris at openjdk.org Thu Sep 22 08:15:29 2022 From: iris at openjdk.org (Iris Clark) Date: Thu, 22 Sep 2022 08:15:29 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v14] In-Reply-To: References: Message-ID: <1E7Yr-7zxnhTReLJBrPYCQJNOo-slOt8bI7WKuPWvm4=.159d5e6f-fdb6-4516-b0df-c95d0134b509@github.com> On Tue, 3 May 2022 13:22:05 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - Fix merge issue >> - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2 >> - 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 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/2283c324...be7510e5 > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java line 192: > >> 190: * >> 191: * @param element the element that owns the doc comment >> 192: * @param specTags the array of @spec tags. > > Naked tags that aren't meant to be interpreted by javadoc make me uncomfortable. `{@code @spec}` similar to line 200? ------------- PR: https://git.openjdk.org/jdk/pull/8439 From jlahoda at openjdk.org Thu Sep 22 14:35:51 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 22 Sep 2022 14:35:51 GMT Subject: Integrated: 8292756: java.lang.AssertionError at at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 18:13:27 GMT, Jan Lahoda wrote: > Consider code like: > > public class JDK_8292756 { > private int test(Object o) { > int i1, i2, i3, i4, i5, i6, i7; > return switch(o) { > case Object oo when oo != null -> 0; > default -> 0; > }; > } > } > > > Compiling this leads to a crash: > > $ javac --enable-preview -source 19 /tmp/JDK_8292756.java > Note: /tmp/JDK_8292756.java uses preview features of Java SE 19. > Note: Recompile with -Xlint:preview for details. > An exception has occurred in the compiler (19-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.AssertionError > at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) > at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5621) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5512) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5336) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5275) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50) > printing javac parameters to: /tmp/javac.20220919_200140.args > > > The reason for the failure is this: in `Attr.handleSwitch`, there is an input scope `env`, and a sub-scope of it, `switchEnv`, is created for the switch. Eventually, another (shared) sub-scope is created for the guard expression, `bodyEnv`. All `env`, `switchEnv` and `bodyEnv` share an internal table. But, the `bodyEnv` sub-scope is created from `env`, not from `switchEnv` (as it should). Which mostly works, but if the internal table for `bodyEnv` is resized, it will correctly fix only `env`, but not `switchEnv`. > > The solution to this problem is to simply base the `bodyEnv` on `switchEnv`, not on `env`. But, in addition to that, it does not seem right the scopes don't protect from an accident like this. So the proposed patch here is enhancing the assertions in `Scope` so that a shared duplicate of a Scope can only be done from a leaf Scope. This pull request has now been integrated. Changeset: 0be2b2c2 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/0be2b2c2f1b670bbcd3a8e17bc9b43a534909da5 Stats: 119 lines in 3 files changed: 106 ins; 0 del; 13 mod 8292756: java.lang.AssertionError at at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10347 From cushon at openjdk.org Thu Sep 22 16:54:23 2022 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 22 Sep 2022 16:54:23 GMT Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods [v2] In-Reply-To: References: Message-ID: On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy 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 src/java.compiler/share/classes/javax/lang/model/util/Types.java line 40: > 38: * Where a method returns a type mirror or a collection of type > 39: * mirrors, any type mirrors represent types with no type annotations, > 40: * unless otherwise indicated. I'm seeing `erasure` preserve type annotations on the array type (but not its component) after this change: `erasure(@A int @B []) = int @B []`. (Here's the [repro](https://gist.github.com/cushon/e0a59cc291c3b83204b9139addb01340).) Is that deliberate, or is this still work in progress? ------------- PR: https://git.openjdk.org/jdk/pull/8984 From cushon at openjdk.org Thu Sep 22 16:56:24 2022 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 22 Sep 2022 16:56:24 GMT Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods [v2] In-Reply-To: References: Message-ID: On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy 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 FWIW I did some testing with the current version of the patch, and didn't see any compatibility impact. ------------- PR: https://git.openjdk.org/jdk/pull/8984 From martin at openjdk.org Thu Sep 22 19:24:30 2022 From: martin at openjdk.org (Martin Buchholz) Date: Thu, 22 Sep 2022 19:24:30 GMT Subject: RFR: JDK-8293877: Rewrite MineField test In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 00:57:22 GMT, Jonathan Gibbons wrote: > Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. > > This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. > > The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. > > Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. > > The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. > > Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. > > On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. > > Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. > > The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. > > Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. > > Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. Explicit OS command invocation and ToolProvider invocation both seem important to test. IIRC there were times when they were not in fact equivalent in effect. Consider library infrastructure to run both variants and ensure results are identical. I recall being slightly proud when writing the first iteration of this test - it allowed a very terse test description in shell. But terseness is not universally admired, and even I (in my dotage) have joined the camp of writing tests in more verbose junit style. ------------- PR: https://git.openjdk.org/jdk/pull/10366 From darcy at openjdk.org Fri Sep 23 05:48:12 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 23 Sep 2022 05:48:12 GMT Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 16:54:08 GMT, Liam Miller-Cushon wrote: > FWIW I did some testing with the current version of the patch, and didn't see any compatibility impact. Thanks for the testing Liam. Completing this patch has gotten swapped out for me, but I intend to swap it back in for JDK 20. ------------- PR: https://git.openjdk.org/jdk/pull/8984 From imkiva at islovely.icu Fri Sep 23 12:43:32 2022 From: imkiva at islovely.icu (Kiva) Date: Fri, 23 Sep 2022 20:43:32 +0800 Subject: Javac throws AssertionError randomly for nested pattern matching Message-ID: <3jsb56s6st-1@m0246573.ppops.net> Hello! I found a severe bug when pattern-matching switches are nested. My Java version: openjdk 19 2022-09-20 OpenJDK Runtime Environment (build 19+37) OpenJDK 64-Bit Server VM (build 19+37, mixed mode, sharing) The code that triggers ICE (just a ordinary unification algorithm): public class Bug { sealed interface Term { record Mula(Formula formula) implements Term {} record I() implements Term {} record U() implements Term {} } sealed interface Formula { record Lit(boolean left) implements Formula {} record Inv(Term i) implements Formula {} } public static Term compare(Term preLhs, Term preRhs) { return switch (preLhs) { case Term.I i -> new Term.U(); case Term.U u -> new Term.U(); case Term.Mula lhs -> { if (!(preRhs instanceof Term.Mula rhs)) yield null; var happy = switch (lhs.formula()) { case Formula.Lit ll when rhs.formula() instanceof Formula.Lit rr -> ll.left() == rr.left(); case Formula.Inv ll when rhs.formula() instanceof Formula.Inv rr -> compare(ll.i(), rr.i()) != null; default -> false; }; yield happy ? new Term.I() : null; } }; } public static void main(String[] args) { System.out.println(System.getProperty("java.version")); } } Throws this error randomly: An exception has occurred in the compiler (19). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5601) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5492) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5316) at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5255) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94) at org.gradle.internal.compiler.java.IncrementalCompileTask.call(IncrementalCompileTask.java:89) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesw at openjdk.org Fri Sep 23 14:18:26 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 23 Sep 2022 14:18:26 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v14] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 03:41:23 GMT, Jonathan Gibbons wrote: >> 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 22 commits: > > - Fix merge issue > - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2 > - 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 > - ... and 12 more: https://git.openjdk.org/jdk/compare/2283c324...be7510e5 All looks very good! The only place that looks suspicious to me is the `inherit` implementation in `SpecTaglet.java`, which also seems not to be covered by the test. I guess the best way to examine the output of the new tag is via test output. I'll have a look at that to see the HTML and CSS in action before giving a thumbs up. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 65: > 63: ? ch.getFirstSentenceTrees(output.holderTag) > 64: : ch.getReference(output.holderTag); > 65: } This implementation seems to be copied from SeeTaglet.java. Is it fully functional in this context? The use of CommentHelper.getReference looks suspicious to me. ------------- PR: https://git.openjdk.org/jdk/pull/8439 From jjg at openjdk.org Fri Sep 23 17:17:41 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 23 Sep 2022 17:17:41 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v14] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 13:53:46 GMT, Hannes Walln?fer wrote: >> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - Fix merge issue >> - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2 >> - 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 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/2283c324...be7510e5 > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 65: > >> 63: ? ch.getFirstSentenceTrees(output.holderTag) >> 64: : ch.getReference(output.holderTag); >> 65: } > > This implementation seems to be copied from SeeTaglet.java. Is it fully functional in this context? The use of CommentHelper.getReference looks suspicious to me. Thanks for the comment; I'll investigate ------------- PR: https://git.openjdk.org/jdk/pull/8439 From jjg at openjdk.org Fri Sep 23 17:27:50 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 23 Sep 2022 17:27:50 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v14] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 17:15:23 GMT, Jonathan Gibbons wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 65: >> >>> 63: ? ch.getFirstSentenceTrees(output.holderTag) >>> 64: : ch.getReference(output.holderTag); >>> 65: } >> >> This implementation seems to be copied from SeeTaglet.java. Is it fully functional in this context? The use of CommentHelper.getReference looks suspicious to me. > > Thanks for the comment; I'll investigate Good catch; Yes, the use of `getReference` is indeed questionable, given its implementation, which is specific to `@see`. Given ongoing recent work, it's also not clear that the `@spec` tag should be inheritable. ------------- PR: https://git.openjdk.org/jdk/pull/8439 From jjg at openjdk.org Fri Sep 23 17:50:23 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 23 Sep 2022 17:50:23 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v14] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 17:24:49 GMT, Jonathan Gibbons wrote: >> Thanks for the comment; I'll investigate > > Good catch; > > Yes, the use of `getReference` is indeed questionable, given its implementation, which is specific to `@see`. Given ongoing recent work, it's also not clear that the `@spec` tag should be inheritable. For now, I'll change it to `getTags`, pending discussions on whether the tag should be inheritable. ------------- PR: https://git.openjdk.org/jdk/pull/8439 From jjg at openjdk.org Fri Sep 23 21:47:30 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 23 Sep 2022 21:47:30 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v15] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Address review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8439/files - new: https://git.openjdk.org/jdk/pull/8439/files/be7510e5..97301921 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=13-14 Stats: 35 lines in 2 files changed: 16 ins; 16 del; 3 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 jjg at openjdk.org Fri Sep 23 21:49:07 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 23 Sep 2022 21:49:07 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v14] In-Reply-To: References: Message-ID: <904pGLMooArW2T1H3Fpwt0HeFsFdtqO1YOisJCCe7F0=.91279180-2a3e-4e44-9fdb-64bd947d3870@github.com> On Fri, 23 Sep 2022 17:48:18 GMT, Jonathan Gibbons wrote: >> Good catch; >> >> Yes, the use of `getReference` is indeed questionable, given its implementation, which is specific to `@see`. Given ongoing recent work, it's also not clear that the `@spec` tag should be inheritable. > > For now, I'll change it to `getTags`, pending discussions on whether the tag should be inheritable. With the latest update, toy examples show that tag inherits works as expected, as least as far as parity with `@see`. ------------- PR: https://git.openjdk.org/jdk/pull/8439 From jjg at openjdk.org Fri Sep 23 22:46:06 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 23 Sep 2022 22:46:06 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v16] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Update DPrinter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8439/files - new: https://git.openjdk.org/jdk/pull/8439/files/97301921..30a43968 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 jai.forums2013 at gmail.com Sat Sep 24 06:23:28 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 24 Sep 2022 11:53:28 +0530 Subject: Javac throws AssertionError randomly for nested pattern matching In-Reply-To: <3jsb56s6st-1@m0246573.ppops.net> References: <3jsb56s6st-1@m0246573.ppops.net> Message-ID: <478957b5-1847-97e2-78d6-3d519620fafc@gmail.com> Hello Kiva, I haven't been able to reproduce this issue. But more importantly, this output that you pasted looks odd: On 23/09/22 6:13 pm, Kiva wrote: > ... > > My Java version: > > openjdk 19 2022-09-20 > > OpenJDK Runtime Environment (build 19+37) > > OpenJDK 64-Bit Server VM (build 19+37, mixed mode, sharing) > Where did you get this Java downloaded from and which OS are you on? As far as I know from the release announcement (and even comparing against my local install), OpenJDK 19 build is: openjdk 19 2022-09-20 OpenJDK Runtime Environment (build 19+36-2238) OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode, sharing) So that "build 19+37" looks odd in your output. -Jaikiran -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Sat Sep 24 06:28:18 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 24 Sep 2022 11:58:18 +0530 Subject: Javac throws AssertionError randomly for nested pattern matching In-Reply-To: <478957b5-1847-97e2-78d6-3d519620fafc@gmail.com> References: <3jsb56s6st-1@m0246573.ppops.net> <478957b5-1847-97e2-78d6-3d519620fafc@gmail.com> Message-ID: <753ddcab-55ec-fa88-f03e-d733a79348cd@gmail.com> After I sent this mail, I noticed a recent PR which fixed this issue https://bugs.openjdk.org/browse/JDK-8292756. -Jaikiran On 24/09/22 11:53 am, Jaikiran Pai wrote: > > Hello Kiva, > > I haven't been able to reproduce this issue. But more importantly, > this output that you pasted looks odd: > > On 23/09/22 6:13 pm, Kiva wrote: >> ... >> >> My Java version: >> >> openjdk 19 2022-09-20 >> >> OpenJDK Runtime Environment (build 19+37) >> >> OpenJDK 64-Bit Server VM (build 19+37, mixed mode, sharing) >> > Where did you get this Java downloaded from and which OS are you on? > As far as I know from the release announcement (and even comparing > against my local install), OpenJDK 19 build is: > > openjdk 19 2022-09-20 > OpenJDK Runtime Environment (build 19+36-2238) > OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode, sharing) > > So that "build 19+37" looks odd in your output. > > -Jaikiran > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun Sep 25 00:30:05 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Sun, 25 Sep 2022 00:30:05 GMT Subject: RFR: 8043179: Lambda expression can mutate final field [v2] In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: > This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`. > > This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this: > > LambdaFieldInit.java:6: error: variable x might already have been assigned > Runnable r1 = () -> x = "hi"; > ^ > > > This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins). Archie L. Cobbs has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8043179: Lambda expression can mutate final field ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10381/files - new: https://git.openjdk.org/jdk/pull/10381/files/df8a09a1..47df9c96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=00-01 Stats: 52 lines in 5 files changed: 46 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From duke at openjdk.org Sun Sep 25 00:30:08 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Sun, 25 Sep 2022 00:30:08 GMT Subject: RFR: 8043179: Lambda expression can mutate final field In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: On Wed, 21 Sep 2022 23:03:45 GMT, Archie L. Cobbs wrote: > This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`. > > This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this: > > LambdaFieldInit.java:6: error: variable x might already have been assigned > Runnable r1 = () -> x = "hi"; > ^ > > > This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins). I've updated this pull request to include a new unit test (apologies for omitting it previously). Also there are a couple of changes to other unit tests which get broken because this change reflects changes to the JLS spec per [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176). I'm a little unclear on precisely what the new behavior is supposed to be, but in any case the actual behavior now makes a lot more sense: basically, everything that happens in a lambda is assumed to happen some indefinite time later in the future (same as if you were instantiating the equivalent local class), so the previous errors expected by `T8024809/SelfInitializerInLambdaTestb.java` regarding instance field initialization are no longer errors. In summary: * Added new unit test `LambdaMutateFinalField.java` testing [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) directly. * Unit test [`lambda/self_initializer/T8024809/SelfInitializerInLambdaTestb.java`](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/lambda/self_initializer/T8024809/SelfInitializerInLambdaTestb.java) is now obsolete. Now it compiles successfully. * Unit test [`lambda/lambdaExpression/EffectivelyFinal_neg.java`](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.java) still works, but no longer generates a duplicate error. I think this is a good thing? The expected test output has been updated. With the above changes now all javac tests should succeed. ------------- PR: https://git.openjdk.org/jdk/pull/10381 From duke at openjdk.org Sun Sep 25 00:55:12 2022 From: duke at openjdk.org (Tesla I. =?UTF-8?B?WmhhbmfigK4=?=) Date: Sun, 25 Sep 2022 00:55:12 GMT Subject: RFR: 8292756: java.lang.AssertionError at at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 18:13:27 GMT, Jan Lahoda wrote: > Consider code like: > > public class JDK_8292756 { > private int test(Object o) { > int i1, i2, i3, i4, i5, i6, i7; > return switch(o) { > case Object oo when oo != null -> 0; > default -> 0; > }; > } > } > > > Compiling this leads to a crash: > > $ javac --enable-preview -source 19 /tmp/JDK_8292756.java > Note: /tmp/JDK_8292756.java uses preview features of Java SE 19. > Note: Recompile with -Xlint:preview for details. > An exception has occurred in the compiler (19-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.AssertionError > at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) > at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5621) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5512) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5336) > at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5275) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50) > printing javac parameters to: /tmp/javac.20220919_200140.args > > > The reason for the failure is this: in `Attr.handleSwitch`, there is an input scope `env`, and a sub-scope of it, `switchEnv`, is created for the switch. Eventually, another (shared) sub-scope is created for the guard expression, `bodyEnv`. All `env`, `switchEnv` and `bodyEnv` share an internal table. But, the `bodyEnv` sub-scope is created from `env`, not from `switchEnv` (as it should). Which mostly works, but if the internal table for `bodyEnv` is resized, it will correctly fix only `env`, but not `switchEnv`. > > The solution to this problem is to simply base the `bodyEnv` on `switchEnv`, not on `env`. But, in addition to that, it does not seem right the scopes don't protect from an accident like this. So the proposed patch here is enhancing the assertions in `Scope` so that a shared duplicate of a Scope can only be done from a leaf Scope. Any chance this can be backported to JDK 19? Several benefits of backporting to JDK 19: + Build tools like Gradle wouldn't support JDK 20 until GA, so having a serious bug in JDK 19 = having a JDK 19 without record patterns at all. + Users won't be able to extensively test the feature without being able to use the feature. Preview features are supposed to be tested. + Bug-fix updates are supposed to deliver bug-fixes, and this is a bug-fix. ------------- PR: https://git.openjdk.org/jdk/pull/10347 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Message-ID: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni ------------- Commit messages: - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294321 Stats: 317 lines in 108 files changed: 0 ins; 195 del; 122 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue. Done: https://bugs.openjdk.org/browse/SKARA-1566 ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Sun Sep 25 17:04:38 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Thu, 25 Aug 2022 19:55:47 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > >> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue. > > Done: https://bugs.openjdk.org/browse/SKARA-1566 Hello Michael @mernst, these changes are mostly fine. However, they are spread across files which reside in different areas of the JDK. For changes like these, we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs. Would you be willing to split this PR into separate ones. I would recommend starting with one PR which includes changes that are part of `test/jdk/java`, `test/jdk/jdk` and `test/jdk/jni`. If you can come up with that PR, then I'll go ahead and create a JBS issue for it and you can then link the PR against that issue. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Mon, 5 Sep 2022 06:32:44 GMT, Jaikiran Pai wrote: > these changes are mostly fine. Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies. > we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs. Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:04:39 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst wrote: > Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Sun Sep 25 17:04:39 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Hello Michael, > > these changes are mostly fine. > > Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies. I wasn't implying this PR had deficiencies. What I meant was, to be able to have this reviewed, in addition to code changes this will also need a issue to be created and linked to this PR (and the PR title changed to the form `: `). I have now created https://bugs.openjdk.org/browse/JDK-8294321. Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Sat, 24 Sep 2022 10:41:05 GMT, Jaikiran Pai wrote: > Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers. OK. I'll repeat my comment from before: > Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Sun, 25 Sep 2022 16:51:27 GMT, SWinxy wrote: > Oh no what happened Oops! Thanks for pointing out the goof. It seems to be fixed now. It has now been a month since I opened the pull request, and I have responded to each substantive comment promptly. It would be great to merge this pull request to avoid the need for more merges. > src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053: > >> 1051: * fetch will take place at index 1. >> 1052: * >> 1053: * @return The current position index. > > Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here. Thanks for pointing out the inconsistency. I have fixed it. (I noticed many violations of the official Javadoc style, but this is not the right pull request to fix them.) ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:04:39 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Oh no what happened ![image](https://user-images.githubusercontent.com/8303399/192155378-4bb439fa-d27a-417d-8a3c-cf7f7329458f.png) src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053: > 1051: * fetch will take place at index 1. > 1052: * > 1053: * @return The current position index. Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From alanb at openjdk.org Sun Sep 25 17:04:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni src/java.base/share/native/libzip/zlib/zlib.h line 756: > 754: If this is done, the old level and strategy will be applied to the data > 755: compressed before deflateParams(), and the new level and strategy will be > 756: applied to the data compressed after deflateParams(). This is an issue for the upstream zlib project, we probably don't want to change it here. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From lancea at openjdk.org Sun Sep 25 17:04:40 2022 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > src/java.base/share/native/libzip/zlib/zlib.h line 756: > >> 754: If this is done, the old level and strategy will be applied to the data >> 755: compressed before deflateParams(), and the new level and strategy will be >> 756: applied to the data compressed after deflateParams(). > > This is an issue for the upstream zlib project, we probably don't want to change it here. Agree. See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 09:55:18 GMT, Lance Andersen wrote: >> src/java.base/share/native/libzip/zlib/zlib.h line 756: >> >>> 754: If this is done, the old level and strategy will be applied to the data >>> 755: compressed before deflateParams(), and the new level and strategy will be >>> 756: applied to the data compressed after deflateParams(). >> >> This is an issue for the upstream zlib project, we probably don't want to change it here. > > Agree. See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos. OK. I backed out the change to zlib. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:23:28 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:23:28 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From archie.cobbs at gmail.com Sun Sep 25 21:02:32 2022 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Sun, 25 Sep 2022 16:02:32 -0500 Subject: 8043179: Lambda expression can mutate final field Message-ID: Hi folks, Hello, I'm new here. As a result of trying to be less of a complainer and more of a problem solver in life, I've decided to try to contribute fixes to some javac bugs that have particularly annoyed me over the years. Unfortunately I already screwed up and submitted my first PR before discovering The OpenJDK Developer's Guide - my apologies. A very handy reference! Now I'm enlightened, and so first I need to backfill and... 2. Socialize your change > > Once the OCA is signed, please restrain your urge to create a PR just a > little while longer. In order to prepare the community for your patch, > please socialize your idea on the relevant mailing lists. > OK let's talk about this bug and this fix. The bug JDK-8043179 is really due to a more general problem with the JLS, which is described in JDK-8043176 : Chapter 16 is missing rules for handling DA/DU analysis of lambda > expressions... To detect assignments to blank final fields, a field is > *never* DU before the lambda body. (The intuition is that the timing of the > body invocation is unknown, so we don't know whether the variable has been > initialized or not.) > That spec bug was fixed a long time ago; now the spec says : > If an expression is a lambda expression, then the following rules apply: > > - > > V is [un]assigned after the expression iff V is [un]assigned before > the expression. > - > > V is definitely assigned before the expression or block that is the > lambda body (?15.27.2 > ) > iff V is definitely assigned before the lambda expression. > > No rule allows V to be definitely unassigned before a lambda body. > This is by design: a variable that was definitely unassigned before the > lambda body may end up being assigned to later on, so we cannot conclude > that the variable will be unassigned when the body is executed. > > I'm not a JLS expert, so I'd appreciate confirmation, but what I think this is in effect saying is that the DA/DU rules for what you can do with instance fields in a lambda are the same as if that lambda were replaced with the equivalent anonymous inner class - which would make perfect sense! Here's an example of the existing discrepancy: import java.util.function.*; public class WhyAreTheseDifferent { final Object obj; final Supplier supplier1 = new Supplier() { @Override public Object get() { return WhyAreTheseDifferent.this.obj; // no error here } }; final Supplier supplier2 = () -> { return this.obj; }; // error here WhyAreTheseDifferent(Object obj) { this.obj = obj; } } If the above interpretation is correct, then the good news is that this is an easy three line fix , which is to ignore instance fields when performing DA/DU analysis, in exactly the same way we do when visiting any normal non-initial-constructor method during flow analysis (see this code in Flow.java ). Thanks for any comments/feedback. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun Sep 25 21:06:32 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Sun, 25 Sep 2022 21:06:32 GMT Subject: RFR: 8043179: Lambda expression can mutate final field [v3] In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: > This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`. > > This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this: > > LambdaFieldInit.java:6: error: variable x might already have been assigned > Runnable r1 = () -> x = "hi"; > ^ > > > This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins). Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Move unit test into a more appropriate subdirectory. - Use /nodynamiccopyright/ for "golden file" test per instructions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10381/files - new: https://git.openjdk.org/jdk/pull/10381/files/47df9c96..6ae0fca3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=01-02 Stats: 54 lines in 4 files changed: 16 ins; 38 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From hannesw at openjdk.org Mon Sep 26 12:36:23 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 26 Sep 2022 12:36:23 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v16] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 22:46:06 GMT, Jonathan Gibbons wrote: >> 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 incrementally with one additional commit since the last revision: > > Update DPrinter I don't know if you want to further discuss inheritability of the new tag, but the code looks good to me. I've also looked at the generated output and it also looks good. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.org/jdk/pull/8439 From joehw at openjdk.org Mon Sep 26 16:16:34 2022 From: joehw at openjdk.org (Joe Wang) Date: Mon, 26 Sep 2022 16:16:34 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni We have discussed several times in the past that we don't touch upstream (in this case, Apache) code unless the change is essential. In general, if you fix a bug in a class, it's fine to fix other non-essential things within the class, such as code styles, javadocs, typos as in this case, etc. Otherwise, I would suggest you contribute such changes to the upstream projects. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Mon Sep 26 16:51:36 2022 From: mernst at openjdk.org (Michael Ernst) Date: Mon, 26 Sep 2022 16:51:36 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Reinstate typos in Apache code that is copied into the JDK - Merge ../jdk-openjdk into typos-typos - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos ------------- Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=01 Stats: 85 lines in 76 files changed: 0 ins; 0 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From joehw at openjdk.org Mon Sep 26 17:04:25 2022 From: joehw at openjdk.org (Joe Wang) Date: Mon, 26 Sep 2022 17:04:25 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Thanks for the update! ------------- PR: https://git.openjdk.org/jdk/pull/10029 From lancea at openjdk.org Mon Sep 26 19:38:20 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 26 Sep 2022 19:38:20 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Thank you for your efforts on the cleaning up these typos I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review. I realize the changes are fairly trivial but this will most likely expedite getting your changes back ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jjg at openjdk.org Mon Sep 26 21:07:23 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 26 Sep 2022 21:07:23 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v16] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 12:32:46 GMT, Hannes Walln?fer wrote: > I don't know if you want to further discuss inheritability of the new tag, but the code looks good to me. I've also looked at the generated output and it also looks good. I think of `@spec` as a highly specialized form of `@see` with the significant side effect of generating an extra summary page. So, I'm happy/OK that the support for inheritability is on a par with `@see`. It's not great, since it will only inherit one tag (!!) and you cannot specify which one, but the code is sufficiently similar so when we fix one (later) we should be able to easily fix the other. ------------- PR: https://git.openjdk.org/jdk/pull/8439 From jjg at openjdk.org Mon Sep 26 21:31:53 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 26 Sep 2022 21:31:53 GMT Subject: Integrated: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) In-Reply-To: References: Message-ID: <1fCLKKNXfUNpMOJeld9cHXB0rPq9I3iGWVJE2TIf5Sg=.e23d4b7c-d1bd-49a0-ad7d-18050c3a20f5@github.com> On Thu, 28 Apr 2022 02:05:47 GMT, Jonathan Gibbons wrote: > 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. This pull request has now been integrated. Changeset: b88ee1ee Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/b88ee1ee22a4ea859f2a7bdf80a12c1d56fe6fd2 Stats: 1536 lines in 42 files changed: 1490 ins; 22 del; 24 mod 6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) Reviewed-by: hannesw ------------- PR: https://git.openjdk.org/jdk/pull/8439 From amaembo at gmail.com Tue Sep 27 10:03:32 2022 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 27 Sep 2022 12:03:32 +0200 Subject: Effectively final local variable cannot be declared as final Message-ID: Hello! Consider the following code: public class Demo { public static void main(String[] args) { for (int i = 0; i < 10; i++) { Runnable r = () -> System.out.println(i); r.run(); break; } } } It can be compiled with javac (version 19), successfully executed and prints 0. As only effectively final locals are allowed to be captured in lambda, I conclude that `i` is effectively final. I also assumed that for every effectively final variable, it's possible to write an explicit `final` modifier. However, this is not the case. The following code fails with the compilation error: public class Demo { public static void main(String[] args) { for (final int i = 0; i < 10; i++) { Runnable r = () -> System.out.println(i); r.run(); break; } } } Demo.java:3: error: cannot assign a value to final variable i for (final int i = 0; i < 10; i++) { ^ 1 error error: compilation failed In my opinion, either both should be accepted or both should be rejected. According to JLS 4.12.4, I'm inclined that both should be rejected: A local variable whose declarator has an initializer (?14.4.2) is effectively final if all of the following are true: - It is not declared final. - It never occurs as the left hand side in an assignment expression (?15.26). (Note that the local variable declarator containing the initializer is not an assignment expression.) - It never occurs as the operand of a prefix or postfix increment or decrement operator (?15.14, ?15.15). Here, `i` has an initializer and also occurs as the operand of prefix increment, so it cannot be effectively final. What do you think? With best regards, Tagir Valeev. From sundararajan.athijegannathan at oracle.com Tue Sep 27 13:22:36 2022 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 27 Sep 2022 13:22:36 +0000 Subject: Effectively final local variable cannot be declared as final Message-ID: Hi, Thanks for reporting this issue. Filed https://bugs.openjdk.org/browse/JDK-8294461 PS. This is in response to https://mail.openjdk.org/pipermail/compiler-dev/2022-September/020481.html -Sundar -------------- next part -------------- An HTML attachment was scrubbed... URL: From vromero at openjdk.org Tue Sep 27 19:36:39 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 27 Sep 2022 19:36:39 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 718: > 716: Assert.checkNonNull(commonBinding); > 717: Assert.checkNonNull(commonNestedExpression); > 718: Assert.checkNonNull(commonNestedBinding); nit: consider folding these three assertion checks into one. ------------- PR: https://git.openjdk.org/jdk/pull/9746 From vromero at openjdk.org Tue Sep 27 20:32:28 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 27 Sep 2022 20:32:28 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved not strictly related to this patch but for this code: record Box(Object o) {} class Test { private int test(Object obj) { return switch (obj) { case Box(String s) -> 0; case Box(Integer i) -> 0; case Box(Number n) -> 0; case Box(CharSequence cs) -> 0; default -> -1; }; } } after compiling it without the preview options set as in: `javac Test.java`, javac issues two errors in the same line: Test.java:6: error: patterns in switch statements are a preview feature and are disabled by default. case Box(String s) -> 0; ^ (use --enable-preview to enable patterns in switch statements) Test.java:6: error: deconstruction patterns are a preview feature and are disabled by default. case Box(String s) -> 0; ^ (use --enable-preview to enable deconstruction patterns) 2 errors ------------- PR: https://git.openjdk.org/jdk/pull/9746 From vromero at openjdk.org Tue Sep 27 20:41:27 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 27 Sep 2022 20:41:27 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 403: > 401: ? syms.objectType > 402: : selector.type; > 403: Assert.check(preview.isEnabled()); side: not part of your patch but, do we need to check if preview is enabled at this point? ------------- PR: https://git.openjdk.org/jdk/pull/9746 From maurizio.cimadamore at oracle.com Tue Sep 27 21:25:29 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 27 Sep 2022 22:25:29 +0100 Subject: Effectively final local variable cannot be declared as final In-Reply-To: References: Message-ID: Hi Tagir, I believe this is a bug in how the compiler determines effective finality. Javac does this while computing DA/DU. This is because locals that are assigned "at most once" are considered effectively final (as per the JLS). In the case of for loop, the DA/DU logic is tripping us up: when we see the initializer of "i" in the for loop, we know that "i" is DA and not DU. But then we scan the loop body, and there's a break. And, per JLS, after a break, any variable is both DA and DU. In other words, the DA/DU status is reset. That means that, by the time we reach "i++", javac thinks it's an assignment to a variable that is still DU, so the assignment will not make the variable lose its effectively final status. In a way, what the compiler does is correct - the variable is assigned only once, and can only have value 0, but I agree that there's an inconsistency with the JLS and, more broadly, with what happens if you add an explicit "final". There is also some code in Flow to deal with assignment of "final" variables in loop, for instance in cases like this: ``` final int x; for (int i = 0; i < 10 ; i++) { ?? x = 2; // error: variable might be assigned in loop } ``` And the logic is exactly the same as the one we use for effectively final. But variables declared as `final` also gets an extra check in an earlier compiler pass (Attr), which simply looks at assignments, and if the target of the assignment is final, then it reports an error (and that's where the discrepancy comes from). It looks like the javac logic based on DA/DU should be dialled back a bit to only be applied in cases when the variable doesn't have an initializer. Thanks Maurizio On 27/09/2022 11:03, Tagir Valeev wrote: > Hello! > > Consider the following code: > > public class Demo { > public static void main(String[] args) { > for (int i = 0; i < 10; i++) { > Runnable r = () -> System.out.println(i); > r.run(); > break; > } > } > } > > It can be compiled with javac (version 19), successfully executed and > prints 0. As only effectively final locals are allowed to be captured > in lambda, I conclude that `i` is effectively final. I also assumed > that for every effectively final variable, it's possible to write an > explicit `final` modifier. However, this is not the case. The > following code fails with the compilation error: > > public class Demo { > public static void main(String[] args) { > for (final int i = 0; i < 10; i++) { > Runnable r = () -> System.out.println(i); > r.run(); > break; > } > } > } > Demo.java:3: error: cannot assign a value to final variable i > for (final int i = 0; i < 10; i++) { > ^ > 1 error > error: compilation failed > > In my opinion, either both should be accepted or both should be > rejected. According to JLS 4.12.4, I'm inclined that both should be > rejected: > > A local variable whose declarator has an initializer (?14.4.2) is > effectively final if all of the following are true: > - It is not declared final. > - It never occurs as the left hand side in an assignment expression > (?15.26). (Note that the local variable declarator containing the > initializer is not an assignment expression.) > - It never occurs as the operand of a prefix or postfix increment or > decrement operator (?15.14, ?15.15). > > Here, `i` has an initializer and also occurs as the operand of prefix > increment, so it cannot be effectively final. > > What do you think? > > With best regards, > Tagir Valeev. From vromero at openjdk.org Tue Sep 27 23:05:19 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 27 Sep 2022 23:05:19 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved another side comment but given that we are retouching this code, I'm seeing that TransPatterns is a phase that is run always regardless of the presence or not of patterns. Shouldn't we do something similar as for LambdaToMethod that is executed only if there are lambdas? Of course there is no need to address this as part of this patch ------------- PR: https://git.openjdk.org/jdk/pull/9746 From mernst at openjdk.org Tue Sep 27 23:16:16 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Sep 2022 23:16:16 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> References: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> Message-ID: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> On Mon, 26 Sep 2022 19:36:02 GMT, Lance Andersen wrote: > Thank you for your efforts on the cleaning up these typos > > I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review. > > I realize the changes are fairly trivial but this will most likely expedite getting your changes back Feel free to break up the pull request if that is what is needed to free it from red tape. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From vromero at openjdk.org Tue Sep 27 23:42:21 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 27 Sep 2022 23:42:21 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: References: Message-ID: <5wmYANFtMHXPXR2oHon2AeKw8JSG2Adp6NEFMBpnoyc=.fe9329d9-bbe3-411f-87a7-615770c319dd@github.com> On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 369: > 367: nestedPatterns = nestedPatterns.tail; > 368: } > 369: Assert.check(components.isEmpty() == nestedPatterns.isEmpty()); is it possible for this assertion not to hold under some conditions? can it be removed? ------------- PR: https://git.openjdk.org/jdk/pull/9746 From vromero at openjdk.org Wed Sep 28 01:04:44 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 28 Sep 2022 01:04:44 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 790: > 788: > 789: if (c.head.labels.size() == 1 && > 790: c.head.labels.head instanceof JCPatternCaseLabel patternLabel && nit: (c.head.labels.size() == 1 && c.head.labels.head instanceof JCPatternCaseLabel patternLabel) seems to be a common condition that could be evaluated twice in this `if` and in the one in the `else if` below, consider evaluating it only once ------------- PR: https://git.openjdk.org/jdk/pull/9746 From vromero at openjdk.org Wed Sep 28 03:03:43 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 28 Sep 2022 03:03:43 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 819: > 817: } > 818: } else if (currentBinding != null && > 819: commonBinding.type.tsym == currentBinding.type.tsym && question, what about having a map relating commonBindings and accumulators, shouldn't this allow you to group common patterns even if they are not consecutive? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 648: > 646: result = > 647: scan(tree.mods, that.mods) > 648: && (tree.name == that.name || synthetic) I think that considering two variables equal if one is synthetic should be something that probably shouldn't occur by default, IMO there should be a way for clients of `TreeDiffer` to op-in if they want this behavior ------------- PR: https://git.openjdk.org/jdk/pull/9746 From dfuchs at openjdk.org Wed Sep 28 13:24:26 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 28 Sep 2022 13:24:26 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> References: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> Message-ID: On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst wrote: > Feel free to break up the pull request if that is what is needed to free it from red tape. Only you can do that @mernst ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Wed Sep 28 14:49:20 2022 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 28 Sep 2022 14:49:20 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Regarding breaking up the pull request: * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape. * I have spent a nontrivial amount of time on these fixes. There have been long delays, which forced me to resolve merge conflicts. I was told that the changes are "mostly fine" without any indication of what is wrong. I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted. * No one has explained what to do. "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is. I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to corrections. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From dfuchs at openjdk.org Wed Sep 28 15:13:39 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 28 Sep 2022 15:13:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst wrote: >> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk into typos-typos >> - Remove file that was removed upstream >> - Fix inconsistency in capitalization >> - Undo change in zlip >> - Fix typos > > Regarding breaking up the pull request: > * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape. > * Despite my repeated requests, no one has justified that *this particular pull request* needs the expertise of different teams. The only reasons stated have been custom and bureaucracy. > * I have spent a nontrivial amount of time on these fixes. There have been long delays, which forced me to resolve merge conflicts. I was told that the changes are "mostly fine" without any indication of what is wrong. I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted. > * I was condescendingly told "We have discussed several times in the past ..." even though I was not privy to those discussions. No pointer to documentation in the JDK itself, about pull requests, was given. > * No one has explained what to do. "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is. > > I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to contributions. Hi @mernst, sorry if this is how it appears. Pull requests that involve changes spanning a large set of files are notoriously harder to review since they require a reviewer from each different area to chime in. Basically you will need one reviewer from each of these areas: - client - compiler - core-libs - hotspot - i18n - javadoc - jmx - net - nio - security - serviceability Jaikiran suggested to reduce the scope of this PR in his first comment: https://github.com/openjdk/jdk/pull/10029#issuecomment-1236588632 as did several other reviewers. Sorry if the meaning (or reason) was not clear. best regards, ------------- PR: https://git.openjdk.org/jdk/pull/10029 From aivanov at openjdk.org Wed Sep 28 15:28:24 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Sep 2022 15:28:24 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Wed Sep 28 15:35:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 28 Sep 2022 15:35:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 15:26:13 GMT, Alexey Ivanov wrote: > The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`. The title was edited by someone other than me, as you can see from the PR history. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Wed Sep 28 16:45:10 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 28 Sep 2022 16:45:10 GMT Subject: RFR: 8043179: Lambda expression can mutate final field [v4] In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: > This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`. > > This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this: > > LambdaFieldInit.java:6: error: variable x might already have been assigned > Runnable r1 = () -> x = "hi"; > ^ > > > This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins). Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Fix @author in test to match github username per instructions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10381/files - new: https://git.openjdk.org/jdk/pull/10381/files/6ae0fca3..b7bc0b6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From jjg at openjdk.org Wed Sep 28 22:45:32 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 28 Sep 2022 22:45:32 GMT Subject: RFR: JDK-8293877: Rewrite MineField test In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 19:20:38 GMT, Martin Buchholz wrote: > Explicit OS command invocation and ToolProvider invocation both seem important to test. IIRC there were times when they were not in fact equivalent in effect. Consider library infrastructure to run both variants and ensure results are identical. > @Martin-Buchholz Thanks for the feedback. While I understand what you are suggesting, I think it is potentially for a different test. The goal here was to try and do a reasonably direct translation of the original code from shell to Java. And OK, I did do some minor optimizations to use javac's `ToolProvider` where possible, to save exec-ing processes unnecessarily. Rewriting the test to do both (where that is even possible) would either be a significant rewrite or maybe involve running all of the test twice, in both modes. And, for javac, it might be even worse, because there is the `javax.tools.JavaCompiler` API as well. There is no reason to suspect the functionality might be semantically different in these different ways to invoke javac. Once you get down into the compiler, the code paths are the same. The difference is the _availability_ of features ... such as the _classpath wildcard_ feature, which is only available when using the native launcher. So, if we were to write anything more in the way of tests, it would be to test the specified difference in availability of the features, without necessarily exercising the full functionality and comparing everything against the launcher for the Java runtime, `java`. One other outcome from the overall work here: as a result of (re)discovering the _classpath wildcard_ feature, we realized that there were enough differences between the native launcher and the `ToolProvider` interface (and `JavaCompiler`) to justify a spec update for the `idk.compiler` module. This is being tracked in [JDK-8294546](https://bugs.openjdk.org/browse/JDK-8294546). ------------- PR: https://git.openjdk.org/jdk/pull/10366 From jlahoda at openjdk.org Thu Sep 29 14:29:58 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 29 Sep 2022 14:29:58 GMT Subject: RFR: 8294550: Sealed check for casts isn't applied to array components Message-ID: For code like: sealed interface I permits A {} final class A implements I {} interface J {} J j = null; I i = (I) j; //error reported here, as no instance of J can implement I J[] jj = null; I[] i = (I[]) jj; //incorrectly no error reported here, despite JLS saying there must be a narrowing conversion from J to I in this case, which there isn't as per the case above The cause for this is that we check the sealed constraints at the end of `Types.isCastable`, and only for classes, not for arrays. It would be possible to enhance the check to include array types, but feels clearer and more reliable to recurse, and do a full castability check on the element types. A sketch of a CSR is here: https://bugs.openjdk.org/browse/JDK-8294586 Feedback is welcome! ------------- Commit messages: - 8294550: Sealed check for casts isn't applied to array components Changes: https://git.openjdk.org/jdk/pull/10490/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10490&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294550 Stats: 26 lines in 2 files changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10490.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10490/head:pull/10490 PR: https://git.openjdk.org/jdk/pull/10490 From archie.cobbs at gmail.com Thu Sep 29 17:54:06 2022 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 29 Sep 2022 12:54:06 -0500 Subject: 8043179: Lambda expression can mutate final field In-Reply-To: References: Message-ID: Hi folks, On Sun, Sep 25, 2022 at 4:02 PM Archie Cobbs wrote: > then the good news is that this is an easy three line fix > > I'm still looking for any thoughts or comments on this proposed fix for 8043179. I'm also looking for someone who is willing to consider being a sponsor for me. I've got this PR and a couple of other fixes in the hopper. In return I promise to be a good listener and hopefully a net positive contributor. Also, I have a question - is anyone else having trouble building the JDK on macos 12.6 and Xcode 14.0? I'm getting two build failures in the latest code jdk-20+17-23-g0d8e3ce6b6e, one in GTest and one in JniInvocationTest. The GTest build errors start like this: Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s) In file included from /Users/archie/proj/googletest/ googlemock/src/gmock-all.cc:39: In file included from /Users/archie/proj/googletest/ googlemock/include/gmock/gmock.h:59: /Users/archie/proj/googletest/googlemock/include/gmock/gmock-actions.h:484:3: error: definition of implicit copy constructor for 'PolymorphicAction' is deprecated because it has a user-declared copy assignment operator [-Werror,-Wdeprecated-copy] GTEST_DISALLOW_ASSIGN_(PolymorphicAction); ^ /Users/archie/proj/googletest/googletest/include/gtest/internal/gtest-port.h:928:8: note: expanded from macro 'GTEST_DISALLOW_ASSIGN_' void operator=(type const &) GTEST_CXX11_EQUALS_DELETE_ ^ /Users/archie/proj/googletest/googlemock/include/gmock/gmock-actions.h:1125:10: note: in implicit copy constructor for 'testing::PolymorphicAction< testing::internal::ReturnNullAction>' first required here return MakePolymorphicAction(internal::ReturnNullAction()); ^ These are the JniInvocationTest errors: Creating support/test/jdk/jtreg/native/bin/JniInvocationTest from 1 file(s) /Users/archie/proj/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag) ^ /Users/archie/proj/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag) ^ 2 errors generated. The latter error is easy to workaround. I haven't tried fixing the former. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Fri Sep 30 00:40:24 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 00:40:24 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org Message-ID: With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. Updates were made using a shell script. I"ll run a copyright updater before any push. ------------- Commit messages: - JDK-8294618: Update openjdk.java.net => openjdk.org Changes: https://git.openjdk.org/jdk/pull/10501/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294618 Stats: 79 lines in 39 files changed: 0 ins; 0 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 00:54:05 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 00:54:05 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2] In-Reply-To: References: Message-ID: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Update copyright. - Revert unintended update to binary file. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/b12d774f..2f257762 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00-01 Stats: 10 lines in 11 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From mikael at openjdk.org Fri Sep 30 00:54:08 2022 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 30 Sep 2022 00:54:08 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy wrote: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Switch to https where needed/applicable while at it? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From mikael at openjdk.org Fri Sep 30 00:54:06 2022 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 30 Sep 2022 00:54:06 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2] In-Reply-To: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> References: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> Message-ID: On Fri, 30 Sep 2022 00:50:13 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright. > - Revert unintended update to binary file. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:01:29 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:01:29 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v3] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Undo manpage update. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/2f257762..04dfc3ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:11:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:11:45 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: http -> https ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/04dfc3ef..cee96d0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02-03 Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:11:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:11:45 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 00:48:02 GMT, Mikael Vidstedt wrote: > Switch to https where needed/applicable while at it? Good idea; might as well do the update in a single changeset. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From iris at openjdk.org Fri Sep 30 04:11:19 2022 From: iris at openjdk.org (Iris Clark) Date: Fri, 30 Sep 2022 04:11:19 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https Marked as reviewed by iris (Reviewer). src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > 32: * the following link: > 33: * > 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c The domain for hg wasn't changed to openjdk.org. The original URL is correct. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From jlahoda at openjdk.org Fri Sep 30 12:21:58 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 30 Sep 2022 12:21:58 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v7] In-Reply-To: References: Message-ID: > 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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Reflecting review feedback. - Merge branch 'master' into JDK-8291769 - Merge branch 'master' into JDK-8291769 - Merge branch 'master' into JDK-8291769 - Reflecting review feedback. - Merge branch 'master' into JDK-8291769 - Using a custom record instead of a generic Pair. - Fixing test. - Properly handle null record components. - 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=06 Stats: 1458 lines in 13 files changed: 1277 ins; 83 del; 98 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 jlahoda at openjdk.org Fri Sep 30 12:26:24 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 30 Sep 2022 12:26:24 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v7] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 12:21:58 GMT, Jan Lahoda 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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved Thanks for all the comments! I've reflected the feedback here: https://github.com/openjdk/jdk/pull/9746/commits/4f9f7f9859c98f6312675455bdfa02f02b0015c7 and added additional comments. ------------- PR: https://git.openjdk.org/jdk/pull/9746 From jlahoda at openjdk.org Fri Sep 30 12:26:27 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 30 Sep 2022 12:26:27 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: <5wmYANFtMHXPXR2oHon2AeKw8JSG2Adp6NEFMBpnoyc=.fe9329d9-bbe3-411f-87a7-615770c319dd@github.com> References: <5wmYANFtMHXPXR2oHon2AeKw8JSG2Adp6NEFMBpnoyc=.fe9329d9-bbe3-411f-87a7-615770c319dd@github.com> Message-ID: <_fgFAvWJj_xpfQAVG1AWxKviTm7mzyy2N43gFagAPHs=.3ee0a962-a0cf-4cb0-811d-a56b08a18073@github.com> On Tue, 27 Sep 2022 23:40:12 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'master' into JDK-8291769 >> - Merge branch 'master' into JDK-8291769 >> - Reflecting review feedback. >> - Merge branch 'master' into JDK-8291769 >> - Using a custom record instead of a generic Pair. >> - Fixing test. >> - Properly handle null record components. >> - 8291769: Translation of switch with record patterns could be improved > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 369: > >> 367: nestedPatterns = nestedPatterns.tail; >> 368: } >> 369: Assert.check(components.isEmpty() == nestedPatterns.isEmpty()); > > is it possible for this assertion not to hold under some conditions? can it be removed? This is mostly to ensure that if there would be a bug in `Attr` that would not produce an error in case the number of record components, and the number of nested patterns would not match, javac will fail consistently. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 403: > >> 401: ? syms.objectType >> 402: : selector.type; >> 403: Assert.check(preview.isEnabled()); > > side: not part of your patch but, do we need to check if preview is enabled at this point? The ordinary checks should have happened in the parser and/or `Attr`, this is mostly s safeguard in case some of the checks would be missing for any reason. ------------- PR: https://git.openjdk.org/jdk/pull/9746 From jlahoda at openjdk.org Fri Sep 30 12:33:31 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 30 Sep 2022 12:33:31 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: References: Message-ID: <0ZmUt3AJoNdEPvMML_-HCaruEBJ0YbRhDltKr2ASH5g=.5cc148f0-a115-4aef-a54b-f510dadbf86f@github.com> On Wed, 28 Sep 2022 03:00:28 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'master' into JDK-8291769 >> - Merge branch 'master' into JDK-8291769 >> - Reflecting review feedback. >> - Merge branch 'master' into JDK-8291769 >> - Using a custom record instead of a generic Pair. >> - Fixing test. >> - Properly handle null record components. >> - 8291769: Translation of switch with record patterns could be improved > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 819: > >> 817: } >> 818: } else if (currentBinding != null && >> 819: commonBinding.type.tsym == currentBinding.type.tsym && > > question, what about having a map relating commonBindings and accumulators, shouldn't this allow you to group common patterns even if they are not consecutive? This would mean we would change the order of the cases, which is something I'd like to avoid in this patch, for several reasons. Partly because there's a fairly big set of cases where it is unclear if we can do the reordering (and the exact rules when we can do reordering are debatable, and sometimes depend on very particular aspects of the spec), and partly because this patch seems complex enough without reordering. One possibility we could do case reordering as a separate step before coalescing the prefixes, as simple use of map would not necessarily allow to avoid coalescing in cases like: switch (o) { case I1 i when -> {} case I2 i when -> {} case I1 i when -> {} } (where `I1` and `I2` are unrelated interfaces, we cannot easily change the order of the cases here, as `o` may be an object that implements both, and `` might be `false`). ------------- PR: https://git.openjdk.org/jdk/pull/9746 From ihse at openjdk.org Fri Sep 30 14:01:18 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 30 Sep 2022 14:01:18 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https $ grep -rl doc make -e openjdk.java.net doc/hotspot-unit-tests.html doc/hotspot-style.html doc/building.html doc/hotspot-unit-tests.md doc/hotspot-style.md doc/building.md make/Doctor.gmk make/jdk/src/classes/build/tools/taglet/Incubating.java make/autoconf/configure.ac make/conf/branding.conf Think you can fix those as well? Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From weijun at openjdk.org Fri Sep 30 14:18:28 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 30 Sep 2022 14:18:28 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> http -> https > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > >> 32: * the following link: >> 33: * >> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c > > The domain for hg wasn't changed to openjdk.org. The original URL is correct. Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From vromero at openjdk.org Fri Sep 30 15:19:23 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 30 Sep 2022 15:19:23 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v6] In-Reply-To: <0ZmUt3AJoNdEPvMML_-HCaruEBJ0YbRhDltKr2ASH5g=.5cc148f0-a115-4aef-a54b-f510dadbf86f@github.com> References: <0ZmUt3AJoNdEPvMML_-HCaruEBJ0YbRhDltKr2ASH5g=.5cc148f0-a115-4aef-a54b-f510dadbf86f@github.com> Message-ID: On Fri, 30 Sep 2022 12:31:09 GMT, Jan Lahoda wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 819: >> >>> 817: } >>> 818: } else if (currentBinding != null && >>> 819: commonBinding.type.tsym == currentBinding.type.tsym && >> >> question, what about having a map relating commonBindings and accumulators, shouldn't this allow you to group common patterns even if they are not consecutive? > > This would mean we would change the order of the cases, which is something I'd like to avoid in this patch, for several reasons. Partly because there's a fairly big set of cases where it is unclear if we can do the reordering (and the exact rules when we can do reordering are debatable, and sometimes depend on very particular aspects of the spec), and partly because this patch seems complex enough without reordering. > > One possibility we could do case reordering as a separate step before coalescing the prefixes, as simple use of map would not necessarily allow to avoid coalescing in cases like: > > switch (o) { > case I1 i when -> {} > case I2 i when -> {} > case I1 i when -> {} > } > > (where `I1` and `I2` are unrelated interfaces, we cannot easily change the order of the cases here, as `o` may be an object that implements both, and `` might be `false`). got it I agree, thanks ------------- PR: https://git.openjdk.org/jdk/pull/9746 From vromero at openjdk.org Fri Sep 30 15:27:34 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 30 Sep 2022 15:27:34 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v7] In-Reply-To: References: Message-ID: <8T5xnwzlgKq6moiq676hwAtxQjuUrKtMbUlkXYjLvig=.005b7697-825f-4e22-8d61-63474d2df2fa@github.com> On Fri, 30 Sep 2022 12:21:58 GMT, Jan Lahoda 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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/9746 From vromero at openjdk.org Fri Sep 30 16:30:30 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 30 Sep 2022 16:30:30 GMT Subject: RFR: 8294550: Sealed check for casts isn't applied to array components In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 14:24:18 GMT, Jan Lahoda wrote: > For code like: > > sealed interface I permits A {} > final class A implements I {} > interface J {} > > J j = null; > I i = (I) j; //error reported here, as no instance of J can implement I > J[] jj = null; > I[] i = (I[]) jj; //incorrectly no error reported here, despite JLS saying there must be a narrowing conversion from J to I in this case, which there isn't as per the case above > > > The cause for this is that we check the sealed constraints at the end of `Types.isCastable`, and only for classes, not for arrays. It would be possible to enhance the check to include array types, but feels clearer and more reliable to recurse, and do a full castability check on the element types. > > A sketch of a CSR is here: > https://bugs.openjdk.org/browse/JDK-8294586 > > Feedback is welcome! looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10490 From prr at openjdk.org Fri Sep 30 17:42:29 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Sep 2022 17:42:29 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 14:16:24 GMT, Weijun Wang wrote: >> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: >> >>> 32: * the following link: >>> 33: * >>> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c >> >> The domain for hg wasn't changed to openjdk.org. The original URL is correct. > > Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../" ------------- PR: https://git.openjdk.org/jdk/pull/10501 From joehw at openjdk.org Fri Sep 30 18:12:25 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 30 Sep 2022 18:12:25 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https The ones in java.xml look good to me. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk/pull/10501 From vromero at openjdk.org Fri Sep 30 18:38:16 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 30 Sep 2022 18:38:16 GMT Subject: RFR: JDK-8293877: Rewrite MineField test In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 00:57:22 GMT, Jonathan Gibbons wrote: > Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. > > This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. > > The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. > > Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. > > The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. > > Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. > > On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. > > Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. > > The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. > > Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. > > Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. test/langtools/tools/javac/Paths/ClassPath.java line 130: > 128: > 129: /* > 130: * The following lines are commented out in the original, I think these old comments could be removed ------------- PR: https://git.openjdk.org/jdk/pull/10366 From darcy at openjdk.org Fri Sep 30 20:29:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:20 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v5] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. 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 seven additional commits since the last revision: - Update hg URLs to git. - Merge branch 'master' into JDK-8294618 - http -> https - Undo manpage update. - Update copyright. - Revert unintended update to binary file. - JDK-8294618: Update openjdk.java.net => openjdk.org ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/cee96d0a..fbaf3d4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03-04 Stats: 2670 lines in 133 files changed: 1729 ins; 406 del; 535 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:21 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:21 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 13:59:12 GMT, Magnus Ihse Bursie wrote: > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..? Yes; I think it is sufficient to update src and doc with this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:22 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:22 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race wrote: > This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../" Update to persistent git links. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From vromero at openjdk.org Fri Sep 30 23:42:40 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 30 Sep 2022 23:42:40 GMT Subject: RFR: JDK-8293877: Rewrite MineField test In-Reply-To: References: Message-ID: <1aVIGSEHuoo2Xs72rAzd6djwF9Lo4RUW4eNIOyAhD50=.53af99b6-f96e-414c-b03d-c40bf8af7547@github.com> On Wed, 21 Sep 2022 00:57:22 GMT, Jonathan Gibbons wrote: > Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. > > This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. > > The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. > > Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. > > The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. > > Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. > > On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. > > Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. > > The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. > > Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. > > Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. I have gone through all the changes, I think semantically the original tests have been preserved as closed as possible. After a first review iteration I think it could make sense to clean up a bit an remove dead code etc ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10366 From joe.darcy at oracle.com Fri Sep 30 04:41:12 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 30 Sep 2022 04:41:12 -0000 Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: <857259f1-daa2-46a0-ded8-24d866482707@oracle.com> Thanks for catching that Iris; I'll changes those to git URLs. -Joe On 9/29/2022 9:11 PM, Iris Clark wrote: > On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: > >>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >>> >>> Updates were made using a shell script. I"ll run a copyright updater before any push. >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> http -> https > Marked as reviewed by iris (Reviewer). > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > >> 32: * the following link: >> 33: * >> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c > The domain for hg wasn't changed to openjdk.org. The original URL is correct. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/10501