Re: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator)
On Wed, 27 Apr 2022 11:03:48 GMT, Jatin Bhateja wrote: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted > for [JEP 426: Vector API (Fourth > Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector > operations. >- VectorOperations.BIT_COUNT: counts the number of one-bits >- VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero > bits >- VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing > zero bits >- VectorOperations.REVERSE: reversing the order of bits >- VectorOperations.REVERSE_BYTES: reversing the order of bytes >- compress and expand bits: Semantics are based on Hacker's Delight > section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and > expansion operations under the influence of a mask. >- Vector.compress >- Vector.expand >- VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load > and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support > for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Remind: please use the command `/jep JEP-426` [1] to mark this PR. [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep - PR: https://git.openjdk.java.net/jdk/pull/8425
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34]
On Fri, 29 Apr 2022 08:06:24 GMT, Maurizio Cimadamore wrote: > would a jep unneeded be enough to "unstuck" this PR? Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep command. - PR: https://git.openjdk.java.net/jdk/pull/7888
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and >> require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems >> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for >> zero and some of the other ports. Additional ports can be contributed via >> PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels >> have been trimmed down for now to hotspot, serviceability and core-libs. >> We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from >> Doug Lea's CVS. These changes will probably be proposed and integrated in >> advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support >> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to >> make life a bit easier and avoid having to separate VM changes and juggle >> branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional > commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Remind: please use the command `/jep JEP-425` [1] to mark this PR. [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep - PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34]
On Thu, 28 Apr 2022 18:10:57 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Downcall and upcall tests use wrong layout which is missing some trailing > padding Remind: please use the command `/jep JEP-424` [1] to mark this PR. [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep - PR: https://git.openjdk.java.net/jdk/pull/7888
Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v3]
On Fri, 19 Nov 2021 05:07:23 GMT, Vicente Romero wrote: >> Please review this PR which aims to optimize the implementation of the >> `toString` method we provide for records. A benchmark comparing the >> implementation we are providing for records with lombok found out that >> lombok is much faster mainly because our implementation uses >> `String::format`. This fix is basically delegating on >> StringConcatFactory::makeConcatWithConstants which is faster. >> >> TIA >> >> This is the result of the benchmark comparing records to lombok with vanilla >> JDK: >> >> Benchmark Mode CntScoreError Units >> MyBenchmark.base avgt40.849 ± 0.111 ns/op >> MyBenchmark.equals_record avgt47.343 ± 2.740 ns/op >> MyBenchmark.equals_value avgt46.644 ± 1.920 ns/op >> MyBenchmark.record_hash_code avgt45.763 ± 3.882 ns/op >> MyBenchmark.record_to_string avgt4 262.626 ± 12.574 ns/op >><-- Before >> MyBenchmark.value_class_to_string avgt4 30.325 ± 21.389 ns/op >> MyBenchmark.value_hash_codeavgt45.048 ± 3.936 ns/op >> >> >> after this patch: >> >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.base avgt4 0.680 ± 0.185 ns/op >> MyBenchmark.equals_record avgt4 5.599 ± 1.348 ns/op >> MyBenchmark.equals_value avgt4 5.718 ± 4.633 ns/op >> MyBenchmark.record_hash_code avgt4 4.628 ± 4.368 ns/op >> MyBenchmark.record_to_string avgt4 26.791 ± 1.817 ns/op >><--- After >> MyBenchmark.value_class_to_string avgt4 35.473 ± 2.626 ns/op >> MyBenchmark.value_hash_codeavgt4 6.152 ± 5.101 ns/op > > Vicente Romero has updated the pull request incrementally with one additional > commit since the last revision: > > adding the benchmark FYI: this patch also seems to solve [JDK-8265747](https://bugs.openjdk.java.net/browse/JDK-8265747). - PR: https://git.openjdk.java.net/jdk/pull/6403
Re: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1
On Thu, 22 Jul 2021 19:38:07 GMT, Joe Darcy wrote:
>> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements
>> about annotation applicability made in java.lang.annotation.Target need to
>> be updated to match.
>>
>> Please also review the corresponding CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8270917
>
> CSR now approved.
Hi @jddarcy,
Sorry for the delay.
I notice the current javac code(shown below) doesn't meet the JLS 9.6.4.1 .
The code doesn't mark `TYPE_PARAMETER` as the default target.
Because the PR https://github.com/openjdk/jdk/pull/622 and
https://github.com/openjdk/jdk/pull/2412 , which tried to fix this problem, is
earlier than the
[JDK-8261610](https://bugs.openjdk.java.net/browse/JDK-8261610),
[JDK-8270916](https://bugs.openjdk.java.net/browse/JDK-8270916), and
[JDK-8270917](https://bugs.openjdk.java.net/browse/JDK-8270917).
According to the new JLS 9.6.4.1, the javac compiler should be adjusted to add
`TYPE_PARAMETER` as the default target.
Should we fix the compiler issue in JDK17? But it seems too late to do that.
Maybe JDK18 is a good place. What do you think about it? Any ideas are
appreciated.
// com.sun.tools.javac.comp.Check.java
private Name[] dfltTargetMeta;
private Name[] defaultTargetMetaInfo() {
if (dfltTargetMeta == null) {
ArrayList defaultTargets = new ArrayList<>();
defaultTargets.add(names.PACKAGE);
defaultTargets.add(names.TYPE);
defaultTargets.add(names.FIELD);
defaultTargets.add(names.METHOD);
defaultTargets.add(names.CONSTRUCTOR);
defaultTargets.add(names.ANNOTATION_TYPE);
defaultTargets.add(names.LOCAL_VARIABLE);
defaultTargets.add(names.PARAMETER);
if (allowRecords) {
defaultTargets.add(names.RECORD_COMPONENT);
}
if (allowModules) {
defaultTargets.add(names.MODULE);
}
dfltTargetMeta = defaultTargets.toArray(new Name[0]);
}
return dfltTargetMeta;
}
Best Regards,
-- Guoxiong
-
PR: https://git.openjdk.java.net/jdk17/pull/256
Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll
On Thu, 17 Dec 2020 10:36:17 GMT, Rémi Forax wrote: >> Looks like I've found the original ticket: >> https://bugs.openjdk.java.net/browse/JDK-8193031 > > Apart from the @SuppressWarnings, this looks good to me. > And i like the irony of this. Hi all, According to the document of [SafeVarargs](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/SafeVarargs.html). > Compilers are encouraged to issue warnings when this annotation type is > applied to a method or constructor declaration where: > The body of the method or constructor declaration performs potentially unsafe > operations, such as an assignment to an element of the variable arity > parameter's array that generates an unchecked warning. The `SafeVarargs` may not suppress the warning of this assignment and the `SuppressWarnings` may be necessary. If you still think it is the bug of compiler. I suggest that you move the bug discussion to the compiler-...@openjdk.java.net to solve the bug as soon as possible. - PR: https://git.openjdk.java.net/jdk/pull/1764
