Hi Jini,
Thanks for pointing out that, yes we cannot make that cleanup for JDK8.
Keeping it very simple and taking only changes required to fix JDK-8164383
http://cr.openjdk.java.net/~fmatte/8164383/webrev.02/
I have verified running "test/serviceability/sa/jmap-hashcode/Test8028623.java"
test c
Hi Matthias,
looks good (and trivial). Ccing serviceability-dev because of change in libjdwp.
Best regards
Christoph
From: nio-dev On Behalf Of Baesken, Matthias
Sent: Mittwoch, 26. September 2018 11:25
To: 'build-...@openjdk.java.net' ; net-dev
; nio-...@openjdk.java.net
Cc: Lindenmaier, Goet
That all seems fine to me.
Thanks for fixing.
David
On 26/09/2018 5:48 AM, Langer, Christoph wrote:
Hi Matthias,
looks good (and trivial). Ccing serviceability-dev because of change in
libjdwp.
Best regards
Christoph
*From:*nio-dev *On Behalf Of
*Baesken, Matthias
*Sent:* Mittwoch, 26
A race condition exists in hs203t003 between the main test thread and
the processing in callbackFieldAccess processing. The main thread
already includes a polling loop to wait for the redefine class operation
to be performed, but it does not wait for the following suspend thread
operation to be co
Hi Gary,
Should you not also fail the test if the test fails at popping or resuming
the thread?
Apart from that looks good to me (I would remark normally that I'm getting
rid of the NSK_CPP_STUBs so you could just jump the gun and remove it
directly but this is consistent with the current code ba
The native code for popThreadFrame and resumeThread
already set the failed agent status. These incremental steps
are non fatal as far as the test is concerned. I even saw some
test logs where the popThreadFrame failed, but the
resumeThread succeeded, because the thread was suspended
by that time.
Hi Gary,
Should the following comment come first, not after the join() call:
115 mt.join();
116 // Wait till the other thread completes its execution.
Rather than using JVMTI to detect if the field is suspended, couldn't
you have just set a static variable in callback
On 9/26/18, 1:40 PM, Chris Plummer wrote:
Hi Gary,
Should the following comment come first, not after the join() call:
115 mt.join();
116 // Wait till the other thread completes its execution.
I'll move the comment up.
Rather than using JVMTI to detect if the field
On 9/26/18 11:07 AM, Gary Adams wrote:
On 9/26/18, 1:40 PM, Chris Plummer wrote:
Hi Gary,
Should the following comment come first, not after the join() call:
115 mt.join();
116 // Wait till the other thread completes its execution.
I'll move the comment up.
Rather
Hi Daniil,
It is great that you came up the fix for this issue.
Thanks to Gary for the help too.
I wonder if we could get away without updating the javadoc
of com/sun/jdi/connect/ListeningConnector.java.
Filing a CSR would not be needed then (simple javadoc reformatting
should not require a CSR
Hi all,
I continued the NSK_CPP_STUB removal with this webrev:
Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8211131
This does the first 50 files of the jvmti subfolder, it is done
automatically by the scripts I put in the bug comme
Ping on this, anybody have time to do a review and give a LGTM? Or David if
you have time and will to provide an explicit LGTM :)
Thanks,
Jc
On Mon, Sep 24, 2018 at 9:18 AM JC Beyler wrote:
> Hi David,
>
> Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting for an
> explicit LGTM
Sorry for being late to the game. Can I request a helpful comment in
SafeJNIEnv.hpp describing what its purpose is?
Also, I don’t necessarily have a better suggestion (and don’t consider this
blocking), but Is there another word than “Safe” to describe this wrapper?
“Checked”? ExceptionCheckin
Can I get one more review from a (R)eviewer please ?
Thanks,
Sharath
-Original Message-
From: Sharath Ballal
Sent: Wednesday, September 26, 2018 9:57 AM
To: Jini Susan George; serviceability-dev
Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times
out parsing a
14 matches
Mail list logo
