Re: jpackage ea-17 --mac-entitlements

2021-04-11 Thread Michael Hall 



> On Apr 9, 2021, at 9:27 PM, Michael Hall  wrote:
> 
>> 
>> OK, probable user error. I eliminated my entitlement changes and it worked.
>> 
> Related to the same functionality that I am trying to add, I should, or have 
> to, make changes to my Info.plist
> This being the addition of NSAppleEventsUsageDescription. 
> If I remember correctly in prior discussion concerning application specific 
> environment variables provision was made for the user to include their own 
> custom Info.plist in the Resources directory? Is that correct? Does the file 
> name stay the same?
>  

I apparently remembered this correctly. I added the above 
NSAppleEventsUsageDescription to a copied Info.plist and it worked from the 
resources dir.

On the AppleEvent permission issue it was my misunderstanding on that. I 
thought I should pass my application bundle id for the user to give permission 
to. 
But it should be passed the ‘other’ bundle id of what I want to send events to.
So in this case with the permission request…
System.out.println(aePerm("com.apple.systemevents",true));

You can then…

exec open "/System/Library/CoreServices/System Events.app”.   [The target 
app must be running or -600 error]
us.hall.osx.AEPermit
  [This got the dialog requesting permission without hanging]
0

And an AppleScript against System Events can be run…

mps
376 Finder  com.apple.finder
/System/Library/CoreServices/Finder.app MACS
836 Mailcom.apple.mail  /System/Applications/Mail.app   emal
1338AdobeReader com.adobe.Reader/Applications/Adobe Acrobat 
Reader DC.app   CARO
2225Terminalcom.apple.Terminal  
/System/Applications/Utilities/Terminal.app 
2398HalfPipeus.hall.HalfPipe
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app
2834System Preferences  com.apple.systempreferences 
/System/Applications/System Preferences.app sprf
2855eclipse org.eclipse.platform.ide
/Users/mjh/java-2019-06/Eclipse.app 

Old AppleScript based command to get Apple specific information about running 
processes from System Events, which is an application itself I just found out.

Requesting permission for your own bundle id hangs. Otherwise no problem, and 
nothing jpackage/Java related for that matter.
But to indicate resolved.

Re: RFR: 8264208: Console charset API [v2]

2021-04-11 Thread Alan Bateman 
On Fri, 9 Apr 2021 21:06:00 GMT, Naoto Sato  wrote:

>> Please review the changes for the subject issue.  This has been suggested in 
>> a recent discussion thread for the JEP 400 
>> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>>  A CSR has also been drafted, and comments are welcome 
>> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Reflected the review comments.

src/java.base/share/classes/java/io/Console.java line 397:

> 395: /**
> 396:  * Returns the {@link java.nio.charset.Charset Charset} object used 
> in
> 397:  * this {@code Console}.

The Console is a singleton and the existing methods use "the console" so I 
think we should do the same here.

We'll need to add to the description of the System.{in,out,err} fields, I don't 
mind if we do it as part of this PR or another issue.

-

PR: https://git.openjdk.java.net/jdk/pull/3419

Re: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v3]

2021-04-11 Thread Lance Andersen 

Hi Lin
On Apr 10, 2021, at 11:16 PM, Lin Zang 
mailto:lz...@openjdk.java.net>> wrote:


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.

Please look at:

The Jep https://openjdk.java.net/jeps/395

A simple tutorial

https://oracle.github.io/learning-library/oci-library/oci-hol/oci-java-app/workshops/freetier/?customTrackingParam=:ow:lp:pt:::RC_WWMK200728P9:OCIJava_HOL=7e168170255b485a917a5e6602097868=100601=2=:ow:lp:cpo:::RC_WWMK200728P00012:LPD400088742+:ow:lp:cpo::=lab-6-records#STEP1:AsimpleRecord

Chris and Julia’s video is also very good:

https://www.youtube.com/watch?v=pxiHwrEMEtI

Between the use of Record and/or the Builder pattern, assembling the header 
values can be done quite nicely without constructor overload.

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.

Sorry, that what not my point  Your current proposal provides no wayto access 
these fields similar to for example ZipEntry.  If we are going to set these 
additional fields then we should we should provided a means to access the fields

Have you looked at other gzip api implementations to see what they provide in 
this area?

Please look at api’s such as commons-compress.  They provide access to these 
fields via the API in addition to being able to set the fields.  This is what I 
was referring to above.


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?

Adding additional support for these fields is fine, we just need to agree on 
the API changes to move forward prior to updating the PR

Thanks!
Lin

-

PR: https://git.openjdk.java.net/jdk/pull/3072

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8264806: Remove the experimental JIT compiler [v2]

2021-04-11 Thread Doug Simon 
On Sat, 10 Apr 2021 17:41:05 GMT, Vladimir Kozlov  wrote:

>> Marked as reviewed by iignatyev (Reviewer).
>
> Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032

We would definitely like to be able to continue testing of GraalVM with the JDK 
set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it 
does today is important.

-

PR: https://git.openjdk.java.net/jdk/pull/3421

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v2]

2021-04-11 Thread Tagir F . Valeev 
> 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.

Tagir F. Valeev has updated the pull request incrementally with one

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v2]

2021-04-11 Thread Tagir F . Valeev 
On Sat, 10 Apr 2021 14:18:57 GMT, Vladimir Sitnikov  
wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Fixes according to review:
>>   
>>   1. Comments in adjustSize
>>   2. repeating code extracted from testNoEvaluationForSizedStream
>
> test/micro/org/openjdk/bench/java/util/stream/ops/ref/SliceToList.java line 
> 50:
> 
>> 48: @Benchmark
>> 49: public List seq_baseline() {
>> 50: return IntStream.range(0, size)
> 
> Typically you want to move all the constants to state fields to avoid 
> constant folding by the compiler.
> The compiler might accidentally use the fact that range start is always 0 and 
> produce a dedicated optimized code for it. 
> 
> See https://shipilev.net/blog/2014/java-scala-divided-we-fail/

I know this article. Here, the upper bound is a state field, so the whole range 
cannot be optimized. And even if the compiler optimizes at the loop start, it's 
pretty common to have ranges starting with the constant 0 in the production, so 
I would not say that having 0 as an iteration starting point makes the 
benchmark more artificial. The same approach is used in neighbor benchmarks, 
and in fact, this is not the biggest problem with these benchmarks. Clean type 
profile makes them much more artificial than starting with zero. So I'd prefer 
keeping zero as is.

-

PR: https://git.openjdk.java.net/jdk/pull/3427

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)

2021-04-11 Thread Tagir F . Valeev 
On Sat, 10 Apr 2021 14:16:40 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,

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)

2021-04-11 Thread Tagir F . Valeev 
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,