On 9/10/2018 4:08 PM, Chris Plummer wrote:
Looks good. Any idea what caused it, other than it was introduced by
JDK-8209611?
It wasn't in the original webrev for 8209611 (no cast at all) so I'm
guessing it was a last minute change that somehow went awry. I wonder if
compilers have a -Wunneces
Looks good. Any idea what caused it,
other than it was introduced by JDK-8209611?
Chris
On 10/8/18 8:54 PM, JC Beyler wrote:
Hi all,
Seems like there is an over-zealous castin
Hello!
[Including runtime-dev since the changes are in runtime code]
Requesting reviews for:
Webrev: http://cr.openjdk.java.net/~jgeorge/8200613/webrev.01/
BugID: https://bugs.openjdk.java.net/browse/JDK-8200613
Issue: jhsdb jstack would throw an UnmappedAddressException with a core
file gene
Hi all,
I am continuing the NSK_CPP_STUB removal with this next webrev.
Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8211899
The change is still straight-forward though, since it is just doing the
same NSK_CPP_STUB removal. However
Hi Jc,
It looks good.
Thank you for fixing it!
Thanks,
Serguei
On 10/8/18 20:54, JC Beyler wrote:
Hi all,
Seems like there is an over-zealous casting in the
Hi all,
Seems like there is an over-zealous casting in the file
nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp:
jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) (jstring)
(jstring) (jstring) (jstring) NSK_CPP_STUB3(CallObjectMethod, jni_env,
klass,
This webrev fixes that:
We
Hi Serguei,
Sure. That was my intention.
Thanks!
Bets regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Monday, October 8, 2018 at 6:17 PM
To: Daniil Titov , , Alex
Menkov , Chris Plummer
Cc: serviceability-dev
Subject: Re: RFR 8193879: Java debugger hangs on method i
Daniil,
Could you wait a little bit for reply from Severin G.?
Thanks,
Serguei
On 10/8/18 18:12, Daniil Titov wrote:
Hi Serguei, Chris, Alex, and Garry,
Thank you for reviewing this change. I w
Hi Serguei, Chris, Alex, and Garry,
Thank you for reviewing this change. I will remove added space in
test/jdk/com/sun/jdi/TestScaffold.java resumeTo() method before pushing the
change. It was accidentally added.
- return (BreakpointEvent)waitForRequestedEvent(request);
+ r
Hi Severin,
You already fixed a couple of deadlocks in the debugger method
invocation and have an expertise in this area.
Do you have any time to review the webrev from Daniil?
Otherwise, I'd like to keep you aware about this fix.
Thanks,
Hi Daniil,
It seems to me, this fix is going to work.
The freeze() method only cares there are no pending resume
commands:
99 synchronized void freeze() {
100 if (cache == null && (pendingResumeCommands.isEmpty())) {
101 /
Hi Jc,
Thank you for the update!
It looks good to me.
Thanks,
Serguei
On 10/8/18 14:53, JC Beyler wrote:
Hi Serguei,
Normally, I try not to fix issues that
Hi Gary,
+1
Thanks,
Serguei
On 10/8/18 11:30, Chris Hegarty wrote:
The updated link looks ok to me.
-Chris
On 8 Oct 2018, at 19:15, Gary Adams wrote:
Alan suggested in the bug report for the broken link from the jdwp-protocol
spec to the java/lang/ThreadGroup documentation to simply remov
On 08/10/2018 19:15, Gary Adams wrote:
Alan suggested in the bug report for the broken link from the
jdwp-protocol
spec to the java/lang/ThreadGroup documentation to simply remove the
href link. Another possibility is to simply update the link to include
the java.base
subdirectory.
My comment
Looks good.
For some reason one statement in
nsk/jvmti/RetransformClasses/retransform003/retransform003.cpp
(@@ -105,92 +97,35 @@)
was not converted to 1-liner like others in the same file:
+if (!NSK_VERIFY((loader_class = jni->GetObjectClass(loader)
) != NULL
)
Patch attached.
I think one reviewer is sufficient since this mimics
the cm02t001 bug fix.
On 10/8/18, 3:02 PM, Gary Adams wrote:
Hi Gary,
Looks good. Please add the comment "Wait for contended "sychronized (M)".
thanks,
Chris
On 10/8/18 4:47 AM, Gary Adams wrote:
>/ The main thread in tc0
The updated link looks ok to me.
-Chris
> On 8 Oct 2018, at 19:15, Gary Adams wrote:
>
> Alan suggested in the bug report for the broken link from the jdwp-protocol
> spec to the java/lang/ThreadGroup documentation to simply remove the
> href link. Another possibility is to simply update the li
Hi Gary,
Looks good. Please add the comment "Wait for contended "sychronized (M)".
thanks,
Chris
On 10/8/18 4:47 AM, Gary Adams wrote:
The main thread in tc02t001 is using a sleep(100) to cause a
monitor contention for the debuggee thread. On some slower
platform builds the main thread contin
Alan suggested in the bug report for the broken link from the jdwp-protocol
spec to the java/lang/ThreadGroup documentation to simply remove the
href link. Another possibility is to simply update the link to include
the java.base
subdirectory.
I don't think the doc structure changes very often
The main thread in tc02t001 is using a sleep(100) to cause a
monitor contention for the debuggee thread. On some slower
platform builds the main thread continues before the debuggee
thread observes the contention.
Similar to the fix for cm02t001, this is a simple change to increase
the pauses to
Patch attached. (Added Dan as a reviewer)
Chris if you can push this, I still need patches sponsored.
To add time factor support is a much bigger task
that should be done consistently across all the
vmTestbase/nsk suite.
On 10/4/18, 3:06 PM, Daniel D. Daugherty wrote:
Just FYI...
http://mail.o
Hi Jc,
http://cr.openjdk.java.net/%7Ejcbeyler/8211801/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/ap06t001.cpp.udiff.html
if (!NSK_JNI_VERIFY(jni, (fid =
-NSK_CPP_STUB4(GetStaticFieldID, jni,
-
22 matches
Mail list logo
