On 12/03/2022 2:37 am, Anton Kozlov wrote:
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.
On Sat, 12 Mar 2022 12:30:39 GMT, Andrew Haley wrote:
> 1ns
Incidentally, there must be a lot of speculation and bypassing going on there.
I can see 15 cycles of latency, probably 20, so that'd be more like 5ns start
to finish. M1 is a remarkable thing.
-
PR:
On Fri, 11 Mar 2022 12:18:36 GMT, Florian Weimer 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
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
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
>
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
> > > >
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.
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
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
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
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
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
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
> > >
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
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
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
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
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
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
On Thu, 10 Mar 2022 07:09:27 GMT, Anton Kozlov wrote:
> > Interesting. But I would nonetheless create an assertion that checks that
> > there is no nesting in the case without a Thread object. I would this using
> > a thread local nesting counter in the ThreadWXEnable class (incremented in
>
On Thu, 10 Mar 2022 06:00:42 GMT, Thomas Stuefe wrote:
> Arguably we should restore, upon leaving the VM, the state that has been
> present before. Because a native thread may already have modified the wx
> state and overruling it is just rude. But I offhand don't see a way to do
> this since
On Wed, 9 Mar 2022 20:25:02 GMT, Johannes Bechberger
wrote:
> Interesting. But I would nonetheless create an assertion that checks that
> there is no nesting in the case without a Thread object. I would this using a
> thread local nesting counter in the ThreadWXEnable class (incremented in
On Thu, 10 Mar 2022 05:52:48 GMT, Thomas Stuefe wrote:
> Why don't we just switch it on once, for a thread that conceivably may call
> into generated code, and be done with? Why is this fine granular switching
> even needed? I find it difficult to imagine an attack vector that exploits
>
On Wed, 9 Mar 2022 19:03:16 GMT, Anton Kozlov wrote:
>> Johannes Bechberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> current_thread_wx -> ThreadWX
>
>
On Wed, 9 Mar 2022 19:03:16 GMT, Anton Kozlov wrote:
>> Johannes Bechberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> current_thread_wx -> ThreadWX
>
>
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
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
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
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
On Wed, 9 Mar 2022 11:14:09 GMT, David Holmes wrote:
>> Johannes Bechberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> current_thread_wx -> ThreadWX
>
> src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp line 35:
>
>> 33:
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
> 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
32 matches
Mail list logo
