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&pr=6091&range=00
Issue: https://bugs.openjdk
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 th
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 ch
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 al
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 al
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
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 d
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
`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 s
> 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.op
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/classe
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
>
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
>
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
>> - f
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
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
>
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`. Su
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
> 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
> th
> 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`.
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`. Suc
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
> 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,
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 t
> 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
> 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, spec
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
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 tes
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 t
> 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
> `
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.
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
> intro
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 els
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
>
34 matches
Mail list logo
