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

2022-03-11 Thread Alan Bateman
On Tue, 8 Mar 2022 19:26:41 GMT, Chris Plummer wrote: >> jdb has 3 types of arguments: >> >> 1. Those that are jdb specific, such as -attach, -launch, and -listconnectors >> 2. Those that are passed to the JVM used to run jdb. These are all prefixed >> with -J, and any valid JVM argument can be

Re: RFR: 8282241: Invalid generic signature for redefined classes [v2]

2022-03-11 Thread Alex Menkov
On Fri, 4 Mar 2022 17:12:51 GMT, Alex Menkov wrote: >> JDK-8238048 (fixed in jdk15) moved major_version, minor_version, >> generic_signature_index and source_file_name_index from InstanceKlass to >> ConstantPool. >> We still have some incorrect code in CP merge during class redefinition. >> >>

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

2022-03-11 Thread Kevin Walls
On Tue, 8 Mar 2022 19:26:41 GMT, Chris Plummer wrote: >> jdb has 3 types of arguments: >> >> 1. Those that are jdb specific, such as -attach, -launch, and -listconnectors >> 2. Those that are passed to the JVM used to run jdb. These are all prefixed >> with -J, and any valid JVM argument can be

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

2022-03-11 Thread Andrew Haley
On Thu, 10 Mar 2022 14:09:24 GMT, Anton Kozlov wrote: > > Depending on what the pthread library call does, and if it's a real > > function call into a library, it would be more expensive than that. > > Yes, unfortunately we need something like this. But we don't need to speculate. If thread-lo

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

2022-03-11 Thread Johannes Bechberger
On Fri, 11 Mar 2022 09:33:40 GMT, Andrew Haley wrote: > But we don't need to speculate. If thread-local variables are cheap on MacOS, > and there is no reason why they should be expensive, then we can stop > worrying and just use a thread-local variable for WX state. We can measure > how long

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

2022-03-11 Thread Thomas Stuefe
On Fri, 11 Mar 2022 09:33:40 GMT, Andrew Haley wrote: > We could also redefine SafeFetch on MacOS/AArch64 to not need WX. We could do > this by statically generating SafeFetch on that platform, and it wouldn't be > in the JIT region at all. Why not just do that? Do you mean using inline assemb

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

2022-03-11 Thread Andrew Haley
On Fri, 11 Mar 2022 07:52:16 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

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

2022-03-11 Thread Thomas Stuefe
On Fri, 11 Mar 2022 10:27:25 GMT, Andrew Haley wrote: > On 3/11/22 10:12, Thomas Stuefe wrote: We could also redefine SafeFetch on > MacOS/AArch64 to not need WX. We could do this by statically generating > SafeFetch on that platform, and it wouldn't be in the JIT region at all. Why > not just

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

2022-03-11 Thread Florian Weimer
On Fri, 11 Mar 2022 09:50:22 GMT, Johannes Bechberger wrote: > According to > https://forums.swift.org/t/concurrencys-use-of-thread-local-variables/48654: > "these accesses are just a move from a system register plus a load/store at a > constant offset." Ideally you'd still benchmark that. S

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

2022-03-11 Thread Weijun Wang
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 The security related changes look fine,

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

2022-03-11 Thread Anton Kozlov
On Thu, 10 Mar 2022 18:07:37 GMT, Thomas Stuefe 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 > > > > assum

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

2022-03-11 Thread Anton Kozlov
On Thu, 10 Mar 2022 18:04:50 GMT, Thomas Stuefe wrote: > blocking SIGSEGV and SIGBUS - or other synchronous error signals like SIGFPE > - and then triggering said signal is UB. What happens is OS-dependent. I saw > processes vanishing, or hang, or core. It makes sense, since what is the > kern

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

2022-03-11 Thread Chris Plummer
On Tue, 8 Mar 2022 19:26:41 GMT, Chris Plummer wrote: >> jdb has 3 types of arguments: >> >> 1. Those that are jdb specific, such as -attach, -launch, and -listconnectors >> 2. Those that are passed to the JVM used to run jdb. These are all prefixed >> with -J, and any valid JVM argument can be

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

2022-03-11 Thread Anton Kozlov
On Fri, 11 Mar 2022 07:52:16 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

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

2022-03-11 Thread Thomas Stuefe
On Fri, 11 Mar 2022 16:34:29 GMT, Anton Kozlov wrote: > > blocking SIGSEGV and SIGBUS - or other synchronous error signals like > > SIGFPE - and then triggering said signal is UB. What happens is > > OS-dependent. I saw processes vanishing, or hang, or core. It makes sense, > > since what is t

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

2022-03-11 Thread Thomas Stuefe
On Fri, 11 Mar 2022 10:44:25 GMT, Thomas Stuefe wrote: > > On 3/11/22 10:12, Thomas Stuefe wrote: We could also redefine SafeFetch on > > MacOS/AArch64 to not need WX. We could do this by statically generating > > SafeFetch on that platform, and it wouldn't be in the JIT region at all. > > Why

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

2022-03-11 Thread Chris Plummer
> jdb has 3 types of arguments: > > 1. Those that are jdb specific, such as -attach, -launch, and -listconnectors > 2. Those that are passed to the JVM used to run jdb. These are all prefixed > with -J, and any valid JVM argument can be passed in this manner. > 3. Those that are passed to the deb

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

2022-03-11 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` or

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

2022-03-11 Thread Chris Plummer
On Sat, 12 Mar 2022 05:44:21 GMT, Chris Plummer wrote: >> jdb has 3 types of arguments: >> >> 1. Those that are jdb specific, such as -attach, -launch, and -listconnectors >> 2. Those that are passed to the JVM used to run jdb. These are all prefixed >> with -J, and any valid JVM argument can b

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

2022-03-11 Thread Florian Weimer
On Fri, 11 Mar 2022 23:40:36 GMT, Thomas Stuefe wrote: > I spent some time doing a static implementation of SafeFetch on Linux x64, > and its not super trivial. The problem is that we need to know addresses of > instructions inside that function. I can set labels in assembly, and I can > expor