From prasad1310 at hotmail.com Fri Feb 1 05:52:01 2008 From: prasad1310 at hotmail.com (Prasad Kulkarni) Date: Fri, 1 Feb 2008 08:52:01 -0500 Subject: hotspot build instructions In-Reply-To: <47A2BAE6.50106@Sun.COM> References: <47A2BAE6.50106@Sun.COM> Message-ID: Thanks everyone for your help. My research only involves making changes to the hotspot JVM. I do not want to build the class libraries and anything else that I don't have to. Earlier this week, I downloaded just the hotspot compiler from one of Sun's site (not the OpenJDK) and built it on fedora/gcc 4.1.2 after making some changes to the source files, mainly due to gcc incompatibilities, I believe. I also downloaded the latest java SDK hoping that just by replacing the libjvm.so file all would work. Since that did not work, I started looking at the OpenJDK project. One question I have is, exactly how much of the entire JDK does one have to build to start customizing hotspot? The hotspot FAQ page provides instructions to get the source for the hotspot VM. Those links did not work for me, in particular the one for the source bundle, https://openjdk.dev.java.net/servlets/ProjectDocumentList?folderID=6127&expandFolder=6127&folderID=0 So, I have been attempting to download the OpenJDK using Volker's instructions on his weblog. Currently, I don't have all the files as yet, mercurial only downloads 26 files without hgforest. So, I will try to solve those issues today. Please let me know if any one has any suggestions. thanks, Prasad ---------------------------------------- > Date: Thu, 31 Jan 2008 22:23:34 -0800 > From: Peter.Kessler at Sun.COM > Subject: Re: hotspot build instructions > To: prasad1310 at hotmail.com > CC: hotspot-dev at openjdk.java.net > > I wrote osse-build-linux-i586 back when all we had out in the > open was the HotSpot source code. It's been superseded by all > the good work people have done making it easy (possible) to > build HotSpot as part of building the whole OpenJDK. > > Do you want to build just HotSpot (the JVM, no class libraries) > or do you want to build the whole JDK? If so, you might want > to post questions on build-dev at openjdk.java.net. > > I'll take a note to clean up old http://openjdk.java.net/groups/hotspot > web pages, but it won't make it to the top of my stack soon. > > ... peter > > Prasad Kulkarni wrote: >> Hi, >> >> I am attempting to install hotspot, and use it for some of our research. >> Although I have downloaded all the source files, the link to the "instructions >> for building Hotspot VM" does not seem to work for me. I am trying to open the >> link from the FAQ page at: >> http://openjdk.java.net/groups/hotspot/faq.html >> >> The link for instructions for linux points to: >> http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 >> >> I will greatly appreciate if it could be possible to fix the link, or for some >> one to send me their copy of the build instructions. >> >> thank you, >> Prasad > _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx From volker.simonis at gmail.com Fri Feb 1 06:56:33 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 1 Feb 2008 15:56:33 +0100 Subject: hotspot build instructions In-Reply-To: References: <47A2BAE6.50106@Sun.COM> Message-ID: You can clone the sources without the forest extension, you just have to clone the different trees "manually" (e.g "hg clone http://hg.openjdk.java.net/jdk7/jdk7/hotspot" for the hotspot, "hg clone http://hg.openjdk.java.net/jdk7/jdk7/jdk" for the jdk tree and so on for corba, langtools, jaxp and jaxws). If you only want to hack the VM, you can either build the entire OpenJDK once or download a JDK7 binary from http://download.java.net/jdk7/binaries/ and. Than you can build and run the OpenJDK HotSpot as described in: http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html#HotSpotBuild and http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html#HotSpotRun On 2/1/08, Prasad Kulkarni wrote: > > Thanks everyone for your help. > My research only involves making changes to the hotspot JVM. I do not want to build the class libraries and anything else that I don't have to. Earlier this week, I downloaded just the hotspot compiler from one of Sun's site (not the OpenJDK) and built it on fedora/gcc 4.1.2 after making some changes to the source files, mainly due to gcc incompatibilities, I believe. I also downloaded the latest java SDK hoping that just by replacing the libjvm.so file all would work. > > Since that did not work, I started looking at the OpenJDK project. One question I have is, exactly how much of the entire JDK does one have to build to start customizing hotspot? The hotspot FAQ page provides instructions to get the source for the hotspot VM. Those links did not work for me, in particular the one for the source bundle, > https://openjdk.dev.java.net/servlets/ProjectDocumentList?folderID=6127&expandFolder=6127&folderID=0 > > So, I have been attempting to download the OpenJDK using Volker's instructions on his weblog. Currently, I don't have all the files as yet, mercurial only downloads 26 files without hgforest. So, I will try to solve those issues today. Please let me know if any one has any suggestions. > > thanks, > Prasad > > > ---------------------------------------- > > Date: Thu, 31 Jan 2008 22:23:34 -0800 > > From: Peter.Kessler at Sun.COM > > Subject: Re: hotspot build instructions > > To: prasad1310 at hotmail.com > > CC: hotspot-dev at openjdk.java.net > > > > I wrote osse-build-linux-i586 back when all we had out in the > > open was the HotSpot source code. It's been superseded by all > > the good work people have done making it easy (possible) to > > build HotSpot as part of building the whole OpenJDK. > > > > Do you want to build just HotSpot (the JVM, no class libraries) > > or do you want to build the whole JDK? If so, you might want > > to post questions on build-dev at openjdk.java.net. > > > > I'll take a note to clean up old http://openjdk.java.net/groups/hotspot > > web pages, but it won't make it to the top of my stack soon. > > > > ... peter > > > > Prasad Kulkarni wrote: > >> Hi, > >> > >> I am attempting to install hotspot, and use it for some of our research. > >> Although I have downloaded all the source files, the link to the "instructions > >> for building Hotspot VM" does not seem to work for me. I am trying to open the > >> link from the FAQ page at: > >> http://openjdk.java.net/groups/hotspot/faq.html > >> > >> The link for instructions for linux points to: > >> http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 > >> > >> I will greatly appreciate if it could be possible to fix the link, or for some > >> one to send me their copy of the build instructions. > >> > >> thank you, > >> Prasad > > > > _________________________________________________________________ > Need to know the score, the latest news, or you need your Hotmail(R)-get your "fix". > http://www.msnmobilefix.com/Default.aspx From prasad1310 at hotmail.com Fri Feb 1 11:22:43 2008 From: prasad1310 at hotmail.com (Prasad Kulkarni) Date: Fri, 1 Feb 2008 14:22:43 -0500 Subject: hotspot build instructions In-Reply-To: References: <47A2BAE6.50106@Sun.COM> Message-ID: I was able to download all the sources. I was also able to build hotspot using the JDK7 binaries (for now). I had earlier tried to manually use "hg clone" on all sub-directories, but I had obviously made some mistake there. Thanks! Your blog is very helpful and instructive! I may use it again to setup Netbeans. Do you know of any other resource that gives the internal details of hotspot (like what function is the entry point for the JIT, interpreter, function flow, something like that...). thank you, Prasad ---------------------------------------- > Date: Fri, 1 Feb 2008 15:56:33 +0100 > From: volker.simonis at gmail.com > To: prasad1310 at hotmail.com > Subject: Re: hotspot build instructions > CC: hotspot-dev at openjdk.java.net > > You can clone the sources without the forest extension, you just have > to clone the different trees "manually" (e.g "hg clone > http://hg.openjdk.java.net/jdk7/jdk7/hotspot" for the hotspot, "hg > clone http://hg.openjdk.java.net/jdk7/jdk7/jdk" for the jdk tree and > so on for corba, langtools, jaxp and jaxws). > > If you only want to hack the VM, you can either build the entire > OpenJDK once or download a JDK7 binary from > http://download.java.net/jdk7/binaries/ and. Than you can build and > run the OpenJDK HotSpot as described in: > http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html#HotSpotBuild > and > http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html#HotSpotRun > > On 2/1/08, Prasad Kulkarni wrote: >> >> Thanks everyone for your help. >> My research only involves making changes to the hotspot JVM. I do not want to build the class libraries and anything else that I don't have to. Earlier this week, I downloaded just the hotspot compiler from one of Sun's site (not the OpenJDK) and built it on fedora/gcc 4.1.2 after making some changes to the source files, mainly due to gcc incompatibilities, I believe. I also downloaded the latest java SDK hoping that just by replacing the libjvm.so file all would work. >> >> Since that did not work, I started looking at the OpenJDK project. One question I have is, exactly how much of the entire JDK does one have to build to start customizing hotspot? The hotspot FAQ page provides instructions to get the source for the hotspot VM. Those links did not work for me, in particular the one for the source bundle, >> https://openjdk.dev.java.net/servlets/ProjectDocumentList?folderID=6127&expandFolder=6127&folderID=0 >> >> So, I have been attempting to download the OpenJDK using Volker's instructions on his weblog. Currently, I don't have all the files as yet, mercurial only downloads 26 files without hgforest. So, I will try to solve those issues today. Please let me know if any one has any suggestions. >> >> thanks, >> Prasad >> >> >> ---------------------------------------- >>> Date: Thu, 31 Jan 2008 22:23:34 -0800 >>> From: Peter.Kessler at Sun.COM >>> Subject: Re: hotspot build instructions >>> To: prasad1310 at hotmail.com >>> CC: hotspot-dev at openjdk.java.net >>> >>> I wrote osse-build-linux-i586 back when all we had out in the >>> open was the HotSpot source code. It's been superseded by all >>> the good work people have done making it easy (possible) to >>> build HotSpot as part of building the whole OpenJDK. >>> >>> Do you want to build just HotSpot (the JVM, no class libraries) >>> or do you want to build the whole JDK? If so, you might want >>> to post questions on build-dev at openjdk.java.net. >>> >>> I'll take a note to clean up old http://openjdk.java.net/groups/hotspot >>> web pages, but it won't make it to the top of my stack soon. >>> >>> ... peter >>> >>> Prasad Kulkarni wrote: >>>> Hi, >>>> >>>> I am attempting to install hotspot, and use it for some of our research. >>>> Although I have downloaded all the source files, the link to the "instructions >>>> for building Hotspot VM" does not seem to work for me. I am trying to open the >>>> link from the FAQ page at: >>>> http://openjdk.java.net/groups/hotspot/faq.html >>>> >>>> The link for instructions for linux points to: >>>> http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 >>>> >>>> I will greatly appreciate if it could be possible to fix the link, or for some >>>> one to send me their copy of the build instructions. >>>> >>>> thank you, >>>> Prasad >>> >> >> _________________________________________________________________ >> Need to know the score, the latest news, or you need your Hotmail(R)-get your "fix". >> http://www.msnmobilefix.com/Default.aspx _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan From feng.xian at gmail.com Fri Feb 1 12:14:21 2008 From: feng.xian at gmail.com (Feng Xian) Date: Fri, 1 Feb 2008 14:14:21 -0600 Subject: hotspot build instructions In-Reply-To: References: <47A2BAE6.50106@Sun.COM> Message-ID: <610b3d450802011214r322bf2ccq188f92b53814323c@mail.gmail.com> The following link gives an overview of internal details of hotspot. It is very useful for you to read the source code of hotspot. But it only gives explaination of several important functions. http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Command-Line%20Argument%20Processing|outline On 2/1/08, Prasad Kulkarni wrote: > > > I was able to download all the sources. I was also able to build hotspot > using the JDK7 binaries (for now). I had earlier tried to manually use "hg > clone" on all sub-directories, but I had obviously made some mistake there. > Thanks! Your blog is very helpful and instructive! I may use it again to > setup Netbeans. > Do you know of any other resource that gives the internal details of > hotspot (like what function is the entry point for the JIT, interpreter, > function flow, something like that...). > > thank you, > Prasad > > ---------------------------------------- > > Date: Fri, 1 Feb 2008 15:56:33 +0100 > > From: volker.simonis at gmail.com > > To: prasad1310 at hotmail.com > > Subject: Re: hotspot build instructions > > CC: hotspot-dev at openjdk.java.net > > > > You can clone the sources without the forest extension, you just have > > to clone the different trees "manually" (e.g "hg clone > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot" for the hotspot, "hg > > clone http://hg.openjdk.java.net/jdk7/jdk7/jdk" for the jdk tree and > > so on for corba, langtools, jaxp and jaxws). > > > > If you only want to hack the VM, you can either build the entire > > OpenJDK once or download a JDK7 binary from > > http://download.java.net/jdk7/binaries/ and. Than you can build and > > run the OpenJDK HotSpot as described in: > > > http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html#HotSpotBuild > > and > > > http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html#HotSpotRun > > > > On 2/1/08, Prasad Kulkarni wrote: > >> > >> Thanks everyone for your help. > >> My research only involves making changes to the hotspot JVM. I do not > want to build the class libraries and anything else that I don't have to. > Earlier this week, I downloaded just the hotspot compiler from one of Sun's > site (not the OpenJDK) and built it on fedora/gcc 4.1.2 after making some > changes to the source files, mainly due to gcc incompatibilities, I believe. > I also downloaded the latest java SDK hoping that just by replacing the > libjvm.so file all would work. > >> > >> Since that did not work, I started looking at the OpenJDK project. One > question I have is, exactly how much of the entire JDK does one have to > build to start customizing hotspot? The hotspot FAQ page provides > instructions to get the source for the hotspot VM. Those links did not work > for me, in particular the one for the source bundle, > >> > https://openjdk.dev.java.net/servlets/ProjectDocumentList?folderID=6127&expandFolder=6127&folderID=0 > >> > >> So, I have been attempting to download the OpenJDK using Volker's > instructions on his weblog. Currently, I don't have all the files as yet, > mercurial only downloads 26 files without hgforest. So, I will try to solve > those issues today. Please let me know if any one has any suggestions. > >> > >> thanks, > >> Prasad > >> > >> > >> ---------------------------------------- > >>> Date: Thu, 31 Jan 2008 22:23:34 -0800 > >>> From: Peter.Kessler at Sun.COM > >>> Subject: Re: hotspot build instructions > >>> To: prasad1310 at hotmail.com > >>> CC: hotspot-dev at openjdk.java.net > >>> > >>> I wrote osse-build-linux-i586 back when all we had out in the > >>> open was the HotSpot source code. It's been superseded by all > >>> the good work people have done making it easy (possible) to > >>> build HotSpot as part of building the whole OpenJDK. > >>> > >>> Do you want to build just HotSpot (the JVM, no class libraries) > >>> or do you want to build the whole JDK? If so, you might want > >>> to post questions on build-dev at openjdk.java.net. > >>> > >>> I'll take a note to clean up old > http://openjdk.java.net/groups/hotspot > >>> web pages, but it won't make it to the top of my stack soon. > >>> > >>> ... peter > >>> > >>> Prasad Kulkarni wrote: > >>>> Hi, > >>>> > >>>> I am attempting to install hotspot, and use it for some of our > research. > >>>> Although I have downloaded all the source files, the link to the > "instructions > >>>> for building Hotspot VM" does not seem to work for me. I am trying to > open the > >>>> link from the FAQ page at: > >>>> http://openjdk.java.net/groups/hotspot/faq.html > >>>> > >>>> The link for instructions for linux points to: > >>>> http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 > >>>> > >>>> I will greatly appreciate if it could be possible to fix the link, or > for some > >>>> one to send me their copy of the build instructions. > >>>> > >>>> thank you, > >>>> Prasad > >>> > >> > >> _________________________________________________________________ > >> Need to know the score, the latest news, or you need your > Hotmail(R)-get your "fix". > >> http://www.msnmobilefix.com/Default.aspx > > _________________________________________________________________ > Climb to the top of the charts! Play the word scramble challenge with star > power. > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -- Addr: 1025N, 23rd str, APT 33, Lincoln, NE, 68503 Phone: (402)310-9826 WWW: cse.unl.edu/~fxian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080201/2a01d7d9/attachment.html From feng.xian at gmail.com Fri Feb 1 12:24:18 2008 From: feng.xian at gmail.com (Feng Xian) Date: Fri, 1 Feb 2008 14:24:18 -0600 Subject: hotspot build instructions In-Reply-To: References: <47A2BAE6.50106@Sun.COM> Message-ID: <610b3d450802011224r55c5ad68k183b5bbb0152c8df@mail.gmail.com> I guess that you didnt create a .hgrc file in your $HOME directory. Therefore, mercurial could not load forest extensions (fclone, fpush, etc.). Below is my .hgrc . I installed mercurial under /usr/share/hg. Hope it helps. ==============the content of /home/fxian/.hgrc ============ [ui] username = TerryXian [extensions] hgext.forest = /usr/share/hg/lib/python2.5/site-packages/hgext/forest.py ============================ On 2/1/08, Prasad Kulkarni wrote: > > > Thanks everyone for your help. > My research only involves making changes to the hotspot JVM. I do not want > to build the class libraries and anything else that I don't have to. Earlier > this week, I downloaded just the hotspot compiler from one of Sun's site > (not the OpenJDK) and built it on fedora/gcc 4.1.2 after making some > changes to the source files, mainly due to gcc incompatibilities, I believe. > I also downloaded the latest java SDK hoping that just by replacing the > libjvm.so file all would work. > > Since that did not work, I started looking at the OpenJDK project. One > question I have is, exactly how much of the entire JDK does one have to > build to start customizing hotspot? The hotspot FAQ page provides > instructions to get the source for the hotspot VM. Those links did not work > for me, in particular the one for the source bundle, > > https://openjdk.dev.java.net/servlets/ProjectDocumentList?folderID=6127&expandFolder=6127&folderID=0 > > So, I have been attempting to download the OpenJDK using Volker's > instructions on his weblog. Currently, I don't have all the files as yet, > mercurial only downloads 26 files without hgforest. So, I will try to solve > those issues today. Please let me know if any one has any suggestions. > > thanks, > Prasad > > > ---------------------------------------- > > Date: Thu, 31 Jan 2008 22:23:34 -0800 > > From: Peter.Kessler at Sun.COM > > Subject: Re: hotspot build instructions > > To: prasad1310 at hotmail.com > > CC: hotspot-dev at openjdk.java.net > > > > I wrote osse-build-linux-i586 back when all we had out in the > > open was the HotSpot source code. It's been superseded by all > > the good work people have done making it easy (possible) to > > build HotSpot as part of building the whole OpenJDK. > > > > Do you want to build just HotSpot (the JVM, no class libraries) > > or do you want to build the whole JDK? If so, you might want > > to post questions on build-dev at openjdk.java.net. > > > > I'll take a note to clean up old http://openjdk.java.net/groups/hotspot > > web pages, but it won't make it to the top of my stack soon. > > > > ... peter > > > > Prasad Kulkarni wrote: > >> Hi, > >> > >> I am attempting to install hotspot, and use it for some of our > research. > >> Although I have downloaded all the source files, the link to the > "instructions > >> for building Hotspot VM" does not seem to work for me. I am trying to > open the > >> link from the FAQ page at: > >> http://openjdk.java.net/groups/hotspot/faq.html > >> > >> The link for instructions for linux points to: > >> http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 > >> > >> I will greatly appreciate if it could be possible to fix the link, or > for some > >> one to send me their copy of the build instructions. > >> > >> thank you, > >> Prasad > > > > _________________________________________________________________ > Need to know the score, the latest news, or you need your Hotmail(R)-get > your "fix". > http://www.msnmobilefix.com/Default.aspx -- Addr: 1025N, 23rd str, APT 33, Lincoln, NE, 68503 Phone: (402)310-9826 WWW: cse.unl.edu/~fxian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080201/6d4cbf93/attachment.html From John.Rose at Sun.COM Mon Feb 4 16:45:52 2008 From: John.Rose at Sun.COM (John Rose) Date: Mon, 04 Feb 2008 16:45:52 -0800 Subject: JVM internals documentation? In-Reply-To: <002501c80f96$6f0c5790$4d2506b0$@com> References: <09ec01c80ea1$8e8c6bf0$aba543d0$@com> <47127EA5.6080308@sun.com> <002501c80f96$6f0c5790$4d2506b0$@com> Message-ID: Responding to an old and inconclusive thread... Here's a place we can collaborate on internals docs: http://wikis.sun.com/display/HotSpotInternals/Home -- John On Oct 15, 2007, at 6:46 PM, Ted Neward wrote: > I knew about that already; is there anything "deeper" and/or more > detailed? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: James.Melvin at Sun.COM [mailto:James.Melvin at Sun.COM] >> Sent: Sunday, October 14, 2007 1:40 PM >> To: Ted Neward >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: JVM internals documentation? >> >> Hi Ted, >> >> Here is a good place to start... >> >> http://openjdk.java.net/groups/hotspot >> >> There are several docs covering various Hotspot subsystems and >> internals, including a glossary of terms. From Peter.Kessler at Sun.COM Tue Feb 5 17:37:31 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 05 Feb 2008 17:37:31 -0800 Subject: Can I remove this code: Handle::Handle duplicate declaration? Message-ID: <47A90F5B.8080406@Sun.COM> In http://hg.openjdk.java.net/jdk7/hotspot-gc-gate/hotspot/file/a61af66fc99e/src/share/vm/runtime/handles.hpp I see 68 class Handle VALUE_OBJ_CLASS_SPEC { .... 80 #ifndef ASSERT 81 Handle(Thread* thread, oop obj); 82 #else 83 // Don't inline body with assert for current thread 84 Handle(Thread* thread, oop obj); 85 #endif // ASSERT .... 109 }; It looks from the comment in the #else like there used to be an inlined body in the #ifndef, but there isn't any more. Over in http://hg.openjdk.java.net/jdk7/hotspot-gc-gate/hotspot/file/a61af66fc99e/src/share/vm/runtime/handles.inline.hpp there is the inline definition of Handle(Thread*, oop) if ASSERT is not defined, and in http://hg.openjdk.java.net/jdk7/hotspot-gc-gate/hotspot/file/a61af66fc99e/src/share/vm/runtime/handles.cpp there is the non-inline definition of Handle(Thread*, oop) if ASSERT is defined. Just like one would expect. But the declaration is the same in either case, so I think the .hpp file could be cleaned up. Unless something really subtle is going on. ... peter P.S. This might make a good "first push" change, since it would be easy to undo or redo if things don't work quite the way we expect them to. From volker.simonis at gmail.com Fri Feb 8 10:08:16 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 Feb 2008 19:08:16 +0100 Subject: Bug in os::current_frame()/_get_previous_fp() or why parenthesis somtimes really matter Message-ID: Hi, the implementation of "_get_previous_fp()" which is used by "os::current_frame()" seems to be buggy on Solaris/x86_64. "_get_previous_fp()" is implemented as assembler inline function in "hotspot/src/os_cpu/solaris_amd64/vm/solaris_amd64.il" as follows: // Get the frame pointer from previous frame. .inline _get_previous_fp,0 movq %rbp, %rax movq %rax, %rax .end Although I'm not an x86 expert I think that after locking at "generate_get_previous_fp()" in hotspot/src/cpu/amd64/vm/stubGenerator_amd64.cpp which generated a stub that was used previously in "os::current_frame()" to query the frame pointer and looks as follows: address generate_get_previous_fp() { StubCodeMark mark(this, "StubRoutines", "get_previous_fp"); const Address old_fp(rbp, 0); const Address older_fp(rax, 0); address start = __ pc(); __ enter(); __ movq(rax, old_fp); // callers fp __ movq(rax, older_fp); // the frame for ps() __ popq(rbp); __ ret(0); return start; } the correct implementation of "_get_previous_fp()" should read as follows: // Get the frame pointer from previous frame. .inline _get_previous_fp,0 movq (%rbp), %rax movq (%rax), %rax .end The funny thing is that although the current implementation is clearly wrong, it still worked in the debug build. I think this has to do with how CC treats inline assembly under optimization. In the debug build, it generated the following code: 185. frame os::current_frame() { [ 185] 780: pushq %rbp [ 185] 781: movq %rsp,%rbp [ 185] 784: subq $0xc0,%rsp [ 185] 78b: movq %r12,-0xb8(%rbp) [ 185] 792: movq %rdi,-8(%rbp) 186. intptr_t* fp = _get_previous_fp(); [ 186] 796: movl $0,%eax [ 186] 79b: movq %rbp,%rax [ 186] 79e: movq %rax,%rax [ 186] 7a1: movq %rax,%r8 [ 186] 7a4: movq %r8,-0x40(%rbp) 187. frame myframe((intptr_t*)os::current_stack_pointer(), This code returned the wrong, but still a valid fp which is just good enough for "os::current_frame()". However if compiled with '-xO1' as done in the opt build, CC generates the following code: [ ?] 0: pushq %rbp [ ?] 1: movq %rsp,%rbp [ ?] 4: subq $0x60,%rsp [ ?] 8: pushq %r12 [ ?] a: pushq %r13 [ ?] c: movq %rdi,%r12 [ ?] f: movq %rax,%r13 [ ?] 12: call os::current_stack_pointer() [ 0x17, .+5 ] You can see that it elliminated the code from "_get_previous_fp()" and just used the uninitialized value of %rax as frame pointer, which is usually wrong. Notice that this problem exists in the latest JDK 6 build as well as in OpenJDK (Java 7). It probably hasn't showed up until now because "os::current_frame()" is only called in the following three places: 1.oop::register_oop() in /hotspot/src/share/vm/oops/oopsHierarchy.cpp 2.ps() in hotspot/src/share/vm/utilities/debug.cpp 3. VMError::report(outputStream* st) in /hotspot/src/share/vm/utilities/vmError.cpp The first one is usually disabled, the second one is only called by developers in the debugger (and probably for a long time nobody called "ps()" in the debugger for an opt-build) and the last one is during the creation of an hs_error file where probably nobody noticed the problem. Regards, Volker From Steve.Goldman at Sun.COM Fri Feb 8 11:39:49 2008 From: Steve.Goldman at Sun.COM (steve goldman) Date: Fri, 08 Feb 2008 14:39:49 -0500 Subject: Bug in os::current_frame()/_get_previous_fp() or why parenthesis somtimes really matter In-Reply-To: References: Message-ID: <47ACB005.6000300@sun.com> Volker Simonis wrote: > Hi, > > the implementation of "_get_previous_fp()" which is used by > "os::current_frame()" seems to be buggy on Solaris/x86_64. > "_get_previous_fp()" is implemented as assembler inline function in > "hotspot/src/os_cpu/solaris_amd64/vm/solaris_amd64.il" as follows: > > // Get the frame pointer from previous frame. > .inline _get_previous_fp,0 > movq %rbp, %rax > movq %rax, %rax > .end This seems to be correct. Since no new frame pointer is created, the value of rbp is the "fp" of the previous frame, not the previous value of rbp. Certainly the definition of previous is ambiguous here but the .il file on the 32bit side does say it returns the caller's fp. The comment in the 64bit version is more ambiguous. > > Although I'm not an x86 expert I think that after locking at > "generate_get_previous_fp()" in > hotspot/src/cpu/amd64/vm/stubGenerator_amd64.cpp which generated a > stub that was used previously in "os::current_frame()" to query the > frame pointer and looks as follows: > > address generate_get_previous_fp() { > StubCodeMark mark(this, "StubRoutines", "get_previous_fp"); > const Address old_fp(rbp, 0); > const Address older_fp(rax, 0); > address start = __ pc(); > > __ enter(); > __ movq(rax, old_fp); // callers fp > __ movq(rax, older_fp); // the frame for ps() > __ popq(rbp); > __ ret(0); > this code is incorrect. The frame pointer that is desired in os::current_frame is the frame pointer that exists for itself. The frame it constructs uses "previous fp" (it's own fp) and current sp. That is a sensible frame. The incorrect code would create a frame whose fp was from the call of os::current_frame and whose sp was the sp for os::current_frame which is not a proper description of the frame. For what this particular frame is used for it is completely harmless since we won't be doing anything with sp. The truth is almost any value of fp that is returned that is actually a frame pointer is usable since the stack walking the caller's are going to do is dependent on fp being a valid frame pointer and that's about it. > return start; > } > > the correct implementation of "_get_previous_fp()" should read as follows: > > // Get the frame pointer from previous frame. > .inline _get_previous_fp,0 > movq (%rbp), %rax > movq (%rax), %rax > .end > > The funny thing is that although the current implementation is clearly > wrong, it still worked in the debug build. I think this has to do with > how CC treats inline assembly under optimization. In the debug build, > it generated the following code: > > 185. frame os::current_frame() { > > [ 185] 780: pushq %rbp > [ 185] 781: movq %rsp,%rbp > [ 185] 784: subq $0xc0,%rsp > [ 185] 78b: movq %r12,-0xb8(%rbp) > [ 185] 792: movq %rdi,-8(%rbp) > 186. intptr_t* fp = _get_previous_fp(); > [ 186] 796: movl $0,%eax > [ 186] 79b: movq %rbp,%rax > [ 186] 79e: movq %rax,%rax > [ 186] 7a1: movq %rax,%r8 > [ 186] 7a4: movq %r8,-0x40(%rbp) > 187. frame myframe((intptr_t*)os::current_stack_pointer(), > > This code returned the wrong, but still a valid fp which is just good > enough for "os::current_frame()". However if compiled with '-xO1' as > done in the opt build, CC generates the following code: > > > [ ?] 0: pushq %rbp > [ ?] 1: movq %rsp,%rbp > [ ?] 4: subq $0x60,%rsp > [ ?] 8: pushq %r12 > [ ?] a: pushq %r13 > [ ?] c: movq %rdi,%r12 > [ ?] f: movq %rax,%r13 > [ ?] 12: call os::current_stack_pointer() [ > 0x17, .+5 ] > > You can see that it elliminated the code from "_get_previous_fp()" and > just used the uninitialized value of %rax as frame pointer, which is > usually wrong. I think this is a CC bug. How is it able to eliminate the read of rbp and simply give us a random value in rax? Maybe the .il file needs some annotation so that the compiler doesn't decide that rbp is "un-initialized" and so any old value in rax is as good as another. > > Notice that this problem exists in the latest JDK 6 build as well as > in OpenJDK (Java 7). It probably hasn't showed up until now because > "os::current_frame()" is only called in the following three places: > > 1.oop::register_oop() in /hotspot/src/share/vm/oops/oopsHierarchy.cpp > 2.ps() in hotspot/src/share/vm/utilities/debug.cpp > 3. VMError::report(outputStream* st) in > /hotspot/src/share/vm/utilities/vmError.cpp > > The first one is usually disabled, the second one is only called by > developers in the debugger (and probably for a long time nobody called > "ps()" in the debugger for an opt-build) and the last one is during > the creation of an hs_error file where probably nobody noticed the > problem. > > Regards, > Volker -- Steve From kirk.pepperdine at gmail.com Tue Feb 12 00:35:26 2008 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 12 Feb 2008 09:35:26 +0100 Subject: wacky micro-benchmark Message-ID: I've been fiddling with the loop invariant hoisting optimization trying to demonstrate how it works. In my first iteration I used a long to sum up the invariant in a loop. First run with -Xint showed 7.6 seconds for the hoisted version and 15.4 for the non-hoisted version. Pretty much as one would predict. Running with -client I see 3.5 seconds for hoisted and 6.3 for non-hoisted. A bit of surprise because I figured the client would hoist the invariant but it appears not to have. Then things got weird when I ran with -server. The hoisted code ran in 6.3 seconds and non hoisted in 6.4. Now, I expected the values to be about the same but not towards the slower end of the spectrum. I of course immediately suspected that the benchmark is bad as that is usually is the case more often than not. However after lots of fiddles (checking for mono/poly morphic optimizations... etc) I was unable to get a different result which now leaves me wondering, is there something with long in loop invariants that results in a slower optimization than expected? And why would the client compiler not hoist the invariant. One of the fiddles was to change the longs to ints. The server compiler ran in (hoisted) 46ms and (non-hoisted) 47ms respectively. Difficult to say without further testing if they are really the same. Client testing was 1188ms and 1297ms respectively. Again difficult to say without further testing if these are the same. For completeness the -Xint values are 99.2sand 126.5s. It was very nice to see that without having any return value, the -server compiler identified the methods as dead and replaced the call with a noop. So, does anyone have any comments (including you are a moron for attempting this ;-)) on why the long invariant hoisting bench appears to be broken. -- Kind regards, Kirk Pepperdine http://www.kodewerk.com http://www.javaperformancetuning.com http//www.cretesoft.com public int hoist( int a, int b) { int total = Integer.MIN_VALUE; int hoisted = a + b; for ( int i = 0; i < LOOP_COUNT; i++) total += hoisted; return total; } public int nonHoist( int a, int b) { int total = Integer.MIN_VALUE; for ( int i = 0; i < LOOP_COUNT; i++) total += (a + b); return total; } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080212/476d6a76/attachment.html From John.Rose at Sun.COM Tue Feb 12 01:57:29 2008 From: John.Rose at Sun.COM (John Rose) Date: Tue, 12 Feb 2008 01:57:29 -0800 Subject: wacky micro-benchmark In-Reply-To: References: Message-ID: <9FEF641B-B923-484A-83E2-C074B7781B7B@sun.com> Hi, Kirk. You seem to be measuring noise. Can someone on this list please produce the standard URL about "10 mistakes you shouldn't make when playing with HotSpot and micro-benchmarks"? The server compiler routinely hoists values like a+b for you, since it uses global value numbering. It is therefore compiling the same SSA graph in both cases. If you want to measure stuff like that, you need to look at the disassembled code and make sure your cases differ in the way you expect. I think you'd be surprised (and find intriguing things to ponder) if you were to study the output code. That's what I do when I'm trying to figure out what the JIT is thinking. If you can find or build a "fastdebug" version of the server JVM, run it with -XX:+PrintOptoAssembly. Best wishes, -- John P.S. There's a Gnu-based disassembler also which has internally been integrated with HotSpot, but for various almost-forgettable legal reasons we cannot easily release it, yet. Maybe some kind soul outside of Sun can re-integrate it into HotSpot as a hygenically factored disassembler.so. The flag -XX:+PrintAssembly requires this separate module, and when it works it produces truly wonderful output. On Feb 12, 2008, at 12:35 AM, Kirk Pepperdine wrote: > > public int hoist( int a, int b) { > int total = Integer.MIN_VALUE; > int hoisted = a + b; > for ( int i = 0; i < LOOP_COUNT; i++) > total += hoisted; > return total; > } > > public int nonHoist( int a, int b) { > int total = Integer.MIN_VALUE; > for ( int i = 0; i < LOOP_COUNT; i++) > total += (a + b); > return total; > } From volker.simonis at gmail.com Tue Feb 12 02:29:17 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 12 Feb 2008 11:29:17 +0100 Subject: wacky micro-benchmark In-Reply-To: <9FEF641B-B923-484A-83E2-C074B7781B7B@sun.com> References: <9FEF641B-B923-484A-83E2-C074B7781B7B@sun.com> Message-ID: > P.S. There's a Gnu-based disassembler also > which has internally been integrated with > HotSpot, but for various almost-forgettable > legal reasons we cannot easily release > it, yet. Maybe some kind soul outside > of Sun can re-integrate it into HotSpot as a > hygenically factored disassembler.so. > The flag -XX:+PrintAssembly requires > this separate module, and when it > works it produces truly wonderful output. > I don't pretend to be the kind soul that's been asked for in the post, but some while ago I submitted a patch to this list which enabled the disassembler for i486. You can find it here: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2007-August/000015.html If you follow the thread, you'll see that Chuck Rasbold from Sun was working on this topic. I agreed with him to use a version of the disassembler that doesn't include but just uses an opaque interface (in fact just a duplication of some structs from ) declared within the JDK to communicate with the libopcode library. But I have to admit, I didn't finished it yet and Chuck probably didn't had the time either, so it will probably stay a fix for some more time. As mentioned before, the problems are not technical but rather licensing issues (mostly because the dissasembler is GPL licensed and can not easily be reassigned a dual license as required by the OpenJDK/SCL). For more details you can see this thread: http://mail.openjdk.java.net/pipermail/discuss/2007-August/000189.html I'm ready to take over the role of the "kind soul outside of Sun" and volunteer in integrating the disassembler into the OpenJDK if only we could solve the legal issues and some peer inside SUN will review the code (Chuck?). Regards, Volker > > On Feb 12, 2008, at 12:35 AM, Kirk Pepperdine wrote: > > > > > public int hoist( int a, int b) { > > int total = Integer.MIN_VALUE; > > int hoisted = a + b; > > for ( int i = 0; i < LOOP_COUNT; i++) > > total += hoisted; > > return total; > > } > > > > public int nonHoist( int a, int b) { > > int total = Integer.MIN_VALUE; > > for ( int i = 0; i < LOOP_COUNT; i++) > > total += (a + b); > > return total; > > } > > From Steve.Goldman at Sun.COM Tue Feb 12 06:16:19 2008 From: Steve.Goldman at Sun.COM (steve goldman) Date: Tue, 12 Feb 2008 09:16:19 -0500 Subject: wacky micro-benchmark In-Reply-To: References: Message-ID: <47B1AA33.4020008@sun.com> Kirk Pepperdine wrote: > I've been fiddling with the loop invariant hoisting optimization trying to > demonstrate how it works. In my first iteration I used a long to sum up the > invariant in a loop. First run with -Xint showed 7.6 seconds for the hoisted > version and 15.4 for the non-hoisted version. Pretty much as one would > predict. Running with -client I see 3.5 seconds for hoisted and 6.3 for > non-hoisted. A bit of surprise because I figured the client would hoist the > invariant but it appears not to have. Then things got weird when I ran with > -server. The hoisted code ran in 6.3 seconds and non hoisted in 6.4. Now, I > expected the values to be about the same but not towards the slower end of > the spectrum. As John Rose already stated micro-benchmarks are tricky and unless you look at the generated code you are often surprised. Heck the compiler writers are often surprised. You have a lot of other variables to worry about when shifting from client/server. The compile threshold for server is 10x the client compiler. Also it appears that the code you have here will probably have to do an OSR (on stack replacement) to get to running compiled code. It's not too surprising that the results are surprising. > > I of course immediately suspected that the benchmark is bad as that is > usually is the case more often than not. However after lots of fiddles > (checking for mono/poly morphic optimizations... etc) I was unable to get a > different result which now leaves me wondering, is there something with long > in loop invariants that results in a slower optimization than expected? And > why would the client compiler not hoist the invariant. The client compiler is not an optimizing compiler. You should suspect that it doesn't hoist loop invariants. As far as the server compiler there should be anything special about long vs. ints. they should all be treated the same by the global value numbering. -- Steve From volker.simonis at gmail.com Tue Feb 12 09:15:20 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 12 Feb 2008 18:15:20 +0100 Subject: Bug in os::current_frame()/_get_previous_fp() or why parenthesis somtimes really matter In-Reply-To: <47ACB005.6000300@sun.com> References: <47ACB005.6000300@sun.com> Message-ID: On 2/8/08, steve goldman wrote: > Volker Simonis wrote: > > Hi, > > > > the implementation of "_get_previous_fp()" which is used by > > "os::current_frame()" seems to be buggy on Solaris/x86_64. > > "_get_previous_fp()" is implemented as assembler inline function in > > "hotspot/src/os_cpu/solaris_amd64/vm/solaris_amd64.il" as follows: > > > > // Get the frame pointer from previous frame. > > .inline _get_previous_fp,0 > > movq %rbp, %rax > > movq %rax, %rax > > .end > > This seems to be correct. Since no new frame pointer is created, the > value of rbp is the "fp" of the previous frame, not the previous value > of rbp. Certainly the definition of previous is ambiguous here but the > .il file on the 32bit side does say it returns the caller's fp. The > comment in the 64bit version is more ambiguous. > Ok, I agree with you on this. But what is the line: movq %rax, %rax good for. Isn't it just a nop? > > > > Although I'm not an x86 expert I think that after locking at > > "generate_get_previous_fp()" in > > hotspot/src/cpu/amd64/vm/stubGenerator_amd64.cpp which generated a > > stub that was used previously in "os::current_frame()" to query the > > frame pointer and looks as follows: > > > > address generate_get_previous_fp() { > > StubCodeMark mark(this, "StubRoutines", "get_previous_fp"); > > const Address old_fp(rbp, 0); > > const Address older_fp(rax, 0); > > address start = __ pc(); > > > > __ enter(); > > __ movq(rax, old_fp); // callers fp > > __ movq(rax, older_fp); // the frame for ps() > > __ popq(rbp); > > __ ret(0); > > > > this code is incorrect. The frame pointer that is desired in > os::current_frame is the frame pointer that exists for itself. The frame > it constructs uses "previous fp" (it's own fp) and current sp. That is a > sensible frame. > > The incorrect code would create a frame whose fp was from the call of > os::current_frame and whose sp was the sp for os::current_frame which is > not a proper description of the frame. > > For what this particular frame is used for it is completely harmless > since we won't be doing anything with sp. The truth is almost any value > of fp that is returned that is actually a frame pointer is usable since > the stack walking the caller's are going to do is dependent on fp being > a valid frame pointer and that's about it. > > > return start; > > } > > > > the correct implementation of "_get_previous_fp()" should read as follows: > > > > // Get the frame pointer from previous frame. > > .inline _get_previous_fp,0 > > movq (%rbp), %rax > > movq (%rax), %rax > > .end > > > > The funny thing is that although the current implementation is clearly > > wrong, it still worked in the debug build. I think this has to do with > > how CC treats inline assembly under optimization. In the debug build, > > it generated the following code: > > > > 185. frame os::current_frame() { > > > > [ 185] 780: pushq %rbp > > [ 185] 781: movq %rsp,%rbp > > [ 185] 784: subq $0xc0,%rsp > > [ 185] 78b: movq %r12,-0xb8(%rbp) > > [ 185] 792: movq %rdi,-8(%rbp) > > 186. intptr_t* fp = _get_previous_fp(); > > [ 186] 796: movl $0,%eax > > [ 186] 79b: movq %rbp,%rax > > [ 186] 79e: movq %rax,%rax > > [ 186] 7a1: movq %rax,%r8 > > [ 186] 7a4: movq %r8,-0x40(%rbp) > > 187. frame myframe((intptr_t*)os::current_stack_pointer(), > > > > This code returned the wrong, but still a valid fp which is just good > > enough for "os::current_frame()". However if compiled with '-xO1' as > > done in the opt build, CC generates the following code: > > > > > > [ ?] 0: pushq %rbp > > [ ?] 1: movq %rsp,%rbp > > [ ?] 4: subq $0x60,%rsp > > [ ?] 8: pushq %r12 > > [ ?] a: pushq %r13 > > [ ?] c: movq %rdi,%r12 > > [ ?] f: movq %rax,%r13 > > [ ?] 12: call os::current_stack_pointer() [ > > 0x17, .+5 ] > > > > You can see that it elliminated the code from "_get_previous_fp()" and > > just used the uninitialized value of %rax as frame pointer, which is > > usually wrong. > > I think this is a CC bug. How is it able to eliminate the read of rbp > and simply give us a random value in rax? Maybe the .il file needs some > annotation so that the compiler doesn't decide that rbp is > "un-initialized" and so any old value in rax is as good as another. > I also agree on this one - seems to be a compiler bug. I found Alfred Huang's weblog at http://blogs.sun.com/alblog/entry/on_studio_and_gcc_style where he explains that inline assembler templates get heavily optimzed by the backend ('ube' on x86). The solution is to use the compiler option '-Wu,-no_a2lf' for C or "-Qoption ube -no_a2lf" for C++ to disable inline assembly optimization. This can be easily added to 'hotspot/build/solaris/makefiles/amd64.make' which already contains special opt-flags for 'os_solaris_amd64.o' anyway: OPT_CFLAGS/os_solaris_amd64.o = -xO1 -Qoption ube -no_a2lf > > > > Notice that this problem exists in the latest JDK 6 build as well as > > in OpenJDK (Java 7). It probably hasn't showed up until now because > > "os::current_frame()" is only called in the following three places: > > > > 1.oop::register_oop() in /hotspot/src/share/vm/oops/oopsHierarchy.cpp > > 2.ps() in hotspot/src/share/vm/utilities/debug.cpp > > 3. VMError::report(outputStream* st) in > > /hotspot/src/share/vm/utilities/vmError.cpp > > > > The first one is usually disabled, the second one is only called by > > developers in the debugger (and probably for a long time nobody called > > "ps()" in the debugger for an opt-build) and the last one is during > > the creation of an hs_error file where probably nobody noticed the > > problem. > > > > Regards, > > Volker > > > -- > Steve > From kirk.pepperdine at gmail.com Tue Feb 12 00:45:18 2008 From: kirk.pepperdine at gmail.com (Kirk) Date: Tue, 12 Feb 2008 09:45:18 +0100 Subject: wacky micro-benchmark In-Reply-To: References: Message-ID: <47B15C9E.5040107@javaperformancetuning.com> I should have added that this is the JDK 1.6.0_04-b12 running on Windows XP, plenty of RAM and no garbage. Kirk Pepperdine wrote: > I've been fiddling with the loop invariant hoisting optimization > trying to demonstrate how it works. In my first iteration I used a > long to sum up the invariant in a loop. First run with -Xint showed > 7.6 seconds for the hoisted version and 15.4 for the non-hoisted > version. Pretty much as one would predict. Running with -client I see > 3.5 seconds for hoisted and 6.3 for non-hoisted. A bit of surprise > because I figured the client would hoist the invariant but it appears > not to have. Then things got weird when I ran with -server. The > hoisted code ran in 6.3 seconds and non hoisted in 6.4. Now, I > expected the values to be about the same but not towards the slower > end of the spectrum. > > I of course immediately suspected that the benchmark is bad as that is > usually is the case more often than not. However after lots of fiddles > (checking for mono/poly morphic optimizations... etc) I was unable to > get a different result which now leaves me wondering, is there > something with long in loop invariants that results in a slower > optimization than expected? And why would the client compiler not > hoist the invariant. > > One of the fiddles was to change the longs to ints. The server > compiler ran in (hoisted) 46ms and (non-hoisted) 47ms respectively. > Difficult to say without further testing if they are really the same. > Client testing was 1188ms and 1297ms respectively. Again difficult to > say without further testing if these are the same. For completeness > the -Xint values are 99.2s and 126.5s. > > It was very nice to see that without having any return value, the > -server compiler identified the methods as dead and replaced the call > with a noop. > > So, does anyone have any comments (including you are a moron for > attempting this ;-)) on why the long invariant hoisting bench appears > to be broken. > > -- > Kind regards, > Kirk Pepperdine > > http://www.kodewerk.com > http://www.javaperformancetuning.com > http//www.cretesoft.com > > public int hoist( int a, int b) { > int total = Integer.MIN_VALUE; > int hoisted = a + b; > for ( int i = 0; i < LOOP_COUNT; i++) > total += hoisted; > return total; > } > > public int nonHoist( int a, int b) { > int total = Integer.MIN_VALUE; > for ( int i = 0; i < LOOP_COUNT; i++) > total += (a + b); > return total; > } From charlie.hunt at sun.com Tue Feb 12 06:31:52 2008 From: charlie.hunt at sun.com (charlie hunt) Date: Tue, 12 Feb 2008 08:31:52 -0600 Subject: wacky micro-benchmark In-Reply-To: <9FEF641B-B923-484A-83E2-C074B7781B7B@sun.com> References: <9FEF641B-B923-484A-83E2-C074B7781B7B@sun.com> Message-ID: <47B1ADD8.5030908@sun.com> Kirk, If you haven't already discovered Sun Studio Collector / Analyzer, you might find it very useful for a lot of the performance work you do. It's free, it runs on Linux & Solaris and can be downloaded from http://developers.sun.com/sunstudio/downloads/. Here's several additional links on using Sun Studio Collector / Analyzer: - (Intro) http://developers.sun.com/solaris/articles/perftools.html - (Profile Java apps) http://developers.sun.com/solaris/articles/javapps.html - (Profile WebSphere) http://developers.sun.com/solaris/articles/profiling_websphere.html In the absence of -XX:+PrintOptoAssembly and a fastdebug JVM, Sun Studio's Collector / Analyzer might give you some clues as to what's happening with your micro-benchmark. If you tell Sun Studio Analyzer to present the collected information in machine mode, you can view the generated assembly. I'm speculating you won't get as much detailed information as -XX:+PrintOptoAssembly though. But, you will be able to view the generated assembly. Disclaimer: I have not run Sun Studio Collector / Analyzer on Linux so I don't know if there are any limitations over what's available on Solaris x86 / Sparc. hths, charlie ... John Rose wrote: > Hi, Kirk. You seem to be measuring noise. > > Can someone on this list please produce > the standard URL about "10 mistakes you > shouldn't make when playing with > HotSpot and micro-benchmarks"? > > The server compiler routinely hoists > values like a+b for you, since it uses > global value numbering. It is therefore > compiling the same SSA graph in > both cases. > > If you want to measure stuff like that, > you need to look at the disassembled > code and make sure your cases differ > in the way you expect. I think you'd > be surprised (and find intriguing things > to ponder) if you were to study the > output code. That's what I do when > I'm trying to figure out what the JIT > is thinking. > > If you can find or build a "fastdebug" > version of the server JVM, run it > with -XX:+PrintOptoAssembly. > > Best wishes, > -- John > > P.S. There's a Gnu-based disassembler also > which has internally been integrated with > HotSpot, but for various almost-forgettable > legal reasons we cannot easily release > it, yet. Maybe some kind soul outside > of Sun can re-integrate it into HotSpot as a > hygenically factored disassembler.so. > The flag -XX:+PrintAssembly requires > this separate module, and when it > works it produces truly wonderful output. > > > On Feb 12, 2008, at 12:35 AM, Kirk Pepperdine wrote: > >> >> public int hoist( int a, int b) { >> int total = Integer.MIN_VALUE; >> int hoisted = a + b; >> for ( int i = 0; i < LOOP_COUNT; i++) >> total += hoisted; >> return total; >> } >> >> public int nonHoist( int a, int b) { >> int total = Integer.MIN_VALUE; >> for ( int i = 0; i < LOOP_COUNT; i++) >> total += (a + b); >> return total; >> } > -- Charlie Hunt Java Performance Engineer From kirk.pepperdine at gmail.com Tue Feb 12 02:27:20 2008 From: kirk.pepperdine at gmail.com (Kirk) Date: Tue, 12 Feb 2008 11:27:20 +0100 Subject: wacky micro-benchmark In-Reply-To: <9FEF641B-B923-484A-83E2-C074B7781B7B@sun.com> References: <9FEF641B-B923-484A-83E2-C074B7781B7B@sun.com> Message-ID: <47B17488.5070506@javaperformancetuning.com> Hi John, Thanks for your response. I was expected that both methods would produce the same SSA graph. So I was expecting that both methods would produce the same results. What I wasn't expecting was that the run time would drift towards the slower end of the scale. I'm looking for a fastdebug version of the JVM. Kirk John Rose wrote: > Hi, Kirk. You seem to be measuring noise. > > Can someone on this list please produce > the standard URL about "10 mistakes you > shouldn't make when playing with > HotSpot and micro-benchmarks"? > > The server compiler routinely hoists > values like a+b for you, since it uses > global value numbering. It is therefore > compiling the same SSA graph in > both cases. > > If you want to measure stuff like that, > you need to look at the disassembled > code and make sure your cases differ > in the way you expect. I think you'd > be surprised (and find intriguing things > to ponder) if you were to study the > output code. That's what I do when > I'm trying to figure out what the JIT > is thinking. > > If you can find or build a "fastdebug" > version of the server JVM, run it > with -XX:+PrintOptoAssembly. > > Best wishes, > -- John > > P.S. There's a Gnu-based disassembler also > which has internally been integrated with > HotSpot, but for various almost-forgettable > legal reasons we cannot easily release > it, yet. Maybe some kind soul outside > of Sun can re-integrate it into HotSpot as a > hygenically factored disassembler.so. > The flag -XX:+PrintAssembly requires > this separate module, and when it > works it produces truly wonderful output. > > > On Feb 12, 2008, at 12:35 AM, Kirk Pepperdine wrote: > >> >> public int hoist( int a, int b) { >> int total = Integer.MIN_VALUE; >> int hoisted = a + b; >> for ( int i = 0; i < LOOP_COUNT; i++) >> total += hoisted; >> return total; >> } >> >> public int nonHoist( int a, int b) { >> int total = Integer.MIN_VALUE; >> for ( int i = 0; i < LOOP_COUNT; i++) >> total += (a + b); >> return total; >> } > > From loveheaven_zhengwei at hotmail.com Thu Feb 14 05:57:24 2008 From: loveheaven_zhengwei at hotmail.com (Wei Zheng) Date: Thu, 14 Feb 2008 21:57:24 +0800 Subject: Help! where the interpreter is invoked? Message-ID: Hi All, I am reading the source codes of hotspot. I want to know where the interpreter is invoked to translate the bytecodes of the static method "main" in a class file into native instructions. I debugged the source codes and found the functions below are invoked to execute the static method "main" : jni_CallStaticVoidMethod -> jni_invoke_static -> JavaCalls::call -> JavaCalls::call_helper -> StubRoutines::call_stub()( (address)&link, ..) // the static method "main" is executed after this step. Who can tell me where the interpreter is invoked in the functions above? Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080214/19b749a7/attachment.html From lars.westergren at ki.se Thu Feb 14 06:53:18 2008 From: lars.westergren at ki.se (Lars Westergren) Date: Thu, 14 Feb 2008 15:53:18 +0100 Subject: Patch submission advice: use webrev, jtreg tests where, cmd line test? Message-ID: <47B455DE.6040705@ki.se> Hello, I have a fix ready for bug 6523160 - "RuntimeMXBean.getUptime() returns negative values". Mandy Chung long ago suggested I use this mailing list rather than the management mailinglist for this bug since the fix involves changes in Hotspot code. Before I submit, I wanted to clarify three things - 1. Should I include diff files as attachments as is recommended here: http://openjdk.java.net/contribute/ or do you now prefer that I use Webrev for OpenJDK as Jean-Christophe Collet describes, so I include a link to my webrev pages in the mail instead? http://blogs.sun.com/jcc/ 2. My jtreg tests, would you prefer them included as standalone files attachments to the mail so you yourselves can decide where to put them, or should I place them in the correct package in jdk/test so they become a part of the webrev? 3. Provoking the bug involves setting back the OS clock. Is it ok if I use the command line "date" command (making the test platform dependent) to set back the clock in the test? Or should I prefer user interaction as is done in some other tests I've seen - i.e. popping up a window that says "Set back the OS clock an hour now, click 'ok' when done to continue"? Thanks in advance, Lars From v-weizhe at microsoft.com Thu Feb 14 05:54:33 2008 From: v-weizhe at microsoft.com (Wei Zheng (Person Consulting)) Date: Thu, 14 Feb 2008 21:54:33 +0800 Subject: Help! where the interpreter is invoked? Message-ID: Hi All, I am reading the source codes of hotspot. I want to know where the interpreter is invoked to translate the bytecodes of the static method "main" in a class file into native instructions. I debugged the source codes and found the functions below are invoked to execute the static method "main" : jni_CallStaticVoidMethod -> jni_invoke_static -> JavaCalls::call -> JavaCalls::call_helper -> StubRoutines::call_stub()( (address)&link, ....) // the static method "main" is executed after this step. Who can tell me where the interpreter is invoked in the functions above? Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080214/3313509b/attachment.html From Mandy.Chung at Sun.COM Thu Feb 14 14:51:17 2008 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Thu, 14 Feb 2008 14:51:17 -0800 Subject: Patch submission advice: use webrev, jtreg tests where, cmd line test? In-Reply-To: <47B455DE.6040705@ki.se> References: <47B455DE.6040705@ki.se> Message-ID: <47B4C5E5.1010309@Sun.com> Hi Lars, Thanks for getting a fix for 6523160. You can use serviceability-dev at openjdk.java.net alias for submitting the patch and I believe the change in the hotspot code is local to serviceability. My comment is inlined.... Lars Westergren wrote: > Hello, > > I have a fix ready for bug 6523160 - "RuntimeMXBean.getUptime() returns > negative values". Mandy Chung long ago suggested I use this mailing list > rather than the management mailinglist for this bug since the fix > involves changes in Hotspot code. > > > Before I submit, I wanted to clarify three things - > > 1. Should I include diff files as attachments as is recommended here: > http://openjdk.java.net/contribute/ > or do you now prefer that I use Webrev for OpenJDK as Jean-Christophe > Collet describes, so I include a link to my webrev pages in the mail > instead? > http://blogs.sun.com/jcc/ It would be great if you can use webrev. It's a very useful code-review generating tool and I'm sure you will like it. You can either include a link to your webrev (public accessible) or include the tarball of the webrev pages which is also fine with me. > 2. My jtreg tests, would you prefer them included as standalone files > attachments to the mail so you yourselves can decide where to put them, > or should I place them in the correct package in jdk/test so they become > a part of the webrev? You can just include the jtreg tests in the jdk/test/java/lang/management/RuntimeMXBean directory since the test will be specific for testing that API. I'll be able to get a copy of the test from the webrev generated. FYI. The source and test location for the serviceability project are listed at: http://openjdk.java.net/groups/serviceability/svcjdk.html > 3. Provoking the bug involves setting back the OS clock. Is it ok if I > use the command line "date" command (making the test platform dependent) > to set back the clock in the test? Or should I prefer user interaction > as is done in some other tests I've seen - i.e. popping up a window that > says "Set back the OS clock an hour now, click 'ok' when done to continue"? The jtreg tests have to be fully automated and can be run on machines that may be used by others for various purposes. In addition, changing the clock on a shared machine might cause unexpected problems to other applications/testing running on the same machine. The Java SE Quality team has several functional tests that fail due to this bug. I can help run those tests to verify your fix. We can work together. Mandy P.S. I'll be on vacation next week and return on 1/25. > > Thanks in advance, > Lars From pnasrat at thoughtworks.com Fri Feb 22 00:40:29 2008 From: pnasrat at thoughtworks.com (Paul Nasrat) Date: Fri, 22 Feb 2008 08:40:29 +0000 Subject: [New Bug] cscope make target doesn't work with mercurial repository Message-ID: The current cscope makefile targets rely on Codemgr directories, the attached patch switches to use hg fstatus to get the desired information of added/removed files. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-hotspot-cscope-mercurial.patch Type: application/octet-stream Size: 1150 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080222/1815272a/attachment.obj From John.Rose at Sun.COM Sun Feb 24 01:04:15 2008 From: John.Rose at Sun.COM (John Rose) Date: Sun, 24 Feb 2008 01:04:15 -0800 Subject: wacky micro-benchmark In-Reply-To: References: <9FEF641B-B923-484A-83E2-C074B7781B7B@sun.com> Message-ID: <4B03A074-E459-469F-B12F-37304EB41BB4@Sun.COM> On Feb 12, 2008, at 2:29 AM, Volker Simonis wrote: >> P.S. There's a Gnu-based disassembler also >> which has internally been integrated with >> HotSpot, but for various almost-forgettable >> legal reasons we cannot easily release >> it, yet. Maybe some kind soul outside >> of Sun can re-integrate it into HotSpot as a >> hygenically factored disassembler.so. >> > > I don't pretend to be the kind soul that's been asked for in the post, > but some while ago I submitted a patch to this list which enabled the > disassembler for i486. You can find it here: > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2007- > August/000015.html > > I'm ready to take over the role of the "kind soul outside of Sun" and > volunteer in integrating the disassembler into the OpenJDK if only we > could solve the legal issues and some peer inside SUN will review the > code (Chuck?). Thanks for showing the way on this problem. I made a similar integration of the binutils code, but only with a plugin project (a single file of shim). That keeps the GNU code at a suitable distance from the HotSpot code. Meanwhile, it's time get rid of the old plugin interface in the JVM, for a number of reasons. This week I have freshened up the disassembly handling by reworking the plugin interface and promoting the disassembly output options to 'diagnostic' status, which means they are available in product mode, for help with debugging the JVM and Java apps. in the field. I just posted a review request: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2008- February/000060.html An initial binutils-based version of the plugin is included for reference in the review request. Best wishes, -- John From mr at sun.com Fri Feb 29 21:47:00 2008 From: mr at sun.com (mr at sun.com) Date: Sat, 01 Mar 2008 05:47:00 +0000 Subject: hg: jdk7/hotspot: 2 new changesets Message-ID: <20080301054700.F364926E25@hg.openjdk.java.net> Changeset: 0a5c5386a678 Author: xdono Date: 2007-12-04 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/0a5c5386a678 Added tag jdk7-b24 for changeset cfeea66a3fa8 + .hgtags Changeset: c57bef8dda9c Author: mr Date: 2008-02-29 20:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/c57bef8dda9c 6669216: Add jcheck configuration directories Reviewed-by: ohair, xdono + .jcheck/conf From mr at sun.com Fri Feb 29 21:47:06 2008 From: mr at sun.com (mr at sun.com) Date: Sat, 01 Mar 2008 05:47:06 +0000 Subject: hg: jdk7/hotspot/corba: 2 new changesets Message-ID: <20080301054708.61EE926E2C@hg.openjdk.java.net> Changeset: 474c23b174e9 Author: xdono Date: 2007-12-04 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/474c23b174e9 Added tag jdk7-b24 for changeset 55540e827aef + .hgtags Changeset: fec639c69db2 Author: mr Date: 2008-02-29 20:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/fec639c69db2 6669216: Add jcheck configuration directories Reviewed-by: ohair, xdono + .jcheck/conf From mr at sun.com Fri Feb 29 21:47:25 2008 From: mr at sun.com (mr at sun.com) Date: Sat, 01 Mar 2008 05:47:25 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20080301054731.6994F26E33@hg.openjdk.java.net> Changeset: 92489cdc94d1 Author: xdono Date: 2007-12-04 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/92489cdc94d1 Added tag jdk7-b24 for changeset a61af66fc99e + .hgtags Changeset: 7836be3e92d0 Author: mr Date: 2008-02-29 20:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7836be3e92d0 6669216: Add jcheck configuration directories Reviewed-by: ohair, xdono + .jcheck/conf From mr at sun.com Fri Feb 29 21:48:09 2008 From: mr at sun.com (mr at sun.com) Date: Sat, 01 Mar 2008 05:48:09 +0000 Subject: hg: jdk7/hotspot/jaxp: 2 new changesets Message-ID: <20080301054813.4BA1026E3A@hg.openjdk.java.net> Changeset: 9e3c1ad7cdb9 Author: xdono Date: 2007-12-04 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/9e3c1ad7cdb9 Added tag jdk7-b24 for changeset 6ce5f4757bde + .hgtags Changeset: 49a4bc7b0aa0 Author: mr Date: 2008-02-29 20:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/49a4bc7b0aa0 6669216: Add jcheck configuration directories Reviewed-by: ohair, xdono + .jcheck/conf From mr at sun.com Fri Feb 29 21:48:20 2008 From: mr at sun.com (mr at sun.com) Date: Sat, 01 Mar 2008 05:48:20 +0000 Subject: hg: jdk7/hotspot/jaxws: 2 new changesets Message-ID: <20080301054823.859D726E41@hg.openjdk.java.net> Changeset: 7d53d3bd7879 Author: xdono Date: 2007-12-04 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/7d53d3bd7879 Added tag jdk7-b24 for changeset 0961a4a21176 + .hgtags Changeset: 018781e80410 Author: mr Date: 2008-02-29 20:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/018781e80410 6669216: Add jcheck configuration directories Reviewed-by: ohair, xdono + .jcheck/conf From mr at sun.com Fri Feb 29 21:48:32 2008 From: mr at sun.com (mr at sun.com) Date: Sat, 01 Mar 2008 05:48:32 +0000 Subject: hg: jdk7/hotspot/jdk: 2 new changesets Message-ID: <20080301054906.8E2F626E48@hg.openjdk.java.net> Changeset: 99a06bc7fdb5 Author: xdono Date: 2007-12-04 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/99a06bc7fdb5 Added tag jdk7-b24 for changeset 37a05a11f281 + .hgtags Changeset: 8266cb7549d3 Author: mr Date: 2008-02-29 20:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8266cb7549d3 6669216: Add jcheck configuration directories Reviewed-by: ohair, xdono + .jcheck/conf From mr at sun.com Fri Feb 29 21:50:49 2008 From: mr at sun.com (mr at sun.com) Date: Sat, 01 Mar 2008 05:50:49 +0000 Subject: hg: jdk7/hotspot/langtools: 2 new changesets Message-ID: <20080301055053.7698E26E4F@hg.openjdk.java.net> Changeset: e4dae1993f8b Author: xdono Date: 2007-12-04 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e4dae1993f8b Added tag jdk7-b24 for changeset 9a66ca7c79fa + .hgtags Changeset: e5e9fa6fa29c Author: mr Date: 2008-02-29 20:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e5e9fa6fa29c 6669216: Add jcheck configuration directories Reviewed-by: ohair, xdono + .jcheck/conf From ted at tedneward.com Fri Feb 29 07:08:12 2008 From: ted at tedneward.com (Ted Neward) Date: Fri, 29 Feb 2008 07:08:12 -0800 Subject: Is 'optimized' a legit target? Message-ID: <025e01c87ae4$e99bc090$bcd341b0$@com> Using b24 sources, tried to do a ?make all_product all_fastdebug all_debug all_optimized? and the optimized target failed: make[1]: Entering directory `/cygdrive/c/Prg/OpenJDK/jdk7/hotspot/make' rm -f /cygdrive/c/Prg/OpenJDK/jdk7/hotspot/build/windows/export-windows-i586/opt imized/jre/bin/server/Xusage.txt.temp sed 's/\(separated by \)[;:]/\1;/g' /cygdrive/c/Prg/OpenJDK/jdk7/hotspot/src/sha re/vm/Xusage.txt > /cygdrive/c/Prg/OpenJDK/jdk7/hotspot/build/windows/export-win dows-i586/optimized/jre/bin/server/Xusage.txt.temp mv /cygdrive/c/Prg/OpenJDK/jdk7/hotspot/build/windows/export-windows-i586/optim i zed/jre/bin/server/Xusage.txt.temp /cygdrive/c/Prg/OpenJDK/jdk7/hotspot/build/wi ndows/export-windows-i586/optimized/jre/bin/server/Xusage.txt make[1]: *** No rule to make target `/cygdrive/c/Prg/OpenJDK/jdk7/hotspot/build/ windows/export-windows-i586/optimized/jre/bin/server/jvm.dll', needed by `generi c_export'. Stop. make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/jdk7/hotspot/make' make: *** [export_optimized] Error 2 I?d not heard of ?optimized? before, which was why I was trying to build it?it shows up in ?make help?. Is it a legit target? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.1/1303 - Release Date: 2/28/2008 12:14 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080229/113f5fb6/attachment.html