Re: RFR: 8276042: Remove unused local variables in java.naming [v2]
On Wed, 27 Oct 2021 15:42:32 GMT, Andrey Turbanov wrote: >> 8276042: Remove unused local variables in java.naming > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8276042: Remove unused local variables in java.naming > use instanceof pattern Looks good to me. - Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.net/jdk/pull/6091
Re: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v4]
On Fri, 22 Oct 2021 10:33:42 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2559: >> >>> 2557: continue; >>> 2558: } >>> 2559: h += e.ordinal(); >> >> This e == null check suggests there is an issue elsewhere, can you explain >> the scenario where you see this? Also can you drop the spurious use of >> "final" here, it's inconsistent with the existing code. >> >> Do you want us to look at the test? It looks like it needs clean-up and I'm >> not sure if you want to wait for the CDS issue or not. > > Hello Alan, > >> This e == null check suggests there is an issue elsewhere, can you explain >> the scenario where you see this? > > That was just a pre-emptive defensive check I had added. There isn't a > scenario in that flow where any of the elements are currently null. I have > updated this PR to remove that check. Test continues to pass with this > change. Also removed the "final". > >> Do you want us to look at the test? It looks like it needs clean-up and I'm >> not sure if you want to wait for the CDS issue or not. > > Yes please. The test is ready for review. The only place where there's a > `TODO` is where that part of commented code is affected by the bug mentioned > in that comment. I would like to use that check (the commented out one) but I > don't want to wait for that other bug to be fixed for this PR, since I am > unsure how big or how long it might take for the other bug to be fixed. I > plan to uncomment that part in a separate PR once that other bug is fixed, if > that's OK. Hello Alan, Looking at the CDS issue that's being tracked at https://bugs.openjdk.java.net/browse/JDK-8275731, it's looking like a much bigger change and might take a while. In the meantime do you think this test case (and the fix to the hashCode() part) looks OK? I am open to deleting the commented out equality check in this test case since although that equality testing should be done, it doesn't have to be done as part of this hashCode() fix/test PR. Let me know what you and others prefer. - PR: https://git.openjdk.java.net/jdk/pull/6078
Re: RFR: 8252990: Intrinsify Unsafe.storeStoreFence
On Wed, 27 Oct 2021 11:53:47 GMT, Aleksey Shipilev wrote:
> `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`.
> We can teach compilers to map this directly to already existing rules that
> handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we
> introduce the special node to differentiate explicit fence and implicit
> store-store barriers. This node is usually used to simulate safe
> `final`-field like constructions in special JDK classes, like
> `ConstantCallSite` and friends.
>
> Motivational performance difference on benchmarks from JDK-8276054 on ARM32:
>
>
> Benchmark Mode Cnt ScoreError Units
> Multiple.plain avgt3 2.669 ± 0.004 ns/op
> Multiple.release avgt3 16.688 ± 0.057 ns/op
> Multiple.storeStoreavgt3 14.021 ± 0.144 ns/op // Better
>
> MultipleWithLoads.plainavgt3 4.672 ± 0.053 ns/op
> MultipleWithLoads.release avgt3 16.689 ± 0.044 ns/op
> MultipleWithLoads.storeStore avgt3 14.012 ± 0.010 ns/op // Better
>
> MultipleWithStores.plain avgt3 14.687 ± 0.009 ns/op
> MultipleWithStores.release avgt3 45.393 ± 0.192 ns/op
> MultipleWithStores.storeStore avgt3 38.048 ± 0.033 ns/op // Better
>
> Publishing.plain avgt3 27.079 ± 0.201 ns/op
> Publishing.release avgt3 27.088 ± 0.241 ns/op
> Publishing.storeStore avgt3 27.009 ± 0.259 ns/op // Within
> error, hidden by allocation
>
> Single.plain avgt3 2.670 ± 0.002 ns/op
> Single.releaseFenceavgt3 6.675 ± 0.001 ns/op
> Single.storeStoreFence avgt3 8.012 ± 0.027 ns/op // Worse,
> seems to be ARM32 implementation artifact
>
>
> As expected, this does not affect x86_64 at all, because both `release` and
> `storeStore` are effectively no-ops, only affecting compiler optimizations:
>
>
> Benchmark Mode Cnt Score Error Units
>
> Multiple.plain avgt3 0.406 ± 0.002 ns/op
> Multiple.release avgt3 0.409 ± 0.018 ns/op
> Multiple.storeStoreavgt3 0.406 ± 0.001 ns/op
>
> MultipleWithLoads.plainavgt3 4.328 ± 0.006 ns/op
> MultipleWithLoads.release avgt3 4.600 ± 0.014 ns/op
> MultipleWithLoads.storeStore avgt3 4.602 ± 0.006 ns/op
>
> MultipleWithStores.plain avgt3 0.812 ± 0.001 ns/op
> MultipleWithStores.release avgt3 0.812 ± 0.002 ns/op
> MultipleWithStores.storeStore avgt3 0.812 ± 0.002 ns/op
>
> Publishing.plain avgt3 6.370 ± 0.059 ns/op
> Publishing.release avgt3 6.358 ± 0.436 ns/op
> Publishing.storeStore avgt3 6.367 ± 0.054 ns/op
>
> Single.plain avgt3 0.407 ± 0.039 ns/op
> Single.releaseFenceavgt3 0.406 ± 0.001 ns/op
> Single.storeStoreFence avgt3 0.406 ± 0.001 ns/op
>
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `tier1`
src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3449:
> 3447: public final void storeStoreFence() {
> 3448: // Without the special intrinsic, default to a stronger
> storeFence,
> 3449: // which is already intrinsified.
Not clear me to me why we need to retain this fallback?
-
PR: https://git.openjdk.java.net/jdk/pull/6136
Re: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v2]
On Mon, 25 Oct 2021 21:39:34 GMT, Dan Smith wrote: > I'd suggest invoking the LMF API directly instead, testing both private and > non-private invokespecial MethodHandles, just making sure the rules can be > used without error. That's a good idea. I updated the test and see what you think. - PR: https://git.openjdk.java.net/jdk/pull/5901
Re: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v3]
> Classes compiled prior to the nestmate support will generate > `REF_invokeSpecial` if the implementation method is a private instance > method. Since a lambda proxy class is a hidden class, a nestmate of the > host class, it can invoke the private implementation method but it has to use > `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old > classes running on the new runtime, LMF implementation adjusts the reference > kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. > > This PR fixes the check properly to ensure the adjustment is only made if the > implementation method is private method in the host class. Mandy Chung 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 five additional commits since the last revision: - Update test to test LMF with no dependency on javac behavior - Merge branch 'master' of https://github.com/openjdk/jdk into invokespecial - Merge branch 'invokespecial' of https://github.com/mlchung/jdk into invokespecial - remove filelist which was added accidentally - JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior - Changes: - all: https://git.openjdk.java.net/jdk/pull/5901/files - new: https://git.openjdk.java.net/jdk/pull/5901/files/cfdd036e..c44a5910 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5901=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5901=01-02 Stats: 29565 lines in 721 files changed: 21974 ins; 5102 del; 2489 mod Patch: https://git.openjdk.java.net/jdk/pull/5901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5901/head:pull/5901 PR: https://git.openjdk.java.net/jdk/pull/5901
Re: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v6]
On Sun, 24 Oct 2021 07:55:01 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in >> the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= >> this.length()` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should end successfully. >>(test31) >> >> 2. `pos - 1 + length > this.length()` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should end successfully. *1 >>(test32) >> >> 3. `pos == this.length() + 1` >>The original implementation throws `SerialException` but this case should >> end successfully. *2 >>(test33) >> >> 4. `length < 0` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should throw `SerialException`. >>(test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >>The original implementation throws `ArrayIndexOutOfBoundsException` (or >> `OutOfMemoryError` in most cases) but this case should throw >> `SerialException`. >>(test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, >> int length)` in the following cases: >> >> 1. `offset > str.length()` >>The original implementaion throws `StringIndexOutOfBoundsException` but >> this case should throw `SerialException`. >>(test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= >> this.length()` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should end successfully. >>(test32) >> >> 3. `pos - 1 + length > this.length()` >>The original implementaion throws `SerialException` but this case should >> end successfully. *3 >>(test40) >> >> 4. `pos == this.length() + 1` >>The original implementaion throws `SerialException` but this case should >> end successfully. *4 >>(test41) >> >> 5. `length < 0` >>The original implementation throws `StringIndexOutOfBoundsException` but >> this case should throw `SerialException`. >>(test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >>The original implementation throws `ArrayIndexOutOfBoundsException` (or >> `OutOfMemoryError` in most cases) but this case should throw >> `SerialException`. >>(test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob >> value is reached while writing the array of bytes, then the length of the >> Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for >> pos is greater than the length+1 of the BLOB value then the behavior is >> undefined." >>So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob >> value is eached while writing the given string, then the length of the Clob >> value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for >> pos is greater than the length+1 of the CLOB value then the behavior is >> undefined." >>So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya 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: > > - Merge branch 'master' into JDK-8153490 > - Follow the comment > - Modify javadoc for consistency > - Fix for length + offset > Integer.MAX_VALUE case > - Add check: ensure length >= 0 > - 8153490:Cannot setBytes() if incoming buffer's length is bigger than > number of elements we want to insert. > >Fix SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length) in > the >following cases: > >1. pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= > this.length() > The original implementation throws ArrayIndexOutOfBoundsException but > this case > should end successfully. > (test31) > >2. pos - 1 + length > this.length() > The original implementation throws ArrayIndexOutOfBoundsException but > this case > should end successfully. *1 > (test32) > >3. pos == this.length() + 1 > The original implementation throws SerialException but this case should > end > successfully. *2 > (test33) > >Additionally, fix SerialClob.setString(long pos, String str, int offset, > int length) >in the following cases: > >1. offset > str.length() > The original implementaion throws StringIndexOutOfBoundsException but > this case > should throw SerialException. > (test39) > >
Re: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string
On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app > (default is 1024, 8K should be enough for any environments) Marked as reviewed by cjplummer (Reviewer). Actually revoking my review for the moment. Do we have any tests that currently test the default PerfMaxStringConstLength, and this change could be subverting the test by making it so the length is never exceeded? - PR: https://git.openjdk.java.net/jdk/pull/5858
Re: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string
On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app > (default is 1024, 8K should be enough for any environments) Ping. Need 2nd reviewer - PR: https://git.openjdk.java.net/jdk/pull/5858
Re: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v7]
> This PR improves the performance of vector operations that accept masks on > architectures that support masking in hardware, specifically Intel AVX512 and > ARM SVE. > > On architectures that do not support masking in hardware the same technique > as before is applied to most operations, specifically composition using blend. > > Masked loads/stores are a special form of masked operation that require > additional care to ensure out-of-bounds access throw exceptions. The range > checking has not been fully optimized and will require further work. > > No API enhancements were required and only a few additional tests were needed. Paul Sandoz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8271515-vector-api - Merge pull request #1 from nsjian/JDK-8271515 Address AArch64 review comments from Nick. - Address review comments from Nick. - Merge branch 'master' into JDK-8271515-vector-api - Resolve review comments. - Merge branch 'master' into JDK-8271515-vector-api - Apply patch from https://github.com/openjdk/panama-vector/pull/152 - Apply patch from https://github.com/openjdk/panama-vector/pull/142 - Apply patch from https://github.com/openjdk/panama-vector/pull/139 - Apply patch from https://github.com/openjdk/panama-vector/pull/151 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/9a3e9542...c9a77225 - Changes: https://git.openjdk.java.net/jdk/pull/5873/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5873=06 Stats: 21966 lines in 104 files changed: 16193 ins; 2089 del; 3684 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873
Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v16]
> This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation > uses `MethodHandle`. For `Field` accessor, the new implementation uses > `VarHandle`.For the first few invocations of one of these reflective > methods on a specific reflective object we invoke the corresponding method > handle directly. After that we spin a dynamic bytecode stub defined in a > hidden class which loads the target `MethodHandle` or `VarHandle` from its > class data as a dynamically computed constant. Loading the method handle from > a constant allows JIT to inline the method-handle invocation in order to > achieve good performance. > > The VM's native reflection methods are needed during early startup, before > the method-handle mechanism is initialized. That happens soon after > System::initPhase1 and before System::initPhase2, after which we switch to > using method handles exclusively. > > The core reflection and method handle implementation are updated to handle > chained caller-sensitive method calls [1] properly. A caller-sensitive method > can define with a caller-sensitive adapter method that will take an > additional caller class parameter and the adapter method will be annotated > with `@CallerSensitiveAdapter` for better auditing. See the detailed > description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] > https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: - fix copyright header and typo - improve documentation of AccessorUtils - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Fall back to the VM native reflection support if method handle cannot be created - fix bug id in test - Merge - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Separate paramFlgas into paramCount and flags fields - Minor cleanup. Improve javadoc in CallerSensitiveAdapter - ... and 33 more: https://git.openjdk.java.net/jdk/compare/9a3e9542...46cb306b - Changes: https://git.openjdk.java.net/jdk/pull/5027/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5027=15 Stats: 6436 lines in 78 files changed: 5891 ins; 317 del; 228 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027
Re: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v6]
On Sun, 24 Oct 2021 07:55:01 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in >> the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= >> this.length()` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should end successfully. >>(test31) >> >> 2. `pos - 1 + length > this.length()` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should end successfully. *1 >>(test32) >> >> 3. `pos == this.length() + 1` >>The original implementation throws `SerialException` but this case should >> end successfully. *2 >>(test33) >> >> 4. `length < 0` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should throw `SerialException`. >>(test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >>The original implementation throws `ArrayIndexOutOfBoundsException` (or >> `OutOfMemoryError` in most cases) but this case should throw >> `SerialException`. >>(test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, >> int length)` in the following cases: >> >> 1. `offset > str.length()` >>The original implementaion throws `StringIndexOutOfBoundsException` but >> this case should throw `SerialException`. >>(test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= >> this.length()` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should end successfully. >>(test32) >> >> 3. `pos - 1 + length > this.length()` >>The original implementaion throws `SerialException` but this case should >> end successfully. *3 >>(test40) >> >> 4. `pos == this.length() + 1` >>The original implementaion throws `SerialException` but this case should >> end successfully. *4 >>(test41) >> >> 5. `length < 0` >>The original implementation throws `StringIndexOutOfBoundsException` but >> this case should throw `SerialException`. >>(test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >>The original implementation throws `ArrayIndexOutOfBoundsException` (or >> `OutOfMemoryError` in most cases) but this case should throw >> `SerialException`. >>(test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob >> value is reached while writing the array of bytes, then the length of the >> Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for >> pos is greater than the length+1 of the BLOB value then the behavior is >> undefined." >>So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob >> value is eached while writing the given string, then the length of the Clob >> value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for >> pos is greater than the length+1 of the CLOB value then the behavior is >> undefined." >>So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya 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: > > - Merge branch 'master' into JDK-8153490 > - Follow the comment > - Modify javadoc for consistency > - Fix for length + offset > Integer.MAX_VALUE case > - Add check: ensure length >= 0 > - 8153490:Cannot setBytes() if incoming buffer's length is bigger than > number of elements we want to insert. > >Fix SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length) in > the >following cases: > >1. pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= > this.length() > The original implementation throws ArrayIndexOutOfBoundsException but > this case > should end successfully. > (test31) > >2. pos - 1 + length > this.length() > The original implementation throws ArrayIndexOutOfBoundsException but > this case > should end successfully. *1 > (test32) > >3. pos == this.length() + 1 > The original implementation throws SerialException but this case should > end > successfully. *2 > (test33) > >Additionally, fix SerialClob.setString(long pos, String str, int offset, > int length) >in the following cases: > >1. offset > str.length() > The original implementaion throws StringIndexOutOfBoundsException but > this case > should throw SerialException. > (test39) > >
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v4]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments. - 4511638: Double.toString(double) sometimes produces incorrect results Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results Refactored test classes to better match OpenJDK conventions. Added tests recommended by Guy Steele and Paul Zimmermann. - Changed MAX_CHARS to static - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results - Changes: https://git.openjdk.java.net/jdk/pull/3402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3402=03 Stats: 23945 lines in 16 files changed: 23809 ins; 61 del; 75 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem
On Wed, 27 Oct 2021 18:25:40 GMT, Alan Snyder wrote: > I never load system libraries directly. I load my own libraries (that support > JNI entry points) and the system loader loads the necessary system frameworks > that they were linked against. > > What's different in this case that motivates loading system libraries > directly from Java Panama would be the right place to provide the support of loading system libraries directly from Java and enhance the interconnection between JVM and native code. The bug report is an example showing that developers want to load a system library for their native code to use. It's not surprise that they use `System::load/loadLibrary` even it's designed for JNI without Panama since it works. So this patch is for compatibility for existing applications to continue to run on Big Sur. - PR: https://git.openjdk.java.net/jdk/pull/6127
Re: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem [v2]
On Wed, 27 Oct 2021 17:27:41 GMT, Mandy Chung wrote: >> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The >> libraries are no longer present on the filesystem. >> `NativeLibraries::loadLibrary` checks for the file existence before calling >> `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This >> proposes that on macOS >= 11, it will skip the file existence check and >> attempt to load a library for each path from java.library.path and system >> library path. > > Mandy Chung has updated the pull request incrementally with two additional > commits since the last revision: > > - Adjust parsing os.version to handle no dot version in case it's allowed > - Exclude building exeLibraryCache.c on other platforms except macOS This came up on panama-dev a bunch of time now. In fact, in the panama use case this would make sense for other systems as well. For instance on linux systems, there's a bunch of known library names in gnu/lib-names.h which programs can depend on, but for which System::load/loadLibrary cannot be used - as they are neither library names, nor paths - for instance "libm.so.6". - Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6127
Re: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem
> On Oct 27, 2021, at 9:28 AM, Mandy Chung wrote: > >>> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The >>> libraries are no longer present on the filesystem. >>> `NativeLibraries::loadLibrary` checks for the file existence before calling >>> `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This >>> proposes that on macOS >= 11, it will skip the file existence check and >>> attempt to load a library for each path from java.library.path and system >>> library path. > I’m curious about this issue. I never load system libraries directly. I load my own libraries (that support JNI entry points) and the system loader loads the necessary system frameworks that they were linked against. What’s different in this case that motivates loading system libraries directly from Java? Alan
Re: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem [v2]
> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The > libraries are no longer present on the filesystem. > `NativeLibraries::loadLibrary` checks for the file existence before calling > `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes > that on macOS >= 11, it will skip the file existence check and attempt to > load a library for each path from java.library.path and system library path. Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: - Adjust parsing os.version to handle no dot version in case it's allowed - Exclude building exeLibraryCache.c on other platforms except macOS - Changes: - all: https://git.openjdk.java.net/jdk/pull/6127/files - new: https://git.openjdk.java.net/jdk/pull/6127/files/e034029f..710925b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6127=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6127=00-01 Stats: 12 lines in 5 files changed: 2 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6127/head:pull/6127 PR: https://git.openjdk.java.net/jdk/pull/6127
Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v9]
On Tue, 26 Oct 2021 16:24:48 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API classes are added to `java.net.spi` package to facilitate
>> this:
>> - `InetAddressResolverProvider` - abstract class defining a service, and
>> is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the
>> platform's built-in configuration for resolution operations that could be
>> used to bootstrap a resolver construction, or to implement partial
>> delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the
>> fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the
>> characteristics of one forward lookup operation.
>>
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>>
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add @ throws NPE to hosts file resolver javadoc
src/java.base/share/classes/java/net/InetAddress.java line 841:
> 839: // 'resolver.lookupByAddress' and 'InetAddress.getAllByName0'
> delegate to the system-wide resolver,
> 840: // which could be a custom one. At that point we treat any
> unexpected RuntimeException thrown by
> 841: // the resolver as we would treat an UnknownHostException or an
> unmatched host name.
indentation issue in comment above
src/java.base/share/classes/java/net/InetAddress.java line 1308:
> 1306: * Creates an InetAddress based on the provided host name and IP
> address.
> 1307: * System {@linkplain InetAddressResolver resolver} is not used to
> check
> 1308: * the validity of the address.
Is this term "system resolver" defined somewhere? I think it means the
configured resolver for the current VM. Previously, it really was the system
resolver. So, I think it's potentially confusing, as there is also reference to
the java.net.preferIPv6Addresses system property as having a possible value
"system" which refers to the operating system. Since the CSR is approved, I'm
happy to discuss this point post integration.
-
PR: https://git.openjdk.java.net/jdk/pull/5822
Re: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem
On Wed, 27 Oct 2021 02:51:24 GMT, Jaikiran Pai wrote:
>> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
>> libraries are no longer present on the filesystem.
>> `NativeLibraries::loadLibrary` checks for the file existence before calling
>> `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This
>> proposes that on macOS >= 11, it will skip the file existence check and
>> attempt to load a library for each path from java.library.path and system
>> library path.
>
> src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java line
> 44:
>
>> 42: } catch (NumberFormatException e) {}
>> 43: }
>> 44: hasDynamicLoaderCache = major >= 11;
>
> Hello Mandy,
> I'm not too familiar with MacOS versioning schemes. However, in this specific
> logic, if the `os.version` value doesn't contain a dot character, then the
> `major` is initialized to `11`, which would then evaluate this
> `hasDynamicLoaderCache` to `true`. That would mean if the `os.version` is
> (for example) `10`, then `hasDynamicLoaderCache` will be incorrectly set to
> `true` here, isn't it?
macOS product version contains 3 parts: major, minor, and patch version. But
it does not hurt to handle the case where no dot exists in the string.
int major = 11;
int i = osVersion.indexOf('.');
try {
major = Integer.parseInt(i < 0 ? osVersion : osVersion.substring(0,
i));
} catch (NumberFormatException e) {}
-
PR: https://git.openjdk.java.net/jdk/pull/6127
Integrated: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern > alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have > better performance > > In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I > migrated only usages which were automatically detected by IDEA. It turns out > there are more usages which can be migrated. This pull request has now been integrated. Changeset: 9a3e9542 Author:Andrey Turbanov Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/9a3e9542997860de79d07a4411b1007e9cd5c348 Stats: 31 lines in 11 files changed: 0 ins; 0 del; 31 mod 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes Reviewed-by: naoto - PR: https://git.openjdk.java.net/jdk/pull/5432
Re: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem
On Wed, 27 Oct 2021 03:39:39 GMT, Jaikiran Pai wrote: > So, I think, the whole point of this change in this block is to skip the file > existence check and return back a file path. exactly. - PR: https://git.openjdk.java.net/jdk/pull/6127
Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v15]
On Wed, 27 Oct 2021 14:08:05 GMT, Alan Bateman wrote:
>> Mandy Chung has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Fall back to the VM native reflection support if method handle cannot be
>> created
>> - fix bug id in test
>> - Merge
>> - Merge branch 'master' of https://github.com/openjdk/jdk into
>> reimplement-method-invoke
>> - Merge branch 'master' of https://github.com/openjdk/jdk into
>> reimplement-method-invoke
>> - Separate paramFlgas into paramCount and flags fields
>> - Minor cleanup. Improve javadoc in CallerSensitiveAdapter
>> - Fix left-over assignment
>> - Remove duplicated microbenchmarks
>> - Avoid pitfall with unwanted inlining in some cases. Also remove
>> boxing/unboxing to focus on the invocation cost
>> - ... and 30 more:
>> https://git.openjdk.java.net/jdk/compare/97d3280e...64738bb2
>
> src/java.base/share/classes/jdk/internal/reflect/AccessorUtils.java line 34:
>
>> 32: */
>> 33: public class AccessorUtils {
>> 34: static boolean isIllegalArgument(Class accessorType,
>> RuntimeException e) {
>
> It might be useful to add a method description. In isolation, it's not
> immediately clear what it does.
I agree that'd be helpful. I'll add the javadoc.
-
PR: https://git.openjdk.java.net/jdk/pull/5027
Re: RFR: 8276042: Remove unused local variables in java.naming [v2]
On Wed, 27 Oct 2021 15:42:32 GMT, Andrey Turbanov wrote: >> 8276042: Remove unused local variables in java.naming > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8276042: Remove unused local variables in java.naming > use instanceof pattern Marked as reviewed by dfuchs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6091
Re: RFR: 8276042: Remove unused local variables in java.naming [v2]
On Wed, 27 Oct 2021 15:42:32 GMT, Andrey Turbanov wrote: >> 8276042: Remove unused local variables in java.naming > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8276042: Remove unused local variables in java.naming > use instanceof pattern Marked as reviewed by aefimov (Committer). - PR: https://git.openjdk.java.net/jdk/pull/6091
Re: RFR: 8276042: Remove unused local variables in java.naming [v2]
On Wed, 27 Oct 2021 11:08:31 GMT, Aleksei Efimov wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276042: Remove unused local variables in java.naming
>> use instanceof pattern
>
> src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java
> line 514:
>
>> 512: Object obj = cont.getResolvedObj();
>> 513:
>> 514: if (obj instanceof PartialCompositeContext) {
>
> Since we're changing this method, maybe `instanceof` pattern matching can be
> used here to remove casting below.
done
-
PR: https://git.openjdk.java.net/jdk/pull/6091
Re: RFR: 8276042: Remove unused local variables in java.naming [v2]
> 8276042: Remove unused local variables in java.naming Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8276042: Remove unused local variables in java.naming use instanceof pattern - Changes: - all: https://git.openjdk.java.net/jdk/pull/6091/files - new: https://git.openjdk.java.net/jdk/pull/6091/files/58bfec0d..f697d88c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6091=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6091=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6091.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6091/head:pull/6091 PR: https://git.openjdk.java.net/jdk/pull/6091
RFR: 8252990: Intrinsify Unsafe.storeStoreFence
`Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`. We can teach compilers to map this directly to already existing rules that handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce the special node to differentiate explicit fence and implicit store-store barriers. This node is usually used to simulate safe `final`-field like constructions in special JDK classes, like `ConstantCallSite` and friends. Motivational performance difference on benchmarks from JDK-8276054 on ARM32: Benchmark Mode Cnt ScoreError Units Multiple.plain avgt3 2.669 ± 0.004 ns/op Multiple.release avgt3 16.688 ± 0.057 ns/op Multiple.storeStoreavgt3 14.021 ± 0.144 ns/op // Better MultipleWithLoads.plainavgt3 4.672 ± 0.053 ns/op MultipleWithLoads.release avgt3 16.689 ± 0.044 ns/op MultipleWithLoads.storeStore avgt3 14.012 ± 0.010 ns/op // Better MultipleWithStores.plain avgt3 14.687 ± 0.009 ns/op MultipleWithStores.release avgt3 45.393 ± 0.192 ns/op MultipleWithStores.storeStore avgt3 38.048 ± 0.033 ns/op // Better Publishing.plain avgt3 27.079 ± 0.201 ns/op Publishing.release avgt3 27.088 ± 0.241 ns/op Publishing.storeStore avgt3 27.009 ± 0.259 ns/op // Within error, hidden by allocation Single.plain avgt3 2.670 ± 0.002 ns/op Single.releaseFenceavgt3 6.675 ± 0.001 ns/op Single.storeStoreFence avgt3 8.012 ± 0.027 ns/op // Worse, seems to be ARM32 implementation artifact As expected, this does not affect x86_64 at all, because both `release` and `storeStore` are effectively no-ops, only affecting compiler optimizations: Benchmark Mode Cnt Score Error Units Multiple.plain avgt3 0.406 ± 0.002 ns/op Multiple.release avgt3 0.409 ± 0.018 ns/op Multiple.storeStoreavgt3 0.406 ± 0.001 ns/op MultipleWithLoads.plainavgt3 4.328 ± 0.006 ns/op MultipleWithLoads.release avgt3 4.600 ± 0.014 ns/op MultipleWithLoads.storeStore avgt3 4.602 ± 0.006 ns/op MultipleWithStores.plain avgt3 0.812 ± 0.001 ns/op MultipleWithStores.release avgt3 0.812 ± 0.002 ns/op MultipleWithStores.storeStore avgt3 0.812 ± 0.002 ns/op Publishing.plain avgt3 6.370 ± 0.059 ns/op Publishing.release avgt3 6.358 ± 0.436 ns/op Publishing.storeStore avgt3 6.367 ± 0.054 ns/op Single.plain avgt3 0.407 ± 0.039 ns/op Single.releaseFenceavgt3 0.406 ± 0.001 ns/op Single.storeStoreFence avgt3 0.406 ± 0.001 ns/op Additional testing: - [x] Linux x86_64 fastdebug `tier1` - Commit messages: - Formatting - Little cleanup - 8252990: Intrinsify Unsafe.storeStoreFence Changes: https://git.openjdk.java.net/jdk/pull/6136/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6136=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252990 Stats: 39 lines in 16 files changed: 33 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6136.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6136/head:pull/6136 PR: https://git.openjdk.java.net/jdk/pull/6136
Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v15]
On Tue, 26 Oct 2021 16:35:34 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the first few invocations of one of these reflective
>> methods on a specific reflective object we invoke the corresponding method
>> handle directly. After that we spin a dynamic bytecode stub defined in a
>> hidden class which loads the target `MethodHandle` or `VarHandle` from its
>> class data as a dynamically computed constant. Loading the method handle
>> from a constant allows JIT to inline the method-handle invocation in order
>> to achieve good performance.
>>
>> The VM's native reflection methods are needed during early startup, before
>> the method-handle mechanism is initialized. That happens soon after
>> System::initPhase1 and before System::initPhase2, after which we switch to
>> using method handles exclusively.
>>
>> The core reflection and method handle implementation are updated to handle
>> chained caller-sensitive method calls [1] properly. A caller-sensitive
>> method can define with a caller-sensitive adapter method that will take an
>> additional caller class parameter and the adapter method will be annotated
>> with `@CallerSensitiveAdapter` for better auditing. See the detailed
>> description from [2].
>>
>> Ran tier1-tier8 tests.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8013527
>> [2]
>> https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430
>
> Mandy Chung has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 40 commits:
>
> - Fall back to the VM native reflection support if method handle cannot be
> created
> - fix bug id in test
> - Merge
> - Merge branch 'master' of https://github.com/openjdk/jdk into
> reimplement-method-invoke
> - Merge branch 'master' of https://github.com/openjdk/jdk into
> reimplement-method-invoke
> - Separate paramFlgas into paramCount and flags fields
> - Minor cleanup. Improve javadoc in CallerSensitiveAdapter
> - Fix left-over assignment
> - Remove duplicated microbenchmarks
> - Avoid pitfall with unwanted inlining in some cases. Also remove
> boxing/unboxing to focus on the invocation cost
> - ... and 30 more:
> https://git.openjdk.java.net/jdk/compare/97d3280e...64738bb2
src/java.base/share/classes/jdk/internal/reflect/AccessorUtils.java line 34:
> 32: */
> 33: public class AccessorUtils {
> 34: static boolean isIllegalArgument(Class accessorType,
> RuntimeException e) {
It might be useful to add a method description. In isolation, it's not
immediately clear what it does.
-
PR: https://git.openjdk.java.net/jdk/pull/5027
Integrated: 8270490: Charset.forName() taking fallback default value
On Wed, 20 Oct 2021 17:23:36 GMT, Naoto Sato wrote: > During the review of JEP 400, a proposal to provide an overloaded method to > `Charset.forName()` was suggested > [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This > PR is to implement the proposal. A CSR is also drafted as > https://bugs.openjdk.java.net/browse/JDK-8275348 This pull request has now been integrated. Changeset: 168081ef Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/168081efc8af1f5d1d7524246eb4a0675bd49ae0 Stats: 114 lines in 3 files changed: 106 ins; 5 del; 3 mod 8270490: Charset.forName() taking fallback default value Reviewed-by: joehw, rriggs, serb, dfuchs - PR: https://git.openjdk.java.net/jdk/pull/6045
Re: RFR: 8276042: Remove unused local variables in java.naming
On Sat, 23 Oct 2021 12:51:15 GMT, Andrey Turbanov wrote:
> 8276042: Remove unused local variables in java.naming
Hi Andrey,
Thanks for cleaning up the code.
Changes look good to me, with one suggestion below.
src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java
line 514:
> 512: Object obj = cont.getResolvedObj();
> 513:
> 514: if (obj instanceof PartialCompositeContext) {
Since we're changing this method, maybe `instanceof` pattern matching can be
used here to remove casting below.
-
Marked as reviewed by aefimov (Committer).
PR: https://git.openjdk.java.net/jdk/pull/6091
Re: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings
On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the > `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such > `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte > encoders - and also more in line with how well these charsets behave when > calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error > Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ± 0.120 > us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ± 1.942 > us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ± 2.006 > us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ± 5.019 > us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ± 1.651 > us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error > Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ± 0.078 > us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ± 0.209 > us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ± 0.251 > us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ± 0.368 > us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ± 0.267 > us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for > the purpose of implementing such ASCII fast-paths, but is only used in what > is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` > operations. > > Testing: tier1-3 Thanks for reviewing! - PR: https://git.openjdk.java.net/jdk/pull/6102
Integrated: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings
On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the > `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such > `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte > encoders - and also more in line with how well these charsets behave when > calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error > Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ± 0.120 > us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ± 1.942 > us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ± 2.006 > us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ± 5.019 > us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ± 1.651 > us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error > Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ± 0.078 > us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ± 0.209 > us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ± 0.251 > us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ± 0.368 > us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ± 0.267 > us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for > the purpose of implementing such ASCII fast-paths, but is only used in what > is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` > operations. > > Testing: tier1-3 This pull request has now been integrated. Changeset: 6c05cc9d Author:Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/6c05cc9d15fb6014b8293a66ef132f3461badca1 Stats: 35 lines in 5 files changed: 24 ins; 4 del; 7 mod 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Reviewed-by: naoto, rriggs, alanb - PR: https://git.openjdk.java.net/jdk/pull/6102
Re: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem
On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote: > On, macOS 11.x, system libraries are loaded from dynamic linker cache. The > libraries are no longer present on the filesystem. > `NativeLibraries::loadLibrary` checks for the file existence before calling > `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes > that on macOS >= 11, it will skip the file existence check and attempt to > load a library for each path from java.library.path and system library path. The change is unfortunate but looks okay. - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6127
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Wed, 6 Oct 2021 18:40:36 GMT, Mark Reinhold wrote: >> @mbreinhold Could you comment on this pull request? > >> @mbreinhold Could you comment on this pull request? > > This is somewhat tricky code. I’ll take a look, but give me a few days. @mbreinhold @AlanBateman Could you please reply to the above comments? - PR: https://git.openjdk.java.net/jdk/pull/5679
RFR: 8276042: Remove unused local variables in java.naming
8276042: Remove unused local variables in java.naming - Commit messages: - [PATCH] Remove unused local variable in java.naming Changes: https://git.openjdk.java.net/jdk/pull/6091/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6091=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276042 Stats: 10 lines in 5 files changed: 0 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6091.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6091/head:pull/6091 PR: https://git.openjdk.java.net/jdk/pull/6091
