Sorry I just realized I reviewed version 00 :(
I have concerns with the added locking:
MutexLocker mu(JvmtiThreadState_lock);
Who else may be holding that lock? Could it be our target thread that we
have already initiated a handshake with? (The lock ranking checks
related to safepoints don't
Hi Yasumasa,
On 27/08/2020 9:40 am, Yasumasa Suenaga wrote:
Hi David,
On 2020/08/27 8:09, David Holmes wrote:
Hi Yasumasa,
On 26/08/2020 5:34 pm, Yasumasa Suenaga wrote:
Hi Patricio, David,
Thanks for your comment!
I updated webrev which includes the fix which is commented by
Patricio, an
Hi Yasumasa,
On 8/26/20 8:57 PM, Yasumasa Suenaga wrote:
Hi Patricio,
Thanks for your review, but webrev.00 has been rotten.
Can you review webrev.02?
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242427/webrev.02/
diff between webrev.00 and webrev.01:
http://hg.openjdk.java.net/jdk
http://cr.openjdk.java.net/~iignatyev//8252403/webrev.00
> 76 lines changed: 8 ins; 0 del; 68 mod;
Hi all,
could you please review the patch which rewrites
serviceability/7170638/SDTProbesGNULinuxTest.sh to java?
JBS: https://bugs.openjdk.java.net/browse/JDK-8252403
webrev: http://cr.openjdk.ja
Hi Alex,
On 21/08/2020 6:54 am, Alex Menkov wrote:
Hi Igor,
On 08/20/2020 09:23, Igor Ignatyev wrote:
HI Alex,
one minor nit: according to usual java coding conventions,
isJVMTIIncluded should be spelled as isJvmtiIncluded. otherwise the
fix looks good to me.
I tried to be consistent with
http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00
> 6 lines changed: 5 ins; 0 del; 1 mod;
Hi all,
could you please review this trivial patch which adds
j.t.l.Utils.TEST_NATIVE_PATH static field to store the value of test.nativepath
system property?
JBS: https://bugs.openjdk.java.net/br
http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00
> 287 lines changed: 60 ins; 200 del; 27 mod;
Hi all,
could you please review the patch which removes shell script from alloc001 test?
there are two small difference comparing to the original test:
- if we don't get OutOfMemory on mac or
Hi Patricio,
Thanks for your review, but webrev.00 has been rotten.
Can you review webrev.02?
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242427/webrev.02/
diff between webrev.00 and webrev.01:
http://hg.openjdk.java.net/jdk/submit/rev/7facd1dd39d6
diff between webrev.01 and web
Hi Robbin,
On 2020/08/27 0:08, Robbin Ehn wrote:
Hi Yasumasa,
Thanks for fixing, seems good.
Note that there are jdk tests for jdi which also runs this code under:
test/jdk/com/sun/jdi/
webrev.02 passed test/jdk/com/sun/jdi/ on my Linux x64.
Thanks,
Yasumasa
/Robbin
On 2020-08-26 16:33
Hi David,
On 2020/08/27 8:09, David Holmes wrote:
Hi Yasumasa,
On 26/08/2020 5:34 pm, Yasumasa Suenaga wrote:
Hi Patricio, David,
Thanks for your comment!
I updated webrev which includes the fix which is commented by Patricio, and it
passed submit repo. So I switch this mail thread to RFR.
Hi Richard,
I've described the motivation on JDK-8201641 (it is a parent task of
JDK-8242427)
```
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.
```
I aimed to improve JVMTI monitor operation
Hi Yasumasa,
On 26/08/2020 5:34 pm, Yasumasa Suenaga wrote:
Hi Patricio, David,
Thanks for your comment!
I updated webrev which includes the fix which is commented by Patricio,
and it passed submit repo. So I switch this mail thread to RFR.
JBS: https://bugs.openjdk.java.net/browse/JDK-8
Hi Yasumasa,
On 8/26/20 4:34 AM, Yasumasa Suenaga wrote:
Hi Patricio, David,
Thanks for your comment!
I updated webrev which includes the fix which is commented by
Patricio, and it passed submit repo. So I switch this mail thread to RFR.
JBS: https://bugs.openjdk.java.net/browse/JDK-82424
Hi Yasumasa,
Could you explain a little bit the motivation to replace these vm operations
with handshakes?
Would be good, if you could add the goals as well to the JBS item.
Thanks, Richard.
-Original Message-
From: serviceability-dev On Behalf
Of Yasumasa Suenaga
Sent: Montag, 24. Au
+Joe for an opinion.
I agree. I've added a comment to the CSR
(https://bugs.openjdk.java.net/browse/JDK-8251498) and moved it back to Draft.
"Volker Simonis has pointed out in
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012557.html that
when we backport a JMM feature, we're a
Hi Paul,
thanks for adapting your change. Please find my comments in-line below:
On Tue, Aug 25, 2020 at 10:28 PM Hohensee, Paul wrote:
>
> :)
>
> New webrevs following Volker's suggestion.
>
> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.06/
Looks good except JNI_OnLoad() in "manageme
Hi Yasumasa,
Thanks for fixing, seems good.
Note that there are jdk tests for jdi which also runs this code under:
test/jdk/com/sun/jdi/
/Robbin
On 2020-08-26 16:33, Yasumasa Suenaga wrote:
Hi Robbin,
I fixed them in new webrev. Could you review again?
webrev: http://cr.openjdk.java.net/~
Hi Robbin,
I fixed them in new webrev. Could you review again?
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242427/webrev.02/
diff from previous webrev:
http://hg.openjdk.java.net/jdk/submit/rev/2ef7feb5681f
It passed vmTestbase/nsk/{jdi,jdwp,jvmti} serviceability/{jdwp,jvmti} jtreg
Hi Yasumasa,
Yes that should work.
Can you please add assert where you removed the:
- MutexLocker mu(JvmtiThreadState_lock);
E.g.
+ // If we are in a handshake we only know that the requesting thread
should have locked it.
+ assert(SafepointSynchronize::is_at_safepoint() ||
JvmtiThreadState
Hi Robbin,
Thanks for your comment!
How about this change?
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242427/webrev.01/
diff from previous webrev:
http://hg.openjdk.java.net/jdk/submit/rev/7facd1dd39d6
I still use JvmtiThreadState_lock because it has a different locking range from
Hi Yasumasa,
You cannot take the MutexLocker mu(JvmtiThreadState_lock) with safepoint
checks inside a handshake.
We are missing a NoSafepointVerifier for handshakes.
(I have added this in my work in progress asynchronous handshake patch)
Also this can deadlock with the handshake semaphore.
(In
Hi Patricio, David,
Thanks for your comment!
I updated webrev which includes the fix which is commented by Patricio, and it
passed submit repo. So I switch this mail thread to RFR.
JBS: https://bugs.openjdk.java.net/browse/JDK-8242427
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-824242
Hi Yasumasa,
On 24/08/2020 12:40 pm, Yasumasa Suenaga wrote:
Hi all,
I want to hear your opinions about the change for JDK-8242427.
I'm trying to migrate following operations to direct handshake.
- VM_UpdateForPopTopFrame
- VM_SetFramePop
- VM_GetCurrentLocation
Some operation
23 matches
Mail list logo
