RE: RFR (M): 8201247: Various cleanups in the attach framework

Hi Chris, thanks for looking into this. As for ArgumentIterator::next, I must admit, I found this patch in our code base when taking over the code. I believe that an issue would be seen if an attach operation has 2 or 3 arguments and the first one is NULL/empty. I guess such a situation can't

RE: inspect a thread’s stack

Hi Martin, >Hi Pietro >Not sure JDI is what you really want, but if you would like to play with it I >have some code here that uses the PID of the JVM to open a >connection to itself and among other things print stack frames with variables: >https://github.com/skarsaune/kantega.debug and some

RE: inspect a thread’s stack

>Access to stacktraces with locals is demoed in this test >http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/java/lang/StackWalker/LocalsAndOperands.java Maybe I haven't read it well enough but isn't that accessible through https://docs.oracle.com/javase/9/docs/api/java/lang/StackWalker.html

Re: RFR(xxs): 8200384: jcmd help output should be sorted

Hi Sergey, Christoph, thanks for the review! Sure, here you go: Old output, unsorted: thomas@mainframe /shared/projects/openjdk/jdk-submit-hs/output-fastdebug $ ./images/jdk/bin/jcmd test3.Example2 help 24278: The following commands are available: VM.log VM.native_memory ManagementAgent.status

jcmd, windows x64: cannot see other processes?

Hi all, I try to attach a jcmd to a running process on windows x64, but jcmd only lists its own process. Both jcmd and process are built from jdk-hs. Then I tried attaching jdk-hs tip jcmd to an older VM (jdk 9), did not work either. Then - and here it gets weird - I tried attaching a jdk9 jcmd

RE: jcmd, windows x64: cannot see other processes?

Hi Thomas,   Are you running in two separate Terminal Server Sessions?   You need to be in the same WindowsStation https://msdn.microsoft.com/en-us/library/windows/desktop/ms687096(v=vs.85).aspx   HTH Markus   From: Thomas Stüfe [mailto:thomas.stu...@gmail.com] Sent: den 9 april 2018 1

Re: jcmd, windows x64: cannot see other processes?

Hi Markus, On Mon, Apr 9, 2018 at 5:30 PM, Markus Gronlund wrote: > Hi Thomas, > > > > Are you running in two separate Terminal Server Sessions? > > > no, this is all on my local Laptop. > You need to be in the same WindowsStation https://msdn.microsoft.com/en- > us/library/windows/desktop/ms

Re: jcmd, windows x64: cannot see other processes?

So, I found that I can attach with jcmd just fine, just the process listing does not work. I can only attach via pid, not via command name, which I think stems from the same error. Does anyone have any idea? Should I open a bug report? ..Thomas On Mon, Apr 9, 2018 at 5:24 PM, Thomas Stüfe wrot

Re: jcmd, windows x64: cannot see other processes?

On 09/04/2018 16:50, Thomas Stüfe wrote: So, I found that I can attach with jcmd just fine, just the process listing does not work. I can only attach via pid, not via command name, which I think stems from the same error. Does anyone have any idea? Should I open a bug report? Its this some

RFR: Fix race condition in jdwp

Hi, We discovered in our testing with OpenJ9 that a race condition can occur in the jdwp under certain circumstances, and we were able to force the same issue with Hotspot. Normally, the event helper thread suspends all threads, then the debug loop in the listener thread receives a command to r

Re: inspect a thread’s stack

I think the conversation will shift a bit if you explain what you mean with: "// inspect the frames of that thread doing any needed business with them" What exactly do you have in mind? Do you want to change the stack in some way? Because, depending on what you want, Andrew's comment on: ThreadM

RFR: 8201327: Make Sensor deeply immutably thread safe

Another little cleanup to make Google's race detector happy. 8201327: Make Sensor deeply immutably thread safe http://cr.openjdk.java.net/~martin/webrevs/jdk/Sensor-init/ https://bugs.openjdk.java.net/browse/JDK-8201327

Re: RFR (M): 8201247: Various cleanups in the attach framework

Hi Christoph, We have some closed "attach on demand" tests that should be run also. I can do this for you when you are ready. Please also let me know which other jtreg tests you have run. thanks, Chris On 4/9/18 12:08 AM, Langer, Christoph wrote: Hi Chris, thanks for looking into this. A

Re: RFR: 8201327: Make Sensor deeply immutably thread safe

On 09/04/2018 18:54, Martin Buchholz wrote: Another little cleanup to make Google's race detector happy. 8201327: Make Sensor deeply immutably thread safe http://cr.openjdk.java.net/~martin/webrevs/jdk/Sensor-init/ https://bugs.op

Re: RFR: 8201327: Make Sensor deeply immutably thread safe

> On 9 Apr 2018, at 20:31, Alan Bateman wrote: > >> On 09/04/2018 18:54, Martin Buchholz wrote: >> Another little cleanup to make Google's race detector happy. >> >> 8201327: Make Sensor deeply immutably thread safe >> http://cr.openjdk.java.net/~martin/webrevs/jdk/Sensor-init/ >>

RFR: 8200195 : serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java crashes with "assert(thread->thread_state() == _thread_in_native) failed: coming from wrong thread state"

Hi all, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8200195 webrev: http://cr.openjdk.java.net/~amenkov/field_access_graal/webrev/ The problem with the test is it uses cached JNIEnv value instead using a value passed to the callbacks. JNIEnv is valid only for the current th

Re: RFR: 8200195 : serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java crashes with "assert(thread->thread_state() == _thread_in_native) failed: coming from wrong thread state"

Hi Alex, I'd suggest renaming javaEnv to jni_env to be consistent. Not sure why javaEnv was chosen in the original implementation. Otherwise the changes look good. thanks, Chris On 4/9/18 2:13 PM, Alex Menkov wrote: Hi all, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-

Re: RFR: 8200195 : serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java crashes with "assert(thread->thread_state() == _thread_in_native) failed: coming from wrong thread state"

+1 Though I'd also like to understand why the test only fails sometimes and which other thread is involved? Thanks, David On 10/04/2018 7:28 AM, Chris Plummer wrote: Hi Alex, I'd suggest renaming javaEnv to jni_env to be consistent. Not sure why javaEnv was chosen in the original implement

Re: RFR: Fix race condition in jdwp

Hi Andrew, The patch itself looks reasonable. However, in order to proceed with it, a bug report with a standalone test case demonstrating the issue is needed. Thanks, Serguei On 4/9/18 09:07, Andrew Leonard wrote: Hi, We discovered in our testing with OpenJ9 that a race condition can occur

Re: RFR: 8200195 : serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java crashes with "assert(thread->thread_state() == _thread_in_native) failed: coming from wrong thread state"

updated webrev: http://cr.openjdk.java.net/~amenkov/field_access_graal/webrev.02/ (javaEnv is replaced with jni_env) On 04/09/2018 14:35, David Holmes wrote: +1 Though I'd also like to understand why the test only fails sometimes and which other thread is involved? It always fails with Graa

Re: RFR: 8200195 : serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java crashes with "assert(thread->thread_state() == _thread_in_native) failed: coming from wrong thread state"

Hi Alex, The fix looks good. Thank you for replacing the javaEnv with the jni_env. Thanks, Serguei On 4/9/18 15:04, Alex Menkov wrote: updated webrev: http://cr.openjdk.java.net/~amenkov/field_access_graal/webrev.02/ (javaEnv is replaced with jni_env) On 04/09/2018 14:35, David Holmes wrot

Re: RFR: 8200195 : serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java crashes with "assert(thread->thread_state() == _thread_in_native) failed: coming from wrong thread state"

On 4/9/18 3:04 PM, Alex Menkov wrote: updated webrev: http://cr.openjdk.java.net/~amenkov/field_access_graal/webrev.02/ (javaEnv is replaced with jni_env) Looks good. On 04/09/2018 14:35, David Holmes wrote: +1 Though I'd also like to understand why the test only fails sometimes and which

Re: RFR: Fix race condition in jdwp

Hi Andrew, On 10/04/2018 2:07 AM, Andrew Leonard wrote: Hi, We discovered in our testing with OpenJ9 that a race condition can occur in the jdwp under certain circumstances, and we were able to force the same issue with Hotspot. Normally, the event helper thread suspends all threads, then the

Re: RFR: 8201327: Make Sensor deeply immutably thread safe

On Mon, Apr 9, 2018 at 1:25 PM, Chris Hegarty wrote: > > > On 9 Apr 2018, at 20:31, Alan Bateman wrote: > > > >> On 09/04/2018 18:54, Martin Buchholz wrote: > >> Another little cleanup to make Google's race detector happy. > >> > >> 8201327: Make Sensor deeply immutably thread safe > >> http://c