Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)
On Sat, 10 Apr 2021 14:13:55 GMT, Vladimir Sitnikov wrote: >> With the introduction of `toList()`, preserving the SIZED characteristics in >> more cases becomes more important. This patch preserves SIZED on `skip()` >> and `limit()` operations, so now every combination of >> `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and >> `toList()`, `toArray()` and `count()` may benefit from this. E. g., >> `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result >> instantly with this patch. >> >> Some microbenchmarks added that confirm the reduced memory allocation in >> `toList()` and `toArray()` cases. Before patch: >> ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 >> thrpt 10 40235,534 ± 0,984B/op >> ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 >> thrpt 10 106431,101 ± 0,198B/op >> ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 >> thrpt 10 106544,977 ± 1,983B/op >> value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 >> thrpt 10 40121,878 ± 0,247B/op >> value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 >> thrpt 10 106317,693 ± 1,083B/op >> value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 >> thrpt 10 106430,954 ± 0,136B/op >> >> After patch: >> ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 >> thrpt 10 40235,648 ± 1,354B/op >> ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 >> thrpt 10 40355,784 ± 1,288B/op >> ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 >> thrpt 10 40476,032 ± 2,855B/op >> value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 >> thrpt 10 40121,830 ± 0,308B/op >> value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 >> thrpt 10 40242,554 ± 0,443B/op >> value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 >> thrpt 10 40363,674 ± 1,576B/op >> >> Time improvements are less exciting. It's likely that inlining and >> vectorizing dominate in these tests over array allocations and unnecessary >> copying. Still, I notice a significant improvement in SliceToArray.seq_limit >> case (2x) and mild improvement (+12..16%) in other slice tests. No >> significant change in parallel execution time, though its performance is >> much less stable and I didn't run enough tests. >> >> Before patch: >> Benchmark (size) Mode Cnt Score Error >> Units >> ref.SliceToList.par_baseline 1 thrpt 30 14876,723 ± 99,770 >> ops/s >> ref.SliceToList.par_limit 1 thrpt 30 14856,841 ± 215,089 >> ops/s >> ref.SliceToList.par_skipLimit 1 thrpt 30 9555,818 ± 991,335 >> ops/s >> ref.SliceToList.seq_baseline 1 thrpt 30 23732,290 ± 444,162 >> ops/s >> ref.SliceToList.seq_limit 1 thrpt 30 14894,040 ± 176,496 >> ops/s >> ref.SliceToList.seq_skipLimit 1 thrpt 30 10646,929 ± 36,469 >> ops/s >> value.SliceToArray.par_baseline1 thrpt 30 25093,141 ± 376,402 >> ops/s >> value.SliceToArray.par_limit 1 thrpt 30 24798,889 ± 760,762 >> ops/s >> value.SliceToArray.par_skipLimit 1 thrpt 30 16456,310 ± 926,882 >> ops/s >> value.SliceToArray.seq_baseline1 thrpt 30 69669,787 ± 494,562 >> ops/s >> value.SliceToArray.seq_limit 1 thrpt 30 21097,081 ± 117,338 >> ops/s >> value.SliceToArray.seq_skipLimit 1 thrpt 30 15522,871 ± 112,557 >> ops/s >> >> After patch: >> Benchmark (size) Mode Cnt Score Error >> Units >> ref.SliceToList.par_baseline 1 thrpt 30 14793,373 ± 64,905 >> ops/s >> ref.SliceToList.par_limit 1 thrpt 30 13301,024 ± 1300,431 >> ops/s >> ref.SliceToList.par_skipLimit 1 thrpt 30 11131,698 ± 1769,932 >> ops/s >> ref.SliceToList.seq_baseline 1 thrpt 30 24101,048 ± 263,528 >> ops/s >> ref.SliceToList.seq_limit 1 thrpt 30 16872,168 ± 76,696 >> ops/s >> ref.SliceToList.seq_skipLimit 1 thrpt 30 11953,253 ± 105,231 >> ops/s >> value.SliceToArray.par_baseline1 thrpt 30 25442,442 ± 455,554 >> ops/s >> value.SliceToArray.par_limit 1 thrpt 30 23111,730 ± 2246,086 >> ops/s >> value.SliceToArray.par_skipLimit 1 thrpt 30 17980,750 ± 2329,077 >> ops/s >> value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 >> ops/s >> value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 >> ops/s >> value.SliceToArray.seq_skipLimit 1 thrpt 30 18007,613 ± 141,716 >> ops/s >> >> I also modernized SliceOps a little bit, u
Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)
On Sat, 10 Apr 2021 14:10:21 GMT, Vladimir Sitnikov wrote: >> With the introduction of `toList()`, preserving the SIZED characteristics in >> more cases becomes more important. This patch preserves SIZED on `skip()` >> and `limit()` operations, so now every combination of >> `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and >> `toList()`, `toArray()` and `count()` may benefit from this. E. g., >> `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result >> instantly with this patch. >> >> Some microbenchmarks added that confirm the reduced memory allocation in >> `toList()` and `toArray()` cases. Before patch: >> ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 >> thrpt 10 40235,534 ± 0,984B/op >> ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 >> thrpt 10 106431,101 ± 0,198B/op >> ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 >> thrpt 10 106544,977 ± 1,983B/op >> value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 >> thrpt 10 40121,878 ± 0,247B/op >> value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 >> thrpt 10 106317,693 ± 1,083B/op >> value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 >> thrpt 10 106430,954 ± 0,136B/op >> >> After patch: >> ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 >> thrpt 10 40235,648 ± 1,354B/op >> ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 >> thrpt 10 40355,784 ± 1,288B/op >> ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 >> thrpt 10 40476,032 ± 2,855B/op >> value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 >> thrpt 10 40121,830 ± 0,308B/op >> value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 >> thrpt 10 40242,554 ± 0,443B/op >> value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 >> thrpt 10 40363,674 ± 1,576B/op >> >> Time improvements are less exciting. It's likely that inlining and >> vectorizing dominate in these tests over array allocations and unnecessary >> copying. Still, I notice a significant improvement in SliceToArray.seq_limit >> case (2x) and mild improvement (+12..16%) in other slice tests. No >> significant change in parallel execution time, though its performance is >> much less stable and I didn't run enough tests. >> >> Before patch: >> Benchmark (size) Mode Cnt Score Error >> Units >> ref.SliceToList.par_baseline 1 thrpt 30 14876,723 ± 99,770 >> ops/s >> ref.SliceToList.par_limit 1 thrpt 30 14856,841 ± 215,089 >> ops/s >> ref.SliceToList.par_skipLimit 1 thrpt 30 9555,818 ± 991,335 >> ops/s >> ref.SliceToList.seq_baseline 1 thrpt 30 23732,290 ± 444,162 >> ops/s >> ref.SliceToList.seq_limit 1 thrpt 30 14894,040 ± 176,496 >> ops/s >> ref.SliceToList.seq_skipLimit 1 thrpt 30 10646,929 ± 36,469 >> ops/s >> value.SliceToArray.par_baseline1 thrpt 30 25093,141 ± 376,402 >> ops/s >> value.SliceToArray.par_limit 1 thrpt 30 24798,889 ± 760,762 >> ops/s >> value.SliceToArray.par_skipLimit 1 thrpt 30 16456,310 ± 926,882 >> ops/s >> value.SliceToArray.seq_baseline1 thrpt 30 69669,787 ± 494,562 >> ops/s >> value.SliceToArray.seq_limit 1 thrpt 30 21097,081 ± 117,338 >> ops/s >> value.SliceToArray.seq_skipLimit 1 thrpt 30 15522,871 ± 112,557 >> ops/s >> >> After patch: >> Benchmark (size) Mode Cnt Score Error >> Units >> ref.SliceToList.par_baseline 1 thrpt 30 14793,373 ± 64,905 >> ops/s >> ref.SliceToList.par_limit 1 thrpt 30 13301,024 ± 1300,431 >> ops/s >> ref.SliceToList.par_skipLimit 1 thrpt 30 11131,698 ± 1769,932 >> ops/s >> ref.SliceToList.seq_baseline 1 thrpt 30 24101,048 ± 263,528 >> ops/s >> ref.SliceToList.seq_limit 1 thrpt 30 16872,168 ± 76,696 >> ops/s >> ref.SliceToList.seq_skipLimit 1 thrpt 30 11953,253 ± 105,231 >> ops/s >> value.SliceToArray.par_baseline1 thrpt 30 25442,442 ± 455,554 >> ops/s >> value.SliceToArray.par_limit 1 thrpt 30 23111,730 ± 2246,086 >> ops/s >> value.SliceToArray.par_skipLimit 1 thrpt 30 17980,750 ± 2329,077 >> ops/s >> value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 >> ops/s >> value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 >> ops/s >> value.SliceToArray.seq_skipLimit 1 thrpt 30 18007,613 ± 141,716 >> ops/s >> >> I also modernized SliceOps a little bit, u
Re: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v3]
On Thu, 8 Apr 2021 08:54:06 GMT, Alan Bateman wrote: >> Dear All, >> May I ask your help to review this change? Thanks! >> >> BRs, >> Lin > >> Dear All, >> May I ask your help to review this change? Thanks! > > @LanceAndersen Do you have cycles to help Lin? This proposal will require > discussion, they may be case for the header to be a record for example. My > personal view is that the PR should be set aside until there is at least at > least some agreement on the API. Dear @AlanBateman and @LanceAndersen, Thanks a lot for your review and comments! > > We should look to see if it makes sense to use some of the more recent java > features such as Record. > > If we are adding a specific class to hold the header fields, perhaps using > the builder pattern should be considered vs constructors. I agree, we should finalize the API before moving forward. I am not quite fimilar with Record, I will do some investigation, trying to use it in this PR and discuss with you later. > If we are writing out these additional fields, what should we do with them > when reading a gzip file back? IMO, generally there should be check of header crc, and some other checks like the header format, magic number etc. May be we could implement it like the gnu gzip tool, which ingore contents of most header fields but verified the general header info. > Have you looked at other gzip api implementations to see what they provide in > this area? I have looked at the gzip implementation at https://github.com/linzang/gzip/blob/distrotech-gzip/gzip.c#L1281, this method is use to generate header crc value for check. And there is some legal header check in this method. And `file name` is used to save original file name in gzip when it is truncated. refer to https://github.com/linzang/gzip/blob/distrotech-gzip/zip.c#L37 In JDK, there is a usage of `file comment` in the gzip heap dump file generated by jcmd `jmap -dump` command. at https://github.com/openjdk/jdk/blob/ff52f2989fd60ec8251eaf76f4c4b78f10d3e048/src/hotspot/share/services/heapDumperCompression.cpp#L127 , and this info is used in testing like an hint for uncompression, please refer https://github.com/openjdk/jdk/blob/ff52f2989fd60ec8251eaf76f4c4b78f10d3e048/test/lib/jdk/test/lib/hprof/parser/GzipRandomAccess.java#L280. And IMHO the behavior of adding information in `file comments` seems like a general way to transfer extra information between compressor and uncompressor. > Is there anyone who relies on this additional header info? As I mentioned in > an earlier comment, we should validate the changes against another > implementation to ensure that we can read the data back correctly and that > the additional header data that we write can be read by other tools. May be we could have similar behavior? which just do some general header info check, calculate CRC of the header and ignore the real contents of most header fields. Do you think it is reasonable? Thanks! Lin - PR: https://git.openjdk.java.net/jdk/pull/3072
Re: RFR: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices [v2]
On Fri, 9 Apr 2021 21:27:24 GMT, Joe Darcy wrote:
>> Rafael Winterhalter 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.
>
> src/java.base/share/classes/java/lang/reflect/Constructor.java line 612:
>
>> 610: Class declaringClass = getDeclaringClass();
>> 611: if (
>> 612: declaringClass.isEnum()
>
> Please format as
> if (declaringClass.isEnum()) {
> ...
Changed the formatting.
> test/jdk/java/lang/annotation/EnumConstructorAnnotation.java line 39:
>
>> 37: public static void main(String[] args) {
>> 38: Constructor c = SampleEnum.class.getDeclaredConstructors()[0];
>> 39: Annotation[] a = c.getParameters()[2].getAnnotations();
>
> The value of c.getParameters().getAnnotations() can be checked for
> consistency against c.getParameterAnnotations(). (The type
> java.lang.reflect.Parameter was added several releases after annotations were
> added.)
I added a test for both approaches.
-
PR: https://git.openjdk.java.net/jdk/pull/3082
Re: RFR: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices [v3]
> 8263763: The constructor of an enumeration prefixes with two synthetic > arguments for constant name and ordinal index. For this reason, the > constructor annotations need to be shifted two indices to the right, such > that the annotation indices match with the parameter indices. Rafael Winterhalter 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: 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices. - Changes: - all: https://git.openjdk.java.net/jdk/pull/3082/files - new: https://git.openjdk.java.net/jdk/pull/3082/files/d50d5f4c..0302611f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3082&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3082&range=01-02 Stats: 11 lines in 2 files changed: 3 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3082/head:pull/3082 PR: https://git.openjdk.java.net/jdk/pull/3082
Re: RFR: 8264806: Remove the experimental JIT compiler [v2]
On Sat, 10 Apr 2021 16:47:45 GMT, Igor Ignatyev wrote: >> Vladimir Kozlov 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: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > Marked as reviewed by iignatyev (Reviewer). Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032 - PR: https://git.openjdk.java.net/jdk/pull/3421
Re: jpackage ea-17 --mac-entitlements
> On Apr 9, 2021, at 9:27 PM, Michael Hall wrote: > > Although I believe > codesign -v --verbose=4 outputdir/HalfPipe.app > This verify would be sufficient to reproduce that error for any(?) jpackage > Developer signed application. An additional thought on this might be that it would be an idea to include a codesign verify as part of the build. From my java command line app. exec codesign -v /Applications/BBEdit.app exec codesign -v /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: a sealed resource is missing or invalid exec codesign -v /Applications/BBEdit.app | wc wc: chars - 0 wc: words - 0 wc: lines - 0 exec codesign -v /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app | wc wc: chars - 97 wc: words - 8 wc: lines - 1 Verify appears to return nothing if it succeeds and an error message if it doesn’t. From java it might have to check on that? I could RFE if wanted.
Re: RFR: 8264806: Remove the experimental JIT compiler [v2]
On Sat, 10 Apr 2021 16:36:54 GMT, Vladimir Kozlov wrote: >> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and >> update a few of its users accordingly? >> what about `vm.graal.enabled` `@requires` property? > > @iignatev If you think that I should clean tests anyway I will file follow > up RFE to do that. > > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and > > update a few of its users accordingly? > > what about `vm.graal.enabled` `@requires` property? > > Thank you, @iignatev for looking on changes. > > I forgot to mention that `Compiler::isGraalEnabled()` returns always false > now. Because 94 tests uses `@requires !vm.graal.enabled` I don't want to > include them in these changes which are already very big. I am not sure if I > should modify tests if GraalVM group wants to run all these tests. > If you think that I should clean tests anyway I will file follow up RFE to do > that. changing `Compiler::isGraalEnabled()` to always return false effectively makes these tests unrunnable for GraalVM group (unless they are keep the modified `sun/hotspot/code/Compiler` and/or `requires/VMProps` in their forks). on top of that, I foresee that there will be more tests incompatible w/ Graal yet given it won't be run/tested in OpenJDK, these tests won't be marked and hence will fail when run w/ Graal. so Graal people will have to either do marking themselves (I guess in both upstream and their fork) or maintain a list of inapplicable tests in a format that works best for their setup. that's to say, I think we should clean up the tests, yet I totally agree there is no need to do it as part of this PR. we can discuss how to do it better for both OpenJDK and GraalVM folks in the follow-up RFE. - PR: https://git.openjdk.java.net/jdk/pull/3421
Re: RFR: 8264806: Remove the experimental JIT compiler [v2]
On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related >> to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` — the Graal compiler >> - `jdk.internal.vm.compiler.management` — Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` — Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI >> module `jdk.internal.vm.ci` continues to build: >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> @AlanBateman suggested that we can avoid it by using Module API to export >> packages at runtime . It requires changes in GraalVM's JVMCI too so I will >> file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov 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: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler Marked as reviewed by iignatyev (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3421
Re: RFR: 8264806: Remove the experimental JIT compiler [v2]
On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev wrote: >> Vladimir Kozlov 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: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and > update a few of its users accordingly? > what about `vm.graal.enabled` `@requires` property? @iignatev If you think that I should clean tests anyway I will file follow up RFE to do that. - PR: https://git.openjdk.java.net/jdk/pull/3421
Re: RFR: 8264806: Remove the experimental JIT compiler [v2]
On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev wrote:
> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and
> update a few of its users accordingly?
> what about `vm.graal.enabled` `@requires` property?
Thank you, @iignatev for looking on changes.
I forgot to mention that `Compiler::isGraalEnabled()` returns always false now.
Because 94 tests uses `@requires !vm.graal.enabled` I don't want to include
them in these changes which are already very big. I am not sure if I should
modify tests if GraalVM group wants to run all these tests.
Unfortunately changes in `Compiler.java` are listed the last on `Files changed`
tab and GitHub has trouble to load these big changes - it takes time to see
them. Here `Compiler.java` chnges for review:
diff --git a/test/lib/sun/hotspot/code/Compiler.java
b/test/lib/sun/hotspot/code/Compiler.java
index 99122bd93b8..71288ae4482 100644
--- a/test/lib/sun/hotspot/code/Compiler.java
+++ b/test/lib/sun/hotspot/code/Compiler.java
@@ -60,33 +60,10 @@ public class Compiler {
/**
* Check if Graal is used as JIT compiler.
*
- * Graal is enabled if following conditions are true:
- * - we are not in Interpreter mode
- * - UseJVMCICompiler flag is true
- * - jvmci.Compiler variable is equal to 'graal'
- * - TieredCompilation is not used or TieredStopAtLevel is greater than 3
- * No need to check client mode because it set UseJVMCICompiler to false.
- *
- * @return true if Graal is used as JIT compiler.
+ * @return false because Graal is removed from JDK.
*/
public static boolean isGraalEnabled() {
-Boolean useCompiler = WB.getBooleanVMFlag("UseCompiler");
-if (useCompiler == null || !useCompiler) {
-return false;
-}
-Boolean useJvmciComp = WB.getBooleanVMFlag("UseJVMCICompiler");
-if (useJvmciComp == null || !useJvmciComp) {
-return false;
-}
-
-Boolean tieredCompilation = WB.getBooleanVMFlag("TieredCompilation");
-Long compLevel = WB.getIntxVMFlag("TieredStopAtLevel");
-// if TieredCompilation is enabled and compilation level is <= 3 then
no Graal is used
-if (tieredCompilation != null && tieredCompilation &&
-compLevel != null && compLevel <= 3) {
-return false;
-}
-return true;
+return false;
}
```
-
PR: https://git.openjdk.java.net/jdk/pull/3421
Re: RFR: 8264806: Remove the experimental JIT compiler [v2]
On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related >> to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` — the Graal compiler >> - `jdk.internal.vm.compiler.management` — Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` — Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI >> module `jdk.internal.vm.ci` continues to build: >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> @AlanBateman suggested that we can avoid it by using Module API to export >> packages at runtime . It requires changes in GraalVM's JVMCI too so I will >> file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov 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: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? what about `vm.graal.enabled` `@requires` property? - Changes requested by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3421
Re: RFR: 8264806: Remove the experimental JIT compiler
On Fri, 9 Apr 2021 22:30:32 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related >> to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` — the Graal compiler >> - `jdk.internal.vm.compiler.management` — Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` — Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI >> module `jdk.internal.vm.ci` continues to build: >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> @AlanBateman suggested that we can avoid it by using Module API to export >> packages at runtime . It requires changes in GraalVM's JVMCI too so I will >> file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Thankyou, @erikj79, for review. I restored code as you asked. > For some reasons incremental webrev shows update only in Cdiffs. none of the full webrevs seem to render even the list of changed files? is it just me? - PR: https://git.openjdk.java.net/jdk/pull/3421
Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)
On Sat, 10 Apr 2021 06:30:33 GMT, Tagir F. Valeev wrote: > With the introduction of `toList()`, preserving the SIZED characteristics in > more cases becomes more important. This patch preserves SIZED on `skip()` and > `limit()` operations, so now every combination of > `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and > `toList()`, `toArray()` and `count()` may benefit from this. E. g., > `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result > instantly with this patch. > > Some microbenchmarks added that confirm the reduced memory allocation in > `toList()` and `toArray()` cases. Before patch: > ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 > thrpt 10 40235,534 ± 0,984B/op > ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 > thrpt 10 106431,101 ± 0,198B/op > ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 > thrpt 10 106544,977 ± 1,983B/op > value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 > thrpt 10 40121,878 ± 0,247B/op > value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 > thrpt 10 106317,693 ± 1,083B/op > value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 > thrpt 10 106430,954 ± 0,136B/op > > After patch: > ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 > thrpt 10 40235,648 ± 1,354B/op > ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 > thrpt 10 40355,784 ± 1,288B/op > ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 > thrpt 10 40476,032 ± 2,855B/op > value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 > thrpt 10 40121,830 ± 0,308B/op > value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 > thrpt 10 40242,554 ± 0,443B/op > value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 > thrpt 10 40363,674 ± 1,576B/op > > Time improvements are less exciting. It's likely that inlining and > vectorizing dominate in these tests over array allocations and unnecessary > copying. Still, I notice a significant improvement in SliceToArray.seq_limit > case (2x) and mild improvement (+12..16%) in other slice tests. No > significant change in parallel execution time, though its performance is much > less stable and I didn't run enough tests. > > Before patch: > Benchmark (size) Mode Cnt Score Error > Units > ref.SliceToList.par_baseline 1 thrpt 30 14876,723 ± 99,770 > ops/s > ref.SliceToList.par_limit 1 thrpt 30 14856,841 ± 215,089 > ops/s > ref.SliceToList.par_skipLimit 1 thrpt 30 9555,818 ± 991,335 > ops/s > ref.SliceToList.seq_baseline 1 thrpt 30 23732,290 ± 444,162 > ops/s > ref.SliceToList.seq_limit 1 thrpt 30 14894,040 ± 176,496 > ops/s > ref.SliceToList.seq_skipLimit 1 thrpt 30 10646,929 ± 36,469 > ops/s > value.SliceToArray.par_baseline1 thrpt 30 25093,141 ± 376,402 > ops/s > value.SliceToArray.par_limit 1 thrpt 30 24798,889 ± 760,762 > ops/s > value.SliceToArray.par_skipLimit 1 thrpt 30 16456,310 ± 926,882 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 69669,787 ± 494,562 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 21097,081 ± 117,338 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30 15522,871 ± 112,557 > ops/s > > After patch: > Benchmark (size) Mode Cnt Score Error > Units > ref.SliceToList.par_baseline 1 thrpt 30 14793,373 ± 64,905 > ops/s > ref.SliceToList.par_limit 1 thrpt 30 13301,024 ± 1300,431 > ops/s > ref.SliceToList.par_skipLimit 1 thrpt 30 11131,698 ± 1769,932 > ops/s > ref.SliceToList.seq_baseline 1 thrpt 30 24101,048 ± 263,528 > ops/s > ref.SliceToList.seq_limit 1 thrpt 30 16872,168 ± 76,696 > ops/s > ref.SliceToList.seq_skipLimit 1 thrpt 30 11953,253 ± 105,231 > ops/s > value.SliceToArray.par_baseline1 thrpt 30 25442,442 ± 455,554 > ops/s > value.SliceToArray.par_limit 1 thrpt 30 23111,730 ± 2246,086 > ops/s > value.SliceToArray.par_skipLimit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30 18007,613 ± 141,716 > ops/s > > I also modernized SliceOps a little bit, using switch expression (with no > explicit default!) and diamonds on anonymous classes. test/jdk/java/
Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)
On Sat, 10 Apr 2021 06:30:33 GMT, Tagir F. Valeev wrote: > With the introduction of `toList()`, preserving the SIZED characteristics in > more cases becomes more important. This patch preserves SIZED on `skip()` and > `limit()` operations, so now every combination of > `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and > `toList()`, `toArray()` and `count()` may benefit from this. E. g., > `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result > instantly with this patch. > > Some microbenchmarks added that confirm the reduced memory allocation in > `toList()` and `toArray()` cases. Before patch: > ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 > thrpt 10 40235,534 ± 0,984B/op > ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 > thrpt 10 106431,101 ± 0,198B/op > ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 > thrpt 10 106544,977 ± 1,983B/op > value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 > thrpt 10 40121,878 ± 0,247B/op > value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 > thrpt 10 106317,693 ± 1,083B/op > value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 > thrpt 10 106430,954 ± 0,136B/op > > After patch: > ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 > thrpt 10 40235,648 ± 1,354B/op > ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 > thrpt 10 40355,784 ± 1,288B/op > ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 > thrpt 10 40476,032 ± 2,855B/op > value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 > thrpt 10 40121,830 ± 0,308B/op > value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 > thrpt 10 40242,554 ± 0,443B/op > value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 > thrpt 10 40363,674 ± 1,576B/op > > Time improvements are less exciting. It's likely that inlining and > vectorizing dominate in these tests over array allocations and unnecessary > copying. Still, I notice a significant improvement in SliceToArray.seq_limit > case (2x) and mild improvement (+12..16%) in other slice tests. No > significant change in parallel execution time, though its performance is much > less stable and I didn't run enough tests. > > Before patch: > Benchmark (size) Mode Cnt Score Error > Units > ref.SliceToList.par_baseline 1 thrpt 30 14876,723 ± 99,770 > ops/s > ref.SliceToList.par_limit 1 thrpt 30 14856,841 ± 215,089 > ops/s > ref.SliceToList.par_skipLimit 1 thrpt 30 9555,818 ± 991,335 > ops/s > ref.SliceToList.seq_baseline 1 thrpt 30 23732,290 ± 444,162 > ops/s > ref.SliceToList.seq_limit 1 thrpt 30 14894,040 ± 176,496 > ops/s > ref.SliceToList.seq_skipLimit 1 thrpt 30 10646,929 ± 36,469 > ops/s > value.SliceToArray.par_baseline1 thrpt 30 25093,141 ± 376,402 > ops/s > value.SliceToArray.par_limit 1 thrpt 30 24798,889 ± 760,762 > ops/s > value.SliceToArray.par_skipLimit 1 thrpt 30 16456,310 ± 926,882 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 69669,787 ± 494,562 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 21097,081 ± 117,338 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30 15522,871 ± 112,557 > ops/s > > After patch: > Benchmark (size) Mode Cnt Score Error > Units > ref.SliceToList.par_baseline 1 thrpt 30 14793,373 ± 64,905 > ops/s > ref.SliceToList.par_limit 1 thrpt 30 13301,024 ± 1300,431 > ops/s > ref.SliceToList.par_skipLimit 1 thrpt 30 11131,698 ± 1769,932 > ops/s > ref.SliceToList.seq_baseline 1 thrpt 30 24101,048 ± 263,528 > ops/s > ref.SliceToList.seq_limit 1 thrpt 30 16872,168 ± 76,696 > ops/s > ref.SliceToList.seq_skipLimit 1 thrpt 30 11953,253 ± 105,231 > ops/s > value.SliceToArray.par_baseline1 thrpt 30 25442,442 ± 455,554 > ops/s > value.SliceToArray.par_limit 1 thrpt 30 23111,730 ± 2246,086 > ops/s > value.SliceToArray.par_skipLimit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30 18007,613 ± 141,716 > ops/s > > I also modernized SliceOps a little bit, using switch expression (with no > explicit default!) and diamonds on anonymous classes. src/java.base/
Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)
On Sat, 10 Apr 2021 06:30:33 GMT, Tagir F. Valeev wrote: > With the introduction of `toList()`, preserving the SIZED characteristics in > more cases becomes more important. This patch preserves SIZED on `skip()` and > `limit()` operations, so now every combination of > `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and > `toList()`, `toArray()` and `count()` may benefit from this. E. g., > `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result > instantly with this patch. > > Some microbenchmarks added that confirm the reduced memory allocation in > `toList()` and `toArray()` cases. Before patch: > ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 > thrpt 10 40235,534 ± 0,984B/op > ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 > thrpt 10 106431,101 ± 0,198B/op > ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 > thrpt 10 106544,977 ± 1,983B/op > value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 > thrpt 10 40121,878 ± 0,247B/op > value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 > thrpt 10 106317,693 ± 1,083B/op > value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 > thrpt 10 106430,954 ± 0,136B/op > > After patch: > ref.SliceToList.seq_baseline:·gc.alloc.rate.norm1 > thrpt 10 40235,648 ± 1,354B/op > ref.SliceToList.seq_limit:·gc.alloc.rate.norm 1 > thrpt 10 40355,784 ± 1,288B/op > ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 1 > thrpt 10 40476,032 ± 2,855B/op > value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 1 > thrpt 10 40121,830 ± 0,308B/op > value.SliceToArray.seq_limit:·gc.alloc.rate.norm1 > thrpt 10 40242,554 ± 0,443B/op > value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm1 > thrpt 10 40363,674 ± 1,576B/op > > Time improvements are less exciting. It's likely that inlining and > vectorizing dominate in these tests over array allocations and unnecessary > copying. Still, I notice a significant improvement in SliceToArray.seq_limit > case (2x) and mild improvement (+12..16%) in other slice tests. No > significant change in parallel execution time, though its performance is much > less stable and I didn't run enough tests. > > Before patch: > Benchmark (size) Mode Cnt Score Error > Units > ref.SliceToList.par_baseline 1 thrpt 30 14876,723 ± 99,770 > ops/s > ref.SliceToList.par_limit 1 thrpt 30 14856,841 ± 215,089 > ops/s > ref.SliceToList.par_skipLimit 1 thrpt 30 9555,818 ± 991,335 > ops/s > ref.SliceToList.seq_baseline 1 thrpt 30 23732,290 ± 444,162 > ops/s > ref.SliceToList.seq_limit 1 thrpt 30 14894,040 ± 176,496 > ops/s > ref.SliceToList.seq_skipLimit 1 thrpt 30 10646,929 ± 36,469 > ops/s > value.SliceToArray.par_baseline1 thrpt 30 25093,141 ± 376,402 > ops/s > value.SliceToArray.par_limit 1 thrpt 30 24798,889 ± 760,762 > ops/s > value.SliceToArray.par_skipLimit 1 thrpt 30 16456,310 ± 926,882 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 69669,787 ± 494,562 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 21097,081 ± 117,338 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30 15522,871 ± 112,557 > ops/s > > After patch: > Benchmark (size) Mode Cnt Score Error > Units > ref.SliceToList.par_baseline 1 thrpt 30 14793,373 ± 64,905 > ops/s > ref.SliceToList.par_limit 1 thrpt 30 13301,024 ± 1300,431 > ops/s > ref.SliceToList.par_skipLimit 1 thrpt 30 11131,698 ± 1769,932 > ops/s > ref.SliceToList.seq_baseline 1 thrpt 30 24101,048 ± 263,528 > ops/s > ref.SliceToList.seq_limit 1 thrpt 30 16872,168 ± 76,696 > ops/s > ref.SliceToList.seq_skipLimit 1 thrpt 30 11953,253 ± 105,231 > ops/s > value.SliceToArray.par_baseline1 thrpt 30 25442,442 ± 455,554 > ops/s > value.SliceToArray.par_limit 1 thrpt 30 23111,730 ± 2246,086 > ops/s > value.SliceToArray.par_skipLimit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30 18007,613 ± 141,716 > ops/s > > I also modernized SliceOps a little bit, using switch expression (with no > explicit default!) and diamonds on anonymous classes. src/java.base/
