On Fri, 8 Sep 2023 10:58:23 GMT, Matthias Baesken wrote:
> So probably we could avoid changing VMManagementImpl.java because it is not
> needed any more at least in jdk-head .
It's a JDK internal class so should never have been used directly. I can't
imagine what might be using a JDK internal
On Fri, 8 Sep 2023 01:07:17 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
On Fri, 8 Sep 2023 08:26:16 GMT, Matthias Baesken wrote:
> There are some remaining places in 'general' JDK code (= code not related to
> e.g. a specific tool) getting properties like :
>
> osName = System.getProperty(os.name)
>
>
On Fri, 8 Sep 2023 08:26:16 GMT, Matthias Baesken wrote:
> There are some remaining places in 'general' JDK code (= code not related to
> e.g. a specific tool) getting properties like :
>
> osName = System.getProperty(os.name)
>
>
On Fri, 8 Sep 2023 07:44:21 GMT, Matthias Baesken wrote:
> We could do this mid-term in some follow up action.
It shouldn't be hard to try it. If it works out then it would mean this old
crufty code goes away and the JDK is in a better place. If it doesn't work out
then the a plan B would be
On Mon, 4 Sep 2023 11:57:47 GMT, Matthias Baesken wrote:
>>> Hi Alan , Your assumption 'I assume the use of System.getProperty is
>>> problematic when running with a SM.' is most likely correct.
>>
>> You'll need to test with a SM that denies reading the system property to be
>> sure. There
On Thu, 31 Aug 2023 21:31:40 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX512 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
On Thu, 31 Aug 2023 21:31:40 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX512 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
On Wed, 6 Sep 2023 07:02:53 GMT, Alan Bateman wrote:
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` are slow
> when there is a large number of threads.
>
> The thread dump can be sped up significantly with some small changes:
> - Using println rather t
On Wed, 6 Sep 2023 07:02:53 GMT, Alan Bateman wrote:
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` are slow
> when there is a large number of threads.
>
> The thread dump can be sped up significantly with some small changes:
> - Using println rather t
`HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` are slow
when there is a large number of threads.
The thread dump can be sped up significantly with some small changes
- Using println rather than format when print thread info and thread stacks
- Create the print stream
On Wed, 6 Sep 2023 21:38:39 GMT, Brian Burkhalter wrote:
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
Would it be possible to summarise how this behaves when File just presents this
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote:
> I think it's useful if trying to trace the calls (i.e. set to 0ms).
> Apparently the security manager was being used for that by some.
The SM isn't called once connected so I don't think anyone could have every
done that. Yes, you could
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote:
> I think it's useful if trying to trace the calls (i.e. set to 0ms).
> Apparently the security manager was being used for that by some.
The SM isn't called once connected so I don't think anyone could have every
done that. Yes, you could
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote:
> I think it's useful if trying to trace the calls (i.e. set to 0ms).
> Apparently the security manager was being used for that by some.
The SM isn't called once connected so I don't think anyone could have every
done that. Yes, you could
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote:
> I think it's useful if trying to trace the calls (i.e. set to 0ms).
> Apparently the security manager was being used for that by some.
The SM isn't called once connected so I don't think anyone could have every
done that. Yes, you could
On 06/09/2023 16:17, Volker Simonis wrote:
:
I'm familiar with JEP 260. But wouldn't you agree that an
"encapsulated" monitoring API is an oxymoron? A monitoring API is by
design intended for external usage and completely useless to the
platform itself. There's no single usage of the
On 06/09/2023 16:17, Volker Simonis wrote:
:
I'm familiar with JEP 260. But wouldn't you agree that an
"encapsulated" monitoring API is an oxymoron? A monitoring API is by
design intended for external usage and completely useless to the
platform itself. There's no single usage of the
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
JFR thread sampler to skip sampling when
> it samples during a transition.
>
> Testing: tier1-5
Alan Bateman 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 requ
JFR thread sampler to skip sampling when
> it samples during a transition.
>
> Testing: tier1-5
Alan Bateman 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 requ
On 06/09/2023 14:02, Volker Simonis wrote:
:
I wonder why "sun.management" was encapsulated in the first place? I
understand that it is not an "officially supported" API, but I find it
still quite useful.
sun.management.* is JDK internal so not something for code outside the
JDK to use
On 06/09/2023 14:02, Volker Simonis wrote:
:
I wonder why "sun.management" was encapsulated in the first place? I
understand that it is not an "officially supported" API, but I find it
still quite useful.
sun.management.* is JDK internal so not something for code outside the
JDK to use
On Wed, 6 Sep 2023 11:16:13 GMT, Thomas Obermeier wrote:
>> test/lib/jdk/test/lib/NetworkConfiguration.java line 189:
>>
>>> 187: //if (Platform.isAix() && isIPv6Available() &&
>>> !hasIp6Addresses(nif)) {
>>> 188: //return false;
>>> 189: //}
>>
>> Can
On Wed, 6 Sep 2023 11:19:08 GMT, Thomas Obermeier wrote:
>> 8315651: Stop hiding AIX specific multicast socket errors via
>> NetworkConfiguration (aix)
>
> Thomas Obermeier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> remove instead of
On Wed, 6 Sep 2023 09:40:47 GMT, Thomas Obermeier wrote:
> 8315651: Stop hiding AIX specific multicast socket errors via
> NetworkConfiguration (aix)
test/lib/jdk/test/lib/NetworkConfiguration.java line 189:
> 187: //if (Platform.isAix() && isIPv6Available() &&
>
On Wed, 6 Sep 2023 08:18:45 GMT, JoKern65 wrote:
> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) ,
> the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java;
> The problem was described in
>
On Wed, 6 Sep 2023 08:18:45 GMT, JoKern65 wrote:
> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) ,
> the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java;
> The problem was described in
>
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test
On Fri, 1 Sep 2023 14:59:19 GMT, Jaikiran Pai wrote:
> I asked for Mark's and Joe's inputs on this in the linked JBS issue
> https://bugs.openjdk.org/browse/JDK-8233160. Mark has suggested that we keep
> this `java.vendor.url.bug` system property non-optional and also not to add
> any
On Fri, 1 Sep 2023 11:32:45 GMT, Markus Grönlund wrote:
>> Thanks. One other thing that I see when more testing with generational ZGC
>> is that ZPageAllocator::alloc_page will record an event and this can happen
>> during a mount transition. So I think JfrStackTrace::record also needs to
>>
On Fri, 1 Sep 2023 11:32:45 GMT, Markus Grönlund wrote:
>> Thanks. One other thing that I see when more testing with generational ZGC
>> is that ZPageAllocator::alloc_page will record an event and this can happen
>> during a mount transition. So I think JfrStackTrace::record also needs to
>>
JFR thread sampler to skip sampling when
> it samples during a transition.
>
> Testing: tier1-5
Alan Bateman 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 reque
JFR thread sampler to skip sampling when
> it samples during a transition.
>
> Testing: tier1-5
Alan Bateman 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 reque
On Fri, 28 Jul 2023 18:41:48 GMT, Joe Wang wrote:
> Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to
> specify how DTDs are handled. This property is uniformly supported across the
> JDK XML libraries. It complements, rather than replaces, the existing
> properties
On Fri, 1 Sep 2023 23:12:28 GMT, Justin Lu wrote:
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315558)
> which is a conformance change to document some exceptions in the
> specification of java.text.StringCharacterIterator.
@justin-curtis-lu You are correct that it
On Fri, 1 Sep 2023 13:10:19 GMT, Matthias Baesken wrote:
> Hi Alan , Your assumption 'I assume the use of System.getProperty is
> problematic when running with a SM.' is most likely correct.
You'll need to test with a SM that denies reading the system property to be
sure. There are classes in
On Fri, 1 Sep 2023 12:36:28 GMT, Matthias Baesken wrote:
>> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
>>
>> [JShell] Exception in thread "main" java.lang.IllegalStateException:
>> java.util.prefs.BackingStoreException: Couldn't get file lock.
>> [JShell] at
On Fri, 1 Sep 2023 10:47:25 GMT, Markus Grönlund wrote:
>> Just to add that Patricio suggested today to run the stress tests with
>> -Xint and that does lead to triggering the assert quickly when the thread is
>> sampled in native. There are several native methods that are
>>
On Fri, 1 Sep 2023 10:47:25 GMT, Markus Grönlund wrote:
>> Just to add that Patricio suggested today to run the stress tests with
>> -Xint and that does lead to triggering the assert quickly when the thread is
>> sampled in native. There are several native methods that are
>>
On Fri, 25 Aug 2023 09:49:20 GMT, Alan Bateman wrote:
>> I want to add a log output similar to JDK-8301627 to Runtime.halt().
>> To avoid double logging of Runtime.exit(), add a flag to indicate whether
>> logging was done, and fix it so that logging is done only once.
>&
On Thu, 31 Aug 2023 17:09:40 GMT, Mandy Chung wrote:
>> 8268829: Provide an optimized way to walk the stack with Class object only
>>
>> `StackWalker::walk` creates one `StackFrame` per frame and the current
>> implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per
On Thu, 31 Aug 2023 14:29:41 GMT, iaroslavski wrote:
> Alan, you mentioned that DualPivotQuicksort will need detailed review. Can we
> go ahead and start reviewing? Laurent checked performance, JMH results look
> fine.
As before, I think the main question with this change is whether adding
On Thu, 31 Aug 2023 17:31:34 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 415:
>>
>>> 413: } else {
>>> 414: assert(NATIVE_SAMPLE == type, "invariant");
>>> 415: if (thread_state_in_native(thread) &&
>>>
On Thu, 31 Aug 2023 17:31:34 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 415:
>>
>>> 413: } else {
>>> 414: assert(NATIVE_SAMPLE == type, "invariant");
>>> 415: if (thread_state_in_native(thread) &&
>>>
On Thu, 31 Aug 2023 12:13:40 GMT, Adam Sotona wrote:
> ModuleTarget and ModuleResolution attributes were flagged as 'allow multiple'
> in the Classfile API.
> This patch removed the flags and allows at most one instance of each
> attribute.
>
> Please review.
>
> Thanks,
> Adam
Thanks for
On Thu, 31 Aug 2023 10:38:32 GMT, Markus Grönlund wrote:
>> In the virtual thread implementation, thread identity switches to the
>> carrier before freezing and switches back to the virtual thread after
>> thawing. This was a forced move due to issues getting JVMTI to work with
>> virtual
On Thu, 31 Aug 2023 10:38:32 GMT, Markus Grönlund wrote:
>> In the virtual thread implementation, thread identity switches to the
>> carrier before freezing and switches back to the virtual thread after
>> thawing. This was a forced move due to issues getting JVMTI to work with
>> virtual
On Thu, 31 Aug 2023 06:53:45 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address
> https://bugs.openjdk.org/browse/JDK-8233160?
>
> It has been noted in https://bugs.openjdk.org/browse/JDK-8232753 that:
>
>> The java.vendor.url.bug property has been
On Wed, 30 Aug 2023 16:29:31 GMT, Mandy Chung wrote:
> Indeed, Set.of factory methods are easy to use. I'm okay with taking it out.
It would be easy to add in the future if needed, say if more options were
introduced and the common case requires 2 or more options.
-
PR Comment:
In the virtual thread implementation, thread identity switches to the carrier
before freezing and switches back to the virtual thread after thawing. This was
a forced move due to issues getting JVMTI to work with virtual threads. JVMTI
can now hide events during transitions so we can invert the
In the virtual thread implementation, thread identity switches to the carrier
before freezing and switches back to the virtual thread after thawing. This was
a forced move due to issues getting JVMTI to work with virtual threads. JVMTI
can now hide events during transitions so we can invert the
On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote:
> I wouldn't be opposed to a change that:
>
> * Keeps the `createJavaProcessBuilder` name
> * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> * Removes
On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote:
> I wouldn't be opposed to a change that:
>
> * Keeps the `createJavaProcessBuilder` name
> * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> * Removes
On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote:
> I wouldn't be opposed to a change that:
>
> * Keeps the `createJavaProcessBuilder` name
> * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> * Removes
On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote:
> I wouldn't be opposed to a change that:
>
> * Keeps the `createJavaProcessBuilder` name
> * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> * Removes
On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote:
> I wouldn't be opposed to a change that:
>
> * Keeps the `createJavaProcessBuilder` name
> * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> * Removes
On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote:
> I wouldn't be opposed to a change that:
>
> * Keeps the `createJavaProcessBuilder` name
> * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> * Removes
On Wed, 30 Aug 2023 20:57:43 GMT, Mandy Chung wrote:
> Loom added a special filtering of Continuation.yield0 in stack walker. After
> the initial implementation, JDK-8304919 marks the yielding and entering
> methods with `@Hidden` and hidden frames are filtered by stack walker by
> default.
On Wed, 30 Aug 2023 15:03:27 GMT, Daniel Fuchs wrote:
>> Mandy Chung has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - update mode to be int rather than long
>> - update tests
>> - Review feedback on javadoc
>
>
On Wed, 30 Aug 2023 12:02:12 GMT, chenggwang wrote:
> Hi Can anyone help me to review this PR @sormuras @asotona or any other
> reviewer?
I think you first need to make a case for changing the CyclicBarrier API as
opposed to dealing with the phases in your BarrierAction or using the Phaser
On Wed, 30 Aug 2023 00:37:26 GMT, Srinivas Vamsi Parasa
wrote:
> Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is
> triggering the intrinsic without additional flags
Just to add that Sorting.java has short and long run modes. The default when
running with jtreg
On Wed, 30 Aug 2023 00:37:26 GMT, Srinivas Vamsi Parasa
wrote:
> Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is
> triggering the intrinsic without additional flags
Just to add that Sorting.java has short and long run modes. The default when
running with jtreg
On Tue, 29 Aug 2023 20:51:56 GMT, Mandy Chung wrote:
>> 8268829: Provide an optimized way to walk the stack with Class object only
>>
>> `StackWalker::walk` creates one `StackFrame` per frame and the current
>> implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX512 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX512 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
On Tue, 29 Aug 2023 12:35:19 GMT, Severin Gehwolf wrote:
> @AlanBateman Gentle ping.
On my list, it's a lot to get through and a number of aspects to this that I
think will require refinement and discussion.
-
PR Comment:
On Tue, 29 Aug 2023 16:59:22 GMT, Daniel Fuchs wrote:
>> how about "s/filtering/excluding"?
>
> Yes - that's better.
The example use filter so it might be better to have the text use the same
word, up to you, I think "filtering out known implementation classes" works too.
-
PR
On Tue, 29 Aug 2023 13:46:08 GMT, Matthias Baesken wrote:
> The sun/tools/jhsdb tests have issues when we run them concurrently .
> So add a related config to TEST.root.
This looks okay to me
-
Marked as reviewed by alanb (Reviewer).
PR Review:
On Tue, 29 Aug 2023 00:16:40 GMT, Mandy Chung wrote:
>> 8268829: Provide an optimized way to walk the stack with Class object only
>>
>> `StackWalker::walk` creates one `StackFrame` per frame and the current
>> implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per
On Mon, 28 Aug 2023 16:31:06 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this PR which updates zlib from 1.2.13 to 1.3 in openJDK
>
> The [Zlib Data Compression Library](https://github.com/madler/zlib ) has
> released Zlib 1.3 on August 18, 2023.
>
> There are a [small number of
On Mon, 28 Aug 2023 07:28:48 GMT, Matthias Baesken wrote:
> Hi Alan , when adding the test group sun/tools/jhsdb in TEST.root to the
> exclusiveAccess.dirs , I cannot see the error any more. So it seems your
> suggestions is correct .
My command was actually wondering why we didn't have a
On Mon, 28 Aug 2023 17:15:36 GMT, Lance Andersen wrote:
> It was a clean copy(which I have been able to do as of zlib 1.2.13). Sorry I
> should have mentioned this in the PR request
That's okay, I just wanted to check to be sure that the ChangeLog_java (renamed
adler32.c -> zadler32.c, crc32c
On Mon, 28 Aug 2023 16:31:06 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this PR which updates zlib from 1.2.13 to 1.3 in openJDK
>
> The [Zlib Data Compression Library](https://github.com/madler/zlib ) has
> released Zlib 1.3 on August 18, 2023.
>
> There are a [small number of
On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman wrote:
>>> Something fishy here, is this working around a bug in GraaVM native image
>>> or why does this change need to be in JDK?
>>
>> I've now realized that the bug had an incorrect statement in the
>>
On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman wrote:
>>> Something fishy here, is this working around a bug in GraaVM native image
>>> or why does this change need to be in JDK?
>>
>> I've now realized that the bug had an incorrect statement in the
>>
On Fri, 25 Aug 2023 07:04:50 GMT, Vladimir Petko wrote:
>> 8314491: Linux: jexec launched via PATH fails to find java
>
> Vladimir Petko 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
This looks fun! It's probably best to bring this to loom-dev. In its
archives you'll find several discussions about generators as several
people have been interested in that topic. Even when thread confined,
the main concern has been that exotic control flow yields leads to
surprising
On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote:
> yes this is of course AIX specific. However I found something that might be
> similar on Windows, there we have in case of successful LoadLibrary in
> os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not
>
On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote:
> yes this is of course AIX specific. However I found something that might be
> similar on Windows, there we have in case of successful LoadLibrary in
> os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not
>
On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote:
> yes this is of course AIX specific. However I found something that might be
> similar on Windows, there we have in case of successful LoadLibrary in
> os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not
>
On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote:
> yes this is of course AIX specific. However I found something that might be
> similar on Windows, there we have in case of successful LoadLibrary in
> os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not
>
On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote:
> yes this is of course AIX specific. However I found something that might be
> similar on Windows, there we have in case of successful LoadLibrary in
> os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not
>
Vote: yes
Vote: yes
Vote: yes
1201 - 1300 of 18238 matches
Mail list logo