On Tue, 8 Oct 2024 17:10:43 GMT, Ramkumar Sunderbabu
wrote:
> The time difference check might fail for scenarios such as batch compilation.
> It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
>
> Testing: The test was run for 100 times with -Xcomp option.
This pull requ
On Tue, 15 Oct 2024 12:31:52 GMT, Ramkumar Sunderbabu
wrote:
>> The time difference check might fail for scenarios such as batch
>> compilation. It is safer to give a bigger allowance of 10 seconds instead of
>> 0.1 sec.
>>
>> Testing: The test was run for 100 times with -Xcomp option.
>
> Ra
> Can I please get a review for this patch which proposes to implement the
> enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>
> Edit: This PR description has now been updated to match the changes that were
> done over the course of review inputs that were received
On Wed, 16 Oct 2024 01:19:15 GMT, Tim Prinzing wrote:
> Adds a JFR event for socket connect operations.
>
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
> check for connect events.
src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 1006:
> 1004:
On Wed, 16 Oct 2024 01:19:15 GMT, Tim Prinzing wrote:
> Adds a JFR event for socket connect operations.
>
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
> check for connect events.
src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 624:
> 622:
On Mon, 14 Oct 2024 04:13:46 GMT, Johny Jose wrote:
>> Timezone data 2024b changes
>
> Johny Jose has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Review changes
@johnyjose30
Your change (at version a6aac06faab78b7b6296faedce2c7302f5a4e717
On Tue, 15 Oct 2024 22:15:45 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
>>
>>> 70: private static class StackWalkerHolder {
>>> 71: static final StackWalker STACK_WALKER =
>>> 72:
>>> StackWalker.getInstance(StackWalker
On Fri, 11 Oct 2024 06:43:33 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request
On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken wrote:
>> There is some old awt/2d coding where warnings occur when running with ubsan
>> enabled binaries.
>> However at most of these locations the coding should work (at least on our
>> supported platform set) so the warnings can be disabled
On Tue, 15 Oct 2024 17:34:53 GMT, Chen Liang wrote:
> Currently, to efficiently check if a `ClassEntry`, such as one from an
> `InvokeInstruction`, is of a particular class, we use such a pattern (as seen
> in JEP 486 [Appendix](https://openjdk.org/jeps/486#Appendix)):
>
> inst.owner().name().
On Tue, 15 Oct 2024 10:17:40 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update adlc changes.
>
> src/hotspot/share/opto/vectornode.hpp line 161:
>
>> 159: // Needed for proper cloning.
>
On Wed, 16 Oct 2024 01:26:45 GMT, Ioi Lam wrote:
>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`Lamb
On Tue, 15 Oct 2024 18:39:50 GMT, Magnus Ihse Bursie wrote:
>> src/java.base/unix/native/libjli/java_md.c line 509:
>>
>>> 507:
>>> 508: if (GetApplicationHome(path, pathsize)) {
>>> 509: if (JLI_IsStaticallyLinked()) {
>>
>> In passing, GetJREPath's function description includes "
On Tue, 15 Oct 2024 19:38:43 GMT, Stefan Karlsson wrote:
>> Ioi Lam has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 29 commits:
>>
>> - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init
>> NCPU to runtime
On Tue, 15 Oct 2024 19:40:15 GMT, Stefan Karlsson wrote:
>> Ioi Lam has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 29 commits:
>>
>> - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init
>> NCPU to runtime
> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and
> string concat (`Stri
On Wed, 2 Oct 2024 20:29:10 GMT, David Holmes wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> remove ubsan changes from jni_md.h
>
> jni_util.h is used across all modules but it is located in
> `java.base/shar
On Tue, 15 Oct 2024 20:57:05 GMT, Paul Sandoz wrote:
>>> I gave it a quick scan, and I have no further comments. LGTM.
>>
>> Thank you, i will kick off an internal test.
>
>> > I gave it a quick scan, and I have no further comments. LGTM.
>>
>> Thank you, i will kick off an internal test.
>
>
On Thu, 10 Oct 2024 17:54:51 GMT, Jan Lahoda wrote:
>> Currently, running `java` without any parameters will lead to an output that
>> is a full `--help`, which is over 100 lines (on my computer at least), and
>> it feels overwhelming. And many people might actually want to run
>> JShell/REPL,
On Wed, 16 Oct 2024 01:29:16 GMT, David Holmes wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adjusting the concise help based on review suggestions.
>
> src/java.base/share/classes/sun/launcher/resources/launcher.p
On Mon, 14 Oct 2024 15:52:07 GMT, Dan Heidinga wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed JDK-8341988: jstack launched with AOT cache created with
>> -XX:+AOTClassLinking crashes
>
> src/hotspot/share/cds/ao
> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and
> string concat (`Stri
Adds a JFR event for socket connect operations.
Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
check for connect events.
-
Commit messages:
- fix default settings
- fix merge
- Merge branch 'master' into JDK-8310996
- added tests and support for soc
On Tue, 15 Oct 2024 12:31:52 GMT, Ramkumar Sunderbabu
wrote:
>> The time difference check might fail for scenarios such as batch
>> compilation. It is safer to give a bigger allowance of 10 seconds instead of
>> 0.1 sec.
>>
>> Testing: The test was run for 100 times with -Xcomp option.
>
> Ra
> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> The implementation of java.lang.invoke uses SoftReferences so that unused
> MethodHandles, LambdaForms, etc, can be garbage collected.
>
> However, if we want to store j
On Wed, 2 Oct 2024 23:08:52 GMT, Vladimir Ivanov wrote:
>> Ioi Lam 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 13 additional commits
>> sinc
> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces
> to native code and use these in `ChannelInputStream` to work around cases
> where a wrapped `FileChannelImpl` is not really seekable.
Brian Burkhalter has updated the pull request incrementally with two additional
On Tue, 15 Oct 2024 21:17:37 GMT, Phil Race wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main chan
On Tue, 15 Oct 2024 15:01:00 GMT, Daniel Fuchs wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main c
On Tue, 15 Oct 2024 19:11:24 GMT, Mandy Chung wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 15 Oct 2024 20:55:54 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jv
On Tue, 15 Oct 2024 13:51:18 GMT, Daniel Fuchs wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main c
On Tue, 15 Oct 2024 20:40:50 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jv
On Tue, 15 Oct 2024 20:45:46 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jv
On Tue, 15 Oct 2024 10:19:46 GMT, Emanuel Peter wrote:
> Are there any IR rules that verify that the correct C2 nodes are used? Is
> that a thing you generally do with the VectorAPI, just to make sure things
> get correctly intrinsified?
Not systematically. We have some IR testing for more com
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with new test `vthread/CheckHiddenFrames`
>> - Ma
On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with new test `vthread/CheckHiddenFrames`
>> - Ma
On Tue, 15 Oct 2024 16:39:57 GMT, Paul Sandoz wrote:
> > Hi @vnkozlov , Can you kindly run this through your test infrastructure. We
> > have two review approvals for Java and x86 backend code.
>
> I have kicked off some internal tests (FYI @vnkozlov)
Tier 1 to 3 test past, except for the triv
On Tue, 15 Oct 2024 16:03:13 GMT, Paul Sandoz wrote:
> > I gave it a quick scan, and I have no further comments. LGTM.
>
> Thank you, i will kick off an internal test.
Tier 1 to 3 tests pass.
-
PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2415121395
On Tue, 15 Oct 2024 05:16:58 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses
> repeated squares trick.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Refining the loop invariant for more clear proof
-
Changes:
- all: htt
On Fri, 11 Oct 2024 15:16:50 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which removes overrides of
>> `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and
>> `ZipFileSystem::getInputStream`. Associated boolean fields used to track
>> `eof` are also removed.
>>
>> Th
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam wrote:
>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`Lamb
On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam wrote:
>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`Lamb
On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam wrote:
>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`Lamb
On Sun, 13 Oct 2024 09:57:00 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 15 Oct 2024 19:08:20 GMT, Dan Heidinga wrote:
>> Ioi Lam has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 29 commits:
>>
>> - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init
>> NCPU to runtime val
On Tue, 15 Oct 2024 18:59:32 GMT, Jiangli Zhou wrote:
>> After thinking a bit more on this, I concluded that we cannot automatically
>> extract a proper set of ld flags from what's being passed to the individual
>> libraries. The LDFLAGS needed by the monolithic static library needs to be
>> e
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam wrote:
>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`Lamb
On Sun, 13 Oct 2024 21:07:51 GMT, Ioi Lam wrote:
>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`Lamb
On Tue, 15 Oct 2024 18:50:27 GMT, Magnus Ihse Bursie wrote:
> After thinking a bit more on this, I concluded that we cannot automatically
> extract a proper set of ld flags from what's being passed to the individual
> libraries. The LDFLAGS needed by the monolithic static library needs to be
>
On Thu, 5 Sep 2024 20:41:35 GMT, Jiangli Zhou wrote:
>> You are right, this is dead code. Thanks for spotting this.
>>
>> During my experimentation, I tried passing along LDFLAGS from the individual
>> libraries as well, but it turned out not to be a good idea -- the way we
>> have used them
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Thu, 5 Sep 2024 00:15:35 GMT, Jiangli Zhou wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked
>> check
>
> src/java.base/unix/native/li
On Thu, 5 Sep 2024 10:17:11 GMT, Alan Bateman wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked
>> check
>
> src/java.base/unix/native/li
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
Thanks Viktor, I like your concept of multiple vantage points a lot.
Implementor: "use ofGreedy to signal that this operation does not itself initiate
short-circuiting"
Reviewer: "when you see ofGreedy verify that this operation does not itself initiate
short-circuiting"
Debugger: "when the ex
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Mon, 14 Oct 2024 17:37:01 GMT, Brian Burkhalter wrote:
> Change property `test.src` to `test.dir`.
This pull request has now been integrated.
Changeset: b9cabbec
Author:Brian Burkhalter
URL:
https://git.openjdk.org/jdk/commit/b9cabbecdac27ae8b93df88660a4a0f3f60e6828
Stats: 6
On Tue, 15 Oct 2024 13:06:01 GMT, Erik Joelsson wrote:
> Test successful, thanks for fixing this!
Thanks @erikj79 and @jaikiran for the reviews!
-
PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2414642523
Currently, to efficiently check if a `ClassEntry`, such as one from an
`InvokeInstruction`, is of a particular class, we use such a pattern (as seen
in JEP 486 [Appendix](https://openjdk.org/jeps/486#Appendix)):
inst.owner().name().equalsString("java/lang/System")
This pattern has a few issues:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Tue, 15 Oct 2024 17:00:26 GMT, Jasmine Karthikeyan
wrote:
>> Jatin Bhateja has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains two commits:
>>
>> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>> - 834
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Tue, 15 Oct 2024 16:34:06 GMT, David M. Lloyd wrote:
>> While making `LogManager.checkAccess` be a no-op might be more convenient,
>> it could unconditionally
>> permit operations that formerly required a permission check: clearly a bad
>> idea. Always throwing a `SecurityException` is the s
On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja wrote:
>> This patch optimizes LongVector multiplication by inferring VPMULUDQ
>> instruction for following IR pallets.
>>
>>
>>MulL ( And SRC1, 0x) ( And SRC2, 0x)
>>MulL (URShift SRC1 , 32) (URShift S
On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> mai
On Tue, 15 Oct 2024 12:31:52 GMT, Ramkumar Sunderbabu
wrote:
>> The time difference check might fail for scenarios such as batch
>> compilation. It is safer to give a bigger allowance of 10 seconds instead of
>> 0.1 sec.
>>
>> Testing: The test was run for 100 times with -Xcomp option.
>
> Ra
On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> mai
On Thu, 10 Oct 2024 16:24:35 GMT, Jatin Bhateja wrote:
> Hi @vnkozlov , Can you kindly run this through your test infrastructure. We
> have two review approvals for Java and x86 backend code.
I have kicked off some internal tests (FYI @vnkozlov)
-
PR Comment: https://git.openjdk.o
On Tue, 15 Oct 2024 16:14:58 GMT, Sean Mullan wrote:
> While making `LogManager.checkAccess` be a no-op might be more convenient, it
> could unconditionally permit operations that formerly required a permission
> check: clearly a bad idea. Always throwing a `SecurityException` is the
> safest
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 15 Oct 2024 12:31:52 GMT, Ramkumar Sunderbabu
wrote:
>> The time difference check might fail for scenarios such as batch
>> compilation. It is safer to give a bigger allowance of 10 seconds instead of
>> 0.1 sec.
>>
>> Testing: The test was run for 100 times with -Xcomp option.
>
> Ra
On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja wrote:
>> This patch optimizes LongVector multiplication by inferring VPMULUDQ
>> instruction for following IR pallets.
>>
>>
>>MulL ( And SRC1, 0x) ( And SRC2, 0x)
>>MulL (URShift SRC1 , 32) (URShift S
On Sun, 6 Oct 2024 08:32:20 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly
>> just the revert of the backout.
>>
>> Regarding the related issues:
>>
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
>> [JDK-830
On Wed, 2 Oct 2024 14:03:59 GMT, Nizar Benalla wrote:
>> This checker checks the values of the `@since` tag found in the
>> documentation comment for an element against the release in which the
>> element first appeared.
>>
>> Real since value of an API element is computed as the oldest releas
On Tue, 15 Oct 2024 15:52:13 GMT, David M. Lloyd wrote:
>> OK
>
> While I disagree with this change on the principle of "the system should
> operate as if no security manager were installed", the workaround for callers
> is actually rather simple:
>
>
> if (System.getSecurityManager() != null
On Tue, 15 Oct 2024 15:29:54 GMT, Daniel Fuchs wrote:
>> AFAIU, the original intention of the test is to check if Instant.now and
>> Instant.now(Clock.systemUTC()) returns almost same time since the underlying
>> clock is same.
>> Given that premise,
>> suggestion 1: it does the job but doesn't
On Tue, 15 Oct 2024 08:05:44 GMT, Eirik Bjørsnøs wrote:
>> Yep, looks good. And I agree with Claes' evaluation that we should not
>> complicate this construction further, especially that the result is quickly
>> garbage collected when we compile into the string to int array map.
>
> We could al
On Tue, 15 Oct 2024 09:35:23 GMT, Emanuel Peter wrote:
> I gave it a quick scan, and I have no further comments. LGTM.
Thank you, i will kick off an internal test.
-
PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2414431367
On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs wrote:
>> This is a bit of forced move. Same thing with Thread.checkAccess and
>> ThreadGroup.checkAccess that also have to be re-specified to throw
>> unconditionally. They are called out in the CSR.
>
> OK
While I disagree with this change on th
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman wrote:
>> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
>>
>>> 2428: @Deprecated(since="17", forRemoval=true)
>>> 2429: public void checkAccess() {
>>> 2430: throw new SecurityException();
>>
>> Though
On Tue, 15 Oct 2024 13:31:37 GMT, Ramkumar Sunderbabu
wrote:
>> test/jdk/java/time/tck/java/time/TCKInstant.java line 196:
>>
>>> 194: instantMillis = Instant.now().toEpochMilli();
>>> 195: afterMillis =
>>> Instant.now(Clock.systemUTC()).toEpochMilli();
>>> 196:
On Tue, 15 Oct 2024 14:27:13 GMT, Daniel Fuchs wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main c
On Tue, 15 Oct 2024 15:15:00 GMT, Brian Burkhalter wrote:
>> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 402:
>>
>>> 400: HANDLE handle = (HANDLE)(handleval(env, fdo));
>>> 401: jlong available;
>>> 402: if (handleAvailable((jlong)handle, &available)) {
>>
>> Ug
On Tue, 15 Oct 2024 05:15:53 GMT, Alan Bateman wrote:
>> Add `isOther` and `available` methods to `FileChannelImpl` and the
>> interfaces to native code and use these in `ChannelInputStream` to work
>> around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> src/java.base/wind
On Tue, 15 Oct 2024 15:13:06 GMT, Alan Bateman wrote:
> FileChannel implements SeekableByteChannel. You'll see exactly the same thing
> if you use FileChannel.open to open a special file.
Ah... thanks. Also (for example) `FileInputStream.getChannel()` returns a
`FileChannel`, so we're stuck wi
On Tue, 15 Oct 2024 15:03:50 GMT, Archie Cobbs wrote:
> Albeit with my very basic understanding of these internals, it seems wrong
> that the `FileChannel` created to represent a special ends up also being a
> `SeekableFileChannel`. This seems like the true root of the problem - that
> is, the
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
Hi Viktor, thanks again for sharing your design decisions. I agree this is a
minor matter because not many programmers will implement gatherers. Let me try
to explain my confusion.
On 15/10/2024 13:46, Viktor Klang wrote:
Making of() the short-name is because it is more capable than ofGreedy(
On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter wrote:
> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces
> to native code and use these in `ChannelInputStream` to work around cases
> where a wrapped `FileChannelImpl` is not really seekable.
Albeit with my very
1 - 100 of 137 matches
Mail list logo
