Profiling the hotspot,
charlie.hunt at oracle.com
Sat Nov 12 16:34:23 UTC 2011
This is a bit long winded ... hopefully you'll find it useful though.
If you are wanting to only view HotSpot method names in the profile and
not also view HotSpot source code embedded in the profile and/or not
profile with hardware/CPU counters, then you do not need to build
anything special to see HotSpot method names with Oracle Solaris Studio
Performance Analyzer, (aka collector analyzer).
Btw, don't let "Solaris" embedded in the product name deter you.
Although the official product name is "Oracle Solaris Studio", it is
also available on Linux. Because the product was originally built for
Solaris (both x86 and SPARC), its more mature on Solaris than Linux,
(the Linux port was done a couple years ago -- fwiw, I almost always
profile on Solaris since it is more mature and I can get hardware
counter info "out of the box"). The Linux version requires a (fairly)
recent kernel, i.e. Red Hat EL 5, SuSE ES 11 or Oracle Enterprise Linux
5 or more recent versions. Other variants of Linux may work, i.e.
Ubuntu (I've run it on recent Ubuntu releases).
If you want to see hardware/CPU counters info in the profile, then see
the section below "Hardware/CPU Counter Profiling"
If you want to see HotSpot source code embedded in the profile, then see
the section below "Embedded HotSpot Source Code".
To limit the amount data collected in the profile, you can use collect's
-y <SIGNAL> option to toggle on and toggle off profile gathering.
To help find what you are looking for in tracing GC thread(s) activity,
once you look at the profile in Analyzer, I'd suggest to start by
looking at the Timeline tab where you see a row for every thread in the
JVM and Java application. Although each row doesn't list the thread
name, (an enhancement I've asked for), you can click in a given thread
row and look at the Call Stack panel to get a sense of which thread it
is. The Timeline will also show when the thread was busy. You could
use the Timeline and Call Stack panel to figure out what phase CMS is
in. From there you can filter the profile data based on the time line
info and for those CMS threads. That'll allow you to look specifically
at the CMS threads and when they are running.
There's an intro to how to use Performance Analyzer in the Java
Performance book, but (unfortunately) it does not explicitly show your
use case. It does, however, offer an intro of the basic concepts.
There's also some really good documentation available at the Oracle
Solaris Studio product web site:
There is also some tutorials in the product distribution that can help
get you familiar with the tool.
Download page is:
Hardware/CPU Counter Profiling
If you want to see hardware/CPU counters info in the profile, then, on
Linux, you have to patch the kernel. Fwiw, patching the kernel is not
needed for Solaris (x86 or SPARC). If you want to see what hardware
counters are available, a simple 'collect' command with no args will
printout hardware counters that can be profiled. There's also a section
in the Java Performance book that describes how to profile with
Embedded HotSpot Source Code
If you want to see the HotSpot source code embedded in the profile, then
you need to do a custom build of HotSpot. There's a couple ways you can
accomplish what you need and what I list here is not necessary the best
way, or the only way. Hopefully the instructions below are not out of
date. These worked for me about 6 months ago. I'm sure there's others
who can offer an easier approach or offer corrections, (I'm not a
HotSpot build expert).
This is what I've done on Linux:
1. After getting a copy of the HotSpot source code from the source code
2. Edit the <ws>/make/linux/makefiles/amd64.make file.
3. Append -g0 to the line, OPT_CFLAGS/compactingPermGenGen.o = -O1
i.e. OPT_CFLAGS/compactingPermGenGen.o = -O1 -g0
4. Edit the <ws>/make/linux/makefiles/gcc.make file.
5. Append -g0 to the line, OPT_CFLAGS += -O3 i.e. OPT_CFLAGS += -O3 -g0
6. Append -gdwarf-2 to the line, OPT_CFLAGS += -fno-strict-aliasing
i.e. OPT_CFLAGS += -fno-strict-aliasing -gdwarf-2
7. Append -g0 to the line, OPT_CFLAGS/NOOPT=-O0 i.e.
8. Append -g0 to the line, OPT_CFLAGS/mulnode.o += -O0 i.e.
OPT_CFLAGS/mulnode.o += -O0 -g0
9. Change this line, DEBUG_CFLAGS += -gstabs, to DEBUG_CFLAGS += -gdwarf-2
10. Edit the <ws>/make/linux/makefiles/product.make file.
11. Comment out these two lines:
STRIP_LIBJVM = $(STRIP) -g $@ || exit 1;
STRIP_AOUT = $(STRIP) -x $@ || exit 1;
#STRIP_LIBJVM = $(STRIP) -g $@ || exit 1;
#STRIP_AOUT = $(STRIP) -x $@ || exit 1;
12. Now build HotSpot using the "product" target and build for either
64-bit or 32-bit, i.e. to build 64-bit libjvm.so do, $ gmake LP64=1 product
On 11/12/11 01:44 AM, Jon Masamitsu wrote:
> Take a look at Charlie's blog about the collector analyzer tools
> And the quick start guide
> The profiling build target in hotspot was deleted because they
> were not being used and I believe were not building correctly.
> On 11/11/2011 7:23 PM, David Holmes wrote:
>> As this mainly concerns GC profiling I've cc'ed the GC list.
>> On 12/11/2011 2:22 AM, Dang Nhan Nguyen wrote:
>>> I need to measure some performance (mostly running time) of GC (CMS)
>>> while running on multi-core platform on Linux. I want to break down
>>> the cost of each phase in CMS and some related method. And I am
>>> thinking of performance profiling tool to do that.
>>> I have look at the build files and see that there used to be some
>>> "profiled" target for profiling hotspot. However, it was removed now
>>> (don't know why).
>>> Now, I am looking for a way to do the profiling. As my experience
>>> with profiling the hotspot on Windows (using Visual Studio), the
>>> generated of profiling data is huge (2-6GB) and in many cases, my
>>> computer could not handle the analysis of profiling data. In
>>> addition, hotspot's code and its build are quite complex, I want to
>>> consult some opinions first before actually do it.
>>> I am grateful if you can suggest a way to build the hotspot on Linux
>>> for profiling purpose.
>>> Thank you,
>>> Nhan Nguyen
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5166 bytes
Desc: S/MIME Cryptographic Signature
More information about the build-dev