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
>
On Thu, 28 Oct 2021 07:00:24 GMT, Aleksey Shipilev wrote:
>> 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:
> `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
`Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
`OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
to call to runtime for a single memory barrier. We can simplify the native
`Unsafe` interface by falling back to `fullFence` when `{load|store}Fence`
On Thu, 28 Oct 2021 07:41:59 GMT, Aleksey Shipilev wrote:
>> Thanks for clarifying. Now we have all the intrinsics in place we have the
>> choice of delegating either at the Java level or the native level, where
>> previously we had to delegate at the Java level to get the benefit of the
>>
On Thu, 28 Oct 2021 08:58:48 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
On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote:
> Could you please review the 8233674 bug fixes?
> This problem is caused by the antivirus software opening the file for a short
> time, so CreateFile() should be retried.
This pull request has been closed without being integrated.
On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote:
> Could you please review the 8233674 bug fixes?
> This problem is caused by the antivirus software opening the file for a short
> time, so CreateFile() should be retried.
Thank you for your reply.
I understand we have no need to fix the
On Thu, 28 Oct 2021 02:32:41 GMT, David Holmes 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
Could you please review the 8262297 bug fixes?
In this case, ImageIO.write() should throw java.io.IOException rather than
java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and
wrapped in IIOException in ImageIO.write() with this fix. In addition,
On Thu, 28 Oct 2021 07:23:52 GMT, David Holmes wrote:
>> Something should happen when intrinsic is disabled. Other fences have native
>> `Unsafe_{Load|Store|Full}Fence` entry points for this. We can, technically,
>> do the same here, but I see no need. Instead, we can fall back to the
>>
On Sat, 23 Oct 2021 12:51:15 GMT, Andrey Turbanov wrote:
> 8276042: Remove unused local variables in java.naming
This pull request has now been integrated.
Changeset: 593401fe
Author:Andrey Turbanov
Committer: Aleksei Efimov
URL:
See the [integration
commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30
) for JDK-8245095. It reintroduced `java/util/stream` in
`exclusiveAccess.dirs`, which effectively reverts
Please review this change to remove some API which no longer works as expected
as recent OCI runtimes start to drop support for `--kernel-memory` switch. See
the bug for references. This part of the API is not present in hotspot code.
Testing: Container tests (cgroup v1) on Linux x86_64 (all
On 28/10/2021 05:43, Jaikiran Pai wrote:
:
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()
On Thu, 28 Oct 2021 11:56:45 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>>
On Thu, 28 Oct 2021 09:29:13 GMT, Masanori Yano wrote:
> Could you please review the 8262297 bug fixes?
>
> In this case, ImageIO.write() should throw java.io.IOException rather than
> java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and
> wrapped in IIOException in
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the
On Thu, 28 Oct 2021 14:04:15 GMT, Harold Seigel wrote:
> The changes look good. Thanks for doing this. Harold
Thanks for the review!
-
PR: https://git.openjdk.java.net/jdk/pull/6156
On Thu, 28 Oct 2021 13:03:56 GMT, Severin Gehwolf wrote:
> Please review this change to remove some API which no longer works as
> expected as recent OCI runtimes start to drop support for `--kernel-memory`
> switch. See the bug for references. This part of the API is not present in
> hotspot
On Wed, 12 May 2021 17:48:50 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
On Wed, 27 Oct 2021 20:16:54 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
On Wed, 27 Oct 2021 20:16:54 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
> cc @ctornqvi
Ivan Šipka has updated the pull request incrementally with one additional
commit since the last revision:
changing os id
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6025/files
- new:
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
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe`
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
On Thu, 28 Oct 2021 13:03:56 GMT, Severin Gehwolf wrote:
> Please review this change to remove some API which no longer works as
> expected as recent OCI runtimes start to drop support for `--kernel-memory`
> switch. See the bug for references. This part of the API is not present in
> hotspot
On Thu, 28 Oct 2021 15:30:49 GMT, Ivan Šipka wrote:
>> cc @ctornqvi
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> changing os id
as per comment from Igor above, the bug id in the problemlist is incorrect, and
it should
On Thu, 5 Aug 2021 23:51:13 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
> Please consider this proposed change to ignore comparing the total size of
> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8274750: Change location of check that file
On Tue, 26 Oct 2021 19:00:44 GMT, Brian Burkhalter wrote:
> Please consider this proposed change to ignore comparing the total size of
> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
Please refer to the issue for more detail, but this change is proposed because
the total size of
> Please consider this proposed change to ignore comparing the total size of
> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8274750: Suppress compilation warning about
On Tue, 26 Oct 2021 20:59:45 GMT, Igor Ignatyev wrote:
>> Ivan Šipka has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains two commits:
>>
>> - fixed OS identifier
>> - 8274122: added to problem list
>
> And now you use an incorrect
On Tue, 26 Oct 2021 20:27:47 GMT, Brian Burkhalter wrote:
>> test/jdk/java/io/File/GetXSpace.java line 210:
>>
>>> 208: if (Platform.isOSX() && s.name().equals("/dev")) {
>>> 209: out.println("/dev:\n Skipping size comparison for /dev on
>>> macOS");
>>> 210:
On Thu, 28 Oct 2021 19:33:06 GMT, Roger Riggs wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274750: Change location of check that file system is not /dev on macOS
>
> LTGM
>
> (While you're in there you
On Thu, 28 Oct 2021 18:15:33 GMT, Brian Burkhalter wrote:
>> Please consider this proposed change to ignore comparing the total size of
>> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since
On Thu, 28 Oct 2021 21:21:38 GMT, Brian Burkhalter wrote:
>> Please consider this proposed change to ignore comparing the total size of
>> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since
On Thu, 28 Oct 2021 18:15:33 GMT, Brian Burkhalter wrote:
>> Please consider this proposed change to ignore comparing the total size of
>> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since
On Thu, 28 Oct 2021 20:26:47 GMT, Mandy Chung wrote:
>> 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
> 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 Thu, 28 Oct 2021 20:23:41 GMT, Mandy Chung wrote:
>> 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
On Mon, 11 Oct 2021 20:55:23 GMT, Mandy Chung wrote:
> 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
> cc @ctornqvi
Ivan Šipka has updated the pull request incrementally with one additional
commit since the last revision:
fixed bugid
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6025/files
- new: https://git.openjdk.java.net/jdk/pull/6025/files/97d000a0..f5ea03fa
> Can I please get a review for this change which fixes the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8275509?
>
> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
> components to compute the final hash code. While doing so it ends up calling
>
On Mon, 25 Oct 2021 09:21:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which fixes the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8275509?
>>
>> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
>> components to compute
On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote:
> Please review the integration of tzdata2021e (including tzdata2021d) to the
> JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests.
>
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java
Please review the integration of tzdata2021e (including tzdata2021d) to the JDK.
The fix has passed all relevant JTREG regression tests and JCK tests.
8275754: (tz) Update Timezone Data to 2021d
8275849: TestZoneInfo310.java fails with tzdata2021e
-
Commit messages:
- 8275754:
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> At the time Java supported applets and webstart, a special mechanism for
> launching various applications in one JVM was used to reduce memory usage and
> each application was isolated from each other.
>
> This isolation was
49 matches
Mail list logo
