On Fri, 6 Sep 2024 09:31:45 GMT, Yasumasa Suenaga wrote:
> This PR is successor of #20789 . I got some comments in there, then I needed
> to fix in many pooints. And also I have to fix branch name to kick GHA
> automatically (#20789 is named with `pr/`, it meets the condition to skip
> GHA). H
On Thu, 5 Sep 2024 16:10:05 GMT, Gerard Ziemski wrote:
> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemTag` is a more suitable name.
>
> This fix also includes
On Sat, 7 Sep 2024 01:48:39 GMT, Yasumasa Suenaga wrote:
>> This PR is successor of #20789 . I got some comments in there, then I needed
>> to fix in many pooints. And also I have to fix branch name to kick GHA
>> automatically (#20789 is named with `pr/`, it meets the condition to skip
>> GHA
On Sat, 7 Sep 2024 01:04:14 GMT, Chris Plummer wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Update test/hotspot/jtreg/serviceability/sa/libupcall.c
>>
>>Co-authored-by: Jorn Vernee
>> - Update
>
> This PR is successor of #20789 . I got some comments in there, then I needed
> to fix in many pooints. And also I have to fix branch name to kick GHA
> automatically (#20789 is named with `pr/`, it meets the condition to skip
> GHA). Hence I've opened another PR for this JBS issue.
>
> This P
On Fri, 6 Sep 2024 15:29:18 GMT, Jorn Vernee wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove blank lines
>
> Looks great! Thanks for implementing the JFA-based stack walking.
>
> Please wait for another
On Sat, 7 Sep 2024 00:07:27 GMT, Yasumasa Suenaga wrote:
>> This PR is successor of #20789 . I got some comments in there, then I needed
>> to fix in many pooints. And also I have to fix branch name to kick GHA
>> automatically (#20789 is named with `pr/`, it meets the condition to skip
>> GHA
On Fri, 6 Sep 2024 05:24:18 GMT, David Holmes wrote:
> I've taken an initial look through but there is an awful lot to try and
> digest here. I've flagged numerous typos and minor nits.
>
> One general query: does this stuff work if the user defines their own initial
> application classloader?
> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> **Overview**
>
> - A new `-XX:+AOTClassLinking` flag is added. See [JEP
> 498](https://bugs.openjdk.org/browse/JDK-8315737) and the
> [CSR](https://bugs.openjdk.org/bro
> This PR is successor of #20789 . I got some comments in there, then I needed
> to fix in many pooints. And also I have to fix branch name to kick GHA
> automatically (#20789 is named with `pr/`, it meets the condition to skip
> GHA). Hence I've opened another PR for this JBS issue.
>
> This P
On Fri, 6 Sep 2024 05:10:42 GMT, David Holmes wrote:
>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> **Overview**
>>
>> - A new `-XX:+AOTClassLinking` flag is added. See [JEP
>> 498](https://bugs.openjdk.org/bro
On Fri, 6 Sep 2024 05:07:09 GMT, David Holmes wrote:
>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> **Overview**
>>
>> - A new `-XX:+AOTClassLinking` flag is added. See [JEP
>> 498](https://bugs.openjdk.org/bro
On Thu, 5 Sep 2024 16:10:05 GMT, Gerard Ziemski wrote:
> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemTag` is a more suitable name.
>
> This fix also includes
Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
`MEMFLAGS` implies that we can use more than one at the same time, but those
are exclusive values, so `MemTag` is a more suitable name.
This fix also includes a cleanup of all the related parameter names and local
variable name
On Wed, 4 Sep 2024 14:17:08 GMT, Robert Toyonaga wrote:
> ### Summary
> This PR just replaces `ThreadCritical` with a lock specific to NMT.
> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
> I've implemented the new lock with a semaphore so that it can be used early
On Fri, 6 Sep 2024 20:00:48 GMT, Leonid Mesnik wrote:
>> test/lib/jdk/test/lib/thread/TestThreadFactory.java line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2021, 2024, Oracle and/or its affiliates. All rights
>>> reserved.
>>
>> Should just be 2024.
>
> I copied file from JDIThreadFactory,java (
On Fri, 6 Sep 2024 18:56:32 GMT, Leonid Mesnik wrote:
> Field watch tests updated to be executed with virtual threads when virtual
> test thread factory enabled.I added
> jdk.test.lib.thread.TestThreadFactory
> to created test threads so they support virtual thread factory jtreg plugin.
>
> It
On Fri, 6 Sep 2024 19:52:19 GMT, Chris Plummer wrote:
>> Field watch tests updated to be executed with virtual threads when virtual
>> test thread factory enabled.I added
>> jdk.test.lib.thread.TestThreadFactory
>> to created test threads so they support virtual thread factory jtreg plugin.
>>
On Fri, 6 Sep 2024 18:56:32 GMT, Leonid Mesnik wrote:
> Field watch tests updated to be executed with virtual threads when virtual
> test thread factory enabled.I added
> jdk.test.lib.thread.TestThreadFactory
> to created test threads so they support virtual thread factory jtreg plugin.
>
> It
Field watch tests updated to be executed with virtual threads when virtual test
thread factory enabled.I added
jdk.test.lib.thread.TestThreadFactory
to created test threads so they support virtual thread factory jtreg plugin.
It might makes sense to use it in different tests so virtual threads a
On Wed, 4 Sep 2024 21:17:28 GMT, Gerard Ziemski wrote:
>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>>
>> `MEMFLAGS` implies that we can use more than one at the same time, but those
>> are exclusive values, so `MemType` is much more suitable name.
>>
>> There is a b
On Fri, 6 Sep 2024 08:25:07 GMT, Kevin Walls wrote:
>> Deprecation annotations and warnings on starting the tool(s).
>> Handle man page in a separate issue.
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Correction to test
On Fri, 6 Sep 2024 09:31:45 GMT, Yasumasa Suenaga wrote:
> This PR is successor of #20789 . I got some comments in there, then I needed
> to fix in many pooints. And also I have to fix branch name to kick GHA
> automatically (#20789 is named with `pr/`, it meets the condition to skip
> GHA). H
On Mon, 2 Sep 2024 10:29:40 GMT, Yasumasa Suenaga wrote:
>> I attempted to check stack trace in the core generated by [SEGV example in
>> upcall](https://github.com/YaSuenag/garakuta/blob/841452d9176dab1ddbb552009c180530eb81190b/NativeSEGV/ffm/upcall/src/main/java/com/yasuenag/garakuta/nativeseg
On Fri, 30 Aug 2024 09:14:11 GMT, Yasumasa Suenaga wrote:
> I attempted to check stack trace in the core generated by [SEGV example in
> upcall](https://github.com/YaSuenag/garakuta/blob/841452d9176dab1ddbb552009c180530eb81190b/NativeSEGV/ffm/upcall/src/main/java/com/yasuenag/garakuta/nativesegv
This PR is successor of #20789 . I got some comments in there, then I needed to
fix in many pooints. And also I have to fix branch name to kick GHA
automatically (#20789 is named with `pr/`, it meets the condition to skip GHA).
Hence I've opened another PR for this JBS issue.
This PR has been u
On Thu, 5 Sep 2024 17:03:37 GMT, Kevin Walls wrote:
>> Remove very very old serialization compatibility logic from JMX.
>>
>> This relates to keeping the JDK's JMX implementation compatible with JMX
>> versions from when JMX was a separate component, before being integrated
>> into JDK 5. It
On Wed, 4 Sep 2024 21:17:28 GMT, Gerard Ziemski wrote:
>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>>
>> `MEMFLAGS` implies that we can use more than one at the same time, but those
>> are exclusive values, so `MemType` is much more suitable name.
>>
>> There is a b
On Fri, 6 Sep 2024 10:47:29 GMT, Kevin Walls wrote:
> The ObjectName String "jdk.management:type=VirtualThreadScheduler" could have
> a public static final definition somewhere in future, but there is no obvious
> home, e.g. java.lang.management.ManagementFactory is in the wrong package.
> Som
On Thu, 5 Sep 2024 17:54:46 GMT, Alan Bateman wrote:
>> This PR proposes to add a JDK-specific monitoring and management interface
>> for the virtual thread scheduler. The interface is named
>> [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.manageme
On Thu, 5 Sep 2024 12:28:53 GMT, David Holmes wrote:
>> src/hotspot/os/windows/os_windows.cpp line 5327:
>>
>>> 5325:
>>> 5326: char* result = nullptr;
>>> 5327: ALLOW_C_FUNCTION(::_fullpath, result = ::_fullpath(outbuf,
>>> filename, outbuflen);)
>>
>> Would this work for non-Latin-1 utf
On Fri, 6 Sep 2024 08:32:01 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/nmt/nmtCommon.hpp line 153:
>>
>>> 151: intx const current = os::current_thread_id();
>>> 152: intx const owner = Atomic::load(&_owner);
>>> 153: assert(current != owner, "Lock is not reentrant");
>>
>
On Thu, 5 Sep 2024 21:10:27 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.
>> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
>> I've implemented the new lock with a semaphore so that it can be used e
On Fri, 6 Sep 2024 08:51:31 GMT, Johan Sjölen wrote:
> Thank you Robert.
>
> I think that the `MemoryFileTracker`'s locker should probably also be
> replaced with this semaphore, as in the future we have plans to have a
> globally shared `NativeCallStackStorage`.
+1
-
PR Comment
On Wed, 4 Sep 2024 14:17:08 GMT, Robert Toyonaga wrote:
> ### Summary
> This PR just replaces `ThreadCritical` with a lock specific to NMT.
> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
> I've implemented the new lock with a semaphore so that it can be used early
On Wed, 4 Sep 2024 14:17:08 GMT, Robert Toyonaga wrote:
> ### Summary
> This PR just replaces `ThreadCritical` with a lock specific to NMT.
> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
> I've implemented the new lock with a semaphore so that it can be used early
On Fri, 6 Sep 2024 04:27:44 GMT, David Holmes wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.
>> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
>> I've implemented the new lock with a semaphore so that it can be used earl
On Thu, 5 Sep 2024 18:18:06 GMT, Chris Plummer wrote:
> Make sure you get good test coverage of you OutputAnalyzer change.
That was the right thing to say, as I didn't have it quite right.
stderrShouldBeEmptyIgnoreDeprecatedWarnings() needs to work if both kinds of
deprecation message occurre
> Deprecation annotations and warnings on starting the tool(s).
> Handle man page in a separate issue.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Correction to test library change
-
Changes:
- all: https://git.open
39 matches
Mail list logo
