Hi Martin,
Advertising
>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 demo here: >https://www.youtube.com/watch?v=5sXxIfjaALg >So an example of what you can do, but not suitable for anything serious. I don't want to setup a connection to myself and I was wondering if that could be avoided altogether, it is more complex than I would like it to be, for instance I would need to factor in the connection, what if it goes wrong etc etc . >For inspecting the stack, there is an cool reflection hack to the Java 9 API >demonstrated by Andrei Pangin here that is >able to capture stack values: >https://vimeo.com/233820012 Do you think that is suitable for serious work ? I mean, production code. >For serious work I suppose an JVMTI agent is the best option. Others are in a >better position to offer guidance on that. Reading the docs it seems that the agent has to be written in C/C++ and unfortunately that is not an option on my current project, I quote from there (https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#whatIs) : "Tools can be written directly to JVM TI or indirectly through higher level interfaces. The Java Platform Debugger Architecture includes JVM TI, but also contains higher-level, out-of-process debugger interfaces. The higher-level interfaces are more appropriate than JVM TI for many tools. For more information on the Java Platform Debugger Architecture, see the Java Platform Debugger Architecture website." It easy to get lost among acronyms - me being a newbie in the Java JVM related tooling - but when I open the https://docs.oracle.com/javase/7/docs/technotes/guides/jpda/architecture.html (Java Platform Debugger Architecture website) it lists three "things": 1) JVM TI if native it is not an option 2) JDWP not sure I need to look into that 3) JDI which is why I ended up here Wrapping up, my hope is that the Java 9 reflection hack can work well or that JDI allows me to do inspect frames without the need of having a connection, reading your answer that does not seem to be possible and I should exclude the possibility altogether. Is that right ? Thanks a lot for the answers. P. fre. 6. apr. 2018 kl. 18:14 skrev Pietro Paolini <pietro.paol...@alfasystems.com>: Hi all, I apologise if this is not the right ML for it but I couldn’t find exactly what I was looking for when Googling the problem. I am a bit new to the JDI world. I would like to inspect the stack-frame of a specific thread, I came across the StackFrame/ThreadReference classes but I couldn’t find a way examples where their usage is shown without connecting to the VM somehow, like a debugger would do. Is it possible to inspect a thread’s stack “locally” ? In my mind I could be able to have a function such as : static void hook(Thread thread) { thread.wait() // stop that thread // inspect the frames of that thread doing any needed business with them } I’d need this for diagnostic purposes of my application. Thanks, Pietro Pietro Paolini Consultant Alfa ________________________________________ e: pietro.paol...@alfasystems.com | w: alfasystems.com t: +44 (0) 20 7920-2643 | Moor Place, 1 Fore Street Avenue, London, EC2Y 9DT, GB ________________________________________ The contents of this communication are not intended to be binding or constitute any form of offer or acceptance or give rise to any legal obligations on behalf of the sender or Alfa. The views or opinions expressed represent those of the author and not necessarily those of Alfa. This email and any attachments are strictly confidential and are intended solely for use by the individual or entity to whom it is addressed. If you are not the addressee (or responsible for delivery of the message to the addressee) you may not copy, forward, disclose or use any part of the message or its attachments. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a result of the use of this medium to transmit information by or to Alfa or its affiliates. Alfa Financial Software Ltd Reg. in England No: 0248 2325
