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 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 

Reply via email to