Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

2022-03-10 Thread Johannes Bechberger
On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger wrote: >> The WXMode for the current thread (on MacOS aarch64) is currently stored in >> the thread class which is unnecessary as the WXMode is bound to the current >> OS thread, not the current instance of the thread class. >> This pull

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v7]

2022-03-10 Thread Johannes Bechberger
> The WXMode for the current thread (on MacOS aarch64) is currently stored in > the thread class which is unnecessary as the WXMode is bound to the current > OS thread, not the current instance of the thread class. > This pull request moves the storage of the current WXMode into a thread local

Re: RFR: 8282691: add jdb "-R" option for passing any argument to the launched debuggee process

2022-03-10 Thread Chris Plummer
On Sun, 6 Mar 2022 20:35:04 GMT, Alan Bateman wrote: >>> `jshell --enable-preview` allows developers to use preview features in the >>> REPL, having `jdb --enable-preview` and passing it through to the launching >>> debugee would be useful too. >> >> Is that the same as `-R--enable-preview`

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

2022-03-10 Thread David Holmes
On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger wrote: >> The WXMode for the current thread (on MacOS aarch64) is currently stored in >> the thread class which is unnecessary as the WXMode is bound to the current >> OS thread, not the current instance of the thread class. >> This pull

Re: RFR: 8282314: nsk/jvmti/SuspendThread/suspendthrd003 may leak memory

2022-03-10 Thread Alex Menkov
On Wed, 9 Mar 2022 20:41:37 GMT, Daniel D. Daugherty wrote: > A trivial fix to solve a memory leak/memory pinning for long runs of > suspendthrd003. > > See the bug report for the gory analysis details. > > This fix was included in my jdk-19+12 stress runs so the updated test was > executed

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

2022-03-10 Thread David Holmes
On Thu, 10 Mar 2022 07:31:47 GMT, Anton Kozlov wrote: > How in general safe to call SafeFetch on a native thread that has no Thread > object? The JVM has not initialized the thread, so there could be no JVM > signal handler installed. @AntonKozlov Signal handlers are per-process not

Re: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test [v4]

2022-03-10 Thread Aleksey Shipilev
On Tue, 8 Mar 2022 19:16:25 GMT, Leonid Mesnik wrote: >> Aleksey Shipilev 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 seven additional >>

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10

2022-03-10 Thread Daniel Fuchs
On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For simple webserver resource files - should the copyright year be 2022? - PR: https://git.openjdk.java.net/jdk/pull/7765

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

2022-03-10 Thread Anton Kozlov
On Thu, 10 Mar 2022 10:17:31 GMT, David Holmes wrote: > Signal handlers are per-process not per-thread, so a thread need not be > attached to the VM for our signal handlers to get involved - that is why they > call Thread::current_or_null_safe(). Oh, right, thanks. I was too concentrated on

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

2022-03-10 Thread Anton Kozlov
On Thu, 10 Mar 2022 12:41:11 GMT, Thomas Stuefe wrote: > You are saying that Java Threads may write too. And CompilerThreads, in the > case of SafeFetch at least, may run generated code. So switching has to be > done as a stack mark. Have I gotten this right? Right. > Depending on what the

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

2022-03-10 Thread David Holmes
On Thu, 10 Mar 2022 12:31:06 GMT, Anton Kozlov wrote: > The signal mask is per-thread, and a native thread may block the JVM signal. @AntonKozlov the signal from safefetch (if it is not safe) is a SIGSEGV or SIGBUS. If these signals happen to be blocked and we raise the signal synchronously

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

2022-03-10 Thread Thomas Stuefe
On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger wrote: >> The WXMode for the current thread (on MacOS aarch64) is currently stored in >> the thread class which is unnecessary as the WXMode is bound to the current >> OS thread, not the current instance of the thread class. >> This pull

Re: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test [v5]

2022-03-10 Thread Leonid Mesnik
On Wed, 9 Mar 2022 10:11:41 GMT, Aleksey Shipilev wrote: >> There are few bugs in SetBreakpoint when it reaches for metaspace >> allocation, notably >> [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and >> [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This

Re: RFR: 8282314: nsk/jvmti/SuspendThread/suspendthrd003 may leak memory

2022-03-10 Thread Leonid Mesnik
On Wed, 9 Mar 2022 20:41:37 GMT, Daniel D. Daugherty wrote: > A trivial fix to solve a memory leak/memory pinning for long runs of > suspendthrd003. > > See the bug report for the gory analysis details. > > This fix was included in my jdk-19+12 stress runs so the updated test was > executed

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10

2022-03-10 Thread Daniel Fuchs
On Thu, 10 Mar 2022 17:00:09 GMT, Naoto Sato wrote: > IIRC, localized resource files should have the same copyright year as the > base English one. That's what I was told by the l10n engineer when I had the > same comment. Thanks Naoto! I have no objection then. - PR:

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10

2022-03-10 Thread Naoto Sato
On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment. - PR:

Re: RFR: 8282314: nsk/jvmti/SuspendThread/suspendthrd003 may leak memory

2022-03-10 Thread Daniel D . Daugherty
On Thu, 10 Mar 2022 04:52:46 GMT, David Holmes wrote: >> The fix looks fine, but what about StopAtExit? That test seemed to use a lot >> more memory than suspendthrd003. > > @plummercj - see https://bugs.openjdk.java.net/browse/JDK-8282704 for > StopAtExit. @dholmes-ora, @plummercj and

Re: RFR: 8282314: nsk/jvmti/SuspendThread/suspendthrd003 may leak memory

2022-03-10 Thread Daniel D . Daugherty
On Wed, 9 Mar 2022 20:41:37 GMT, Daniel D. Daugherty wrote: > A trivial fix to solve a memory leak/memory pinning for long runs of > suspendthrd003. > > See the bug report for the gory analysis details. > > This fix was included in my jdk-19+12 stress runs so the updated test was > executed

Re: RFR: 8282314: nsk/jvmti/SuspendThread/suspendthrd003 may leak memory

2022-03-10 Thread Daniel D . Daugherty
On Thu, 10 Mar 2022 16:17:22 GMT, Leonid Mesnik wrote: >> A trivial fix to solve a memory leak/memory pinning for long runs of >> suspendthrd003. >> >> See the bug report for the gory analysis details. >> >> This fix was included in my jdk-19+12 stress runs so the updated test was >>

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

2022-03-10 Thread Naoto Sato
On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > moved CurrencyNames changes to jdk.localedata

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

2022-03-10 Thread Chris Plummer
On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > moved CurrencyNames changes to jdk.localedata

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

2022-03-10 Thread Alisen Chung
> msg drop for jdk19, Mar 9, 2022 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: moved CurrencyNames changes to jdk.localedata - Changes: - all: https://git.openjdk.java.net/jdk/pull/7765/files - new:

Re: RFR: 8282314: nsk/jvmti/SuspendThread/suspendthrd003 may leak memory

2022-03-10 Thread Mikhailo Seledtsov
On Wed, 9 Mar 2022 20:41:37 GMT, Daniel D. Daugherty wrote: > A trivial fix to solve a memory leak/memory pinning for long runs of > suspendthrd003. > > See the bug report for the gory analysis details. > > This fix was included in my jdk-19+12 stress runs so the updated test was > executed

Re: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test [v5]

2022-03-10 Thread Aleksey Shipilev
On Wed, 9 Mar 2022 10:11:41 GMT, Aleksey Shipilev wrote: >> There are few bugs in SetBreakpoint when it reaches for metaspace >> allocation, notably >> [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and >> [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This

Integrated: 8282170: JVMTI SetBreakpoint metaspace allocation test

2022-03-10 Thread Aleksey Shipilev
On Mon, 21 Feb 2022 10:55:42 GMT, Aleksey Shipilev wrote: > There are few bugs in SetBreakpoint when it reaches for metaspace allocation, > notably [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and > [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This adds

Re: RFR: 8282314: nsk/jvmti/SuspendThread/suspendthrd003 may leak memory

2022-03-10 Thread Daniel D . Daugherty
On Thu, 10 Mar 2022 18:11:58 GMT, Mikhailo Seledtsov wrote: >> A trivial fix to solve a memory leak/memory pinning for long runs of >> suspendthrd003. >> >> See the bug report for the gory analysis details. >> >> This fix was included in my jdk-19+12 stress runs so the updated test was >>

Integrated: 8282314: nsk/jvmti/SuspendThread/suspendthrd003 may leak memory

2022-03-10 Thread Daniel D . Daugherty
On Wed, 9 Mar 2022 20:41:37 GMT, Daniel D. Daugherty wrote: > A trivial fix to solve a memory leak/memory pinning for long runs of > suspendthrd003. > > See the bug report for the gory analysis details. > > This fix was included in my jdk-19+12 stress runs so the updated test was > executed

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

2022-03-10 Thread Thomas Stuefe
On Thu, 10 Mar 2022 12:31:06 GMT, Anton Kozlov wrote: > > Signal handlers are per-process not per-thread, so a thread need not be > > attached to the VM for our signal handlers to get involved - that is why > > they call Thread::current_or_null_safe(). > > Oh, right, thanks. I was too

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

2022-03-10 Thread Thomas Stuefe
On Thu, 10 Mar 2022 14:09:24 GMT, Anton Kozlov wrote: > > > Is it possible to change SafeFetch only? Switch to WXExec before calling > > > the stub and switch WXWrite back unconditionally? We won't need to > > > provide assert in ThreadWXEnable. But SafeFetch can check the assumption > > >

Re: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test [v5]

2022-03-10 Thread Chris Plummer
On Wed, 9 Mar 2022 10:11:41 GMT, Aleksey Shipilev wrote: >> There are few bugs in SetBreakpoint when it reaches for metaspace >> allocation, notably >> [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and >> [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This

Re: RFR: 8282852: Debug agent asserts in classTrack_addPreparedClass() [v2]

2022-03-10 Thread Chris Plummer
On Wed, 9 Mar 2022 07:52:37 GMT, Chris Plummer wrote: >> Fix incorrect assert that assumed the debug agent should never see a >> ClassPrepare event for a class that it already saw when calling >> GetLoadedClasses. Details can be found in the bug description. > > Chris Plummer has updated the

Integrated: 8282852: Debug agent asserts in classTrack_addPreparedClass()

2022-03-10 Thread Chris Plummer
On Wed, 9 Mar 2022 06:14:21 GMT, Chris Plummer wrote: > Fix incorrect assert that assumed the debug agent should never see a > ClassPrepare event for a class that it already saw when calling > GetLoadedClasses. Details can be found in the bug description. This pull request has now been