On Mon, 14 Oct 2024 18:02:44 GMT, Brian Burkhalter wrote:
>> Change property `test.src` to `test.dir`.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8341997: Replace test.dir property with CWD
This test-only change l
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 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 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 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 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 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: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 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 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
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 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 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, 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: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
Hi Cay!
>AFAIK, the "greedy/short-circuiting" decision point doesn't have a major
>impact on performance either. Or am I wrong there?
One of my personal goals was to arrive at a point where the built-in
intermediate Stream operations could be implemented as Gatherers with a
performance around-
On Wed, 9 Oct 2024 11:24:43 GMT, Maurizio Cimadamore
wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base
> 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.
Ramkumar Sunderbabu has updated the pull request incrementally with one
addi
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
changes in the JEP and also includes an apidiff of the specification
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 23:26:04 GMT, Brian Burkhalter wrote:
> > I'm taking this fix for a spin over night in the environment where I
> > noticed the problem.
>
> I'll hold off integrating until that is over.
Test successful, thanks for fixing this!
-
PR Comment: https://git.openjdk
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 13:08:37 GMT, Daniel Fuchs wrote:
>> Ramkumar Sunderbabu has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> checking if time is monotonic
>
> test/jdk/java/time/tck/java/time/TCKInstant.java line 196:
>
>> 194:
On Tue, 15 Oct 2024 07:57:46 GMT, Per Minborg wrote:
> Are you able to run the `SegmentBulkMismatch` benchmark on the various BE
> platforms?
Thanks for the hint. I've run it with the old implementation before
[JDK-8339531](https://bugs.openjdk.org/browse/JDK-8339531) but with the new
micro b
> 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 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
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 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 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 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 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 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 08:23:23 GMT, Raffaello Giulietti
wrote:
>> @rgiulietti Or maybe "i.e., 5^(2^i) is larger than the largest power of five
>> that is still removable from intVal", could it be ok?
>
> While I intuitively understand, and I'm convinced of the clever algorithm,
> I'm struggling
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Tue, 15 Oct 2024 10:02:15 GMT, Yudi Zheng wrote:
>> Aleksey Shipilev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 18 commits:
>>
>> - Simplify: just do keep alive checks
>> - Merge branch 'master' into JDK-8329597-intrinsi
On Tue, 15 Oct 2024 09:29:48 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 16 Jul 2024 18:02:57 GMT, Chen Liang wrote:
> In annotated types, local and inner class types should be annotated as
> "top-level" types. For example, in the test here
>
> public static Class getLocalsMember() {
> class Local {
> class Member {
>
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
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (directory `jm
On Tue, 15 Oct 2024 09:13:48 GMT, Raffaello Giulietti
wrote:
>> Yes, I considered that as well.
>> Not sure, however, if this is sufficient to prove that intVal has been
>> indeed divided by 5^z after the 2nd loop is terminated.
>
> Anyway, if you find a nice proof please add it to the comments
On Tue, 15 Oct 2024 09:18:05 GMT, Aleksey Shipilev wrote:
> Thanks for review, folks. I am re-running testing locally here. Would
> appreciate if you can give this patch a spin through your CIs as well.
I will run some internal CI testing and report back in one or two days.
-
PR C
On Mon, 14 Oct 2024 18:17:37 GMT, Martin Doerr wrote:
> This version uses little endian accesses on big endian machines. This may
> defeat the purpose of
> [JDK-8339531](https://bugs.openjdk.org/browse/JDK-8339531) for those
> platforms. Accesses are typically slower when using them with endia
On Mon, 30 Sep 2024 09:19:21 GMT, Per Minborg wrote:
> This PR suggests fixing a problem on big-endian platforms.
This pull request has now been integrated.
Changeset: 521effe0
Author:Per Minborg
URL:
https://git.openjdk.org/jdk/commit/521effe017b9b6322036f1851220056a637d6b1c
Stats:
On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new two vector permutation APIs.
>>
>>
>> Declaration:-
>> Vector.selectFrom(Vector v1, Vector v2)
>>
>>
>> Semantics:-
>>
On Tue, 15 Oct 2024 13:33:16 GMT, Martin Doerr wrote:
>>> This version uses little endian accesses on big endian machines. This may
>>> defeat the purpose of
>>> [JDK-8339531](https://bugs.openjdk.org/browse/JDK-8339531) for those
>>> platforms. Accesses are typically slower when using them wi
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.
>
> Please review this fix for cgroups-based metrics reporting in the
> `jdk.internal.platform` package. This fix is supposed to address wrong
> reporting of certain limits if the limits aren't set at the leaf nodes.
>
> For example, on cg v2, the memory limit interface file is `memory.max`.
> Co
> 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:
More comments for correctness proof
-
Changes:
- all: https://git.open
On Tue, 15 Oct 2024 09:18:59 GMT, fabioromano1 wrote:
>> Anyway, if you find a nice proof please add it to the comments. The
>> algorithm is quite sophisticated, so it needs one.
>
> I would say yes... The invariant `i == max{n : 5^(2^n) <= 5^remainingZeros}`
> should be a sufficient condition
On Mon, 14 Oct 2024 20:01:42 GMT, Rob Spoor wrote:
>> src/java.base/share/classes/java/io/Reader.java line 214:
>>
>>> 212: cbuf[off + i] = cs.charAt(next + i);
>>> 213: }
>>> 214: }
>>
>> Just a drive-by observation, not for this
On Tue, 15 Oct 2024 05:13:14 GMT, Chen Liang wrote:
>> I like simple.
>>
>> Mixing Set.of and HashSet means a lot of semantic fu-fu (throwing/not
>> throwing on nulls) and risks being suboptimal due making some call sites
>> megamorphic.
>
> Yep, looks good. And I agree with Claes' evaluation
On Wed, 18 Sep 2024 15:47:01 GMT, Maurizio Cimadamore
wrote:
> This PR moves the section on restricted methods from the the javadoc of
> `java.lang.foreign` package into a standalone static [javadoc
> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/j
On Tue, 15 Oct 2024 09:02:58 GMT, fabioromano1 wrote:
>> While I intuitively understand, and I'm convinced of the clever algorithm,
>> I'm struggling to find a proof, in particular to formulate a useful
>> invariant for the first loop which seamlessly would bind with the second
>> loop and its
On Tue, 15 Oct 2024 09:11:40 GMT, Raffaello Giulietti
wrote:
>> @rgiulietti Actually, an useful invariant for `remainingZeros` follows
>> directly from its definition: letting `z = max{n : ((intVal * 2^powsOf2) %
>> 10^n) == 0 && n <= scale - preferredScale}`, at the first iteration, it is
>>
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 Mon, 14 Oct 2024 15:44:20 GMT, fabioromano1 wrote:
>> OK, let me give it a try, maybe tomorrow.
>
> @rgiulietti Or maybe "i.e., 5^(2^i) is larger than the largest power of five
> that is still removable from intVal", could it be ok?
While I intuitively understand, and I'm convinced of the cl
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
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 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 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: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 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,
> 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.
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:
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
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 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
Hi Cay,
No problems at all! 🙂 Sharing the background is interesting because people
rarely can see "what didn't work" or "what led to this".
>I don't understand why a short-circuiting integrator is "more capable" than a
>greedy one. And why the "less capable" one would then be the subclass.
Bei
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 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, 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 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 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 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 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 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 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 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 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 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 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: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:
> 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 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 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 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, 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 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 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.
>
1 - 100 of 137 matches
Mail list logo
