Is it possible to stop a specific application thread?

[Lindenmaier, Goetz]

Hi David,

> So a global safepoint still has to iterate the Threads list to update 
> every individual field?
Yes, but that can be done in parallel.  It does not do measurable harm
In our  VM.
If you really want to improve on this, you could use two pages:
one for the normal safepoints that is in the thread's field per default.
Here you change the poisoning of the page.
The second is always unaccessible, and you write it's address into the
threads field if you want to stop a single thread.

I think the biggest effect on performance is that the poll address has 
to be reread on every safepoint, i.e., the node loading the address 
can not be moved out of loops. 

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 12. November 2013 10:39
To: Lindenmaier, Goetz
Cc: Keith McGuigan; hotspot-dev at openjdk.java.net
Subject: Re: Is it possible to stop a specific application thread?

On 12/11/2013 6:24 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> our VM is running with what we call PerThreadSafepoints for a long time.
>
> We implement this by loading the page from the thread as you propose.
> But we don't have a page per thread, as poisoning them seems to costly
> if there are many threads and all threads must be stopped.

Good point. You don't want a global safepoint to be implemented as a set 
of per-thread safepoints.

> Instead, we adapt the field in the thread: usually it points to some
> valid address.  If a safepoint is required, the polling page is written
> into that field.

So a global safepoint still has to iterate the Threads list to update 
every individual field?

I wonder if two polls (one per-thread and one global) would be too 
detrimental to normal performance ....

Cheers,
David

> We implemented this when we tried to improve BiasedLocking,
> but as we could not gain anything, we don't really use it any more.

> If you really have interest in this feature, I can prepare a webrev
> for it.
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Keith McGuigan
> Sent: Dienstag, 12. November 2013 06:46
> To: David Holmes
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: Is it possible to stop a specific application thread?
>
> I had a prototype at one point that did #2, but I don't have the source for
> it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they
> can reply with the diffs to give someone a leg up in doing this again.
>
> --
> - Keith (McGuigan)
>
> On Monday, November 11, 2013, David Holmes wrote:
>
>> On 12/11/2013 11:16 AM, Keith Chapman wrote:
>>
>>> Hi David,
>>>
>>> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>      Hi Keith,
>>>
>>>
>>>      On 12/11/2013 6:29 AM, Keith Chapman wrote:
>>>
>>>          Hi,
>>>
>>>          I'm playing around with some research ideas on hotspot.
>>>
>>>          One of my runtime services of the VM needs to stop a specific
>>>          application
>>>          thread (I have a handle to the pthread of the application
>>>          thread). How can
>>>          the VM stop such a thread? Is there any mechanism in place to do
>>>          this?
>>>
>>>
>>>      There is no general purpose mechanism currently in place.
>>>
>>>
>>> Thats a bummer, having such a mechanism would have been useful for
>>> numerous VM services like biased locking revocation, concurrent GC.
>>>
>>
>> For which safepoints are generally used so a per-thread safepoint
>> mechanism is what you are looking for.
>>
>>
>>>      You could use the deprecated and inherently dangerous Thread.suspend
>>>      mechanism (either directly or via the JVMTI suspension interface).
>>>
>>>      Or if you are more adventurous with your VM hacking you could
>>>      introduce a per-thread safepoint operation to cause it to stop.
>>>
>>>
>>> I actually thought about that and explored the way safepoints are
>>> implemented. The place that I had most trouble was getting threads
>>> running compiled code to stop. The way it currently works is by
>>> allocating a polling page (at startup) and drilling in that address into
>>> the compiled code. Hence i I am to do it per thread I would have to make
>>> a call to the runtime to get the address of the polling page for that
>>> particular thread. I presume this would be too expensive (Making a VM
>>> call at the end of each method and through some loop iterations).
>>>
>>> Is there any insight you could offer on how this could be done?
>>>
>>
>> Two basic options I can think of:
>>
>> 1. Use a single shared page and have other threads simply ignore the
>> safepoint request. This might incur some overhead as not-wanted threads
>> could hit this multiple times.
>>
>> 2. Use a per-thread page accessed via the current thread. There would be a
>> little overhead for the indirection but the compiler knows how to access
>> the current JavaThread object. No need for runtime calls that I can see.
>>
>> Good luck.
>>
>> David
>>
>>   Thanks,
>>> Keith.
>>>
>>>      Or you could hack in a special "magic exception" type the processing
>>>      of which simply blocks the thread until "resumed" somehow (not sure
>>>      how ??). Or ...
>>>
>>>      Cheers,
>>>      David
>>>
>>>          Thanks,
>>>          Keith.
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Keith Chapman
>>> blog: http://www.keith-chapman.org
>>>
>>