On 9/04/2020 5:39 pm, Yasumasa Suenaga wrote:
On 2020/04/09 16:19, Robbin Ehn wrote:
Hi Yasumasa,
We have had internal requests doing GetThreadListStackTraces with
multiple threads with handshakes. Since you can sample hundreds of times
per second using handshakes with little interference with
Ok, thanks for looking into it!
/Robbin
On 2020-04-09 09:39, Yasumasa Suenaga wrote:
On 2020/04/09 16:19, Robbin Ehn wrote:
Hi Yasumasa,
We have had internal requests doing GetThreadListStackTraces with
multiple threads with handshakes. Since you can sample hundreds of times
per second using
On 2020/04/09 16:19, Robbin Ehn wrote:
Hi Yasumasa,
We have had internal requests doing GetThreadListStackTraces with
multiple threads with handshakes. Since you can sample hundreds of times
per second using handshakes with little interference with your
application.
The internal request sampled
Hi Yasumasa,
We have had internal requests doing GetThreadListStackTraces with
multiple threads with handshakes. Since you can sample hundreds of times
per second using handshakes with little interference with your
application.
The internal request sampled all threads ~10 times per second.
So the
Hi Robbin,
I think we can change GetThreadListStackTrace(VM_GetThreadListStackTraces) if
the caller requests only 1 thread stack (thread_count == 1). It does not break
JVMTI spec.
In other case, we should use safepoint (VM Operation) for following JVMTI spec:
```
All stacks are collected simul
Hi, adding the same comment as in the bug regarding
GetThreadListStackTraces.
Please note that there is a semantic difference taking samples in a
safepoint and in handshakes, if there are mutiple thread sampled.
With a safepoint; stacktraces are taken from the same exact moment (from
a Java muta
On 2020/04/09 15:44, serguei.spit...@oracle.com wrote:
On 4/8/20 23:36, Yasumasa Suenaga wrote:
Thanks David and Serguei!
I created 3 subtasks under JDK-8201641, of course I will send review request in
each them.
- GetOneCurrentContendedMonitor => GetCurrentContendedMonitor
`GetCurrentCo
On 4/8/20 23:36, Yasumasa Suenaga wrote:
Thanks David and Serguei!
I created 3 subtasks under JDK-8201641, of course I will send review
request in each them.
- GetOneCurrentContendedMonitor => GetCurrentContendedMonitor
`GetCurrentContendedMonitor` is JVMTI function name, and also it
ex
Thanks David and Serguei!
I created 3 subtasks under JDK-8201641, of course I will send review request in
each them.
- GetOneCurrentContendedMonitor => GetCurrentContendedMonitor
`GetCurrentContendedMonitor` is JVMTI function name, and also it exists as
public member of JvmtiEnv class.
So
Hi Yasumasa,
I'm okay with using sub-tasks to do it incrementally.
This needs to be removed with your fix:
src/hotspot/share/runtime/vmOperations.hpp:
template(GetCurrentContendedMonitor) \
Also, I agree with comments from David below:
- GetOneCurrentContendedMonitor => GetCurre
Hi Yasumasa,
On 9/04/2020 3:08 pm, Yasumasa Suenaga wrote:
Hi,
JDK-8240918 has been pushed, so I made a patch for
GetCurrentContendedMonitor(). How about this?
http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/2/
Generally looks okay. A couple of comments:
src/hotspot/s
Hi,
JDK-8240918 has been pushed, so I made a patch for
GetCurrentContendedMonitor(). How about this?
http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/2/
An observation, it seems to me that calling_thread is not used when this is not
a VMOperation.
calling_thread is used
Thanks David!
If JDK-8201641 is not assigned when JDK-8240918 is resolved, I will start to
work for JDK-8201641.
(It would be large patch...)
Cheers,
Yasumasa
On 2020/04/01 19:05, David Holmes wrote:
On 1/04/2020 11:02 am, Yasumasa Suenaga wrote:
Thanks Dan and Serguei!
I added a comment
On 1/04/2020 11:02 am, Yasumasa Suenaga wrote:
Thanks Dan and Serguei!
I added a comment for this to JDK-8201641.
David, can you share Bug ID for thread-to-thread handshake?
I want to record it to JDK-8201641 as a blocker.
https://bugs.openjdk.java.net/browse/JDK-8240918
I heard the RFR coul
Thanks Dan and Serguei!
I added a comment for this to JDK-8201641.
David, can you share Bug ID for thread-to-thread handshake?
I want to record it to JDK-8201641 as a blocker.
Yasumasa
On 2020/04/01 1:59, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
Yes, this works needs to be done.
I'll
Hi Yasumasa,
Yes, this works needs to be done.
I'll take look at you webrev.
Thanks,
Serguei
On 3/31/20 07:41, Daniel D. Daugherty wrote:
Add Robbin to this thread...
This reminded of the following RFE that Robbin filed:
JDK-8201641 JVMTI: GetThreadListStackTraces should use
Thread-Loc
Add Robbin to this thread...
This reminded of the following RFE that Robbin filed:
JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local
Handshakes
https://bugs.openjdk.java.net/browse/JDK-8201641
We could update 8201641 to include everything that Yasumasa-san is
reque
Hi David,
On 2020/03/31 19:16, David Holmes wrote:
Hi Yasumasa,
On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote:
Hi all,
Many JVMTI functions uses VM Operation to get information. However some of them
need to stop only one thread - they don't need to stop all threads.
So I think we can use Thr
Hi Yasumasa,
On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote:
Hi all,
Many JVMTI functions uses VM Operation to get information. However some
of them need to stop only one thread - they don't need to stop all threads.
So I think we can use Thread Local Handshake as this webrev. It is
example fo
Hi all,
Many JVMTI functions uses VM Operation to get information. However some of them
need to stop only one thread - they don't need to stop all threads.
So I think we can use Thread Local Handshake as this webrev. It is example for
GetOneCurrentContendedMonitor().
http://cr.openjdk.java.n
20 matches
Mail list logo
