Simple answer is "No".
I've actually wanted to do profiling on the target hardware (ARM) running jamvm because it performed significantly slower than on my desktop running the Oracle HotSpot VM.
I've checked the JamVM sources but there is no hidden magic. JamVM was build to be very compact and thus adding support for remote debugging, profiling, JMX and whatnot would have bloated the VM.
What you can do is using -verbose
to get a little insight on what's happening. Using :class
e.g. I was at least able to spot a huge performance bottleneck by monitoring the class loading.
jamvm -verbose[:class|gc|jni]
:class print out information about class loading, etc.
:gc print out results of garbage collection
:jni print out native method dynamic resolution
Nevertheless, since our application has some kind of thin HAL, I am able to run it on desktop using the full power of IDEs, profilers, debuggers which is what I would suggest.
If it is not possible due to some hardware specific code that won't run on desktop, unfortunately I don't know any other way than doing the ugly "printf debugging".