SA.NEXT - SA feedback needed

[Krystal Mok]

Hi Dmitry,

Thanks for starting this discussion on SA. I guess I was one of the heavy
users of SA so I'm really happy to see it still being developed.

I used SA a lot when I was doing OpenJDK development, almost on a daily
basis if I needed to do debugging. SA was most valuable for me when
debugging code dumps on the box where the crash happened. I used it mostly
on Linux/x86, and sometimes on Windows/x86/JDK7.

I would also use SA for demonstration and learning purposes.
e.g. I wrote a blog post to demonstrate where Java local variables,
instance fields and static fields were in memory in a running HotSpot VM,
here: http://rednaxelafx.iteye.com/blog/1847971
(the blog post was in Chinese but the code example should explain what I
was doing)
Learning how to use SA was a great way for people to poke the internals of
HotSpot. It worked for me. Some functionality of SA are exposed through the
SA-plugin in VisualVM. I started learning about SA with that plugin.

I also used SA to dump classes at runtime to see what the VM thinks it had
loaded. It helped me debug some class loading issues. It's different from
dumping generated classes before the VM loads them.

The SA API is also useful for writing some one-off tools for custom
scenarios, for both live processes and code dumps. I wrote quite a few of
those, e.g. the ones listed here: http://rednaxelafx.iteye.com/blog/1814429
(Unfortunately some people would like to try and use SA features
in-process, which is not how SA works. It's a out-of-process debugger.
Wrapping an out-of-process SA agent and using it in-process with RPC calls
is a weird way of using SA. I don't really recommend that.)

For debugging live processes, sometimes I prefer using utility functions
from utilities/debug.cpp in gdb, because those allow me to do whatever SA
could (e.g. stack walking of a mixed Java/C stack, printing out a oop,
etc.), plus I could use normal debugger functionalities like modifying
memory, setting breakpoints and stepping through code, which SA can't do. I
know SA started out planning to support modifying memory, setting
breakpoints and stepping code, but those were never implemented and
probably still won't be in the future.

Along the lines of what Vladimir mentioned, I wish more of the SA files
could be automatically generated as a part of the build process of HotSpot,
so that it's less likely to miss changes from the VM. Most SA files that
represent VM data structures can be directly mapped from the declarations
of their VM counterparts, and I know a lot of those files were actually
generated from a script and then manually edited a little bit. I believe
that's how Tom implemented SA for reading C2 IR.

Also, I'd like to see more VM internals exposed to SA. It could mean more
maintenance burden so I'm not really pushing it, but it'd be a lot more
useful if it did.
e.g. A while ago I wrote a little patch to expose vtable and itable layouts
in instanceKlass. If I come around to polish and finish it, I'll send it in
for reviews.

Thanks,
Kris



On Fri, Jan 31, 2014 at 6:19 AM, Dmitry Samersoff <
dmitry.samersoff at oracle.com> wrote:

> Hi Everyone,
>
> I would like to start a discussion about future of hotspot debugger,
> known as serviceability agent or SA.
>
> How you typically use it? What do you expect from it?  What is missed?
>
> Please, share your stories and wishes.
>
> And please, fill the small quiz:
>
> 1. How often do you use SA?
>
> 2. On what platform do you use SA?
>
> 3. Do you use it to analyze life processes or coredumps?
>
> 5. What other debuggers do you use to debug hotspot issues
>
> -Dmitry
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
>