From david.holmes at oracle.com Sun Mar 1 22:57:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 08:57:13 +1000 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54F0A352.3050809@oracle.com> References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <62229346-9E4F-4F0E-880F-E99ED6A64EFB@oracle.com> <54EED5E5.6040706@oracle.com> <54EF7F75.7030808@oracle.com> <54F0A352.3050809@oracle.com> Message-ID: <54F39949.9090808@oracle.com> On 28/02/2015 3:03 AM, Mikhailo Seledtsov wrote: > I agree with Staffan that the kind of increase in text execution speed > is worth the effort and risk. Just bear in mind that anyone writing tests needs to be more aware of any assumptions that test makes about the global state of the VM, and what affect the test has on the global state of the VM. My concern with getting this up and running is that the test that fails is not the test that should be being run in othervm - and finding the test that is causing the problem is non-obvious. > Also, the reversal of this change is only a single line of code: > test/Makefile > > JTREG_BASIC_OPTIONS += -agentvm > > The rest of the changes will not harm in any way, and will still be > helpful for people or systems that explicitly specify "-agentvm" option > when running the tests. Perhaps, George could first push all the changes > except for the "-agentvm" change; then run the RBT tests as Staffan > recommends; if that is fine and additional issues resolved, include > "JTREG_BASIC_OPTIONS += -agentvm" in a separate changeset. I think the slowdown caused by building the test library makes that infeasible. But there's no need to push anything to run it through RBT is there? Also I am still concerned about some of the othervm changes George made that should not be necessary. The CDS tests for example do all their testing by launching other VMs, so the actual CD test should not need to be othervm itself - and indeed with my testing it did not need to be. Thanks, David > Thank you, > Misha > > On 2/27/2015 1:15 AM, Staffan Larsen wrote: >> You are right that this is a risk we are taking. Tests that leave the >> JVM in an un-clean state should be running in main/othervm mode to >> isolate them. It should be noted that if a test fails, then jtreg will >> /not/ reuse that JVM since it can be an unknown state. Still, I?m >> guessing that we will see some initial problems with tests that need >> to be isolated. It would be good to run through the tests in agent >> mode a fair amount of times on all platforms (say 20? - easy to do >> with Remote Build and Test) before we do this change to shake out any >> obvious problems. I think the increased speed of the tests is still >> worth the effort to clean up and isolate some of the tests. >> >> /Staffan >> >>> On 26 feb 2015, at 21:17, David Holmes wrote: >>> >>> I've been thinking more about this change based on Staffan's >>> clarification of how "othervm" is the current default for testing. I >>> think the move to agentvm is very risky and may result in very >>> unpredictable test results. The problem being that tests no longer >>> start out in a clean VM with a pristine state - this can impact many >>> things that might affect how some of the tests execute. And the >>> problems may vary depending on exactly how the tests are run, the >>> concurrency level and number of agent VMs in use. There may not be >>> any guarantee that the same jtreg command line will result in the >>> same tests being executed in the same sequence on the same agent VMs. >>> >>> It may be that the introduction of "main/othervm" in some tests was >>> already an indication of this problem. But the real problem may be >>> the interaction between tests. >>> >>> David >>> >>> On 26/02/2015 6:14 PM, David Holmes wrote: >>>> Hi Staffan, >>>> >>>> On 26/02/2015 6:00 PM, Staffan Larsen wrote: >>>>>> On 25 feb 2015, at 14:42, George Triantafillou >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Thanks for your review. Comments inline: >>>>>> >>>>>> On 2/24/2015 11:55 PM, David Holmes wrote: >>>>>>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>>>>>> Please review this fix for JDK-8068685: >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>>>>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>>>>>> >>>>>>>> >>>>>>>> "@build com.oracle.java.testlibrary.*" was added to all relevant >>>>>>>> tests, >>>>>>> I thought we had an RFE open against jtreg to avoid the need to do >>>>>>> this, but it seems I was mistaken. :( >>>>>>> >>>>>>> Most of the additions to @build seem okay. A few minor issues: >>>>>>> >>>>>>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>> 10:31:03.991071066 -0800 >>>>>>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>> 10:31:03.617052982 -0800 >>>>>>> @@ -35,6 +35,9 @@ >>>>>>> * @test >>>>>>> * @bug 8059624 8064669 >>>>>>> * @library /testlibrary /../../test/lib >>>>>>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>>>>>> + * @ignore 8066998 >>>>>>> + * @library /testlibrary /../../test/lib >>>>>>> * @build ForceNMethodSweepTest >>>>>>> >>>>>>> The second @library shouldn't have been added. >>>>>> Good catch, thanks. Changed. >>>>>> >>>>>>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>> 10:32:28.209143019 -0800 >>>>>>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>> 10:32:27.855125901 -0800 >>>>>>> @@ -22,11 +22,13 @@ >>>>>>> */ >>>>>>> >>>>>>> /* >>>>>>> - * @test TestStringSymbolTableStats.java >>>>>>> + * @test TestStringSymbolTableStats >>>>>>> >>>>>>> Why did you change the @test? I see a lot of unchanged @test >>>>>>> foo.java. >>>>>> According to the jtreg tag >>>>>> spechttp://openjdk.java.net/jtreg/tag-spec.html, either way is >>>>>> correct. The only tests that were considered for this change >>>>>> included >>>>>> "@library /testlibrary", so I changed this one for consistency with >>>>>> other tests that I've written. I'll change it back if it's a >>>>>> concern. >>>>>>> >>>>>>>> which resulted in longer test execution times. In order to offset >>>>>>>> these >>>>>>>> longer test execution times and to support running jtreg in >>>>>>>> -agentvm >>>>>>>> mode, the following changes were made: >>>>>>>> >>>>>>>> test/Makefile: added -agentvm option >>>>>>> I'm unclear exactly what this buys us - do we just save on the >>>>>>> startup costs of new vms running jtreg? I thought the default was >>>>>>> samevm anyway? >>>>>>> >>>>>>> Also does this mean that all VMs will share a single copy of the >>>>>>> testlibrary or will we still have a copy per test that gets built >>>>>>> each time? >>>>>> The jtreg command >>>>>> helphttp://openjdk.java.net/jtreg/command-help.htmldoc states: >>>>>> >>>>>> -agentvm "Run tests using a pool of reusable JVMs." >>>>>> -samevm "If possible, run each test in the same JVM as the JavaTest" >>>>>> >>>>>> I'm not really sure how samevm decides "if possible", but the intent >>>>>> of this change was to explicitly add "@build >>>>>> com.oracle.java.testlibrary.*" to relevant jtreg runtime tests >>>>>> without >>>>>> increasing test execution times. The analysis below shows decreased >>>>>> test execution times using agentvm. >>>>> Re-reading the documentation, checking the sources and running some >>>>> experiments show that the default mode for jtreg is not samevm, but >>>>> othervm. In othervm mode, jtreg will create a new JVM for each test >>>>> /and/ for each javac invocation. In agentvm mode a pool of JVMs >>>>> will be >>>>> reused for both javac and for the tests. When running in agentmode, >>>>> even >>>>> if a test says ?main/othervm?, the javac invocation of the test will >>>>> happen in the agent. So running in agentvm mode saves time even if all >>>>> tests say ?main/othervm?. >>>> Thanks for clarifying that. It would seem main/othervm is only ever >>>> needed to override -agentvm or -samevm. That makes sense. >>>> >>>> I still wonder how many times the test library gets built per set of >>>> tests ? :) >>>> >>>>> The following passage from the documentation is confusing: >>>>> >>>>> ---- >>>>> Test Mode Options >>>>> >>>>> When the JavaTest harness is used to run tests, two possibly different >>>>> versions of the JDK are used: the JDK version used to run the harness >>>>> and the JDK version used to run the test(s). The following options >>>>> provide a means to specify the JDK version used to run the tests. The >>>>> default is to use the same JDK version (provided by JAVA_HOME) for >>>>> both >>>>> the harness and the tests, and for each test to run in its own JVM. >>>>> ---- >>>>> >>>>> Notice how the last sentence seems to begin by saying samevm mode >>>>> is the >>>>> default, but its really just talking about the version of the JDK used >>>>> to for running the tests. The sentence ends by saying (not very >>>>> explicitly) that othervm is the default mode. I?ll see if we can >>>>> clarify >>>>> that. >>>> It is even more confusing if you take into account that with samevm it >>>> uses the testjdk, but you can also set compilejdk to a different jdk, >>>> which suggests it will run the tests in the same vm as the harness but >>>> launch separate vms to do the compilation. >>>> >>>> Well now I've said that perhaps not so confusing after all :) >>>> >>>> Thanks, >>>> David >>>> >>>>> /Staffan >>>>> >>>>> >>>>>>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: >>>>>>>> added >>>>>>>> -classpath since -agentvm passes the classpath differently than >>>>>>>> -othervm >>>>>>>> >>>>>>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>>>>>> hotspot testset, and a 48% speed improvement for >>>>>>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>>>>>> >>>>>>>> *Note that some tests required the explicit addition of -othervm in >>>>>>>> order for the tests to pass. In addition, a number of gc, compiler >>>>>>>> and >>>>>>>> runtime tests were modified with @run so they would run >>>>>>>> successfully >>>>>>>> with -agentvm. Consequently, reviews from members of the compiler, >>>>>>>> gc, >>>>>>>> runtime, and serviceability teams would be very helpful. >>>>>>> I'm unclear about the need for some of the othervm changes. I would >>>>>>> only expect othervm to be needed if passing -XX options via @run ?? >>>>>> I added @run to some tests, and some of them failed with -agentvm >>>>>> until I added -othervm. >>>>>> >>>>>> -George >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks to Erik Helin for providing a solution for passing classpath >>>>>>>> with >>>>>>>> -agentvm. >>>>>>>> >>>>>>>> The fix was tested locally on Linux with jtreg and on all platforms >>>>>>>> with >>>>>>>> the JPRT hotspot testset.* >>>>>>>> * >>>>>>>> Thanks. >>>>>>>> >>>>>>>> -George > From david.holmes at oracle.com Mon Mar 2 02:08:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 12:08:08 +1000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: <54EBE25E.2080905@oracle.com> References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> <54EBE25E.2080905@oracle.com> Message-ID: <54F3C608.6080405@oracle.com> On 24/02/2015 12:30 PM, David Holmes wrote: > On 24/02/2015 4:45 AM, Karen Kinnear wrote: >> >> On Feb 20, 2015, at 1:24 PM, Erik ?sterlund wrote: >> >> And truly many thanks - in my mind you have made this much more >> conceptually clean and safer. >> I am good with your checking in the parts I have reviewed. > > Thanks Karen! So unless someone has something they really want to be > changed now (and I think everyone has so far said there are no strOng > objections to anything) then I will push this version: > > http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ > > in a couple of days. Updated with compiler version information where known: http://cr.openjdk.java.net/~dholmes/7143664/webrev-v5/ Changeset prepared ready for push - please let me know if I've missed anybody off the reviewer list. I will push this on Wednesday my time (GMT+10) as I won't be in the office Tuesday. Thanks, David ----- From david.holmes at oracle.com Mon Mar 2 08:38:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 18:38:43 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1798541240.20403783.1425063960818.JavaMail.zimbra@redhat.com> References: <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> <54EFD092.5090007@oracle.com> <1798541240.20403783.1425063960818.JavaMail.zimbra@redhat.com> Message-ID: <54F42193.3030700@oracle.com> On 28/02/2015 5:06 AM, Andrew Hughes wrote: > ----- Original Message ----- >> On 27/02/2015 11:25 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> >>>> On 26/02/2015 12:31 PM, David Holmes wrote: >>>>> On 26/02/2015 2:57 AM, Andrew Hughes wrote: >>>>>>>>> These are the revised versions of the webrevs: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ >>>>>>>>> >>>>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK) >>>>>> >>>>>> Ok if I push the jdk and root parts then? I think someone on the Oracle >>>>>> HS team (David?) needs to push the HotSpot bit. >>>>> >>>>> Best to push it all together I think, which I can do through the hs-rt >>>>> forest. But first I need to see where things settled with all this :) I >>>>> was quite confused by some of the initial suggestions. Will try to get >>>>> to this today. >>> >>> Well, I'd push it all myself if there weren't still restrictions on pushing >>> to HotSpot... >>> >>>> >>>> I'm still very confused by these changes and have trouble tracking the >>>> values of the various "arch" related variables. If I follow this right >>>> presently the only distinction between ppc64 and ppc64le is the value of >>>> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the >>>> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 >>>> is either unused or only used by a hotspot-only build?) >>>> >>>> The desired change is that the top-level architecture (VAR_CPU which >>>> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that >>>> for hotspot the only difference is LIBARCH becomes ppc64le. So to >>>> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the >>>> current ppc; and then hotspot's def.make uses that combined with being >>>> lttle-endian to reset the LIBARCH to ppc64le. >>> >>> From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build >>> will get called with ARCH=ppc64le and fail, because make/defs.make will >>> set SRCARCH to x86 >> >> No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from >> $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to >> ppc as per current code. Then BUILDARCH will check LP64 and so become >> ppc64. Then you can check endian-ness to define LIBARCH to ppc64le. >> > > Ah, not in 8 where this was tested: > > ARCH=$(OPENJDK_TARGET_CPU_LEGACY) > +# ppc64le uses the HotSpot ppc64 build > +ifeq ($(OPENJDK_TARGET_CPU), ppc64le) > + ARCH=ppc64 > +endif > > OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this case. > > 9 changed this with: > > 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH > > So it looks like we're going to end up with three different patches for this issue. That explains all the confusion :) >> Yes but you can do it based on the value of LIBARCH rather than a >> modified ARCH. > > Yes, with 8046471 in place. Hardly a huge difference though. Avoiding the need to mess with what happens at the configure level in hoptspot-spec.gmk.in makes it a lot simpler to follow IMHO. >> I don't know if I already had this conversation but it strikes me as >> really bizarre that the PPC64 port uses two different ARCH values >> depending on whether it is a configure-based build or not! ??? >> > > It's not just that port. Every build either gets ARCH set by > hotspot-spec.gmk (by way of configure) or by uname -m in > make/linux/makefiles/defs.make. This is necessary if you're > going to allow someone to skip configure and just build HotSpot. It's not the two different mechanisms that I was referring to, but the fact that those mechanisms result in two completely different values for ARCH for the same port. This just piles complexity on top of complexity. > If no-one does that any more, then the old stuff that was needed > for 7 builds (no configure) could be culled. Eventually the hotspot build will be all configure based. Even now I'm not sure why people need to do a hotspot-only build this way rather than just running configure and "make hotspot-only". >> That aside if ARCH == ppc64 from uname then: >> - SRCARCH = ARCH/ppc64 = ppc >> - BUILDARCH = ppc64 >> >> and so the same fix as above would work for this case. >> > > It doesn't, as I said. It's ppc64le. So the uname override is necessary. > For consistency, it probably should now be overridden to be ppc, not > ppc64, given the value passed in from configure changed to that in > 8046471. Ok. Thanks, David ----- >>> so our addition to hotspot-spec.gmk is just to do the same as this >>> block for configure builds. >>> >>> It was unneeded before because configure would just set the arch >>> to ppc64 for the entire build, not just HotSpot. >> >> AFAICS it set it to ppc not ppc64. > > I was referring to: > > - VAR_CPU=ppc64 > + VAR_CPU=ppc64le > > and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH. > >> >> David >> ----- >> >> >>>> Thanks, >>>> David >>>> >>>> >>>> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why >>>> bother also doing the switcheroo in >>>> /common/autoconf/hotspot-spec.gmk.in when you could just do >>>> everything in hotspot/make/defs >>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>> >>> >> > From staffan.larsen at oracle.com Mon Mar 2 08:43:26 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 2 Mar 2015 09:43:26 +0100 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54F39949.9090808@oracle.com> References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <62229346-9E4F-4F0E-880F-E99ED6A64EFB@oracle.com> <54EED5E5.6040706@oracle.com> <54EF7F75.7030808@oracle.com> <54F0A352.3050809@oracle.com> <54F39949.9090808@oracle.com> Message-ID: > On 1 mar 2015, at 23:57, David Holmes wrote: > > On 28/02/2015 3:03 AM, Mikhailo Seledtsov wrote: >> I agree with Staffan that the kind of increase in text execution speed >> is worth the effort and risk. > > Just bear in mind that anyone writing tests needs to be more aware of any assumptions that test makes about the global state of the VM, and what affect the test has on the global state of the VM. > > My concern with getting this up and running is that the test that fails is not the test that should be being run in othervm - and finding the test that is causing the problem is non-obvious. > >> Also, the reversal of this change is only a single line of code: >> test/Makefile >> >> JTREG_BASIC_OPTIONS += -agentvm >> >> The rest of the changes will not harm in any way, and will still be >> helpful for people or systems that explicitly specify "-agentvm" option >> when running the tests. Perhaps, George could first push all the changes >> except for the "-agentvm" change; then run the RBT tests as Staffan >> recommends; if that is fine and additional issues resolved, include >> "JTREG_BASIC_OPTIONS += -agentvm" in a separate changeset. > > I think the slowdown caused by building the test library makes that infeasible. But there's no need to push anything to run it through RBT is there? That should be fixed by CODETOOLS-7901315, but we have to wait for the next jtreg promotion. > > Also I am still concerned about some of the othervm changes George made that should not be necessary. The CDS tests for example do all their testing by launching other VMs, so the actual CD test should not need to be othervm itself - and indeed with my testing it did not need to be. I share these concerns. We need to understand better why these changes were needed. /Staffan > > Thanks, > David > >> Thank you, >> Misha >> >> On 2/27/2015 1:15 AM, Staffan Larsen wrote: >>> You are right that this is a risk we are taking. Tests that leave the >>> JVM in an un-clean state should be running in main/othervm mode to >>> isolate them. It should be noted that if a test fails, then jtreg will >>> /not/ reuse that JVM since it can be an unknown state. Still, I?m >>> guessing that we will see some initial problems with tests that need >>> to be isolated. It would be good to run through the tests in agent >>> mode a fair amount of times on all platforms (say 20? - easy to do >>> with Remote Build and Test) before we do this change to shake out any >>> obvious problems. I think the increased speed of the tests is still >>> worth the effort to clean up and isolate some of the tests. >>> >>> /Staffan >>> >>>> On 26 feb 2015, at 21:17, David Holmes wrote: >>>> >>>> I've been thinking more about this change based on Staffan's >>>> clarification of how "othervm" is the current default for testing. I >>>> think the move to agentvm is very risky and may result in very >>>> unpredictable test results. The problem being that tests no longer >>>> start out in a clean VM with a pristine state - this can impact many >>>> things that might affect how some of the tests execute. And the >>>> problems may vary depending on exactly how the tests are run, the >>>> concurrency level and number of agent VMs in use. There may not be >>>> any guarantee that the same jtreg command line will result in the >>>> same tests being executed in the same sequence on the same agent VMs. >>>> >>>> It may be that the introduction of "main/othervm" in some tests was >>>> already an indication of this problem. But the real problem may be >>>> the interaction between tests. >>>> >>>> David >>>> >>>> On 26/02/2015 6:14 PM, David Holmes wrote: >>>>> Hi Staffan, >>>>> >>>>> On 26/02/2015 6:00 PM, Staffan Larsen wrote: >>>>>>> On 25 feb 2015, at 14:42, George Triantafillou >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for your review. Comments inline: >>>>>>> >>>>>>> On 2/24/2015 11:55 PM, David Holmes wrote: >>>>>>>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>>>>>>> Please review this fix for JDK-8068685: >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>>>>>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>>>>>>> >>>>>>>>> >>>>>>>>> "@build com.oracle.java.testlibrary.*" was added to all relevant >>>>>>>>> tests, >>>>>>>> I thought we had an RFE open against jtreg to avoid the need to do >>>>>>>> this, but it seems I was mistaken. :( >>>>>>>> >>>>>>>> Most of the additions to @build seem okay. A few minor issues: >>>>>>>> >>>>>>>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>>> 10:31:03.991071066 -0800 >>>>>>>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>>> 10:31:03.617052982 -0800 >>>>>>>> @@ -35,6 +35,9 @@ >>>>>>>> * @test >>>>>>>> * @bug 8059624 8064669 >>>>>>>> * @library /testlibrary /../../test/lib >>>>>>>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>>>>>>> + * @ignore 8066998 >>>>>>>> + * @library /testlibrary /../../test/lib >>>>>>>> * @build ForceNMethodSweepTest >>>>>>>> >>>>>>>> The second @library shouldn't have been added. >>>>>>> Good catch, thanks. Changed. >>>>>>> >>>>>>>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>>> 10:32:28.209143019 -0800 >>>>>>>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>>> 10:32:27.855125901 -0800 >>>>>>>> @@ -22,11 +22,13 @@ >>>>>>>> */ >>>>>>>> >>>>>>>> /* >>>>>>>> - * @test TestStringSymbolTableStats.java >>>>>>>> + * @test TestStringSymbolTableStats >>>>>>>> >>>>>>>> Why did you change the @test? I see a lot of unchanged @test >>>>>>>> foo.java. >>>>>>> According to the jtreg tag >>>>>>> spechttp://openjdk.java.net/jtreg/tag-spec.html, either way is >>>>>>> correct. The only tests that were considered for this change >>>>>>> included >>>>>>> "@library /testlibrary", so I changed this one for consistency with >>>>>>> other tests that I've written. I'll change it back if it's a >>>>>>> concern. >>>>>>>> >>>>>>>>> which resulted in longer test execution times. In order to offset >>>>>>>>> these >>>>>>>>> longer test execution times and to support running jtreg in >>>>>>>>> -agentvm >>>>>>>>> mode, the following changes were made: >>>>>>>>> >>>>>>>>> test/Makefile: added -agentvm option >>>>>>>> I'm unclear exactly what this buys us - do we just save on the >>>>>>>> startup costs of new vms running jtreg? I thought the default was >>>>>>>> samevm anyway? >>>>>>>> >>>>>>>> Also does this mean that all VMs will share a single copy of the >>>>>>>> testlibrary or will we still have a copy per test that gets built >>>>>>>> each time? >>>>>>> The jtreg command >>>>>>> helphttp://openjdk.java.net/jtreg/command-help.htmldoc states: >>>>>>> >>>>>>> -agentvm "Run tests using a pool of reusable JVMs." >>>>>>> -samevm "If possible, run each test in the same JVM as the JavaTest" >>>>>>> >>>>>>> I'm not really sure how samevm decides "if possible", but the intent >>>>>>> of this change was to explicitly add "@build >>>>>>> com.oracle.java.testlibrary.*" to relevant jtreg runtime tests >>>>>>> without >>>>>>> increasing test execution times. The analysis below shows decreased >>>>>>> test execution times using agentvm. >>>>>> Re-reading the documentation, checking the sources and running some >>>>>> experiments show that the default mode for jtreg is not samevm, but >>>>>> othervm. In othervm mode, jtreg will create a new JVM for each test >>>>>> /and/ for each javac invocation. In agentvm mode a pool of JVMs >>>>>> will be >>>>>> reused for both javac and for the tests. When running in agentmode, >>>>>> even >>>>>> if a test says ?main/othervm?, the javac invocation of the test will >>>>>> happen in the agent. So running in agentvm mode saves time even if all >>>>>> tests say ?main/othervm?. >>>>> Thanks for clarifying that. It would seem main/othervm is only ever >>>>> needed to override -agentvm or -samevm. That makes sense. >>>>> >>>>> I still wonder how many times the test library gets built per set of >>>>> tests ? :) >>>>> >>>>>> The following passage from the documentation is confusing: >>>>>> >>>>>> ---- >>>>>> Test Mode Options >>>>>> >>>>>> When the JavaTest harness is used to run tests, two possibly different >>>>>> versions of the JDK are used: the JDK version used to run the harness >>>>>> and the JDK version used to run the test(s). The following options >>>>>> provide a means to specify the JDK version used to run the tests. The >>>>>> default is to use the same JDK version (provided by JAVA_HOME) for >>>>>> both >>>>>> the harness and the tests, and for each test to run in its own JVM. >>>>>> ---- >>>>>> >>>>>> Notice how the last sentence seems to begin by saying samevm mode >>>>>> is the >>>>>> default, but its really just talking about the version of the JDK used >>>>>> to for running the tests. The sentence ends by saying (not very >>>>>> explicitly) that othervm is the default mode. I?ll see if we can >>>>>> clarify >>>>>> that. >>>>> It is even more confusing if you take into account that with samevm it >>>>> uses the testjdk, but you can also set compilejdk to a different jdk, >>>>> which suggests it will run the tests in the same vm as the harness but >>>>> launch separate vms to do the compilation. >>>>> >>>>> Well now I've said that perhaps not so confusing after all :) >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: >>>>>>>>> added >>>>>>>>> -classpath since -agentvm passes the classpath differently than >>>>>>>>> -othervm >>>>>>>>> >>>>>>>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>>>>>>> hotspot testset, and a 48% speed improvement for >>>>>>>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>>>>>>> >>>>>>>>> *Note that some tests required the explicit addition of -othervm in >>>>>>>>> order for the tests to pass. In addition, a number of gc, compiler >>>>>>>>> and >>>>>>>>> runtime tests were modified with @run so they would run >>>>>>>>> successfully >>>>>>>>> with -agentvm. Consequently, reviews from members of the compiler, >>>>>>>>> gc, >>>>>>>>> runtime, and serviceability teams would be very helpful. >>>>>>>> I'm unclear about the need for some of the othervm changes. I would >>>>>>>> only expect othervm to be needed if passing -XX options via @run ?? >>>>>>> I added @run to some tests, and some of them failed with -agentvm >>>>>>> until I added -othervm. >>>>>>> >>>>>>> -George >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks to Erik Helin for providing a solution for passing classpath >>>>>>>>> with >>>>>>>>> -agentvm. >>>>>>>>> >>>>>>>>> The fix was tested locally on Linux with jtreg and on all platforms >>>>>>>>> with >>>>>>>>> the JPRT hotspot testset.* >>>>>>>>> * >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> -George >> From paul.sandoz at oracle.com Mon Mar 2 10:04:44 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Mar 2015 11:04:44 +0100 Subject: Unasafe.putOdered -> Unsafe.releasePut Message-ID: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> Hi, In light of the changes to clean up OrderAccess implementations [1] what to people think about: 1) deprecating the putOrdered* methods and renaming to release*Put? 2) adding a get*Acquire*. Initial implementations could defer to the relaxed operation followed by a load fence, but we should re-implement natively as a bound variant since the initial implementation is likely to be more conservative. I want to add such methods for VarHandle support. 3) perhaps deprecating/renaming the Unsafe fences to align with the fence/release/acquire naming. ? At one level most of this is kind of cosmetic but given this area is very confusing using consistent naming seems worthwhile. Paul. [1] http://cr.openjdk.java.net/~dholmes/7143664/webrev-v5/src/share/vm/runtime/orderAccess.hpp.sdiff.html From stefan.johansson at oracle.com Mon Mar 2 10:14:35 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 02 Mar 2015 11:14:35 +0100 Subject: RFR [8u60]: 8073944: Simplify ArgumentsExt and remove unneeded functionallity In-Reply-To: References: <54EEFFD2.6040806@oracle.com> Message-ID: <54F4380B.7020703@oracle.com> Thanks for the review Kim, Stefan On 2015-02-26 22:00, Kim Barrett wrote: > On Feb 26, 2015, at 6:13 AM, Stefan Johansson wrote: >> Hi, >> >> Please review this small changes for: >> https://bugs.openjdk.java.net/browse/JDK-8073944 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8073944/hotspot.00/ >> >> Summary: >> The removed functionality was added as part of JDK-8057623, but is no longer needed. >> >> Thanks, >> Stefan > Looks good. > From stefan.johansson at oracle.com Mon Mar 2 10:17:52 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 02 Mar 2015 11:17:52 +0100 Subject: RFR [8u60]: 8073944: Simplify ArgumentsExt and remove unneeded functionallity In-Reply-To: <54EFB739.1030702@oracle.com> References: <54EEFFD2.6040806@oracle.com> <54EFB739.1030702@oracle.com> Message-ID: <54F438D0.3070209@oracle.com> Thanks for the review David, On 2015-02-27 01:15, David Holmes wrote: > On 26/02/2015 9:13 PM, Stefan Johansson wrote: >> Hi, >> >> Please review this small changes for: >> https://bugs.openjdk.java.net/browse/JDK-8073944 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8073944/hotspot.00/ >> >> Summary: >> The removed functionality was added as part of JDK-8057623, but is no >> longer needed. > > Given it hasn't been in long, removing it should not be an issue - > particularly for 8u - but it suggests we need to give more thought to > the form of these extension points when we add them. > I agree, that we should have good reasons for adding these hooks and that we should add them in way that they allow further extensions. I this case we had a requirement for 8u40 that has been changed to 8u60. Thanks, Stefan > Reviewed. > > Thanks, > David > > >> Thanks, >> Stefan From david.holmes at oracle.com Mon Mar 2 11:07:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 21:07:48 +1000 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> Message-ID: <54F44484.3030403@oracle.com> Hi Paul, This is more a question for core-libs and the users of this Unsafe API. Sometimes the implementation of unsafe doesn't exactly match the API, so we need to check what the intended API semantics are. David On 2/03/2015 8:04 PM, Paul Sandoz wrote: > Hi, > > In light of the changes to clean up OrderAccess implementations [1] what to people think about: > > 1) deprecating the putOrdered* methods and renaming to release*Put? > > 2) adding a get*Acquire*. Initial implementations could defer to the relaxed operation followed by a load fence, but we should re-implement natively as a bound variant since the initial implementation is likely to be more conservative. I want to add such methods for VarHandle support. > > 3) perhaps deprecating/renaming the Unsafe fences to align with the fence/release/acquire naming. > > ? > > At one level most of this is kind of cosmetic but given this area is very confusing using consistent naming seems worthwhile. > > Paul. > > [1] http://cr.openjdk.java.net/~dholmes/7143664/webrev-v5/src/share/vm/runtime/orderAccess.hpp.sdiff.html > From paul.sandoz at oracle.com Mon Mar 2 11:54:57 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Mar 2015 12:54:57 +0100 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <54F44484.3030403@oracle.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> <54F44484.3030403@oracle.com> Message-ID: <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> On Mar 2, 2015, at 12:07 PM, David Holmes wrote: > Hi Paul, > > This is more a question for core-libs and the users of this Unsafe API. I wanted to check here first because of work done in [1] and because this is where there is most experience with the Unsafe implementation. I don't want to change the semantics of existing Unsafe methods. Note that the VarHandle work will expose using release/acquire names, where the former implementation defers to Unsafe.putOrdered*, and the later to relaxed plus explicit load fence. > Sometimes the implementation of unsafe doesn't exactly match the API, so we need to check what the intended API semantics are. > I believe things align naming-wise at least from eyeballing C2 code i.e. Unsafe.putOrdered* is a form of release-store like that of OrderAccess::release_store and Unsafe.storeFence is a form of release-fence like that of OrderAccess::release. src/share/vm/opto/library_call.cpp: bool LibraryCallKit::inline_unsafe_ordered_store(BasicType type) { ... insert_mem_bar(Op_MemBarRelease); insert_mem_bar(Op_MemBarCPUOrder); // Ensure that the store is atomic for longs: const bool require_atomic_access = true; Node* store; if (type == T_OBJECT) // reference stores need a store barrier. store = store_oop_to_unknown(control(), base, adr, adr_type, val, type, MemNode::release); else { store = store_to_memory(control(), adr, val, type, adr_type, MemNode::release, require_atomic_access); } insert_mem_bar(Op_MemBarCPUOrder); return true; } bool LibraryCallKit::inline_unsafe_fence(vmIntrinsics::ID id) { // Regardless of form, don't allow previous ld/st to move down, // then issue acquire, release, or volatile mem_bar. insert_mem_bar(Op_MemBarCPUOrder); switch(id) { case vmIntrinsics::_loadFence: insert_mem_bar(Op_LoadFence); return true; case vmIntrinsics::_storeFence: insert_mem_bar(Op_StoreFence); return true; case vmIntrinsics::_fullFence: insert_mem_bar(Op_MemBarVolatile); return true; default: fatal_unexpected_iid(id); return false; } } src/cpu/x86/vm/x86_32.ad: instruct membar_release() %{ match(MemBarRelease); match(StoreFence); ins_cost(400); size(0); format %{ "MEMBAR-release ! (empty encoding)" %} ins_encode( ); ins_pipe(empty); %} ... instruct membar_acquire() %{ match(MemBarAcquire); match(LoadFence); ins_cost(400); size(0); format %{ "MEMBAR-acquire ! (empty encoding)" %} ins_encode(); ins_pipe(empty); %} ... instruct membar_volatile(eFlagsReg cr) %{ match(MemBarVolatile); effect(KILL cr); ins_cost(400); format %{ $$template if (os::is_MP()) { $$emit$$"LOCK ADDL [ESP + #0], 0\t! membar_volatile" } else { $$emit$$"MEMBAR-volatile ! (empty encoding)" } %} ins_encode %{ __ membar(Assembler::StoreLoad); %} ins_pipe(pipe_slow); %} Paul. From goetz.lindenmaier at sap.com Mon Mar 2 12:43:08 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 2 Mar 2015 12:43:08 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> Hi Kim, I agree not to fix this. I uploaded a new webrev that fixes the remaining issues: http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.04/ I changed the makefile to only set the flag in gcc 4.8, changed get_core_path to return -1 and removed the assertions, and fixed the bracket in graphKit. Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Freitag, 27. Februar 2015 21:34 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Feb 27, 2015, at 6:59 AM, Lindenmaier, Goetz wrote: > > I started to fix the issues you noted, but I'm not sure about this one: >> - Result of final jio_snprintf is not checked. That was one of the issues I recommended not be fixed as part of this changeset, in part to avoid questions like this. > I think it's on purpose that the result is not checked. In case of an error > of the VM, one wants to see as much information as possible. The result > of get_core_path is only used for printing, and printing a truncated path > still might help to find the core. > That's also the reason to return strlen and not the result of jio_snprintf. > > Note that jio_snprintf always terminates strings and returns -1 on error. jio_snprintf also returns -1 for things other than for truncation. So I disagree with that rationale for not checking the final jio_snprintf result. But as I said, I would prefer to not delay / derail this change set with this largely unrelated discussion. From coleen.phillimore at oracle.com Mon Mar 2 15:01:45 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 02 Mar 2015 10:01:45 -0500 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F0FA11.3030903@oracle.com> References: <54F0AB0B.5090904@oracle.com> <54F0B9EF.4090800@oracle.com> <54F0CE60.9070505@oracle.com> <54F0FA11.3030903@oracle.com> Message-ID: <54F47B59.1030300@oracle.com> Hi Dean, I'm not sure how to do this diff that you're suggesting. I don't think an intermediate changeset makes sense either. The bytecodes are pretty well tested with our normal testing so increasing this to more than one change, just increases testing and putback overhead. I've looked at this several times and it's not very difficult to tell what's done and whether it's correct. The diffs do not span a lot of code (at most 5 lines at a time), so there are no new whole functions to read that are new code. I'm still really don't understand what kind of diff you're requesting that would make it easier. Can you provide an example? thanks, Coleen On 2/27/15, 6:13 PM, Dean Long wrote: > Hi Coleen. I believe I understand what Max did, and that it was not > an automated merge, > which to me says that properly reviewing the change requires looking > at all 2851 > changed lines and mentally deciding if the result is equivalent to the > original. > > What I was suggesting was essentially two things. First, an aid to > the reviewer, > and second, a way to reduce risk. In the end it's up to the > reviewers. If they > prefer to see the changes in a single diff, they can compare a > single-file > automated merge with the single-file result of Max's merge. It > doesn't matter > if the reviewer does it or Max does it as a convenience. Regarding risk, > if the reviewers aren't comfortable deciding that all 2851 are correct, > the changes could be staged into several pieces, and the first piece > could > be an automated merge that would be cleaned up later, on the assumption > that an automated merge could be considered trivially correct and > therefore > not risky. I hope that clears up my somewhat terse comments below. > > dl > > On 2/27/2015 12:06 PM, Coleen Phillimore wrote: >> >> Dean, This merge wasn't automatic in any way, so I don't think what >> you're proposing makes sense. I think if you look at the webrev >> you'll see what Max has done. >> Thanks, >> Coleen >> >> On 2/27/15, 1:39 PM, Dean Long wrote: >>> Hi Max. You could do an automatic merge using something like "diff >>> -w -D LP64 templateTable_x86_32.cpp and templateTable_x86_64.cpp", >>> then compare >>> your improvements to that. That way all the changes would show up in >>> a single diff. Or you could even check in the automatic merge >>> first, to reduce >>> risk, then break up the improvements into smaller pieces. >>> >>> dl >>> >>> On 2/27/2015 9:36 AM, Max Ockner wrote: >>>> Hello all, >>>> Please review this change which involves merging 32 and 64 bit >>>> interpreter files. >>>> >>>> Bug ID: 8013393 >>>> Webrev: cr.openjdk.java.net/~coleenp/8013393 >>>> >>>> Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp have >>>> been merged into one file*. These files originally shared thousands >>>> of lines of duplicate code. >>>> There were also many nearly identical sections of code which >>>> differed only in register usage (example: rsi vs. r13) or in the >>>> usage of nearly identical functions (example: movptr vs. movq/movl). >>>> Given that (1) new bytecodes could be added soon, and (2) these >>>> files have been tormenting Coleen for years, this change seems >>>> overdue. >>>> >>>> *There are currently two files. The updated templateTable_x86.cpp >>>> is copied into both templateTable_x86_32.cpp and >>>> templateTable_x86_64.cpp to make it easier to review (so the diff >>>> is not the entire file). This will be changed back to one file >>>> after review. >>>> >>>> For functions that could be merged, one copy was kept. In some >>>> cases, files were merged by factoring out small differences such as >>>> register usage (example: rbcp equals r13 or rsi depending on the >>>> platform). For functions that could not be merged, the 32 and 64 >>>> bit versions are adjacent and are defined conditionally using >>>> #ifdef based on the platform. >>>> >>>> There are still improvements to be made, but they are small and can >>>> be filed seperately. >>>> >>>> Tested with: >>>> JPRT >>>> UTE nsk.jvmti.testlist >>>> >>>> >>>> Thanks, >>>> Max Ockner >>> >> > From adinn at redhat.com Mon Mar 2 16:04:17 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 02 Mar 2015 16:04:17 +0000 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F0B061.6080802@oracle.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> <54F0A270.8080708@oracle.com> <54F0A517.9030101@redhat.com> <54F0B061.6080802@oracle.com> Message-ID: <54F48A01.1070300@redhat.com> Hi Vladimir, On 27/02/15 17:58, Vladimir Kozlov wrote: > Okay, I am making executive :) decision to merge on Monday (unless > someone strongly objects until then). > > Note, I am pushing to jdk9/dev and it will take time before the code > will propagate to Hotspot groups repos (could be next Friday or even > later). We need the code to be in those repos to push any changes for > Hotspot. I now seem to have a working AArch64 tree. It has passed the usual smoke tests (run Hello, compile Hello, run netbeans). The changesets required are attached in two distinct versions: a single patch (all.patch) which appears to fix all outstandign disparities between AArch64 and shared code a sequence of 6 patches ({7887-7892}.patch), equivalent in effect to the above patch -- n.b. that's one patch for each of the original issues whose shared changes required corresponding changes in the src/cpu/aarch64 tree (issues 8059606, 8069230, 8068976, 8068977, 8072911 and 8071805) I assume that you will want to apply all.patch -- so long as it passes review. I have posted the 6 separate patches so as to make it easier for other aarch64-port contributors wishing to review this patch to verify that they are correct or, if not, identify the root of any problems they may find. regards, Andrew Dinn ----------- -------------- next part -------------- A non-text attachment was scrubbed... Name: 7887.patch Type: text/x-patch Size: 9207 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7888.patch Type: text/x-patch Size: 989 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7889.patch Type: text/x-patch Size: 2894 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7890.patch Type: text/x-patch Size: 3585 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7891.patch Type: text/x-patch Size: 1807 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7892.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: all.patch Type: text/x-patch Size: 17706 bytes Desc: not available URL: From coleen.phillimore at oracle.com Mon Mar 2 16:53:43 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 02 Mar 2015 11:53:43 -0500 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F0AB0B.5090904@oracle.com> References: <54F0AB0B.5090904@oracle.com> Message-ID: <54F49597.7080606@oracle.com> Hi Max, This was a lot of work! Thank you for this technical debt relief! I've reviewed this code and made several cosmetic issues already and I don't have any more that matter to me. The only thing I wanted people's opinions on was the global register declarations in the beginning of the templateTable*cpp files. I don't really have a good/easy alternate solution. I tried changing them to __ bcp_register() (as declared in interp_masm_x86_32/64.hpp) but that looks really ugly and the static inline function like iaddress() would have to be added to templateTable.hpp. I think if someone has a better idea, you could file an RFE and fix it in an update to this change. The code looks great. This came out well. Thanks! Coleen On 2/27/15, 12:36 PM, Max Ockner wrote: > Hello all, > Please review this change which involves merging 32 and 64 bit > interpreter files. > > Bug ID: 8013393 > Webrev: cr.openjdk.java.net/~coleenp/8013393 > > Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp have > been merged into one file*. These files originally shared thousands of > lines of duplicate code. > There were also many nearly identical sections of code which differed > only in register usage (example: rsi vs. r13) or in the usage of > nearly identical functions (example: movptr vs. movq/movl). > Given that (1) new bytecodes could be added soon, and (2) these files > have been tormenting Coleen for years, this change seems overdue. > > *There are currently two files. The updated templateTable_x86.cpp is > copied into both templateTable_x86_32.cpp and templateTable_x86_64.cpp > to make it easier to review (so the diff is not the entire file). This > will be changed back to one file after review. > > For functions that could be merged, one copy was kept. In some cases, > files were merged by factoring out small differences such as register > usage (example: rbcp equals r13 or rsi depending on the platform). For > functions that could not be merged, the 32 and 64 bit versions are > adjacent and are defined conditionally using #ifdef based on the > platform. > > There are still improvements to be made, but they are small and can be > filed seperately. > > Tested with: > JPRT > UTE nsk.jvmti.testlist > > > Thanks, > Max Ockner From aph at redhat.com Mon Mar 2 17:08:37 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 02 Mar 2015 17:08:37 +0000 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F48A01.1070300@redhat.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> <54F0A270.8080708@oracle.com> <54F0A517.9030101@redhat.com> <54F0B061.6080802@oracle.com> <54F48A01.1070300@redhat.com> Message-ID: <54F49915.8050901@redhat.com> Hi, tried to call you. Can we have a webrev for this? Ta, Andrew. From vladimir.kozlov at oracle.com Mon Mar 2 17:13:24 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Mar 2015 09:13:24 -0800 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F49915.8050901@redhat.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> <54F0A270.8080708@oracle.com> <54F0A517.9030101@redhat.com> <54F0B061.6080802@oracle.com> <54F48A01.1070300@redhat.com> <54F49915.8050901@redhat.com> Message-ID: <54F49A34.8040808@oracle.com> Yes, I will prepare webrevs and do review and push the fix when I am in office today. I will do one all.patch as Andrew Dinn suggested. Regards, Vladimir On 3/2/15 9:08 AM, Andrew Haley wrote: > Hi, tried to call you. > > Can we have a webrev for this? > > Ta, > Andrew. > From adinn at redhat.com Mon Mar 2 17:52:58 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 02 Mar 2015 17:52:58 +0000 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F49915.8050901@redhat.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> <54F0A270.8080708@oracle.com> <54F0A517.9030101@redhat.com> <54F0B061.6080802@oracle.com> <54F48A01.1070300@redhat.com> <54F49915.8050901@redhat.com> Message-ID: <54F4A37A.9070209@redhat.com> On 02/03/15 17:08, Andrew Haley wrote: > Hi, tried to call you. > > Can we have a webrev for this? http://cr.openjdk.java.net/~adinn/8074119/webrev.00 regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From aph at redhat.com Mon Mar 2 17:58:40 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 02 Mar 2015 17:58:40 +0000 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F4A37A.9070209@redhat.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> <54F0A270.8080708@oracle.com> <54F0A517.9030101@redhat.com> <54F0B061.6080802@oracle.com> <54F48A01.1070300@redhat.com> <54F49915.8050901@redhat.com> <54F4A37A.9070209@redhat.com> Message-ID: <54F4A4D0.2080704@redhat.com> On 03/02/2015 05:52 PM, Andrew Dinn wrote: > On 02/03/15 17:08, Andrew Haley wrote: > >> Can we have a webrev for this? > > > http://cr.openjdk.java.net/~adinn/8074119/webrev.00 Thanks, that all looks reasonable. Andrew. From vladimir.kozlov at oracle.com Mon Mar 2 18:11:05 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Mar 2015 10:11:05 -0800 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F4A4D0.2080704@redhat.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> <54F0A270.8080708@oracle.com> <54F0A517.9030101@redhat.com> <54F0B061.6080802@oracle.com> <54F48A01.1070300@redhat.com> <54F49915.8050901@redhat.com> <54F4A37A.9070209@redhat.com> <54F4A4D0.2080704@redhat.com> Message-ID: <54F4A7B9.9010700@oracle.com> Looks good to me too. I will push it now to stage repo first. Thanks, Vladimir On 3/2/15 9:58 AM, Andrew Haley wrote: > On 03/02/2015 05:52 PM, Andrew Dinn wrote: >> On 02/03/15 17:08, Andrew Haley wrote: >> >>> Can we have a webrev for this? >> >> >> http://cr.openjdk.java.net/~adinn/8074119/webrev.00 > > Thanks, that all looks reasonable. > > Andrew. > > From dean.long at oracle.com Mon Mar 2 18:37:50 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Mar 2015 10:37:50 -0800 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F47B59.1030300@oracle.com> References: <54F0AB0B.5090904@oracle.com> <54F0B9EF.4090800@oracle.com> <54F0CE60.9070505@oracle.com> <54F0FA11.3030903@oracle.com> <54F47B59.1030300@oracle.com> Message-ID: <54F4ADFE.3060805@oracle.com> Hi Coleen. Let's say the _32 file contains 32 x y z int and the _64 file contains 64 x y z long Then "diff -DLP64 _32 _64" will give: #ifndef LP64 32 #else /* LP64 */ 64 #endif /* LP64 */ x y z #ifndef LP64 int #else /* LP64 */ long #endif /* LP64 */ In other words, an automatic merge of the two files, with the differences in #ifdefs. thanks, dl On 3/2/2015 7:01 AM, Coleen Phillimore wrote: > > Hi Dean, > I'm not sure how to do this diff that you're suggesting. I don't > think an intermediate changeset makes sense either. The bytecodes are > pretty well tested with our normal testing so increasing this to more > than one change, just increases testing and putback overhead. > > I've looked at this several times and it's not very difficult to tell > what's done and whether it's correct. The diffs do not span a lot of > code (at most 5 lines at a time), so there are no new whole functions > to read that are new code. > > I'm still really don't understand what kind of diff you're requesting > that would make it easier. Can you provide an example? > > thanks, > Coleen > > On 2/27/15, 6:13 PM, Dean Long wrote: >> Hi Coleen. I believe I understand what Max did, and that it was not >> an automated merge, >> which to me says that properly reviewing the change requires looking >> at all 2851 >> changed lines and mentally deciding if the result is equivalent to >> the original. >> >> What I was suggesting was essentially two things. First, an aid to >> the reviewer, >> and second, a way to reduce risk. In the end it's up to the >> reviewers. If they >> prefer to see the changes in a single diff, they can compare a >> single-file >> automated merge with the single-file result of Max's merge. It >> doesn't matter >> if the reviewer does it or Max does it as a convenience. Regarding risk, >> if the reviewers aren't comfortable deciding that all 2851 are correct, >> the changes could be staged into several pieces, and the first piece >> could >> be an automated merge that would be cleaned up later, on the assumption >> that an automated merge could be considered trivially correct and >> therefore >> not risky. I hope that clears up my somewhat terse comments below. >> >> dl >> >> On 2/27/2015 12:06 PM, Coleen Phillimore wrote: >>> >>> Dean, This merge wasn't automatic in any way, so I don't think what >>> you're proposing makes sense. I think if you look at the webrev >>> you'll see what Max has done. >>> Thanks, >>> Coleen >>> >>> On 2/27/15, 1:39 PM, Dean Long wrote: >>>> Hi Max. You could do an automatic merge using something like "diff >>>> -w -D LP64 templateTable_x86_32.cpp and templateTable_x86_64.cpp", >>>> then compare >>>> your improvements to that. That way all the changes would show up in >>>> a single diff. Or you could even check in the automatic merge >>>> first, to reduce >>>> risk, then break up the improvements into smaller pieces. >>>> >>>> dl >>>> >>>> On 2/27/2015 9:36 AM, Max Ockner wrote: >>>>> Hello all, >>>>> Please review this change which involves merging 32 and 64 bit >>>>> interpreter files. >>>>> >>>>> Bug ID: 8013393 >>>>> Webrev: cr.openjdk.java.net/~coleenp/8013393 >>>>> >>>>> Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp >>>>> have been merged into one file*. These files originally shared >>>>> thousands of lines of duplicate code. >>>>> There were also many nearly identical sections of code which >>>>> differed only in register usage (example: rsi vs. r13) or in the >>>>> usage of nearly identical functions (example: movptr vs. movq/movl). >>>>> Given that (1) new bytecodes could be added soon, and (2) these >>>>> files have been tormenting Coleen for years, this change seems >>>>> overdue. >>>>> >>>>> *There are currently two files. The updated templateTable_x86.cpp >>>>> is copied into both templateTable_x86_32.cpp and >>>>> templateTable_x86_64.cpp to make it easier to review (so the diff >>>>> is not the entire file). This will be changed back to one file >>>>> after review. >>>>> >>>>> For functions that could be merged, one copy was kept. In some >>>>> cases, files were merged by factoring out small differences such >>>>> as register usage (example: rbcp equals r13 or rsi depending on >>>>> the platform). For functions that could not be merged, the 32 and >>>>> 64 bit versions are adjacent and are defined conditionally using >>>>> #ifdef based on the platform. >>>>> >>>>> There are still improvements to be made, but they are small and >>>>> can be filed seperately. >>>>> >>>>> Tested with: >>>>> JPRT >>>>> UTE nsk.jvmti.testlist >>>>> >>>>> >>>>> Thanks, >>>>> Max Ockner >>>> >>> >> > From christian.thalinger at oracle.com Mon Mar 2 19:46:34 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 2 Mar 2015 11:46:34 -0800 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F0AB0B.5090904@oracle.com> References: <54F0AB0B.5090904@oracle.com> Message-ID: That?s quite a large change (I wish we had Crucible or something to leave inline comments). First, you have to keep the oldest copyright year (but maybe that?s just the diff). + #ifdef _LP64 + void TemplateTable::lconst(int value) { I?d prefer to have #ifdef?s inside methods and not around them. There are a bunch; please change all of them. + #ifdef _LP64 + __ movzbl(rdx, Address(rax, rbx, Address::times_1, tags_offset)); + #else __ xorptr(rdx, rdx); __ movb(rdx, Address(rax, rbx, Address::times_1, tags_offset)); + #endif There is no movzbl on 32-bit? void TemplateTable::iaload() { transition(itos, itos); + // eax: index // rdx: array ! index_check(rdx, rax); // kills rbx, That comment should say rax (or maybe the comments should say ax, but that?s for another day). + __ load_signed_byte(rax, + Address(rdx, rax, + Address::times_1, ! arrayOopDesc::base_offset_in_bytes(T_BYTE))); That indent is annoying. Make it one line like before. - assert(Bytecodes::java_code(Bytecodes::_fast_iaccess_0) == Bytecodes::_aload_0, "fix bytecode definition"); + Bytecodes::_aload_0, + "fix bytecode definition?); These as well. ! __ stop("fast_invokevfinal not used on x86"); ! __ stop("fast_invokevfinal not used on amd64?); This is wrong. It should say x86. ! __ restore_bcp(); // rsi must be correct for exception handler (was destroyed) ! __ restore_bcp(); // r13 must be correct for exception handler (was destroyed) What are we doing with these? All in all this is a good change. Very much appreciated. Hopefully our testing will show if we made a mistake. > On Feb 27, 2015, at 9:36 AM, Max Ockner wrote: > > Hello all, > Please review this change which involves merging 32 and 64 bit interpreter files. > > Bug ID: 8013393 > Webrev: cr.openjdk.java.net/~coleenp/8013393 > > Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp have been merged into one file*. These files originally shared thousands of lines of duplicate code. > There were also many nearly identical sections of code which differed only in register usage (example: rsi vs. r13) or in the usage of nearly identical functions (example: movptr vs. movq/movl). > Given that (1) new bytecodes could be added soon, and (2) these files have been tormenting Coleen for years, this change seems overdue. > > *There are currently two files. The updated templateTable_x86.cpp is copied into both templateTable_x86_32.cpp and templateTable_x86_64.cpp to make it easier to review (so the diff is not the entire file). This will be changed back to one file after review. > > For functions that could be merged, one copy was kept. In some cases, files were merged by factoring out small differences such as register usage (example: rbcp equals r13 or rsi depending on the platform). For functions that could not be merged, the 32 and 64 bit versions are adjacent and are defined conditionally using #ifdef based on the platform. > > There are still improvements to be made, but they are small and can be filed seperately. > > Tested with: > JPRT > UTE nsk.jvmti.testlist > > > Thanks, > Max Ockner From coleen.phillimore at oracle.com Mon Mar 2 20:30:32 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 02 Mar 2015 15:30:32 -0500 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F4ADFE.3060805@oracle.com> References: <54F0AB0B.5090904@oracle.com> <54F0B9EF.4090800@oracle.com> <54F0CE60.9070505@oracle.com> <54F0FA11.3030903@oracle.com> <54F47B59.1030300@oracle.com> <54F4ADFE.3060805@oracle.com> Message-ID: <54F4C868.7030009@oracle.com> Cool option to diff. I didn't know that existed. In this case, it would yield a file that would be mostly impossible to review. Max's change goes a lot further in merging these files, and would be unfortunate to go backwards. This diff would leave a mess in the file with a lot of #ifdefs that were easily resolved with register names that I wouldn't want to look at. Coleen On 3/2/15, 1:37 PM, Dean Long wrote: > Hi Coleen. Let's say the _32 file contains > > 32 > x > y > z > int > > and the _64 file contains > > 64 > x > y > z > long > > Then "diff -DLP64 _32 _64" will give: > > #ifndef LP64 > 32 > #else /* LP64 */ > 64 > #endif /* LP64 */ > x > y > z > #ifndef LP64 > int > #else /* LP64 */ > long > #endif /* LP64 */ > > In other words, an automatic merge of the two files, with the > differences in #ifdefs. > > thanks, > > dl > > On 3/2/2015 7:01 AM, Coleen Phillimore wrote: >> >> Hi Dean, >> I'm not sure how to do this diff that you're suggesting. I don't >> think an intermediate changeset makes sense either. The bytecodes are >> pretty well tested with our normal testing so increasing this to more >> than one change, just increases testing and putback overhead. >> >> I've looked at this several times and it's not very difficult to tell >> what's done and whether it's correct. The diffs do not span a lot of >> code (at most 5 lines at a time), so there are no new whole functions >> to read that are new code. >> >> I'm still really don't understand what kind of diff you're requesting >> that would make it easier. Can you provide an example? >> >> thanks, >> Coleen >> >> On 2/27/15, 6:13 PM, Dean Long wrote: >>> Hi Coleen. I believe I understand what Max did, and that it was not >>> an automated merge, >>> which to me says that properly reviewing the change requires looking >>> at all 2851 >>> changed lines and mentally deciding if the result is equivalent to >>> the original. >>> >>> What I was suggesting was essentially two things. First, an aid to >>> the reviewer, >>> and second, a way to reduce risk. In the end it's up to the >>> reviewers. If they >>> prefer to see the changes in a single diff, they can compare a >>> single-file >>> automated merge with the single-file result of Max's merge. It >>> doesn't matter >>> if the reviewer does it or Max does it as a convenience. Regarding >>> risk, >>> if the reviewers aren't comfortable deciding that all 2851 are correct, >>> the changes could be staged into several pieces, and the first piece >>> could >>> be an automated merge that would be cleaned up later, on the assumption >>> that an automated merge could be considered trivially correct and >>> therefore >>> not risky. I hope that clears up my somewhat terse comments below. >>> >>> dl >>> >>> On 2/27/2015 12:06 PM, Coleen Phillimore wrote: >>>> >>>> Dean, This merge wasn't automatic in any way, so I don't think >>>> what you're proposing makes sense. I think if you look at the >>>> webrev you'll see what Max has done. >>>> Thanks, >>>> Coleen >>>> >>>> On 2/27/15, 1:39 PM, Dean Long wrote: >>>>> Hi Max. You could do an automatic merge using something like >>>>> "diff -w -D LP64 templateTable_x86_32.cpp and >>>>> templateTable_x86_64.cpp", then compare >>>>> your improvements to that. That way all the changes would show up in >>>>> a single diff. Or you could even check in the automatic merge >>>>> first, to reduce >>>>> risk, then break up the improvements into smaller pieces. >>>>> >>>>> dl >>>>> >>>>> On 2/27/2015 9:36 AM, Max Ockner wrote: >>>>>> Hello all, >>>>>> Please review this change which involves merging 32 and 64 bit >>>>>> interpreter files. >>>>>> >>>>>> Bug ID: 8013393 >>>>>> Webrev: cr.openjdk.java.net/~coleenp/8013393 >>>>>> >>>>>> Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp >>>>>> have been merged into one file*. These files originally shared >>>>>> thousands of lines of duplicate code. >>>>>> There were also many nearly identical sections of code which >>>>>> differed only in register usage (example: rsi vs. r13) or in the >>>>>> usage of nearly identical functions (example: movptr vs. movq/movl). >>>>>> Given that (1) new bytecodes could be added soon, and (2) these >>>>>> files have been tormenting Coleen for years, this change seems >>>>>> overdue. >>>>>> >>>>>> *There are currently two files. The updated templateTable_x86.cpp >>>>>> is copied into both templateTable_x86_32.cpp and >>>>>> templateTable_x86_64.cpp to make it easier to review (so the diff >>>>>> is not the entire file). This will be changed back to one file >>>>>> after review. >>>>>> >>>>>> For functions that could be merged, one copy was kept. In some >>>>>> cases, files were merged by factoring out small differences such >>>>>> as register usage (example: rbcp equals r13 or rsi depending on >>>>>> the platform). For functions that could not be merged, the 32 and >>>>>> 64 bit versions are adjacent and are defined conditionally using >>>>>> #ifdef based on the platform. >>>>>> >>>>>> There are still improvements to be made, but they are small and >>>>>> can be filed seperately. >>>>>> >>>>>> Tested with: >>>>>> JPRT >>>>>> UTE nsk.jvmti.testlist >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Max Ockner >>>>> >>>> >>> >> > From kim.barrett at oracle.com Mon Mar 2 20:44:41 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 2 Mar 2015 15:44:41 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> Message-ID: <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> On Mar 2, 2015, at 7:43 AM, Lindenmaier, Goetz wrote: > > I agree not to fix this. [kab: error checking in get_core_path()] > I uploaded a new webrev that fixes the remaining issues: > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.04/ > > I changed the makefile to only set the flag in gcc 4.8, > changed get_core_path to return -1 and removed the assertions, > and fixed the bracket in graphKit. Mostly looks good; just a couple more things. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/heapRegionSet.cpp 59 guarantee(( is_empty() && length() == 0 && total_capacity_bytes() == 0) || 60 (!is_empty() && length() >= 0 && total_capacity_bytes() >= 0), 61 hrs_ext_msg(this, "invariant")); => 59 guarantee((is_empty() && length() == 0 && total_capacity_bytes() == 0) || !is_empty(), 60 hrs_ext_msg(this, "invariant")); [Sorry I didn't notice this earlier.] Might it be that the real defect here is that the !is_empty() bounds should be > rather than >= ? I haven't done the analysis to verify that, just positing based on "obvious" reading of the code. If not, then it would be simpler as guarantee(!is_empty() || (length() == 0 && total_capacity_bytes() == 0), ...); or even better (since this is a guarantee) if (is_empty()) { guarantee(length() == 0 && total_capacity_bytes() == 0, ...); } ------------------------------------------------------------------------------ src/share/vm/runtime/dtraceJSDT.hpp New file? ------------------------------------------------------------------------------ I'd still like to see a doc comment update for the os::get_core_path() declaration in runtime/os.hpp that mentions the -1 return to indicate an error. ------------------------------------------------------------------------------ I've filed the following CRs for things we agreed not to address in this change set. https://bugs.openjdk.java.net/browse/JDK-8074136 Many missing error checks in get_core_path variants https://bugs.openjdk.java.net/browse/JDK-8074142 Simplify use of G1StressConcRegionFreeingDelayMillis From dean.long at oracle.com Mon Mar 2 20:44:20 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Mar 2015 12:44:20 -0800 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F4C868.7030009@oracle.com> References: <54F0AB0B.5090904@oracle.com> <54F0B9EF.4090800@oracle.com> <54F0CE60.9070505@oracle.com> <54F0FA11.3030903@oracle.com> <54F47B59.1030300@oracle.com> <54F4ADFE.3060805@oracle.com> <54F4C868.7030009@oracle.com> Message-ID: <54F4CBA4.3040609@oracle.com> OK. If we had to take as much time to review the "diff -D" merge as the human merge, then it's probably not worth it. It's only if we trust the "diff" merge and use that as a starting point for the pretty human merge that I see it helping. dl On 3/2/2015 12:30 PM, Coleen Phillimore wrote: > > Cool option to diff. I didn't know that existed. In this case, it > would yield a file that would be mostly impossible to review. Max's > change goes a lot further in merging these files, and would be > unfortunate to go backwards. This diff would leave a mess in the file > with a lot of #ifdefs that were easily resolved with register names > that I wouldn't want to look at. > > Coleen > > On 3/2/15, 1:37 PM, Dean Long wrote: >> Hi Coleen. Let's say the _32 file contains >> >> 32 >> x >> y >> z >> int >> >> and the _64 file contains >> >> 64 >> x >> y >> z >> long >> >> Then "diff -DLP64 _32 _64" will give: >> >> #ifndef LP64 >> 32 >> #else /* LP64 */ >> 64 >> #endif /* LP64 */ >> x >> y >> z >> #ifndef LP64 >> int >> #else /* LP64 */ >> long >> #endif /* LP64 */ >> >> In other words, an automatic merge of the two files, with the >> differences in #ifdefs. >> >> thanks, >> >> dl >> >> On 3/2/2015 7:01 AM, Coleen Phillimore wrote: >>> >>> Hi Dean, >>> I'm not sure how to do this diff that you're suggesting. I don't >>> think an intermediate changeset makes sense either. The bytecodes >>> are pretty well tested with our normal testing so increasing this to >>> more than one change, just increases testing and putback overhead. >>> >>> I've looked at this several times and it's not very difficult to >>> tell what's done and whether it's correct. The diffs do not span a >>> lot of code (at most 5 lines at a time), so there are no new whole >>> functions to read that are new code. >>> >>> I'm still really don't understand what kind of diff you're >>> requesting that would make it easier. Can you provide an example? >>> >>> thanks, >>> Coleen >>> >>> On 2/27/15, 6:13 PM, Dean Long wrote: >>>> Hi Coleen. I believe I understand what Max did, and that it was >>>> not an automated merge, >>>> which to me says that properly reviewing the change requires >>>> looking at all 2851 >>>> changed lines and mentally deciding if the result is equivalent to >>>> the original. >>>> >>>> What I was suggesting was essentially two things. First, an aid to >>>> the reviewer, >>>> and second, a way to reduce risk. In the end it's up to the >>>> reviewers. If they >>>> prefer to see the changes in a single diff, they can compare a >>>> single-file >>>> automated merge with the single-file result of Max's merge. It >>>> doesn't matter >>>> if the reviewer does it or Max does it as a convenience. Regarding >>>> risk, >>>> if the reviewers aren't comfortable deciding that all 2851 are >>>> correct, >>>> the changes could be staged into several pieces, and the first >>>> piece could >>>> be an automated merge that would be cleaned up later, on the >>>> assumption >>>> that an automated merge could be considered trivially correct and >>>> therefore >>>> not risky. I hope that clears up my somewhat terse comments below. >>>> >>>> dl >>>> >>>> On 2/27/2015 12:06 PM, Coleen Phillimore wrote: >>>>> >>>>> Dean, This merge wasn't automatic in any way, so I don't think >>>>> what you're proposing makes sense. I think if you look at the >>>>> webrev you'll see what Max has done. >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 2/27/15, 1:39 PM, Dean Long wrote: >>>>>> Hi Max. You could do an automatic merge using something like >>>>>> "diff -w -D LP64 templateTable_x86_32.cpp and >>>>>> templateTable_x86_64.cpp", then compare >>>>>> your improvements to that. That way all the changes would show >>>>>> up in >>>>>> a single diff. Or you could even check in the automatic merge >>>>>> first, to reduce >>>>>> risk, then break up the improvements into smaller pieces. >>>>>> >>>>>> dl >>>>>> >>>>>> On 2/27/2015 9:36 AM, Max Ockner wrote: >>>>>>> Hello all, >>>>>>> Please review this change which involves merging 32 and 64 bit >>>>>>> interpreter files. >>>>>>> >>>>>>> Bug ID: 8013393 >>>>>>> Webrev: cr.openjdk.java.net/~coleenp/8013393 >>>>>>> >>>>>>> Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp >>>>>>> have been merged into one file*. These files originally shared >>>>>>> thousands of lines of duplicate code. >>>>>>> There were also many nearly identical sections of code which >>>>>>> differed only in register usage (example: rsi vs. r13) or in the >>>>>>> usage of nearly identical functions (example: movptr vs. >>>>>>> movq/movl). >>>>>>> Given that (1) new bytecodes could be added soon, and (2) these >>>>>>> files have been tormenting Coleen for years, this change seems >>>>>>> overdue. >>>>>>> >>>>>>> *There are currently two files. The updated >>>>>>> templateTable_x86.cpp is copied into both >>>>>>> templateTable_x86_32.cpp and templateTable_x86_64.cpp to make it >>>>>>> easier to review (so the diff is not the entire file). This will >>>>>>> be changed back to one file after review. >>>>>>> >>>>>>> For functions that could be merged, one copy was kept. In some >>>>>>> cases, files were merged by factoring out small differences such >>>>>>> as register usage (example: rbcp equals r13 or rsi depending on >>>>>>> the platform). For functions that could not be merged, the 32 >>>>>>> and 64 bit versions are adjacent and are defined conditionally >>>>>>> using #ifdef based on the platform. >>>>>>> >>>>>>> There are still improvements to be made, but they are small and >>>>>>> can be filed seperately. >>>>>>> >>>>>>> Tested with: >>>>>>> JPRT >>>>>>> UTE nsk.jvmti.testlist >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max Ockner >>>>>> >>>>> >>>> >>> >> > From john.r.rose at oracle.com Mon Mar 2 21:45:16 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 2 Mar 2015 13:45:16 -0800 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: References: <54F0AB0B.5090904@oracle.com> Message-ID: <0BAC24A3-40E0-4E34-AA1E-EE9ECAB4A99F@oracle.com> On Mar 2, 2015, at 11:46 AM, Christian Thalinger wrote: > > That?s quite a large change (I wish we had Crucible or something to leave inline comments). > > First, you have to keep the oldest copyright year (but maybe that?s just the diff). > > + #ifdef _LP64 > + void TemplateTable::lconst(int value) { > > I?d prefer to have #ifdef?s inside methods and not around them. There are a bunch; please change all of them. I agree Christian's comments, and especially with this request. A few more points on small matters: In our source base, C++ comments usually begin with two slashes and a space (less than 10% exceptions). +//Global Register Names +//Address Computation: local variables (etc.) Let's use the term "amd64" only where required; x86_64 is the standard now. // No amd64 specific initialization More on #ifdefs: I think there are too many; Chris has pointed out the main problem. It's a judgement call, but here's another example: +#ifdef _LP64 + Register rtmp = r8; + Register rthread = r15_thread; +#else + Register rtmp = rsi; + Register rthread = rcx; + __ get_thread(rcx); + __ save_bcp(); +#endif // _LP64 could just as well be: + Register rtmp = LP64_ONLY(r8) NOT_LP64(rsi); + Register rthread = LP64_ONLY(r15_thread) NOT_LP64(rcx); + LP64_ONLY(__ get_thread(rcx)); + LP64_ONLY(__ save_bcp()); Advantages: Fewer lines, less duplication, less chance of merge problems. Possible objection: Ugly; but only in a different way from the other ugly. However, I admit that is a marginal example. ? John From goetz.lindenmaier at sap.com Mon Mar 2 21:48:34 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 2 Mar 2015 21:48:34 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> Hi Kim, thanks for looking at it again. I will look into heapRetionSet.cpp tomorrow. About the comment, I don't feel good documenting something that's not true, as the other implementations still return 0 on error. I can't see where that file is coming from, I sure never did a hg add for it. It used to be there. An artefact of pull & rebase? I'll remove it again... Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Monday, March 02, 2015 9:45 PM To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Mar 2, 2015, at 7:43 AM, Lindenmaier, Goetz wrote: > > I agree not to fix this. [kab: error checking in get_core_path()] > I uploaded a new webrev that fixes the remaining issues: > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.04/ > > I changed the makefile to only set the flag in gcc 4.8, > changed get_core_path to return -1 and removed the assertions, > and fixed the bracket in graphKit. Mostly looks good; just a couple more things. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/heapRegionSet.cpp 59 guarantee(( is_empty() && length() == 0 && total_capacity_bytes() == 0) || 60 (!is_empty() && length() >= 0 && total_capacity_bytes() >= 0), 61 hrs_ext_msg(this, "invariant")); => 59 guarantee((is_empty() && length() == 0 && total_capacity_bytes() == 0) || !is_empty(), 60 hrs_ext_msg(this, "invariant")); [Sorry I didn't notice this earlier.] Might it be that the real defect here is that the !is_empty() bounds should be > rather than >= ? I haven't done the analysis to verify that, just positing based on "obvious" reading of the code. If not, then it would be simpler as guarantee(!is_empty() || (length() == 0 && total_capacity_bytes() == 0), ...); or even better (since this is a guarantee) if (is_empty()) { guarantee(length() == 0 && total_capacity_bytes() == 0, ...); } ------------------------------------------------------------------------------ src/share/vm/runtime/dtraceJSDT.hpp New file? ------------------------------------------------------------------------------ I'd still like to see a doc comment update for the os::get_core_path() declaration in runtime/os.hpp that mentions the -1 return to indicate an error. ------------------------------------------------------------------------------ I've filed the following CRs for things we agreed not to address in this change set. https://bugs.openjdk.java.net/browse/JDK-8074136 Many missing error checks in get_core_path variants https://bugs.openjdk.java.net/browse/JDK-8074142 Simplify use of G1StressConcRegionFreeingDelayMillis From vladimir.kozlov at oracle.com Mon Mar 2 22:57:30 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Mar 2015 14:57:30 -0800 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F4A7B9.9010700@oracle.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> <54F0A270.8080708@oracle.com> <54F0A517.9030101@redhat.com> <54F0B061.6080802@oracle.com> <54F48A01.1070300@redhat.com> <54F49915.8050901@redhat.com> <54F4A37A.9070209@redhat.com> <54F4A4D0.2080704@redhat.com> <54F4A7B9.9010700@oracle.com> Message-ID: <54F4EADA.6050704@oracle.com> Changes were pushed into stage repo. I also included latest changes from jdk9/dev. I am pushing it into jdk9/dev now. Regards, Vladimir On 3/2/15 10:11 AM, Vladimir Kozlov wrote: > Looks good to me too. I will push it now to stage repo first. > > Thanks, > Vladimir > > On 3/2/15 9:58 AM, Andrew Haley wrote: >> On 03/02/2015 05:52 PM, Andrew Dinn wrote: >>> On 02/03/15 17:08, Andrew Haley wrote: >>> >>>> Can we have a webrev for this? >>> >>> >>> http://cr.openjdk.java.net/~adinn/8074119/webrev.00 >> >> Thanks, that all looks reasonable. >> >> Andrew. >> >> From kim.barrett at oracle.com Tue Mar 3 02:02:02 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 2 Mar 2015 21:02:02 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> Message-ID: <63935ED2-F85A-4EBE-8F42-C742BF18B873@oracle.com> On Mar 2, 2015, at 4:48 PM, Lindenmaier, Goetz wrote: > > I will look into heapRetionSet.cpp tomorrow. OK. If it turns out to be hard to prove the tests should be > rather than >= (e.g. proving that if !is_empty() then those values must *not* be zero), then I?d be ok with just having the test simplified, and maybe file a CR to investigate further. > About the comment, I don't feel good documenting something > that's not true, as the other implementations still return 0 on > error. OK. I?ll adjust the corresponding comment in the CR I filed. > I can't see where that file is coming from, I sure never did a > hg add for it. It used to be there. An artefact of pull & rebase? > I'll remove it again... Can?t help you there; just make sure it?s gone when pushing. From vladimir.kozlov at oracle.com Tue Mar 3 02:18:25 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Mar 2015 18:18:25 -0800 Subject: AARCH64 open port was merged to jdk9/dev Message-ID: <54F519F1.6010809@oracle.com> AARCH64 port was pushed to jdk9/dev: http://hg.openjdk.java.net/jdk9/dev I will ask to make stage repo as ReadOnly: http://hg.openjdk.java.net/aarch64-port/stage Regards, Vladimir From goetz.lindenmaier at sap.com Tue Mar 3 14:46:32 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 3 Mar 2015 14:46:32 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <63935ED2-F85A-4EBE-8F42-C742BF18B873@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> <63935ED2-F85A-4EBE-8F42-C742BF18B873@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF9C1CE@DEWDFEMB12A.global.corp.sap> Hi Kim, as I understand the code, > 0 should hold for both tests. But I think what is really meant by the check, protecting against underflow, should be checked in decrement(): --- //bas2/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 +++ /sapmnt/home/d045726/src3/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 @@ -67,6 +67,9 @@ } void decrement(const uint length_to_remove, const size_t capacity_to_remove) { +#ifdef HEAP_REGION_SET_FORCE_VERIFY + guarantee(length_to_remove <= _length && capacity_to_remove <= _capacity, "underflow"); +#endif _length -= length_to_remove; _capacity -= capacity_to_remove; } Or by casting _length and _capacity to singed types in the guarantee in verify(), which is quite ugly. But I think it would work fine by the values one can expect here. I changed verify() to check for '>', but didn't add above guarantee, I think that again is out of the scope of this change. http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.05/ I ran a row of tests with the adapted assertion, and will push it into our nightbuild. Best regards, Goetz -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Dienstag, 3. M?rz 2015 03:02 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Mar 2, 2015, at 4:48 PM, Lindenmaier, Goetz wrote: > > I will look into heapRetionSet.cpp tomorrow. OK. If it turns out to be hard to prove the tests should be > rather than >= (e.g. proving that if !is_empty() then those values must *not* be zero), then I'd be ok with just having the test simplified, and maybe file a CR to investigate further. > About the comment, I don't feel good documenting something > that's not true, as the other implementations still return 0 on > error. OK. I'll adjust the corresponding comment in the CR I filed. > I can't see where that file is coming from, I sure never did a > hg add for it. It used to be there. An artefact of pull & rebase? > I'll remove it again... Can't help you there; just make sure it's gone when pushing. From aph at redhat.com Tue Mar 3 18:01:15 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 03 Mar 2015 18:01:15 +0000 Subject: RFA: 8074349: AARCH64: C2 generates poor code for some byte and character stores Message-ID: <54F5F6EB.1040904@redhat.com> We should use iRegIorL2I as the source operand for all stores of int size or less. http://cr.openjdk.java.net/~aph/8074349/ Andrew. From vladimir.kozlov at oracle.com Tue Mar 3 18:16:32 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Mar 2015 10:16:32 -0800 Subject: RFA: 8074349: AARCH64: C2 generates poor code for some byte and character stores In-Reply-To: <54F5F6EB.1040904@redhat.com> References: <54F5F6EB.1040904@redhat.com> Message-ID: <54F5FA80.7040305@oracle.com> Looks good. Since it is platform specific code new rule allow you to push changes yourself. Make sure you have jcheck enabled - ~/.hgrc has [extensions] jcheck=//jcheck.py [hooks] pretxnchangegroup=python:jcheck.hook pretxncommit=python:jcheck.hook See http://openjdk.java.net/projects/code-tools/jcheck/ And, please, make sure changeset has correct header: 8074349: AARCH64: C2 generates poor code for some byte and character stores Summary: Use iRegIorL2I as the source operand for all stores of int size or less. Reviewed-by: kvn See http://openjdk.java.net/guide/producingChangeset.html Thanks, Vladimir On 3/3/15 10:01 AM, Andrew Haley wrote: > We should use iRegIorL2I as the source operand for all stores of int > size or less. > > http://cr.openjdk.java.net/~aph/8074349/ > > Andrew. > From aph at redhat.com Tue Mar 3 18:19:44 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 03 Mar 2015 18:19:44 +0000 Subject: RFA: 8074349: AARCH64: C2 generates poor code for some byte and character stores In-Reply-To: <54F5FA80.7040305@oracle.com> References: <54F5F6EB.1040904@redhat.com> <54F5FA80.7040305@oracle.com> Message-ID: <54F5FB40.5080103@redhat.com> On 03/03/2015 06:16 PM, Vladimir Kozlov wrote: > Looks good. > > Since it is platform specific code new rule allow you to push changes yourself. OK. > Make sure you have jcheck enabled - ~/.hgrc has > > [extensions] > jcheck=//jcheck.py > [hooks] > pretxnchangegroup=python:jcheck.hook > pretxncommit=python:jcheck.hook > > See http://openjdk.java.net/projects/code-tools/jcheck/ Yes, long since. > And, please, make sure changeset has correct header: > > 8074349: AARCH64: C2 generates poor code for some byte and character stores > Summary: Use iRegIorL2I as the source operand for all stores of int size or less. > Reviewed-by: kvn > > See http://openjdk.java.net/guide/producingChangeset.html If this header is wrong, you'll have to tell me where. I can't see it. Thanks, Andrew. From vladimir.kozlov at oracle.com Tue Mar 3 18:41:55 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Mar 2015 10:41:55 -0800 Subject: RFA: 8074349: AARCH64: C2 generates poor code for some byte and character stores In-Reply-To: <54F5FB40.5080103@redhat.com> References: <54F5F6EB.1040904@redhat.com> <54F5FA80.7040305@oracle.com> <54F5FB40.5080103@redhat.com> Message-ID: <54F60073.8000306@oracle.com> On 3/3/15 10:19 AM, Andrew Haley wrote: > On 03/03/2015 06:16 PM, Vladimir Kozlov wrote: >> Looks good. >> >> Since it is platform specific code new rule allow you to push changes yourself. > > OK. > >> Make sure you have jcheck enabled - ~/.hgrc has >> >> [extensions] >> jcheck=//jcheck.py >> [hooks] >> pretxnchangegroup=python:jcheck.hook >> pretxncommit=python:jcheck.hook >> >> See http://openjdk.java.net/projects/code-tools/jcheck/ > > Yes, long since. Good. > >> And, please, make sure changeset has correct header: >> >> 8074349: AARCH64: C2 generates poor code for some byte and character stores >> Summary: Use iRegIorL2I as the source operand for all stores of int size or less. >> Reviewed-by: kvn >> >> See http://openjdk.java.net/guide/producingChangeset.html > > If this header is wrong, you'll have to tell me where. I can't see it. It is example what the header should be for this fix. It is correct one. Your patch in webrev does not have a header so I don't know what you have. Regards, Vladimir > > Thanks, > Andrew. > > From filamoon at gmail.com Tue Mar 3 18:58:24 2015 From: filamoon at gmail.com (Zhanglei Wang) Date: Tue, 3 Mar 2015 10:58:24 -0800 Subject: Two JDK issues were closed as they duplicate EACH OTHER Message-ID: https://bugs.openjdk.java.net/browse/JDK-8068663 https://bugs.openjdk.java.net/browse/JDK-8067648 They were closed as duplicate but they actually point to each other! From aleksey.shipilev at oracle.com Tue Mar 3 19:14:12 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 03 Mar 2015 22:14:12 +0300 Subject: Two JDK issues were closed as they duplicate EACH OTHER In-Reply-To: References: Message-ID: <54F60804.4010108@oracle.com> On 03/03/2015 09:58 PM, Zhanglei Wang wrote: > https://bugs.openjdk.java.net/browse/JDK-8068663 > https://bugs.openjdk.java.net/browse/JDK-8067648 Interesting. Actually I think 8067648 is closed as "Incomplete", not "Duplicate". Reopened that one, since Nils seems to be asking for confirmation for 8u40, and Abhijit did it with 8068663. -Aleksey. From kim.barrett at oracle.com Tue Mar 3 21:30:03 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Mar 2015 16:30:03 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF9C1CE@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> <63935ED2-F85A-4EBE-8F42-C742BF18B873@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9C1CE@DEWDFEMB12A.global.corp.sap> Message-ID: On Mar 3, 2015, at 9:46 AM, Lindenmaier, Goetz wrote: > > Hi Kim, > > as I understand the code, > 0 should hold for both tests. > But I think what is really meant by the check, protecting against underflow, > should be checked in decrement(): > > --- //bas2/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 > +++ /sapmnt/home/d045726/src3/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 > @@ -67,6 +67,9 @@ > } > > void decrement(const uint length_to_remove, const size_t capacity_to_remove) { > +#ifdef HEAP_REGION_SET_FORCE_VERIFY > + guarantee(length_to_remove <= _length && capacity_to_remove <= _capacity, "underflow"); > +#endif > _length -= length_to_remove; > _capacity -= capacity_to_remove; > } > > Or by casting _length and _capacity to singed types in the guarantee in verify(), which is > quite ugly. But I think it would work fine by the values one can expect here. > > I changed verify() to check for '>', but didn't add above guarantee, I think that again > is out of the scope of this change. > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.05/ > > I ran a row of tests with the adapted assertion, and will push it into our nightbuild. I think you are right that the check is really for underflow, and that should be in decrement() as you suggest. And I?m fine with the way you?ve left it. Anything further can be a later cleanup if desired. So I?m done reviewing. Looks good to me. From max.ockner at oracle.com Tue Mar 3 21:39:43 2015 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 03 Mar 2015 16:39:43 -0500 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <0BAC24A3-40E0-4E34-AA1E-EE9ECAB4A99F@oracle.com> References: <54F0AB0B.5090904@oracle.com> <0BAC24A3-40E0-4E34-AA1E-EE9ECAB4A99F@oracle.com> Message-ID: <54F62A1F.4000507@oracle.com> Hello all, I have made all of the changes recommended by Chris and John. I realize there are plenty of further cleanups and optimizations that I could make, but I think this is nearing a good stopping point for now. We can always clean it up more later. What do you think? new webrev: cr.openjdk.java.net/~coleenp/8013393 tested with nsk.jvmti.testlist On 3/2/2015 4:45 PM, John Rose wrote: > On Mar 2, 2015, at 11:46 AM, Christian Thalinger wrote: >> That?s quite a large change (I wish we had Crucible or something to leave inline comments). >> >> First, you have to keep the oldest copyright year (but maybe that?s just the diff). >> >> + #ifdef _LP64 >> + void TemplateTable::lconst(int value) { >> >> I?d prefer to have #ifdef?s inside methods and not around them. There are a bunch; please change all of them. I have moved the #ifdef's to the inside of the function declarations. Some of the #ifdefs could be moved far enough in that it made sense to replace them with the LP64_ONLY() or NOT_LP64() tools. The remaining #ifdef's are there because some large sections of code could not be merged, and needed to be kept together. > I agree Christian's comments, and especially with this request. > > A few more points on small matters: > > In our source base, C++ comments usually begin with two slashes and a space (less than 10% exceptions). > +//Global Register Names > +//Address Computation: local variables > (etc.) Fixed. > Let's use the term "amd64" only where required; x86_64 is the standard now. > // No amd64 specific initialization Fixed. > More on #ifdefs: I think there are too many; Chris has pointed out the main problem. > > It's a judgement call, but here's another example: > > +#ifdef _LP64 > + Register rtmp = r8; > + Register rthread = r15_thread; > +#else > + Register rtmp = rsi; > + Register rthread = rcx; > + __ get_thread(rcx); > + __ save_bcp(); > +#endif // _LP64 > > could just as well be: > > + Register rtmp = LP64_ONLY(r8) NOT_LP64(rsi); > + Register rthread = LP64_ONLY(r15_thread) NOT_LP64(rcx); > + LP64_ONLY(__ get_thread(rcx)); > + LP64_ONLY(__ save_bcp()); > > Advantages: Fewer lines, less duplication, less chance of merge problems. > Possible objection: Ugly; but only in a different way from the other ugly. Fixed, but there are some #ifdef's left over. There are some pretty large code blocks that are conditionally defined. I don't think it makes sense to enclose every conditionally defined line of code in an LP64_ONLY or NOT_LP64. At best you save 3 lines of code, but I feel that a those 3 lines would be less distracting than having 25 LP64_ONLY's in a row. > > However, I admit that is a marginal example. > > ? John Thanks, Max Ockner From serguei.spitsyn at oracle.com Wed Mar 4 00:00:34 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 03 Mar 2015 16:00:34 -0800 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F62A1F.4000507@oracle.com> References: <54F0AB0B.5090904@oracle.com> <0BAC24A3-40E0-4E34-AA1E-EE9ECAB4A99F@oracle.com> <54F62A1F.4000507@oracle.com> Message-ID: <54F64B22.9040008@oracle.com> Hi Max, A minor comment. The testlist (nsk.jvmti.testlist) looks strange. I'd expect at least some runtime tests to be run. Thanks, Serguei On 3/3/15 1:39 PM, Max Ockner wrote: > Hello all, > I have made all of the changes recommended by Chris and John. I > realize there are plenty of further cleanups and optimizations that I > could make, but I think this is nearing a good stopping point for now. > We can always clean it up more later. What do you think? > > new webrev: cr.openjdk.java.net/~coleenp/8013393 > tested with nsk.jvmti.testlist > > On 3/2/2015 4:45 PM, John Rose wrote: >> On Mar 2, 2015, at 11:46 AM, Christian Thalinger >> wrote: >>> That?s quite a large change (I wish we had Crucible or something to >>> leave inline comments). >>> >>> First, you have to keep the oldest copyright year (but maybe that?s >>> just the diff). >>> >>> + #ifdef _LP64 >>> + void TemplateTable::lconst(int value) { >>> >>> I?d prefer to have #ifdef?s inside methods and not around them. >>> There are a bunch; please change all of them. > I have moved the #ifdef's to the inside of the function declarations. > Some of the #ifdefs could be moved far enough in that it made sense to > replace them with the LP64_ONLY() or NOT_LP64() tools. The remaining > #ifdef's are there because some large sections of code could not be > merged, and needed to be kept together. > >> I agree Christian's comments, and especially with this request. >> >> A few more points on small matters: >> >> In our source base, C++ comments usually begin with two slashes and a >> space (less than 10% exceptions). >> +//Global Register Names >> +//Address Computation: local variables >> (etc.) > > Fixed. > >> Let's use the term "amd64" only where required; x86_64 is the >> standard now. >> // No amd64 specific initialization > > Fixed. > >> More on #ifdefs: I think there are too many; Chris has pointed out >> the main problem. >> >> It's a judgement call, but here's another example: >> >> +#ifdef _LP64 >> + Register rtmp = r8; >> + Register rthread = r15_thread; >> +#else >> + Register rtmp = rsi; >> + Register rthread = rcx; >> + __ get_thread(rcx); >> + __ save_bcp(); >> +#endif // _LP64 >> >> could just as well be: >> >> + Register rtmp = LP64_ONLY(r8) NOT_LP64(rsi); >> + Register rthread = LP64_ONLY(r15_thread) NOT_LP64(rcx); >> + LP64_ONLY(__ get_thread(rcx)); >> + LP64_ONLY(__ save_bcp()); >> >> Advantages: Fewer lines, less duplication, less chance of merge >> problems. >> Possible objection: Ugly; but only in a different way from the other >> ugly. > > Fixed, but there are some #ifdef's left over. There are some pretty > large code blocks that are conditionally defined. I don't think it > makes sense to enclose every conditionally defined line of code in an > LP64_ONLY or NOT_LP64. At best you save 3 lines of code, but I feel > that a those 3 lines would be less distracting than having 25 > LP64_ONLY's in a row. >> >> However, I admit that is a marginal example. >> >> ? John > > Thanks, > Max Ockner > From john.r.rose at oracle.com Wed Mar 4 02:13:28 2015 From: john.r.rose at oracle.com (John Rose) Date: Tue, 3 Mar 2015 18:13:28 -0800 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F62A1F.4000507@oracle.com> References: <54F0AB0B.5090904@oracle.com> <0BAC24A3-40E0-4E34-AA1E-EE9ECAB4A99F@oracle.com> <54F62A1F.4000507@oracle.com> Message-ID: On Mar 3, 2015, at 1:39 PM, Max Ockner wrote: > > I have made all of the changes recommended by Chris and John. I realize there are plenty of further cleanups and optimizations that I could make, but I think this is nearing a good stopping point for now. We can always clean it up more later. What do you think? > > new webrev: cr.openjdk.java.net/~coleenp/8013393 > tested with nsk.jvmti.testlist I think the webrev is: cr.openjdk.java.net/~coleenp/8013393.02 It looks good. The balance of shared code, #ifdefs, and LP64 macros is very reasonable now. The template '_new' uses register allocations from 32-bit on 64-bit, and so there is a slight chance of regression there. I didn't notice that of the other templates. You can count me as a reviewer. ? John From goetz.lindenmaier at sap.com Wed Mar 4 08:10:52 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Mar 2015 08:10:52 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> <63935ED2-F85A-4EBE-8F42-C742BF18B873@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9C1CE@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFA45F8@DEWDFEMB12A.global.corp.sap> Thanks a lot for looking into this! Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Dienstag, 3. M?rz 2015 22:30 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Mar 3, 2015, at 9:46 AM, Lindenmaier, Goetz wrote: > > Hi Kim, > > as I understand the code, > 0 should hold for both tests. > But I think what is really meant by the check, protecting against underflow, > should be checked in decrement(): > > --- //bas2/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 > +++ /sapmnt/home/d045726/src3/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 > @@ -67,6 +67,9 @@ > } > > void decrement(const uint length_to_remove, const size_t capacity_to_remove) { > +#ifdef HEAP_REGION_SET_FORCE_VERIFY > + guarantee(length_to_remove <= _length && capacity_to_remove <= _capacity, "underflow"); > +#endif > _length -= length_to_remove; > _capacity -= capacity_to_remove; > } > > Or by casting _length and _capacity to singed types in the guarantee in verify(), which is > quite ugly. But I think it would work fine by the values one can expect here. > > I changed verify() to check for '>', but didn't add above guarantee, I think that again > is out of the scope of this change. > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.05/ > > I ran a row of tests with the adapted assertion, and will push it into our nightbuild. I think you are right that the check is really for underflow, and that should be in decrement() as you suggest. And I'm fine with the way you've left it. Anything further can be a later cleanup if desired. So I'm done reviewing. Looks good to me. From david.holmes at oracle.com Wed Mar 4 08:23:36 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Mar 2015 18:23:36 +1000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: <54F3C608.6080405@oracle.com> References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> <54EBE25E.2080905@oracle.com> <54F3C608.6080405@oracle.com> Message-ID: <54F6C108.6070408@oracle.com> Changes have been pushed. Thanks, David On 2/03/2015 12:08 PM, David Holmes wrote: > On 24/02/2015 12:30 PM, David Holmes wrote: >> On 24/02/2015 4:45 AM, Karen Kinnear wrote: >>> >>> On Feb 20, 2015, at 1:24 PM, Erik ?sterlund wrote: >>> >>> And truly many thanks - in my mind you have made this much more >>> conceptually clean and safer. >>> I am good with your checking in the parts I have reviewed. >> >> Thanks Karen! So unless someone has something they really want to be >> changed now (and I think everyone has so far said there are no strOng >> objections to anything) then I will push this version: >> >> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ >> >> in a couple of days. > > Updated with compiler version information where known: > > http://cr.openjdk.java.net/~dholmes/7143664/webrev-v5/ > > Changeset prepared ready for push - please let me know if I've missed > anybody off the reviewer list. > > I will push this on Wednesday my time (GMT+10) as I won't be in the > office Tuesday. > > Thanks, > David > ----- From erik.osterlund at lnu.se Wed Mar 4 09:16:48 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Wed, 4 Mar 2015 09:16:48 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> <54EBE25E.2080905@oracle.com> <54F3C608.6080405@oracle.com> <54F6C108.6070408@oracle.com> Message-ID: Big thanks to all the 7 reviewers and also extra thanks to Jesper for being helpful running JPRT for me and David for sponsoring the change, the lengthy discussions and pointing me in the right directions! /Erik On 04/03/15 09:24, David Holmes wrote: > Changes have been pushed. > > Thanks, > David > > On 2/03/2015 12:08 PM, David Holmes wrote: >> On 24/02/2015 12:30 PM, David Holmes wrote: >>> On 24/02/2015 4:45 AM, Karen Kinnear wrote: >>>> >>>> On Feb 20, 2015, at 1:24 PM, Erik ?sterlund wrote: >>>> >>>> And truly many thanks - in my mind you have made this much more >>>> conceptually clean and safer. >>>> I am good with your checking in the parts I have reviewed. >>> >>> Thanks Karen! So unless someone has something they really want to be >>> changed now (and I think everyone has so far said there are no strOng >>> objections to anything) then I will push this version: >>> >>> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ >>> >>> in a couple of days. >> >> Updated with compiler version information where known: >> >> http://cr.openjdk.java.net/~dholmes/7143664/webrev-v5/ >> >> Changeset prepared ready for push - please let me know if I've missed >> anybody off the reviewer list. >> >> I will push this on Wednesday my time (GMT+10) as I won't be in the >> office Tuesday. >> >> Thanks, >> David >> ----- > From volker.simonis at gmail.com Wed Mar 4 16:19:45 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Mar 2015 17:19:45 +0100 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFA45F8@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> <63935ED2-F85A-4EBE-8F42-C742BF18B873@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9C1CE@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CFA45F8@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, Kim, thanks a lot for working this out so far. I've looked at the change myself now and I thinks it is in a good state. I just found some minor issues: - fix Copyright date in: src/share/vm/gc_implementation/g1/concurrentMark.hpp src/share/vm/memory/blockOffsetTable.cpp - not sure why we need the following in: src/share/vm/gc_implementation/g1/ptrQueue.cpp 196 _index = _sz; 197 assert(_index <= _sz, "Invariant."); ..until we are really, really paranoid that the assignment "_index = _sz" can fail :) - in: src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp we do the check: 245 assert(start_chunk_index >= lowest_non_clean_base_chunk_index && // Check underflow. only in one branch of the following if/else, but in the other branch we use 'cur_chunk_index' without check: 264 assert(lowest_non_clean[cur_chunk_index] == NULL, "Write once : value should be stable hereafter"); 265 jbyte* first_card_of_cur_chunk = byte_for(chunk_mr.start()); 266 lowest_non_clean[cur_chunk_index] = first_card_of_cur_chunk; Wouldn't it be better to do the check for 'start_chunk_index >= lowest_non_clean_base_chunk_index' right before the definition of 'cur_chunk_index' like so: 198 uintptr_t start_chunk_index = addr_to_chunk_index(chunk_mr.start()); assert(start_chunk_index >= lowest_non_clean_base_chunk_index, "Bounds error."); // Check underflow. 199 uintptr_t cur_chunk_index = start_chunk_index - lowest_non_clean_base_chunk_index; - the change in: src/share/vm/memory/blockOffsetTable.cpp 795 size_t next = _next_offset_index; 796 return next == 0 ? 0 : next - 1; could be simplified into just one line: 796 return _next_offset_index == 0 ? 0 : _next_offset_index - 1; Thanks, Volker On Wed, Mar 4, 2015 at 9:10 AM, Lindenmaier, Goetz wrote: > Thanks a lot for looking into this! > > Best regards, > Goetz. > > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Dienstag, 3. M?rz 2015 22:30 > To: Lindenmaier, Goetz > Cc: hotspot-dev Source Developers > Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. > > On Mar 3, 2015, at 9:46 AM, Lindenmaier, Goetz wrote: >> >> Hi Kim, >> >> as I understand the code, > 0 should hold for both tests. >> But I think what is really meant by the check, protecting against underflow, >> should be checked in decrement(): >> >> --- //bas2/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 >> +++ /sapmnt/home/d045726/src3/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 >> @@ -67,6 +67,9 @@ >> } >> >> void decrement(const uint length_to_remove, const size_t capacity_to_remove) { >> +#ifdef HEAP_REGION_SET_FORCE_VERIFY >> + guarantee(length_to_remove <= _length && capacity_to_remove <= _capacity, "underflow"); >> +#endif >> _length -= length_to_remove; >> _capacity -= capacity_to_remove; >> } >> >> Or by casting _length and _capacity to singed types in the guarantee in verify(), which is >> quite ugly. But I think it would work fine by the values one can expect here. >> >> I changed verify() to check for '>', but didn't add above guarantee, I think that again >> is out of the scope of this change. >> http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.05/ >> >> I ran a row of tests with the adapted assertion, and will push it into our nightbuild. > > I think you are right that the check is really for underflow, and that should be in decrement() > as you suggest. And I'm fine with the way you've left it. Anything further can be a later cleanup > if desired. > > So I'm done reviewing. Looks good to me. > From kim.barrett at oracle.com Wed Mar 4 20:14:21 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 4 Mar 2015 15:14:21 -0500 Subject: RFR: 8073994: STATIC_ASSERT use of __LINE__ is wrong Message-ID: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> Please review this small cleanup of the infrastructure underlying the STATIC_ASSERT macro. I will need a sponsor for this change. STATIC_ASSERT is using macro token splicing incorrectly to (attempt to) produce a unique type name. Rather than fixing the splicing we note that the unique type name isn't actually needed. - If the assertion fails the type name never gets used at all. - If the assertion passes we're just redefining a typedef name with the same type, which is permitted (C++03 7.1.3 clause 3). So we just pick a dummy type name to always use. CR: https://bugs.openjdk.java.net/browse/JDK-8073994 Webrev: http://cr.openjdk.java.net/~kbarrett/8073994/webrev.00 Testing: JPRT Local testing of assertion failures. From coleen.phillimore at oracle.com Wed Mar 4 21:55:41 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 04 Mar 2015 16:55:41 -0500 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F62A1F.4000507@oracle.com> References: <54F0AB0B.5090904@oracle.com> <0BAC24A3-40E0-4E34-AA1E-EE9ECAB4A99F@oracle.com> <54F62A1F.4000507@oracle.com> Message-ID: <54F77F5D.5040705@oracle.com> Still thumbs up. Coleen On 3/3/15, 4:39 PM, Max Ockner wrote: > Hello all, > I have made all of the changes recommended by Chris and John. I > realize there are plenty of further cleanups and optimizations that I > could make, but I think this is nearing a good stopping point for now. > We can always clean it up more later. What do you think? > > new webrev: cr.openjdk.java.net/~coleenp/8013393 > tested with nsk.jvmti.testlist > > On 3/2/2015 4:45 PM, John Rose wrote: >> On Mar 2, 2015, at 11:46 AM, Christian Thalinger >> wrote: >>> That?s quite a large change (I wish we had Crucible or something to >>> leave inline comments). >>> >>> First, you have to keep the oldest copyright year (but maybe that?s >>> just the diff). >>> >>> + #ifdef _LP64 >>> + void TemplateTable::lconst(int value) { >>> >>> I?d prefer to have #ifdef?s inside methods and not around them. >>> There are a bunch; please change all of them. > I have moved the #ifdef's to the inside of the function declarations. > Some of the #ifdefs could be moved far enough in that it made sense to > replace them with the LP64_ONLY() or NOT_LP64() tools. The remaining > #ifdef's are there because some large sections of code could not be > merged, and needed to be kept together. > >> I agree Christian's comments, and especially with this request. >> >> A few more points on small matters: >> >> In our source base, C++ comments usually begin with two slashes and a >> space (less than 10% exceptions). >> +//Global Register Names >> +//Address Computation: local variables >> (etc.) > > Fixed. > >> Let's use the term "amd64" only where required; x86_64 is the >> standard now. >> // No amd64 specific initialization > > Fixed. > >> More on #ifdefs: I think there are too many; Chris has pointed out >> the main problem. >> >> It's a judgement call, but here's another example: >> >> +#ifdef _LP64 >> + Register rtmp = r8; >> + Register rthread = r15_thread; >> +#else >> + Register rtmp = rsi; >> + Register rthread = rcx; >> + __ get_thread(rcx); >> + __ save_bcp(); >> +#endif // _LP64 >> >> could just as well be: >> >> + Register rtmp = LP64_ONLY(r8) NOT_LP64(rsi); >> + Register rthread = LP64_ONLY(r15_thread) NOT_LP64(rcx); >> + LP64_ONLY(__ get_thread(rcx)); >> + LP64_ONLY(__ save_bcp()); >> >> Advantages: Fewer lines, less duplication, less chance of merge >> problems. >> Possible objection: Ugly; but only in a different way from the other >> ugly. > > Fixed, but there are some #ifdef's left over. There are some pretty > large code blocks that are conditionally defined. I don't think it > makes sense to enclose every conditionally defined line of code in an > LP64_ONLY or NOT_LP64. At best you save 3 lines of code, but I feel > that a those 3 lines would be less distracting than having 25 > LP64_ONLY's in a row. >> >> However, I admit that is a marginal example. >> >> ? John > > Thanks, > Max Ockner > From david.holmes at oracle.com Thu Mar 5 00:27:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Mar 2015 10:27:54 +1000 Subject: RFR: 8073994: STATIC_ASSERT use of __LINE__ is wrong In-Reply-To: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> References: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> Message-ID: <54F7A30A.9020801@oracle.com> Hi Kim, On 5/03/2015 6:14 AM, Kim Barrett wrote: > Please review this small cleanup of the infrastructure underlying the > STATIC_ASSERT macro. > > I will need a sponsor for this change. > > STATIC_ASSERT is using macro token splicing incorrectly to (attempt > to) produce a unique type name. Rather than fixing the splicing we > note that the unique type name isn't actually needed. > > - If the assertion fails the type name never gets used at all. I can't figure out what this means if cond is false: typedef char STATIC_ASSERT_DUMMY_TYPE[ STATIC_ASSERT_FAILURE< (Cond) >::value ] > - If the assertion passes we're just redefining a typedef name with > the same type, which is permitted (C++03 7.1.3 clause 3). > > So we just pick a dummy type name to always use. Sounds reasonable. David ----- > CR: > https://bugs.openjdk.java.net/browse/JDK-8073994 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8073994/webrev.00 > > Testing: > JPRT > Local testing of assertion failures. > From david.holmes at oracle.com Thu Mar 5 00:49:59 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Mar 2015 10:49:59 +1000 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> <54F44484.3030403@oracle.com> <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> Message-ID: <54F7A837.6070500@oracle.com> On 2/03/2015 9:54 PM, Paul Sandoz wrote: > > On Mar 2, 2015, at 12:07 PM, David Holmes wrote: > >> Hi Paul, >> >> This is more a question for core-libs and the users of this Unsafe API. > > I wanted to check here first because of work done in [1] and because this is where there is most experience with the Unsafe implementation. I don't want to change the semantics of existing Unsafe methods. > > Note that the VarHandle work will expose using release/acquire names, where the former implementation defers to Unsafe.putOrdered*, and the later to relaxed plus explicit load fence. The Unsafe API naming tends to be done by whomever is defining the public API that uses it (eg. Doug Lea for j.u.c). The implementation of the Unsafe API then has to map through to whatever the VM provides. So given there are three layers you either match the first two or the last two but you can rarely make all three the same. So for example, j.u.c.atomic lazySet is defined as providing: *
  • {@code lazySet} has the memory effects of writing (assigning) * a {@code volatile} variable except that it permits reorderings with * subsequent (but not previous) memory actions that do not themselves * impose reordering constraints with ordinary non-{@code volatile} * writes. and is implemented by a call to Unsafe.putOrdered, which in turn is implemented by doing a full volatile write, which is OrderAccess::release_store_fence. The implementation provides a stronger barrier than what is required. Depending on your perspective either putOrdered captures the right "lazySet" semantics but happens to be implemented using stronger ones (and that implementation might be relaxed in the future); or putOrdered is really intended to be release_store_fence (and so could be renamed accordingly) and if you want to implement true lazySet semantics then you have to define a new Unsafe API to capture that. Conversely if you need release_store_fence then you either define an API that always provide it, or use an existing one (in this case it is a normal volatile field write). I'm in the former camp where putOrdered is weaker than a putRelease would be. I think the VarHandle work would be wrong to assume putOrdered must be as strong as it is, and should instead define a stronger Unsafe API. But that is why I think this needs to be discussed with the folks at the front-end API's not the backend ones :) Cheers, David ----- > >> Sometimes the implementation of unsafe doesn't exactly match the API, so we need to check what the intended API semantics are. >> > > I believe things align naming-wise at least from eyeballing C2 code i.e. Unsafe.putOrdered* is a form of release-store like that of OrderAccess::release_store and Unsafe.storeFence is a form of release-fence like that of OrderAccess::release. > > src/share/vm/opto/library_call.cpp: > > bool LibraryCallKit::inline_unsafe_ordered_store(BasicType type) { > ... > insert_mem_bar(Op_MemBarRelease); > insert_mem_bar(Op_MemBarCPUOrder); > // Ensure that the store is atomic for longs: > const bool require_atomic_access = true; > Node* store; > if (type == T_OBJECT) // reference stores need a store barrier. > store = store_oop_to_unknown(control(), base, adr, adr_type, val, type, MemNode::release); > else { > store = store_to_memory(control(), adr, val, type, adr_type, MemNode::release, require_atomic_access); > } > insert_mem_bar(Op_MemBarCPUOrder); > return true; > } > > bool LibraryCallKit::inline_unsafe_fence(vmIntrinsics::ID id) { > // Regardless of form, don't allow previous ld/st to move down, > // then issue acquire, release, or volatile mem_bar. > insert_mem_bar(Op_MemBarCPUOrder); > switch(id) { > case vmIntrinsics::_loadFence: > insert_mem_bar(Op_LoadFence); > return true; > case vmIntrinsics::_storeFence: > insert_mem_bar(Op_StoreFence); > return true; > case vmIntrinsics::_fullFence: > insert_mem_bar(Op_MemBarVolatile); > return true; > default: > fatal_unexpected_iid(id); > return false; > } > } > > > src/cpu/x86/vm/x86_32.ad: > > instruct membar_release() %{ > match(MemBarRelease); > match(StoreFence); > ins_cost(400); > > size(0); > format %{ "MEMBAR-release ! (empty encoding)" %} > ins_encode( ); > ins_pipe(empty); > %} > > ... > > instruct membar_acquire() %{ > match(MemBarAcquire); > match(LoadFence); > ins_cost(400); > > size(0); > format %{ "MEMBAR-acquire ! (empty encoding)" %} > ins_encode(); > ins_pipe(empty); > %} > > ... > > instruct membar_volatile(eFlagsReg cr) %{ > match(MemBarVolatile); > effect(KILL cr); > ins_cost(400); > > format %{ > $$template > if (os::is_MP()) { > $$emit$$"LOCK ADDL [ESP + #0], 0\t! membar_volatile" > } else { > $$emit$$"MEMBAR-volatile ! (empty encoding)" > } > %} > ins_encode %{ > __ membar(Assembler::StoreLoad); > %} > ins_pipe(pipe_slow); > %} > > > Paul. > From max.ockner at oracle.com Thu Mar 5 05:16:54 2015 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 05 Mar 2015 00:16:54 -0500 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F64B22.9040008@oracle.com> References: <54F0AB0B.5090904@oracle.com> <0BAC24A3-40E0-4E34-AA1E-EE9ECAB4A99F@oracle.com> <54F62A1F.4000507@oracle.com> <54F64B22.9040008@oracle.com> Message-ID: <54F7E6C6.4070905@oracle.com> Serguei- I originally tested with JPRT, vm.quick.testlist, and nsk.jvmti.testlist. After making formatting changes, I retested with nsk.jvmti.testlist. Still, just to be safe, I also retested with vm.quick.testlist today. John- The _new operator used registers that weren't available on 64 bits, so the 32 bit version was kept. Thanks, Max On 3/3/2015 7:00 PM, serguei.spitsyn at oracle.com wrote: > Hi Max, > > A minor comment. > The testlist (nsk.jvmti.testlist) looks strange. > I'd expect at least some runtime tests to be run. > > Thanks, > Serguei > > > On 3/3/15 1:39 PM, Max Ockner wrote: >> Hello all, >> I have made all of the changes recommended by Chris and John. I >> realize there are plenty of further cleanups and optimizations that I >> could make, but I think this is nearing a good stopping point for >> now. We can always clean it up more later. What do you think? >> >> new webrev: cr.openjdk.java.net/~coleenp/8013393 >> tested with nsk.jvmti.testlist >> >> On 3/2/2015 4:45 PM, John Rose wrote: >>> On Mar 2, 2015, at 11:46 AM, Christian Thalinger >>> wrote: >>>> That?s quite a large change (I wish we had Crucible or something to >>>> leave inline comments). >>>> >>>> First, you have to keep the oldest copyright year (but maybe that?s >>>> just the diff). >>>> >>>> + #ifdef _LP64 >>>> + void TemplateTable::lconst(int value) { >>>> >>>> I?d prefer to have #ifdef?s inside methods and not around them. >>>> There are a bunch; please change all of them. >> I have moved the #ifdef's to the inside of the function declarations. >> Some of the #ifdefs could be moved far enough in that it made sense >> to replace them with the LP64_ONLY() or NOT_LP64() tools. The >> remaining #ifdef's are there because some large sections of code >> could not be merged, and needed to be kept together. >> >>> I agree Christian's comments, and especially with this request. >>> >>> A few more points on small matters: >>> >>> In our source base, C++ comments usually begin with two slashes and >>> a space (less than 10% exceptions). >>> +//Global Register Names >>> +//Address Computation: local variables >>> (etc.) >> >> Fixed. >> >>> Let's use the term "amd64" only where required; x86_64 is the >>> standard now. >>> // No amd64 specific initialization >> >> Fixed. >> >>> More on #ifdefs: I think there are too many; Chris has pointed out >>> the main problem. >>> >>> It's a judgement call, but here's another example: >>> >>> +#ifdef _LP64 >>> + Register rtmp = r8; >>> + Register rthread = r15_thread; >>> +#else >>> + Register rtmp = rsi; >>> + Register rthread = rcx; >>> + __ get_thread(rcx); >>> + __ save_bcp(); >>> +#endif // _LP64 >>> >>> could just as well be: >>> >>> + Register rtmp = LP64_ONLY(r8) NOT_LP64(rsi); >>> + Register rthread = LP64_ONLY(r15_thread) NOT_LP64(rcx); >>> + LP64_ONLY(__ get_thread(rcx)); >>> + LP64_ONLY(__ save_bcp()); >>> >>> Advantages: Fewer lines, less duplication, less chance of merge >>> problems. >>> Possible objection: Ugly; but only in a different way from the >>> other ugly. >> >> Fixed, but there are some #ifdef's left over. There are some pretty >> large code blocks that are conditionally defined. I don't think it >> makes sense to enclose every conditionally defined line of code in an >> LP64_ONLY or NOT_LP64. At best you save 3 lines of code, but I feel >> that a those 3 lines would be less distracting than having 25 >> LP64_ONLY's in a row. >>> >>> However, I admit that is a marginal example. >>> >>> ? John >> >> Thanks, >> Max Ockner >> > From serguei.spitsyn at oracle.com Thu Mar 5 08:24:18 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 05 Mar 2015 00:24:18 -0800 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F7E6C6.4070905@oracle.com> References: <54F0AB0B.5090904@oracle.com> <0BAC24A3-40E0-4E34-AA1E-EE9ECAB4A99F@oracle.com> <54F62A1F.4000507@oracle.com> <54F64B22.9040008@oracle.com> <54F7E6C6.4070905@oracle.com> Message-ID: <54F812B2.90908@oracle.com> On 3/4/15 9:16 PM, Max Ockner wrote: > Serguei- > I originally tested with JPRT, vm.quick.testlist, and > nsk.jvmti.testlist. After making formatting changes, I retested with > nsk.jvmti.testlist. Still, just to be safe, I also retested with > vm.quick.testlist today. Good. Thanks, Max! Serguei > > John- > The _new operator used registers that weren't available on 64 bits, so > the 32 bit version was kept. > > Thanks, > Max > > On 3/3/2015 7:00 PM, serguei.spitsyn at oracle.com wrote: >> Hi Max, >> >> A minor comment. >> The testlist (nsk.jvmti.testlist) looks strange. >> I'd expect at least some runtime tests to be run. >> >> Thanks, >> Serguei >> >> >> On 3/3/15 1:39 PM, Max Ockner wrote: >>> Hello all, >>> I have made all of the changes recommended by Chris and John. I >>> realize there are plenty of further cleanups and optimizations that >>> I could make, but I think this is nearing a good stopping point for >>> now. We can always clean it up more later. What do you think? >>> >>> new webrev: cr.openjdk.java.net/~coleenp/8013393 >>> tested with nsk.jvmti.testlist >>> >>> On 3/2/2015 4:45 PM, John Rose wrote: >>>> On Mar 2, 2015, at 11:46 AM, Christian Thalinger >>>> wrote: >>>>> That?s quite a large change (I wish we had Crucible or something >>>>> to leave inline comments). >>>>> >>>>> First, you have to keep the oldest copyright year (but maybe >>>>> that?s just the diff). >>>>> >>>>> + #ifdef _LP64 >>>>> + void TemplateTable::lconst(int value) { >>>>> >>>>> I?d prefer to have #ifdef?s inside methods and not around them. >>>>> There are a bunch; please change all of them. >>> I have moved the #ifdef's to the inside of the function >>> declarations. Some of the #ifdefs could be moved far enough in that >>> it made sense to replace them with the LP64_ONLY() or NOT_LP64() >>> tools. The remaining #ifdef's are there because some large sections >>> of code could not be merged, and needed to be kept together. >>> >>>> I agree Christian's comments, and especially with this request. >>>> >>>> A few more points on small matters: >>>> >>>> In our source base, C++ comments usually begin with two slashes and >>>> a space (less than 10% exceptions). >>>> +//Global Register Names >>>> +//Address Computation: local variables >>>> (etc.) >>> >>> Fixed. >>> >>>> Let's use the term "amd64" only where required; x86_64 is the >>>> standard now. >>>> // No amd64 specific initialization >>> >>> Fixed. >>> >>>> More on #ifdefs: I think there are too many; Chris has pointed out >>>> the main problem. >>>> >>>> It's a judgement call, but here's another example: >>>> >>>> +#ifdef _LP64 >>>> + Register rtmp = r8; >>>> + Register rthread = r15_thread; >>>> +#else >>>> + Register rtmp = rsi; >>>> + Register rthread = rcx; >>>> + __ get_thread(rcx); >>>> + __ save_bcp(); >>>> +#endif // _LP64 >>>> >>>> could just as well be: >>>> >>>> + Register rtmp = LP64_ONLY(r8) NOT_LP64(rsi); >>>> + Register rthread = LP64_ONLY(r15_thread) NOT_LP64(rcx); >>>> + LP64_ONLY(__ get_thread(rcx)); >>>> + LP64_ONLY(__ save_bcp()); >>>> >>>> Advantages: Fewer lines, less duplication, less chance of merge >>>> problems. >>>> Possible objection: Ugly; but only in a different way from the >>>> other ugly. >>> >>> Fixed, but there are some #ifdef's left over. There are some pretty >>> large code blocks that are conditionally defined. I don't think it >>> makes sense to enclose every conditionally defined line of code in >>> an LP64_ONLY or NOT_LP64. At best you save 3 lines of code, but I >>> feel that a those 3 lines would be less distracting than having 25 >>> LP64_ONLY's in a row. >>>> >>>> However, I admit that is a marginal example. >>>> >>>> ? John >>> >>> Thanks, >>> Max Ockner >>> >> > From aph at redhat.com Thu Mar 5 09:16:07 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 05 Mar 2015 09:16:07 +0000 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <54F7A837.6070500@oracle.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> <54F44484.3030403@oracle.com> <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> <54F7A837.6070500@oracle.com> Message-ID: <54F81ED7.10407@redhat.com> On 05/03/15 00:49, David Holmes wrote: > On 2/03/2015 9:54 PM, Paul Sandoz wrote: >> >> On Mar 2, 2015, at 12:07 PM, David Holmes wrote: >> >>> Hi Paul, >>> >>> This is more a question for core-libs and the users of this Unsafe API. >> >> I wanted to check here first because of work done in [1] and because this is where there is most experience with the Unsafe implementation. I don't want to change the semantics of existing Unsafe methods. >> >> Note that the VarHandle work will expose using release/acquire names, where the former implementation defers to Unsafe.putOrdered*, and the later to relaxed plus explicit load fence. > > The Unsafe API naming tends to be done by whomever is defining the > public API that uses it (eg. Doug Lea for j.u.c). The implementation of > the Unsafe API then has to map through to whatever the VM provides. So > given there are three layers you either match the first two or the last > two but you can rarely make all three the same. > > So for example, j.u.c.atomic lazySet is defined as providing: > > *
  • {@code lazySet} has the memory effects of writing (assigning) > * a {@code volatile} variable except that it permits reorderings with > * subsequent (but not previous) memory actions that do not themselves > * impose reordering constraints with ordinary non-{@code volatile} > * writes. > > and is implemented by a call to Unsafe.putOrdered, which in turn is > implemented by doing a full volatile write, which is > OrderAccess::release_store_fence. A volatile write is stronger than just a release_store_fence. > The implementation provides a stronger barrier than what is > required. Depending on your perspective either putOrdered captures > the right "lazySet" semantics but happens to be implemented using > stronger ones (and that implementation might be relaxed in the > future); or putOrdered is really intended to be release_store_fence > (and so could be renamed accordingly) and if you want to implement > true lazySet semantics then you have to define a new Unsafe API to > capture that. > Conversely if you need release_store_fence then you either define an > API that always provide it, or use an existing one (in this case it > is a normal volatile field write). Doug sez: << There are three basic strengths of write: Relaxed (normal), releasing, and SC volatile. I got talked into naming the second releasing version "lazySet" which is confusing enough, but compounded by the almost equally odd internal unsafe name "ordered". << These should be less confusing in JDK9 when we provide more uniform enhanced-volatile support. >> Andrew. From goetz.lindenmaier at sap.com Thu Mar 5 10:38:26 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 5 Mar 2015 10:38:26 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> <63935ED2-F85A-4EBE-8F42-C742BF18B873@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9C1CE@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CFA45F8@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFA78F0@DEWDFEMB12A.global.corp.sap> Hi Volker, thanks for looking at this. > - fix Copyright date in: ... Done. > src/share/vm/gc_implementation/g1/ptrQueue.cpp ... Removed. > Wouldn't it be better to do the check ... right before the definition of ''cur_chunk_index' Yes, this would cover both cases. In general, I tried not to do changes affecting the scope of an assertion, but here it's quite obvious as the value is used the same way. I moved the test up there. > src/share/vm/memory/blockOffsetTable.cpp Simplified. New webrev: http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.06/ Best regards, Goetz. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 4. M?rz 2015 17:20 To: Lindenmaier, Goetz Cc: Kim Barrett; hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. Hi Goetz, Kim, thanks a lot for working this out so far. I've looked at the change myself now and I thinks it is in a good state. I just found some minor issues: - fix Copyright date in: src/share/vm/gc_implementation/g1/concurrentMark.hpp src/share/vm/memory/blockOffsetTable.cpp - not sure why we need the following in: src/share/vm/gc_implementation/g1/ptrQueue.cpp 196 _index = _sz; 197 assert(_index <= _sz, "Invariant."); ..until we are really, really paranoid that the assignment "_index = _sz" can fail :) - in: src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp we do the check: 245 assert(start_chunk_index >= lowest_non_clean_base_chunk_index && // Check underflow. only in one branch of the following if/else, but in the other branch we use 'cur_chunk_index' without check: 264 assert(lowest_non_clean[cur_chunk_index] == NULL, "Write once : value should be stable hereafter"); 265 jbyte* first_card_of_cur_chunk = byte_for(chunk_mr.start()); 266 lowest_non_clean[cur_chunk_index] = first_card_of_cur_chunk; Wouldn't it be better to do the check for 'start_chunk_index >= lowest_non_clean_base_chunk_index' right before the definition of 'cur_chunk_index' like so: 198 uintptr_t start_chunk_index = addr_to_chunk_index(chunk_mr.start()); assert(start_chunk_index >= lowest_non_clean_base_chunk_index, "Bounds error."); // Check underflow. 199 uintptr_t cur_chunk_index = start_chunk_index - lowest_non_clean_base_chunk_index; - the change in: src/share/vm/memory/blockOffsetTable.cpp 795 size_t next = _next_offset_index; 796 return next == 0 ? 0 : next - 1; could be simplified into just one line: 796 return _next_offset_index == 0 ? 0 : _next_offset_index - 1; Thanks, Volker On Wed, Mar 4, 2015 at 9:10 AM, Lindenmaier, Goetz wrote: > Thanks a lot for looking into this! > > Best regards, > Goetz. > > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Dienstag, 3. M?rz 2015 22:30 > To: Lindenmaier, Goetz > Cc: hotspot-dev Source Developers > Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. > > On Mar 3, 2015, at 9:46 AM, Lindenmaier, Goetz wrote: >> >> Hi Kim, >> >> as I understand the code, > 0 should hold for both tests. >> But I think what is really meant by the check, protecting against underflow, >> should be checked in decrement(): >> >> --- //bas2/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 >> +++ /sapmnt/home/d045726/src3/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 >> @@ -67,6 +67,9 @@ >> } >> >> void decrement(const uint length_to_remove, const size_t capacity_to_remove) { >> +#ifdef HEAP_REGION_SET_FORCE_VERIFY >> + guarantee(length_to_remove <= _length && capacity_to_remove <= _capacity, "underflow"); >> +#endif >> _length -= length_to_remove; >> _capacity -= capacity_to_remove; >> } >> >> Or by casting _length and _capacity to singed types in the guarantee in verify(), which is >> quite ugly. But I think it would work fine by the values one can expect here. >> >> I changed verify() to check for '>', but didn't add above guarantee, I think that again >> is out of the scope of this change. >> http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.05/ >> >> I ran a row of tests with the adapted assertion, and will push it into our nightbuild. > > I think you are right that the check is really for underflow, and that should be in decrement() > as you suggest. And I'm fine with the way you've left it. Anything further can be a later cleanup > if desired. > > So I'm done reviewing. Looks good to me. > From volker.simonis at gmail.com Thu Mar 5 10:57:30 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 5 Mar 2015 11:57:30 +0100 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFA78F0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> <63935ED2-F85A-4EBE-8F42-C742BF18B873@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9C1CE@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CFA45F8@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CFA78F0@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, thanks for doing these last changes. >From my side, the change is now ready for push. Regards, Volker On Thu, Mar 5, 2015 at 11:38 AM, Lindenmaier, Goetz wrote: > Hi Volker, > > thanks for looking at this. > >> - fix Copyright date in: ... > Done. > >> src/share/vm/gc_implementation/g1/ptrQueue.cpp ... > Removed. > >> Wouldn't it be better to do the check ... right before the definition of ''cur_chunk_index' > Yes, this would cover both cases. In general, I tried not to do changes affecting > the scope of an assertion, but here it's quite obvious as the value is used the > same way. > I moved the test up there. > >> src/share/vm/memory/blockOffsetTable.cpp > Simplified. > > New webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.06/ > > Best regards, > Goetz. > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Mittwoch, 4. M?rz 2015 17:20 > To: Lindenmaier, Goetz > Cc: Kim Barrett; hotspot-dev Source Developers > Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. > > Hi Goetz, Kim, > > thanks a lot for working this out so far. > I've looked at the change myself now and I thinks it is in a good state. > I just found some minor issues: > > - fix Copyright date in: > src/share/vm/gc_implementation/g1/concurrentMark.hpp > src/share/vm/memory/blockOffsetTable.cpp > > - not sure why we need the following in: > src/share/vm/gc_implementation/g1/ptrQueue.cpp > > 196 _index = _sz; > 197 assert(_index <= _sz, "Invariant."); > > ..until we are really, really paranoid that the assignment "_index = > _sz" can fail :) > > > - in: > src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp > > we do the check: > > 245 assert(start_chunk_index >= > lowest_non_clean_base_chunk_index && // Check underflow. > > only in one branch of the following if/else, but in the other branch > we use 'cur_chunk_index' without check: > > 264 assert(lowest_non_clean[cur_chunk_index] == NULL, "Write once > : value should be stable hereafter"); > 265 jbyte* first_card_of_cur_chunk = byte_for(chunk_mr.start()); > 266 lowest_non_clean[cur_chunk_index] = first_card_of_cur_chunk; > > Wouldn't it be better to do the check for 'start_chunk_index >= > lowest_non_clean_base_chunk_index' right before the definition of > 'cur_chunk_index' like so: > > 198 uintptr_t start_chunk_index = addr_to_chunk_index(chunk_mr.start()); > assert(start_chunk_index >= lowest_non_clean_base_chunk_index, > "Bounds error."); // Check underflow. > 199 uintptr_t cur_chunk_index = start_chunk_index - > lowest_non_clean_base_chunk_index; > > > - the change in: > src/share/vm/memory/blockOffsetTable.cpp > > 795 size_t next = _next_offset_index; > 796 return next == 0 ? 0 : next - 1; > > could be simplified into just one line: > > 796 return _next_offset_index == 0 ? 0 : _next_offset_index - 1; > > Thanks, > Volker > > > On Wed, Mar 4, 2015 at 9:10 AM, Lindenmaier, Goetz > wrote: >> Thanks a lot for looking into this! >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Kim Barrett [mailto:kim.barrett at oracle.com] >> Sent: Dienstag, 3. M?rz 2015 22:30 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev Source Developers >> Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. >> >> On Mar 3, 2015, at 9:46 AM, Lindenmaier, Goetz wrote: >>> >>> Hi Kim, >>> >>> as I understand the code, > 0 should hold for both tests. >>> But I think what is really meant by the check, protecting against underflow, >>> should be checked in decrement(): >>> >>> --- //bas2/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 >>> +++ /sapmnt/home/d045726/src3/sapjvm/dev/6/hotspot/src/share/vm/gc_implementation/g1/heapRegionSet.hpp 2015-03-03 09:00:44.000000000 0100 >>> @@ -67,6 +67,9 @@ >>> } >>> >>> void decrement(const uint length_to_remove, const size_t capacity_to_remove) { >>> +#ifdef HEAP_REGION_SET_FORCE_VERIFY >>> + guarantee(length_to_remove <= _length && capacity_to_remove <= _capacity, "underflow"); >>> +#endif >>> _length -= length_to_remove; >>> _capacity -= capacity_to_remove; >>> } >>> >>> Or by casting _length and _capacity to singed types in the guarantee in verify(), which is >>> quite ugly. But I think it would work fine by the values one can expect here. >>> >>> I changed verify() to check for '>', but didn't add above guarantee, I think that again >>> is out of the scope of this change. >>> http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.05/ >>> >>> I ran a row of tests with the adapted assertion, and will push it into our nightbuild. >> >> I think you are right that the check is really for underflow, and that should be in decrement() >> as you suggest. And I'm fine with the way you've left it. Anything further can be a later cleanup >> if desired. >> >> So I'm done reviewing. Looks good to me. >> From david.holmes at oracle.com Thu Mar 5 11:37:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Mar 2015 21:37:52 +1000 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <54F81ED7.10407@redhat.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> <54F44484.3030403@oracle.com> <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> <54F7A837.6070500@oracle.com> <54F81ED7.10407@redhat.com> Message-ID: <54F84010.1080804@oracle.com> On 5/03/2015 7:16 PM, Andrew Haley wrote: > On 05/03/15 00:49, David Holmes wrote: >> On 2/03/2015 9:54 PM, Paul Sandoz wrote: >>> >>> On Mar 2, 2015, at 12:07 PM, David Holmes wrote: >>> >>>> Hi Paul, >>>> >>>> This is more a question for core-libs and the users of this Unsafe API. >>> >>> I wanted to check here first because of work done in [1] and because this is where there is most experience with the Unsafe implementation. I don't want to change the semantics of existing Unsafe methods. >>> >>> Note that the VarHandle work will expose using release/acquire names, where the former implementation defers to Unsafe.putOrdered*, and the later to relaxed plus explicit load fence. >> >> The Unsafe API naming tends to be done by whomever is defining the >> public API that uses it (eg. Doug Lea for j.u.c). The implementation of >> the Unsafe API then has to map through to whatever the VM provides. So >> given there are three layers you either match the first two or the last >> two but you can rarely make all three the same. >> >> So for example, j.u.c.atomic lazySet is defined as providing: >> >> *
  • {@code lazySet} has the memory effects of writing (assigning) >> * a {@code volatile} variable except that it permits reorderings with >> * subsequent (but not previous) memory actions that do not themselves >> * impose reordering constraints with ordinary non-{@code volatile} >> * writes. >> >> and is implemented by a call to Unsafe.putOrdered, which in turn is >> implemented by doing a full volatile write, which is >> OrderAccess::release_store_fence. > > A volatile write is stronger than just a release_store_fence. release_store_fence is: loadstore|storestore loadload|loadstore|storestore|storeload what do you think is missing? >> The implementation provides a stronger barrier than what is >> required. Depending on your perspective either putOrdered captures >> the right "lazySet" semantics but happens to be implemented using >> stronger ones (and that implementation might be relaxed in the >> future); or putOrdered is really intended to be release_store_fence >> (and so could be renamed accordingly) and if you want to implement >> true lazySet semantics then you have to define a new Unsafe API to >> capture that. > >> Conversely if you need release_store_fence then you either define an >> API that always provide it, or use an existing one (in this case it >> is a normal volatile field write). > > Doug sez: > > << There are three basic strengths of write: Relaxed (normal), > releasing, and SC volatile. I got talked into naming the second > releasing version "lazySet" which is confusing enough, but compounded > by the almost equally odd internal unsafe name "ordered". > > << These should be less confusing in JDK9 when we provide more uniform > enhanced-volatile support. >> Then there may indeed be hope for reconciling the different names. Thanks, David > Andrew. > From aph at redhat.com Thu Mar 5 11:49:40 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 05 Mar 2015 11:49:40 +0000 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <54F84010.1080804@oracle.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> <54F44484.3030403@oracle.com> <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> <54F7A837.6070500@oracle.com> <54F81ED7.10407@redhat.com> <54F84010.1080804@oracle.com> Message-ID: <54F842D4.3020708@redhat.com> On 05/03/15 11:37, David Holmes wrote: > On 5/03/2015 7:16 PM, Andrew Haley wrote: >> On 05/03/15 00:49, David Holmes wrote: >>> On 2/03/2015 9:54 PM, Paul Sandoz wrote: >>>> >>>> On Mar 2, 2015, at 12:07 PM, David Holmes wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> This is more a question for core-libs and the users of this Unsafe API. >>>> >>>> I wanted to check here first because of work done in [1] and because this is where there is most experience with the Unsafe implementation. I don't want to change the semantics of existing Unsafe methods. >>>> >>>> Note that the VarHandle work will expose using release/acquire names, where the former implementation defers to Unsafe.putOrdered*, and the later to relaxed plus explicit load fence. >>> >>> The Unsafe API naming tends to be done by whomever is defining the >>> public API that uses it (eg. Doug Lea for j.u.c). The implementation of >>> the Unsafe API then has to map through to whatever the VM provides. So >>> given there are three layers you either match the first two or the last >>> two but you can rarely make all three the same. >>> >>> So for example, j.u.c.atomic lazySet is defined as providing: >>> >>> *
  • {@code lazySet} has the memory effects of writing (assigning) >>> * a {@code volatile} variable except that it permits reorderings with >>> * subsequent (but not previous) memory actions that do not themselves >>> * impose reordering constraints with ordinary non-{@code volatile} >>> * writes. >>> >>> and is implemented by a call to Unsafe.putOrdered, which in turn is >>> implemented by doing a full volatile write, which is >>> OrderAccess::release_store_fence. >> >> A volatile write is stronger than just a release_store_fence. > > release_store_fence is: > > loadstore|storestore > > loadload|loadstore|storestore|storeload > > what do you think is missing? My apologies. I'd forgotten that release_store_fence is rather confusingly named: it's not a release-store fence, it's a release store followed by a full fence. It's clear from Doug's comment that this implementation of lazySet is too strong: it was intended to be a releasing store. Andrew. From sgehwolf at redhat.com Thu Mar 5 16:27:08 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 05 Mar 2015 17:27:08 +0100 Subject: RFR(S) 8074312: Enable hotspot builds on 4.x Linux kernels Message-ID: <1425572828.3401.14.camel@redhat.com> Hi, Could someone please review the following one-liner to the hotspot build files. This prevents someone from building on 4.x Linux kernels such as F22, which will become available in May 2015[1]. Currently, a JDK 9 build fails for me with: >&2 echo "*** This OS is not supported:" `uname -a`; exit 1; ++ uname -a + echo '*** This OS is not supported:' Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 '#1' SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux *** This OS is not supported: Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 #1 SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux + exit 1 The fix is to add 4 to the list of Linux kernels, similar to what was done for 3.x kernels in JDK-7072341. Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/webrev.00/ I'd also please need a sponsor for this change. Thanks, Severin [1] http://fedoraproject.org/wiki/Releases/22/Schedule From kim.barrett at oracle.com Thu Mar 5 16:55:20 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 5 Mar 2015 11:55:20 -0500 Subject: RFR: 8073994: STATIC_ASSERT use of __LINE__ is wrong In-Reply-To: <54F7A30A.9020801@oracle.com> References: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> <54F7A30A.9020801@oracle.com> Message-ID: <65C759C1-79B1-4DD0-B33F-F9EBB9B496BE@oracle.com> On Mar 4, 2015, at 7:27 PM, David Holmes wrote: > > Hi Kim, > > On 5/03/2015 6:14 AM, Kim Barrett wrote: >> Please review this small cleanup of the infrastructure underlying the >> STATIC_ASSERT macro. >> >> I will need a sponsor for this change. >> >> STATIC_ASSERT is using macro token splicing incorrectly to (attempt >> to) produce a unique type name. Rather than fixing the splicing we >> note that the unique type name isn't actually needed. >> >> - If the assertion fails the type name never gets used at all. > > I can't figure out what this means if cond is false: > > typedef char STATIC_ASSERT_DUMMY_TYPE[ STATIC_ASSERT_FAILURE< (Cond) >::value ] We get a compiler error for attempting to access the non-existent STATIC_ASSERT_FAILURE::value member before the compiler has any chance of complaining about a possible redefinition of STATIC_ASSERT_DUMMY_TYPE. From kim.barrett at oracle.com Thu Mar 5 18:52:14 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 5 Mar 2015 13:52:14 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFA78F0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BDC1@DEWDFEMB12A.global.corp.sap> <5F22DB8E-65EE-4F1C-8994-05A4A15CDBD0@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9BFED@DEWDFEMB12A.global.corp.sap> <63935ED2-F85A-4EBE-8F42-C742BF18B873@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF9C1CE@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CFA45F8@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CFA78F0@DEWDFEMB12A.global.corp.sap> Message-ID: On Mar 5, 2015, at 5:38 AM, Lindenmaier, Goetz wrote: > > New webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.06/ Still looks good. From david.holmes at oracle.com Thu Mar 5 21:00:22 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Mar 2015 07:00:22 +1000 Subject: RFR(S) 8074312: Enable hotspot builds on 4.x Linux kernels In-Reply-To: <1425572828.3401.14.camel@redhat.com> References: <1425572828.3401.14.camel@redhat.com> Message-ID: <54F8C3E6.8010808@oracle.com> Hi Severin, On 6/03/2015 2:27 AM, Severin Gehwolf wrote: > Hi, > > Could someone please review the following one-liner to the hotspot build > files. This prevents someone from building on 4.x Linux kernels such as > F22, which will become available in May 2015[1]. > > Currently, a JDK 9 build fails for me with: >> &2 echo "*** This OS is not supported:" `uname -a`; exit 1; > ++ uname -a > + echo '*** This OS is not supported:' Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 '#1' SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > *** This OS is not supported: Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 #1 SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > + exit 1 > > The fix is to add 4 to the list of Linux kernels, similar to what was > done for 3.x kernels in JDK-7072341. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/webrev.00/ > > I'd also please need a sponsor for this change. The whole purpose of those version checks is to ensure we know there is a reasonable level of support for a platform before we enable it - anyone can make the change locally to try for themselves (and deal with the consequences). Otherwise we may as well just remove the version checks. So I can sponsor this change for you assuming that everything does indeed build and run fine on the Linux 4 kernel. Also it seems Fedora22 will have gcc 5 so do we need build changes to support that as well? Are there any major new or changed features in the linux 4 kernel that may impact the JVM? Thanks, David > Thanks, > Severin > > [1] http://fedoraproject.org/wiki/Releases/22/Schedule > From david.holmes at oracle.com Thu Mar 5 21:01:22 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Mar 2015 07:01:22 +1000 Subject: RFR: 8073994: STATIC_ASSERT use of __LINE__ is wrong In-Reply-To: <65C759C1-79B1-4DD0-B33F-F9EBB9B496BE@oracle.com> References: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> <54F7A30A.9020801@oracle.com> <65C759C1-79B1-4DD0-B33F-F9EBB9B496BE@oracle.com> Message-ID: <54F8C422.2040006@oracle.com> On 6/03/2015 2:55 AM, Kim Barrett wrote: > On Mar 4, 2015, at 7:27 PM, David Holmes wrote: >> >> Hi Kim, >> >> On 5/03/2015 6:14 AM, Kim Barrett wrote: >>> Please review this small cleanup of the infrastructure underlying the >>> STATIC_ASSERT macro. >>> >>> I will need a sponsor for this change. >>> >>> STATIC_ASSERT is using macro token splicing incorrectly to (attempt >>> to) produce a unique type name. Rather than fixing the splicing we >>> note that the unique type name isn't actually needed. >>> >>> - If the assertion fails the type name never gets used at all. >> >> I can't figure out what this means if cond is false: >> >> typedef char STATIC_ASSERT_DUMMY_TYPE[ STATIC_ASSERT_FAILURE< (Cond) >::value ] > > We get a compiler error for attempting to access the non-existent > STATIC_ASSERT_FAILURE::value > member before the compiler has any chance of complaining about a possible redefinition > of STATIC_ASSERT_DUMMY_TYPE. > Doh! Hence why it is a compile-time checking idiom. Thanks, David From goetz.lindenmaier at sap.com Fri Mar 6 09:36:54 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Mar 2015 09:36:54 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <54E4BDBD.6000206@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <54E4BDBD.6000206@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFA7AED@DEWDFEMB12A.global.corp.sap> Hi Jesper, You offered to sponsor this change. I think it's ok to be pushed. Kim and Volker are ok with it, too, and I ran it through our nightly tests. These cover quite a range of compilers and platforms. This is the final webrev: http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.06/ I would appreciate a lot if you could sponsor this! Best regards, Goetz. -----Original Message----- From: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com] Sent: Mittwoch, 18. Februar 2015 17:29 To: Lindenmaier, Goetz; Kim Barrett Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. Hi Goetz, Lindenmaier, Goetz skrev den 18/2/15 11:53: > Hi Kim, > > thanks for looking at this! > >> As Jesper noted, there are cases where, yes, the >> warning is correct today, but future maintenance might change that. > You mean, somebody could change the type to signed, and then again > the assertion makes sense? > I thought about that. One could add some function > is_unsigned(uint64_t x) { return true; } > is_unsigned(int64_t x) { return false; } > in the assertions. It might even be possible to get a warning if the > second is left out, so that it's a compile time error (-Werror). > But it seemed a bit overengineered to me, as there's sure lots of > cases where changing signedness would causes similar problems > with current code, but there is no assertion to catch it. This approach seems, as you say, over engineered. If someone wants to change the type of a variable all usages of that variable should be examined anyway. There are several things that can go wrong with a change like that. Things the developers never even thought about since they had a reason to choose the type they used in the first place. Anyway, I think the latest webrev looks good. I can sponsor the change if Kim agrees that this is an OK change to do. Please note that you need a Reviewer as well. Both me and Kim are committers only. /Jesper > >> This warning can also lead to serious ugliness with generic code >> (e.g. templates), where only some values of a type parameter trigger >> warnings. > There is currently no such code in the VM. We could again remove > the flag if such a case comes up. Until then, the warning will avoid > future errors. And maybe, until then, openJDK uses a compiler with > that issue fixed. > Should I add a respective comment in the makefile? > > I fixed last_active_index() as you proposed. Yes, that's better. > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.02/ > > Best regards, > Goetz. > > > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Mittwoch, 18. Februar 2015 00:28 > To: Lindenmaier, Goetz > Cc: hotspot-dev Source Developers > Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. > > On Feb 17, 2015, at 6:42 AM, Lindenmaier, Goetz wrote: >> >> We fixed all the warnings showing with -Wtype-limits and gcc in our VM. >> I would like to contribute these small changes. >> >> This warning detects unnecessary compares for >= 0 of unsigned values. >> >> At least one warning unveils a real bug. In memory/blockOffsetTable.cpp, >> BlockOffsetArrayContigSpace::last_active_index(), the compare to >=0 >> tries to prevent an underflow, but the value is unsigned. >> >> Further useless compares in real code are in os_linux.cpp, >> opto/graphKit.cpp, prims/jvmtiRedefineClasses.cpp >> >> In some places debug code with constant debug flags caused >> warnings in the opt build (g1/concurrentMark.cpp, classfile/systemDictionary.cpp) >> >> The remaining warnings occur in asserts, which is also the biggest part. >> >> The change also removes an empty #ifdef ASSERT . >> >> Please review this change. I please need a sponsor. >> https://bugs.openjdk.java.net/browse/JDK-8073315 >> http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.01/ >> >> I tested this on linuxx86_64 with gcc 4.1.2, 4.3 and 4.8. Further I ran the patch >> with our nightly builds and tests of jdk9,see >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html > > -Wtype-limits is one of those somewhat questionable warnings that are > enabled by -Wextra. As Jesper noted, there are cases where, yes, the > warning is correct today, but future maintenance might change that. > And the information that one needs in order to make that determination > might be far away from the expression generating the warning. > > This warning can also lead to serious ugliness with generic code > (e.g. templates), where only some values of a type parameter trigger > warnings. I've seen real code that used template metapogramming to > select different expressions in order to dodge this specific warning. > > In other words, while this warning does sometimes find real bugs, it > also tends to generate a lot of false positives. Because of that, I'm > not sure it's actually a good idea to enable it. > > For the specific bug mentioned, I would like to just see that fixed, > but not in the way that was done in the webrev, e.g. > > incorrect old: > 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { > 795 size_t result = _next_offset_index - 1; > 796 return result >= 0 ? result : 0; > 797 }mem > > webrev: > 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { > 795 size_t result = _next_offset_index - 1; > 796 return ((intptr_t)result) >= 0 ? result : 0; > 797 } > > better: > size_t BlockOffsetArrayContigSpace::last_active_index() const { > size_t next = _next_offset_index; > return next == 0 ? 0 : next - 1; > } > > Eschew unnecessary casts! > From jesper.wilhelmsson at oracle.com Fri Mar 6 10:52:45 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 06 Mar 2015 11:52:45 +0100 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFA7AED@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <54E4BDBD.6000206@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFA7AED@DEWDFEMB12A.global.corp.sap> Message-ID: <54F986FD.7080600@oracle.com> Yep, I'll get right on it. It seems to be based on hs-comp(?) Thanks for fixing this!! /Jesper Lindenmaier, Goetz skrev den 6/3/15 10:36: > Hi Jesper, > > You offered to sponsor this change. I think it's ok to be pushed. > Kim and Volker are ok with it, too, and I ran it through our nightly tests. > These cover quite a range of compilers and platforms. > > This is the final webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.06/ > > I would appreciate a lot if you could sponsor this! > > Best regards, > Goetz. > > -----Original Message----- > From: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com] > Sent: Mittwoch, 18. Februar 2015 17:29 > To: Lindenmaier, Goetz; Kim Barrett > Cc: hotspot-dev Source Developers > Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. > > Hi Goetz, > > Lindenmaier, Goetz skrev den 18/2/15 11:53: >> Hi Kim, >> >> thanks for looking at this! >> >>> As Jesper noted, there are cases where, yes, the >>> warning is correct today, but future maintenance might change that. >> You mean, somebody could change the type to signed, and then again >> the assertion makes sense? >> I thought about that. One could add some function >> is_unsigned(uint64_t x) { return true; } >> is_unsigned(int64_t x) { return false; } >> in the assertions. It might even be possible to get a warning if the >> second is left out, so that it's a compile time error (-Werror). >> But it seemed a bit overengineered to me, as there's sure lots of >> cases where changing signedness would causes similar problems >> with current code, but there is no assertion to catch it. > > This approach seems, as you say, over engineered. If someone wants to change the > type of a variable all usages of that variable should be examined anyway. There > are several things that can go wrong with a change like that. Things the > developers never even thought about since they had a reason to choose the type > they used in the first place. > > Anyway, I think the latest webrev looks good. I can sponsor the change if Kim > agrees that this is an OK change to do. Please note that you need a Reviewer as > well. Both me and Kim are committers only. > /Jesper > >> >>> This warning can also lead to serious ugliness with generic code >>> (e.g. templates), where only some values of a type parameter trigger >>> warnings. >> There is currently no such code in the VM. We could again remove >> the flag if such a case comes up. Until then, the warning will avoid >> future errors. And maybe, until then, openJDK uses a compiler with >> that issue fixed. >> Should I add a respective comment in the makefile? >> >> I fixed last_active_index() as you proposed. Yes, that's better. >> http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.02/ >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Kim Barrett [mailto:kim.barrett at oracle.com] >> Sent: Mittwoch, 18. Februar 2015 00:28 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev Source Developers >> Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. >> >> On Feb 17, 2015, at 6:42 AM, Lindenmaier, Goetz wrote: >>> >>> We fixed all the warnings showing with -Wtype-limits and gcc in our VM. >>> I would like to contribute these small changes. >>> >>> This warning detects unnecessary compares for >= 0 of unsigned values. >>> >>> At least one warning unveils a real bug. In memory/blockOffsetTable.cpp, >>> BlockOffsetArrayContigSpace::last_active_index(), the compare to >=0 >>> tries to prevent an underflow, but the value is unsigned. >>> >>> Further useless compares in real code are in os_linux.cpp, >>> opto/graphKit.cpp, prims/jvmtiRedefineClasses.cpp >>> >>> In some places debug code with constant debug flags caused >>> warnings in the opt build (g1/concurrentMark.cpp, classfile/systemDictionary.cpp) >>> >>> The remaining warnings occur in asserts, which is also the biggest part. >>> >>> The change also removes an empty #ifdef ASSERT . >>> >>> Please review this change. I please need a sponsor. >>> https://bugs.openjdk.java.net/browse/JDK-8073315 >>> http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.01/ >>> >>> I tested this on linuxx86_64 with gcc 4.1.2, 4.3 and 4.8. Further I ran the patch >>> with our nightly builds and tests of jdk9,see >>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >> >> -Wtype-limits is one of those somewhat questionable warnings that are >> enabled by -Wextra. As Jesper noted, there are cases where, yes, the >> warning is correct today, but future maintenance might change that. >> And the information that one needs in order to make that determination >> might be far away from the expression generating the warning. >> >> This warning can also lead to serious ugliness with generic code >> (e.g. templates), where only some values of a type parameter trigger >> warnings. I've seen real code that used template metapogramming to >> select different expressions in order to dodge this specific warning. >> >> In other words, while this warning does sometimes find real bugs, it >> also tends to generate a lot of false positives. Because of that, I'm >> not sure it's actually a good idea to enable it. >> >> For the specific bug mentioned, I would like to just see that fixed, >> but not in the way that was done in the webrev, e.g. >> >> incorrect old: >> 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { >> 795 size_t result = _next_offset_index - 1; >> 796 return result >= 0 ? result : 0; >> 797 }mem >> >> webrev: >> 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { >> 795 size_t result = _next_offset_index - 1; >> 796 return ((intptr_t)result) >= 0 ? result : 0; >> 797 } >> >> better: >> size_t BlockOffsetArrayContigSpace::last_active_index() const { >> size_t next = _next_offset_index; >> return next == 0 ? 0 : next - 1; >> } >> >> Eschew unnecessary casts! >> From erik.joelsson at oracle.com Mon Mar 9 11:16:55 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 09 Mar 2015 12:16:55 +0100 Subject: RFR: JDK-8073021: add native code coverage target into makefiles Message-ID: <54FD8127.3040404@oracle.com> Hello, Please review this patch. A new configure parameter --enable-native-coverage is introduced. Setting it only works when using gcc, for now. It adds '-fprofile-arcs -ftest-coverage -fno-inline' to compiler flags and '-fprofile-arcs' to linker flags, for both jdk and hotspot native libraries (but not for native test libraries). Setting this causes gcc to generate code coverage instrumentation into the binaries as well as generating a .gcno file for each object file created. The gcno files are needed for converting gathered coverage data into a comprehensible report. When native coverage is active, a new image containing the .gcno files is created by the images target. Bug: https://bugs.openjdk.java.net/browse/JDK-8073021 Webrev: http://cr.openjdk.java.net/~erikj/8073021/webrev.root.01/ /Erik From magnus.ihse.bursie at oracle.com Mon Mar 9 11:31:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 09 Mar 2015 12:31:19 +0100 Subject: RFR: JDK-8073021: add native code coverage target into makefiles In-Reply-To: <54FD8127.3040404@oracle.com> References: <54FD8127.3040404@oracle.com> Message-ID: <54FD8487.9040006@oracle.com> On 2015-03-09 12:16, Erik Joelsson wrote: > Hello, > > Please review this patch. A new configure parameter > --enable-native-coverage is introduced. Setting it only works when > using gcc, for now. It adds '-fprofile-arcs -ftest-coverage > -fno-inline' to compiler flags and '-fprofile-arcs' to linker flags, > for both jdk and hotspot native libraries (but not for native test > libraries). Setting this causes gcc to generate code coverage > instrumentation into the binaries as well as generating a .gcno file > for each object file created. The gcno files are needed for converting > gathered coverage data into a comprehensible report. When native > coverage is active, a new image containing the .gcno files is created > by the images target. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073021 > Webrev: http://cr.openjdk.java.net/~erikj/8073021/webrev.root.01/ Looks good to me. /Magnus From igor.ignatyev at oracle.com Mon Mar 9 12:03:40 2015 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Mon, 09 Mar 2015 15:03:40 +0300 Subject: =?utf-8?B?UmU6IFJGUjogSkRLLTgwNzMwMjE6IGFkZCBuYXRpdmUgY29kZSBjb3ZlcmFnZSB0?= =?utf-8?B?YXJnZXQgaW50byBtYWtlZmlsZXM=?= Message-ID: <201503091203.t29C3qF5017905@aserv0122.oracle.com> Look good to me. -- II ----- Reply message ----- From: "Magnus Ihse Bursie" To: "Erik Joelsson" , "build-dev" , "hotspot-dev developers" Subject: RFR: JDK-8073021: add native code coverage target into makefiles Date: Mon, Mar 9, 2015 14:31 On 2015-03-09 12:16, Erik Joelsson wrote: > Hello, > > Please review this patch. A new configure parameter > --enable-native-coverage is introduced. Setting it only works when > using gcc, for now. It adds '-fprofile-arcs -ftest-coverage > -fno-inline' to compiler flags and '-fprofile-arcs' to linker flags, > for both jdk and hotspot native libraries (but not for native test > libraries). Setting this causes gcc to generate code coverage > instrumentation into the binaries as well as generating a .gcno file > for each object file created. The gcno files are needed for converting > gathered coverage data into a comprehensible report. When native > coverage is active, a new image containing the .gcno files is created > by the images target. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073021 > Webrev: http://cr.openjdk.java.net/~erikj/8073021/webrev.root.01/ Looks good to me. /Magnus From sgehwolf at redhat.com Mon Mar 9 12:29:34 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 09 Mar 2015 13:29:34 +0100 Subject: RFR(S) 8074312: Enable hotspot builds on 4.x Linux kernels In-Reply-To: <54F8C3E6.8010808@oracle.com> References: <1425572828.3401.14.camel@redhat.com> <54F8C3E6.8010808@oracle.com> Message-ID: <1425904174.3466.38.camel@redhat.com> Hi David, Thanks for getting back to me so quickly! On Fri, 2015-03-06 at 07:00 +1000, David Holmes wrote: > Hi Severin, > > On 6/03/2015 2:27 AM, Severin Gehwolf wrote: > > Hi, > > > > Could someone please review the following one-liner to the hotspot build > > files. This prevents someone from building on 4.x Linux kernels such as > > F22, which will become available in May 2015[1]. > > > > Currently, a JDK 9 build fails for me with: > >> &2 echo "*** This OS is not supported:" `uname -a`; exit 1; > > ++ uname -a > > + echo '*** This OS is not supported:' Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 '#1' SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > *** This OS is not supported: Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 #1 SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > + exit 1 > > > > The fix is to add 4 to the list of Linux kernels, similar to what was > > done for 3.x kernels in JDK-7072341. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/webrev.00/ > > > > I'd also please need a sponsor for this change. > > The whole purpose of those version checks is to ensure we know there is > a reasonable level of support for a platform before we enable it - > anyone can make the change locally to try for themselves (and deal with > the consequences). Otherwise we may as well just remove the version checks. OK. Is there some form of definition for "reasonable level of support"? Is being able to build hotspot and being able to run simple Java programs enough? For the time being I'm fine with keeping this patch local, fwiw. > So I can sponsor this change for you assuming that everything does > indeed build and run fine on the Linux 4 kernel. I can build JDK 8 fine on a F22 pre-release (x86_64): $ hg paths default = http://hg.openjdk.java.net/jdk8u/jdk8u $ hg tip changeset: 1284:e532f3672f63 tag: tip user: katleman date: Wed Feb 25 12:59:47 2015 -0800 summary: Added tag jdk8u60-b04 for changeset d8d408861c20 $ ./build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-sgeholf_2015_03_09_12_00-b00) OpenJDK 64-Bit Server VM (build 25.60-b05, mixed mode) $ cat /etc/fedora-release Fedora release 22 (Twenty Two) $ gcc --version gcc (GCC) 5.0.0 20150226 (Red Hat 5.0.0-0.17) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Things get trickier with JDK 9. However, I don't think they're linux kernel version related, but rather GCC 5 related. > Also it seems Fedora22 will have gcc 5 so do we need build changes to > support that as well? Very likely. At this point I'm still investigating what's necessary to build JDK 9 on F22. While JDK 8 builds fine with this patch, JDK 9 has more failures which I'm currently looking into too. > Are there any major new or changed features in the linux 4 kernel that > may impact the JVM? I don't think so. FWIW, calling the kernel version 4.0-rc1 instead of 3.20 is just a majority decision from the crowd on G+[1] :) The 4.x version bump does not mean there are any breaking changes. That's similar to the 3.0.0.rc-1 naming instead of calling it 2.6.40, back in May 2011[2]. That begs the question: Should hotspot really be doing this kernel version check? It does make sense for OS releases that use major version bumps to communicate breaking changes. Not so much for the linux kernel these days. There is no specific check for 3.18 or 3.16 in hotspot. AFAIUI there is only a global 3.x version check. Considering that 4.0-rc1 could have been called just as well 3.20 this kernel version checking by default seems arbitrary. Thoughts? Cheers, Severin [1] http://lkml.iu.edu/hypermail/linux/kernel/1502.2/04059.html [2] https://lkml.org/lkml/2011/5/29/204 > Thanks, > David > > > > Thanks, > > Severin > > > > [1] http://fedoraproject.org/wiki/Releases/22/Schedule > > From volker.simonis at gmail.com Mon Mar 9 12:53:55 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 9 Mar 2015 13:53:55 +0100 Subject: RFR(S) 8074312: Enable hotspot builds on 4.x Linux kernels In-Reply-To: <1425904174.3466.38.camel@redhat.com> References: <1425572828.3401.14.camel@redhat.com> <54F8C3E6.8010808@oracle.com> <1425904174.3466.38.camel@redhat.com> Message-ID: On Mon, Mar 9, 2015 at 1:29 PM, Severin Gehwolf wrote: > Hi David, > > Thanks for getting back to me so quickly! > > On Fri, 2015-03-06 at 07:00 +1000, David Holmes wrote: >> Hi Severin, >> >> On 6/03/2015 2:27 AM, Severin Gehwolf wrote: >> > Hi, >> > >> > Could someone please review the following one-liner to the hotspot build >> > files. This prevents someone from building on 4.x Linux kernels such as >> > F22, which will become available in May 2015[1]. >> > >> > Currently, a JDK 9 build fails for me with: >> >> &2 echo "*** This OS is not supported:" `uname -a`; exit 1; >> > ++ uname -a >> > + echo '*** This OS is not supported:' Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 '#1' SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> > *** This OS is not supported: Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 #1 SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> > + exit 1 >> > >> > The fix is to add 4 to the list of Linux kernels, similar to what was >> > done for 3.x kernels in JDK-7072341. >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 >> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/webrev.00/ >> > >> > I'd also please need a sponsor for this change. >> >> The whole purpose of those version checks is to ensure we know there is >> a reasonable level of support for a platform before we enable it - >> anyone can make the change locally to try for themselves (and deal with >> the consequences). Otherwise we may as well just remove the version checks. > > OK. Is there some form of definition for "reasonable level of support"? > Is being able to build hotspot and being able to run simple Java > programs enough? For the time being I'm fine with keeping this patch > local, fwiw. > >> So I can sponsor this change for you assuming that everything does >> indeed build and run fine on the Linux 4 kernel. > > I can build JDK 8 fine on a F22 pre-release (x86_64): > $ hg paths > default = http://hg.openjdk.java.net/jdk8u/jdk8u > $ hg tip > changeset: 1284:e532f3672f63 > tag: tip > user: katleman > date: Wed Feb 25 12:59:47 2015 -0800 > summary: Added tag jdk8u60-b04 for changeset d8d408861c20 > $ ./build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-sgeholf_2015_03_09_12_00-b00) > OpenJDK 64-Bit Server VM (build 25.60-b05, mixed mode) > $ cat /etc/fedora-release > Fedora release 22 (Twenty Two) > $ gcc --version > gcc (GCC) 5.0.0 20150226 (Red Hat 5.0.0-0.17) > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Things get trickier with JDK 9. However, I don't think they're linux > kernel version related, but rather GCC 5 related. > >> Also it seems Fedora22 will have gcc 5 so do we need build changes to >> support that as well? > > Very likely. At this point I'm still investigating what's necessary to > build JDK 9 on F22. While JDK 8 builds fine with this patch, JDK 9 has > more failures which I'm currently looking into too. > >> Are there any major new or changed features in the linux 4 kernel that >> may impact the JVM? > > I don't think so. FWIW, calling the kernel version 4.0-rc1 instead of > 3.20 is just a majority decision from the crowd on G+[1] :) The 4.x > version bump does not mean there are any breaking changes. That's > similar to the 3.0.0.rc-1 naming instead of calling it 2.6.40, back in > May 2011[2]. > > That begs the question: Should hotspot really be doing this kernel > version check? It does make sense for OS releases that use major version > bumps to communicate breaking changes. Not so much for the linux kernel > these days. There is no specific check for 3.18 or 3.16 in hotspot. > AFAIUI there is only a global 3.x version check. Considering that > 4.0-rc1 could have been called just as well 3.20 this kernel version > checking by default seems arbitrary. Thoughts? > I agree. We could leave the check for the minimum supported versions in place, but everything greater 3 will be supported anyway (sooner or later) so I don't see a need for such a check. We have the build wiki [1] with the officially and community supported build platforms. If somebody builds on a newer platfrom it's at his own risk. We shouldn't make it unnecessarily hard for people to build on other/newer platfroms. Regards, Volker [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > Cheers, > Severin > > [1] http://lkml.iu.edu/hypermail/linux/kernel/1502.2/04059.html > [2] https://lkml.org/lkml/2011/5/29/204 > >> Thanks, >> David >> >> >> > Thanks, >> > Severin >> > >> > [1] http://fedoraproject.org/wiki/Releases/22/Schedule >> > > > > From paul.sandoz at oracle.com Mon Mar 9 14:42:51 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Mar 2015 15:42:51 +0100 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <54F7A837.6070500@oracle.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> <54F44484.3030403@oracle.com> <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> <54F7A837.6070500@oracle.com> Message-ID: <2E0DE42B-9EAE-41AE-8FC5-5A5738279B88@oracle.com> On Mar 5, 2015, at 1:49 AM, David Holmes wrote: > On 2/03/2015 9:54 PM, Paul Sandoz wrote: >> >> On Mar 2, 2015, at 12:07 PM, David Holmes wrote: >> >>> Hi Paul, >>> >>> This is more a question for core-libs and the users of this Unsafe API. >> >> I wanted to check here first because of work done in [1] and because this is where there is most experience with the Unsafe implementation. I don't want to change the semantics of existing Unsafe methods. >> >> Note that the VarHandle work will expose using release/acquire names, where the former implementation defers to Unsafe.putOrdered*, and the later to relaxed plus explicit load fence. > > The Unsafe API naming tends to be done by whomever is defining the public API that uses it (eg. Doug Lea for j.u.c). The implementation of the Unsafe API then has to map through to whatever the VM provides. So given there are three layers you either match the first two or the last two but you can rarely make all three the same. > > So for example, j.u.c.atomic lazySet is defined as providing: > > *
  • {@code lazySet} has the memory effects of writing (assigning) > * a {@code volatile} variable except that it permits reorderings with > * subsequent (but not previous) memory actions that do not themselves > * impose reordering constraints with ordinary non-{@code volatile} > * writes. > > and is implemented by a call to Unsafe.putOrdered, which in turn is implemented by doing a full volatile write, which is OrderAccess::release_store_fence. I don't observe that from looking at the C2 code, nor from the generated x86 code. Its implemented like a release_store and used accordingly with that in mind. See the following for Java code snippets and corresponding C2 x86 generated code: static int putOrdered(Object o, long offset, int i) { Unsafer.UNSAFE.putOrderedInt(o, offset, i); return i; } 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 IDom: 0/#2 RegPressure: 3 IHRP Index: 23 FRegPressure: 0 FHRP Index: 23 000 # stack bang (96 bytes) pushq rbp # Save rbp subq rsp, #16 # Create frame 00c MEMBAR-release ! (empty encoding) 00c 00c movl [RSI + RDX], RCX # int <---- store 00f 00f movl RAX, RCX # spill 011 addq rsp, 16 # Destroy frame popq rbp testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC 01c ret 01c static int putVolatile(Object o, long offset, int i) { Unsafer.UNSAFE.putIntVolatile(o, offset, i); return i; } 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 IDom: 0/#2 RegPressure: 3 IHRP Index: 27 FRegPressure: 0 FHRP Index: 27 000 # stack bang (96 bytes) pushq rbp # Save rbp subq rsp, #16 # Create frame 00c MEMBAR-release ! (empty encoding) 00c 00c movl [RSI + RDX], RCX # int <---- store 00f lock addl [rsp + #0], 0 ! membar_volatile <---- fence 015 015 movl RAX, RCX # spill 017 addq rsp, 16 # Destroy frame popq rbp testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC 022 ret 022 It's the naming that appears to be all over the place (as Andrew's email points out). As a result it's hard to infer what the actual implementation does, which in turn is why we have conversations like this :-) Paul. > The implementation provides a stronger barrier than what is required. Depending on your perspective either putOrdered captures the right "lazySet" semantics but happens to be implemented using stronger ones (and that implementation might be relaxed in the future); or putOrdered is really intended to be release_store_fence (and so could be renamed accordingly) and if you want to implement true lazySet semantics then you have to define a new Unsafe API to capture that. Conversely if you need release_store_fence then you either define an API that always provide it, or use an existing one (in this case it is a normal volatile field write). > > I'm in the former camp where putOrdered is weaker than a putRelease would be. I think the VarHandle work would be wrong to assume putOrdered must be as strong as it is, and should instead define a stronger Unsafe API. > > But that is why I think this needs to be discussed with the folks at the front-end API's not the backend ones :) > > Cheers, > David > ----- > >> >>> Sometimes the implementation of unsafe doesn't exactly match the API, so we need to check what the intended API semantics are. >>> >> >> I believe things align naming-wise at least from eyeballing C2 code i.e. Unsafe.putOrdered* is a form of release-store like that of OrderAccess::release_store and Unsafe.storeFence is a form of release-fence like that of OrderAccess::release. >> >> src/share/vm/opto/library_call.cpp: >> >> bool LibraryCallKit::inline_unsafe_ordered_store(BasicType type) { >> ... >> insert_mem_bar(Op_MemBarRelease); >> insert_mem_bar(Op_MemBarCPUOrder); >> // Ensure that the store is atomic for longs: >> const bool require_atomic_access = true; >> Node* store; >> if (type == T_OBJECT) // reference stores need a store barrier. >> store = store_oop_to_unknown(control(), base, adr, adr_type, val, type, MemNode::release); >> else { >> store = store_to_memory(control(), adr, val, type, adr_type, MemNode::release, require_atomic_access); >> } >> insert_mem_bar(Op_MemBarCPUOrder); >> return true; >> } >> >> bool LibraryCallKit::inline_unsafe_fence(vmIntrinsics::ID id) { >> // Regardless of form, don't allow previous ld/st to move down, >> // then issue acquire, release, or volatile mem_bar. >> insert_mem_bar(Op_MemBarCPUOrder); >> switch(id) { >> case vmIntrinsics::_loadFence: >> insert_mem_bar(Op_LoadFence); >> return true; >> case vmIntrinsics::_storeFence: >> insert_mem_bar(Op_StoreFence); >> return true; >> case vmIntrinsics::_fullFence: >> insert_mem_bar(Op_MemBarVolatile); >> return true; >> default: >> fatal_unexpected_iid(id); >> return false; >> } >> } >> >> >> src/cpu/x86/vm/x86_32.ad: >> >> instruct membar_release() %{ >> match(MemBarRelease); >> match(StoreFence); >> ins_cost(400); >> >> size(0); >> format %{ "MEMBAR-release ! (empty encoding)" %} >> ins_encode( ); >> ins_pipe(empty); >> %} >> >> ... >> >> instruct membar_acquire() %{ >> match(MemBarAcquire); >> match(LoadFence); >> ins_cost(400); >> >> size(0); >> format %{ "MEMBAR-acquire ! (empty encoding)" %} >> ins_encode(); >> ins_pipe(empty); >> %} >> >> ... >> >> instruct membar_volatile(eFlagsReg cr) %{ >> match(MemBarVolatile); >> effect(KILL cr); >> ins_cost(400); >> >> format %{ >> $$template >> if (os::is_MP()) { >> $$emit$$"LOCK ADDL [ESP + #0], 0\t! membar_volatile" >> } else { >> $$emit$$"MEMBAR-volatile ! (empty encoding)" >> } >> %} >> ins_encode %{ >> __ membar(Assembler::StoreLoad); >> %} >> ins_pipe(pipe_slow); >> %} >> >> >> Paul. >> From tobias.hartmann at oracle.com Mon Mar 9 14:58:38 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 09 Mar 2015 15:58:38 +0100 Subject: [8u60] Backport RFR: 8006960: hotspot, "impossible" assertion failure Message-ID: <54FDB51E.7040709@oracle.com> Hi, please review the following backport request for 8u60. 8006960: hotspot, "impossible" assertion failure http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/16a66b3338de http://cr.openjdk.java.net/~thartmann/8006960/webrev.00/ The changes were pushed to JDK 9 a week ago and nightly testing showed no problems. The patch applies cleanly to 8u60. Thanks, Tobias From tim.bell at oracle.com Mon Mar 9 15:13:41 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 09 Mar 2015 08:13:41 -0700 Subject: RFR: JDK-8073021: add native code coverage target into makefiles In-Reply-To: <54FD8487.9040006@oracle.com> References: <54FD8127.3040404@oracle.com> <54FD8487.9040006@oracle.com> Message-ID: <54FDB8A5.1020204@oracle.com> Erik: >> Hello, >> >> Please review this patch. A new configure parameter >> --enable-native-coverage is introduced. Setting it only works when >> using gcc, for now. It adds '-fprofile-arcs -ftest-coverage >> -fno-inline' to compiler flags and '-fprofile-arcs' to linker flags, >> for both jdk and hotspot native libraries (but not for native test >> libraries). Setting this causes gcc to generate code coverage >> instrumentation into the binaries as well as generating a .gcno file >> for each object file created. The gcno files are needed for >> converting gathered coverage data into a comprehensible report. When >> native coverage is active, a new image containing the .gcno files is >> created by the images target. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073021 >> Webrev: http://cr.openjdk.java.net/~erikj/8073021/webrev.root.01/ > > Looks good to me. > > /Magnus Looks good to me as well. Tim From vladimir.kozlov at oracle.com Mon Mar 9 15:53:16 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 09 Mar 2015 08:53:16 -0700 Subject: [8u60] Backport RFR: 8006960: hotspot, "impossible" assertion failure In-Reply-To: <54FDB51E.7040709@oracle.com> References: <54FDB51E.7040709@oracle.com> Message-ID: <54FDC1EC.7090502@oracle.com> Looks good. Thanks, Vladimir On 3/9/15 7:58 AM, Tobias Hartmann wrote: > Hi, > > please review the following backport request for 8u60. > > 8006960: hotspot, "impossible" assertion failure > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/16a66b3338de > http://cr.openjdk.java.net/~thartmann/8006960/webrev.00/ > > The changes were pushed to JDK 9 a week ago and nightly testing showed no problems. The patch applies cleanly to 8u60. > > Thanks, > Tobias > From mikael.vidstedt at oracle.com Mon Mar 9 19:28:59 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 09 Mar 2015 12:28:59 -0700 Subject: RFR (S): 8074726: Update source and target version used when compiling hotspot class files Message-ID: <54FDF47B.4040400@oracle.com> The Java class files under hotspot/ are currently compiled using "-source 6 -target 6" which generates unnecessarily old class files and also prints out warning messages doing so. This change does two things: * bumps the default version used to "-source 8 -target 8" * uses the BOOT_JDK_SOURCETARGET from the top level build system if it has been set (typically to "-source 8 -target 8") Tested through JPRT, the serviceability/sa regression tests as well as some Oracle internal tests. http://cr.openjdk.java.net/~mikael/webrevs/8074726/webrev.00/webrev/ The change in make/defs.gmk is needed to pass the relevant option through to the jvmti docs compilation. Cheers, Mikael From coleen.phillimore at oracle.com Mon Mar 9 20:36:05 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 09 Mar 2015 16:36:05 -0400 Subject: RFR 8074717: Merge interp_masm files for x86 _32 and _64 Message-ID: <54FE0435.1000904@oracle.com> Summary: Merge duplicate code and use #ifdef for non-mergeable sections. Inspired by Max's change and because I was working on this with him, I've merged interp_masm_x86_32 and _64.cpp/hpp files. There are two webrevs generated. The first webrev is generated to see the diffs. Mostly the _64 contents are chosen because the formatting was better. The second is moving the code into the already existant interp_masm_x86.cpp/hpp files. Ran all jck tests on this and JPRT, also ran NSK vm.quick.testlist which includes jvmti tests. bug link https://bugs.openjdk.java.net/browse/JDK-8074717 open webrev at http://cr.openjdk.java.net/~coleenp/8074717 open webrev at http://cr.openjdk.java.net/~coleenp/8074717_2/ Thanks, Coleen From coleen.phillimore at oracle.com Mon Mar 9 20:57:47 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 09 Mar 2015 16:57:47 -0400 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition Message-ID: <54FE094B.1080009@oracle.com> Summary: Only do full metadata walk during class redefinition and only walk handles during class unloading. This change decouples metadata walking for redefinition and class unloading, so that class unloading for G1 doesn't walk the code cache. It also decouples GC and on_stack marking in the code cache. open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ bug link https://bugs.openjdk.java.net/browse/JDK-8061205 Tested with FMW performance runs. vm.quick.testlist, jdk/test/java/lang/instrument tests and JPRT. Thanks, Coleen From david.holmes at oracle.com Mon Mar 9 22:03:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 08:03:57 +1000 Subject: RFR(S) 8074312: Enable hotspot builds on 4.x Linux kernels In-Reply-To: <1425904174.3466.38.camel@redhat.com> References: <1425572828.3401.14.camel@redhat.com> <54F8C3E6.8010808@oracle.com> <1425904174.3466.38.camel@redhat.com> Message-ID: <54FE18CD.5060708@oracle.com> On 9/03/2015 10:29 PM, Severin Gehwolf wrote: > Hi David, > > Thanks for getting back to me so quickly! > > On Fri, 2015-03-06 at 07:00 +1000, David Holmes wrote: >> Hi Severin, >> >> On 6/03/2015 2:27 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> Could someone please review the following one-liner to the hotspot build >>> files. This prevents someone from building on 4.x Linux kernels such as >>> F22, which will become available in May 2015[1]. >>> >>> Currently, a JDK 9 build fails for me with: >>>> &2 echo "*** This OS is not supported:" `uname -a`; exit 1; >>> ++ uname -a >>> + echo '*** This OS is not supported:' Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 '#1' SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> *** This OS is not supported: Linux f22 4.0.0-0.rc1.git0.1.fc22.x86_64 #1 SMP Mon Feb 23 21:15:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> + exit 1 >>> >>> The fix is to add 4 to the list of Linux kernels, similar to what was >>> done for 3.x kernels in JDK-7072341. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/webrev.00/ >>> >>> I'd also please need a sponsor for this change. >> >> The whole purpose of those version checks is to ensure we know there is >> a reasonable level of support for a platform before we enable it - >> anyone can make the change locally to try for themselves (and deal with >> the consequences). Otherwise we may as well just remove the version checks. > > OK. Is there some form of definition for "reasonable level of support"? > Is being able to build hotspot and being able to run simple Java > programs enough? For the time being I'm fine with keeping this patch > local, fwiw. The main thing is not to have something that might cause newcomers a lot of grief trying to build/run OpenJDK on their brand new system XYZ. Chances are they haven't checked to see if XYZ is on the supported platform list. :) So if it builds and runs basic programs okay it should be okay. >> So I can sponsor this change for you assuming that everything does >> indeed build and run fine on the Linux 4 kernel. > > I can build JDK 8 fine on a F22 pre-release (x86_64): > $ hg paths > default = http://hg.openjdk.java.net/jdk8u/jdk8u > $ hg tip > changeset: 1284:e532f3672f63 > tag: tip > user: katleman > date: Wed Feb 25 12:59:47 2015 -0800 > summary: Added tag jdk8u60-b04 for changeset d8d408861c20 > $ ./build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-sgeholf_2015_03_09_12_00-b00) > OpenJDK 64-Bit Server VM (build 25.60-b05, mixed mode) > $ cat /etc/fedora-release > Fedora release 22 (Twenty Two) > $ gcc --version > gcc (GCC) 5.0.0 20150226 (Red Hat 5.0.0-0.17) > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Things get trickier with JDK 9. However, I don't think they're linux > kernel version related, but rather GCC 5 related. Interesting ... >> Also it seems Fedora22 will have gcc 5 so do we need build changes to >> support that as well? > > Very likely. At this point I'm still investigating what's necessary to > build JDK 9 on F22. While JDK 8 builds fine with this patch, JDK 9 has > more failures which I'm currently looking into too. ... Is that because we have additional warnings enabled in 9 and -Werror ? >> Are there any major new or changed features in the linux 4 kernel that >> may impact the JVM? > > I don't think so. FWIW, calling the kernel version 4.0-rc1 instead of > 3.20 is just a majority decision from the crowd on G+[1] :) The 4.x > version bump does not mean there are any breaking changes. That's > similar to the 3.0.0.rc-1 naming instead of calling it 2.6.40, back in > May 2011[2]. > > That begs the question: Should hotspot really be doing this kernel > version check? It does make sense for OS releases that use major version > bumps to communicate breaking changes. Not so much for the linux kernel > these days. There is no specific check for 3.18 or 3.16 in hotspot. > AFAIUI there is only a global 3.x version check. Considering that > 4.0-rc1 could have been called just as well 3.20 this kernel version > checking by default seems arbitrary. Thoughts? Yes this does seem somewhat pointless if major version number changes are not based on technical changes. But I'd probably just add the 4.x support and not throw it out altogether - then revisit for 5 :) So I can accept this patch as-is. Still need a second reviewer. David > Cheers, > Severin > > [1] http://lkml.iu.edu/hypermail/linux/kernel/1502.2/04059.html > [2] https://lkml.org/lkml/2011/5/29/204 > >> Thanks, >> David >> >> >>> Thanks, >>> Severin >>> >>> [1] http://fedoraproject.org/wiki/Releases/22/Schedule >>> > > > From david.holmes at oracle.com Mon Mar 9 22:38:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 08:38:46 +1000 Subject: RFR (S): 8074726: Update source and target version used when compiling hotspot class files In-Reply-To: <54FDF47B.4040400@oracle.com> References: <54FDF47B.4040400@oracle.com> Message-ID: <54FE20F6.300@oracle.com> Hi Mikael, On 10/03/2015 5:28 AM, Mikael Vidstedt wrote: > > The Java class files under hotspot/ are currently compiled using > "-source 6 -target 6" which generates unnecessarily old class files and > also prints out warning messages doing so. This change does two things: > > * bumps the default version used to "-source 8 -target 8" > * uses the BOOT_JDK_SOURCETARGET from the top level build system if it > has been set (typically to "-source 8 -target 8") Makes sense to auto update this. The use of 6 was a "manual" update: https://bugs.openjdk.java.net/browse/JDK-6873059 > Tested through JPRT, the serviceability/sa regression tests as well as > some Oracle internal tests. > > http://cr.openjdk.java.net/~mikael/webrevs/8074726/webrev.00/webrev/ > > The change in make/defs.gmk is needed to pass the relevant option > through to the jvmti docs compilation. Hmmm. That suggests something is amiss as the value should be coming through spec.gmk and shouldn't need to be passed directly to all the sub-makes via MAKE_ARGS. The generated jvmti.make includes the generated flags.make which includes the configured hotspot-spec.gmk which includes spec.gmk, which defines BOOT_JDK_SOURCETARGET. Ah, but the jvmtidocs target doesn't start with the generated jvmti.make, it uses the repo version: ./linux/Makefile: $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/makefiles/jvmti.make $(MFLAGS) $(BUILDTREE_VARS) JvmtiOutDir=$(SUBDIR_DOCS) BUILD_FLAVOR=product jvmtidocs Hmmm - not happy but either it gets fixed once by MAKE_FLAGS, or in every platform Makefile by MFLAGS. Ok. Thanks, David > Cheers, > Mikael > From serguei.spitsyn at oracle.com Tue Mar 10 01:52:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 09 Mar 2015 18:52:35 -0700 Subject: RFR 8074717: Merge interp_masm files for x86 _32 and _64 In-Reply-To: <54FE0435.1000904@oracle.com> References: <54FE0435.1000904@oracle.com> Message-ID: <54FE4E63.9080201@oracle.com> Hi Coleen, It looks good. Just one comment: src/cpu/x86/vm/interp_masm_x86_32.cpp src/cpu/x86/vm/interp_masm_x86_64.cpp 1656 get_thread(rthread); . . . 1669 get_thread(rthread); Should it be?: 1656NOT_LP64(get_thread(rthread)); . . . 1669NOT_LP64(get_thread(rthread)); To be safe, it'd be nice to run the nsk.quick-jdi.testlist in both 32- and 64-bit mode, which include more PopFrame and ForceEarlyReturn tests. Thanks, Serguei On 3/9/15 1:36 PM, Coleen Phillimore wrote: > Summary: Merge duplicate code and use #ifdef for non-mergeable sections. > > Inspired by Max's change and because I was working on this with him, > I've merged interp_masm_x86_32 and _64.cpp/hpp files. > > There are two webrevs generated. The first webrev is generated to see > the diffs. Mostly the _64 contents are chosen because the formatting > was better. The second is moving the code into the already existant > interp_masm_x86.cpp/hpp files. > > Ran all jck tests on this and JPRT, also ran NSK vm.quick.testlist > which includes jvmti tests. > > bug link https://bugs.openjdk.java.net/browse/JDK-8074717 > open webrev at http://cr.openjdk.java.net/~coleenp/8074717 > open webrev at http://cr.openjdk.java.net/~coleenp/8074717_2/ > > Thanks, > Coleen From david.holmes at oracle.com Tue Mar 10 02:06:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 12:06:54 +1000 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <2E0DE42B-9EAE-41AE-8FC5-5A5738279B88@oracle.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> <54F44484.3030403@oracle.com> <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> <54F7A837.6070500@oracle.com> <2E0DE42B-9EAE-41AE-8FC5-5A5738279B88@oracle.com> Message-ID: <54FE51BE.5040905@oracle.com> On 10/03/2015 12:42 AM, Paul Sandoz wrote: > > On Mar 5, 2015, at 1:49 AM, David Holmes wrote: > >> On 2/03/2015 9:54 PM, Paul Sandoz wrote: >>> >>> On Mar 2, 2015, at 12:07 PM, David Holmes wrote: >>> >>>> Hi Paul, >>>> >>>> This is more a question for core-libs and the users of this Unsafe API. >>> >>> I wanted to check here first because of work done in [1] and because this is where there is most experience with the Unsafe implementation. I don't want to change the semantics of existing Unsafe methods. >>> >>> Note that the VarHandle work will expose using release/acquire names, where the former implementation defers to Unsafe.putOrdered*, and the later to relaxed plus explicit load fence. >> >> The Unsafe API naming tends to be done by whomever is defining the public API that uses it (eg. Doug Lea for j.u.c). The implementation of the Unsafe API then has to map through to whatever the VM provides. So given there are three layers you either match the first two or the last two but you can rarely make all three the same. >> >> So for example, j.u.c.atomic lazySet is defined as providing: >> >> *
  • {@code lazySet} has the memory effects of writing (assigning) >> * a {@code volatile} variable except that it permits reorderings with >> * subsequent (but not previous) memory actions that do not themselves >> * impose reordering constraints with ordinary non-{@code volatile} >> * writes. >> >> and is implemented by a call to Unsafe.putOrdered, which in turn is implemented by doing a full volatile write, which is OrderAccess::release_store_fence. > > I don't observe that from looking at the C2 code, nor from the generated x86 code. Its implemented like a release_store and used accordingly with that in mind. I was referring to the non-intrinsified version of Unsafe: // The non-intrinsified versions of setOrdered just use setVolatile UNSAFE_ENTRY(void, Unsafe_SetOrderedInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint x)) UnsafeWrapper("Unsafe_SetOrderedInt"); SET_FIELD_VOLATILE(obj, offset, jint, x); UNSAFE_END and IIRC that was something Martin complained about a few weeks back. Okay in that case aligning the names makes more sense - and we should fix the the non-intrinsic form. :) Thanks, David > See the following for Java code snippets and corresponding C2 x86 generated code: > > static int putOrdered(Object o, long offset, int i) { > Unsafer.UNSAFE.putOrderedInt(o, offset, i); > return i; > } > > 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 IDom: 0/#2 RegPressure: 3 IHRP Index: 23 FRegPressure: 0 FHRP Index: 23 > 000 # stack bang (96 bytes) > pushq rbp # Save rbp > subq rsp, #16 # Create frame > > 00c MEMBAR-release ! (empty encoding) > 00c > 00c movl [RSI + RDX], RCX # int <---- store > 00f > 00f movl RAX, RCX # spill > 011 addq rsp, 16 # Destroy frame > popq rbp > testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC > > 01c ret > 01c > > > static int putVolatile(Object o, long offset, int i) { > Unsafer.UNSAFE.putIntVolatile(o, offset, i); > return i; > } > > 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 IDom: 0/#2 RegPressure: 3 IHRP Index: 27 FRegPressure: 0 FHRP Index: 27 > 000 # stack bang (96 bytes) > pushq rbp # Save rbp > subq rsp, #16 # Create frame > > 00c MEMBAR-release ! (empty encoding) > 00c > 00c movl [RSI + RDX], RCX # int <---- store > 00f lock addl [rsp + #0], 0 ! membar_volatile <---- fence > 015 > 015 movl RAX, RCX # spill > 017 addq rsp, 16 # Destroy frame > popq rbp > testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC > > 022 ret > 022 > > > It's the naming that appears to be all over the place (as Andrew's email points out). As a result it's hard to infer what the actual implementation does, which in turn is why we have conversations like this :-) > > Paul. > >> The implementation provides a stronger barrier than what is required. Depending on your perspective either putOrdered captures the right "lazySet" semantics but happens to be implemented using stronger ones (and that implementation might be relaxed in the future); or putOrdered is really intended to be release_store_fence (and so could be renamed accordingly) and if you want to implement true lazySet semantics then you have to define a new Unsafe API to capture that. Conversely if you need release_store_fence then you either define an API that always provide it, or use an existing one (in this case it is a normal volatile field write). >> >> I'm in the former camp where putOrdered is weaker than a putRelease would be. I think the VarHandle work would be wrong to assume putOrdered must be as strong as it is, and should instead define a stronger Unsafe API. >> > >> But that is why I think this needs to be discussed with the folks at the front-end API's not the backend ones :) >> >> Cheers, >> David >> ----- >> >>> >>>> Sometimes the implementation of unsafe doesn't exactly match the API, so we need to check what the intended API semantics are. >>>> >>> >>> I believe things align naming-wise at least from eyeballing C2 code i.e. Unsafe.putOrdered* is a form of release-store like that of OrderAccess::release_store and Unsafe.storeFence is a form of release-fence like that of OrderAccess::release. >>> >>> src/share/vm/opto/library_call.cpp: >>> >>> bool LibraryCallKit::inline_unsafe_ordered_store(BasicType type) { >>> ... >>> insert_mem_bar(Op_MemBarRelease); >>> insert_mem_bar(Op_MemBarCPUOrder); >>> // Ensure that the store is atomic for longs: >>> const bool require_atomic_access = true; >>> Node* store; >>> if (type == T_OBJECT) // reference stores need a store barrier. >>> store = store_oop_to_unknown(control(), base, adr, adr_type, val, type, MemNode::release); >>> else { >>> store = store_to_memory(control(), adr, val, type, adr_type, MemNode::release, require_atomic_access); >>> } >>> insert_mem_bar(Op_MemBarCPUOrder); >>> return true; >>> } >>> >>> bool LibraryCallKit::inline_unsafe_fence(vmIntrinsics::ID id) { >>> // Regardless of form, don't allow previous ld/st to move down, >>> // then issue acquire, release, or volatile mem_bar. >>> insert_mem_bar(Op_MemBarCPUOrder); >>> switch(id) { >>> case vmIntrinsics::_loadFence: >>> insert_mem_bar(Op_LoadFence); >>> return true; >>> case vmIntrinsics::_storeFence: >>> insert_mem_bar(Op_StoreFence); >>> return true; >>> case vmIntrinsics::_fullFence: >>> insert_mem_bar(Op_MemBarVolatile); >>> return true; >>> default: >>> fatal_unexpected_iid(id); >>> return false; >>> } >>> } >>> >>> >>> src/cpu/x86/vm/x86_32.ad: >>> >>> instruct membar_release() %{ >>> match(MemBarRelease); >>> match(StoreFence); >>> ins_cost(400); >>> >>> size(0); >>> format %{ "MEMBAR-release ! (empty encoding)" %} >>> ins_encode( ); >>> ins_pipe(empty); >>> %} >>> >>> ... >>> >>> instruct membar_acquire() %{ >>> match(MemBarAcquire); >>> match(LoadFence); >>> ins_cost(400); >>> >>> size(0); >>> format %{ "MEMBAR-acquire ! (empty encoding)" %} >>> ins_encode(); >>> ins_pipe(empty); >>> %} >>> >>> ... >>> >>> instruct membar_volatile(eFlagsReg cr) %{ >>> match(MemBarVolatile); >>> effect(KILL cr); >>> ins_cost(400); >>> >>> format %{ >>> $$template >>> if (os::is_MP()) { >>> $$emit$$"LOCK ADDL [ESP + #0], 0\t! membar_volatile" >>> } else { >>> $$emit$$"MEMBAR-volatile ! (empty encoding)" >>> } >>> %} >>> ins_encode %{ >>> __ membar(Assembler::StoreLoad); >>> %} >>> ins_pipe(pipe_slow); >>> %} >>> >>> >>> Paul. >>> > From mikael.vidstedt at oracle.com Tue Mar 10 02:07:01 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 09 Mar 2015 19:07:01 -0700 Subject: RFR(S) 8074312: Enable hotspot builds on 4.x Linux kernels In-Reply-To: <54FE18CD.5060708@oracle.com> References: <1425572828.3401.14.camel@redhat.com> <54F8C3E6.8010808@oracle.com> <1425904174.3466.38.camel@redhat.com> <54FE18CD.5060708@oracle.com> Message-ID: <54FE51C5.9070804@oracle.com> On 2015-03-09 15:03, David Holmes wrote: > On 9/03/2015 10:29 PM, Severin Gehwolf wrote: >> Hi David, >> >> Thanks for getting back to me so quickly! >> >> On Fri, 2015-03-06 at 07:00 +1000, David Holmes wrote: >>> Hi Severin, >>> >>> On 6/03/2015 2:27 AM, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Could someone please review the following one-liner to the hotspot >>>> build >>>> files. This prevents someone from building on 4.x Linux kernels >>>> such as >>>> F22, which will become available in May 2015[1]. >>>> >>>> Currently, a JDK 9 build fails for me with: >>>>> &2 echo "*** This OS is not supported:" `uname -a`; exit 1; >>>> ++ uname -a >>>> + echo '*** This OS is not supported:' Linux f22 >>>> 4.0.0-0.rc1.git0.1.fc22.x86_64 '#1' SMP Mon Feb 23 21:15:25 UTC >>>> 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> *** This OS is not supported: Linux f22 >>>> 4.0.0-0.rc1.git0.1.fc22.x86_64 #1 SMP Mon Feb 23 21:15:25 UTC 2015 >>>> x86_64 x86_64 x86_64 GNU/Linux >>>> + exit 1 >>>> >>>> The fix is to add 4 to the list of Linux kernels, similar to what was >>>> done for 3.x kernels in JDK-7072341. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 >>>> webrev: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/webrev.00/ >>>> >>>> I'd also please need a sponsor for this change. >>> >>> The whole purpose of those version checks is to ensure we know there is >>> a reasonable level of support for a platform before we enable it - >>> anyone can make the change locally to try for themselves (and deal with >>> the consequences). Otherwise we may as well just remove the version >>> checks. >> >> OK. Is there some form of definition for "reasonable level of support"? >> Is being able to build hotspot and being able to run simple Java >> programs enough? For the time being I'm fine with keeping this patch >> local, fwiw. > > The main thing is not to have something that might cause newcomers a > lot of grief trying to build/run OpenJDK on their brand new system > XYZ. Chances are they haven't checked to see if XYZ is on the > supported platform list. :) So if it builds and runs basic programs > okay it should be okay. > >>> So I can sponsor this change for you assuming that everything does >>> indeed build and run fine on the Linux 4 kernel. >> >> I can build JDK 8 fine on a F22 pre-release (x86_64): >> $ hg paths >> default = http://hg.openjdk.java.net/jdk8u/jdk8u >> $ hg tip >> changeset: 1284:e532f3672f63 >> tag: tip >> user: katleman >> date: Wed Feb 25 12:59:47 2015 -0800 >> summary: Added tag jdk8u60-b04 for changeset d8d408861c20 >> $ >> ./build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -version >> >> openjdk version "1.8.0-internal" >> OpenJDK Runtime Environment (build >> 1.8.0-internal-sgeholf_2015_03_09_12_00-b00) >> OpenJDK 64-Bit Server VM (build 25.60-b05, mixed mode) >> $ cat /etc/fedora-release >> Fedora release 22 (Twenty Two) >> $ gcc --version >> gcc (GCC) 5.0.0 20150226 (Red Hat 5.0.0-0.17) >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There >> is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> Things get trickier with JDK 9. However, I don't think they're linux >> kernel version related, but rather GCC 5 related. > > Interesting ... > >>> Also it seems Fedora22 will have gcc 5 so do we need build changes to >>> support that as well? >> >> Very likely. At this point I'm still investigating what's necessary to >> build JDK 9 on F22. While JDK 8 builds fine with this patch, JDK 9 has >> more failures which I'm currently looking into too. > > ... Is that because we have additional warnings enabled in 9 and > -Werror ? > >>> Are there any major new or changed features in the linux 4 kernel that >>> may impact the JVM? >> >> I don't think so. FWIW, calling the kernel version 4.0-rc1 instead of >> 3.20 is just a majority decision from the crowd on G+[1] :) The 4.x >> version bump does not mean there are any breaking changes. That's >> similar to the 3.0.0.rc-1 naming instead of calling it 2.6.40, back in >> May 2011[2]. >> >> That begs the question: Should hotspot really be doing this kernel >> version check? It does make sense for OS releases that use major version >> bumps to communicate breaking changes. Not so much for the linux kernel >> these days. There is no specific check for 3.18 or 3.16 in hotspot. >> AFAIUI there is only a global 3.x version check. Considering that >> 4.0-rc1 could have been called just as well 3.20 this kernel version >> checking by default seems arbitrary. Thoughts? > > Yes this does seem somewhat pointless if major version number changes > are not based on technical changes. But I'd probably just add the 4.x > support and not throw it out altogether - then revisit for 5 :) > > So I can accept this patch as-is. > > Still need a second reviewer. I agree that having the check is rather arbitrary to start with, but the suggested change looks good! Cheers, Mikael > > David > >> Cheers, >> Severin >> >> [1] http://lkml.iu.edu/hypermail/linux/kernel/1502.2/04059.html >> [2] https://lkml.org/lkml/2011/5/29/204 >> >>> Thanks, >>> David >>> >>> >>>> Thanks, >>>> Severin >>>> >>>> [1] http://fedoraproject.org/wiki/Releases/22/Schedule >>>> >> >> >> From tobias.hartmann at oracle.com Tue Mar 10 06:21:08 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 10 Mar 2015 07:21:08 +0100 Subject: [8u60] Backport RFR: 8006960: hotspot, "impossible" assertion failure In-Reply-To: <54FDC1EC.7090502@oracle.com> References: <54FDB51E.7040709@oracle.com> <54FDC1EC.7090502@oracle.com> Message-ID: <54FE8D54.9080908@oracle.com> Thanks, Vladimir. Best, Tobias On 09.03.2015 16:53, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 3/9/15 7:58 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following backport request for 8u60. >> >> 8006960: hotspot, "impossible" assertion failure >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/16a66b3338de >> http://cr.openjdk.java.net/~thartmann/8006960/webrev.00/ >> >> The changes were pushed to JDK 9 a week ago and nightly testing showed no problems. The patch applies cleanly to 8u60. >> >> Thanks, >> Tobias >> From staffan.larsen at oracle.com Tue Mar 10 08:06:38 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Mar 2015 09:06:38 +0100 Subject: RFR (S): 8074726: Update source and target version used when compiling hotspot class files In-Reply-To: <54FDF47B.4040400@oracle.com> References: <54FDF47B.4040400@oracle.com> Message-ID: <6CCA8931-F7E3-4B89-9841-816854A9C656@oracle.com> Looks good! Thanks, /Staffan > On 9 mar 2015, at 20:28, Mikael Vidstedt wrote: > > > The Java class files under hotspot/ are currently compiled using "-source 6 -target 6" which generates unnecessarily old class files and also prints out warning messages doing so. This change does two things: > > * bumps the default version used to "-source 8 -target 8" > * uses the BOOT_JDK_SOURCETARGET from the top level build system if it has been set (typically to "-source 8 -target 8") > > Tested through JPRT, the serviceability/sa regression tests as well as some Oracle internal tests. > > http://cr.openjdk.java.net/~mikael/webrevs/8074726/webrev.00/webrev/ > > The change in make/defs.gmk is needed to pass the relevant option through to the jvmti docs compilation. > > Cheers, > Mikael > From paul.sandoz at oracle.com Tue Mar 10 08:32:04 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 Mar 2015 09:32:04 +0100 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <54FE51BE.5040905@oracle.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> <54F44484.3030403@oracle.com> <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> <54F7A837.6070500@oracle.com> <2E0DE42B-9EAE-41AE-8FC5-5A5738279B88@oracle.com> <54FE51BE.5040905@oracle.com> Message-ID: <18343500-897C-47B9-84D9-6A257BBC1097@oracle.com> On Mar 10, 2015, at 3:06 AM, David Holmes wrote: >>> >>> So for example, j.u.c.atomic lazySet is defined as providing: >>> >>> *
  • {@code lazySet} has the memory effects of writing (assigning) >>> * a {@code volatile} variable except that it permits reorderings with >>> * subsequent (but not previous) memory actions that do not themselves >>> * impose reordering constraints with ordinary non-{@code volatile} >>> * writes. >>> >>> and is implemented by a call to Unsafe.putOrdered, which in turn is implemented by doing a full volatile write, which is OrderAccess::release_store_fence. >> >> I don't observe that from looking at the C2 code, nor from the generated x86 code. Its implemented like a release_store and used accordingly with that in mind. > > I was referring to the non-intrinsified version of Unsafe: > > // The non-intrinsified versions of setOrdered just use setVolatile > > UNSAFE_ENTRY(void, Unsafe_SetOrderedInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint x)) > UnsafeWrapper("Unsafe_SetOrderedInt"); > SET_FIELD_VOLATILE(obj, offset, jint, x); > UNSAFE_END > > and IIRC that was something Martin complained about a few weeks back. > Ah! ok. > Okay in that case aligning the names makes more sense - and we should fix the the non-intrinsic form. :) > When would that non-intrinsified version be used, just for the interpreter? I suppose it could be changed, but it does not seem absolutely necessary to do so. What's currently there seems a pragmatic solution to me given what happens when C1/C2 kick in. Paul. From david.holmes at oracle.com Tue Mar 10 11:11:05 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 21:11:05 +1000 Subject: Unasafe.putOdered -> Unsafe.releasePut In-Reply-To: <18343500-897C-47B9-84D9-6A257BBC1097@oracle.com> References: <2B149B0F-9A99-486A-BBCF-4C072077A906@oracle.com> <54F44484.3030403@oracle.com> <2BDDB201-C3CA-4732-92D0-E25DB3018FDF@oracle.com> <54F7A837.6070500@oracle.com> <2E0DE42B-9EAE-41AE-8FC5-5A5738279B88@oracle.com> <54FE51BE.5040905@oracle.com> <18343500-897C-47B9-84D9-6A257BBC1097@oracle.com> Message-ID: <54FED149.9040409@oracle.com> On 10/03/2015 6:32 PM, Paul Sandoz wrote: > On Mar 10, 2015, at 3:06 AM, David Holmes wrote: >>>> >>>> So for example, j.u.c.atomic lazySet is defined as providing: >>>> >>>> *
  • {@code lazySet} has the memory effects of writing (assigning) >>>> * a {@code volatile} variable except that it permits reorderings with >>>> * subsequent (but not previous) memory actions that do not themselves >>>> * impose reordering constraints with ordinary non-{@code volatile} >>>> * writes. >>>> >>>> and is implemented by a call to Unsafe.putOrdered, which in turn is implemented by doing a full volatile write, which is OrderAccess::release_store_fence. >>> >>> I don't observe that from looking at the C2 code, nor from the generated x86 code. Its implemented like a release_store and used accordingly with that in mind. >> >> I was referring to the non-intrinsified version of Unsafe: >> >> // The non-intrinsified versions of setOrdered just use setVolatile >> >> UNSAFE_ENTRY(void, Unsafe_SetOrderedInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint x)) >> UnsafeWrapper("Unsafe_SetOrderedInt"); >> SET_FIELD_VOLATILE(obj, offset, jint, x); >> UNSAFE_END >> >> and IIRC that was something Martin complained about a few weeks back. >> > > Ah! ok. > > >> Okay in that case aligning the names makes more sense - and we should fix the the non-intrinsic form. :) >> > > When would that non-intrinsified version be used, just for the interpreter? Yes. > I suppose it could be changed, but it does not seem absolutely necessary to do so. What's currently there seems a pragmatic solution to me given what happens when C1/C2 kick in. No not essential to fix when you have the JIT - may be more of a concern in interpreter only environments. David > Paul. > From goetz.lindenmaier at sap.com Tue Mar 10 13:16:12 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 10 Mar 2015 13:16:12 +0000 Subject: RFR(XS): 8073954: Initialize _replaced_nodes in SafePoints. In-Reply-To: <58809E49-E3AF-4F40-B93E-E8A116539A33@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF993F5@DEWDFEMB12A.global.corp.sap> <58809E49-E3AF-4F40-B93E-E8A116539A33@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFAC641@DEWDFEMB12A.global.corp.sap> Yes, Kim, you are right, this is useless. I withdraw this change. Thanks, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Donnerstag, 26. Februar 2015 19:15 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(XS): 8073954: Initialize _replaced_nodes in SafePoints. On Feb 26, 2015, at 6:48 AM, Lindenmaier, Goetz wrote: > > please review this tiny fix in the C2 compiler. I please need a sponsor. > > The field _replaced_node added to SafePoints in "8026796: Make replace_in_map() on parent maps generic" > is not initialized to NULL. As the memory is pre-set to 0, this doesn't cause immediate problems. > But we saw lots of sporadic failures in our nightly tests of SAP JVM with the debug build, where memory > in Arenas is zapped to 0xab. We also saw rare failures with the opt builds. > > https://bugs.openjdk.java.net/browse/JDK-8073954 > http://cr.openjdk.java.net/~goetz/webrevs/8073954-replNd/webrev/ > > 8026796 was downported to 8u40, so it's wrong there, too. I've no problem with the change, per se. However, I don't understand the motivation for the change. "The field _replaced_node added to SafePoints in "8026796: Make replace_in_map() on parent maps generic" is not initialized to NULL." _replaced_nodes is of type ReplacedNodes, which is a class type with user-defined constructors (in this case, only a default constructor). Note that it is not a pointer type, it is a nested object. Not mentioning _replaced_nodes in the ctor-initializer (old code) causes it to be default initialized. (C++03 12.6.2/4) Including _replaced_nodes with an empty initializer list (proposed change) causes it to be value initialized. (C++03 12.6.2/3) For a class type with a user-defined constructor, value initialization and default initialization are the same; both forms of initialization call the class's default constructor. (C++03 8.5/5) So with or without this change, _replaced_nodes should be initialized via a call to its default constructor. And that default constructor directly initializes the pointer member to NULL. In other words, I don't think this code change leads to any program execution change. From stefan.karlsson at oracle.com Tue Mar 10 16:24:58 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 Mar 2015 17:24:58 +0100 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <54FE094B.1080009@oracle.com> References: <54FE094B.1080009@oracle.com> Message-ID: <54FF1ADA.9080604@oracle.com> Hi Coleen, Thanks for fixing this and lowering the G1 remark times when class redefinition is used. I'm only reviewing the GC specific parts: On 2015-03-09 21:57, Coleen Phillimore wrote: > Summary: Only do full metadata walk during class redefinition and only > walk handles during class unloading. > > This change decouples metadata walking for redefinition and class > unloading, so that class unloading for G1 doesn't walk the code > cache. It also decouples GC and on_stack marking in the code cache. > > open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/classfile/metadataOnStackMark.cpp.frames.html There are Atomic calls left to handle concurrent retiring of buffers. Do you want to keep it?: 97 void MetadataOnStackMark::retire_buffer(MetadataOnStackBuffer* buffer) { 98 if (buffer == NULL) { 99 return; 100 } 101 102 MetadataOnStackBuffer* old_head; 103 104 do { 105 old_head = const_cast(_used_buffers); 106 buffer->set_next_used(old_head); 107 } while (Atomic::cmpxchg_ptr(buffer, &_used_buffers, old_head) != old_head); 108 } There's also some Atomic code in accessFlags that were added to support concurrent mark_on_stack calls. Maybe you want to get rid of that code as well? http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.cdiff.html Could you get rid of the pre/post_work_verification functions? They were only added to be able to verify the MetadataOnStackMark state, and is not needed anymore. void pre_work_verification() { - assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), "Should be empty"); } void post_work_verification() { - assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), "Should be empty"); } http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/runtime/thread.cpp.frames.html 4105 void Threads::metadata_handles_do(void f(Metadata*)) { 4106 // Only walk the Handles in Thread. 4107 ALL_JAVA_THREADS(p) { 4108 p->metadata_handles_do(f); 4109 } 4110 } This only walks metadata handles in the Java threads. Don't we have metadata handles in the VM Thread? http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html Could you motivate why only Metadata induced Full GCs need to do this unloading? 268 // If redefinition, make a pass over the metadata to find any that 269 // can be marked to be deallocated 270 if (JvmtiExport::has_redefined_a_class()) { 271 ClassLoaderDataGraph::clean_redefinition_metadata(); 272 } Don't we need it for our other Full GCs? I would prefer if this code could be kept inside the GC code or where it used to be, inside the ClassLoaderDataGraph::do_unloading function. With the current change, the VM_CollectForMetadataAllocation class is burdened with the internal knowledge about class redefinition and class unloading. Thanks, StefanK > bug link https://bugs.openjdk.java.net/browse/JDK-8061205 > > Tested with FMW performance runs. vm.quick.testlist, > jdk/test/java/lang/instrument tests and JPRT. > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Mar 10 17:45:43 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 10 Mar 2015 13:45:43 -0400 Subject: RFR 8074717: Merge interp_masm files for x86 _32 and _64 In-Reply-To: <54FE4E63.9080201@oracle.com> References: <54FE0435.1000904@oracle.com> <54FE4E63.9080201@oracle.com> Message-ID: <54FF2DC7.3040201@oracle.com> Serguei, Thank you for spotting this! get_thread is expensive so it would have worked but been expensive, so I made the changes below. I ran the nsk.quick-jdk.testlist on both 32 and 64 bit linux with all the changes. Thanks! coleen On 3/9/15, 9:52 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > It looks good. > > Just one comment: > > src/cpu/x86/vm/interp_masm_x86_32.cpp > src/cpu/x86/vm/interp_masm_x86_64.cpp > 1656 get_thread(rthread); > . . . > 1669 get_thread(rthread);Should it be?: > 1656NOT_LP64(get_thread(rthread)); > . . . > 1669NOT_LP64(get_thread(rthread)); > > To be safe, it'd be nice to run the nsk.quick-jdi.testlist in both 32- > and 64-bit mode, > which include more PopFrame and ForceEarlyReturn tests. > > > Thanks, > Serguei > > > > On 3/9/15 1:36 PM, Coleen Phillimore wrote: >> Summary: Merge duplicate code and use #ifdef for non-mergeable sections. >> >> Inspired by Max's change and because I was working on this with him, >> I've merged interp_masm_x86_32 and _64.cpp/hpp files. >> >> There are two webrevs generated. The first webrev is generated to >> see the diffs. Mostly the _64 contents are chosen because the >> formatting was better. The second is moving the code into the >> already existant interp_masm_x86.cpp/hpp files. >> >> Ran all jck tests on this and JPRT, also ran NSK vm.quick.testlist >> which includes jvmti tests. >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8074717 >> open webrev at http://cr.openjdk.java.net/~coleenp/8074717 >> open webrev at http://cr.openjdk.java.net/~coleenp/8074717_2/ >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Tue Mar 10 19:50:52 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 10 Mar 2015 15:50:52 -0400 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <54FF1ADA.9080604@oracle.com> References: <54FE094B.1080009@oracle.com> <54FF1ADA.9080604@oracle.com> Message-ID: <54FF4B1C.3090307@oracle.com> Stefan, Thank you for reviewing this so quickly! On 3/10/15, 12:24 PM, Stefan Karlsson wrote: > Hi Coleen, > > Thanks for fixing this and lowering the G1 remark times when class > redefinition is used. > > I'm only reviewing the GC specific parts: > > On 2015-03-09 21:57, Coleen Phillimore wrote: >> Summary: Only do full metadata walk during class redefinition and >> only walk handles during class unloading. >> >> This change decouples metadata walking for redefinition and class >> unloading, so that class unloading for G1 doesn't walk the code >> cache. It also decouples GC and on_stack marking in the code cache. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ > > > http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/classfile/metadataOnStackMark.cpp.frames.html > > > There are Atomic calls left to handle concurrent retiring of buffers. > Do you want to keep it?: I didn't know whether I should or not. I suppose we should trust our source code control system in case we ever need to do this concurrently again. I'll remove the concurrency - it makes the code a bit simpler. The code to do chunked lists is still good though, so I'm glad you added that as a utility class. > > 97 void MetadataOnStackMark::retire_buffer(MetadataOnStackBuffer* > buffer) { > 98 if (buffer == NULL) { > 99 return; > 100 } > 101 > 102 MetadataOnStackBuffer* old_head; > 103 > 104 do { > 105 old_head = const_cast(_used_buffers); > 106 buffer->set_next_used(old_head); > 107 } while (Atomic::cmpxchg_ptr(buffer, &_used_buffers, old_head) > != old_head); > 108 } > > There's also some Atomic code in accessFlags that were added to > support concurrent mark_on_stack calls. Maybe you want to get rid of > that code as well? I like how you changed it so that the cpool and method is only recorded if it's not already marked. That probably saves a lot of time and space. > > > http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.cdiff.html > > > Could you get rid of the pre/post_work_verification functions? They > were only added to be able to verify the MetadataOnStackMark state, > and is not needed anymore. > > void pre_work_verification() { > - > assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), > "Should be empty"); > } > void post_work_verification() { > - > assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), > "Should be empty"); > } > > Okay, thanks. I didn't know if you'd prefer that. > > http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/runtime/thread.cpp.frames.html > > > 4105 void Threads::metadata_handles_do(void f(Metadata*)) { > 4106 // Only walk the Handles in Thread. > 4107 ALL_JAVA_THREADS(p) { > 4108 p->metadata_handles_do(f); > 4109 } > 4110 } > > This only walks metadata handles in the Java threads. Don't we have > metadata handles in the VM Thread? > > Hm. We never walked non-Java threads before but yes, we could have Metadata handles on these threads. Wow, thanks for finding this bug! I think this should walk GC threads too (no?) > > http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html > > > Could you motivate why only Metadata induced Full GCs need to do this > unloading? > > 268 // If redefinition, make a pass over the metadata to find any that > 269 // can be marked to be deallocated > 270 if (JvmtiExport::has_redefined_a_class()) { > 271 ClassLoaderDataGraph::clean_redefinition_metadata(); > 272 } > > Don't we need it for our other Full GCs? No, I don't think we want it for all full GCs. The effect of cleaning out the redefinition metadata is to remove the metadata itself. There may be some mirrors unused from the redefined classes. I suppose you could construct a test case where one of the mirrors is gigantic and causes an out of memory situation in Java heap. The main effect of walking the previous versions is to find more metadata to clean out though, for the next attempt at class unloading. > > I would prefer if this code could be kept inside the GC code or where > it used to be, inside the ClassLoaderDataGraph::do_unloading function. > With the current change, the VM_CollectForMetadataAllocation class is > burdened with the internal knowledge about class redefinition and > class unloading. In ClassLoaderDataGraph::do_unloading() is used when you're not in a Full GC, which is the problem. It can't go there unless we pass down the logic that we're in a full GC or not. I think this is messier. I think this VM_CollectForMetadataAllocation seems the right place to clean up metadata, if needed. One place or another, there has to be knowledge of class redefinition. Actually, my original change had it not called at all, since this code is executed for every class redefinition. Then I thought something should call it... The bias should be to avoid calling this function though because generally it doesn't find very much to do. I thought a better place to call this would be for last-ditch collections, but I didn't know exactly where that was. Coleen > > Thanks, > StefanK > >> bug link https://bugs.openjdk.java.net/browse/JDK-8061205 >> >> Tested with FMW performance runs. vm.quick.testlist, >> jdk/test/java/lang/instrument tests and JPRT. >> >> Thanks, >> Coleen > From serguei.spitsyn at oracle.com Wed Mar 11 00:55:33 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 10 Mar 2015 17:55:33 -0700 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <54FE094B.1080009@oracle.com> References: <54FE094B.1080009@oracle.com> Message-ID: <54FF9285.8000406@oracle.com> Coleen, It looks good, just one minor comment is below. src/share/vm/code/nmethod.cpp 1628 bool a_class_was_redefined = JvmtiExport::has_redefined_a_class(); 1629 if (a_class_was_redefined) { . . . 1634 } 1757 bool a_class_was_redefined = JvmtiExport::has_redefined_a_class(); 1758 if (a_class_was_redefined) { . . . 1763 } Minor: No reason to keep the local variable "a_class_was_redefined" Thanks, Serguei On 3/9/15 1:57 PM, Coleen Phillimore wrote: > Summary: Only do full metadata walk during class redefinition and only > walk handles during class unloading. > > This change decouples metadata walking for redefinition and class > unloading, so that class unloading for G1 doesn't walk the code > cache. It also decouples GC and on_stack marking in the code cache. > > open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ > bug link https://bugs.openjdk.java.net/browse/JDK-8061205 > > Tested with FMW performance runs. vm.quick.testlist, > jdk/test/java/lang/instrument tests and JPRT. > > Thanks, > Coleen From david.holmes at oracle.com Wed Mar 11 01:22:01 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Mar 2015 11:22:01 +1000 Subject: RFR(S) 8074312: Enable hotspot builds on 4.x Linux kernels In-Reply-To: <54FE51C5.9070804@oracle.com> References: <1425572828.3401.14.camel@redhat.com> <54F8C3E6.8010808@oracle.com> <1425904174.3466.38.camel@redhat.com> <54FE18CD.5060708@oracle.com> <54FE51C5.9070804@oracle.com> Message-ID: <54FF98B9.9010007@oracle.com> Thanks Mikael. This change is now being pushed. David On 10/03/2015 12:07 PM, Mikael Vidstedt wrote: > > > On 2015-03-09 15:03, David Holmes wrote: >> On 9/03/2015 10:29 PM, Severin Gehwolf wrote: >>> Hi David, >>> >>> Thanks for getting back to me so quickly! >>> >>> On Fri, 2015-03-06 at 07:00 +1000, David Holmes wrote: >>>> Hi Severin, >>>> >>>> On 6/03/2015 2:27 AM, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Could someone please review the following one-liner to the hotspot >>>>> build >>>>> files. This prevents someone from building on 4.x Linux kernels >>>>> such as >>>>> F22, which will become available in May 2015[1]. >>>>> >>>>> Currently, a JDK 9 build fails for me with: >>>>>> &2 echo "*** This OS is not supported:" `uname -a`; exit 1; >>>>> ++ uname -a >>>>> + echo '*** This OS is not supported:' Linux f22 >>>>> 4.0.0-0.rc1.git0.1.fc22.x86_64 '#1' SMP Mon Feb 23 21:15:25 UTC >>>>> 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>> *** This OS is not supported: Linux f22 >>>>> 4.0.0-0.rc1.git0.1.fc22.x86_64 #1 SMP Mon Feb 23 21:15:25 UTC 2015 >>>>> x86_64 x86_64 x86_64 GNU/Linux >>>>> + exit 1 >>>>> >>>>> The fix is to add 4 to the list of Linux kernels, similar to what was >>>>> done for 3.x kernels in JDK-7072341. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/webrev.00/ >>>>> >>>>> I'd also please need a sponsor for this change. >>>> >>>> The whole purpose of those version checks is to ensure we know there is >>>> a reasonable level of support for a platform before we enable it - >>>> anyone can make the change locally to try for themselves (and deal with >>>> the consequences). Otherwise we may as well just remove the version >>>> checks. >>> >>> OK. Is there some form of definition for "reasonable level of support"? >>> Is being able to build hotspot and being able to run simple Java >>> programs enough? For the time being I'm fine with keeping this patch >>> local, fwiw. >> >> The main thing is not to have something that might cause newcomers a >> lot of grief trying to build/run OpenJDK on their brand new system >> XYZ. Chances are they haven't checked to see if XYZ is on the >> supported platform list. :) So if it builds and runs basic programs >> okay it should be okay. >> >>>> So I can sponsor this change for you assuming that everything does >>>> indeed build and run fine on the Linux 4 kernel. >>> >>> I can build JDK 8 fine on a F22 pre-release (x86_64): >>> $ hg paths >>> default = http://hg.openjdk.java.net/jdk8u/jdk8u >>> $ hg tip >>> changeset: 1284:e532f3672f63 >>> tag: tip >>> user: katleman >>> date: Wed Feb 25 12:59:47 2015 -0800 >>> summary: Added tag jdk8u60-b04 for changeset d8d408861c20 >>> $ >>> ./build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -version >>> >>> openjdk version "1.8.0-internal" >>> OpenJDK Runtime Environment (build >>> 1.8.0-internal-sgeholf_2015_03_09_12_00-b00) >>> OpenJDK 64-Bit Server VM (build 25.60-b05, mixed mode) >>> $ cat /etc/fedora-release >>> Fedora release 22 (Twenty Two) >>> $ gcc --version >>> gcc (GCC) 5.0.0 20150226 (Red Hat 5.0.0-0.17) >>> Copyright (C) 2015 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There >>> is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>> PURPOSE. >>> >>> Things get trickier with JDK 9. However, I don't think they're linux >>> kernel version related, but rather GCC 5 related. >> >> Interesting ... >> >>>> Also it seems Fedora22 will have gcc 5 so do we need build changes to >>>> support that as well? >>> >>> Very likely. At this point I'm still investigating what's necessary to >>> build JDK 9 on F22. While JDK 8 builds fine with this patch, JDK 9 has >>> more failures which I'm currently looking into too. >> >> ... Is that because we have additional warnings enabled in 9 and >> -Werror ? >> >>>> Are there any major new or changed features in the linux 4 kernel that >>>> may impact the JVM? >>> >>> I don't think so. FWIW, calling the kernel version 4.0-rc1 instead of >>> 3.20 is just a majority decision from the crowd on G+[1] :) The 4.x >>> version bump does not mean there are any breaking changes. That's >>> similar to the 3.0.0.rc-1 naming instead of calling it 2.6.40, back in >>> May 2011[2]. >>> >>> That begs the question: Should hotspot really be doing this kernel >>> version check? It does make sense for OS releases that use major version >>> bumps to communicate breaking changes. Not so much for the linux kernel >>> these days. There is no specific check for 3.18 or 3.16 in hotspot. >>> AFAIUI there is only a global 3.x version check. Considering that >>> 4.0-rc1 could have been called just as well 3.20 this kernel version >>> checking by default seems arbitrary. Thoughts? >> >> Yes this does seem somewhat pointless if major version number changes >> are not based on technical changes. But I'd probably just add the 4.x >> support and not throw it out altogether - then revisit for 5 :) >> >> So I can accept this patch as-is. >> >> Still need a second reviewer. > > I agree that having the check is rather arbitrary to start with, but the > suggested change looks good! > > Cheers, > Mikael > >> >> David >> >>> Cheers, >>> Severin >>> >>> [1] http://lkml.iu.edu/hypermail/linux/kernel/1502.2/04059.html >>> [2] https://lkml.org/lkml/2011/5/29/204 >>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> [1] http://fedoraproject.org/wiki/Releases/22/Schedule >>>>> >>> >>> >>> > From jesper.wilhelmsson at oracle.com Wed Mar 11 13:54:56 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 11 Mar 2015 14:54:56 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t Message-ID: <55004930.1030708@oracle.com> Hi, Please review this change to make most flags handling memory sizes to be of type size_t. Flags dealing with code heap and code cache are not included in this change. Se the bug for details. The change is surprisingly small considering the amount of flags changed. Most variables around these flags was already of type size_t so there are only a few places where related code had to change in some way. Bug: https://bugs.openjdk.java.net/browse/JDK-8074459 Webrev: http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.01/ Testing: jprt, jtreg tests Thanks, /Jesper From coleen.phillimore at oracle.com Wed Mar 11 16:28:36 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 11 Mar 2015 12:28:36 -0400 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <54FF9285.8000406@oracle.com> References: <54FE094B.1080009@oracle.com> <54FF9285.8000406@oracle.com> Message-ID: <55006D34.8060108@oracle.com> Thank you Serguei, I removed the local variable. Coleen On 3/10/15, 8:55 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > > It looks good, just one minor comment is below. > > src/share/vm/code/nmethod.cpp > 1628 bool a_class_was_redefined = JvmtiExport::has_redefined_a_class(); > 1629 if (a_class_was_redefined) { > . . . > 1634 } > 1757 bool a_class_was_redefined = JvmtiExport::has_redefined_a_class(); > 1758 if (a_class_was_redefined) { > . . . > 1763 } > > Minor: No reason to keep the local variable "a_class_was_redefined" > > Thanks, > Serguei > > > On 3/9/15 1:57 PM, Coleen Phillimore wrote: >> Summary: Only do full metadata walk during class redefinition and >> only walk handles during class unloading. >> >> This change decouples metadata walking for redefinition and class >> unloading, so that class unloading for G1 doesn't walk the code >> cache. It also decouples GC and on_stack marking in the code cache. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8061205 >> >> Tested with FMW performance runs. vm.quick.testlist, >> jdk/test/java/lang/instrument tests and JPRT. >> >> Thanks, >> Coleen > From jesper.wilhelmsson at oracle.com Wed Mar 11 17:21:05 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 11 Mar 2015 18:21:05 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <55004930.1030708@oracle.com> References: <55004930.1030708@oracle.com> Message-ID: <55007981.5030703@oracle.com> Hi, Thomas pointed out a few more flags to change and also that the patch file in this webrev is empty. This was due to the fact that I didn't commit my changes before creating the webrev and had an empty outgoing patch... I'll provide a new webrev in a while. Thanks, /Jesper Jesper Wilhelmsson skrev den 11/3/15 14:54: > Hi, > > Please review this change to make most flags handling memory sizes to be of type > size_t. Flags dealing with code heap and code cache are not included in this > change. Se the bug for details. > > The change is surprisingly small considering the amount of flags changed. Most > variables around these flags was already of type size_t so there are only a few > places where related code had to change in some way. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074459 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.01/ > > Testing: jprt, jtreg tests > > Thanks, > /Jesper From kim.barrett at oracle.com Wed Mar 11 17:48:22 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 11 Mar 2015 13:48:22 -0400 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <55004930.1030708@oracle.com> References: <55004930.1030708@oracle.com> Message-ID: <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> On Mar 11, 2015, at 9:54 AM, Jesper Wilhelmsson wrote: > > Hi, > > Please review this change to make most flags handling memory sizes to be of type size_t. Flags dealing with code heap and code cache are not included in this change. Se the bug for details. > > The change is surprisingly small considering the amount of flags changed. Most variables around these flags was already of type size_t so there are only a few places where related code had to change in some way. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074459 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.01/ > > Testing: jprt, jtreg tests > > Thanks, > /Jesper Looks good. Just a couple of minor issues, plus a new CR to file for a pre-existing problem I noticed during the review. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1RemSet.cpp src/share/vm/gc_implementation/g1/g1_globals.hpp Update copyright. ------------------------------------------------------------------------------ src/share/vm/runtime/sweeper.cpp No changes, other than copyright update? ------------------------------------------------------------------------------ src/share/vm/utilities/ostream.hpp 253 ((GCLogFileSize != 0) && ((size_t)_bytes_written >= GCLogFileSize)); [changed cast of _bytes_written from uintx to size_t] On a 32bit platform this is, and always has been, a narrowing conversion, because _bytes_written is declared to be of type jlong. But GCLogFileSize is of type size_t (was uintx). If, on a 32bit platform, GCLogFileSize were set to something large, like (1 << 32) - 1 and the log grew large, rotation would probably not occur as expected. This is a pre-existing problem, and should be dealt with via a separate CR. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Wed Mar 11 17:49:41 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 11 Mar 2015 13:49:41 -0400 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <55007981.5030703@oracle.com> References: <55004930.1030708@oracle.com> <55007981.5030703@oracle.com> Message-ID: <21C37599-0281-40E1-B465-C09ACA5FC7F7@oracle.com> On Mar 11, 2015, at 1:21 PM, Jesper Wilhelmsson wrote: > > Thomas pointed out a few more flags to change and also that the patch file in this webrev is empty. This was due to the fact that I didn't commit my changes before creating the webrev and had an empty outgoing patch... I'll provide a new webrev in a while. Missed this before sending my comments. Any chance of an incremental webrev for the additional flags? From coleen.phillimore at oracle.com Wed Mar 11 20:48:22 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 11 Mar 2015 16:48:22 -0400 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <54FF4B1C.3090307@oracle.com> References: <54FE094B.1080009@oracle.com> <54FF1ADA.9080604@oracle.com> <54FF4B1C.3090307@oracle.com> Message-ID: <5500AA16.1000302@oracle.com> Stefan, I made the changes you suggested. I also moved purge_previous_versions conditionally back to class unloading, where G1 doesn't do this until full GC. Do you prefer this to calling the separate function for ClassLoaderDataGraph::clean_redefinition_metadata()? I thought with a separate function we could be more judicious where to call it, but we can also add conditions to ClassLoaderDataGraph::do_unloading() to avoid metadata walking. http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/ I've rerun all the class redefinition tests with -XX:+UseG1GC and with the default collector. Thanks, Coleen On 3/10/15, 3:50 PM, Coleen Phillimore wrote: > > Stefan, Thank you for reviewing this so quickly! > > On 3/10/15, 12:24 PM, Stefan Karlsson wrote: >> Hi Coleen, >> >> Thanks for fixing this and lowering the G1 remark times when class >> redefinition is used. >> >> I'm only reviewing the GC specific parts: >> >> On 2015-03-09 21:57, Coleen Phillimore wrote: >>> Summary: Only do full metadata walk during class redefinition and >>> only walk handles during class unloading. >>> >>> This change decouples metadata walking for redefinition and class >>> unloading, so that class unloading for G1 doesn't walk the code >>> cache. It also decouples GC and on_stack marking in the code cache. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ >> >> >> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/classfile/metadataOnStackMark.cpp.frames.html >> >> >> There are Atomic calls left to handle concurrent retiring of buffers. >> Do you want to keep it?: > > I didn't know whether I should or not. I suppose we should trust our > source code control system in case we ever need to do this > concurrently again. I'll remove the concurrency - it makes the code a > bit simpler. The code to do chunked lists is still good though, so > I'm glad you added that as a utility class. >> >> 97 void MetadataOnStackMark::retire_buffer(MetadataOnStackBuffer* >> buffer) { >> 98 if (buffer == NULL) { >> 99 return; >> 100 } >> 101 >> 102 MetadataOnStackBuffer* old_head; >> 103 >> 104 do { >> 105 old_head = const_cast(_used_buffers); >> 106 buffer->set_next_used(old_head); >> 107 } while (Atomic::cmpxchg_ptr(buffer, &_used_buffers, old_head) >> != old_head); >> 108 } >> >> There's also some Atomic code in accessFlags that were added to >> support concurrent mark_on_stack calls. Maybe you want to get rid of >> that code as well? > > I like how you changed it so that the cpool and method is only > recorded if it's not already marked. That probably saves a lot of > time and space. >> >> >> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.cdiff.html >> >> >> Could you get rid of the pre/post_work_verification functions? They >> were only added to be able to verify the MetadataOnStackMark state, >> and is not needed anymore. >> >> void pre_work_verification() { >> - >> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), "Should >> be empty"); >> } >> void post_work_verification() { >> - >> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), "Should >> be empty"); >> } >> >> > > Okay, thanks. I didn't know if you'd prefer that. > >> >> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/runtime/thread.cpp.frames.html >> >> >> 4105 void Threads::metadata_handles_do(void f(Metadata*)) { >> 4106 // Only walk the Handles in Thread. >> 4107 ALL_JAVA_THREADS(p) { >> 4108 p->metadata_handles_do(f); >> 4109 } >> 4110 } >> >> This only walks metadata handles in the Java threads. Don't we have >> metadata handles in the VM Thread? >> >> > > Hm. We never walked non-Java threads before but yes, we could have > Metadata handles on these threads. Wow, thanks for finding this > bug! I think this should walk GC threads too (no?) > >> >> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html >> >> >> Could you motivate why only Metadata induced Full GCs need to do this >> unloading? >> >> 268 // If redefinition, make a pass over the metadata to find any >> that >> 269 // can be marked to be deallocated >> 270 if (JvmtiExport::has_redefined_a_class()) { >> 271 ClassLoaderDataGraph::clean_redefinition_metadata(); >> 272 } >> >> Don't we need it for our other Full GCs? > > No, I don't think we want it for all full GCs. The effect of > cleaning out the redefinition metadata is to remove the metadata > itself. There may be some mirrors unused from the redefined classes. > I suppose you could construct a test case where one of the mirrors is > gigantic and causes an out of memory situation in Java heap. > > The main effect of walking the previous versions is to find more > metadata to clean out though, for the next attempt at class unloading. >> >> I would prefer if this code could be kept inside the GC code or where >> it used to be, inside the ClassLoaderDataGraph::do_unloading >> function. With the current change, the >> VM_CollectForMetadataAllocation class is burdened with the internal >> knowledge about class redefinition and class unloading. > > In ClassLoaderDataGraph::do_unloading() is used when you're not in a > Full GC, which is the problem. It can't go there unless we pass down > the logic that we're in a full GC or not. I think this is messier. I > think this VM_CollectForMetadataAllocation seems the right place to > clean up metadata, if needed. One place or another, there has to be > knowledge of class redefinition. > > Actually, my original change had it not called at all, since this code > is executed for every class redefinition. Then I thought something > should call it... The bias should be to avoid calling this function > though because generally it doesn't find very much to do. > > I thought a better place to call this would be for last-ditch > collections, but I didn't know exactly where that was. > > Coleen >> >> Thanks, >> StefanK >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8061205 >>> >>> Tested with FMW performance runs. vm.quick.testlist, >>> jdk/test/java/lang/instrument tests and JPRT. >>> >>> Thanks, >>> Coleen >> > From serguei.spitsyn at oracle.com Thu Mar 12 09:45:45 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Mar 2015 02:45:45 -0700 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <5500AA16.1000302@oracle.com> References: <54FE094B.1080009@oracle.com> <54FF1ADA.9080604@oracle.com> <54FF4B1C.3090307@oracle.com> <5500AA16.1000302@oracle.com> Message-ID: <55016049.9060706@oracle.com> Coleen, The updated webrev .03 looks good. Thank you for the changes! Thanks, Serguei On 3/11/15 1:48 PM, Coleen Phillimore wrote: > > Stefan, > > I made the changes you suggested. I also moved > purge_previous_versions conditionally back to class unloading, where > G1 doesn't do this until full GC. Do you prefer this to calling the > separate function for > ClassLoaderDataGraph::clean_redefinition_metadata()? I thought with a > separate function we could be more judicious where to call it, but we > can also add conditions to ClassLoaderDataGraph::do_unloading() to > avoid metadata walking. > > http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/ > > I've rerun all the class redefinition tests with -XX:+UseG1GC and with > the default collector. > > Thanks, > Coleen > > On 3/10/15, 3:50 PM, Coleen Phillimore wrote: >> >> Stefan, Thank you for reviewing this so quickly! >> >> On 3/10/15, 12:24 PM, Stefan Karlsson wrote: >>> Hi Coleen, >>> >>> Thanks for fixing this and lowering the G1 remark times when class >>> redefinition is used. >>> >>> I'm only reviewing the GC specific parts: >>> >>> On 2015-03-09 21:57, Coleen Phillimore wrote: >>>> Summary: Only do full metadata walk during class redefinition and >>>> only walk handles during class unloading. >>>> >>>> This change decouples metadata walking for redefinition and class >>>> unloading, so that class unloading for G1 doesn't walk the code >>>> cache. It also decouples GC and on_stack marking in the code cache. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ >>> >>> >>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/classfile/metadataOnStackMark.cpp.frames.html >>> >>> >>> There are Atomic calls left to handle concurrent retiring of >>> buffers. Do you want to keep it?: >> >> I didn't know whether I should or not. I suppose we should trust our >> source code control system in case we ever need to do this >> concurrently again. I'll remove the concurrency - it makes the code >> a bit simpler. The code to do chunked lists is still good though, >> so I'm glad you added that as a utility class. >>> >>> 97 void MetadataOnStackMark::retire_buffer(MetadataOnStackBuffer* >>> buffer) { >>> 98 if (buffer == NULL) { >>> 99 return; >>> 100 } >>> 101 >>> 102 MetadataOnStackBuffer* old_head; >>> 103 >>> 104 do { >>> 105 old_head = const_cast(_used_buffers); >>> 106 buffer->set_next_used(old_head); >>> 107 } while (Atomic::cmpxchg_ptr(buffer, &_used_buffers, >>> old_head) != old_head); >>> 108 } >>> >>> There's also some Atomic code in accessFlags that were added to >>> support concurrent mark_on_stack calls. Maybe you want to get rid of >>> that code as well? >> >> I like how you changed it so that the cpool and method is only >> recorded if it's not already marked. That probably saves a lot of >> time and space. >>> >>> >>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.cdiff.html >>> >>> >>> Could you get rid of the pre/post_work_verification functions? They >>> were only added to be able to verify the MetadataOnStackMark state, >>> and is not needed anymore. >>> >>> void pre_work_verification() { >>> - >>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>> "Should be empty"); >>> } >>> void post_work_verification() { >>> - >>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>> "Should be empty"); >>> } >>> >>> >> >> Okay, thanks. I didn't know if you'd prefer that. >> >>> >>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/runtime/thread.cpp.frames.html >>> >>> >>> 4105 void Threads::metadata_handles_do(void f(Metadata*)) { >>> 4106 // Only walk the Handles in Thread. >>> 4107 ALL_JAVA_THREADS(p) { >>> 4108 p->metadata_handles_do(f); >>> 4109 } >>> 4110 } >>> >>> This only walks metadata handles in the Java threads. Don't we have >>> metadata handles in the VM Thread? >>> >>> >> >> Hm. We never walked non-Java threads before but yes, we could have >> Metadata handles on these threads. Wow, thanks for finding this >> bug! I think this should walk GC threads too (no?) >> >>> >>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html >>> >>> >>> Could you motivate why only Metadata induced Full GCs need to do >>> this unloading? >>> >>> 268 // If redefinition, make a pass over the metadata to find any >>> that >>> 269 // can be marked to be deallocated >>> 270 if (JvmtiExport::has_redefined_a_class()) { >>> 271 ClassLoaderDataGraph::clean_redefinition_metadata(); >>> 272 } >>> >>> Don't we need it for our other Full GCs? >> >> No, I don't think we want it for all full GCs. The effect of >> cleaning out the redefinition metadata is to remove the metadata >> itself. There may be some mirrors unused from the redefined >> classes. I suppose you could construct a test case where one of the >> mirrors is gigantic and causes an out of memory situation in Java heap. >> >> The main effect of walking the previous versions is to find more >> metadata to clean out though, for the next attempt at class unloading. >>> >>> I would prefer if this code could be kept inside the GC code or >>> where it used to be, inside the ClassLoaderDataGraph::do_unloading >>> function. With the current change, the >>> VM_CollectForMetadataAllocation class is burdened with the internal >>> knowledge about class redefinition and class unloading. >> >> In ClassLoaderDataGraph::do_unloading() is used when you're not in a >> Full GC, which is the problem. It can't go there unless we pass down >> the logic that we're in a full GC or not. I think this is messier. >> I think this VM_CollectForMetadataAllocation seems the right place to >> clean up metadata, if needed. One place or another, there has to be >> knowledge of class redefinition. >> >> Actually, my original change had it not called at all, since this >> code is executed for every class redefinition. Then I thought >> something should call it... The bias should be to avoid calling >> this function though because generally it doesn't find very much to do. >> >> I thought a better place to call this would be for last-ditch >> collections, but I didn't know exactly where that was. >> >> Coleen >>> >>> Thanks, >>> StefanK >>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8061205 >>>> >>>> Tested with FMW performance runs. vm.quick.testlist, >>>> jdk/test/java/lang/instrument tests and JPRT. >>>> >>>> Thanks, >>>> Coleen >>> >> > From stefan.karlsson at oracle.com Thu Mar 12 13:09:06 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Mar 2015 14:09:06 +0100 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <5500AA16.1000302@oracle.com> References: <54FE094B.1080009@oracle.com> <54FF1ADA.9080604@oracle.com> <54FF4B1C.3090307@oracle.com> <5500AA16.1000302@oracle.com> Message-ID: <55018FF2.8070202@oracle.com> Hi Coleen, On 2015-03-11 21:48, Coleen Phillimore wrote: > > Stefan, > > I made the changes you suggested. Thanks. > I also moved purge_previous_versions conditionally back to class > unloading, where G1 doesn't do this until full GC. Thanks. > Do you prefer this to calling the separate function for > ClassLoaderDataGraph::clean_redefinition_metadata()? I thought with a > separate function we could be more judicious where to call it, but we > can also add conditions to ClassLoaderDataGraph::do_unloading() to > avoid metadata walking. > > http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/ http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/src/share/vm/classfile/classLoaderData.cpp.udiff.html With this code: while (data != NULL) { if (data->is_alive(is_alive_closure)) { *+ // clean metaspace* *+ if (walk_all_metadata) {* *+ data->classes_do(InstanceKlass::purge_previous_versions);* *+ }* *+ data->free_deallocate_list();* are you reintroducing the bug that Roland fixed with the follwing change:: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c3388a74a6fb + if (has_redefined_a_class) { + // purge_previous_versions also cleans weak method links. Because + // one method's MDO can reference another method from another + // class loader, we need to first clean weak method links for all + // class loaders here. Below, we can then free redefined methods + // for all class loaders. + while (data != NULL) { + if (data->is_alive(is_alive_closure)) { + data->classes_do(InstanceKlass::purge_previous_versions); + } + data = data->next(); + } + } + data = _head; while (data != NULL) { if (data->is_alive(is_alive_closure)) { - if (has_redefined_a_class) { - data->classes_do(InstanceKlass::purge_previous_versions); - } Thanks, StefanK > > I've rerun all the class redefinition tests with -XX:+UseG1GC and with > the default collector. > > Thanks, > Coleen > > On 3/10/15, 3:50 PM, Coleen Phillimore wrote: >> >> Stefan, Thank you for reviewing this so quickly! >> >> On 3/10/15, 12:24 PM, Stefan Karlsson wrote: >>> Hi Coleen, >>> >>> Thanks for fixing this and lowering the G1 remark times when class >>> redefinition is used. >>> >>> I'm only reviewing the GC specific parts: >>> >>> On 2015-03-09 21:57, Coleen Phillimore wrote: >>>> Summary: Only do full metadata walk during class redefinition and >>>> only walk handles during class unloading. >>>> >>>> This change decouples metadata walking for redefinition and class >>>> unloading, so that class unloading for G1 doesn't walk the code >>>> cache. It also decouples GC and on_stack marking in the code cache. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ >>> >>> >>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/classfile/metadataOnStackMark.cpp.frames.html >>> >>> >>> There are Atomic calls left to handle concurrent retiring of >>> buffers. Do you want to keep it?: >> >> I didn't know whether I should or not. I suppose we should trust our >> source code control system in case we ever need to do this >> concurrently again. I'll remove the concurrency - it makes the code >> a bit simpler. The code to do chunked lists is still good though, >> so I'm glad you added that as a utility class. >>> >>> 97 void MetadataOnStackMark::retire_buffer(MetadataOnStackBuffer* >>> buffer) { >>> 98 if (buffer == NULL) { >>> 99 return; >>> 100 } >>> 101 >>> 102 MetadataOnStackBuffer* old_head; >>> 103 >>> 104 do { >>> 105 old_head = const_cast(_used_buffers); >>> 106 buffer->set_next_used(old_head); >>> 107 } while (Atomic::cmpxchg_ptr(buffer, &_used_buffers, >>> old_head) != old_head); >>> 108 } >>> >>> There's also some Atomic code in accessFlags that were added to >>> support concurrent mark_on_stack calls. Maybe you want to get rid of >>> that code as well? >> >> I like how you changed it so that the cpool and method is only >> recorded if it's not already marked. That probably saves a lot of >> time and space. >>> >>> >>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.cdiff.html >>> >>> >>> Could you get rid of the pre/post_work_verification functions? They >>> were only added to be able to verify the MetadataOnStackMark state, >>> and is not needed anymore. >>> >>> void pre_work_verification() { >>> - >>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>> "Should be empty"); >>> } >>> void post_work_verification() { >>> - >>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>> "Should be empty"); >>> } >>> >>> >> >> Okay, thanks. I didn't know if you'd prefer that. >> >>> >>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/runtime/thread.cpp.frames.html >>> >>> >>> 4105 void Threads::metadata_handles_do(void f(Metadata*)) { >>> 4106 // Only walk the Handles in Thread. >>> 4107 ALL_JAVA_THREADS(p) { >>> 4108 p->metadata_handles_do(f); >>> 4109 } >>> 4110 } >>> >>> This only walks metadata handles in the Java threads. Don't we have >>> metadata handles in the VM Thread? >>> >>> >> >> Hm. We never walked non-Java threads before but yes, we could have >> Metadata handles on these threads. Wow, thanks for finding this >> bug! I think this should walk GC threads too (no?) >> >>> >>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html >>> >>> >>> Could you motivate why only Metadata induced Full GCs need to do >>> this unloading? >>> >>> 268 // If redefinition, make a pass over the metadata to find any >>> that >>> 269 // can be marked to be deallocated >>> 270 if (JvmtiExport::has_redefined_a_class()) { >>> 271 ClassLoaderDataGraph::clean_redefinition_metadata(); >>> 272 } >>> >>> Don't we need it for our other Full GCs? >> >> No, I don't think we want it for all full GCs. The effect of >> cleaning out the redefinition metadata is to remove the metadata >> itself. There may be some mirrors unused from the redefined >> classes. I suppose you could construct a test case where one of the >> mirrors is gigantic and causes an out of memory situation in Java heap. >> >> The main effect of walking the previous versions is to find more >> metadata to clean out though, for the next attempt at class unloading. >>> >>> I would prefer if this code could be kept inside the GC code or >>> where it used to be, inside the ClassLoaderDataGraph::do_unloading >>> function. With the current change, the >>> VM_CollectForMetadataAllocation class is burdened with the internal >>> knowledge about class redefinition and class unloading. >> >> In ClassLoaderDataGraph::do_unloading() is used when you're not in a >> Full GC, which is the problem. It can't go there unless we pass down >> the logic that we're in a full GC or not. I think this is messier. >> I think this VM_CollectForMetadataAllocation seems the right place to >> clean up metadata, if needed. One place or another, there has to be >> knowledge of class redefinition. >> >> Actually, my original change had it not called at all, since this >> code is executed for every class redefinition. Then I thought >> something should call it... The bias should be to avoid calling >> this function though because generally it doesn't find very much to do. >> >> I thought a better place to call this would be for last-ditch >> collections, but I didn't know exactly where that was. >> >> Coleen >>> >>> Thanks, >>> StefanK >>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8061205 >>>> >>>> Tested with FMW performance runs. vm.quick.testlist, >>>> jdk/test/java/lang/instrument tests and JPRT. >>>> >>>> Thanks, >>>> Coleen >>> >> > From coleen.phillimore at oracle.com Thu Mar 12 18:16:50 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 12 Mar 2015 14:16:50 -0400 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <55018FF2.8070202@oracle.com> References: <54FE094B.1080009@oracle.com> <54FF1ADA.9080604@oracle.com> <54FF4B1C.3090307@oracle.com> <5500AA16.1000302@oracle.com> <55018FF2.8070202@oracle.com> Message-ID: <5501D812.4070105@oracle.com> Hi, On 3/12/15, 9:09 AM, Stefan Karlsson wrote: > Hi Coleen, > > On 2015-03-11 21:48, Coleen Phillimore wrote: >> >> Stefan, >> >> I made the changes you suggested. > > Thanks. > >> I also moved purge_previous_versions conditionally back to class >> unloading, where G1 doesn't do this until full GC. > > Thanks. > >> Do you prefer this to calling the separate function for >> ClassLoaderDataGraph::clean_redefinition_metadata()? I thought with >> a separate function we could be more judicious where to call it, but >> we can also add conditions to ClassLoaderDataGraph::do_unloading() to >> avoid metadata walking. >> >> http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/ > > http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/src/share/vm/classfile/classLoaderData.cpp.udiff.html > > With this code: > while (data != NULL) { > if (data->is_alive(is_alive_closure)) { > *+ // clean metaspace* > *+ if (walk_all_metadata) {* > *+ data->classes_do(InstanceKlass::purge_previous_versions);* > *+ }* > *+ data->free_deallocate_list();* > > are you reintroducing the bug that Roland fixed with the follwing change:: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c3388a74a6fb No, I moved clean_weak_method_links to the end of redefinition and clean MethodData to not have any old methods (not just ones on stack). This cleaning used to be inside of purge_previous_versions, which is why we needed the loop to deallocate after all the classes had called purge_previous_versions. I had to take out the assert that used to be clean_weak_method_links because it was confusing me. I don't think it was verifying anything since all the methods aren't marked is_old until all the classes are redefined, and they're cleaned out then. Thanks - I'm glad you remembered that bug. Coleen > > + if (has_redefined_a_class) { > + // purge_previous_versions also cleans weak method links. Because > + // one method's MDO can reference another method from another > + // class loader, we need to first clean weak method links for all > + // class loaders here. Below, we can then free redefined methods > + // for all class loaders. > + while (data != NULL) { > + if (data->is_alive(is_alive_closure)) { > + data->classes_do(InstanceKlass::purge_previous_versions); > + } > + data = data->next(); > + } > + } > + data = _head; > while (data != NULL) { > if (data->is_alive(is_alive_closure)) { > - if (has_redefined_a_class) { > - data->classes_do(InstanceKlass::purge_previous_versions); > - } > > Thanks, > StefanK > >> >> I've rerun all the class redefinition tests with -XX:+UseG1GC and >> with the default collector. >> >> Thanks, >> Coleen >> >> On 3/10/15, 3:50 PM, Coleen Phillimore wrote: >>> >>> Stefan, Thank you for reviewing this so quickly! >>> >>> On 3/10/15, 12:24 PM, Stefan Karlsson wrote: >>>> Hi Coleen, >>>> >>>> Thanks for fixing this and lowering the G1 remark times when class >>>> redefinition is used. >>>> >>>> I'm only reviewing the GC specific parts: >>>> >>>> On 2015-03-09 21:57, Coleen Phillimore wrote: >>>>> Summary: Only do full metadata walk during class redefinition and >>>>> only walk handles during class unloading. >>>>> >>>>> This change decouples metadata walking for redefinition and class >>>>> unloading, so that class unloading for G1 doesn't walk the code >>>>> cache. It also decouples GC and on_stack marking in the code cache. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ >>>> >>>> >>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/classfile/metadataOnStackMark.cpp.frames.html >>>> >>>> >>>> There are Atomic calls left to handle concurrent retiring of >>>> buffers. Do you want to keep it?: >>> >>> I didn't know whether I should or not. I suppose we should trust >>> our source code control system in case we ever need to do this >>> concurrently again. I'll remove the concurrency - it makes the code >>> a bit simpler. The code to do chunked lists is still good though, >>> so I'm glad you added that as a utility class. >>>> >>>> 97 void MetadataOnStackMark::retire_buffer(MetadataOnStackBuffer* >>>> buffer) { >>>> 98 if (buffer == NULL) { >>>> 99 return; >>>> 100 } >>>> 101 >>>> 102 MetadataOnStackBuffer* old_head; >>>> 103 >>>> 104 do { >>>> 105 old_head = const_cast(_used_buffers); >>>> 106 buffer->set_next_used(old_head); >>>> 107 } while (Atomic::cmpxchg_ptr(buffer, &_used_buffers, >>>> old_head) != old_head); >>>> 108 } >>>> >>>> There's also some Atomic code in accessFlags that were added to >>>> support concurrent mark_on_stack calls. Maybe you want to get rid >>>> of that code as well? >>> >>> I like how you changed it so that the cpool and method is only >>> recorded if it's not already marked. That probably saves a lot of >>> time and space. >>>> >>>> >>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.cdiff.html >>>> >>>> >>>> Could you get rid of the pre/post_work_verification functions? They >>>> were only added to be able to verify the MetadataOnStackMark state, >>>> and is not needed anymore. >>>> >>>> void pre_work_verification() { >>>> - >>>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>>> "Should be empty"); >>>> } >>>> void post_work_verification() { >>>> - >>>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>>> "Should be empty"); >>>> } >>>> >>>> >>> >>> Okay, thanks. I didn't know if you'd prefer that. >>> >>>> >>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/runtime/thread.cpp.frames.html >>>> >>>> >>>> 4105 void Threads::metadata_handles_do(void f(Metadata*)) { >>>> 4106 // Only walk the Handles in Thread. >>>> 4107 ALL_JAVA_THREADS(p) { >>>> 4108 p->metadata_handles_do(f); >>>> 4109 } >>>> 4110 } >>>> >>>> This only walks metadata handles in the Java threads. Don't we have >>>> metadata handles in the VM Thread? >>>> >>>> >>> >>> Hm. We never walked non-Java threads before but yes, we could have >>> Metadata handles on these threads. Wow, thanks for finding this >>> bug! I think this should walk GC threads too (no?) >>> >>>> >>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html >>>> >>>> >>>> Could you motivate why only Metadata induced Full GCs need to do >>>> this unloading? >>>> >>>> 268 // If redefinition, make a pass over the metadata to find >>>> any that >>>> 269 // can be marked to be deallocated >>>> 270 if (JvmtiExport::has_redefined_a_class()) { >>>> 271 ClassLoaderDataGraph::clean_redefinition_metadata(); >>>> 272 } >>>> >>>> Don't we need it for our other Full GCs? >>> >>> No, I don't think we want it for all full GCs. The effect of >>> cleaning out the redefinition metadata is to remove the metadata >>> itself. There may be some mirrors unused from the redefined >>> classes. I suppose you could construct a test case where one of the >>> mirrors is gigantic and causes an out of memory situation in Java heap. >>> >>> The main effect of walking the previous versions is to find more >>> metadata to clean out though, for the next attempt at class unloading. >>>> >>>> I would prefer if this code could be kept inside the GC code or >>>> where it used to be, inside the ClassLoaderDataGraph::do_unloading >>>> function. With the current change, the >>>> VM_CollectForMetadataAllocation class is burdened with the internal >>>> knowledge about class redefinition and class unloading. >>> >>> In ClassLoaderDataGraph::do_unloading() is used when you're not in a >>> Full GC, which is the problem. It can't go there unless we pass >>> down the logic that we're in a full GC or not. I think this is >>> messier. I think this VM_CollectForMetadataAllocation seems the >>> right place to clean up metadata, if needed. One place or another, >>> there has to be knowledge of class redefinition. >>> >>> Actually, my original change had it not called at all, since this >>> code is executed for every class redefinition. Then I thought >>> something should call it... The bias should be to avoid calling >>> this function though because generally it doesn't find very much to do. >>> >>> I thought a better place to call this would be for last-ditch >>> collections, but I didn't know exactly where that was. >>> >>> Coleen >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8061205 >>>>> >>>>> Tested with FMW performance runs. vm.quick.testlist, >>>>> jdk/test/java/lang/instrument tests and JPRT. >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> > From kim.barrett at oracle.com Thu Mar 12 22:27:05 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 12 Mar 2015 18:27:05 -0400 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFA7AED@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <54E4BDBD.6000206@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFA7AED@DEWDFEMB12A.global.corp.sap> Message-ID: <9AE7F2BD-75DB-4585-B232-F94976D4D943@oracle.com> On Mar 6, 2015, at 4:36 AM, Lindenmaier, Goetz wrote: > > Hi Jesper, > > You offered to sponsor this change. I think it's ok to be pushed. > Kim and Volker are ok with it, too, and I ran it through our nightly tests. > These cover quite a range of compilers and platforms. > > This is the final webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.06/ > > I would appreciate a lot if you could sponsor this! During JPRT testing we discovered a change like the following is needed in order to build on 32bit x86 platforms: diff -r 47e882f3a6bc src/share/vm/runtime/virtualspace.cpp --- a/src/share/vm/runtime/virtualspace.cpp Fri Mar 06 13:16:32 2015 -0500 +++ b/src/share/vm/runtime/virtualspace.cpp Thu Mar 12 18:13:52 2015 -0400 @@ -519,12 +519,13 @@ // Calc address range within we try to attach (range of possible start addresses). char *const highest_start = (char *)align_ptr_down(zerobased_max - size, attach_point_alignment); - // SS10 and SS12u1 cannot compile "(char *)UnscaledOopHeapMax - size" on solaris sparc 32-bit: - // "Cannot use int to initialize char*." Introduce aux variable. - char *unscaled_end = (char *)UnscaledOopHeapMax; - unscaled_end -= size; - char *lowest_start = (size < UnscaledOopHeapMax) ? - MAX2(unscaled_end, aligned_heap_base_min_address) : aligned_heap_base_min_address; + // Need to be careful about size being guaranteed to be less + // than UnscaledOopHeapMax due to type constraints. + char *lowest_start = aligned_heap_base_min_address; + uint64_t unscaled_end = UnscaledOopHeapMax - size; + if (unscaled_end < UnscaledOopHeapMax) { // unscaled_end wrapped if size is large + lowest_start = MAX2(lowest_start, (char*)unscaled_end); + } lowest_start = (char *)align_ptr_up(lowest_start, attach_point_alignment); try_reserve_range(highest_start, lowest_start, attach_point_alignment, aligned_heap_base_min_address, zerobased_max, size, alignment, large); The problem is that UnscaledOopHeapMax is a uint64_t with a value of 2^32. On a 32bit platform, with size_t being of the same size as uint32_t, all possible values for "size" are < UnscaledOopHeapMax. And that triggers the newly enabled warning. There are many possible ways to deal with this. I could pretty easily be convinced to use something else. Can we get the requisite reviewers for this additional change? And have it added to the patch / webrev / whatever that will be handed off to Jesper for pushing? Also, the webrev.06 doesn't apply entirely cleanly to the current tip of hs-comp. From mark.reinhold at oracle.com Fri Mar 13 00:12:53 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Mar 2015 17:12:53 -0700 (PDT) Subject: JEP 242: JVM Trace Events for Failed Allocations Message-ID: <20150313001253.D0CDF51BC0@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/242 - Mark From david.holmes at oracle.com Fri Mar 13 01:55:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2015 11:55:14 +1000 Subject: [8u60] Backport approval: 8027914: Client JVM silently exit with fail exit code when running in compact(1, 2) with options -Dcom.sun.management and -XX:+ManagementServer Message-ID: <55024382.6010704@oracle.com> Please approve this simple backport to 8u60, the 9 changeset imported cleanly: bug: https://bugs.openjdk.java.net/browse/JDK-8027914 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6b2bfaef5a61 Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010014.html Thanks, David From david.holmes at oracle.com Fri Mar 13 02:10:59 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2015 12:10:59 +1000 Subject: [8u60] Backport approval: 8043770: File leak in MemNotifyThread::start() in hotspot.src.os.linux.vm.os_linux.cpp Message-ID: <55024733.9010609@oracle.com> Please approve this simple backport to 8u60. The 9 changeset applied cleanly. bug: https://bugs.openjdk.java.net/browse/JDK-8043770 9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-October/012886.html Thanks, David From serguei.spitsyn at oracle.com Fri Mar 13 05:27:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Mar 2015 22:27:54 -0700 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. Message-ID: <5502755A.5060309@oracle.com> Please, review the jdk 9 fix for: https://bugs.openjdk.java.net/browse/JDK-8067662 Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ Open webrev for unit test update: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ Summary: An NPE is trown in a thread dumping via JMX when doing CPU profiling in NetBeans Profiler and VisualVM. The issue is that the methods and related klass versions are not kept alive if a class redefinition takes place between catching a Throwable and taking a thread dump. It can result in loosing an obsolete method, and so, the reconstruction of method name becomes impossible. In such a case, the null reference is returned instead of a valid method name. The solution is to use current klass version and method orig_idnum instead of ordinary method idnum to find required method pointer. In the worst case when the related klass version is gone (was not included to or was removed from the previous_versions linked list), a saved method name CP index of the latest klass version can be used to restore the method name. The footprint extra overhead for this approach is u2 per stack frame. The plan is also to backport the fix to 8u60. Testing: In progress: nsk redefine classes tests, JTREG java/lang/instrument Thanks, Serguei From goetz.lindenmaier at sap.com Fri Mar 13 10:03:02 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Mar 2015 10:03:02 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <9AE7F2BD-75DB-4585-B232-F94976D4D943@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <54E4BDBD.6000206@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFA7AED@DEWDFEMB12A.global.corp.sap> <9AE7F2BD-75DB-4585-B232-F94976D4D943@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB3231@DEWDFEMB12A.global.corp.sap> Hi Kim, Jesper, thanks for dealing with this. I made a new webrev, rebased and including your patch, Kim: http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.07/ Jesper, I don't care whether you push this webrev or one you assembled yourself - whatever is less trouble for you. Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Thursday, March 12, 2015 11:27 PM To: Lindenmaier, Goetz Cc: Jesper Wilhelmsson; hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Mar 6, 2015, at 4:36 AM, Lindenmaier, Goetz wrote: > > Hi Jesper, > > You offered to sponsor this change. I think it's ok to be pushed. > Kim and Volker are ok with it, too, and I ran it through our nightly tests. > These cover quite a range of compilers and platforms. > > This is the final webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.06/ > > I would appreciate a lot if you could sponsor this! During JPRT testing we discovered a change like the following is needed in order to build on 32bit x86 platforms: diff -r 47e882f3a6bc src/share/vm/runtime/virtualspace.cpp --- a/src/share/vm/runtime/virtualspace.cpp Fri Mar 06 13:16:32 2015 -0500 +++ b/src/share/vm/runtime/virtualspace.cpp Thu Mar 12 18:13:52 2015 -0400 @@ -519,12 +519,13 @@ // Calc address range within we try to attach (range of possible start addresses). char *const highest_start = (char *)align_ptr_down(zerobased_max - size, attach_point_alignment); - // SS10 and SS12u1 cannot compile "(char *)UnscaledOopHeapMax - size" on solaris sparc 32-bit: - // "Cannot use int to initialize char*." Introduce aux variable. - char *unscaled_end = (char *)UnscaledOopHeapMax; - unscaled_end -= size; - char *lowest_start = (size < UnscaledOopHeapMax) ? - MAX2(unscaled_end, aligned_heap_base_min_address) : aligned_heap_base_min_address; + // Need to be careful about size being guaranteed to be less + // than UnscaledOopHeapMax due to type constraints. + char *lowest_start = aligned_heap_base_min_address; + uint64_t unscaled_end = UnscaledOopHeapMax - size; + if (unscaled_end < UnscaledOopHeapMax) { // unscaled_end wrapped if size is large + lowest_start = MAX2(lowest_start, (char*)unscaled_end); + } lowest_start = (char *)align_ptr_up(lowest_start, attach_point_alignment); try_reserve_range(highest_start, lowest_start, attach_point_alignment, aligned_heap_base_min_address, zerobased_max, size, alignment, large); The problem is that UnscaledOopHeapMax is a uint64_t with a value of 2^32. On a 32bit platform, with size_t being of the same size as uint32_t, all possible values for "size" are < UnscaledOopHeapMax. And that triggers the newly enabled warning. There are many possible ways to deal with this. I could pretty easily be convinced to use something else. Can we get the requisite reviewers for this additional change? And have it added to the patch / webrev / whatever that will be handed off to Jesper for pushing? Also, the webrev.06 doesn't apply entirely cleanly to the current tip of hs-comp. From jesper.wilhelmsson at oracle.com Fri Mar 13 12:45:40 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 13 Mar 2015 13:45:40 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> Message-ID: <5502DBF4.9040508@oracle.com> Hi Kim and Thomas, Thanks for the reviews! A new webrev is available here: http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.02/ There is an incremental diff as well with the latest changes suggested by you. Thanks, /Jesper Kim Barrett skrev den 11/3/15 18:48: > On Mar 11, 2015, at 9:54 AM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> Please review this change to make most flags handling memory sizes to be of type size_t. Flags dealing with code heap and code cache are not included in this change. Se the bug for details. >> >> The change is surprisingly small considering the amount of flags changed. Most variables around these flags was already of type size_t so there are only a few places where related code had to change in some way. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074459 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.01/ >> >> Testing: jprt, jtreg tests >> >> Thanks, >> /Jesper > > Looks good. > > Just a couple of minor issues, plus a new CR to file for a > pre-existing problem I noticed during the review. > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1RemSet.cpp > src/share/vm/gc_implementation/g1/g1_globals.hpp > > Update copyright. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/sweeper.cpp > > No changes, other than copyright update? > > ------------------------------------------------------------------------------ > src/share/vm/utilities/ostream.hpp > > 253 ((GCLogFileSize != 0) && ((size_t)_bytes_written >= GCLogFileSize)); > [changed cast of _bytes_written from uintx to size_t] > > On a 32bit platform this is, and always has been, a narrowing > conversion, because _bytes_written is declared to be of type > jlong. But GCLogFileSize is of type size_t (was uintx). If, on a > 32bit platform, GCLogFileSize were set to something large, like > (1 << 32) - 1 and the log grew large, rotation would probably not > occur as expected. > > This is a pre-existing problem, and should be dealt with via a > separate CR. > > ------------------------------------------------------------------------------ > From jesper.wilhelmsson at oracle.com Fri Mar 13 12:55:56 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 13 Mar 2015 13:55:56 +0100 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB3231@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <54E4BDBD.6000206@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFA7AED@DEWDFEMB12A.global.corp.sap> <9AE7F2BD-75DB-4585-B232-F94976D4D943@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB3231@DEWDFEMB12A.global.corp.sap> Message-ID: <5502DE5C.1010907@oracle.com> Lindenmaier, Goetz skrev den 13/3/15 11:03: > Hi Kim, Jesper, > > thanks for dealing with this. > I made a new webrev, rebased and including your patch, Kim: > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.07/ > > Jesper, I don't care whether you push this webrev or one you assembled > yourself - whatever is less trouble for you. I'll use the patch from the webrev. Thanks for updating it! /Jesper > > Best regards, > Goetz. > > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Thursday, March 12, 2015 11:27 PM > To: Lindenmaier, Goetz > Cc: Jesper Wilhelmsson; hotspot-dev Source Developers > Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. > > On Mar 6, 2015, at 4:36 AM, Lindenmaier, Goetz wrote: >> >> Hi Jesper, >> >> You offered to sponsor this change. I think it's ok to be pushed. >> Kim and Volker are ok with it, too, and I ran it through our nightly tests. >> These cover quite a range of compilers and platforms. >> >> This is the final webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.06/ >> >> I would appreciate a lot if you could sponsor this! > > During JPRT testing we discovered a change like the following is > needed in order to build on 32bit x86 platforms: > > diff -r 47e882f3a6bc src/share/vm/runtime/virtualspace.cpp > --- a/src/share/vm/runtime/virtualspace.cpp Fri Mar 06 13:16:32 2015 -0500 > +++ b/src/share/vm/runtime/virtualspace.cpp Thu Mar 12 18:13:52 2015 -0400 > @@ -519,12 +519,13 @@ > > // Calc address range within we try to attach (range of possible start addresses). > char *const highest_start = (char *)align_ptr_down(zerobased_max - size, attach_point_alignment); > - // SS10 and SS12u1 cannot compile "(char *)UnscaledOopHeapMax - size" on solaris sparc 32-bit: > - // "Cannot use int to initialize char*." Introduce aux variable. > - char *unscaled_end = (char *)UnscaledOopHeapMax; > - unscaled_end -= size; > - char *lowest_start = (size < UnscaledOopHeapMax) ? > - MAX2(unscaled_end, aligned_heap_base_min_address) : aligned_heap_base_min_address; > + // Need to be careful about size being guaranteed to be less > + // than UnscaledOopHeapMax due to type constraints. > + char *lowest_start = aligned_heap_base_min_address; > + uint64_t unscaled_end = UnscaledOopHeapMax - size; > + if (unscaled_end < UnscaledOopHeapMax) { // unscaled_end wrapped if size is large > + lowest_start = MAX2(lowest_start, (char*)unscaled_end); > + } > lowest_start = (char *)align_ptr_up(lowest_start, attach_point_alignment); > try_reserve_range(highest_start, lowest_start, attach_point_alignment, > aligned_heap_base_min_address, zerobased_max, size, alignment, large); > > The problem is that UnscaledOopHeapMax is a uint64_t with a value of > 2^32. On a 32bit platform, with size_t being of the same size as > uint32_t, all possible values for "size" are < UnscaledOopHeapMax. > And that triggers the newly enabled warning. > > There are many possible ways to deal with this. I could pretty easily > be convinced to use something else. > > Can we get the requisite reviewers for this additional change? And > have it added to the patch / webrev / whatever that will be handed off > to Jesper for pushing? > > Also, the webrev.06 doesn't apply entirely cleanly to the current tip > of hs-comp. > From stefan.karlsson at oracle.com Fri Mar 13 13:52:18 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Mar 2015 14:52:18 +0100 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <5501D812.4070105@oracle.com> References: <54FE094B.1080009@oracle.com> <54FF1ADA.9080604@oracle.com> <54FF4B1C.3090307@oracle.com> <5500AA16.1000302@oracle.com> <55018FF2.8070202@oracle.com> <5501D812.4070105@oracle.com> Message-ID: <5502EB92.4050308@oracle.com> On 2015-03-12 19:16, Coleen Phillimore wrote: > > Hi, > > On 3/12/15, 9:09 AM, Stefan Karlsson wrote: >> Hi Coleen, >> >> On 2015-03-11 21:48, Coleen Phillimore wrote: >>> >>> Stefan, >>> >>> I made the changes you suggested. >> >> Thanks. >> >>> I also moved purge_previous_versions conditionally back to class >>> unloading, where G1 doesn't do this until full GC. >> >> Thanks. >> >>> Do you prefer this to calling the separate function for >>> ClassLoaderDataGraph::clean_redefinition_metadata()? I thought with >>> a separate function we could be more judicious where to call it, but >>> we can also add conditions to ClassLoaderDataGraph::do_unloading() >>> to avoid metadata walking. >>> >>> http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/ >> >> http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/src/share/vm/classfile/classLoaderData.cpp.udiff.html >> >> With this code: >> while (data != NULL) { >> if (data->is_alive(is_alive_closure)) { >> *+ // clean metaspace* >> *+ if (walk_all_metadata) {* >> *+ data->classes_do(InstanceKlass::purge_previous_versions);* >> *+ }* >> *+ data->free_deallocate_list();* >> >> are you reintroducing the bug that Roland fixed with the follwing >> change:: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c3388a74a6fb > > No, I moved clean_weak_method_links to the end of redefinition and > clean MethodData to not have any old methods (not just ones on > stack). This cleaning used to be inside of purge_previous_versions, > which is why we needed the loop to deallocate after all the classes > had called purge_previous_versions. > > I had to take out the assert that used to be clean_weak_method_links > because it was confusing me. I don't think it was verifying anything > since all the methods aren't marked is_old until all the classes are > redefined, and they're cleaned out then. > > Thanks - I'm glad you remembered that bug. Thanks for explaining. The GC parts looks good. I'll let others Review the actual class redefinition parts. Thanks, StefanK > > Coleen > >> >> + if (has_redefined_a_class) { >> + // purge_previous_versions also cleans weak method links. Because >> + // one method's MDO can reference another method from another >> + // class loader, we need to first clean weak method links for all >> + // class loaders here. Below, we can then free redefined methods >> + // for all class loaders. >> + while (data != NULL) { >> + if (data->is_alive(is_alive_closure)) { >> + data->classes_do(InstanceKlass::purge_previous_versions); >> + } >> + data = data->next(); >> + } >> + } >> + data = _head; >> while (data != NULL) { >> if (data->is_alive(is_alive_closure)) { >> - if (has_redefined_a_class) { >> - data->classes_do(InstanceKlass::purge_previous_versions); >> - } >> >> Thanks, >> StefanK >> >>> >>> I've rerun all the class redefinition tests with -XX:+UseG1GC and >>> with the default collector. >>> >>> Thanks, >>> Coleen >>> >>> On 3/10/15, 3:50 PM, Coleen Phillimore wrote: >>>> >>>> Stefan, Thank you for reviewing this so quickly! >>>> >>>> On 3/10/15, 12:24 PM, Stefan Karlsson wrote: >>>>> Hi Coleen, >>>>> >>>>> Thanks for fixing this and lowering the G1 remark times when class >>>>> redefinition is used. >>>>> >>>>> I'm only reviewing the GC specific parts: >>>>> >>>>> On 2015-03-09 21:57, Coleen Phillimore wrote: >>>>>> Summary: Only do full metadata walk during class redefinition and >>>>>> only walk handles during class unloading. >>>>>> >>>>>> This change decouples metadata walking for redefinition and class >>>>>> unloading, so that class unloading for G1 doesn't walk the code >>>>>> cache. It also decouples GC and on_stack marking in the code cache. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/classfile/metadataOnStackMark.cpp.frames.html >>>>> >>>>> >>>>> There are Atomic calls left to handle concurrent retiring of >>>>> buffers. Do you want to keep it?: >>>> >>>> I didn't know whether I should or not. I suppose we should trust >>>> our source code control system in case we ever need to do this >>>> concurrently again. I'll remove the concurrency - it makes the >>>> code a bit simpler. The code to do chunked lists is still good >>>> though, so I'm glad you added that as a utility class. >>>>> >>>>> 97 void >>>>> MetadataOnStackMark::retire_buffer(MetadataOnStackBuffer* buffer) { >>>>> 98 if (buffer == NULL) { >>>>> 99 return; >>>>> 100 } >>>>> 101 >>>>> 102 MetadataOnStackBuffer* old_head; >>>>> 103 >>>>> 104 do { >>>>> 105 old_head = >>>>> const_cast(_used_buffers); >>>>> 106 buffer->set_next_used(old_head); >>>>> 107 } while (Atomic::cmpxchg_ptr(buffer, &_used_buffers, >>>>> old_head) != old_head); >>>>> 108 } >>>>> >>>>> There's also some Atomic code in accessFlags that were added to >>>>> support concurrent mark_on_stack calls. Maybe you want to get rid >>>>> of that code as well? >>>> >>>> I like how you changed it so that the cpool and method is only >>>> recorded if it's not already marked. That probably saves a lot of >>>> time and space. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.cdiff.html >>>>> >>>>> >>>>> Could you get rid of the pre/post_work_verification functions? >>>>> They were only added to be able to verify the MetadataOnStackMark >>>>> state, and is not needed anymore. >>>>> >>>>> void pre_work_verification() { >>>>> - >>>>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>>>> "Should be empty"); >>>>> } >>>>> void post_work_verification() { >>>>> - >>>>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>>>> "Should be empty"); >>>>> } >>>>> >>>>> >>>> >>>> Okay, thanks. I didn't know if you'd prefer that. >>>> >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/runtime/thread.cpp.frames.html >>>>> >>>>> >>>>> 4105 void Threads::metadata_handles_do(void f(Metadata*)) { >>>>> 4106 // Only walk the Handles in Thread. >>>>> 4107 ALL_JAVA_THREADS(p) { >>>>> 4108 p->metadata_handles_do(f); >>>>> 4109 } >>>>> 4110 } >>>>> >>>>> This only walks metadata handles in the Java threads. Don't we >>>>> have metadata handles in the VM Thread? >>>>> >>>>> >>>> >>>> Hm. We never walked non-Java threads before but yes, we could >>>> have Metadata handles on these threads. Wow, thanks for finding >>>> this bug! I think this should walk GC threads too (no?) >>>> >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html >>>>> >>>>> >>>>> Could you motivate why only Metadata induced Full GCs need to do >>>>> this unloading? >>>>> >>>>> 268 // If redefinition, make a pass over the metadata to find >>>>> any that >>>>> 269 // can be marked to be deallocated >>>>> 270 if (JvmtiExport::has_redefined_a_class()) { >>>>> 271 ClassLoaderDataGraph::clean_redefinition_metadata(); >>>>> 272 } >>>>> >>>>> Don't we need it for our other Full GCs? >>>> >>>> No, I don't think we want it for all full GCs. The effect of >>>> cleaning out the redefinition metadata is to remove the metadata >>>> itself. There may be some mirrors unused from the redefined >>>> classes. I suppose you could construct a test case where one of >>>> the mirrors is gigantic and causes an out of memory situation in >>>> Java heap. >>>> >>>> The main effect of walking the previous versions is to find more >>>> metadata to clean out though, for the next attempt at class unloading. >>>>> >>>>> I would prefer if this code could be kept inside the GC code or >>>>> where it used to be, inside the ClassLoaderDataGraph::do_unloading >>>>> function. With the current change, the >>>>> VM_CollectForMetadataAllocation class is burdened with the >>>>> internal knowledge about class redefinition and class unloading. >>>> >>>> In ClassLoaderDataGraph::do_unloading() is used when you're not in >>>> a Full GC, which is the problem. It can't go there unless we pass >>>> down the logic that we're in a full GC or not. I think this is >>>> messier. I think this VM_CollectForMetadataAllocation seems the >>>> right place to clean up metadata, if needed. One place or >>>> another, there has to be knowledge of class redefinition. >>>> >>>> Actually, my original change had it not called at all, since this >>>> code is executed for every class redefinition. Then I thought >>>> something should call it... The bias should be to avoid calling >>>> this function though because generally it doesn't find very much to >>>> do. >>>> >>>> I thought a better place to call this would be for last-ditch >>>> collections, but I didn't know exactly where that was. >>>> >>>> Coleen >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8061205 >>>>>> >>>>>> Tested with FMW performance runs. vm.quick.testlist, >>>>>> jdk/test/java/lang/instrument tests and JPRT. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>> >>> >> > From erik.joelsson at oracle.com Fri Mar 13 14:08:14 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Mar 2015 15:08:14 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS Message-ID: <5502EF4E.2060006@oracle.com> Hello, While working on the new Hotspot makefiles in build-infra I noticed this problem. When introducing devkits for Solaris, we rely on the variables EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT specific flags into the hotspot build. However, these flags aren't consistently used in the Hotspot build for all the native libraries. This patch adds the variables to all missing compile and link command lines. It also fixes an issue with saproc.so where the debug info was created off one of the object files instead of the library. Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ /Erik From tim.bell at oracle.com Fri Mar 13 15:55:04 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 13 Mar 2015 08:55:04 -0700 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <5502EF4E.2060006@oracle.com> References: <5502EF4E.2060006@oracle.com> Message-ID: <55030858.8020003@oracle.com> Hello Erik: > While working on the new Hotspot makefiles in build-infra I noticed > this problem. When introducing devkits for Solaris, we rely on the > variables EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate > the SYSROOT specific flags into the hotspot build. However, these > flags aren't consistently used in the Hotspot build for all the native > libraries. > > This patch adds the variables to all missing compile and link command > lines. It also fixes an issue with saproc.so where the debug info was > created off one of the object files instead of the library. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 > Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ Looks good to me. Tim From coleen.phillimore at oracle.com Fri Mar 13 16:33:19 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 Mar 2015 12:33:19 -0400 Subject: RFR (L) 8061205: MetadataOnStackMark only needs to walk code cache during class redefinition In-Reply-To: <5502EB92.4050308@oracle.com> References: <54FE094B.1080009@oracle.com> <54FF1ADA.9080604@oracle.com> <54FF4B1C.3090307@oracle.com> <5500AA16.1000302@oracle.com> <55018FF2.8070202@oracle.com> <5501D812.4070105@oracle.com> <5502EB92.4050308@oracle.com> Message-ID: <5503114F.6020902@oracle.com> Thanks Stefan. Serguei reviewed the class redefinition parts. Coleen On 3/13/15, 9:52 AM, Stefan Karlsson wrote: > > On 2015-03-12 19:16, Coleen Phillimore wrote: >> >> Hi, >> >> On 3/12/15, 9:09 AM, Stefan Karlsson wrote: >>> Hi Coleen, >>> >>> On 2015-03-11 21:48, Coleen Phillimore wrote: >>>> >>>> Stefan, >>>> >>>> I made the changes you suggested. >>> >>> Thanks. >>> >>>> I also moved purge_previous_versions conditionally back to class >>>> unloading, where G1 doesn't do this until full GC. >>> >>> Thanks. >>> >>>> Do you prefer this to calling the separate function for >>>> ClassLoaderDataGraph::clean_redefinition_metadata()? I thought >>>> with a separate function we could be more judicious where to call >>>> it, but we can also add conditions to >>>> ClassLoaderDataGraph::do_unloading() to avoid metadata walking. >>>> >>>> http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/ >>> >>> http://javaweb.us.oracle.com/~cphillim/webrev/8061205.03/src/share/vm/classfile/classLoaderData.cpp.udiff.html >>> >>> With this code: >>> while (data != NULL) { >>> if (data->is_alive(is_alive_closure)) { >>> *+ // clean metaspace* >>> *+ if (walk_all_metadata) {* >>> *+ data->classes_do(InstanceKlass::purge_previous_versions);* >>> *+ }* >>> *+ data->free_deallocate_list();* >>> >>> are you reintroducing the bug that Roland fixed with the follwing >>> change:: >>> >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c3388a74a6fb >> >> No, I moved clean_weak_method_links to the end of redefinition and >> clean MethodData to not have any old methods (not just ones on >> stack). This cleaning used to be inside of purge_previous_versions, >> which is why we needed the loop to deallocate after all the classes >> had called purge_previous_versions. >> >> I had to take out the assert that used to be clean_weak_method_links >> because it was confusing me. I don't think it was verifying anything >> since all the methods aren't marked is_old until all the classes are >> redefined, and they're cleaned out then. >> >> Thanks - I'm glad you remembered that bug. > > Thanks for explaining. The GC parts looks good. I'll let others Review > the actual class redefinition parts. > > > Thanks, > StefanK > >> >> Coleen >> >>> >>> + if (has_redefined_a_class) { >>> + // purge_previous_versions also cleans weak method links. Because >>> + // one method's MDO can reference another method from another >>> + // class loader, we need to first clean weak method links for all >>> + // class loaders here. Below, we can then free redefined methods >>> + // for all class loaders. >>> + while (data != NULL) { >>> + if (data->is_alive(is_alive_closure)) { >>> + data->classes_do(InstanceKlass::purge_previous_versions); >>> + } >>> + data = data->next(); >>> + } >>> + } >>> + data = _head; >>> while (data != NULL) { >>> if (data->is_alive(is_alive_closure)) { >>> - if (has_redefined_a_class) { >>> - data->classes_do(InstanceKlass::purge_previous_versions); >>> - } >>> >>> Thanks, >>> StefanK >>> >>>> >>>> I've rerun all the class redefinition tests with -XX:+UseG1GC and >>>> with the default collector. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 3/10/15, 3:50 PM, Coleen Phillimore wrote: >>>>> >>>>> Stefan, Thank you for reviewing this so quickly! >>>>> >>>>> On 3/10/15, 12:24 PM, Stefan Karlsson wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> Thanks for fixing this and lowering the G1 remark times when >>>>>> class redefinition is used. >>>>>> >>>>>> I'm only reviewing the GC specific parts: >>>>>> >>>>>> On 2015-03-09 21:57, Coleen Phillimore wrote: >>>>>>> Summary: Only do full metadata walk during class redefinition >>>>>>> and only walk handles during class unloading. >>>>>>> >>>>>>> This change decouples metadata walking for redefinition and >>>>>>> class unloading, so that class unloading for G1 doesn't walk the >>>>>>> code cache. It also decouples GC and on_stack marking in the >>>>>>> code cache. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8061205/ >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/classfile/metadataOnStackMark.cpp.frames.html >>>>>> >>>>>> >>>>>> There are Atomic calls left to handle concurrent retiring of >>>>>> buffers. Do you want to keep it?: >>>>> >>>>> I didn't know whether I should or not. I suppose we should trust >>>>> our source code control system in case we ever need to do this >>>>> concurrently again. I'll remove the concurrency - it makes the >>>>> code a bit simpler. The code to do chunked lists is still good >>>>> though, so I'm glad you added that as a utility class. >>>>>> >>>>>> 97 void >>>>>> MetadataOnStackMark::retire_buffer(MetadataOnStackBuffer* buffer) { >>>>>> 98 if (buffer == NULL) { >>>>>> 99 return; >>>>>> 100 } >>>>>> 101 >>>>>> 102 MetadataOnStackBuffer* old_head; >>>>>> 103 >>>>>> 104 do { >>>>>> 105 old_head = >>>>>> const_cast(_used_buffers); >>>>>> 106 buffer->set_next_used(old_head); >>>>>> 107 } while (Atomic::cmpxchg_ptr(buffer, &_used_buffers, >>>>>> old_head) != old_head); >>>>>> 108 } >>>>>> >>>>>> There's also some Atomic code in accessFlags that were added to >>>>>> support concurrent mark_on_stack calls. Maybe you want to get rid >>>>>> of that code as well? >>>>> >>>>> I like how you changed it so that the cpool and method is only >>>>> recorded if it's not already marked. That probably saves a lot of >>>>> time and space. >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.cdiff.html >>>>>> >>>>>> >>>>>> Could you get rid of the pre/post_work_verification functions? >>>>>> They were only added to be able to verify the MetadataOnStackMark >>>>>> state, and is not needed anymore. >>>>>> >>>>>> void pre_work_verification() { >>>>>> - >>>>>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>>>>> "Should be empty"); >>>>>> } >>>>>> void post_work_verification() { >>>>>> - >>>>>> assert(!MetadataOnStackMark::has_buffer_for_thread(Thread::current()), >>>>>> "Should be empty"); >>>>>> } >>>>>> >>>>>> >>>>> >>>>> Okay, thanks. I didn't know if you'd prefer that. >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/runtime/thread.cpp.frames.html >>>>>> >>>>>> >>>>>> 4105 void Threads::metadata_handles_do(void f(Metadata*)) { >>>>>> 4106 // Only walk the Handles in Thread. >>>>>> 4107 ALL_JAVA_THREADS(p) { >>>>>> 4108 p->metadata_handles_do(f); >>>>>> 4109 } >>>>>> 4110 } >>>>>> >>>>>> This only walks metadata handles in the Java threads. Don't we >>>>>> have metadata handles in the VM Thread? >>>>>> >>>>>> >>>>> >>>>> Hm. We never walked non-Java threads before but yes, we could >>>>> have Metadata handles on these threads. Wow, thanks for finding >>>>> this bug! I think this should walk GC threads too (no?) >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8061205/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html >>>>>> >>>>>> >>>>>> Could you motivate why only Metadata induced Full GCs need to do >>>>>> this unloading? >>>>>> >>>>>> 268 // If redefinition, make a pass over the metadata to find >>>>>> any that >>>>>> 269 // can be marked to be deallocated >>>>>> 270 if (JvmtiExport::has_redefined_a_class()) { >>>>>> 271 ClassLoaderDataGraph::clean_redefinition_metadata(); >>>>>> 272 } >>>>>> >>>>>> Don't we need it for our other Full GCs? >>>>> >>>>> No, I don't think we want it for all full GCs. The effect of >>>>> cleaning out the redefinition metadata is to remove the metadata >>>>> itself. There may be some mirrors unused from the redefined >>>>> classes. I suppose you could construct a test case where one of >>>>> the mirrors is gigantic and causes an out of memory situation in >>>>> Java heap. >>>>> >>>>> The main effect of walking the previous versions is to find more >>>>> metadata to clean out though, for the next attempt at class >>>>> unloading. >>>>>> >>>>>> I would prefer if this code could be kept inside the GC code or >>>>>> where it used to be, inside the >>>>>> ClassLoaderDataGraph::do_unloading function. With the current >>>>>> change, the VM_CollectForMetadataAllocation class is burdened >>>>>> with the internal knowledge about class redefinition and class >>>>>> unloading. >>>>> >>>>> In ClassLoaderDataGraph::do_unloading() is used when you're not in >>>>> a Full GC, which is the problem. It can't go there unless we pass >>>>> down the logic that we're in a full GC or not. I think this is >>>>> messier. I think this VM_CollectForMetadataAllocation seems the >>>>> right place to clean up metadata, if needed. One place or >>>>> another, there has to be knowledge of class redefinition. >>>>> >>>>> Actually, my original change had it not called at all, since this >>>>> code is executed for every class redefinition. Then I thought >>>>> something should call it... The bias should be to avoid calling >>>>> this function though because generally it doesn't find very much >>>>> to do. >>>>> >>>>> I thought a better place to call this would be for last-ditch >>>>> collections, but I didn't know exactly where that was. >>>>> >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8061205 >>>>>>> >>>>>>> Tested with FMW performance runs. vm.quick.testlist, >>>>>>> jdk/test/java/lang/instrument tests and JPRT. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>> >>>>> >>>> >>> >> > From harold.seigel at oracle.com Fri Mar 13 17:35:24 2015 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 13 Mar 2015 13:35:24 -0400 Subject: RFR 8074717: Merge interp_masm files for x86 _32 and _64 In-Reply-To: <54FE0435.1000904@oracle.com> References: <54FE0435.1000904@oracle.com> Message-ID: <55031FDC.4030600@oracle.com> Hi Coleen, The changes look good but I have a few questions. 1. Why were rsi and rdi sometimes replaced with r13 and r14, and other times with esi and edi, or bcp_register? 2. Do you plan to delete the "// XXX l ?" comments? 3. How did you choose when to use long vs. ptr instructions? 4. At line 756 in interp_masm_x86_64.cpp, Why do the move here? Why not just unlock_object(rmon) ? 5. At lines 814 and 1601 in interp_masm_x86_64.cpp, why /* */ instead of // for: #endif /* !CC_INTERP */ Thanks, Harold On 3/9/2015 4:36 PM, Coleen Phillimore wrote: > Summary: Merge duplicate code and use #ifdef for non-mergeable sections. > > Inspired by Max's change and because I was working on this with him, > I've merged interp_masm_x86_32 and _64.cpp/hpp files. > > There are two webrevs generated. The first webrev is generated to see > the diffs. Mostly the _64 contents are chosen because the formatting > was better. The second is moving the code into the already existant > interp_masm_x86.cpp/hpp files. > > Ran all jck tests on this and JPRT, also ran NSK vm.quick.testlist > which includes jvmti tests. > > bug link https://bugs.openjdk.java.net/browse/JDK-8074717 > open webrev at http://cr.openjdk.java.net/~coleenp/8074717 > open webrev at http://cr.openjdk.java.net/~coleenp/8074717_2/ > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Mar 13 17:40:43 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 Mar 2015 13:40:43 -0400 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5502755A.5060309@oracle.com> References: <5502755A.5060309@oracle.com> Message-ID: <5503211B.90309@oracle.com> Serguei, This looks good. This works a lot harder to find the original method than the code used to. Thanks, Coleen On 3/13/15, 1:27 AM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8067662 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ > > > Open webrev for unit test update: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ > > > > Summary: > An NPE is trown in a thread dumping via JMX when doing CPU profiling > in NetBeans Profiler and VisualVM. > The issue is that the methods and related klass versions are not > kept alive if a class redefinition > takes place between catching a Throwable and taking a thread dump. > It can result in loosing an obsolete method, and so, the > reconstruction of method name becomes impossible. > In such a case, the null reference is returned instead of a valid > method name. > > The solution is to use current klass version and method orig_idnum > instead of ordinary method idnum > to find required method pointer. In the worst case when the related > klass version is gone > (was not included to or was removed from the previous_versions > linked list), a saved method name > CP index of the latest klass version can be used to restore the > method name. > The footprint extra overhead for this approach is u2 per stack frame. > > The plan is also to backport the fix to 8u60. > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei From coleen.phillimore at oracle.com Fri Mar 13 17:47:40 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 Mar 2015 13:47:40 -0400 Subject: RFR 8074717: Merge interp_masm files for x86 _32 and _64 In-Reply-To: <55031FDC.4030600@oracle.com> References: <54FE0435.1000904@oracle.com> <55031FDC.4030600@oracle.com> Message-ID: <550322BC.8080307@oracle.com> On 3/13/15, 1:35 PM, harold seigel wrote: > Hi Coleen, > > The changes look good but I have a few questions. > > 1. Why were rsi and rdi sometimes replaced with r13 and r14, and other > times with esi and edi, or bcp_register? There was only that bit in the first comment so I fixed the comment and it makes sense now, looks like: // interpreter specific // // Note: No need to save/restore bcp & locals registers // since these are callee saved registers and no blocking/ // GC can happen in leaf calls. // Further Note: DO NOT save/restore bcp/locals. If a caller has // already saved them so that it can use rsi/rdi as temporaries // then a save/restore here will DESTROY the copy the caller // saved! There used to be a save_bcp() that only happened in // the ASSERT path (no restore_bcp). Which caused bizarre failures // when jvm built with ASSERTs. .. then later ... // interpreter specific // LP64: Used to ASSERT that r13/r14 were equal to frame's bcp/locals // but since they may not have been saved (and we don't want to // save them here (see note above) the assert is invalid. It says "interpreter specific" because the compiled code also can call this call_VM_leaf_base function indirectly. > > 2. Do you plan to delete the "// XXX l ?" comments? No, these were preexisting in one of the 64 or 32 bit versions. I'm not going to change this because I don't know the answer... > > 3. How did you choose when to use long vs. ptr instructions? In 32 bits sometimes there's a movptr which is the same as movl . In the 64 bit version, the mov was movl which means that the data was actually 32 bits and not a pointer. So I chose movl. > > 4. At line 756 in interp_masm_x86_64.cpp, Why do the move here? Why > not just unlock_object(rmon) ? On 32 bits robj and rmon are not the same registers and unlock_object has to have rdx. On 64 bits the mov is a nop because the registers are the same and I don't think this affects any performance, so I had the mov be unconditional (without NOT_LP64). > > 5. At lines 814 and 1601 in interp_masm_x86_64.cpp, why /* */ instead > of // for: #endif /* !CC_INTERP */ I fixed those. The 32 bit and 64 bit files were inconsistent about this. Thanks for going through this change! Coleen > > Thanks, Harold > > On 3/9/2015 4:36 PM, Coleen Phillimore wrote: >> Summary: Merge duplicate code and use #ifdef for non-mergeable sections. >> >> Inspired by Max's change and because I was working on this with him, >> I've merged interp_masm_x86_32 and _64.cpp/hpp files. >> >> There are two webrevs generated. The first webrev is generated to >> see the diffs. Mostly the _64 contents are chosen because the >> formatting was better. The second is moving the code into the >> already existant interp_masm_x86.cpp/hpp files. >> >> Ran all jck tests on this and JPRT, also ran NSK vm.quick.testlist >> which includes jvmti tests. >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8074717 >> open webrev at http://cr.openjdk.java.net/~coleenp/8074717 >> open webrev at http://cr.openjdk.java.net/~coleenp/8074717_2/ >> >> Thanks, >> Coleen > From serguei.spitsyn at oracle.com Fri Mar 13 18:36:13 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Mar 2015 11:36:13 -0700 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5503211B.90309@oracle.com> References: <5502755A.5060309@oracle.com> <5503211B.90309@oracle.com> Message-ID: <55032E1D.6080403@oracle.com> Coleen, Thank you for review and great idea to use the method name cp index! However, this approach is going stop working if we get rid of the CP merge in the future. Thanks, Serguei On 3/13/15 10:40 AM, Coleen Phillimore wrote: > > Serguei, > > This looks good. This works a lot harder to find the original method > than the code used to. > > Thanks, > Coleen > > On 3/13/15, 1:27 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ >> >> >> Open webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ >> >> >> >> Summary: >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> The plan is also to backport the fix to 8u60. >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei > From coleen.phillimore at oracle.com Fri Mar 13 18:37:52 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 Mar 2015 14:37:52 -0400 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55032E1D.6080403@oracle.com> References: <5502755A.5060309@oracle.com> <5503211B.90309@oracle.com> <55032E1D.6080403@oracle.com> Message-ID: <55032E80.9060008@oracle.com> On 3/13/15, 2:36 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > Thank you for review and great idea to use the method name cp index! > However, this approach is going stop working if we get rid of the CP > merge in the future. Yes, it will. I was just thinking about how to resolve that. We'll have to brainstorm this in the summer. Coleen > > Thanks, > Serguei > > On 3/13/15 10:40 AM, Coleen Phillimore wrote: >> >> Serguei, >> >> This looks good. This works a lot harder to find the original method >> than the code used to. >> >> Thanks, >> Coleen >> >> On 3/13/15, 1:27 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 9 fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>> >>> >>> Open hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ >>> >>> >>> Open webrev for unit test update: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ >>> >>> >>> >>> Summary: >>> An NPE is trown in a thread dumping via JMX when doing CPU >>> profiling in NetBeans Profiler and VisualVM. >>> The issue is that the methods and related klass versions are not >>> kept alive if a class redefinition >>> takes place between catching a Throwable and taking a thread dump. >>> It can result in loosing an obsolete method, and so, the >>> reconstruction of method name becomes impossible. >>> In such a case, the null reference is returned instead of a valid >>> method name. >>> >>> The solution is to use current klass version and method orig_idnum >>> instead of ordinary method idnum >>> to find required method pointer. In the worst case when the >>> related klass version is gone >>> (was not included to or was removed from the previous_versions >>> linked list), a saved method name >>> CP index of the latest klass version can be used to restore the >>> method name. >>> The footprint extra overhead for this approach is u2 per stack frame. >>> >>> The plan is also to backport the fix to 8u60. >>> >>> Testing: >>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>> >>> >>> Thanks, >>> Serguei >> > From aph at redhat.com Fri Mar 13 18:47:42 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Mar 2015 18:47:42 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods Message-ID: <550330CE.3030607@redhat.com> I've tried to address all the points that have been made. I haven't changed the way the sub-words are read and written because the code I'm seeing is fairly nearly optimal right now and anything more complex runs the risk of tripping inlining limits, thus pessimizing performance. We need a general solution which isn't optimized for special cases but is decent on average and often very good. I think it's close to the best compromise we're going to get. I have changed the javadoc as requested and I have fixed the code in HeapByteBuffer so that it doesn't check the index twice for floating- point put() and get() operations. I have added a jtreg test for HeapByteBuffer which tests it pretty thoroughly. It also, as a consequence, tests the underlying Unsafe methods. I wasn't sure what a separate test for the Unsafe methods would achieve so I didn't write one. OK? http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/ http://cr.openjdk.java.net/~aph/unaligned.jdk.6/ Andrew. From aph at redhat.com Fri Mar 13 18:48:17 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Mar 2015 18:48:17 +0000 Subject: RFR: 8026049: (bf) Intrinsify ByteBuffer.put{Int,Double,Float,...} methods Message-ID: <550330F1.4090604@redhat.com> I've tried to address all the points that have been made. I haven't changed the way the sub-words are read and written because the code I'm seeing is fairly nearly optimal right now and anything more complex runs the risk of tripping inlining limits, thus pessimizing performance. We need a general solution which isn't optimized for special cases but is decent on average and often very good. I think it's close to the best compromise we're going to get. I have changed the javadoc as requested and I have fixed the code in HeapByteBuffer so that it doesn't check the index twice for floating- point put() and get() operations. I have added a jtreg test for HeapByteBuffer which tests it pretty thoroughly. It also, as a consequence, tests the underlying Unsafe methods. I wasn't sure what a separate test for the Unsafe methods would achieve so I didn't write one. OK? http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/ http://cr.openjdk.java.net/~aph/unaligned.jdk.6/ Andrew. From david.holmes at oracle.com Sat Mar 14 00:08:21 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 14 Mar 2015 10:08:21 +1000 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <5502EF4E.2060006@oracle.com> References: <5502EF4E.2060006@oracle.com> Message-ID: <55037BF5.5010700@oracle.com> Hi Erik, On 14/03/2015 12:08 AM, Erik Joelsson wrote: > Hello, > > While working on the new Hotspot makefiles in build-infra I noticed this > problem. When introducing devkits for Solaris, we rely on the variables > EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT > specific flags into the hotspot build. However, these flags aren't > consistently used in the Hotspot build for all the native libraries. > > This patch adds the variables to all missing compile and link command > lines. It also fixes an issue with saproc.so where the debug info was > created off one of the object files instead of the library. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 > Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ For linux we primarily (only?) use these to pass cross-compilation flags and so everything that is compiled generally needs the same flags. Outside of cross-compilation though that doesn't necessarily hold. If someone uses EXTRA_CFLAGS as a general customization mechanism it might only be intended for the primary VM build not for secondary libraries like jsig, dtrace and SA. So I'm not sure that this is the right thing to do as really these variables are not quite what people might expect them to be. In general local customizations are better handled by local editing of the appropriate build file. David > /Erik From forax at univ-mlv.fr Sat Mar 14 11:32:05 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 14 Mar 2015 12:32:05 +0100 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550330CE.3030607@redhat.com> References: <550330CE.3030607@redhat.com> Message-ID: <55041C35.3070406@univ-mlv.fr> Hi Andrew, Looks good to me. R?mi On 03/13/2015 07:47 PM, Andrew Haley wrote: > I've tried to address all the points that have been made. > > I haven't changed the way the sub-words are read and written because > the code I'm seeing is fairly nearly optimal right now and anything > more complex runs the risk of tripping inlining limits, thus > pessimizing performance. We need a general solution which isn't > optimized for special cases but is decent on average and often very > good. I think it's close to the best compromise we're going to get. > > I have changed the javadoc as requested and I have fixed the code in > HeapByteBuffer so that it doesn't check the index twice for floating- > point put() and get() operations. > > I have added a jtreg test for HeapByteBuffer which tests it pretty > thoroughly. It also, as a consequence, tests the underlying Unsafe > methods. I wasn't sure what a separate test for the Unsafe methods > would achieve so I didn't write one. > > OK? > > http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/ > http://cr.openjdk.java.net/~aph/unaligned.jdk.6/ > > Andrew. From dean.long at oracle.com Sat Mar 14 19:34:17 2015 From: dean.long at oracle.com (Dean Long) Date: Sat, 14 Mar 2015 12:34:17 -0700 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <55037BF5.5010700@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> Message-ID: <55048D39.4030403@oracle.com> On 3/13/2015 5:08 PM, David Holmes wrote: > Hi Erik, > > On 14/03/2015 12:08 AM, Erik Joelsson wrote: >> Hello, >> >> While working on the new Hotspot makefiles in build-infra I noticed this >> problem. When introducing devkits for Solaris, we rely on the variables >> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >> specific flags into the hotspot build. However, these flags aren't >> consistently used in the Hotspot build for all the native libraries. >> >> This patch adds the variables to all missing compile and link command >> lines. It also fixes an issue with saproc.so where the debug info was >> created off one of the object files instead of the library. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ > > For linux we primarily (only?) use these to pass cross-compilation > flags and so everything that is compiled generally needs the same flags. > > Outside of cross-compilation though that doesn't necessarily hold. If > someone uses EXTRA_CFLAGS as a general customization mechanism it > might only be intended for the primary VM build not for secondary > libraries like jsig, dtrace and SA. > > So I'm not sure that this is the right thing to do as really these > variables are not quite what people might expect them to be. In > general local customizations are better handled by local editing of > the appropriate build file. > Related to that, I noticed that cross-compiler sysroot flags are being included in jdk/make/gensrc/GensrcMisc.gmk when BUILD_CC and BUILD_LD are used, apparently because these flags get added to CFLAGS by default. Is there such thing as BUILD_CFLAGS that BUILD_CC should use? dl > David > >> /Erik From david.holmes at oracle.com Mon Mar 16 00:40:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Mar 2015 10:40:20 +1000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550330CE.3030607@redhat.com> References: <550330CE.3030607@redhat.com> Message-ID: <55062674.9020407@oracle.com> Andrew, Experimental options are supposed to be opt-in only via UnlockExperimentalVMOptions. You presently have the experimental UseUnalignedAccesses being turned on unconditionally on those architectures that support it. David On 14/03/2015 4:47 AM, Andrew Haley wrote: > I've tried to address all the points that have been made. > > I haven't changed the way the sub-words are read and written because > the code I'm seeing is fairly nearly optimal right now and anything > more complex runs the risk of tripping inlining limits, thus > pessimizing performance. We need a general solution which isn't > optimized for special cases but is decent on average and often very > good. I think it's close to the best compromise we're going to get. > > I have changed the javadoc as requested and I have fixed the code in > HeapByteBuffer so that it doesn't check the index twice for floating- > point put() and get() operations. > > I have added a jtreg test for HeapByteBuffer which tests it pretty > thoroughly. It also, as a consequence, tests the underlying Unsafe > methods. I wasn't sure what a separate test for the Unsafe methods > would achieve so I didn't write one. > > OK? > > http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/ > http://cr.openjdk.java.net/~aph/unaligned.jdk.6/ > > Andrew. > From erik.joelsson at oracle.com Mon Mar 16 08:26:52 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Mar 2015 09:26:52 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <55037BF5.5010700@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> Message-ID: <550693CC.7050300@oracle.com> On 2015-03-14 01:08, David Holmes wrote: > Hi Erik, > > On 14/03/2015 12:08 AM, Erik Joelsson wrote: >> Hello, >> >> While working on the new Hotspot makefiles in build-infra I noticed this >> problem. When introducing devkits for Solaris, we rely on the variables >> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >> specific flags into the hotspot build. However, these flags aren't >> consistently used in the Hotspot build for all the native libraries. >> >> This patch adds the variables to all missing compile and link command >> lines. It also fixes an issue with saproc.so where the debug info was >> created off one of the object files instead of the library. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ > > For linux we primarily (only?) use these to pass cross-compilation > flags and so everything that is compiled generally needs the same flags. > > Outside of cross-compilation though that doesn't necessarily hold. If > someone uses EXTRA_CFLAGS as a general customization mechanism it > might only be intended for the primary VM build not for secondary > libraries like jsig, dtrace and SA. > > So I'm not sure that this is the right thing to do as really these > variables are not quite what people might expect them to be. In > general local customizations are better handled by local editing of > the appropriate build file. > Well, the devkit/sysroot CFLAGS and LDFLAGS should be considered more or less equal to cross compilation arguments. Everything being compiled for the target platform should use them. If EXTRA_CFLAGS is not a good option for providing these compiler options, then it shouldn't be used for cross compilation on linux either. I figured that since we are already using them that way on linux, extending that usage to Solaris would be the right thing to do. If it isn't, should I define a new set of variables for transporting these options for both platforms instead? I still think using EXTRA_*FLAGS is a viable solution for my usecase and that anyone trying to use these variables and expecting them to only apply selectively is on a slippery slope. /Erik > David > >> /Erik From erik.joelsson at oracle.com Mon Mar 16 08:29:48 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Mar 2015 09:29:48 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <55048D39.4030403@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> <55048D39.4030403@oracle.com> Message-ID: <5506947C.6060901@oracle.com> On 2015-03-14 20:34, Dean Long wrote: > > Related to that, I noticed that cross-compiler sysroot flags are being > included in > jdk/make/gensrc/GensrcMisc.gmk when BUILD_CC and BUILD_LD are used, > apparently because these flags get added to CFLAGS by default. Is > there such > thing as BUILD_CFLAGS that BUILD_CC should use? > Yes, this is a problem. We currently have no way of overriding those flags for specific compilations, and I think we should. A workaround is to empty the SYSROOT_*FLAGS variables before calling SetupNativeCompilation when using BUILD_CC. /Erik From aph at redhat.com Mon Mar 16 09:29:47 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 09:29:47 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <55062674.9020407@oracle.com> References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> Message-ID: <5506A28B.3070009@redhat.com> On 16/03/15 00:40, David Holmes wrote: > Experimental options are supposed to be opt-in only via > UnlockExperimentalVMOptions. You presently have the experimental > UseUnalignedAccesses being turned on unconditionally on those > architectures that support it. Well, it works. I guess this could be changed to be a product option, but it's only really needed for testing. And aren't product options supposed to be properly documented for all users? In other words: please don't say "don't do that." Please tell me what I should do instead. All suggestions are welcome, really because I'm rather stuck. Andrew. From paul.sandoz at oracle.com Mon Mar 16 10:03:25 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 16 Mar 2015 11:03:25 +0100 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550330CE.3030607@redhat.com> References: <550330CE.3030607@redhat.com> Message-ID: I am running this patch though our JPRT test system right now. The test looks good, two comments on it: - IMO it does not need the internal PRNG FastRandom, SplittableRandom can be used instead. - I suspect that test needs to be located in the hotspot test area, which likely means it gets run on more "exotic" platforms. Perhaps someone with more knowledge of the test configuration and infrastructure can comment? Paul. On Mar 13, 2015, at 7:47 PM, Andrew Haley wrote: > I've tried to address all the points that have been made. > > I haven't changed the way the sub-words are read and written because > the code I'm seeing is fairly nearly optimal right now and anything > more complex runs the risk of tripping inlining limits, thus > pessimizing performance. We need a general solution which isn't > optimized for special cases but is decent on average and often very > good. I think it's close to the best compromise we're going to get. > > I have changed the javadoc as requested and I have fixed the code in > HeapByteBuffer so that it doesn't check the index twice for floating- > point put() and get() operations. > > I have added a jtreg test for HeapByteBuffer which tests it pretty > thoroughly. It also, as a consequence, tests the underlying Unsafe > methods. I wasn't sure what a separate test for the Unsafe methods > would achieve so I didn't write one. > > OK? > > http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/ > http://cr.openjdk.java.net/~aph/unaligned.jdk.6/ > > Andrew. From aph at redhat.com Mon Mar 16 10:14:53 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 10:14:53 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: References: <550330CE.3030607@redhat.com> Message-ID: <5506AD1D.1090000@redhat.com> On 16/03/15 10:03, Paul Sandoz wrote: > I am running this patch though our JPRT test system right now. > > The test looks good, two comments on it: > > - IMO it does not need the internal PRNG FastRandom, > SplittableRandom can be used instead. OK. > - I suspect that test needs to be located in the hotspot test area, > which likely means it gets run on more "exotic" platforms. Perhaps > someone with more knowledge of the test configuration and > infrastructure can comment? OK. I'll wait for an answer. Andrew. From paul.sandoz at oracle.com Mon Mar 16 10:30:15 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 16 Mar 2015 11:30:15 +0100 Subject: Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: References: <550330CE.3030607@redhat.com> Message-ID: On Mar 16, 2015, at 11:03 AM, Paul Sandoz wrote: > I am running this patch though our JPRT test system right now. > I am getting a build error on spark: "... /hotspot/src/share/vm/prims/unsafe.cpp", line 335: Error: #error VM_LITTLE_ENDIAN or VM_BIG_ENDIAN must be defined. The assumption seems to be that if VM_LITTLE_ENDIAN is not defined then the platform is implicitly VM_BIG_ENDIAN. Paul. From aph at redhat.com Mon Mar 16 10:39:20 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 10:39:20 +0000 Subject: Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: References: <550330CE.3030607@redhat.com> Message-ID: <5506B2D8.3000307@redhat.com> On 03/16/2015 10:30 AM, Paul Sandoz wrote: > > On Mar 16, 2015, at 11:03 AM, Paul Sandoz wrote: > >> I am running this patch though our JPRT test system right now. >> > > I am getting a build error on spark: > > "... /hotspot/src/share/vm/prims/unsafe.cpp", line 335: Error: #error VM_LITTLE_ENDIAN or VM_BIG_ENDIAN must be defined. > > The assumption seems to be that if VM_LITTLE_ENDIAN is not defined then the platform is implicitly VM_BIG_ENDIAN. I think that we've exposed something that we should fix now. As John Rose put it, Culture of clean: Leave it nicer than you found it ? Budget for technical debt, expect and welcome debt removal VM_LITTLE_ENDIAN or VM_BIG_ENDIAN should be defined on all platforms. Andrew. From david.holmes at oracle.com Mon Mar 16 11:36:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Mar 2015 21:36:00 +1000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506A28B.3070009@redhat.com> References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> <5506A28B.3070009@redhat.com> Message-ID: <5506C020.9050703@oracle.com> On 16/03/2015 7:29 PM, Andrew Haley wrote: > On 16/03/15 00:40, David Holmes wrote: >> Experimental options are supposed to be opt-in only via >> UnlockExperimentalVMOptions. You presently have the experimental >> UseUnalignedAccesses being turned on unconditionally on those >> architectures that support it. > > Well, it works. I guess this could be changed to be a product option, > but it's only really needed for testing. And aren't product options > supposed to be properly documented for all users? > > In other words: please don't say "don't do that." Please tell me what > I should do instead. All suggestions are welcome, really because I'm > rather stuck. Either it should be an experimental option, in which case the logic that sets the flag on should check that UnlockExperimentalVMOptions is also on (else do nothing). (Though this would still be a unusual use-case for an experimental option as the intent is that the user chooses to turn them on directly.) Or it should not be an experimental option. If it is a to be a product flag then it needs to go through the CCC process. David ----- > Andrew. > From david.holmes at oracle.com Mon Mar 16 11:41:02 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Mar 2015 21:41:02 +1000 Subject: Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506B2D8.3000307@redhat.com> References: <550330CE.3030607@redhat.com> <5506B2D8.3000307@redhat.com> Message-ID: <5506C14E.6010803@oracle.com> On 16/03/2015 8:39 PM, Andrew Haley wrote: > On 03/16/2015 10:30 AM, Paul Sandoz wrote: >> >> On Mar 16, 2015, at 11:03 AM, Paul Sandoz wrote: >> >>> I am running this patch though our JPRT test system right now. >>> >> >> I am getting a build error on spark: >> >> "... /hotspot/src/share/vm/prims/unsafe.cpp", line 335: Error: #error VM_LITTLE_ENDIAN or VM_BIG_ENDIAN must be defined. >> >> The assumption seems to be that if VM_LITTLE_ENDIAN is not defined then the platform is implicitly VM_BIG_ENDIAN. > > I think that we've exposed something that we should fix now. As > John Rose put it, > > Culture of clean: Leave it nicer than you found it > ? Budget for technical debt, expect and welcome debt removal > > VM_LITTLE_ENDIAN or VM_BIG_ENDIAN should be defined on all platforms. VM_BIG_ENDIAN does not exist in the sources. The only place it exists is in: ./bsd/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN ./linux/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN The expectation is that if VM_LITTLE_ENDIAN is not defined then you are big endian. Given the two options are mutually-exclusive a single flag, defined or not, covers it. David > Andrew. > From aph at redhat.com Mon Mar 16 11:53:11 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 11:53:11 +0000 Subject: RFR: 8075045: AARCH64: Stack banging should use store rather than load Message-ID: <5506C427.1010609@redhat.com> At present, stack banging uses a load rather than a store instruction. We have discovered that on some AArch64 implementations a store performs considerably better but on no implementation is it worse. Therefore, at least for the time being, all stack bangs should use a store. http://cr.openjdk.java.net/~aph/8075045/ Andrew. From aph at redhat.com Mon Mar 16 11:54:37 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 11:54:37 +0000 Subject: Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506C14E.6010803@oracle.com> References: <550330CE.3030607@redhat.com> <5506B2D8.3000307@redhat.com> <5506C14E.6010803@oracle.com> Message-ID: <5506C47D.8000102@redhat.com> On 03/16/2015 11:41 AM, David Holmes wrote: > VM_BIG_ENDIAN does not exist in the sources. The only place it exists is in: > > ./bsd/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN > ./linux/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN > > The expectation is that if VM_LITTLE_ENDIAN is not defined then you are > big endian. Given the two options are mutually-exclusive a single flag, > defined or not, covers it. Unless someone forgets, or there is a bug in the build files. This is not a theoretical possibility. This is a bug which we have seen in the last couple of months. Andrew. From aph at redhat.com Mon Mar 16 12:23:16 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 12:23:16 +0000 Subject: Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506C47D.8000102@redhat.com> References: <550330CE.3030607@redhat.com> <5506B2D8.3000307@redhat.com> <5506C14E.6010803@oracle.com> <5506C47D.8000102@redhat.com> Message-ID: <5506CB34.7040303@redhat.com> On 03/16/2015 11:54 AM, Andrew Haley wrote: > On 03/16/2015 11:41 AM, David Holmes wrote: >> VM_BIG_ENDIAN does not exist in the sources. The only place it exists is in: >> >> ./bsd/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN >> ./linux/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN >> >> The expectation is that if VM_LITTLE_ENDIAN is not defined then you are >> big endian. Given the two options are mutually-exclusive a single flag, >> defined or not, covers it. > > Unless someone forgets, or there is a bug in the build files. This > is not a theoretical possibility. This is a bug which we have seen > in the last couple of months. I will change this because I really want this patch to go in, but under protest. Andrew. From aph at redhat.com Mon Mar 16 12:25:37 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 12:25:37 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506C020.9050703@oracle.com> References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> <5506A28B.3070009@redhat.com> <5506C020.9050703@oracle.com> Message-ID: <5506CBC1.1020309@redhat.com> On 03/16/2015 11:36 AM, David Holmes wrote: > On 16/03/2015 7:29 PM, Andrew Haley wrote: >> On 16/03/15 00:40, David Holmes wrote: >>> Experimental options are supposed to be opt-in only via >>> UnlockExperimentalVMOptions. You presently have the experimental >>> UseUnalignedAccesses being turned on unconditionally on those >>> architectures that support it. >> >> Well, it works. I guess this could be changed to be a product option, >> but it's only really needed for testing. And aren't product options >> supposed to be properly documented for all users? >> >> In other words: please don't say "don't do that." Please tell me what >> I should do instead. All suggestions are welcome, really because I'm >> rather stuck. > > Either it should be an experimental option, in which case the logic that > sets the flag on should check that UnlockExperimentalVMOptions is also > on (else do nothing). But UnlockExperimentalVMOptions is handled by the option processing already. > (Though this would still be a unusual use-case for > an experimental option as the intent is that the user chooses to turn > them on directly.) > > Or it should not be an experimental option. We need a flag which defaults to whatever is right for the platform (so it must be set in the back ends) but can be overridden by testing. What we have right now fits that requirement. I can see no way to do what I think you're asking for with the current option machinery. I certainly don't think this should be a product flag. Andrew. From magnus.ihse.bursie at oracle.com Mon Mar 16 14:24:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Mar 2015 15:24:06 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <550693CC.7050300@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> <550693CC.7050300@oracle.com> Message-ID: <5506E786.1000502@oracle.com> On 2015-03-16 09:26, Erik Joelsson wrote: > > On 2015-03-14 01:08, David Holmes wrote: >> Hi Erik, >> >> On 14/03/2015 12:08 AM, Erik Joelsson wrote: >>> Hello, >>> >>> While working on the new Hotspot makefiles in build-infra I noticed >>> this >>> problem. When introducing devkits for Solaris, we rely on the variables >>> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >>> specific flags into the hotspot build. However, these flags aren't >>> consistently used in the Hotspot build for all the native libraries. >>> >>> This patch adds the variables to all missing compile and link command >>> lines. It also fixes an issue with saproc.so where the debug info was >>> created off one of the object files instead of the library. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >>> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ The changes look good to me. >> >> For linux we primarily (only?) use these to pass cross-compilation >> flags and so everything that is compiled generally needs the same flags. >> >> Outside of cross-compilation though that doesn't necessarily hold. If >> someone uses EXTRA_CFLAGS as a general customization mechanism it >> might only be intended for the primary VM build not for secondary >> libraries like jsig, dtrace and SA. >> >> So I'm not sure that this is the right thing to do as really these >> variables are not quite what people might expect them to be. In >> general local customizations are better handled by local editing of >> the appropriate build file. >> > Well, the devkit/sysroot CFLAGS and LDFLAGS should be considered more > or less equal to cross compilation arguments. Everything being > compiled for the target platform should use them. If EXTRA_CFLAGS is > not a good option for providing these compiler options, then it > shouldn't be used for cross compilation on linux either. I figured > that since we are already using them that way on linux, extending that > usage to Solaris would be the right thing to do. If it isn't, should I > define a new set of variables for transporting these options for both > platforms instead? > > I still think using EXTRA_*FLAGS is a viable solution for my usecase > and that anyone trying to use these variables and expecting them to > only apply selectively is on a slippery slope. I agree. Another way to put it is there has been missing functionality on solaris compared to linux, which has just not really been noticed until now. /Magnus From aph at redhat.com Mon Mar 16 14:50:01 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 14:50:01 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506D002.5060609@gmail.com> References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> <5506A28B.3070009@redhat.com> <5506C020.9050703@oracle.com> <5506CBC1.1020309@redhat.com> <5506D002.5060609@gmail.com> Message-ID: <5506ED99.6000408@redhat.com> Hi, On 03/16/2015 12:43 PM, Peter Levart wrote: > On 03/16/2015 01:25 PM, Andrew Haley wrote: >> We need a flag which defaults to whatever is right for the platform >> (so it must be set in the back ends) but can be overridden by testing. >> What we have right now fits that requirement. I can see no way to do >> what I think you're asking for with the current option machinery. I >> certainly don't think this should be a product flag. > > I think the confusion is caused by UseUnalignedAccesses flag (part of a > public interface unless it is experimental - the command line options) > that is used internally to communicate the cpu default to the > implementation of Unsafe.unalignedAccess() method. What if: > > - you define an internal constant SUPPORTS_UNALIGNED_ACCESSES (I don't > know how to do that correctly) in per-cpu vm_version_cpu.hpp files. It can not be a constant: on some platforms it's something that you read from a configuration register. But I can do something like that. > - rename UseUnalignedAccesses to EmulateUnalignedAccesses (reverse the > meaning, so that default can be false which must be for experimental > options) > > - implement Unsafe.unalignedAccess() to return: > SUPPORTS_UNALIGNED_ACCESSES && !EmulateUnalignedAccesses ... I'm not sure what EmulateUnalignedAccesses means; I guess it must mean that we don't generate code which does unaligned accesses. But is that what "emulate unaligned accesses" means to you? I'm going to go with DisableUnalignedAccesses, because I at least know what that means. :-) Thanks, Andrew. From erik.joelsson at oracle.com Mon Mar 16 14:51:01 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Mar 2015 15:51:01 +0100 Subject: RFR: JDK-8075236: Change layout of gcov .gcno files in symbols image Message-ID: <5506EDD5.6040508@oracle.com> Hello, In JDK-8073021 I added support for compiling with gcov support for native code coverage. When trying to use this it was discovered that the file layout in the new symbols image need to exactly match the layout of the .gcno files in the build directory. Otherwise the runtime data files created by gcov will not match properly. I originally tried to tidy up the layout in the symbols file into: symbols/gcov/hotspot/{client,server}/*.gcno symbols/gcov/jdk/$(module)/$(lib)/*.gcno What we actually need is the (internal) layout of the intermediate build results: symbols/gcov/hotspot/linux_amd64_compiler2/product/*.gcno symbols/gcov/support/native/$(module)/$(lib)/*.gcno Our internal layout for intermediate build results is not something we want to export as an API, but in this case, the file layout just has to match the paths that get encoded into the binaries. Bug: https://bugs.openjdk.java.net/browse/JDK-8075236 Webrev: http://cr.openjdk.java.net/~erikj/8075236/webrev.root.01/ /Erik From magnus.ihse.bursie at oracle.com Mon Mar 16 14:56:53 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Mar 2015 15:56:53 +0100 Subject: RFR: JDK-8075236: Change layout of gcov .gcno files in symbols image In-Reply-To: <5506EDD5.6040508@oracle.com> References: <5506EDD5.6040508@oracle.com> Message-ID: <5506EF35.9060400@oracle.com> On 2015-03-16 15:51, Erik Joelsson wrote: > Hello, > > In JDK-8073021 I added support for compiling with gcov support for > native code coverage. When trying to use this it was discovered that > the file layout in the new symbols image need to exactly match the > layout of the .gcno files in the build directory. Otherwise the > runtime data files created by gcov will not match properly. > > I originally tried to tidy up the layout in the symbols file into: > > symbols/gcov/hotspot/{client,server}/*.gcno > symbols/gcov/jdk/$(module)/$(lib)/*.gcno > > What we actually need is the (internal) layout of the intermediate > build results: > > symbols/gcov/hotspot/linux_amd64_compiler2/product/*.gcno > symbols/gcov/support/native/$(module)/$(lib)/*.gcno > > Our internal layout for intermediate build results is not something we > want to export as an API, but in this case, the file layout just has > to match the paths that get encoded into the binaries. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075236 > Webrev: http://cr.openjdk.java.net/~erikj/8075236/webrev.root.01/ Looks good to me. /Magnus From tim.bell at oracle.com Mon Mar 16 15:43:42 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 16 Mar 2015 08:43:42 -0700 Subject: RFR: JDK-8075236: Change layout of gcov .gcno files in symbols image In-Reply-To: <5506EF35.9060400@oracle.com> References: <5506EDD5.6040508@oracle.com> <5506EF35.9060400@oracle.com> Message-ID: <5506FA2E.50300@oracle.com> Hello Erik On 03/16/15 07:56, Magnus Ihse Bursie wrote: > On 2015-03-16 15:51, Erik Joelsson wrote: >> Hello, >> >> In JDK-8073021 I added support for compiling with gcov support for >> native code coverage. When trying to use this it was discovered that >> the file layout in the new symbols image need to exactly match the >> layout of the .gcno files in the build directory. Otherwise the >> runtime data files created by gcov will not match properly. >> >> I originally tried to tidy up the layout in the symbols file into: >> >> symbols/gcov/hotspot/{client,server}/*.gcno >> symbols/gcov/jdk/$(module)/$(lib)/*.gcno >> >> What we actually need is the (internal) layout of the intermediate >> build results: >> >> symbols/gcov/hotspot/linux_amd64_compiler2/product/*.gcno >> symbols/gcov/support/native/$(module)/$(lib)/*.gcno >> >> Our internal layout for intermediate build results is not something >> we want to export as an API, but in this case, the file layout just >> has to match the paths that get encoded into the binaries. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075236 >> Webrev: http://cr.openjdk.java.net/~erikj/8075236/webrev.root.01/ > > Looks good to me. > > /Magnus Looks good to me as well. Tim From coleen.phillimore at oracle.com Mon Mar 16 15:49:26 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 16 Mar 2015 11:49:26 -0400 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506A28B.3070009@redhat.com> References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> <5506A28B.3070009@redhat.com> Message-ID: <5506FB86.2090402@oracle.com> For the experimental option, I don't see why it has to default to false everywhere to be an experimental option. But why not declare it in globals_arm.hpp as an experimental option so that you don't need to add code for the other platforms to turn it back off again? Thanks, coleen On 3/16/15, 5:29 AM, Andrew Haley wrote: > On 16/03/15 00:40, David Holmes wrote: >> Experimental options are supposed to be opt-in only via >> UnlockExperimentalVMOptions. You presently have the experimental >> UseUnalignedAccesses being turned on unconditionally on those >> architectures that support it. > Well, it works. I guess this could be changed to be a product option, > but it's only really needed for testing. And aren't product options > supposed to be properly documented for all users? > > In other words: please don't say "don't do that." Please tell me what > I should do instead. All suggestions are welcome, really because I'm > rather stuck. > > Andrew. From aph at redhat.com Mon Mar 16 15:52:33 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 15:52:33 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506FB86.2090402@oracle.com> References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> <5506A28B.3070009@redhat.com> <5506FB86.2090402@oracle.com> Message-ID: <5506FC41.1070305@redhat.com> On 03/16/2015 03:49 PM, Coleen Phillimore wrote: > the experimental option, I don't see why it has to default to false > everywhere to be an experimental option. > > But why not declare it in globals_arm.hpp as an experimental option so > that you don't need to add code for the other platforms to turn it back > off again? I think we may be misunderstanding each other. This code isn't an ARM special. It's set one way for x86 and ARM, the other way for PPC, SPARC, and Zero. There isn't a "default" that is really meaningful. Andrew. From max.ockner at oracle.com Mon Mar 16 16:17:58 2015 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 16 Mar 2015 12:17:58 -0400 Subject: RFR: 8072128: Fixed missing "++" in _mutex_array[] initialization. Message-ID: <55070236.7050803@oracle.com> Hello, Please review this small fix. Bug ID: 8072128 Webrev: http://cr.openjdk.java.net/~mockner/8072128/ Summary: The fix for bug 8047290 introduced a bug in mutexLocker.cpp in which the index into _mutex_array[] never increments. The bug did not cause any test failures, and was caught upon inspection of an hs_err file which claimed that no locks were owned. The solution was to restore the original code which increments the index. Tests: jtreg runtime/Safepoint and runtime/RedefineTests. To make sure the desired functionality was restored, the change was manually tested by crashing the vm during VM_RedefineClasses::doit() when we know that some locks are owned, and inspecting the hs_err file. This is difficult to write a test for, so it was only done manually. Thanks, Max From joseph.provino at oracle.com Mon Mar 16 16:34:09 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Mon, 16 Mar 2015 12:34:09 -0400 Subject: RFR: 8072128: Fixed missing "++" in _mutex_array[] initialization. In-Reply-To: <55070236.7050803@oracle.com> References: <55070236.7050803@oracle.com> Message-ID: <55070601.605@oracle.com> Looks good to me. joe On 3/16/2015 12:17 PM, Max Ockner wrote: > Hello, > Please review this small fix. > > Bug ID: 8072128 > Webrev: http://cr.openjdk.java.net/~mockner/8072128/ > Summary: The fix for bug 8047290 introduced a bug in mutexLocker.cpp > in which the index into _mutex_array[] never increments. The bug did > not cause any test failures, and was caught upon inspection of an > hs_err file which claimed that no locks were owned. The solution was > to restore the original code which increments the index. > > Tests: jtreg runtime/Safepoint and runtime/RedefineTests. > To make sure the desired functionality was restored, the change was > manually tested by crashing the vm during VM_RedefineClasses::doit() > when we know that some locks are owned, and inspecting the hs_err > file. This is difficult to write a test for, so it was only done > manually. > > Thanks, > Max From frederic.parain at oracle.com Mon Mar 16 16:57:17 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 16 Mar 2015 17:57:17 +0100 Subject: RFR: 8072128: Fixed missing "++" in _mutex_array[] initialization. In-Reply-To: <55070236.7050803@oracle.com> References: <55070236.7050803@oracle.com> Message-ID: <55070B6D.7080606@oracle.com> Looks good with respect to pre-8047290 code. Fred (not a Reviewer) On 16/03/2015 17:17, Max Ockner wrote: > Hello, > Please review this small fix. > > Bug ID: 8072128 > Webrev: http://cr.openjdk.java.net/~mockner/8072128/ > Summary: The fix for bug 8047290 introduced a bug in mutexLocker.cpp in > which the index into _mutex_array[] never increments. The bug did not > cause any test failures, and was caught upon inspection of an hs_err > file which claimed that no locks were owned. The solution was to > restore the original code which increments the index. > > Tests: jtreg runtime/Safepoint and runtime/RedefineTests. > To make sure the desired functionality was restored, the change was > manually tested by crashing the vm during VM_RedefineClasses::doit() > when we know that some locks are owned, and inspecting the hs_err file. > This is difficult to write a test for, so it was only done manually. > > Thanks, > Max -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From aph at redhat.com Mon Mar 16 17:19:57 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Mar 2015 17:19:57 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: References: <550330CE.3030607@redhat.com> Message-ID: <550710BD.5060301@redhat.com> On 03/16/2015 10:03 AM, Paul Sandoz wrote: > I am running this patch though our JPRT test system right now. > > The test looks good, two comments on it: > > - IMO it does not need the internal PRNG FastRandom, SplittableRandom can be used instead. > > - I suspect that test needs to be located in the hotspot test area, which likely means it gets run on more "exotic" platforms. Perhaps someone with more knowledge of the test configuration and infrastructure can comment? I have a patch with all of the changes that people have asked for except this last one. I don't know who to ask. Andrew. From kim.barrett at oracle.com Mon Mar 16 17:40:55 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 16 Mar 2015 13:40:55 -0400 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <5502DBF4.9040508@oracle.com> References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> <5502DBF4.9040508@oracle.com> Message-ID: <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> On Mar 13, 2015, at 8:45 AM, Jesper Wilhelmsson wrote: > > Hi Kim and Thomas, > > Thanks for the reviews! > > A new webrev is available here: > > http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.02/ > > There is an incremental diff as well with the latest changes suggested by you. Looks good. Please remember to file CR for log rotation test. From jesper.wilhelmsson at oracle.com Mon Mar 16 17:57:54 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 16 Mar 2015 18:57:54 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> <5502DBF4.9040508@oracle.com> <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> Message-ID: <550719A2.7050001@oracle.com> Kim Barrett skrev den 16/3/15 18:40: > On Mar 13, 2015, at 8:45 AM, Jesper Wilhelmsson wrote: >> >> Hi Kim and Thomas, >> >> Thanks for the reviews! >> >> A new webrev is available here: >> >> http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.02/ >> >> There is an incremental diff as well with the latest changes suggested by you. > > Looks good. > Thanks! > Please remember to file CR for log rotation test. > https://bugs.openjdk.java.net/browse/JDK-8075257 /Jesper From john.r.rose at oracle.com Mon Mar 16 19:16:30 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 16 Mar 2015 12:16:30 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506A28B.3070009@redhat.com> References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> <5506A28B.3070009@redhat.com> Message-ID: On Mar 16, 2015, at 2:29 AM, Andrew Haley wrote: > > On 16/03/15 00:40, David Holmes wrote: >> Experimental options are supposed to be opt-in only via >> UnlockExperimentalVMOptions. You presently have the experimental >> UseUnalignedAccesses being turned on unconditionally on those >> architectures that support it. > > Well, it works. I guess this could be changed to be a product option, > but it's only really needed for testing. And aren't product options > supposed to be properly documented for all users? > > In other words: please don't say "don't do that." Please tell me what > I should do instead. All suggestions are welcome, really because I'm > rather stuck. David has a point about experimental options; they have an opt-in sense to them. Since the option provides control for product behavior, without an explicit opt-in, it should either be a product flag or a diagnostic flag. I suggest keeping the more direct name (Use* not Disable*) and making it a diagnostic flag. As a diagnostic flag it does not require a CCC request, since it is not for JVM customers to use. Its purpose is testing and field diagnosis by implementation engineers. Similar flags are ScavengeRootsInCode, LogEventsBufferEntries, and ParGCCardsPerStrideChunk. Typical uses: On platforms which support unaligned accesses, do differential performance testing to verify that the switch is correctly set for the platform. On platforms which do not, if hardware or JIT upgrades supply a faster unaligned access, do differential regression testing with the new feature in play. ? John From thomas.schatzl at oracle.com Mon Mar 16 20:37:55 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Mar 2015 21:37:55 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> <5502DBF4.9040508@oracle.com> <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> Message-ID: <1426538275.3346.4.camel@oracle.com> Hi, On Mon, 2015-03-16 at 13:40 -0400, Kim Barrett wrote: > On Mar 13, 2015, at 8:45 AM, Jesper Wilhelmsson wrote: > > > > Hi Kim and Thomas, > > > > Thanks for the reviews! > > > > A new webrev is available here: > > > > http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.02/ > > > > There is an incremental diff as well with the latest changes suggested by you. > > Looks good. looks good. Thomas From jesper.wilhelmsson at oracle.com Mon Mar 16 21:45:49 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 16 Mar 2015 22:45:49 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <1426538275.3346.4.camel@oracle.com> References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> <5502DBF4.9040508@oracle.com> <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> <1426538275.3346.4.camel@oracle.com> Message-ID: <55074F0D.7020500@oracle.com> Thanks! /Jesper Thomas Schatzl skrev den 16/3/15 21:37: > Hi, > > On Mon, 2015-03-16 at 13:40 -0400, Kim Barrett wrote: >> On Mar 13, 2015, at 8:45 AM, Jesper Wilhelmsson wrote: >>> >>> Hi Kim and Thomas, >>> >>> Thanks for the reviews! >>> >>> A new webrev is available here: >>> >>> http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.02/ >>> >>> There is an incremental diff as well with the latest changes suggested by you. >> >> Looks good. > > looks good. > > Thomas > > > From david.holmes at oracle.com Tue Mar 17 01:50:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Mar 2015 11:50:00 +1000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> <5506A28B.3070009@redhat.com> Message-ID: <55078848.1080800@oracle.com> On 17/03/2015 5:16 AM, John Rose wrote: > On Mar 16, 2015, at 2:29 AM, Andrew Haley wrote: >> >> On 16/03/15 00:40, David Holmes wrote: >>> Experimental options are supposed to be opt-in only via >>> UnlockExperimentalVMOptions. You presently have the experimental >>> UseUnalignedAccesses being turned on unconditionally on those >>> architectures that support it. >> >> Well, it works. I guess this could be changed to be a product option, >> but it's only really needed for testing. And aren't product options >> supposed to be properly documented for all users? >> >> In other words: please don't say "don't do that." Please tell me what >> I should do instead. All suggestions are welcome, really because I'm >> rather stuck. > > David has a point about experimental options; they have an opt-in sense to them. Actually John it has been pointed out to me that my interpretation of experimental options is not correct. It seems we already have a number of "experimental" options that are on by default and the "experimental" aspect is the turning of them off. > Since the option provides control for product behavior, without an explicit opt-in, it should either be a product flag or a diagnostic flag. > > I suggest keeping the more direct name (Use* not Disable*) and making it a diagnostic flag. > > As a diagnostic flag it does not require a CCC request, since it is not for JVM customers to use. Its purpose is testing and field diagnosis by implementation engineers. Similar flags are ScavengeRootsInCode, LogEventsBufferEntries, and ParGCCardsPerStrideChunk. I think diagnostic works better here too. Thanks, David > Typical uses: On platforms which support unaligned accesses, do differential performance testing to verify that the switch is correctly set for the platform. On platforms which do not, if hardware or JIT upgrades supply a faster unaligned access, do differential regression testing with the new feature in play. > > ? John > From david.holmes at oracle.com Tue Mar 17 01:52:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Mar 2015 11:52:13 +1000 Subject: [8u60] Backport approval: 8027914: Client JVM silently exit with fail exit code when running in compact(1, 2) with options -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <55024382.6010704@oracle.com> References: <55024382.6010704@oracle.com> Message-ID: <550788CD.4000101@oracle.com> Ping! David On 13/03/2015 11:55 AM, David Holmes wrote: > Please approve this simple backport to 8u60, the 9 changeset imported > cleanly: > > bug: https://bugs.openjdk.java.net/browse/JDK-8027914 > > 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6b2bfaef5a61 > > Original review thread: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010014.html > > > Thanks, > David From david.holmes at oracle.com Tue Mar 17 01:52:22 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Mar 2015 11:52:22 +1000 Subject: [8u60] Backport approval: 8043770: File leak in MemNotifyThread::start() in hotspot.src.os.linux.vm.os_linux.cpp In-Reply-To: <55024733.9010609@oracle.com> References: <55024733.9010609@oracle.com> Message-ID: <550788D6.6070705@oracle.com> Ping! David On 13/03/2015 12:10 PM, David Holmes wrote: > Please approve this simple backport to 8u60. The 9 changeset applied > cleanly. > > bug: https://bugs.openjdk.java.net/browse/JDK-8043770 > > 9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > > Original review thread: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-October/012886.html > > > Thanks, > David From david.holmes at oracle.com Tue Mar 17 04:42:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Mar 2015 14:42:04 +1000 Subject: RFR: 8072128: Fixed missing "++" in _mutex_array[] initialization. In-Reply-To: <55070236.7050803@oracle.com> References: <55070236.7050803@oracle.com> Message-ID: <5507B09C.2090501@oracle.com> Reviewed! Thanks Max! David On 17/03/2015 2:17 AM, Max Ockner wrote: > Hello, > Please review this small fix. > > Bug ID: 8072128 > Webrev: http://cr.openjdk.java.net/~mockner/8072128/ > Summary: The fix for bug 8047290 introduced a bug in mutexLocker.cpp in > which the index into _mutex_array[] never increments. The bug did not > cause any test failures, and was caught upon inspection of an hs_err > file which claimed that no locks were owned. The solution was to > restore the original code which increments the index. > > Tests: jtreg runtime/Safepoint and runtime/RedefineTests. > To make sure the desired functionality was restored, the change was > manually tested by crashing the vm during VM_RedefineClasses::doit() > when we know that some locks are owned, and inspecting the hs_err file. > This is difficult to write a test for, so it was only done manually. > > Thanks, > Max From david.holmes at oracle.com Tue Mar 17 04:45:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Mar 2015 14:45:55 +1000 Subject: RFR: 8075045: AARCH64: Stack banging should use store rather than load In-Reply-To: <5506C427.1010609@redhat.com> References: <5506C427.1010609@redhat.com> Message-ID: <5507B183.5070301@oracle.com> On 16/03/2015 9:53 PM, Andrew Haley wrote: > At present, stack banging uses a load rather than a store instruction. > We have discovered that on some AArch64 implementations a store > performs considerably better but on no implementation is it worse. > Therefore, at least for the time being, all stack bangs should use a store. > > http://cr.openjdk.java.net/~aph/8075045/ Reviewed and cleared for direct push. Thanks, David > Andrew. > From vladimir.kozlov at oracle.com Tue Mar 17 05:53:43 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 16 Mar 2015 22:53:43 -0700 Subject: [8u60] Backport approval: 8027914: Client JVM silently exit with fail exit code when running in compact(1, 2) with options -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <550788CD.4000101@oracle.com> References: <55024382.6010704@oracle.com> <550788CD.4000101@oracle.com> Message-ID: <5507C167.7040801@oracle.com> Looks good. Thanks, Vladimir On 3/16/15 6:52 PM, David Holmes wrote: > Ping! > > David > > On 13/03/2015 11:55 AM, David Holmes wrote: >> Please approve this simple backport to 8u60, the 9 changeset imported >> cleanly: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8027914 >> >> 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6b2bfaef5a61 >> >> Original review thread: >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010014.html >> >> >> Thanks, >> David From vladimir.kozlov at oracle.com Tue Mar 17 05:55:31 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 16 Mar 2015 22:55:31 -0700 Subject: [8u60] Backport approval: 8043770: File leak in MemNotifyThread::start() in hotspot.src.os.linux.vm.os_linux.cpp In-Reply-To: <550788D6.6070705@oracle.com> References: <55024733.9010609@oracle.com> <550788D6.6070705@oracle.com> Message-ID: <5507C1D3.3080106@oracle.com> Good. Thanks, Vladimir On 3/16/15 6:52 PM, David Holmes wrote: > Ping! > > David > > On 13/03/2015 12:10 PM, David Holmes wrote: >> Please approve this simple backport to 8u60. The 9 changeset applied >> cleanly. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8043770 >> >> 9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b >> >> Original review thread: >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-October/012886.html >> >> >> Thanks, >> David From aph at redhat.com Tue Mar 17 09:02:05 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Mar 2015 09:02:05 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> <5506A28B.3070009@redhat.com> Message-ID: <5507ED8D.4080807@redhat.com> On 16/03/15 19:16, John Rose wrote: > On Mar 16, 2015, at 2:29 AM, Andrew Haley wrote:> > > Since the option provides control for product behavior, without an explicit opt-in, it should either be a product flag or a diagnostic flag. > > I suggest keeping the more direct name (Use* not Disable*) and making it a diagnostic flag. OK. Andrew. From paul.sandoz at oracle.com Tue Mar 17 10:38:33 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 17 Mar 2015 11:38:33 +0100 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550710BD.5060301@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> Message-ID: <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> On Mar 16, 2015, at 6:19 PM, Andrew Haley wrote: > On 03/16/2015 10:03 AM, Paul Sandoz wrote: >> I am running this patch though our JPRT test system right now. >> >> The test looks good, two comments on it: >> >> - IMO it does not need the internal PRNG FastRandom, SplittableRandom can be used instead. >> >> - I suspect that test needs to be located in the hotspot test area, which likely means it gets run on more "exotic" platforms. Perhaps someone with more knowledge of the test configuration and infrastructure can comment? > > I have a patch with all of the changes that people have asked for > except this last one. I don't know who to ask. > Including Stefan, who may know more. Paul. From aph at redhat.com Tue Mar 17 13:55:40 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Mar 2015 13:55:40 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> Message-ID: <5508325C.4000108@redhat.com> On 03/17/2015 10:38 AM, Paul Sandoz wrote: > > On Mar 16, 2015, at 6:19 PM, Andrew Haley wrote: > >> On 03/16/2015 10:03 AM, Paul Sandoz wrote: >>> I am running this patch though our JPRT test system right now. >>> >>> The test looks good, two comments on it: >>> >>> - IMO it does not need the internal PRNG FastRandom, SplittableRandom can be used instead. >>> >>> - I suspect that test needs to be located in the hotspot test area, which likely means it gets run on more "exotic" platforms. Perhaps someone with more knowledge of the test configuration and infrastructure can comment? >> >> I have a patch with all of the changes that people have asked for >> except this last one. I don't know who to ask. > > Including Stefan, who may know more. Righto. I will post a new webrev once we decide. Thanks, Andrew. From erik.joelsson at oracle.com Tue Mar 17 14:12:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 17 Mar 2015 15:12:53 +0100 Subject: RFR: JDK-8072897: File sawindbg.dll has incorrect file version Message-ID: <55083665.5010801@oracle.com> Hello, Please review this minor fix for sawindbg.dll. It is currently not having version info added (the RC stuff) which all other dlls have. Here is a minimal fix that basically adds the same values as for jvm.dll except for the filename (FNAME) field. (Nmake is confusing) Bug: https://bugs.openjdk.java.net/browse/JDK-8072897 Webrev: http://cr.openjdk.java.net/~erikj/8072897/webrev.hotspot.01/ /Erik From tim.bell at oracle.com Tue Mar 17 14:36:05 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 17 Mar 2015 07:36:05 -0700 Subject: RFR: JDK-8072897: File sawindbg.dll has incorrect file version In-Reply-To: <55083665.5010801@oracle.com> References: <55083665.5010801@oracle.com> Message-ID: <55083BD5.9050404@oracle.com> Erik: > Please review this minor fix for sawindbg.dll. It is currently not > having version info added (the RC stuff) which all other dlls have. > Here is a minimal fix that basically adds the same values as for > jvm.dll except for the filename (FNAME) field. > > (Nmake is confusing) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072897 > Webrev: http://cr.openjdk.java.net/~erikj/8072897/webrev.hotspot.01/ Looks good to me, although I am not a 'R'eviewer in hotspot territory... Tim From kim.barrett at oracle.com Tue Mar 17 21:54:22 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Mar 2015 17:54:22 -0400 Subject: RFR: 8073994: STATIC_ASSERT use of __LINE__ is wrong In-Reply-To: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> References: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> Message-ID: <8B648B78-3952-46E7-B372-35DE9BDD2D02@oracle.com> Any takers? On Mar 4, 2015, at 3:14 PM, Kim Barrett wrote: > > Please review this small cleanup of the infrastructure underlying the > STATIC_ASSERT macro. > > I will need a sponsor for this change. > > STATIC_ASSERT is using macro token splicing incorrectly to (attempt > to) produce a unique type name. Rather than fixing the splicing we > note that the unique type name isn't actually needed. > > - If the assertion fails the type name never gets used at all. > > - If the assertion passes we're just redefining a typedef name with > the same type, which is permitted (C++03 7.1.3 clause 3). > > So we just pick a dummy type name to always use. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8073994 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8073994/webrev.00 > > Testing: > JPRT > Local testing of assertion failures. From david.dehaven at oracle.com Tue Mar 17 22:54:40 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 17 Mar 2015 15:54:40 -0700 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) Message-ID: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> Fairly minor build system bug fix on Mac. In short, the -mmacosx-version-min argument is never being passed to the linker, where it's actually needed to assert the minimum OS version requirement in the final Mach-O binary. This was causing ld to fail when building on 10.10. I've no idea why it's different from 10.9 as I'm using the exact same copy of Xcode between 10.9 and 10.10 and it works fine on 10.9. I also had to modify saproc.make to pass that argument when it builds the SA debugger backend. All changes should only affect Mac, but kicking off a full JPRT test run to be sure. Webrev is against jdk8u-dev but will push through hs-dev if/when approved. This bug impacts 8u only, no backports necessary. JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8075400 Webrev: http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ -DrD- From david.holmes at oracle.com Wed Mar 18 00:35:29 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 10:35:29 +1000 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> Message-ID: <5508C851.20906@oracle.com> Hi David On 18/03/2015 8:54 AM, David DeHaven wrote: > Fairly minor build system bug fix on Mac. In short, the -mmacosx-version-min argument is never being passed to the linker, where it's actually needed to assert the minimum OS version requirement in the final Mach-O binary. This was causing ld to fail when building on 10.10. I've no idea why it's different from 10.9 as I'm using the exact same copy of Xcode between 10.9 and 10.10 and it works fine on 10.9. I also had to modify saproc.make to pass that argument when it builds the SA debugger backend. All changes should only affect Mac, but kicking off a full JPRT test run to be sure. Webrev is against jdk8u-dev but will push through hs-dev if/when approved. This bug impacts 8u only, no backports necessary. > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8075400 > > Webrev: > http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ + # bring in minimum version argument or we'll fail on OSX 10.10 + SA_LFLAGS = $(LFLAGS) LFLAGS or LDFLAGS ?? David H. > -DrD- > From david.holmes at oracle.com Wed Mar 18 01:48:29 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 11:48:29 +1000 Subject: RFR: 8073994: STATIC_ASSERT use of __LINE__ is wrong In-Reply-To: <8B648B78-3952-46E7-B372-35DE9BDD2D02@oracle.com> References: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> <8B648B78-3952-46E7-B372-35DE9BDD2D02@oracle.com> Message-ID: <5508D96D.2090504@oracle.com> On 18/03/2015 7:54 AM, Kim Barrett wrote: > Any takers? I didn't realize this was still pending. You had my Review - sorry if that wasn't clear. Do you still need a second reviewer? David > On Mar 4, 2015, at 3:14 PM, Kim Barrett wrote: >> >> Please review this small cleanup of the infrastructure underlying the >> STATIC_ASSERT macro. >> >> I will need a sponsor for this change. >> >> STATIC_ASSERT is using macro token splicing incorrectly to (attempt >> to) produce a unique type name. Rather than fixing the splicing we >> note that the unique type name isn't actually needed. >> >> - If the assertion fails the type name never gets used at all. >> >> - If the assertion passes we're just redefining a typedef name with >> the same type, which is permitted (C++03 7.1.3 clause 3). >> >> So we just pick a dummy type name to always use. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8073994 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8073994/webrev.00 >> >> Testing: >> JPRT >> Local testing of assertion failures. > > From kim.barrett at oracle.com Wed Mar 18 01:59:39 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Mar 2015 21:59:39 -0400 Subject: RFR: 8073994: STATIC_ASSERT use of __LINE__ is wrong In-Reply-To: <5508D96D.2090504@oracle.com> References: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> <8B648B78-3952-46E7-B372-35DE9BDD2D02@oracle.com> <5508D96D.2090504@oracle.com> Message-ID: <22AA0248-0BE9-4A3A-AC4E-4F8B507C7FAF@oracle.com> On Mar 17, 2015, at 9:48 PM, David Holmes wrote: > > On 18/03/2015 7:54 AM, Kim Barrett wrote: >> Any takers? > > I didn't realize this was still pending. You had my Review - sorry if that wasn't clear. > > Do you still need a second reviewer? Thanks for looking at it. While it wasn?t obvious to me that your comments were a Review, I am still looking for that second review. And it?s not like this is super urgent. From david.holmes at oracle.com Wed Mar 18 02:04:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 12:04:16 +1000 Subject: RFR: JDK-8072897: File sawindbg.dll has incorrect file version In-Reply-To: <55083BD5.9050404@oracle.com> References: <55083665.5010801@oracle.com> <55083BD5.9050404@oracle.com> Message-ID: <5508DD20.9080105@oracle.com> On 18/03/2015 12:36 AM, Tim Bell wrote: > Erik: > >> Please review this minor fix for sawindbg.dll. It is currently not >> having version info added (the RC stuff) which all other dlls have. >> Here is a minimal fix that basically adds the same values as for >> jvm.dll except for the filename (FNAME) field. >> >> (Nmake is confusing) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072897 >> Webrev: http://cr.openjdk.java.net/~erikj/8072897/webrev.hotspot.01/ > > Looks good to me, although I am not a 'R'eviewer in hotspot territory... I am :) Looks okay to me too. Don't forget to submit via jprt with "-testset hotspot" Thanks, David > Tim > From erik.joelsson at oracle.com Wed Mar 18 08:24:59 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Mar 2015 09:24:59 +0100 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <5508C851.20906@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> Message-ID: <5509365B.2060808@oracle.com> On 2015-03-18 01:35, David Holmes wrote: > Hi David > > On 18/03/2015 8:54 AM, David DeHaven wrote: >> Fairly minor build system bug fix on Mac. In short, the >> -mmacosx-version-min argument is never being passed to the linker, >> where it's actually needed to assert the minimum OS version >> requirement in the final Mach-O binary. This was causing ld to fail >> when building on 10.10. I've no idea why it's different from 10.9 as >> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >> works fine on 10.9. I also had to modify saproc.make to pass that >> argument when it builds the SA debugger backend. All changes should >> only affect Mac, but kicking off a full JPRT test run to be sure. >> Webrev is against jdk8u-dev but will push through hs-dev if/when >> approved. This bug impacts 8u only, no backports necessary. >> >> JBS Issue: >> https://bugs.openjdk.java.net/browse/JDK-8075400 >> >> Webrev: >> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ > Looks good to me. > + # bring in minimum version argument or we'll fail on OSX 10.10 > + SA_LFLAGS = $(LFLAGS) > > LFLAGS or LDFLAGS ?? > The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at all, it's called LFLAGS. /Erik From erik.joelsson at oracle.com Wed Mar 18 09:32:47 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Mar 2015 10:32:47 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <550693CC.7050300@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> <550693CC.7050300@oracle.com> Message-ID: <5509463F.8020401@oracle.com> David, Are you OK with me pushing this or should I interpret your reply as a need for a different solution? /Erik On 2015-03-16 09:26, Erik Joelsson wrote: > > On 2015-03-14 01:08, David Holmes wrote: >> Hi Erik, >> >> On 14/03/2015 12:08 AM, Erik Joelsson wrote: >>> Hello, >>> >>> While working on the new Hotspot makefiles in build-infra I noticed >>> this >>> problem. When introducing devkits for Solaris, we rely on the variables >>> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >>> specific flags into the hotspot build. However, these flags aren't >>> consistently used in the Hotspot build for all the native libraries. >>> >>> This patch adds the variables to all missing compile and link command >>> lines. It also fixes an issue with saproc.so where the debug info was >>> created off one of the object files instead of the library. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >>> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ >> >> For linux we primarily (only?) use these to pass cross-compilation >> flags and so everything that is compiled generally needs the same flags. >> >> Outside of cross-compilation though that doesn't necessarily hold. If >> someone uses EXTRA_CFLAGS as a general customization mechanism it >> might only be intended for the primary VM build not for secondary >> libraries like jsig, dtrace and SA. >> >> So I'm not sure that this is the right thing to do as really these >> variables are not quite what people might expect them to be. In >> general local customizations are better handled by local editing of >> the appropriate build file. >> > Well, the devkit/sysroot CFLAGS and LDFLAGS should be considered more > or less equal to cross compilation arguments. Everything being > compiled for the target platform should use them. If EXTRA_CFLAGS is > not a good option for providing these compiler options, then it > shouldn't be used for cross compilation on linux either. I figured > that since we are already using them that way on linux, extending that > usage to Solaris would be the right thing to do. If it isn't, should I > define a new set of variables for transporting these options for both > platforms instead? > > I still think using EXTRA_*FLAGS is a viable solution for my usecase > and that anyone trying to use these variables and expecting them to > only apply selectively is on a slippery slope. > > /Erik >> David >> >>> /Erik > From stefan.karlsson at oracle.com Wed Mar 18 09:55:28 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Mar 2015 10:55:28 +0100 Subject: RFR: 8075416: Cleanup GC include dependencies in memoryPool.hpp Message-ID: <55094B90.7070706@oracle.com> Hi, Please review this patch to clean up the GC include dependencies in memoryPool.hpp. The memoryPool.hpp header file uses GC specific code and has to include header and inline files for different Spaces and Generations. I propose that we decouple the memoryPool.hpp from the GC specific header files by moving the definition of the offending functions, and the includes, to memoryPool.cpp. http://cr.openjdk.java.net/~stefank/8075416/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8075416 Tested with the java/lang/management jtreg testes. Thanks, StefanK From erik.helin at oracle.com Wed Mar 18 10:30:00 2015 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 18 Mar 2015 11:30:00 +0100 Subject: RFR: 8075416: Cleanup GC include dependencies in memoryPool.hpp In-Reply-To: <55094B90.7070706@oracle.com> References: <55094B90.7070706@oracle.com> Message-ID: <20150318103000.GC20878@ehelin.jrpg.bea.com> On 2015-03-18, Stefan Karlsson wrote: > Hi, > > Please review this patch to clean up the GC include dependencies in > memoryPool.hpp. > > The memoryPool.hpp header file uses GC specific code and has to include > header and inline files for different Spaces and Generations. I propose that > we decouple the memoryPool.hpp from the GC specific header files by moving > the definition of the offending functions, and the includes, to > memoryPool.cpp. > > http://cr.openjdk.java.net/~stefank/8075416/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075416 Looks good, Reviewed. Thanks, Erik > Tested with the java/lang/management jtreg testes. > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Mar 18 10:34:16 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Mar 2015 11:34:16 +0100 Subject: RFR: 8075416: Cleanup GC include dependencies in memoryPool.hpp In-Reply-To: <20150318103000.GC20878@ehelin.jrpg.bea.com> References: <55094B90.7070706@oracle.com> <20150318103000.GC20878@ehelin.jrpg.bea.com> Message-ID: <550954A8.3030905@oracle.com> On 18/03/15 11:30, Erik Helin wrote: > On 2015-03-18, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to clean up the GC include dependencies in >> memoryPool.hpp. >> >> The memoryPool.hpp header file uses GC specific code and has to include >> header and inline files for different Spaces and Generations. I propose that >> we decouple the memoryPool.hpp from the GC specific header files by moving >> the definition of the offending functions, and the includes, to >> memoryPool.cpp. >> >> http://cr.openjdk.java.net/~stefank/8075416/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075416 > Looks good, Reviewed. Thanks, Erik. StefanK > > Thanks, > Erik > >> Tested with the java/lang/management jtreg testes. >> >> Thanks, >> StefanK From erik.helin at oracle.com Wed Mar 18 10:34:38 2015 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 18 Mar 2015 11:34:38 +0100 Subject: RFR: 8073994: STATIC_ASSERT use of __LINE__ is wrong In-Reply-To: <22AA0248-0BE9-4A3A-AC4E-4F8B507C7FAF@oracle.com> References: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> <8B648B78-3952-46E7-B372-35DE9BDD2D02@oracle.com> <5508D96D.2090504@oracle.com> <22AA0248-0BE9-4A3A-AC4E-4F8B507C7FAF@oracle.com> Message-ID: <20150318103438.GD20878@ehelin.jrpg.bea.com> On 2015-03-17, Kim Barrett wrote: > On Mar 17, 2015, at 9:48 PM, David Holmes wrote: > > > > On 18/03/2015 7:54 AM, Kim Barrett wrote: > >> Any takers? > > > > I didn't realize this was still pending. You had my Review - sorry if that wasn't clear. > > > > Do you still need a second reviewer? > > Thanks for looking at it. > > While it wasn?t obvious to me that your comments were a Review, I am still looking for that second review. And it?s not like this is super urgent. Looks good, Reviewed. Thanks, Erik From david.holmes at oracle.com Wed Mar 18 10:55:05 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 20:55:05 +1000 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <5509365B.2060808@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> <5509365B.2060808@oracle.com> Message-ID: <55095989.5050105@oracle.com> On 18/03/2015 6:24 PM, Erik Joelsson wrote: > > On 2015-03-18 01:35, David Holmes wrote: >> Hi David >> >> On 18/03/2015 8:54 AM, David DeHaven wrote: >>> Fairly minor build system bug fix on Mac. In short, the >>> -mmacosx-version-min argument is never being passed to the linker, >>> where it's actually needed to assert the minimum OS version >>> requirement in the final Mach-O binary. This was causing ld to fail >>> when building on 10.10. I've no idea why it's different from 10.9 as >>> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >>> works fine on 10.9. I also had to modify saproc.make to pass that >>> argument when it builds the SA debugger backend. All changes should >>> only affect Mac, but kicking off a full JPRT test run to be sure. >>> Webrev is against jdk8u-dev but will push through hs-dev if/when >>> approved. This bug impacts 8u only, no backports necessary. >>> >>> JBS Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8075400 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ >> > Looks good to me. >> + # bring in minimum version argument or we'll fail on OSX 10.10 >> + SA_LFLAGS = $(LFLAGS) >> >> LFLAGS or LDFLAGS ?? >> > The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at > all, it's called LFLAGS. Ah! I failed to spot that the change in gcc.make was from LDFLAGS to LFLAGS. Thanks, David H. > /Erik From david.holmes at oracle.com Wed Mar 18 10:58:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 20:58:27 +1000 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <5509463F.8020401@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> <550693CC.7050300@oracle.com> <5509463F.8020401@oracle.com> Message-ID: <55095A53.9030305@oracle.com> On 18/03/2015 7:32 PM, Erik Joelsson wrote: > David, > > Are you OK with me pushing this or should I interpret your reply as a > need for a different solution? It's okay to push. The flag management is quite messy and I don't think there is any simple solution to cover the various kinds of flags that might need to be applied en-masse versus selectively. Anyone messing with these variables is going to need to be very careful to check that it has the desired affect. David > /Erik > > On 2015-03-16 09:26, Erik Joelsson wrote: >> >> On 2015-03-14 01:08, David Holmes wrote: >>> Hi Erik, >>> >>> On 14/03/2015 12:08 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> While working on the new Hotspot makefiles in build-infra I noticed >>>> this >>>> problem. When introducing devkits for Solaris, we rely on the variables >>>> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >>>> specific flags into the hotspot build. However, these flags aren't >>>> consistently used in the Hotspot build for all the native libraries. >>>> >>>> This patch adds the variables to all missing compile and link command >>>> lines. It also fixes an issue with saproc.so where the debug info was >>>> created off one of the object files instead of the library. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ >>> >>> For linux we primarily (only?) use these to pass cross-compilation >>> flags and so everything that is compiled generally needs the same flags. >>> >>> Outside of cross-compilation though that doesn't necessarily hold. If >>> someone uses EXTRA_CFLAGS as a general customization mechanism it >>> might only be intended for the primary VM build not for secondary >>> libraries like jsig, dtrace and SA. >>> >>> So I'm not sure that this is the right thing to do as really these >>> variables are not quite what people might expect them to be. In >>> general local customizations are better handled by local editing of >>> the appropriate build file. >>> >> Well, the devkit/sysroot CFLAGS and LDFLAGS should be considered more >> or less equal to cross compilation arguments. Everything being >> compiled for the target platform should use them. If EXTRA_CFLAGS is >> not a good option for providing these compiler options, then it >> shouldn't be used for cross compilation on linux either. I figured >> that since we are already using them that way on linux, extending that >> usage to Solaris would be the right thing to do. If it isn't, should I >> define a new set of variables for transporting these options for both >> platforms instead? >> >> I still think using EXTRA_*FLAGS is a viable solution for my usecase >> and that anyone trying to use these variables and expecting them to >> only apply selectively is on a slippery slope. >> >> /Erik >>> David >>> >>>> /Erik >> > From mikael.gerdin at oracle.com Wed Mar 18 12:12:26 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Mar 2015 13:12:26 +0100 Subject: RFR: 8075416: Cleanup GC include dependencies in memoryPool.hpp In-Reply-To: <55094B90.7070706@oracle.com> References: <55094B90.7070706@oracle.com> Message-ID: <55096BAA.2030408@oracle.com> Hi Stefan, On 2015-03-18 10:55, Stefan Karlsson wrote: > Hi, > > Please review this patch to clean up the GC include dependencies in > memoryPool.hpp. > > The memoryPool.hpp header file uses GC specific code and has to include > header and inline files for different Spaces and Generations. I propose > that we decouple the memoryPool.hpp from the GC specific header files by > moving the definition of the offending functions, and the includes, to > memoryPool.cpp. > > http://cr.openjdk.java.net/~stefank/8075416/webrev.01/ Looks good. Reviewed. /Mikael > https://bugs.openjdk.java.net/browse/JDK-8075416 > > Tested with the java/lang/management jtreg testes. > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Mar 18 12:16:20 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Mar 2015 13:16:20 +0100 Subject: RFR: 8075416: Cleanup GC include dependencies in memoryPool.hpp In-Reply-To: <55096BAA.2030408@oracle.com> References: <55094B90.7070706@oracle.com> <55096BAA.2030408@oracle.com> Message-ID: <55096C94.8000703@oracle.com> On 18/03/15 13:12, Mikael Gerdin wrote: > Hi Stefan, > > On 2015-03-18 10:55, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to clean up the GC include dependencies in >> memoryPool.hpp. >> >> The memoryPool.hpp header file uses GC specific code and has to include >> header and inline files for different Spaces and Generations. I propose >> that we decouple the memoryPool.hpp from the GC specific header files by >> moving the definition of the offending functions, and the includes, to >> memoryPool.cpp. >> >> http://cr.openjdk.java.net/~stefank/8075416/webrev.01/ > > Looks good. Reviewed. Thanks, Mikael. StefanK > > /Mikael > >> https://bugs.openjdk.java.net/browse/JDK-8075416 >> >> Tested with the java/lang/management jtreg testes. >> >> Thanks, >> StefanK From kim.barrett at oracle.com Wed Mar 18 14:23:53 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Mar 2015 10:23:53 -0400 Subject: RFR: 8073994: STATIC_ASSERT use of __LINE__ is wrong In-Reply-To: <20150318103438.GD20878@ehelin.jrpg.bea.com> References: <17CE5591-733A-4DFA-89F3-33E75238C728@oracle.com> <8B648B78-3952-46E7-B372-35DE9BDD2D02@oracle.com> <5508D96D.2090504@oracle.com> <22AA0248-0BE9-4A3A-AC4E-4F8B507C7FAF@oracle.com> <20150318103438.GD20878@ehelin.jrpg.bea.com> Message-ID: <14E0917F-CCF1-4E1E-805F-6622530A8B85@oracle.com> On Mar 18, 2015, at 6:34 AM, Erik Helin wrote: > > Looks good, Reviewed. > > Thanks, > Erik Thanks for your review. Now just need a sponsor. From david.dehaven at oracle.com Wed Mar 18 17:20:46 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 18 Mar 2015 10:20:46 -0700 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <55095989.5050105@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> <5509365B.2060808@oracle.com> <55095989.5050105@oracle.com> Message-ID: <0023AAD5-A65A-4399-865E-04F17DC7F428@oracle.com> >>> Hi David >>> >>> On 18/03/2015 8:54 AM, David DeHaven wrote: >>>> Fairly minor build system bug fix on Mac. In short, the >>>> -mmacosx-version-min argument is never being passed to the linker, >>>> where it's actually needed to assert the minimum OS version >>>> requirement in the final Mach-O binary. This was causing ld to fail >>>> when building on 10.10. I've no idea why it's different from 10.9 as >>>> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >>>> works fine on 10.9. I also had to modify saproc.make to pass that >>>> argument when it builds the SA debugger backend. All changes should >>>> only affect Mac, but kicking off a full JPRT test run to be sure. >>>> Webrev is against jdk8u-dev but will push through hs-dev if/when >>>> approved. This bug impacts 8u only, no backports necessary. >>>> >>>> JBS Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8075400 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ >>> >> Looks good to me. >>> + # bring in minimum version argument or we'll fail on OSX 10.10 >>> + SA_LFLAGS = $(LFLAGS) >>> >>> LFLAGS or LDFLAGS ?? >>> >> The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at >> all, it's called LFLAGS. > > Ah! I failed to spot that the change in gcc.make was from LDFLAGS to LFLAGS. Correct, that's why vm.make wasn't picking up the -mmacosx-version-min argument when linking. JPRT run was clean. Can I take this as approval? -DrD- From peter.levart at gmail.com Mon Mar 16 12:43:46 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 16 Mar 2015 13:43:46 +0100 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5506CBC1.1020309@redhat.com> References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com> <5506A28B.3070009@redhat.com> <5506C020.9050703@oracle.com> <5506CBC1.1020309@redhat.com> Message-ID: <5506D002.5060609@gmail.com> On 03/16/2015 01:25 PM, Andrew Haley wrote: > On 03/16/2015 11:36 AM, David Holmes wrote: >> On 16/03/2015 7:29 PM, Andrew Haley wrote: >>> On 16/03/15 00:40, David Holmes wrote: >>>> Experimental options are supposed to be opt-in only via >>>> UnlockExperimentalVMOptions. You presently have the experimental >>>> UseUnalignedAccesses being turned on unconditionally on those >>>> architectures that support it. >>> Well, it works. I guess this could be changed to be a product option, >>> but it's only really needed for testing. And aren't product options >>> supposed to be properly documented for all users? >>> >>> In other words: please don't say "don't do that." Please tell me what >>> I should do instead. All suggestions are welcome, really because I'm >>> rather stuck. >> Either it should be an experimental option, in which case the logic that >> sets the flag on should check that UnlockExperimentalVMOptions is also >> on (else do nothing). > But UnlockExperimentalVMOptions is handled by the option processing > already. > >> (Though this would still be a unusual use-case for >> an experimental option as the intent is that the user chooses to turn >> them on directly.) >> >> Or it should not be an experimental option. > We need a flag which defaults to whatever is right for the platform > (so it must be set in the back ends) but can be overridden by testing. > What we have right now fits that requirement. I can see no way to do > what I think you're asking for with the current option machinery. I > certainly don't think this should be a product flag. > > Andrew. Hi Andrew, I think the confusion is caused by UseUnalignedAccesses flag (part of a public interface unless it is experimental - the command line options) that is used internally to communicate the cpu default to the implementation of Unsafe.unalignedAccess() method. What if: - you define an internal constant SUPPORTS_UNALIGNED_ACCESSES (I don't know how to do that correctly) in per-cpu vm_version_cpu.hpp files. - rename UseUnalignedAccesses to EmulateUnalignedAccesses (reverse the meaning, so that default can be false which must be for experimental options) - implement Unsafe.unalignedAccess() to return: SUPPORTS_UNALIGNED_ACCESSES && !EmulateUnalignedAccesses ... Regards, Peter From david.holmes at oracle.com Wed Mar 18 21:34:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Mar 2015 07:34:12 +1000 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <0023AAD5-A65A-4399-865E-04F17DC7F428@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> <5509365B.2060808@oracle.com> <55095989.5050105@oracle.com> <0023AAD5-A65A-4399-865E-04F17DC7F428@oracle.com> Message-ID: <5509EF54.1020502@oracle.com> On 19/03/2015 3:20 AM, David DeHaven wrote: > >>>> Hi David >>>> >>>> On 18/03/2015 8:54 AM, David DeHaven wrote: >>>>> Fairly minor build system bug fix on Mac. In short, the >>>>> -mmacosx-version-min argument is never being passed to the linker, >>>>> where it's actually needed to assert the minimum OS version >>>>> requirement in the final Mach-O binary. This was causing ld to fail >>>>> when building on 10.10. I've no idea why it's different from 10.9 as >>>>> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >>>>> works fine on 10.9. I also had to modify saproc.make to pass that >>>>> argument when it builds the SA debugger backend. All changes should >>>>> only affect Mac, but kicking off a full JPRT test run to be sure. >>>>> Webrev is against jdk8u-dev but will push through hs-dev if/when >>>>> approved. This bug impacts 8u only, no backports necessary. >>>>> >>>>> JBS Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8075400 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ >>>> >>> Looks good to me. >>>> + # bring in minimum version argument or we'll fail on OSX 10.10 >>>> + SA_LFLAGS = $(LFLAGS) >>>> >>>> LFLAGS or LDFLAGS ?? >>>> >>> The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at >>> all, it's called LFLAGS. >> >> Ah! I failed to spot that the change in gcc.make was from LDFLAGS to LFLAGS. > > Correct, that's why vm.make wasn't picking up the -mmacosx-version-min argument when linking. > > JPRT run was clean. > > Can I take this as approval? Yes. Thanks, David > -DrD- > From david.dehaven at oracle.com Thu Mar 19 01:06:12 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 18 Mar 2015 18:06:12 -0700 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <5509EF54.1020502@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> <5509365B.2060808@oracle.com> <55095989.5050105@oracle.com> <0023AAD5-A65A-4399-865E-04F17DC7F428@oracle.com> <5509EF54.1020502@oracle.com> Message-ID: <171DDF0E-CF1D-4310-9982-242D2EEC27EC@oracle.com> >>>>> Hi David >>>>> >>>>> On 18/03/2015 8:54 AM, David DeHaven wrote: >>>>>> Fairly minor build system bug fix on Mac. In short, the >>>>>> -mmacosx-version-min argument is never being passed to the linker, >>>>>> where it's actually needed to assert the minimum OS version >>>>>> requirement in the final Mach-O binary. This was causing ld to fail >>>>>> when building on 10.10. I've no idea why it's different from 10.9 as >>>>>> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >>>>>> works fine on 10.9. I also had to modify saproc.make to pass that >>>>>> argument when it builds the SA debugger backend. All changes should >>>>>> only affect Mac, but kicking off a full JPRT test run to be sure. >>>>>> Webrev is against jdk8u-dev but will push through hs-dev if/when >>>>>> approved. This bug impacts 8u only, no backports necessary. >>>>>> >>>>>> JBS Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8075400 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ >>>>> >>>> Looks good to me. >>>>> + # bring in minimum version argument or we'll fail on OSX 10.10 >>>>> + SA_LFLAGS = $(LFLAGS) >>>>> >>>>> LFLAGS or LDFLAGS ?? >>>>> >>>> The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at >>>> all, it's called LFLAGS. >>> >>> Ah! I failed to spot that the change in gcc.make was from LDFLAGS to LFLAGS. >> >> Correct, that's why vm.make wasn't picking up the -mmacosx-version-min argument when linking. >> >> JPRT run was clean. >> >> Can I take this as approval? > > Yes. Great, thanks! -DrD- From aph at redhat.com Thu Mar 19 09:03:10 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Mar 2015 09:03:10 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5508325C.4000108@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> Message-ID: <550A90CE.9080901@redhat.com> People, please. I have been working on this for weeks. All I am waiting on now is a decision about where the test case should go. Can I have a decision so we can get this in? Thanks, Andrew. From jaroslav.bachorik at oracle.com Thu Mar 19 09:59:23 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 19 Mar 2015 10:59:23 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' Message-ID: <550A9DFB.1070204@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. JVMTI.data_dump will send the data dump request to JVMTI. Both of these commands are covered by the corresponding tests. Thanks, -JB- From paul.sandoz at oracle.com Thu Mar 19 11:07:25 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 19 Mar 2015 12:07:25 +0100 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550A90CE.9080901@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> Message-ID: <93E3554F-4BF0-4510-B4D8-7700DAB05E3C@oracle.com> Hi Andrew, Given no further advice, my inclination is move it to hotspot tests as i suspect the scope is at least as good, if not better. I agree we should not be blocked on this, so it's up to you :-) If left as is, we can/should revisit. Paul. On Mar 19, 2015, at 10:03 AM, Andrew Haley wrote: > People, please. > > I have been working on this for weeks. All I am waiting on now > is a decision about where the test case should go. Can I have a > decision so we can get this in? > From frederic.parain at oracle.com Thu Mar 19 11:20:16 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 19 Mar 2015 12:20:16 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <550A9DFB.1070204@oracle.com> References: <550A9DFB.1070204@oracle.com> Message-ID: <550AB0F0.1010100@oracle.com> Jaroslav, src/share/vm/services/diagnosticCommand.cpp No comments src/share/vm/services/diagnosticCommand.hpp Why adding #include "services/attachListener.hpp" ? test/serviceability/dcmd/jvmti/DataDumpDcmdTest.java test/serviceability/dcmd/vm/SetVMFlagTest.java I don't know the new test framework, so I cannot comment on these files. Regards, Fred On 03/19/2015 10:59 AM, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 > Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 > > This patch is about adding 2 new diagnostic commands - VM.set_flag and > JVMTI.data_dump. > > VM.set_flag allows to set any writeable flag. It takes the flag name and > the flag value in textual form. The mutability of the flag and the value > format checks are forwarded to the shared vm management code. > > JVMTI.data_dump will send the data dump request to JVMTI. > > Both of these commands are covered by the corresponding tests. > > Thanks, > > -JB- -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From vladimir.x.ivanov at oracle.com Thu Mar 19 12:38:03 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 19 Mar 2015 15:38:03 +0300 Subject: JNI calling wrong method In-Reply-To: <96DD6D5EB224D2419E81EF81E4D9C379082BC9A0@EX2K10MBX1.ad.london.inspiredbroadcast.net> References: <96DD6D5EB224D2419E81EF81E4D9C379082BB984@EX2K10MBX1.ad.london.inspiredbroadcast.net> <96DD6D5EB224D2419E81EF81E4D9C379082BC9A0@EX2K10MBX1.ad.london.inspiredbroadcast.net> Message-ID: <550AC32B.1040801@oracle.com> (CCing: hotspot-dev at openjdk.java.net, BCCing: discuss at openjdk.java.net) Forwarding the discussion to hotspot-dev at ... alias, since it is the right place to discuss such issues. Best regards, Vladimir Ivanov On 3/19/15 1:22 PM, Jiri Peinlich wrote: > Hello, > > we have a java application that calls a native method from a dll. This works for us most of the time but very rarely on some Pcs the JNI is calling wrong native method. As we have finally a machine that reproduces the issue regularly we would like to investigate what is the reason and hopefully fix it, but we are out of ideas how to investigate the issue. > > Bellow you can see a java crash dump. It is visible there that we are trying to invoke method "setVolumeNative". The method "create" is invoked however. > > We would expect to see the following on stack: > > Java_net_inspiredbroadcast_legion_jni_volume_MainVolume_setVolumeNative > > But we see there this: Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create > > How should we investigate this issue? > > Thx, Jiri > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6294c518, pid=14900, tid=7008 > # > # JRE version: 7.0 > # Java VM: OpenJDK Client VM (22.0-b10 mixed mode windows-x86 ) > # Problematic frame: > # C [common-win32-native-1.0.6-SNAPSHOT.dll+0xc518] > # > # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- T H R E A D --------------- > > Current thread (0x11969c00): JavaThread "Bootstrap" [_thread_in_native, id=7008, stack(0x12890000,0x128e0000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x00000000 > > Registers: > EAX=0x00000000, EBX=0x0d3871c0, ECX=0x730a3130, EDX=0x128df744 > ESP=0x128df730, EBP=0x128df754, ESI=0x0d3871c0, EDI=0x11969c00 > EIP=0x6294c518, EFLAGS=0x00010247 > > Top of Stack: (sp=0x128df730) > 0x128df730: 6299f488 00000001 00000000 128df744 > 0x128df740: 00000001 00000000 80070490 00000000 > 0x128df750: 00000000 128df788 6294bb31 11969d28 > 0x128df760: 128df7c4 00000000 00000006 00000008 > 0x128df770: 11969c00 0d3871c0 0d3871c0 128df7bc > 0x128df780: 0245a4b7 00969c00 128df7bc 0245a5b7 > 0x128df790: 11969d28 128df7c4 00000000 128df79c > 0x128df7a0: 0d3871c0 128df7cc 0d387920 00000000 > > Instructions: (pc=0x6294c518) > 0x6294c4f8: ff d1 c7 45 fc 00 00 00 00 c7 45 f0 00 00 00 00 > 0x6294c508: 8d 55 f0 52 6a 00 6a 01 68 88 f4 99 62 8b 45 f8 > 0x6294c518: 8b 08 8b 55 f8 52 8b 41 0c ff d0 89 45 f4 83 7d > 0x6294c528: f4 00 74 16 68 70 f1 99 62 68 90 f1 99 62 8b 4d > > > Register to memory mapping: > > EAX=0x00000000 is an unknown value > EBX=0x0d3871c0 is an oop > {method} > - klass: {other class} > ECX=0x730a3130 is an unknown value > EDX=0x128df744 is pointing into the stack for thread: 0x11969c00 > ESP=0x128df730 is pointing into the stack for thread: 0x11969c00 > EBP=0x128df754 is pointing into the stack for thread: 0x11969c00 > ESI=0x0d3871c0 is an oop > {method} > - klass: {other class} > EDI=0x11969c00 is a thread > > > Stack: [0x12890000,0x128e0000], sp=0x128df730, free space=317k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [common-win32-native-1.0.6-SNAPSHOT.dll+0xc518] Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create+0xa410 > C [common-win32-native-1.0.6-SNAPSHOT.dll+0xbb31] Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create+0x9a29 > j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolumeNative(I)V+0 > j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolume(I)V+49 > j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.setVolume(I)V+100 > j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.startUp()V+49 > j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceLoaderImpl.()V+210 > j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceHandler.initialise()V+176 > j net.inspiredbroadcast.legion.ikernel.core.BootstrapDelegate.start()Ljava/lang/Integer;+318 > j net.inspiredbroadcast.legion.ikernel.core.Bootstrap.start([Ljava/lang/String;)Ljava/lang/Integer;+14 > j org.tanukisoftware.wrapper.WrapperManager$11.run()V+75 > v ~StubRoutines::call_stub > V [jvm.dll+0x1233ba] > V [jvm.dll+0x1c8f7e] > V [jvm.dll+0x1235a3] > V [jvm.dll+0x123607] > V [jvm.dll+0xcd1ef] > V [jvm.dll+0x1430af] > V [jvm.dll+0x1711e9] > C [msvcr100.dll+0x10fac] freefls+0x130 > C [msvcr100.dll+0x110b1] __fls_getvalue+0x58 > C [kernel32.dll+0x133aa] BaseThreadInitThunk+0x12 > C [ntdll.dll+0x3bf32] RtlInitializeExceptionChain+0x63 > C [ntdll.dll+0x3bf05] RtlInitializeExceptionChain+0x36 > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolumeNative(I)V+0 > j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolume(I)V+49 > j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.setVolume(I)V+100 > j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.startUp()V+49 > j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceLoaderImpl.()V+210 > j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceHandler.initialise()V+176 > j net.inspiredbroadcast.legion.ikernel.core.BootstrapDelegate.start()Ljava/lang/Integer;+318 > j net.inspiredbroadcast.legion.ikernel.core.Bootstrap.start([Ljava/lang/String;)Ljava/lang/Integer;+14 > j org.tanukisoftware.wrapper.WrapperManager$11.run()V+75 > v ~StubRoutines::call_stub > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x11e76c00 JavaThread "CashHandlingWorker" daemon [_thread_blocked, id=5732, stack(0x18e60000,0x18eb0000)] > 0x11e76800 JavaThread "Swing-Shell" daemon [_thread_blocked, id=15856, stack(0x13220000,0x13270000)] > 0x11e76000 JavaThread "NetConn Monitor" daemon [_thread_blocked, id=15932, stack(0x18560000,0x185b0000)] > 0x11c02800 JavaThread "AudioPlayerThread" [_thread_blocked, id=15000, stack(0x18b90000,0x18be0000)] > 0x11c02000 JavaThread "D3D Screen Updater" daemon [_thread_blocked, id=14308, stack(0x185d0000,0x18620000)] > 0x11c01c00 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=8760, stack(0x17860000,0x178b0000)] > 0x11c01400 JavaThread "AWT-Windows" daemon [_thread_in_native, id=12852, stack(0x13280000,0x132d0000)] > 0x11c01000 JavaThread "AWT-Shutdown" [_thread_blocked, id=7156, stack(0x12f70000,0x12fc0000)] > 0x11c00800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=16016, stack(0x12840000,0x12890000)] > 0x11c00000 JavaThread "TelnetServer" [_thread_in_native, id=6376, stack(0x12ed0000,0x12f20000)] > 0x11bffc00 JavaThread "EventWorker" daemon [_thread_blocked, id=14384, stack(0x12280000,0x122d0000)] > 0x11bff000 JavaThread "ScheduleHandler" daemon [_thread_blocked, id=15584, stack(0x13050000,0x130a0000)] > 0x11a21400 JavaThread "MarimbaDownloadStatusMessenger" [_thread_blocked, id=10380, stack(0x113e0000,0x11430000)] > 0x11a06c00 JavaThread "MetersWorkingThread" [_thread_blocked, id=7028, stack(0x10d00000,0x10d50000)] > 0x119e4800 JavaThread "SuspensionEvaluatorDaemon" daemon [_thread_blocked, id=12132, stack(0x12690000,0x126e0000)] > 0x119e3000 JavaThread "Announcer" daemon [_thread_blocked, id=12116, stack(0x129f0000,0x12a40000)] > 0x119e2800 JavaThread "Asyncmessage sending thread" [_thread_blocked, id=16036, stack(0x125f0000,0x12640000)] > =>0x11969c00 JavaThread "Bootstrap" [_thread_in_native, id=7008, stack(0x12890000,0x128e0000)] > 0x009adc00 JavaThread "DestroyJavaVM" [_thread_blocked, id=14360, stack(0x00b20000,0x00b70000)] > 0x1192bc00 JavaThread "Wrapper-Connection" daemon [_thread_in_native, id=15560, stack(0x12640000,0x12690000)] > 0x118f9c00 JavaThread "Wrapper-Startup-Runner" [_thread_blocked, id=9208, stack(0x12760000,0x127b0000)] > 0x11918c00 JavaThread "Wrapper-Control-Event-Monitor" daemon [_thread_blocked, id=15772, stack(0x12700000,0x12750000)] > 0x118c9400 JavaThread "Cerberus 1" daemon [_thread_blocked, id=10816, stack(0x12330000,0x12380000)] > 0x11325000 JavaThread "ProcessHandler" daemon [_thread_blocked, id=14040, stack(0x11430000,0x11480000)] > 0x10529800 JavaThread "Service Thread" daemon [_thread_blocked, id=11748, stack(0x10ad0000,0x10b20000)] > 0x10525000 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=11232, stack(0x10bc0000,0x10c10000)] > 0x10523c00 JavaThread "Attach Listener" daemon [_thread_blocked, id=16228, stack(0x106f0000,0x10740000)] > 0x10522c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=10324, stack(0x10b20000,0x10b70000)] > 0x104ca000 JavaThread "Finalizer" daemon [_thread_blocked, id=11864, stack(0x109d0000,0x10a20000)] > 0x104c4000 JavaThread "Reference Handler" daemon [_thread_blocked, id=15388, stack(0x10a30000,0x10a80000)] > > Other Threads: > 0x00aff800 VMThread [stack: 0x10760000,0x107b0000] [id=15344] > 0x1053d400 WatcherThread [stack: 0x10f10000,0x10f60000] [id=10968] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap > def new generation total 4928K, used 718K [0x04450000, 0x049a0000, 0x06ef0000) > eden space 4416K, 9% used [0x04450000, 0x044bda98, 0x048a0000) > from space 512K, 54% used [0x04920000, 0x04966020, 0x049a0000) > to space 512K, 0% used [0x048a0000, 0x048a0000, 0x04920000) > tenured generation total 10944K, used 6794K [0x06ef0000, 0x079a0000, 0x0c450000) > the space 10944K, 62% used [0x06ef0000, 0x07592988, 0x07592a00, 0x079a0000) > compacting perm gen total 15616K, used 15582K [0x0c450000, 0x0d390000, 0x10450000) > the space 15616K, 99% used [0x0c450000, 0x0d387a40, 0x0d387c00, 0x0d390000) > No shared spaces configured. > > Code Cache [0x02450000, 0x02638000, 0x04450000) > total_blobs=1078 nmethods=832 adapters=182 free_code_cache=30832Kb largest_free_block=31570240 > > Dynamic libraries: > 0x00bf0000 - 0x00c1c000 C:\ikernel\dist\openjdk7\bin\java.exe > 0x77900000 - 0x77a80000 C:\Windows\SysWOW64\ntdll.dll > 0x767e0000 - 0x768f0000 C:\Windows\syswow64\kernel32.dll > 0x76790000 - 0x767d7000 C:\Windows\syswow64\KERNELBASE.dll > 0x766f0000 - 0x76790000 C:\Windows\syswow64\ADVAPI32.dll > 0x75870000 - 0x7591c000 C:\Windows\syswow64\msvcrt.dll > 0x774e0000 - 0x774f9000 C:\Windows\SysWOW64\sechost.dll > 0x76600000 - 0x766f0000 C:\Windows\syswow64\RPCRT4.dll > 0x75320000 - 0x75380000 C:\Windows\syswow64\SspiCli.dll > 0x75310000 - 0x7531c000 C:\Windows\syswow64\CRYPTBASE.dll > 0x76cc0000 - 0x76dc0000 C:\Windows\syswow64\USER32.dll > 0x772a0000 - 0x77330000 C:\Windows\syswow64\GDI32.dll > 0x76cb0000 - 0x76cba000 C:\Windows\syswow64\LPK.dll > 0x769d0000 - 0x76a6d000 C:\Windows\syswow64\USP10.dll > 0x71020000 - 0x711be000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL32.dll > 0x77460000 - 0x774b7000 C:\Windows\syswow64\SHLWAPI.dll > 0x76570000 - 0x765d0000 C:\Windows\system32\IMM32.DLL > 0x76fd0000 - 0x7709c000 C:\Windows\syswow64\MSCTF.dll > 0x68000000 - 0x68036000 C:\Windows\system32\QIPCAP.DLL > 0x76920000 - 0x769af000 C:\Windows\syswow64\OLEAUT32.dll > 0x76b50000 - 0x76cac000 C:\Windows\syswow64\ole32.dll > 0x622b0000 - 0x6236d000 C:\ikernel\dist\openjdk7\bin\msvcr100.dll > 0x5a810000 - 0x5ab36000 C:\ikernel\dist\openjdk7\bin\client\jvm.dll > 0x740a0000 - 0x740d2000 C:\Windows\system32\WINMM.dll > 0x769b0000 - 0x769b5000 C:\Windows\syswow64\PSAPI.DLL > 0x71620000 - 0x7162c000 C:\ikernel\dist\openjdk7\bin\verify.dll > 0x645e0000 - 0x64600000 C:\ikernel\dist\openjdk7\bin\java.dll > 0x64580000 - 0x64593000 C:\ikernel\dist\openjdk7\bin\zip.dll > 0x64320000 - 0x64334000 C:\ikernel\dist\openjdk7\bin\net.dll > 0x770a0000 - 0x770d5000 C:\Windows\syswow64\WS2_32.dll > 0x77330000 - 0x77336000 C:\Windows\syswow64\NSI.dll > 0x744b0000 - 0x744ec000 C:\Windows\system32\mswsock.dll > 0x71ba0000 - 0x71ba6000 C:\Windows\System32\wship6.dll > 0x718f0000 - 0x718ff000 C:\ikernel\dist\openjdk7\bin\nio.dll > 0x74190000 - 0x741a6000 C:\Windows\system32\CRYPTSP.dll > 0x74150000 - 0x7418b000 C:\Windows\system32\rsaenh.dll > 0x72160000 - 0x72177000 C:\Windows\system32\USERENV.dll > 0x73cc0000 - 0x73ccb000 C:\Windows\system32\profapi.dll > 0x742f0000 - 0x74300000 C:\Windows\system32\NLAapi.dll > 0x742e0000 - 0x742f0000 C:\Windows\system32\napinsp.dll > 0x742c0000 - 0x742d2000 C:\Windows\system32\pnrpnsp.dll > 0x74270000 - 0x742b4000 C:\Windows\system32\DNSAPI.dll > 0x74260000 - 0x74268000 C:\Windows\System32\winrnr.dll > 0x74250000 - 0x7425d000 C:\Windows\system32\wshbth.dll > 0x645b0000 - 0x645d7000 C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live\WLIDNSP.DLL > 0x74560000 - 0x7457c000 C:\Windows\system32\IPHLPAPI.DLL > 0x74550000 - 0x74557000 C:\Windows\system32\WINNSI.DLL > 0x74210000 - 0x74248000 C:\Windows\System32\fwpuclnt.dll > 0x74200000 - 0x74206000 C:\Windows\system32\rasadhlp.dll > 0x71610000 - 0x7161a000 C:\ikernel\dist\openjdk7\bin\management.dll > 0x10c10000 - 0x10c5e000 C:\ikernel\dist\lib\wrapper.dll > 0x744a0000 - 0x744a5000 C:\Windows\System32\wshtcpip.dll > 0x62940000 - 0x629bd000 C:\ikernel\dist\lib\common-win32-native-1.0.6-SNAPSHOT.dll > 0x73690000 - 0x73699000 C:\Windows\system32\HID.DLL > 0x770e0000 - 0x7727d000 C:\Windows\syswow64\SETUPAPI.dll > 0x76fa0000 - 0x76fc7000 C:\Windows\syswow64\CFGMGR32.dll > 0x77280000 - 0x77292000 C:\Windows\syswow64\DEVOBJ.dll > 0x75920000 - 0x7656b000 C:\Windows\syswow64\SHELL32.dll > 0x64060000 - 0x64158000 C:\Windows\system32\CRYPTUI.dll > 0x755a0000 - 0x756bd000 C:\Windows\syswow64\CRYPT32.dll > 0x75730000 - 0x7573c000 C:\Windows\syswow64\MSASN1.dll > 0x768f0000 - 0x7691d000 C:\Windows\syswow64\WINTRUST.dll > 0x741e0000 - 0x741f2000 C:\Windows\system32\dhcpcsvc.DLL > 0x73910000 - 0x7391d000 C:\Windows\system32\dhcpcsvc6.DLL > 0x751b0000 - 0x751d1000 C:\Windows\system32\ntmarta.dll > 0x76b00000 - 0x76b45000 C:\Windows\syswow64\WLDAP32.dll > 0x731a0000 - 0x731b2000 C:\Windows\system32\SAMLIB.dll > 0x72f50000 - 0x72f72000 C:\Windows\system32\logoncli.dll > 0x74330000 - 0x74339000 C:\Windows\system32\netutils.dll > 0x5e750000 - 0x5e891000 C:\ikernel\dist\openjdk7\bin\awt.dll > 0x721a0000 - 0x72220000 C:\Windows\system32\uxtheme.dll > 0x73010000 - 0x73068000 C:\Program Files (x86)\Common Files\microsoft shared\ink\tiptsf.dll > 0x75240000 - 0x75249000 C:\Windows\system32\version.dll > 0x73e30000 - 0x73e43000 C:\Windows\system32\dwmapi.dll > 0x70600000 - 0x707c3000 C:\Windows\system32\d3d9.dll > 0x72f40000 - 0x72f46000 C:\Windows\system32\d3d8thk.dll > 0x69130000 - 0x69f98000 C:\Windows\system32\nvd3dum.dll > 0x72a80000 - 0x72aa5000 C:\Windows\system32\powrprof.dll > 0x628d0000 - 0x6293d000 C:\ikernel\dist\openjdk7\bin\freetype.dll > 0x602c0000 - 0x60345000 C:\ikernel\dist\openjdk7\bin\fontmanager.dll > 0x76a70000 - 0x76af3000 C:\Windows\syswow64\CLBCatQ.DLL > 0x737a0000 - 0x737dc000 C:\Windows\system32\oleacc.dll > 0x70ed0000 - 0x71000000 C:\Windows\system32\WindowsCodecs.dll > 0x744f0000 - 0x7453c000 C:\Windows\system32\apphelp.dll > 0x637b0000 - 0x637c2000 C:\Program Files (x86)\Common Files\TortoiseOverlays\TortoiseOverlays.dll > 0x72ac0000 - 0x72ad4000 C:\Program Files\TortoiseSVN\bin\TortoiseStub32.dll > 0x63740000 - 0x637b0000 C:\Program Files\TortoiseSVN\bin\TortoiseSVN32.dll > 0x76dd0000 - 0x76f94000 C:\Windows\syswow64\WININET.dll > 0x756c0000 - 0x756c4000 C:\Windows\syswow64\api-ms-win-downlevel-user32-l1-1-0.dll > 0x774d0000 - 0x774d4000 C:\Windows\syswow64\api-ms-win-downlevel-shlwapi-l1-1-0.dll > 0x77340000 - 0x77344000 C:\Windows\syswow64\api-ms-win-downlevel-version-l1-1-0.dll > 0x76dc0000 - 0x76dc3000 C:\Windows\syswow64\api-ms-win-downlevel-normaliz-l1-1-0.dll > 0x774c0000 - 0x774c3000 C:\Windows\syswow64\normaliz.DLL > 0x75380000 - 0x75595000 C:\Windows\syswow64\iertutil.dll > 0x778d0000 - 0x778d5000 C:\Windows\syswow64\api-ms-win-downlevel-advapi32-l1-1-0.dll > 0x633d0000 - 0x63735000 C:\Program Files\TortoiseSVN\bin\libsvn_tsvn32.dll > 0x633a0000 - 0x633c7000 C:\Program Files\TortoiseSVN\bin\libapr_tsvn32.dll > 0x632c0000 - 0x63396000 C:\Windows\system32\MSVCR110.dll > 0x63280000 - 0x632b8000 C:\Program Files\TortoiseSVN\bin\libaprutil_tsvn32.dll > 0x63fe0000 - 0x63fed000 C:\Program Files\TortoiseSVN\bin\intl3_tsvn32.dll > 0x63260000 - 0x63273000 C:\Program Files\TortoiseSVN\bin\libsasl32.dll > 0x72190000 - 0x72198000 C:\Windows\system32\Secur32.dll > 0x631d0000 - 0x63255000 C:\Windows\system32\MSVCP110.dll > 0x63150000 - 0x63181000 C:\Windows\system32\EhStorShell.dll > 0x71410000 - 0x71505000 C:\Windows\system32\PROPSYS.dll > 0x71e00000 - 0x71e70000 C:\Windows\system32\ntshrui.dll > 0x74310000 - 0x74329000 C:\Windows\system32\srvcli.dll > 0x741d0000 - 0x741db000 C:\Windows\system32\cscapi.dll > 0x72b60000 - 0x72b6a000 C:\Windows\system32\slc.dll > 0x73990000 - 0x73a14000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll > 0x6f950000 - 0x6fae8000 C:\Windows\system32\NetworkExplorer.dll > 0x726a0000 - 0x726ce000 C:\Windows\System32\shdocvw.dll > 0x741b0000 - 0x741c2000 C:\Windows\system32\MPR.dll > 0x71980000 - 0x71988000 C:\Windows\System32\drprov.dll > 0x73e70000 - 0x73e99000 C:\Windows\System32\WINSTA.dll > 0x71920000 - 0x71934000 C:\Windows\System32\ntlanman.dll > 0x73780000 - 0x73798000 C:\Windows\System32\davclnt.dll > 0x73800000 - 0x73808000 C:\Windows\System32\DAVHLPR.dll > 0x74300000 - 0x7430f000 C:\Windows\system32\wkscli.dll > 0x5dc80000 - 0x5deb8000 C:\Windows\system32\wpdshext.dll > 0x72ba0000 - 0x72d30000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_72d18a4386696c80\gdiplus.dll > 0x60750000 - 0x607d9000 C:\Windows\system32\PortableDeviceApi.dll > 0x64370000 - 0x6439b000 C:\Windows\system32\PortableDeviceTypes.dll > 0x62270000 - 0x622af000 C:\Windows\system32\audiodev.dll > 0x5d5b0000 - 0x5d817000 C:\Windows\system32\WMVCore.DLL > 0x642e0000 - 0x6431d000 C:\Windows\system32\WMASF.DLL > 0x64340000 - 0x64362000 C:\Windows\system32\EhStorAPI.dll > 0x73070000 - 0x730a9000 C:\Windows\System32\MMDevApi.dll > > VM Arguments: > jvm_args: -Djava.security.auth.login.config=jaas.config -Djava.net.preferIPv4Stack=true -XX:-UseSplitVerifier -Dfile.encoding=Cp1252 -Duser.language=en -Xmx128m -Djava.library.path=../lib/patch;../lib/level3;../lib/level2;../lib/level1;../lib;. -Dwrapper.key=dxgPdptyCLpDE9FBk2w3wf_1tGFfWs7N -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=14920 -Dwrapper.version=3.5.15-st -Dwrapper.native_library=wrapper -Dwrapper.cpu.timeout=180 -Dwrapper.jvmid=2 -Dwrapper.lang.domain=wrapper > java_command: net.inspiredbroadcast.legion.ikernel.core.Bootstrap > Launcher Type: SUN_STANDARD > > Environment Variables: > PATH=C:\ikernel\dist\lib;C:\ikernel\dist\lib;C:\ikernel\dist\bin\\..\lib > USERNAME=redacted > OS=Windows_NT > PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel > > > > --------------- S Y S T E M --------------- > > OS: Windows 7 , 64 bit Build 7601 Service Pack 1 > > CPU:total 4 (2 cores per cpu, 2 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht > > Memory: 4k page, physical 4166716k(1004748k free), swap 8331576k(2764928k free) > > vm_info: OpenJDK Client VM (22.0-b10) for windows-x86 JRE (1.7.0-INGG-administrator_2012_03_05_18_26-b00), built on Mar 5 2012 18:48:09 by "Administrator" with unknown MS VC++:1600 > > time: Tue Mar 17 14:39:08 2015 > elapsed time: 3 seconds > From mikael.gerdin at oracle.com Thu Mar 19 13:56:12 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 19 Mar 2015 14:56:12 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build Message-ID: <550AD57C.1030708@oracle.com> Hi, I recently ran into a compiler warning which is enabled by default in Solaris Studio, since HotSpot builds with warnings-as-errors this failed the build only when I got to the Solaris build. To catch this issue earlier for me (and a lot of others who use Linux as their preferred development platform) I suggest that we enable the equivalent warning for GCC. The patch to implement the change is inined below: diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make --- a/make/linux/makefiles/gcc.make +++ b/make/linux/makefiles/gcc.make @@ -207,7 +207,7 @@ WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body endif -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual ifeq ($(USE_CLANG),) # Since GCC 4.3, -Wconversion has changed its meanings to warn these implicit I've verified the change by building on all linux platforms through JPRT. /Mikael From mikael.gerdin at oracle.com Thu Mar 19 13:58:29 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 19 Mar 2015 14:58:29 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: <550AD57C.1030708@oracle.com> References: <550AD57C.1030708@oracle.com> Message-ID: <550AD605.2030706@oracle.com> Oh, and the bug id is 8075511 https://bugs.openjdk.java.net/browse/JDK-8075511 /Mikael On 2015-03-19 14:56, Mikael Gerdin wrote: > Hi, > > I recently ran into a compiler warning which is enabled by default in > Solaris Studio, since HotSpot builds with warnings-as-errors this failed > the build only when I got to the Solaris build. > To catch this issue earlier for me (and a lot of others who use Linux as > their preferred development platform) I suggest that we enable the > equivalent warning for GCC. > > The patch to implement the change is inined below: > > diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make > --- a/make/linux/makefiles/gcc.make > +++ b/make/linux/makefiles/gcc.make > @@ -207,7 +207,7 @@ > WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body > endif > > -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef > -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type > +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef > -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type > -Woverloaded-virtual > > ifeq ($(USE_CLANG),) > # Since GCC 4.3, -Wconversion has changed its meanings to warn these > implicit > > I've verified the change by building on all linux platforms through JPRT. > > /Mikael From erik.joelsson at oracle.com Thu Mar 19 14:18:16 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Mar 2015 15:18:16 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: <550AD605.2030706@oracle.com> References: <550AD57C.1030708@oracle.com> <550AD605.2030706@oracle.com> Message-ID: <550ADAA8.3090900@oracle.com> Looks good to me. /Erik On 2015-03-19 14:58, Mikael Gerdin wrote: > Oh, and the bug id is 8075511 > https://bugs.openjdk.java.net/browse/JDK-8075511 > > /Mikael > > On 2015-03-19 14:56, Mikael Gerdin wrote: >> Hi, >> >> I recently ran into a compiler warning which is enabled by default in >> Solaris Studio, since HotSpot builds with warnings-as-errors this failed >> the build only when I got to the Solaris build. >> To catch this issue earlier for me (and a lot of others who use Linux as >> their preferred development platform) I suggest that we enable the >> equivalent warning for GCC. >> >> The patch to implement the change is inined below: >> >> diff --git a/make/linux/makefiles/gcc.make >> b/make/linux/makefiles/gcc.make >> --- a/make/linux/makefiles/gcc.make >> +++ b/make/linux/makefiles/gcc.make >> @@ -207,7 +207,7 @@ >> WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body >> endif >> >> -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef >> -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type >> +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef >> -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type >> -Woverloaded-virtual >> >> ifeq ($(USE_CLANG),) >> # Since GCC 4.3, -Wconversion has changed its meanings to warn these >> implicit >> >> I've verified the change by building on all linux platforms through >> JPRT. >> >> /Mikael From volker.simonis at gmail.com Thu Mar 19 14:26:20 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 19 Mar 2015 15:26:20 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: <550AD57C.1030708@oracle.com> References: <550AD57C.1030708@oracle.com> Message-ID: Hi Mikael, the change looks good (and I think it is really reasonable to have this warning). I've also checked that our ancient gcc 4.1.2 already supports this option:) Regards, Volker On Thu, Mar 19, 2015 at 2:56 PM, Mikael Gerdin wrote: > Hi, > > I recently ran into a compiler warning which is enabled by default in > Solaris Studio, since HotSpot builds with warnings-as-errors this failed the > build only when I got to the Solaris build. > To catch this issue earlier for me (and a lot of others who use Linux as > their preferred development platform) I suggest that we enable the > equivalent warning for GCC. > > The patch to implement the change is inined below: > > diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make > --- a/make/linux/makefiles/gcc.make > +++ b/make/linux/makefiles/gcc.make > @@ -207,7 +207,7 @@ > WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body > endif > > -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > -Wunused-value -Wformat=2 -Wreturn-type > +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual > > ifeq ($(USE_CLANG),) > # Since GCC 4.3, -Wconversion has changed its meanings to warn these > implicit > > I've verified the change by building on all linux platforms through JPRT. > > /Mikael From bob.vandette at oracle.com Thu Mar 19 14:44:25 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 19 Mar 2015 10:44:25 -0400 Subject: JNI calling wrong method In-Reply-To: <550AC32B.1040801@oracle.com> References: <96DD6D5EB224D2419E81EF81E4D9C379082BB984@EX2K10MBX1.ad.london.inspiredbroadcast.net> <96DD6D5EB224D2419E81EF81E4D9C379082BC9A0@EX2K10MBX1.ad.london.inspiredbroadcast.net> <550AC32B.1040801@oracle.com> Message-ID: <44DDB449-B3C3-4791-B5C8-360AAEFEFE53@oracle.com> But Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create is not on the call stack, Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create+0x9a29 is?? Is Java_net_inspiredbroadcast_legion_jni_volume_MainVolume_setVolumeNative a globally exported function? Did you register it with the JNI Register natives function instead? Is it possible that your stack got corrupted in your native setVolume function and you returned to junk causing the transition to the middle of the create function? I?d set a breakpoint or put a DebugOutputString at the beginning of your Java_net_inspiredbroadcast_legion_jni_volume_MainVolume_setVolumeNative function to see if you actually get there. Bob. > On Mar 19, 2015, at 8:38 AM, Vladimir Ivanov wrote: > > (CCing: hotspot-dev at openjdk.java.net, BCCing: discuss at openjdk.java.net) > > Forwarding the discussion to hotspot-dev at ... alias, since it is the right place to discuss such issues. > > Best regards, > Vladimir Ivanov > > On 3/19/15 1:22 PM, Jiri Peinlich wrote: >> Hello, >> >> we have a java application that calls a native method from a dll. This works for us most of the time but very rarely on some Pcs the JNI is calling wrong native method. As we have finally a machine that reproduces the issue regularly we would like to investigate what is the reason and hopefully fix it, but we are out of ideas how to investigate the issue. >> >> Bellow you can see a java crash dump. It is visible there that we are trying to invoke method "setVolumeNative". The method "create" is invoked however. >> >> We would expect to see the following on stack: >> >> Java_net_inspiredbroadcast_legion_jni_volume_MainVolume_setVolumeNative >> >> But we see there this: Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create >> >> How should we investigate this issue? >> >> Thx, Jiri >> >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6294c518, pid=14900, tid=7008 >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK Client VM (22.0-b10 mixed mode windows-x86 ) >> # Problematic frame: >> # C [common-win32-native-1.0.6-SNAPSHOT.dll+0xc518] >> # >> # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> # See problematic frame for where to report the bug. >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x11969c00): JavaThread "Bootstrap" [_thread_in_native, id=7008, stack(0x12890000,0x128e0000)] >> >> siginfo: ExceptionCode=0xc0000005, reading address 0x00000000 >> >> Registers: >> EAX=0x00000000, EBX=0x0d3871c0, ECX=0x730a3130, EDX=0x128df744 >> ESP=0x128df730, EBP=0x128df754, ESI=0x0d3871c0, EDI=0x11969c00 >> EIP=0x6294c518, EFLAGS=0x00010247 >> >> Top of Stack: (sp=0x128df730) >> 0x128df730: 6299f488 00000001 00000000 128df744 >> 0x128df740: 00000001 00000000 80070490 00000000 >> 0x128df750: 00000000 128df788 6294bb31 11969d28 >> 0x128df760: 128df7c4 00000000 00000006 00000008 >> 0x128df770: 11969c00 0d3871c0 0d3871c0 128df7bc >> 0x128df780: 0245a4b7 00969c00 128df7bc 0245a5b7 >> 0x128df790: 11969d28 128df7c4 00000000 128df79c >> 0x128df7a0: 0d3871c0 128df7cc 0d387920 00000000 >> >> Instructions: (pc=0x6294c518) >> 0x6294c4f8: ff d1 c7 45 fc 00 00 00 00 c7 45 f0 00 00 00 00 >> 0x6294c508: 8d 55 f0 52 6a 00 6a 01 68 88 f4 99 62 8b 45 f8 >> 0x6294c518: 8b 08 8b 55 f8 52 8b 41 0c ff d0 89 45 f4 83 7d >> 0x6294c528: f4 00 74 16 68 70 f1 99 62 68 90 f1 99 62 8b 4d >> >> >> Register to memory mapping: >> >> EAX=0x00000000 is an unknown value >> EBX=0x0d3871c0 is an oop >> {method} >> - klass: {other class} >> ECX=0x730a3130 is an unknown value >> EDX=0x128df744 is pointing into the stack for thread: 0x11969c00 >> ESP=0x128df730 is pointing into the stack for thread: 0x11969c00 >> EBP=0x128df754 is pointing into the stack for thread: 0x11969c00 >> ESI=0x0d3871c0 is an oop >> {method} >> - klass: {other class} >> EDI=0x11969c00 is a thread >> >> >> Stack: [0x12890000,0x128e0000], sp=0x128df730, free space=317k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> C [common-win32-native-1.0.6-SNAPSHOT.dll+0xc518] Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create+0xa410 >> C [common-win32-native-1.0.6-SNAPSHOT.dll+0xbb31] Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create+0x9a29 >> j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolumeNative(I)V+0 >> j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolume(I)V+49 >> j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.setVolume(I)V+100 >> j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.startUp()V+49 >> j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceLoaderImpl.()V+210 >> j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceHandler.initialise()V+176 >> j net.inspiredbroadcast.legion.ikernel.core.BootstrapDelegate.start()Ljava/lang/Integer;+318 >> j net.inspiredbroadcast.legion.ikernel.core.Bootstrap.start([Ljava/lang/String;)Ljava/lang/Integer;+14 >> j org.tanukisoftware.wrapper.WrapperManager$11.run()V+75 >> v ~StubRoutines::call_stub >> V [jvm.dll+0x1233ba] >> V [jvm.dll+0x1c8f7e] >> V [jvm.dll+0x1235a3] >> V [jvm.dll+0x123607] >> V [jvm.dll+0xcd1ef] >> V [jvm.dll+0x1430af] >> V [jvm.dll+0x1711e9] >> C [msvcr100.dll+0x10fac] freefls+0x130 >> C [msvcr100.dll+0x110b1] __fls_getvalue+0x58 >> C [kernel32.dll+0x133aa] BaseThreadInitThunk+0x12 >> C [ntdll.dll+0x3bf32] RtlInitializeExceptionChain+0x63 >> C [ntdll.dll+0x3bf05] RtlInitializeExceptionChain+0x36 >> >> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >> j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolumeNative(I)V+0 >> j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolume(I)V+49 >> j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.setVolume(I)V+100 >> j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.startUp()V+49 >> j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceLoaderImpl.()V+210 >> j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceHandler.initialise()V+176 >> j net.inspiredbroadcast.legion.ikernel.core.BootstrapDelegate.start()Ljava/lang/Integer;+318 >> j net.inspiredbroadcast.legion.ikernel.core.Bootstrap.start([Ljava/lang/String;)Ljava/lang/Integer;+14 >> j org.tanukisoftware.wrapper.WrapperManager$11.run()V+75 >> v ~StubRoutines::call_stub >> >> --------------- P R O C E S S --------------- >> >> Java Threads: ( => current thread ) >> 0x11e76c00 JavaThread "CashHandlingWorker" daemon [_thread_blocked, id=5732, stack(0x18e60000,0x18eb0000)] >> 0x11e76800 JavaThread "Swing-Shell" daemon [_thread_blocked, id=15856, stack(0x13220000,0x13270000)] >> 0x11e76000 JavaThread "NetConn Monitor" daemon [_thread_blocked, id=15932, stack(0x18560000,0x185b0000)] >> 0x11c02800 JavaThread "AudioPlayerThread" [_thread_blocked, id=15000, stack(0x18b90000,0x18be0000)] >> 0x11c02000 JavaThread "D3D Screen Updater" daemon [_thread_blocked, id=14308, stack(0x185d0000,0x18620000)] >> 0x11c01c00 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=8760, stack(0x17860000,0x178b0000)] >> 0x11c01400 JavaThread "AWT-Windows" daemon [_thread_in_native, id=12852, stack(0x13280000,0x132d0000)] >> 0x11c01000 JavaThread "AWT-Shutdown" [_thread_blocked, id=7156, stack(0x12f70000,0x12fc0000)] >> 0x11c00800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=16016, stack(0x12840000,0x12890000)] >> 0x11c00000 JavaThread "TelnetServer" [_thread_in_native, id=6376, stack(0x12ed0000,0x12f20000)] >> 0x11bffc00 JavaThread "EventWorker" daemon [_thread_blocked, id=14384, stack(0x12280000,0x122d0000)] >> 0x11bff000 JavaThread "ScheduleHandler" daemon [_thread_blocked, id=15584, stack(0x13050000,0x130a0000)] >> 0x11a21400 JavaThread "MarimbaDownloadStatusMessenger" [_thread_blocked, id=10380, stack(0x113e0000,0x11430000)] >> 0x11a06c00 JavaThread "MetersWorkingThread" [_thread_blocked, id=7028, stack(0x10d00000,0x10d50000)] >> 0x119e4800 JavaThread "SuspensionEvaluatorDaemon" daemon [_thread_blocked, id=12132, stack(0x12690000,0x126e0000)] >> 0x119e3000 JavaThread "Announcer" daemon [_thread_blocked, id=12116, stack(0x129f0000,0x12a40000)] >> 0x119e2800 JavaThread "Asyncmessage sending thread" [_thread_blocked, id=16036, stack(0x125f0000,0x12640000)] >> =>0x11969c00 JavaThread "Bootstrap" [_thread_in_native, id=7008, stack(0x12890000,0x128e0000)] >> 0x009adc00 JavaThread "DestroyJavaVM" [_thread_blocked, id=14360, stack(0x00b20000,0x00b70000)] >> 0x1192bc00 JavaThread "Wrapper-Connection" daemon [_thread_in_native, id=15560, stack(0x12640000,0x12690000)] >> 0x118f9c00 JavaThread "Wrapper-Startup-Runner" [_thread_blocked, id=9208, stack(0x12760000,0x127b0000)] >> 0x11918c00 JavaThread "Wrapper-Control-Event-Monitor" daemon [_thread_blocked, id=15772, stack(0x12700000,0x12750000)] >> 0x118c9400 JavaThread "Cerberus 1" daemon [_thread_blocked, id=10816, stack(0x12330000,0x12380000)] >> 0x11325000 JavaThread "ProcessHandler" daemon [_thread_blocked, id=14040, stack(0x11430000,0x11480000)] >> 0x10529800 JavaThread "Service Thread" daemon [_thread_blocked, id=11748, stack(0x10ad0000,0x10b20000)] >> 0x10525000 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=11232, stack(0x10bc0000,0x10c10000)] >> 0x10523c00 JavaThread "Attach Listener" daemon [_thread_blocked, id=16228, stack(0x106f0000,0x10740000)] >> 0x10522c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=10324, stack(0x10b20000,0x10b70000)] >> 0x104ca000 JavaThread "Finalizer" daemon [_thread_blocked, id=11864, stack(0x109d0000,0x10a20000)] >> 0x104c4000 JavaThread "Reference Handler" daemon [_thread_blocked, id=15388, stack(0x10a30000,0x10a80000)] >> >> Other Threads: >> 0x00aff800 VMThread [stack: 0x10760000,0x107b0000] [id=15344] >> 0x1053d400 WatcherThread [stack: 0x10f10000,0x10f60000] [id=10968] >> >> VM state:not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: None >> >> Heap >> def new generation total 4928K, used 718K [0x04450000, 0x049a0000, 0x06ef0000) >> eden space 4416K, 9% used [0x04450000, 0x044bda98, 0x048a0000) >> from space 512K, 54% used [0x04920000, 0x04966020, 0x049a0000) >> to space 512K, 0% used [0x048a0000, 0x048a0000, 0x04920000) >> tenured generation total 10944K, used 6794K [0x06ef0000, 0x079a0000, 0x0c450000) >> the space 10944K, 62% used [0x06ef0000, 0x07592988, 0x07592a00, 0x079a0000) >> compacting perm gen total 15616K, used 15582K [0x0c450000, 0x0d390000, 0x10450000) >> the space 15616K, 99% used [0x0c450000, 0x0d387a40, 0x0d387c00, 0x0d390000) >> No shared spaces configured. >> >> Code Cache [0x02450000, 0x02638000, 0x04450000) >> total_blobs=1078 nmethods=832 adapters=182 free_code_cache=30832Kb largest_free_block=31570240 >> >> Dynamic libraries: >> 0x00bf0000 - 0x00c1c000 C:\ikernel\dist\openjdk7\bin\java.exe >> 0x77900000 - 0x77a80000 C:\Windows\SysWOW64\ntdll.dll >> 0x767e0000 - 0x768f0000 C:\Windows\syswow64\kernel32.dll >> 0x76790000 - 0x767d7000 C:\Windows\syswow64\KERNELBASE.dll >> 0x766f0000 - 0x76790000 C:\Windows\syswow64\ADVAPI32.dll >> 0x75870000 - 0x7591c000 C:\Windows\syswow64\msvcrt.dll >> 0x774e0000 - 0x774f9000 C:\Windows\SysWOW64\sechost.dll >> 0x76600000 - 0x766f0000 C:\Windows\syswow64\RPCRT4.dll >> 0x75320000 - 0x75380000 C:\Windows\syswow64\SspiCli.dll >> 0x75310000 - 0x7531c000 C:\Windows\syswow64\CRYPTBASE.dll >> 0x76cc0000 - 0x76dc0000 C:\Windows\syswow64\USER32.dll >> 0x772a0000 - 0x77330000 C:\Windows\syswow64\GDI32.dll >> 0x76cb0000 - 0x76cba000 C:\Windows\syswow64\LPK.dll >> 0x769d0000 - 0x76a6d000 C:\Windows\syswow64\USP10.dll >> 0x71020000 - 0x711be000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL32.dll >> 0x77460000 - 0x774b7000 C:\Windows\syswow64\SHLWAPI.dll >> 0x76570000 - 0x765d0000 C:\Windows\system32\IMM32.DLL >> 0x76fd0000 - 0x7709c000 C:\Windows\syswow64\MSCTF.dll >> 0x68000000 - 0x68036000 C:\Windows\system32\QIPCAP.DLL >> 0x76920000 - 0x769af000 C:\Windows\syswow64\OLEAUT32.dll >> 0x76b50000 - 0x76cac000 C:\Windows\syswow64\ole32.dll >> 0x622b0000 - 0x6236d000 C:\ikernel\dist\openjdk7\bin\msvcr100.dll >> 0x5a810000 - 0x5ab36000 C:\ikernel\dist\openjdk7\bin\client\jvm.dll >> 0x740a0000 - 0x740d2000 C:\Windows\system32\WINMM.dll >> 0x769b0000 - 0x769b5000 C:\Windows\syswow64\PSAPI.DLL >> 0x71620000 - 0x7162c000 C:\ikernel\dist\openjdk7\bin\verify.dll >> 0x645e0000 - 0x64600000 C:\ikernel\dist\openjdk7\bin\java.dll >> 0x64580000 - 0x64593000 C:\ikernel\dist\openjdk7\bin\zip.dll >> 0x64320000 - 0x64334000 C:\ikernel\dist\openjdk7\bin\net.dll >> 0x770a0000 - 0x770d5000 C:\Windows\syswow64\WS2_32.dll >> 0x77330000 - 0x77336000 C:\Windows\syswow64\NSI.dll >> 0x744b0000 - 0x744ec000 C:\Windows\system32\mswsock.dll >> 0x71ba0000 - 0x71ba6000 C:\Windows\System32\wship6.dll >> 0x718f0000 - 0x718ff000 C:\ikernel\dist\openjdk7\bin\nio.dll >> 0x74190000 - 0x741a6000 C:\Windows\system32\CRYPTSP.dll >> 0x74150000 - 0x7418b000 C:\Windows\system32\rsaenh.dll >> 0x72160000 - 0x72177000 C:\Windows\system32\USERENV.dll >> 0x73cc0000 - 0x73ccb000 C:\Windows\system32\profapi.dll >> 0x742f0000 - 0x74300000 C:\Windows\system32\NLAapi.dll >> 0x742e0000 - 0x742f0000 C:\Windows\system32\napinsp.dll >> 0x742c0000 - 0x742d2000 C:\Windows\system32\pnrpnsp.dll >> 0x74270000 - 0x742b4000 C:\Windows\system32\DNSAPI.dll >> 0x74260000 - 0x74268000 C:\Windows\System32\winrnr.dll >> 0x74250000 - 0x7425d000 C:\Windows\system32\wshbth.dll >> 0x645b0000 - 0x645d7000 C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live\WLIDNSP.DLL >> 0x74560000 - 0x7457c000 C:\Windows\system32\IPHLPAPI.DLL >> 0x74550000 - 0x74557000 C:\Windows\system32\WINNSI.DLL >> 0x74210000 - 0x74248000 C:\Windows\System32\fwpuclnt.dll >> 0x74200000 - 0x74206000 C:\Windows\system32\rasadhlp.dll >> 0x71610000 - 0x7161a000 C:\ikernel\dist\openjdk7\bin\management.dll >> 0x10c10000 - 0x10c5e000 C:\ikernel\dist\lib\wrapper.dll >> 0x744a0000 - 0x744a5000 C:\Windows\System32\wshtcpip.dll >> 0x62940000 - 0x629bd000 C:\ikernel\dist\lib\common-win32-native-1.0.6-SNAPSHOT.dll >> 0x73690000 - 0x73699000 C:\Windows\system32\HID.DLL >> 0x770e0000 - 0x7727d000 C:\Windows\syswow64\SETUPAPI.dll >> 0x76fa0000 - 0x76fc7000 C:\Windows\syswow64\CFGMGR32.dll >> 0x77280000 - 0x77292000 C:\Windows\syswow64\DEVOBJ.dll >> 0x75920000 - 0x7656b000 C:\Windows\syswow64\SHELL32.dll >> 0x64060000 - 0x64158000 C:\Windows\system32\CRYPTUI.dll >> 0x755a0000 - 0x756bd000 C:\Windows\syswow64\CRYPT32.dll >> 0x75730000 - 0x7573c000 C:\Windows\syswow64\MSASN1.dll >> 0x768f0000 - 0x7691d000 C:\Windows\syswow64\WINTRUST.dll >> 0x741e0000 - 0x741f2000 C:\Windows\system32\dhcpcsvc.DLL >> 0x73910000 - 0x7391d000 C:\Windows\system32\dhcpcsvc6.DLL >> 0x751b0000 - 0x751d1000 C:\Windows\system32\ntmarta.dll >> 0x76b00000 - 0x76b45000 C:\Windows\syswow64\WLDAP32.dll >> 0x731a0000 - 0x731b2000 C:\Windows\system32\SAMLIB.dll >> 0x72f50000 - 0x72f72000 C:\Windows\system32\logoncli.dll >> 0x74330000 - 0x74339000 C:\Windows\system32\netutils.dll >> 0x5e750000 - 0x5e891000 C:\ikernel\dist\openjdk7\bin\awt.dll >> 0x721a0000 - 0x72220000 C:\Windows\system32\uxtheme.dll >> 0x73010000 - 0x73068000 C:\Program Files (x86)\Common Files\microsoft shared\ink\tiptsf.dll >> 0x75240000 - 0x75249000 C:\Windows\system32\version.dll >> 0x73e30000 - 0x73e43000 C:\Windows\system32\dwmapi.dll >> 0x70600000 - 0x707c3000 C:\Windows\system32\d3d9.dll >> 0x72f40000 - 0x72f46000 C:\Windows\system32\d3d8thk.dll >> 0x69130000 - 0x69f98000 C:\Windows\system32\nvd3dum.dll >> 0x72a80000 - 0x72aa5000 C:\Windows\system32\powrprof.dll >> 0x628d0000 - 0x6293d000 C:\ikernel\dist\openjdk7\bin\freetype.dll >> 0x602c0000 - 0x60345000 C:\ikernel\dist\openjdk7\bin\fontmanager.dll >> 0x76a70000 - 0x76af3000 C:\Windows\syswow64\CLBCatQ.DLL >> 0x737a0000 - 0x737dc000 C:\Windows\system32\oleacc.dll >> 0x70ed0000 - 0x71000000 C:\Windows\system32\WindowsCodecs.dll >> 0x744f0000 - 0x7453c000 C:\Windows\system32\apphelp.dll >> 0x637b0000 - 0x637c2000 C:\Program Files (x86)\Common Files\TortoiseOverlays\TortoiseOverlays.dll >> 0x72ac0000 - 0x72ad4000 C:\Program Files\TortoiseSVN\bin\TortoiseStub32.dll >> 0x63740000 - 0x637b0000 C:\Program Files\TortoiseSVN\bin\TortoiseSVN32.dll >> 0x76dd0000 - 0x76f94000 C:\Windows\syswow64\WININET.dll >> 0x756c0000 - 0x756c4000 C:\Windows\syswow64\api-ms-win-downlevel-user32-l1-1-0.dll >> 0x774d0000 - 0x774d4000 C:\Windows\syswow64\api-ms-win-downlevel-shlwapi-l1-1-0.dll >> 0x77340000 - 0x77344000 C:\Windows\syswow64\api-ms-win-downlevel-version-l1-1-0.dll >> 0x76dc0000 - 0x76dc3000 C:\Windows\syswow64\api-ms-win-downlevel-normaliz-l1-1-0.dll >> 0x774c0000 - 0x774c3000 C:\Windows\syswow64\normaliz.DLL >> 0x75380000 - 0x75595000 C:\Windows\syswow64\iertutil.dll >> 0x778d0000 - 0x778d5000 C:\Windows\syswow64\api-ms-win-downlevel-advapi32-l1-1-0.dll >> 0x633d0000 - 0x63735000 C:\Program Files\TortoiseSVN\bin\libsvn_tsvn32.dll >> 0x633a0000 - 0x633c7000 C:\Program Files\TortoiseSVN\bin\libapr_tsvn32.dll >> 0x632c0000 - 0x63396000 C:\Windows\system32\MSVCR110.dll >> 0x63280000 - 0x632b8000 C:\Program Files\TortoiseSVN\bin\libaprutil_tsvn32.dll >> 0x63fe0000 - 0x63fed000 C:\Program Files\TortoiseSVN\bin\intl3_tsvn32.dll >> 0x63260000 - 0x63273000 C:\Program Files\TortoiseSVN\bin\libsasl32.dll >> 0x72190000 - 0x72198000 C:\Windows\system32\Secur32.dll >> 0x631d0000 - 0x63255000 C:\Windows\system32\MSVCP110.dll >> 0x63150000 - 0x63181000 C:\Windows\system32\EhStorShell.dll >> 0x71410000 - 0x71505000 C:\Windows\system32\PROPSYS.dll >> 0x71e00000 - 0x71e70000 C:\Windows\system32\ntshrui.dll >> 0x74310000 - 0x74329000 C:\Windows\system32\srvcli.dll >> 0x741d0000 - 0x741db000 C:\Windows\system32\cscapi.dll >> 0x72b60000 - 0x72b6a000 C:\Windows\system32\slc.dll >> 0x73990000 - 0x73a14000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll >> 0x6f950000 - 0x6fae8000 C:\Windows\system32\NetworkExplorer.dll >> 0x726a0000 - 0x726ce000 C:\Windows\System32\shdocvw.dll >> 0x741b0000 - 0x741c2000 C:\Windows\system32\MPR.dll >> 0x71980000 - 0x71988000 C:\Windows\System32\drprov.dll >> 0x73e70000 - 0x73e99000 C:\Windows\System32\WINSTA.dll >> 0x71920000 - 0x71934000 C:\Windows\System32\ntlanman.dll >> 0x73780000 - 0x73798000 C:\Windows\System32\davclnt.dll >> 0x73800000 - 0x73808000 C:\Windows\System32\DAVHLPR.dll >> 0x74300000 - 0x7430f000 C:\Windows\system32\wkscli.dll >> 0x5dc80000 - 0x5deb8000 C:\Windows\system32\wpdshext.dll >> 0x72ba0000 - 0x72d30000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_72d18a4386696c80\gdiplus.dll >> 0x60750000 - 0x607d9000 C:\Windows\system32\PortableDeviceApi.dll >> 0x64370000 - 0x6439b000 C:\Windows\system32\PortableDeviceTypes.dll >> 0x62270000 - 0x622af000 C:\Windows\system32\audiodev.dll >> 0x5d5b0000 - 0x5d817000 C:\Windows\system32\WMVCore.DLL >> 0x642e0000 - 0x6431d000 C:\Windows\system32\WMASF.DLL >> 0x64340000 - 0x64362000 C:\Windows\system32\EhStorAPI.dll >> 0x73070000 - 0x730a9000 C:\Windows\System32\MMDevApi.dll >> >> VM Arguments: >> jvm_args: -Djava.security.auth.login.config=jaas.config -Djava.net.preferIPv4Stack=true -XX:-UseSplitVerifier -Dfile.encoding=Cp1252 -Duser.language=en -Xmx128m -Djava.library.path=../lib/patch;../lib/level3;../lib/level2;../lib/level1;../lib;. -Dwrapper.key=dxgPdptyCLpDE9FBk2w3wf_1tGFfWs7N -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=14920 -Dwrapper.version=3.5.15-st -Dwrapper.native_library=wrapper -Dwrapper.cpu.timeout=180 -Dwrapper.jvmid=2 -Dwrapper.lang.domain=wrapper >> java_command: net.inspiredbroadcast.legion.ikernel.core.Bootstrap >> Launcher Type: SUN_STANDARD >> >> Environment Variables: >> PATH=C:\ikernel\dist\lib;C:\ikernel\dist\lib;C:\ikernel\dist\bin\\..\lib >> USERNAME=redacted >> OS=Windows_NT >> PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel >> >> >> >> --------------- S Y S T E M --------------- >> >> OS: Windows 7 , 64 bit Build 7601 Service Pack 1 >> >> CPU:total 4 (2 cores per cpu, 2 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht >> >> Memory: 4k page, physical 4166716k(1004748k free), swap 8331576k(2764928k free) >> >> vm_info: OpenJDK Client VM (22.0-b10) for windows-x86 JRE (1.7.0-INGG-administrator_2012_03_05_18_26-b00), built on Mar 5 2012 18:48:09 by "Administrator" with unknown MS VC++:1600 >> >> time: Tue Mar 17 14:39:08 2015 >> elapsed time: 3 seconds >> From vladimir.kozlov at oracle.com Thu Mar 19 15:59:59 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Mar 2015 08:59:59 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550A90CE.9080901@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> Message-ID: <550AF27F.4050305@oracle.com> If you are asking about HeapByteBufferTest.java test put it into: hotspot/test/compiler/intrinsics/unsafe/ Vladimir On 3/19/15 2:03 AM, Andrew Haley wrote: > People, please. > > I have been working on this for weeks. All I am waiting on now > is a decision about where the test case should go. Can I have a > decision so we can get this in? > > Thanks, > Andrew. > From jesper.wilhelmsson at oracle.com Thu Mar 19 16:09:29 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 19 Mar 2015 17:09:29 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> <5502DBF4.9040508@oracle.com> <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> Message-ID: <550AF4B9.9000602@oracle.com> Hi, The original change has been approved by both Kim and Thomas and is good to go. It was decided to include the fix for the log rotation bug discovered in this review as well. A new webrev including this fix is available here: http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.03/ The only change compared to the previous webrev is the bugfix in src/share/vm/utilities/ostream.hpp Thanks, /Jesper Kim Barrett skrev den 16/3/15 18:40: > On Mar 13, 2015, at 8:45 AM, Jesper Wilhelmsson wrote: >> >> Hi Kim and Thomas, >> >> Thanks for the reviews! >> >> A new webrev is available here: >> >> http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.02/ >> >> There is an incremental diff as well with the latest changes suggested by you. > > Looks good. > > Please remember to file CR for log rotation test. > From serguei.spitsyn at oracle.com Thu Mar 19 16:16:47 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 19 Mar 2015 09:16:47 -0700 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5503211B.90309@oracle.com> References: <5502755A.5060309@oracle.com> <5503211B.90309@oracle.com> Message-ID: <550AF66F.8000102@oracle.com> I need another reviewer for this. Thanks, Serguei On 3/13/15 10:40 AM, Coleen Phillimore wrote: > > Serguei, > > This looks good. This works a lot harder to find the original method > than the code used to. > > Thanks, > Coleen > > On 3/13/15, 1:27 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ >> >> >> Open webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ >> >> >> >> Summary: >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> The plan is also to backport the fix to 8u60. >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei > From Alan.Bateman at oracle.com Thu Mar 19 16:33:00 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Mar 2015 16:33:00 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550AF27F.4050305@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> Message-ID: <550AFA3C.5030002@oracle.com> On 19/03/2015 15:59, Vladimir Kozlov wrote: > If you are asking about HeapByteBufferTest.java test put it into: > > hotspot/test/compiler/intrinsics/unsafe/ > > Vladimir The existing tests for buffers are in jdk/test/java/nio/Buffer and would nice to have all the tests for this API together if possible. So I guess the issue here is that it's one test serving two purposes, it feel that there should be a new test that exercises Unsafe directly to put into the hotspot/test/compiler tree. -Alan From aph at redhat.com Thu Mar 19 16:43:39 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Mar 2015 16:43:39 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550AFA3C.5030002@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> Message-ID: <550AFCBB.6080905@redhat.com> On 03/19/2015 04:33 PM, Alan Bateman wrote: > On 19/03/2015 15:59, Vladimir Kozlov wrote: >> If you are asking about HeapByteBufferTest.java test put it into: >> >> hotspot/test/compiler/intrinsics/unsafe/ >> >> Vladimir > The existing tests for buffers are in jdk/test/java/nio/Buffer and would > nice to have all the tests for this API together if possible. So I guess > the issue here is that it's one test serving two purposes, it feel that > there should be a new test that exercises Unsafe directly to put into > the hotspot/test/compiler tree. Within reason I'll do whatever you want, but I'm as sure as I can be that this test gives the new part of Unsafe a thorough workout. We need HeapByteBufferTest.java because of the substantial changes to that class. I don't know what a test of the unsafe aligned methods would do that is not done by HeapByteBufferTest. Andrew. From aph at redhat.com Thu Mar 19 16:44:46 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Mar 2015 16:44:46 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550AFCBB.6080905@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFCBB.6080905@redhat.com> Message-ID: <550AFCFE.80500@redhat.com> On 03/19/2015 04:43 PM, Andrew Haley wrote: > On 03/19/2015 04:33 PM, Alan Bateman wrote: >> On 19/03/2015 15:59, Vladimir Kozlov wrote: >>> If you are asking about HeapByteBufferTest.java test put it into: >>> >>> hotspot/test/compiler/intrinsics/unsafe/ >>> >>> Vladimir >> The existing tests for buffers are in jdk/test/java/nio/Buffer and would >> nice to have all the tests for this API together if possible. So I guess >> the issue here is that it's one test serving two purposes, it feel that >> there should be a new test that exercises Unsafe directly to put into >> the hotspot/test/compiler tree. > > Within reason I'll do whatever you want, but I'm as sure as I can be > that this test gives the new part of Unsafe a thorough workout. We > need HeapByteBufferTest.java because of the substantial changes to > that class. I don't know what a test of the unsafe aligned methods unaligned > would do that is not done by HeapByteBufferTest. > > Andrew. > From vladimir.kozlov at oracle.com Thu Mar 19 16:53:42 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Mar 2015 09:53:42 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550AFA3C.5030002@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> Message-ID: <550AFF16.9080600@oracle.com> New code did not change API of existing X-Buffer methods. It changed only how they are implementation. And already existing nio/Buffer tests should test these methods already. Regards, Vladimir On 3/19/15 9:33 AM, Alan Bateman wrote: > On 19/03/2015 15:59, Vladimir Kozlov wrote: >> If you are asking about HeapByteBufferTest.java test put it into: >> >> hotspot/test/compiler/intrinsics/unsafe/ >> >> Vladimir > The existing tests for buffers are in jdk/test/java/nio/Buffer and would > nice to have all the tests for this API together if possible. So I guess > the issue here is that it's one test serving two purposes, it feel that > there should be a new test that exercises Unsafe directly to put into > the hotspot/test/compiler tree. > > -Alan From daniel.daugherty at oracle.com Thu Mar 19 18:11:16 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 19 Mar 2015 12:11:16 -0600 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5502755A.5060309@oracle.com> References: <5502755A.5060309@oracle.com> Message-ID: <550B1144.303@oracle.com> On 3/12/15 11:27 PM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8067662 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ > Thumbs up. None of these comments are critical. src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/classfile/javaClasses.cpp line 1316: return method != NULL && (method->constants()->version() == version line 1317: && version < MAX_VERSION); Don't really need the parens and the indenting implies a logical grouping that isn't really there. Perhaps: return method != NULL && method->constants()->version() == version && version < MAX_VERSION; Although I also wonder why the caller would pass a 'version' value that is >= MAX_VERSION. Perhaps this instead: assert(version < MAX_VERSION, "version is too big"); return method != NULL && method->constants()->version() == version line 1347: typeArrayOop _cprefs; Perhaps add a comment: // needed to insulate method name against redefinition line 1486: holder = holder->get_klass_version(version); // Use specific ik version as a holder Perhaps the following comment instead: // Use specific ik version as a holder since the mirror might // refer to version that is now obsolete. I'm not sure "obsolete" is the right term here, but say something about why the mirror version is not good enough. Update: 'obsolete' is the right term now that I've re-read the code review invite! Perhaps this is better: // Use specific ik version as a holder since the mirror might // refer to version that is now obsolete and no longer accessible // via the previous versions list. line 1854: // Get method id, cpref, bci, version and mirror from chunk Perhaps: // Get method id, bci, version, mirror and cpref from chunk since that's the order you do the work... line 1909: holder = holder->get_klass_version(version); // Use specific ik version as a holder Similar comment as on line 1486. src/share/vm/oops/instanceKlass.hpp No comments. src/share/vm/oops/instanceKlass.cpp No comments. > Open webrev for unit test update: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ > test/java/lang/instrument/RedefineMethodInBacktrace.sh No comments. test/java/lang/instrument/RedefineMethodInBacktraceApp.java line 175: System.exit(1); A comment to explain why this test needs to exit on failure would be good. When the work to get rid of shell script driven tests gets here, it would be useful for understanding why this test must be standalone. test/java/lang/instrument/RedefineMethodInBacktraceTarget.java No comments. test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java No comments. test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java No comments. test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java No commetns. Dan > > > Summary: > An NPE is trown in a thread dumping via JMX when doing CPU profiling > in NetBeans Profiler and VisualVM. > The issue is that the methods and related klass versions are not > kept alive if a class redefinition > takes place between catching a Throwable and taking a thread dump. > It can result in loosing an obsolete method, and so, the > reconstruction of method name becomes impossible. > In such a case, the null reference is returned instead of a valid > method name. > > The solution is to use current klass version and method orig_idnum > instead of ordinary method idnum > to find required method pointer. In the worst case when the related > klass version is gone > (was not included to or was removed from the previous_versions > linked list), a saved method name > CP index of the latest klass version can be used to restore the > method name. > The footprint extra overhead for this approach is u2 per stack frame. > > The plan is also to backport the fix to 8u60. > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei > > From zoltan.majo at oracle.com Thu Mar 19 18:26:58 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 19 Mar 2015 19:26:58 +0100 Subject: [8u60] Request for approval: Backport of 8074869(S) Message-ID: <550B14F2.9040204@oracle.com> Hi, I would like to request the backport of the fix for JDK-8074869 to 8u60. Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8074869 Original patch: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fa8456e26deb Unfortunately, the fix does not apply cleanly because aarch64 is not available in 8u60. All other changes apply to the 8u60 tree. Webrev: http://cr.openjdk.java.net/~zmajo/8074869-8u/webrev.00/ Testing: All JPRT tests pass. Thank you and best regards, Zoltan From serguei.spitsyn at oracle.com Thu Mar 19 18:37:14 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 19 Mar 2015 11:37:14 -0700 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <550B1144.303@oracle.com> References: <5502755A.5060309@oracle.com> <550B1144.303@oracle.com> Message-ID: <550B175A.9060405@oracle.com> On 3/19/15 11:11 AM, Daniel D. Daugherty wrote: > On 3/12/15 11:27 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ >> > > Thumbs up. None of these comments are critical. Thanks a lot for the review, Dan! > > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/classfile/javaClasses.cpp > > line 1316: return method != NULL && > (method->constants()->version() == version > line 1317: && version < MAX_VERSION); > Don't really need the parens and the indenting implies > a logical grouping that isn't really there. Perhaps: > > return method != NULL && method->constants()->version() == > version > && version < MAX_VERSION; > > Although I also wonder why the caller would pass a 'version' > value that is >= MAX_VERSION. Perhaps this instead: > > assert(version < MAX_VERSION, "version is too big"); > return method != NULL && method->constants()->version() == > version > > line 1347: typeArrayOop _cprefs; > Perhaps add a comment: // needed to insulate method name > against redefinition > > line 1486: holder = holder->get_klass_version(version); // Use > specific ik version as a holder > Perhaps the following comment instead: > > // Use specific ik version as a holder since the mirror might > // refer to version that is now obsolete. > > I'm not sure "obsolete" is the right term here, but say > something about why the mirror version is not good enough. > > Update: 'obsolete' is the right term now that I've re-read the > code review invite! Perhaps this is better: > > // Use specific ik version as a holder since the mirror might > // refer to version that is now obsolete and no longer accessible > // via the previous versions list. > > line 1854: // Get method id, cpref, bci, version and mirror from > chunk > Perhaps: > > // Get method id, bci, version, mirror and cpref from chunk > > since that's the order you do the work... > > line 1909: holder = holder->get_klass_version(version); // Use > specific ik version as a holder > Similar comment as on line 1486. > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > No comments. > > >> Open webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ >> > > test/java/lang/instrument/RedefineMethodInBacktrace.sh > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceApp.java > line 175: System.exit(1); > A comment to explain why this test needs to exit on > failure would be good. When the work to get rid of > shell script driven tests gets here, it would be > useful for understanding why this test must be > standalone. All of the above suggestions are good. Will update before the push. Thanks! > > test/java/lang/instrument/RedefineMethodInBacktraceTarget.java > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java > No commetns. > Thanks! Serguei > > Dan > > >> >> >> Summary: >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> The plan is also to backport the fix to 8u60. >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> >> > From vladimir.kozlov at oracle.com Thu Mar 19 18:44:47 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Mar 2015 11:44:47 -0700 Subject: [8u60] Request for approval: Backport of 8074869(S) In-Reply-To: <550B14F2.9040204@oracle.com> References: <550B14F2.9040204@oracle.com> Message-ID: <550B191F.6090601@oracle.com> Looks good. Thanks, vladimir On 3/19/15 11:26 AM, Zolt?n Maj? wrote: > Hi, > > > I would like to request the backport of the fix for JDK-8074869 to 8u60. > > Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8074869 > Original patch: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fa8456e26deb > > Unfortunately, the fix does not apply cleanly because aarch64 is not > available in 8u60. All other changes apply to the 8u60 tree. > > Webrev: http://cr.openjdk.java.net/~zmajo/8074869-8u/webrev.00/ > > Testing: All JPRT tests pass. > > Thank you and best regards, > > > Zoltan > From zoltan.majo at oracle.com Thu Mar 19 18:47:14 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 19 Mar 2015 19:47:14 +0100 Subject: [8u60] Request for approval: Backport of 8074869(S) In-Reply-To: <550B191F.6090601@oracle.com> References: <550B14F2.9040204@oracle.com> <550B191F.6090601@oracle.com> Message-ID: <550B19B2.10403@oracle.com> Thank you, Vladimir! Best regards, Zoltan On 03/19/2015 07:44 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > vladimir > > On 3/19/15 11:26 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> I would like to request the backport of the fix for JDK-8074869 to 8u60. >> >> Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8074869 >> Original patch: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fa8456e26deb >> >> Unfortunately, the fix does not apply cleanly because aarch64 is not >> available in 8u60. All other changes apply to the 8u60 tree. >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8074869-8u/webrev.00/ >> >> Testing: All JPRT tests pass. >> >> Thank you and best regards, >> >> >> Zoltan >> From max.ockner at oracle.com Thu Mar 19 19:03:52 2015 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 19 Mar 2015 15:03:52 -0400 Subject: RFR: 8072128: Fixed missing "++" in _mutex_array[] initialization. In-Reply-To: <5507B09C.2090501@oracle.com> References: <55070236.7050803@oracle.com> <5507B09C.2090501@oracle.com> Message-ID: <550B1D98.8040109@oracle.com> Thanks to Frederic Parain and David Holmes for reviewing this. I will commit it now. Max Ockner On 3/17/2015 12:42 AM, David Holmes wrote: > Reviewed! > > Thanks Max! > > David > > On 17/03/2015 2:17 AM, Max Ockner wrote: >> Hello, >> Please review this small fix. >> >> Bug ID: 8072128 >> Webrev: http://cr.openjdk.java.net/~mockner/8072128/ >> Summary: The fix for bug 8047290 introduced a bug in mutexLocker.cpp in >> which the index into _mutex_array[] never increments. The bug did not >> cause any test failures, and was caught upon inspection of an hs_err >> file which claimed that no locks were owned. The solution was to >> restore the original code which increments the index. >> >> Tests: jtreg runtime/Safepoint and runtime/RedefineTests. >> To make sure the desired functionality was restored, the change was >> manually tested by crashing the vm during VM_RedefineClasses::doit() >> when we know that some locks are owned, and inspecting the hs_err file. >> This is difficult to write a test for, so it was only done manually. >> >> Thanks, >> Max From Alan.Bateman at oracle.com Thu Mar 19 20:43:55 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Mar 2015 20:43:55 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550AFF16.9080600@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> Message-ID: <550B350B.6040602@oracle.com> On 19/03/2015 16:53, Vladimir Kozlov wrote: > New code did not change API of existing X-Buffer methods. It changed > only how they are implementation. And already existing nio/Buffer > tests should test these methods already. Okay, although I've made a note to check the test coverage to see that the existing tests cover all cases. I have no objection to this going into the compiler tree of course, just wondering whether the existing buffer tests are enough. -Alan From erik.helin at oracle.com Fri Mar 20 09:02:52 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 20 Mar 2015 10:02:52 +0100 Subject: Result: New hotspot Group Member: Igor Ignatyev Message-ID: <20150320090252.GK20878@ehelin.jrpg.bea.com> The vote for Igor Ignatyev [1] is now closed. Yes: 12 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Erik Helin [1]: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017350.html From Alan.Bateman at oracle.com Fri Mar 20 13:20:17 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Mar 2015 13:20:17 +0000 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: References: Message-ID: <550C1E91.2070107@oracle.com> On 20/03/2015 12:16, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the fix below. > > CR: https://bugs.openjdk.java.net/browse/JDK-8075586 > webrev: http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ > > The fix adds @modules keyword to the existing hotspot tests, as needed, so that the tests can access the required API when the new modular architecture is in place. > > Best regards, > Alex Thanks Alex. Moving this thread from serviceability-dev to hotspot-dev as this patch covers all areas. Just to put more context on this patch and similar patches that will be proposed for tests in other repos. The new @modules tag can be used for test selection (e.g. no point running a test that make use of types in module java.management if the runtime under test does not have the management module), and additionally to declare a dependency on JDK-internal APIs. If my test uses sun.misc.Unsafe for example then the runtime under test needs to export that API for the test to compile and run. Clearly the latter requires the module system in JDK 9 so consider this part as just preparing the tests for when that day comes. One other thing to say to say is that Alex has tooling to examine the test tree and create or change the @modules tag as needed. The intention is that this should run periodically to refresh the @modules tags. In this period before the module system then we can't expect everyone that is adding or changing tests to have internalized the module graph [1] and furthermore know which APIs are exported or not. In other words, the intention is not to needlessly burden anyone that adds or changes tests. Clearly making use of a new jtreg tag means everyone with a local copy of jtreg should grab a recent build. Finally, I hope in time that the TEST.groups files can be cleaned up to remove the needs_* groups, this is important for the group definitions in the jdk repo mostly (but there are some in the hotspot TEST.groups too). -Alan [1] http://openjdk.java.net/jeps/200 From aph at redhat.com Fri Mar 20 16:08:47 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Mar 2015 16:08:47 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550B350B.6040602@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> Message-ID: <550C460F.1090302@redhat.com> Webrev at http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ I've moved the test case into the hotspot repo The test case is diagnostic, not experimental Andrew. From vladimir.kozlov at oracle.com Fri Mar 20 22:00:58 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 Mar 2015 15:00:58 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550C460F.1090302@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> Message-ID: <550C989A.5010203@oracle.com> On 3/20/15 9:08 AM, Andrew Haley wrote: > Webrev at > > http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code. In globals.hpp the empty line after flag description should not have '\' at the end. Otherwise it looks good. > http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ My only comment for jdk change is to use bigEndian name instead of BE in Unsafe.java. Someone from core libs should look on this. > > I've moved the test case into the hotspot repo > The test case is diagnostic, not experimental Good. Thanks, Vladimir > > Andrew. > From john.r.rose at oracle.com Sat Mar 21 05:21:20 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 20 Mar 2015 22:21:20 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550C989A.5010203@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> Message-ID: I'm glad to see this coming along? The code, javadoc, and spec all look good. On Mar 20, 2015, at 3:00 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ > > My only comment for jdk change is to use bigEndian name instead of BE in Unsafe.java. Someone from core libs should look on this. Here's my take on that bit (subject of course to correction from a core-libs eng.). BE (though short), as an upper-case acronym, is more correct than mixed-case bigEndian, according to the conventions suggested by JLS 6.1: > Constant Names > > The names of constants in interface types should be, and final variables of class types may conventionally be, a sequence of one or more words, acronyms, or abbreviations, all uppercase, with components separated by underscore "_" characters. Constant names should be descriptive and not unnecessarily abbreviated. Conventionally they may be any appropriate part of speech. > > Examples of names for constants include MIN_VALUE, MAX_VALUE, MIN_RADIX, and MAX_RADIX of the class Character. So I think it's OK as-is, especially since it is a private name. ? John From aph at redhat.com Sat Mar 21 11:36:17 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 21 Mar 2015 11:36:17 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550C989A.5010203@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> Message-ID: <550D57B1.602@redhat.com> On 20/03/15 22:00, Vladimir Kozlov wrote: > On 3/20/15 9:08 AM, Andrew Haley wrote: >> Webrev at >> >> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ > > I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider > it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code. Darn, I already made that change once but missed it in this webrev. Sorry. > In globals.hpp the empty line after flag description should not have '\' > at the end. OK. > Otherwise it looks good. > >> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ > > My only comment for jdk change is to use bigEndian name instead of BE in > Unsafe.java. Someone from core libs should look on this. I would have used that, but I followed John Rose's suggestion. I don't mind making changes but having to change it back-and-forth really is too much. >> I've moved the test case into the hotspot repo >> The test case is diagnostic, not experimental Yes, is is. I was told to do that. Andrew. From vladimir.kozlov at oracle.com Sat Mar 21 16:25:25 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 21 Mar 2015 09:25:25 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> Message-ID: <550D9B75.3000506@oracle.com> If you say so, John, I am okay with BE. Vladimir On 3/20/15 10:21 PM, John Rose wrote: > I'm glad to see this coming along? The code, javadoc, and spec all look good. > > On Mar 20, 2015, at 3:00 PM, Vladimir Kozlov > wrote: >> >>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ >> >> My only comment for jdk change is to use bigEndian name instead of BE in Unsafe.java. Someone from core libs should >> look on this. > > Here's my take on that bit (subject of course to correction from a core-libs eng.). > > BE (though short), as an upper-case acronym, is more correct than mixed-case bigEndian, according to the conventions > suggested by JLS 6.1: > >> Constant Names >> >> The names of constants in interface types should be, and final variables of class types may conventionally be, a >> sequence of one or more words, acronyms, or abbreviations, all uppercase, with components separated by underscore "_" >> characters. Constant names should be descriptive and not unnecessarily abbreviated. Conventionally they may be >> any appropriate part of speech. >> >> Examples of names for constants include MIN_VALUE, MAX_VALUE, MIN_RADIX, and MAX_RADIX of the class Character. > > So I think it's OK as-is, especially since it is a private name. > > ? John From vladimir.kozlov at oracle.com Sat Mar 21 16:32:02 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 21 Mar 2015 09:32:02 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550D57B1.602@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> Message-ID: <550D9D02.1020303@oracle.com> On 3/21/15 4:36 AM, Andrew Haley wrote: > On 20/03/15 22:00, Vladimir Kozlov wrote: >> On 3/20/15 9:08 AM, Andrew Haley wrote: >>> Webrev at >>> >>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ >> >> I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider >> it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code. > > Darn, I already made that change once but missed it in this webrev. Sorry. I will wait new webrev. > >> In globals.hpp the empty line after flag description should not have '\' >> at the end. > > OK. > >> Otherwise it looks good. >> >>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ >> >> My only comment for jdk change is to use bigEndian name instead of BE in >> Unsafe.java. Someone from core libs should look on this. > > I would have used that, but I followed John Rose's suggestion. I > don't mind making changes but having to change it back-and-forth > really is too much. John have more authority than me :) so be it BE. > >>> I've moved the test case into the hotspot repo >>> The test case is diagnostic, not experimental > > Yes, is is. I was told to do that. I am fine with diagnostic type of flag. The sponsor from Oracle have to set the flag in our closed sources similar to open vm_verstion_* changes - but it is small change. Thanks, Vladimir > > Andrew. > From erik.gahlin at oracle.com Sat Mar 21 18:56:01 2015 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Sat, 21 Mar 2015 19:56:01 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <550A9DFB.1070204@oracle.com> References: <550A9DFB.1070204@oracle.com> Message-ID: <550DBEC1.3030002@oracle.com> Looks good! Erik Jaroslav Bachorik skrev 2015-03-19 10:59: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 > Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 > > This patch is about adding 2 new diagnostic commands - VM.set_flag and > JVMTI.data_dump. > > VM.set_flag allows to set any writeable flag. It takes the flag name > and the flag value in textual form. The mutability of the flag and the > value format checks are forwarded to the shared vm management code. > > JVMTI.data_dump will send the data dump request to JVMTI. > > Both of these commands are covered by the corresponding tests. > > Thanks, > > -JB- From staffan.larsen at oracle.com Mon Mar 23 07:50:27 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Mar 2015 08:50:27 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <550A9DFB.1070204@oracle.com> References: <550A9DFB.1070204@oracle.com> Message-ID: <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> diagnosticCommand.cpp: - Should SetVMFlagDCmd really be inside "#if INCLUDE_SERVICES? ? - L227-234: strange indentation /Staffan > On 19 mar 2015, at 10:59, Jaroslav Bachorik wrote: > > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 > Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 > > This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. > > VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. > > JVMTI.data_dump will send the data dump request to JVMTI. > > Both of these commands are covered by the corresponding tests. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Mar 23 10:55:03 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 23 Mar 2015 11:55:03 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> References: <550A9DFB.1070204@oracle.com> <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> Message-ID: <550FF107.5030504@oracle.com> On 23.3.2015 08:50, Staffan Larsen wrote: > diagnosticCommand.cpp: > - Should SetVMFlagDCmd really be inside "#if INCLUDE_SERVICES? ? Probably not. On the other hand, the JVMTIDataDumpDCmd registration should probably be guarded by #if INCLUDE_JVMTI > - L227-234: strange indentation Fixed. Updated webrev (+ removing the extraneous #include "services/attachListener.hpp" in diagnosticCommand.hpp) : http://cr.openjdk.java.net/~jbachorik/8054890/webrev.01 -JB- > > > /Staffan > > >> On 19 mar 2015, at 10:59, Jaroslav Bachorik wrote: >> >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 >> >> This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. >> >> VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. >> >> JVMTI.data_dump will send the data dump request to JVMTI. >> >> Both of these commands are covered by the corresponding tests. >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Mon Mar 23 11:41:34 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Mar 2015 12:41:34 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <550FF107.5030504@oracle.com> References: <550A9DFB.1070204@oracle.com> <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> <550FF107.5030504@oracle.com> Message-ID: <743A07B6-736B-43FE-8961-6F6FB218AF63@oracle.com> Looks good! Thanks, /Staffan > On 23 mar 2015, at 11:55, Jaroslav Bachorik wrote: > > On 23.3.2015 08:50, Staffan Larsen wrote: >> diagnosticCommand.cpp: >> - Should SetVMFlagDCmd really be inside "#if INCLUDE_SERVICES? ? > > Probably not. On the other hand, the JVMTIDataDumpDCmd registration should probably be guarded by #if INCLUDE_JVMTI > >> - L227-234: strange indentation > > Fixed. > > Updated webrev (+ removing the extraneous #include "services/attachListener.hpp" in diagnosticCommand.hpp) : http://cr.openjdk.java.net/~jbachorik/8054890/webrev.01 > > -JB- > > >> >> >> /Staffan >> >> >>> On 19 mar 2015, at 10:59, Jaroslav Bachorik wrote: >>> >>> Please, review the following change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 >>> >>> This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. >>> >>> VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. >>> >>> JVMTI.data_dump will send the data dump request to JVMTI. >>> >>> Both of these commands are covered by the corresponding tests. >>> >>> Thanks, >>> >>> -JB- >> > From erik.joelsson at oracle.com Mon Mar 23 13:36:49 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Mar 2015 14:36:49 +0100 Subject: RFR: JDK-8075725: Remove /jre subdir in hotspot dist dir Message-ID: <551016F1.1070809@oracle.com> Hello, In JDK 9, the /jre sub directory in the jdk image has been removed. We should also remove this in the hotspot dist output directory and the corresponding import logic in the jdk build. There are still references to /jre in hotspot.script and build.sh, but since I don't know how or if these files are used, I don't dare changing them. Bug: https://bugs.openjdk.java.net/browse/JDK-8075725 Webrev: http://cr.openjdk.java.net/~erikj/8075725/webrev.01/ /Erik From thomas.schatzl at oracle.com Mon Mar 23 15:06:27 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 23 Mar 2015 16:06:27 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <550AF4B9.9000602@oracle.com> References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> <5502DBF4.9040508@oracle.com> <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> <550AF4B9.9000602@oracle.com> Message-ID: <1427123187.3194.82.camel@oracle.com> Hi Jesper, On Thu, 2015-03-19 at 17:09 +0100, Jesper Wilhelmsson wrote: > Hi, > > The original change has been approved by both Kim and Thomas and is good to go. > > It was decided to include the fix for the log rotation bug discovered in this > review as well. A new webrev including this fix is available here: > > http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.03/ > > The only change compared to the previous webrev is the bugfix in > src/share/vm/utilities/ostream.hpp > the change in ostream.hpp looks good. Thomas From stefan.johansson at oracle.com Mon Mar 23 15:06:31 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 23 Mar 2015 16:06:31 +0100 Subject: RFR: 8075735: Missing include causes minimal build failure Message-ID: <55102BF7.7010604@oracle.com> Hi, Please review this small change to fix: https://bugs.openjdk.java.net/browse/JDK-8075735 Webrev: http://cr.openjdk.java.net/~sjohanss/8075735/hotspot.00/ Summary: Minimal1 currently does not build in the hs-gc repo. The cause is a missing include in thread.cpp, which is added by the proposed change. Testing: Verified that minimal1 builds and run after the change. Thanks, Stefan From joseph.provino at oracle.com Mon Mar 23 15:12:51 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Mon, 23 Mar 2015 11:12:51 -0400 Subject: RFR: 8075735: Missing include causes minimal build failure In-Reply-To: <55102BF7.7010604@oracle.com> References: <55102BF7.7010604@oracle.com> Message-ID: <55102D73.6010504@oracle.com> Looks good to me. joe On 3/23/2015 11:06 AM, Stefan Johansson wrote: > Hi, > > Please review this small change to fix: > https://bugs.openjdk.java.net/browse/JDK-8075735 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8075735/hotspot.00/ > > Summary: > Minimal1 currently does not build in the hs-gc repo. The cause is a > missing include in thread.cpp, which is added by the proposed change. > > Testing: > Verified that minimal1 builds and run after the change. > > Thanks, > Stefan From jesper.wilhelmsson at oracle.com Mon Mar 23 15:15:40 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 23 Mar 2015 16:15:40 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <1427123187.3194.82.camel@oracle.com> References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> <5502DBF4.9040508@oracle.com> <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> <550AF4B9.9000602@oracle.com> <1427123187.3194.82.camel@oracle.com> Message-ID: <55102E1C.8040209@oracle.com> Thanks Thomas! /Jesper Thomas Schatzl skrev den 23/3/15 16:06: > Hi Jesper, > > On Thu, 2015-03-19 at 17:09 +0100, Jesper Wilhelmsson wrote: >> Hi, >> >> The original change has been approved by both Kim and Thomas and is good to go. >> >> It was decided to include the fix for the log rotation bug discovered in this >> review as well. A new webrev including this fix is available here: >> >> http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.03/ >> >> The only change compared to the previous webrev is the bugfix in >> src/share/vm/utilities/ostream.hpp >> > > the change in ostream.hpp looks good. > > Thomas > > From kim.barrett at oracle.com Mon Mar 23 15:37:23 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 23 Mar 2015 11:37:23 -0400 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: <550AF4B9.9000602@oracle.com> References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> <5502DBF4.9040508@oracle.com> <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> <550AF4B9.9000602@oracle.com> Message-ID: On Mar 19, 2015, at 12:09 PM, Jesper Wilhelmsson wrote: > > Hi, > > The original change has been approved by both Kim and Thomas and is good to go. > > It was decided to include the fix for the log rotation bug discovered in this review as well. A new webrev including this fix is available here: > > http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.03/ > > The only change compared to the previous webrev is the bugfix in src/share/vm/utilities/ostream.hpp The change to ostream looks good. But then, I would probably think so? From tim.bell at oracle.com Mon Mar 23 15:49:05 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 23 Mar 2015 08:49:05 -0700 Subject: RFR: JDK-8075725: Remove /jre subdir in hotspot dist dir In-Reply-To: <551016F1.1070809@oracle.com> References: <551016F1.1070809@oracle.com> Message-ID: <551035F1.4040800@oracle.com> Erik: > In JDK 9, the /jre sub directory in the jdk image has been removed. We > should also remove this in the hotspot dist output directory and the > corresponding import logic in the jdk build. > > There are still references to /jre in hotspot.script and build.sh, but > since I don't know how or if these files are used, I don't dare > changing them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075725 > Webrev: http://cr.openjdk.java.net/~erikj/8075725/webrev.01/ Looks good to me, although I am not a 'R'eviewer in hotspot territory... Tim From jesper.wilhelmsson at oracle.com Mon Mar 23 16:05:13 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 23 Mar 2015 17:05:13 +0100 Subject: RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t In-Reply-To: References: <55004930.1030708@oracle.com> <3A2FB08D-1EAC-4E6C-9A3D-E4D8EB5F8EDA@oracle.com> <5502DBF4.9040508@oracle.com> <55BB5B8F-D6D6-4E64-AB6C-A63CD4D63337@oracle.com> <550AF4B9.9000602@oracle.com> Message-ID: <551039B9.5050009@oracle.com> Thanks Kim! Yes, I'd be surprised if you had objected to your own fix ;) /Jesper Kim Barrett skrev den 23/3/15 16:37: > On Mar 19, 2015, at 12:09 PM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> The original change has been approved by both Kim and Thomas and is good to go. >> >> It was decided to include the fix for the log rotation bug discovered in this review as well. A new webrev including this fix is available here: >> >> http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.03/ >> >> The only change compared to the previous webrev is the bugfix in src/share/vm/utilities/ostream.hpp > > The change to ostream looks good. But then, I would probably think so? > From aph at redhat.com Mon Mar 23 18:31:38 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 23 Mar 2015 18:31:38 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550D9D02.1020303@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> Message-ID: <55105C0A.8070305@redhat.com> On 03/21/2015 04:32 PM, Vladimir Kozlov wrote: > On 3/21/15 4:36 AM, Andrew Haley wrote: >> On 20/03/15 22:00, Vladimir Kozlov wrote: >>> On 3/20/15 9:08 AM, Andrew Haley wrote: >>>> Webrev at >>>> >>>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ >>> >>> I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider >>> it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code. >> >> Darn, I already made that change once but missed it in this webrev. Sorry. > > I will wait new webrev. > >> >>> In globals.hpp the empty line after flag description should not have '\' >>> at the end. >> >> OK. >> >>> Otherwise it looks good. >>> >>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ >>> >>> My only comment for jdk change is to use bigEndian name instead of BE in >>> Unsafe.java. Someone from core libs should look on this. >> >> I would have used that, but I followed John Rose's suggestion. I >> don't mind making changes but having to change it back-and-forth >> really is too much. > > John have more authority than me :) so be it BE. Ok. Sorry for being impatient. http://cr.openjdk.java.net/~aph/unaligned.hotspot.8/ http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ Andrew. From vladimir.kozlov at oracle.com Mon Mar 23 21:10:08 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 23 Mar 2015 14:10:08 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <55105C0A.8070305@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> Message-ID: <55108130.2010207@oracle.com> Hotspot make files changes? Otherwise looks fine. Vladimir On 3/23/15 11:31 AM, Andrew Haley wrote: > On 03/21/2015 04:32 PM, Vladimir Kozlov wrote: >> On 3/21/15 4:36 AM, Andrew Haley wrote: >>> On 20/03/15 22:00, Vladimir Kozlov wrote: >>>> On 3/20/15 9:08 AM, Andrew Haley wrote: >>>>> Webrev at >>>>> >>>>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ >>>> >>>> I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider >>>> it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code. >>> >>> Darn, I already made that change once but missed it in this webrev. Sorry. >> >> I will wait new webrev. >> >>> >>>> In globals.hpp the empty line after flag description should not have '\' >>>> at the end. >>> >>> OK. >>> >>>> Otherwise it looks good. >>>> >>>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ >>>> >>>> My only comment for jdk change is to use bigEndian name instead of BE in >>>> Unsafe.java. Someone from core libs should look on this. >>> >>> I would have used that, but I followed John Rose's suggestion. I >>> don't mind making changes but having to change it back-and-forth >>> really is too much. >> >> John have more authority than me :) so be it BE. > > Ok. Sorry for being impatient. > > http://cr.openjdk.java.net/~aph/unaligned.hotspot.8/ > http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ > > Andrew. > > From david.holmes at oracle.com Tue Mar 24 07:56:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Mar 2015 17:56:55 +1000 Subject: RFR: 8075735: Missing include causes minimal build failure In-Reply-To: <55102BF7.7010604@oracle.com> References: <55102BF7.7010604@oracle.com> Message-ID: <551118C7.5020601@oracle.com> On 24/03/2015 1:06 AM, Stefan Johansson wrote: > Hi, > > Please review this small change to fix: > https://bugs.openjdk.java.net/browse/JDK-8075735 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8075735/hotspot.00/ > > Summary: > Minimal1 currently does not build in the hs-gc repo. The cause is a > missing include in thread.cpp, which is added by the proposed change. Okay. Can you update the bug report with a link to whatever change caused the build to start failing please. It should not have gotten passed JPRT. Thanks, David > Testing: > Verified that minimal1 builds and run after the change. > > Thanks, > Stefan From aph at redhat.com Tue Mar 24 08:15:29 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Mar 2015 08:15:29 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <55108130.2010207@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> Message-ID: <55111D21.1020502@redhat.com> On 23/03/15 21:10, Vladimir Kozlov wrote: > Hotspot make files changes? There's no need: I think we came to the conclusion that we wouldn't define BIG_ENDIAN. Andrew. From stefan.karlsson at oracle.com Tue Mar 24 09:18:48 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 24 Mar 2015 10:18:48 +0100 Subject: RFR: 8075735: Missing include causes minimal build failure In-Reply-To: <55102BF7.7010604@oracle.com> References: <55102BF7.7010604@oracle.com> Message-ID: <55112BF8.4070500@oracle.com> On 2015-03-23 16:06, Stefan Johansson wrote: > Hi, > > Please review this small change to fix: > https://bugs.openjdk.java.net/browse/JDK-8075735 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8075735/hotspot.00/ Looks good. StefanK > > Summary: > Minimal1 currently does not build in the hs-gc repo. The cause is a > missing include in thread.cpp, which is added by the proposed change. > > Testing: > Verified that minimal1 builds and run after the change. > > Thanks, > Stefan From aaron.grunthal at infinite-source.de Tue Mar 24 09:23:44 2015 From: aaron.grunthal at infinite-source.de (Aaron Grunthal) Date: Tue, 24 Mar 2015 10:23:44 +0100 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <550330CE.3030607@redhat.com> References: <550330CE.3030607@redhat.com> Message-ID: <55112D20.1070200@infinite-source.de> A question from the user perspective, If these things need to be intrinsified, does that mean we cannot expect the compiler to recognize the following (and similar) patterns on any platform and optimize them? byte[i] = (byte)intvalue<<24 byte[i+1] = (byte)intvalue<<16 byte[i+2] = (byte)intvalue<<8 byte[i+3] = (byte)intvalue I.e. should we always wrap byte arrays in bytebuffers if we want multi-byte reads? Or is this only an issue under some limited circumstances? Same questions for reading instead of writing. - Aaron On 13.03.2015 19:47, Andrew Haley wrote: > I've tried to address all the points that have been made. > > I haven't changed the way the sub-words are read and written because > the code I'm seeing is fairly nearly optimal right now and anything > more complex runs the risk of tripping inlining limits, thus > pessimizing performance. We need a general solution which isn't > optimized for special cases but is decent on average and often very > good. I think it's close to the best compromise we're going to get. > > I have changed the javadoc as requested and I have fixed the code in > HeapByteBuffer so that it doesn't check the index twice for floating- > point put() and get() operations. > > I have added a jtreg test for HeapByteBuffer which tests it pretty > thoroughly. It also, as a consequence, tests the underlying Unsafe > methods. I wasn't sure what a separate test for the Unsafe methods > would achieve so I didn't write one. > > OK? > > http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/ > http://cr.openjdk.java.net/~aph/unaligned.jdk.6/ > > Andrew. > From stefan.johansson at oracle.com Tue Mar 24 10:52:54 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 24 Mar 2015 11:52:54 +0100 Subject: RFR: 8075735: Missing include causes minimal build failure In-Reply-To: <55112BF8.4070500@oracle.com> References: <55102BF7.7010604@oracle.com> <55112BF8.4070500@oracle.com> Message-ID: <55114206.1070704@oracle.com> Thanks for the reviews Joe, David and Stefan. I've updated the bug with info on when this was introduced. The reason it was not caught by JPRT is because it uses pre-compiled headers, and it probably hides the problem. In my local builds I disable pre-compiled headers and for minimal that shows the problem. Thanks, Stefan On 2015-03-24 10:18, Stefan Karlsson wrote: > On 2015-03-23 16:06, Stefan Johansson wrote: >> Hi, >> >> Please review this small change to fix: >> https://bugs.openjdk.java.net/browse/JDK-8075735 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8075735/hotspot.00/ > > Looks good. > > StefanK > >> >> Summary: >> Minimal1 currently does not build in the hs-gc repo. The cause is a >> missing include in thread.cpp, which is added by the proposed change. >> >> Testing: >> Verified that minimal1 builds and run after the change. >> >> Thanks, >> Stefan > From mikael.gerdin at oracle.com Tue Mar 24 11:09:14 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 24 Mar 2015 12:09:14 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: References: <550AD57C.1030708@oracle.com> Message-ID: <551145DA.4050208@oracle.com> Hi Volker, On 2015-03-19 15:26, Volker Simonis wrote: > Hi Mikael, > > the change looks good (and I think it is really reasonable to have > this warning). > I've also checked that our ancient gcc 4.1.2 already supports this option:) Thanks! Any more takers from HotSpot land? /Mikael > > Regards, > Volker > > > On Thu, Mar 19, 2015 at 2:56 PM, Mikael Gerdin wrote: >> Hi, >> >> I recently ran into a compiler warning which is enabled by default in >> Solaris Studio, since HotSpot builds with warnings-as-errors this failed the >> build only when I got to the Solaris build. >> To catch this issue earlier for me (and a lot of others who use Linux as >> their preferred development platform) I suggest that we enable the >> equivalent warning for GCC. >> >> The patch to implement the change is inined below: >> >> diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make >> --- a/make/linux/makefiles/gcc.make >> +++ b/make/linux/makefiles/gcc.make >> @@ -207,7 +207,7 @@ >> WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body >> endif >> >> -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function >> -Wunused-value -Wformat=2 -Wreturn-type >> +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function >> -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual >> >> ifeq ($(USE_CLANG),) >> # Since GCC 4.3, -Wconversion has changed its meanings to warn these >> implicit >> >> I've verified the change by building on all linux platforms through JPRT. >> >> /Mikael From yekaterina.kantserova at oracle.com Tue Mar 24 12:09:21 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 24 Mar 2015 13:09:21 +0100 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <3698f540-73e0-4cfa-b356-6fb5ccea5b6f@default> References: <3698f540-73e0-4cfa-b356-6fb5ccea5b6f@default> Message-ID: <551153F1.70409@oracle.com> Notifying hotspot-dev as well. // Katja On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: > Could the reviewers, please, have a look at the proposed changes below? > > In addition, we are going to make a change to the TEST.ROOT file as indicated by Staffan in the mail below. > > Do you think the changes (plus the one-line change to the TEST.ROOT) can be pushed into the jdk? > > Best regards, > Alex > > ----- Original Message ----- > From: staffan.larsen at oracle.com > To: alexander.kulyakhtin at oracle.com > Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com > Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests > > I haven?t looked at the changes in detail, but please change the requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. > > Thanks, > /Staffan > >> On 20 mar 2015, at 13:16, Alexander Kulyakhtin wrote: >> >> Hi, >> >> Could you, please, review the fix below. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >> webrev: http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >> >> The fix adds @modules keyword to the existing hotspot tests, as needed, so that the tests can access the required API when the new modular architecture is in place. >> >> Best regards, >> Alex From erik.helin at oracle.com Tue Mar 24 12:48:31 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 24 Mar 2015 13:48:31 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: <551145DA.4050208@oracle.com> References: <550AD57C.1030708@oracle.com> <551145DA.4050208@oracle.com> Message-ID: <20150324124831.GM20878@ehelin.jrpg.bea.com> On 2015-03-24, Mikael Gerdin wrote: > Hi Volker, > > On 2015-03-19 15:26, Volker Simonis wrote: > >Hi Mikael, > > > >the change looks good (and I think it is really reasonable to have > >this warning). > >I've also checked that our ancient gcc 4.1.2 already supports this option:) > > Thanks! > > Any more takers from HotSpot land? Looks good, Reviewed. Thanks, Erik > /Mikael > > > > >Regards, > >Volker > > > > > >On Thu, Mar 19, 2015 at 2:56 PM, Mikael Gerdin wrote: > >>Hi, > >> > >>I recently ran into a compiler warning which is enabled by default in > >>Solaris Studio, since HotSpot builds with warnings-as-errors this failed the > >>build only when I got to the Solaris build. > >>To catch this issue earlier for me (and a lot of others who use Linux as > >>their preferred development platform) I suggest that we enable the > >>equivalent warning for GCC. > >> > >>The patch to implement the change is inined below: > >> > >>diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make > >>--- a/make/linux/makefiles/gcc.make > >>+++ b/make/linux/makefiles/gcc.make > >>@@ -207,7 +207,7 @@ > >> WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body > >> endif > >> > >>-WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > >>-Wunused-value -Wformat=2 -Wreturn-type > >>+WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > >>-Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual > >> > >> ifeq ($(USE_CLANG),) > >> # Since GCC 4.3, -Wconversion has changed its meanings to warn these > >>implicit > >> > >>I've verified the change by building on all linux platforms through JPRT. > >> > >>/Mikael From lois.foltan at oracle.com Tue Mar 24 12:57:48 2015 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 24 Mar 2015 08:57:48 -0400 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <551153F1.70409@oracle.com> References: <3698f540-73e0-4cfa-b356-6fb5ccea5b6f@default> <551153F1.70409@oracle.com> Message-ID: <55115F4C.5040203@oracle.com> This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From magnus.ihse.bursie at oracle.com Tue Mar 24 13:14:54 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Mar 2015 14:14:54 +0100 Subject: RFR: JDK-8075725: Remove /jre subdir in hotspot dist dir In-Reply-To: <551016F1.1070809@oracle.com> References: <551016F1.1070809@oracle.com> Message-ID: <5511634E.9070703@oracle.com> On 2015-03-23 14:36, Erik Joelsson wrote: > Hello, > > In JDK 9, the /jre sub directory in the jdk image has been removed. We > should also remove this in the hotspot dist output directory and the > corresponding import logic in the jdk build. > > There are still references to /jre in hotspot.script and build.sh, but > since I don't know how or if these files are used, I don't dare > changing them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075725 > Webrev: http://cr.openjdk.java.net/~erikj/8075725/webrev.01/ As far as I can tell, it looks good. Was the reason you renamed EXPORT_JRE_BIN_DIR et al to EXPORT_BIN_DIR to get them to better match the new layout? That also triggered a lot of code changes that would not have been needed otherwise. As I interpret the fix, you only changed the actual path in a few places, and the rest of the changes was just variable renames. If anything, I'd be slightly inclined to think that the variable names, while somewhat misleading, could have stayed, to minimize the impact of the change. /Magnus From volker.simonis at gmail.com Tue Mar 24 13:29:12 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 24 Mar 2015 14:29:12 +0100 Subject: RFR: 8075735: Missing include causes minimal build failure In-Reply-To: <55114206.1070704@oracle.com> References: <55102BF7.7010604@oracle.com> <55112BF8.4070500@oracle.com> <55114206.1070704@oracle.com> Message-ID: When do we finally run NON-PCH builds in JPRT? That's long overdue. I think it will save us from a lot of problems llike this one at the minimal cost of some cpu-cycles. Regards, Volker On Tue, Mar 24, 2015 at 11:52 AM, Stefan Johansson wrote: > Thanks for the reviews Joe, David and Stefan. > > I've updated the bug with info on when this was introduced. The reason it > was not caught by JPRT is because it uses pre-compiled headers, and it > probably hides the problem. In my local builds I disable pre-compiled > headers and for minimal that shows the problem. > > Thanks, > Stefan > > > On 2015-03-24 10:18, Stefan Karlsson wrote: >> >> On 2015-03-23 16:06, Stefan Johansson wrote: >>> >>> Hi, >>> >>> Please review this small change to fix: >>> https://bugs.openjdk.java.net/browse/JDK-8075735 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8075735/hotspot.00/ >> >> >> Looks good. >> >> StefanK >> >>> >>> Summary: >>> Minimal1 currently does not build in the hs-gc repo. The cause is a >>> missing include in thread.cpp, which is added by the proposed change. >>> >>> Testing: >>> Verified that minimal1 builds and run after the change. >>> >>> Thanks, >>> Stefan >> >> > From max.ockner at oracle.com Tue Mar 24 14:56:28 2015 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 24 Mar 2015 10:56:28 -0400 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. Message-ID: <55117B1C.5080602@oracle.com> Hello, please review my clean up of the unused dl_mutex lock. Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 Webrev: http://cr.openjdk.java.net/~mockner/6983747/ Summary: Deleted all references to the dl_mutex lock which was no longer used. Tested with jtreg runtime tests. Thanks, Max Ockner From erik.joelsson at oracle.com Tue Mar 24 14:56:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Mar 2015 15:56:57 +0100 Subject: RFR: JDK-8075725: Remove /jre subdir in hotspot dist dir In-Reply-To: <5511634E.9070703@oracle.com> References: <551016F1.1070809@oracle.com> <5511634E.9070703@oracle.com> Message-ID: <55117B39.6010302@oracle.com> On 2015-03-24 14:14, Magnus Ihse Bursie wrote: > On 2015-03-23 14:36, Erik Joelsson wrote: >> Hello, >> >> In JDK 9, the /jre sub directory in the jdk image has been removed. >> We should also remove this in the hotspot dist output directory and >> the corresponding import logic in the jdk build. >> >> There are still references to /jre in hotspot.script and build.sh, >> but since I don't know how or if these files are used, I don't dare >> changing them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075725 >> Webrev: http://cr.openjdk.java.net/~erikj/8075725/webrev.01/ > > As far as I can tell, it looks good. > > Was the reason you renamed EXPORT_JRE_BIN_DIR et al to EXPORT_BIN_DIR > to get them to better match the new layout? That also triggered a lot > of code changes that would not have been needed otherwise. As I > interpret the fix, you only changed the actual path in a few places, > and the rest of the changes was just variable renames. If anything, > I'd be slightly inclined to think that the variable names, while > somewhat misleading, could have stayed, to minimize the impact of the > change. > The variable names could have stayed yes, but I figured them conceptually wrong in the new world without /jre and for that reason confusing for future readers of these files. /Erik From christian.tornqvist at oracle.com Tue Mar 24 15:07:21 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 24 Mar 2015 11:07:21 -0400 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <0ac9a75a-d1a7-4a07-95e9-36bb338419b4@default> References: <0ac9a75a-d1a7-4a07-95e9-36bb338419b4@default> Message-ID: <276701d06644$3b03abd0$b10b0370$@oracle.com> Hi Alex, I assume you've run all the tests and that they are still passing? The @module changes looks good. As Lois pointed out, you need to update the copyrights and this should be done as part of this change. Thanks, Christian -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Alexander Kulyakhtin Sent: Tuesday, March 24, 2015 10:05 AM To: lois.foltan at oracle.com Cc: hotspot-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; alexandre.iline at oracle.com Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Lois, Thank you very much for your findings. We are going to remove the blank comments as you have suggested. If possible, however, we would prefer to pursue the copyrights issue under a different CR as this is another and not strictly related bulk change, which, probably, can be best achieved by an unrelated, script. I believe, there already is a separate CR for updating the copyrights. However if there's no such CR we are going to create a new one. Do you think it could be possible to have a separate CR for the copyrights issue (and if necessary to submit a new one)? Best regards, Alex ----- Original Message ----- From: lois.foltan at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From dmitry.dmitriev at oracle.com Tue Mar 24 16:35:16 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Tue, 24 Mar 2015 19:35:16 +0300 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <55117B1C.5080602@oracle.com> References: <55117B1C.5080602@oracle.com> Message-ID: <55119244.6020309@oracle.com> Hi Max, Can you please tell me, you intentionally delete following comment from os_linux.cpp file: 4680 // else it defaults to CLOCK_REALTIME It seems that this comment should be leaved. What you think about that? I am not a reviewer. Thanks, Dmitry On 24.03.2015 17:56, Max Ockner wrote: > Hello, > please review my clean up of the unused dl_mutex lock. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 > Webrev: http://cr.openjdk.java.net/~mockner/6983747/ > Summary: Deleted all references to the dl_mutex lock which was no > longer used. > > Tested with jtreg runtime tests. > > > Thanks, > Max Ockner From max.ockner at oracle.com Tue Mar 24 17:01:52 2015 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 24 Mar 2015 13:01:52 -0400 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <55119244.6020309@oracle.com> References: <55117B1C.5080602@oracle.com> <55119244.6020309@oracle.com> Message-ID: <55119880.5040407@oracle.com> This was not intentional. I thought the comment was referring to the line containing dl_mutex, but it was not. I put the comment back in. New webrev: http://cr.openjdk.java.net/~mockner/6983747.2/ Thanks, Max On 3/24/2015 12:35 PM, Dmitry Dmitriev wrote: > Hi Max, > > Can you please tell me, you intentionally delete following comment > from os_linux.cpp file: > 4680 // else it defaults to CLOCK_REALTIME > > It seems that this comment should be leaved. What you think about that? > > I am not a reviewer. > > Thanks, > Dmitry > > On 24.03.2015 17:56, Max Ockner wrote: >> Hello, >> please review my clean up of the unused dl_mutex lock. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 >> Webrev: http://cr.openjdk.java.net/~mockner/6983747/ >> Summary: Deleted all references to the dl_mutex lock which was no >> longer used. >> >> Tested with jtreg runtime tests. >> >> >> Thanks, >> Max Ockner > From harold.seigel at oracle.com Tue Mar 24 17:13:42 2015 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 24 Mar 2015 13:13:42 -0400 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <55119880.5040407@oracle.com> References: <55117B1C.5080602@oracle.com> <55119244.6020309@oracle.com> <55119880.5040407@oracle.com> Message-ID: <55119B46.4090909@oracle.com> Hi Max, Should this comment be removed from both files? // Glibc-2.0 libdl is not MT safe. If you are building with any glibc, // chances are you might want to run the generated bits against glibc-2.0 // libdl.so, so always use locking for any version of glibc. Thanks, Harold On 3/24/2015 1:01 PM, Max Ockner wrote: > This was not intentional. I thought the comment was referring to the > line containing dl_mutex, but it was not. I put the comment back in. > New webrev: http://cr.openjdk.java.net/~mockner/6983747.2/ > Thanks, > Max > > On 3/24/2015 12:35 PM, Dmitry Dmitriev wrote: >> Hi Max, >> >> Can you please tell me, you intentionally delete following comment >> from os_linux.cpp file: >> 4680 // else it defaults to CLOCK_REALTIME >> >> It seems that this comment should be leaved. What you think about that? >> >> I am not a reviewer. >> >> Thanks, >> Dmitry >> >> On 24.03.2015 17:56, Max Ockner wrote: >>> Hello, >>> please review my clean up of the unused dl_mutex lock. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 >>> Webrev: http://cr.openjdk.java.net/~mockner/6983747/ >>> Summary: Deleted all references to the dl_mutex lock which was no >>> longer used. >>> >>> Tested with jtreg runtime tests. >>> >>> >>> Thanks, >>> Max Ockner >> > From max.ockner at oracle.com Tue Mar 24 17:32:03 2015 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 24 Mar 2015 13:32:03 -0400 Subject: RFR: 8074718: Merged templateTable_x86 header files for 32/64 bits. Message-ID: <55119F93.9000007@oracle.com> Hello all, Please review this small change. Bug: https://bugs.openjdk.java.net/browse/JDK-8074718 Webrev: http://cr.openjdk.java.net/~mockner/8074718/src/share/vm/interpreter/templateTable.hpp.cdiff.html Summary: The templateTable_x86 hpp files for 32 and 64 bits have been merged. Just a couple of notes: (1) I would prefer to combine the two conditions which include templateTable_x86.hpp if possible, but I'm not comfortable fiddling with the TARGET_ARCH_MODEL labels. I was hoping to use TARGET_ARCH_MODEL_x86 to encompass both TARGET_ARCH_MODEL_x86_64 and TARGET_ARCH_MODEL_x86_32, but I don't think it exists. Any suggestions? (2) templateTable_x86.hpp is the updated file that will be kept. templateTable_x86_32.hpp and templateTable_x86_64.hpp are copies of templateTable_x86.hpp, and still exist for reviewing purposes. They will be removed before this is committed. Tested with jtreg runtime tests. Thanks, Max From aph at redhat.com Tue Mar 24 17:35:22 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Mar 2015 17:35:22 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <55112D20.1070200@infinite-source.de> References: <550330CE.3030607@redhat.com> <55112D20.1070200@infinite-source.de> Message-ID: <5511A05A.7060900@redhat.com> On 24/03/15 09:23, Aaron Grunthal wrote: > A question from the user perspective, > > If these things need to be intrinsified, does that mean we cannot expect > the compiler to recognize the following (and similar) patterns on any > platform and optimize them? > > byte[i] = (byte)intvalue<<24 > byte[i+1] = (byte)intvalue<<16 > byte[i+2] = (byte)intvalue<<8 > byte[i+3] = (byte)intvalue Not yet, no. > I.e. should we always wrap byte arrays in bytebuffers if we want > multi-byte reads? For the time being, yes. There have been some proposals to write Arrays methods to so this stuff, but right now array-backed ByteBuffers are the way to go. Or will be once this patch goes in. > Or is this only an issue under some limited circumstances? > > Same questions for reading instead of writing. Same answers. Andrew. From volker.simonis at gmail.com Tue Mar 24 17:36:01 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 24 Mar 2015 18:36:01 +0100 Subject: RFR(S): 8075858: AIX: clean-up HotSpot make files Message-ID: Hi, can somebody please review the following, AIX-only change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8075858 https://bugs.openjdk.java.net/browse/JDK-8075858 It's a simple clean-up of the AIX make files: - the compiler version detection can break on systems where bash only supports 32-bit integer compares - there was still a bogus gcc-version check in adlc.make - remove the -qipa options for inter-procedural link time optimizations because they slow down the build and we don't use them anyway. Thank you and best regards, Volker From alexander.kulyakhtin at oracle.com Tue Mar 24 14:04:52 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 24 Mar 2015 07:04:52 -0700 (PDT) Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Message-ID: <0ac9a75a-d1a7-4a07-95e9-36bb338419b4@default> Lois, Thank you very much for your findings. We are going to remove the blank comments as you have suggested. If possible, however, we would prefer to pursue the copyrights issue under a different CR as this is another and not strictly related bulk change, which, probably, can be best achieved by an unrelated, script. I believe, there already is a separate CR for updating the copyrights. However if there's no such CR we are going to create a new one. Do you think it could be possible to have a separate CR for the copyrights issue (and if necessary to submit a new one)? Best regards, Alex ----- Original Message ----- From: lois.foltan at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From alexander.kulyakhtin at oracle.com Tue Mar 24 15:26:29 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 24 Mar 2015 08:26:29 -0700 (PDT) Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Message-ID: <7bb82b4c-1a08-4fe0-a340-dc01f39cbf22@default> Hi Christian, Yes, I have run the tests and they do pass the same as before. According to your and Lois' comments I'm going to fix the copyrights and resubmit the webrev as soon as I'm done. Best regards, Alex ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com, lois.foltan at oracle.com Cc: hotspot-dev at openjdk.java.net, serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 6:07:27 PM GMT +04:00 Abu Dhabi / Muscat Subject: RE: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Hi Alex, I assume you've run all the tests and that they are still passing? The @module changes looks good. As Lois pointed out, you need to update the copyrights and this should be done as part of this change. Thanks, Christian -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Alexander Kulyakhtin Sent: Tuesday, March 24, 2015 10:05 AM To: lois.foltan at oracle.com Cc: hotspot-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; alexandre.iline at oracle.com Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Lois, Thank you very much for your findings. We are going to remove the blank comments as you have suggested. If possible, however, we would prefer to pursue the copyrights issue under a different CR as this is another and not strictly related bulk change, which, probably, can be best achieved by an unrelated, script. I believe, there already is a separate CR for updating the copyrights. However if there's no such CR we are going to create a new one. Do you think it could be possible to have a separate CR for the copyrights issue (and if necessary to submit a new one)? Best regards, Alex ----- Original Message ----- From: lois.foltan at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From vladimir.kozlov at oracle.com Tue Mar 24 18:04:03 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 Mar 2015 11:04:03 -0700 Subject: RFR(S): 8075858: AIX: clean-up HotSpot make files In-Reply-To: References: Message-ID: <5511A713.8050207@oracle.com> Looks fine to me. Thanks, Vladimir On 3/24/15 10:36 AM, Volker Simonis wrote: > Hi, > > can somebody please review the following, AIX-only change: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8075858 > https://bugs.openjdk.java.net/browse/JDK-8075858 > > It's a simple clean-up of the AIX make files: > > - the compiler version detection can break on systems where bash only > supports 32-bit integer compares > - there was still a bogus gcc-version check in adlc.make > - remove the -qipa options for inter-procedural link time > optimizations because they slow down the build and we don't use them > anyway. > > Thank you and best regards, > Volker > From vladimir.kozlov at oracle.com Tue Mar 24 18:07:10 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 Mar 2015 11:07:10 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <55111D21.1020502@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> <55111D21.1020502@redhat.com> Message-ID: <5511A7CE.30006@oracle.com> Got it. I missed that you changed code in unsafe.cpp. Let me prepare closed changes and get it reviewed before we can push this. Thanks, Vladimir On 3/24/15 1:15 AM, Andrew Haley wrote: > On 23/03/15 21:10, Vladimir Kozlov wrote: >> Hotspot make files changes? > > There's no need: I think we came to the conclusion that we wouldn't > define BIG_ENDIAN. > > Andrew. > From coleen.phillimore at oracle.com Tue Mar 24 18:27:33 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 24 Mar 2015 14:27:33 -0400 Subject: RFR: 8074718: Merged templateTable_x86 header files for 32/64 bits. In-Reply-To: <55119F93.9000007@oracle.com> References: <55119F93.9000007@oracle.com> Message-ID: <5511AC95.7070800@oracle.com> On 3/24/15, 1:32 PM, Max Ockner wrote: > Hello all, > Please review this small change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074718 > Webrev: > http://cr.openjdk.java.net/~mockner/8074718/src/share/vm/interpreter/templateTable.hpp.cdiff.html > Summary: The templateTable_x86 hpp files for 32 and 64 bits have been > merged. Just a couple of notes: > > (1) I would prefer to combine the two conditions which include > templateTable_x86.hpp if possible, but I'm not comfortable fiddling > with the TARGET_ARCH_MODEL labels. > I was hoping to use TARGET_ARCH_MODEL_x86 to encompass both > TARGET_ARCH_MODEL_x86_64 and TARGET_ARCH_MODEL_x86_32, but I don't > think it exists. Any suggestions? I think this is fine. I don't think it's worth adding a TARGET_ARCH_MODEL_x86 for just this one case. > > (2) templateTable_x86.hpp is the updated file that will be kept. > templateTable_x86_32.hpp and templateTable_x86_64.hpp are copies of > templateTable_x86.hpp, and still exist for reviewing purposes. They > will be removed before this is committed. This looks good. Thank you for doing this! Coleen > > Tested with jtreg runtime tests. > > Thanks, > Max From dean.long at oracle.com Tue Mar 24 20:31:58 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 24 Mar 2015 13:31:58 -0700 Subject: RFR: 8074718: Merged templateTable_x86 header files for 32/64 bits. In-Reply-To: <55119F93.9000007@oracle.com> References: <55119F93.9000007@oracle.com> Message-ID: <5511C9BE.2070304@oracle.com> On 3/24/2015 10:32 AM, Max Ockner wrote: > Hello all, > Please review this small change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074718 > Webrev: > http://cr.openjdk.java.net/~mockner/8074718/src/share/vm/interpreter/templateTable.hpp.cdiff.html > Summary: The templateTable_x86 hpp files for 32 and 64 bits have been > merged. Just a couple of notes: > > (1) I would prefer to combine the two conditions which include > templateTable_x86.hpp if possible, but I'm not comfortable fiddling > with the TARGET_ARCH_MODEL labels. > I was hoping to use TARGET_ARCH_MODEL_x86 to encompass both > TARGET_ARCH_MODEL_x86_64 and TARGET_ARCH_MODEL_x86_32, but I don't > think it exists. Any suggestions? > You could use TARGET_ARCH_x86, but then it doesn't match all the platforms using TARGET_ARCH_MODEL. Or you could define TEMPLATETABLE_MD_HPP and not worry about TARGET macros at all. dl > (2) templateTable_x86.hpp is the updated file that will be kept. > templateTable_x86_32.hpp and templateTable_x86_64.hpp are copies of > templateTable_x86.hpp, and still exist for reviewing purposes. They > will be removed before this is committed. > > Tested with jtreg runtime tests. > > Thanks, > Max From vladimir.kozlov at oracle.com Tue Mar 24 23:40:26 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 Mar 2015 16:40:26 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <55111D21.1020502@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> <55111D21.1020502@redhat.com> Message-ID: <5511F5EA.6010102@oracle.com> Andrew, The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86: java.lang.RuntimeException at MyByteBuffer.ck(HeapByteBufferTest.java:201) at MyByteBuffer.getLong(HeapByteBufferTest.java:211) at HeapByteBufferTest.step(HeapByteBufferTest.java:311) at HeapByteBufferTest.run(HeapByteBufferTest.java:347) at HeapByteBufferTest.main(HeapByteBufferTest.java:362) Could be intrinsic in C1 does not work correctly? Please, look. Thanks, Vladimir On 3/24/15 1:15 AM, Andrew Haley wrote: > On 23/03/15 21:10, Vladimir Kozlov wrote: >> Hotspot make files changes? > > There's no need: I think we came to the conclusion that we wouldn't > define BIG_ENDIAN. > > Andrew. > From david.holmes at oracle.com Wed Mar 25 03:57:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Mar 2015 13:57:38 +1000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5511A7CE.30006@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> <55111D21.1020502@redhat.com> <5511A7CE.30006@oracle.com> Message-ID: <55123232.2090806@oracle.com> On 25/03/2015 4:07 AM, Vladimir Kozlov wrote: > Got it. I missed that you changed code in unsafe.cpp. > Let me prepare closed changes and get it reviewed before we can push this. Copyright notices need updating too. And the copyright dates on the test look like they have been copied from another file - given this is a new test. Thanks, David > > Thanks, > Vladimir > > On 3/24/15 1:15 AM, Andrew Haley wrote: >> On 23/03/15 21:10, Vladimir Kozlov wrote: >>> Hotspot make files changes? >> >> There's no need: I think we came to the conclusion that we wouldn't >> define BIG_ENDIAN. >> >> Andrew. >> From david.holmes at oracle.com Wed Mar 25 04:19:56 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Mar 2015 14:19:56 +1000 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <55119B46.4090909@oracle.com> References: <55117B1C.5080602@oracle.com> <55119244.6020309@oracle.com> <55119880.5040407@oracle.com> <55119B46.4090909@oracle.com> Message-ID: <5512376C.9050509@oracle.com> On 25/03/2015 3:13 AM, harold seigel wrote: > Hi Max, > > Should this comment be removed from both files? > > // Glibc-2.0 libdl is not MT safe. If you are building with any glibc, > // chances are you might want to run the generated bits against > glibc-2.0 > // libdl.so, so always use locking for any version of glibc. Yes that should also be deleted - it was part of the incorrect copy done by 6721093. And as per 6626677 glibc was fixed at version 2.1 back in 1997. Since this was all investigated we had the AIX code added, so we need to get one of the AIX folk to confirm that no locking is needed around dlsym on that platform. (I would be very surprised if it were needed :) ) Thanks, David > Thanks, Harold > > On 3/24/2015 1:01 PM, Max Ockner wrote: >> This was not intentional. I thought the comment was referring to the >> line containing dl_mutex, but it was not. I put the comment back in. >> New webrev: http://cr.openjdk.java.net/~mockner/6983747.2/ >> Thanks, >> Max >> >> On 3/24/2015 12:35 PM, Dmitry Dmitriev wrote: >>> Hi Max, >>> >>> Can you please tell me, you intentionally delete following comment >>> from os_linux.cpp file: >>> 4680 // else it defaults to CLOCK_REALTIME >>> >>> It seems that this comment should be leaved. What you think about that? >>> >>> I am not a reviewer. >>> >>> Thanks, >>> Dmitry >>> >>> On 24.03.2015 17:56, Max Ockner wrote: >>>> Hello, >>>> please review my clean up of the unused dl_mutex lock. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 >>>> Webrev: http://cr.openjdk.java.net/~mockner/6983747/ >>>> Summary: Deleted all references to the dl_mutex lock which was no >>>> longer used. >>>> >>>> Tested with jtreg runtime tests. >>>> >>>> >>>> Thanks, >>>> Max Ockner >>> >> > From goetz.lindenmaier at sap.com Wed Mar 25 08:22:40 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 25 Mar 2015 08:22:40 +0000 Subject: RFR(L): 8075506: aix: improve handling of native memory Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB69B7@DEWDFEMB12A.global.corp.sap> Hi, this change improves handling of native memory on aix. It adds support for 64K pages and allocation at requested addresses. This improves performance by a few percent. Please review this change. It is aix-only. http://cr.openjdk.java.net/~goetz/webrevs/8075506-aixMem/webrev.00/ Best regards, Goetz. From aph at redhat.com Wed Mar 25 09:13:25 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Mar 2015 09:13:25 +0000 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <5511F5EA.6010102@oracle.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> <55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com> Message-ID: <55127C35.8000108@redhat.com> On 24/03/15 23:40, Vladimir Kozlov wrote: > The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86: > > java.lang.RuntimeException > at MyByteBuffer.ck(HeapByteBufferTest.java:201) > at MyByteBuffer.getLong(HeapByteBufferTest.java:211) > at HeapByteBufferTest.step(HeapByteBufferTest.java:311) > at HeapByteBufferTest.run(HeapByteBufferTest.java:347) > at HeapByteBufferTest.main(HeapByteBufferTest.java:362) > > Could be intrinsic in C1 does not work correctly? Please, look. I certainly will. That is odd: there's no reason I can think of why this might happen, and I know that the test running on a server build runs C1 code for a while so it has been tested. I guess it must be a rare edge case. Still, I'm quite pleased that the test I wrote detected the failure. Do you know if this was running with +UseUnalignedAccesses? I'm not going to be able to analyse this for a few days. Expect a report (and hopefully a fix) next week. Thanks, Andrew. From edward.nevill at linaro.org Wed Mar 25 09:27:28 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 25 Mar 2015 09:27:28 +0000 Subject: RFR: 8075860: aarch64: jdk9/dev fails to build Message-ID: <1427275648.7353.8.camel@mylittlepony.linaroharston> Hi, The following webrev http://cr.openjdk.java.net/~enevill/8075860/webrev.00/ fixes issue https://bugs.openjdk.java.net/browse/JDK-8075860 aarch64 fails to build from jdk9/dev. It fails with an undefined symbol 'os::Linux::ucontext_set_pc' This was introduced in changset 7995:3eb61269f421 The change was not reflected in the aarch64 specific code. Could someone please review this change and if approved, push. Thanks, Ed. From edward.nevill at linaro.org Wed Mar 25 13:02:08 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 25 Mar 2015 13:02:08 +0000 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 Message-ID: <1427288528.7353.25.camel@mylittlepony.linaroharston> Hi, The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation. Recent testing on some micro benchmarks shows that this can have an adverse effect, both in terms of stack usage, and performance. The following webrev allows C2 to use the FP register. http://cr.openjdk.java.net/~enevill/8075930/webrev/ I have run JTreg hotspot and langtools before and after this change with the following results:- Before:- hotspot: passed: 539, failed: 186, error: 87 langtools: passed: 3193, error: 33 After:- hotspot: passed: 540, failed: 186: error: 86 langtools: passed: 3192, error: 34 Please review this change and if OK, push. Thanks, Ed. From zoltan.majo at oracle.com Wed Mar 25 13:28:55 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 25 Mar 2015 14:28:55 +0100 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1427288528.7353.25.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> Message-ID: <5512B817.3080802@oracle.com> Hi Ed, On 03/25/2015 02:02 PM, Edward Nevill wrote: > Hi, > > The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation. It seems to me that the C2 compiler currently saves the SP into FP on method handle invokes. This functionality is encoded by aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages of FrameMap::method_handle_invoke_SP_save_opr()). Stack walking relies on having the SP saved into FP for method handle invokes (e.g., in frame::adjust_unextended_sp()). Saving the SP into FP is not needed on some architectures (e.g., x86). I'm currently working on an enhancement that disables saving the SP into FP on x86 (see JDK-8068945). Maybe that could work for aarch64 as well. Does your change consider this aspect? Maybe running the tests in jdk/test/java/lang/invoke/ could trigger some failures that are caused by the FP not containing the SP of the caller of a method handle invocation. Thank you and best regards, Zoltan > > Recent testing on some micro benchmarks shows that this can have an adverse effect, both in terms of stack usage, and performance. > > The following webrev allows C2 to use the FP register. > > http://cr.openjdk.java.net/~enevill/8075930/webrev/ > > I have run JTreg hotspot and langtools before and after this change with the following results:- > > Before:- > > hotspot: passed: 539, failed: 186, error: 87 > langtools: passed: 3193, error: 33 > > After:- > > hotspot: passed: 540, failed: 186: error: 86 > langtools: passed: 3192, error: 34 > > Please review this change and if OK, push. > > Thanks, > Ed. > > From adinn at redhat.com Wed Mar 25 14:08:09 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 25 Mar 2015 14:08:09 +0000 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5512B817.3080802@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> Message-ID: <5512C149.2060708@redhat.com> On 25/03/15 13:28, Zolt?n Maj? wrote: > On 03/25/2015 02:02 PM, Edward Nevill wrote: >> The aarch64 C2 compiler makes no use of the FP register even though >> this register is saved on entry and restored on exit and is therefore >> always available for allocation. > > It seems to me that the C2 compiler currently saves the SP into FP on > method handle invokes. This functionality is encoded by > aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages > of FrameMap::method_handle_invoke_SP_save_opr()). Yes, that's correct. aarch64_enc_java_handle relies on having FP available to save SP. So, it looks like this fix will break that. > Stack walking relies on having the SP saved into FP for method handle > invokes (e.g., in frame::adjust_unextended_sp()). > > Saving the SP into FP is not needed on some architectures (e.g., x86). > I'm currently working on an enhancement that disables saving the SP into > FP on x86 (see JDK-8068945). Maybe that could work for aarch64 as well. I would certainly hope so. Can you please give the AArch64 devs a shout when you propose a fix so we can help provide/review whatever arch-specific changes are need for AArch64. regards, Andrew Dinn ----------- From zoltan.majo at oracle.com Wed Mar 25 14:27:09 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 25 Mar 2015 15:27:09 +0100 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5512C149.2060708@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <5512C149.2060708@redhat.com> Message-ID: <5512C5BD.8070203@oracle.com> Hi Andrew, On 03/25/2015 03:08 PM, Andrew Dinn wrote: > > I would certainly hope so. Can you please give the AArch64 devs a shout > when you propose a fix so we can help provide/review whatever > arch-specific changes are need for AArch64. Thank you, Andrew. I plan to propose a fix later this week or early next week. The fix will target only x86_64 for now, but I expect that similar changes (at least in principle) have to be done on aarch64 as well. I'll let you know once my changes are out for review. Best regards, Zoltan > > regards, > > > Andrew Dinn > ----------- > From edward.nevill at linaro.org Wed Mar 25 16:59:43 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 25 Mar 2015 16:59:43 +0000 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5512B817.3080802@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> Message-ID: <1427302783.14624.8.camel@mylittlepony.linaroharston> Hi Zolt?n, On Wed, 2015-03-25 at 14:28 +0100, Zolt?n Maj? wrote: > On 03/25/2015 02:02 PM, Edward Nevill wrote: > > The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation. > > It seems to me that the C2 compiler currently saves the SP into FP on > method handle invokes. This functionality is encoded by > aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages > of FrameMap::method_handle_invoke_SP_save_opr()). Thanks! I had not spotted this usage. If my understanding is correct, it does not need to be RFP in aarch64_enc_java_handle_call. It could be any callee saved register? On aarch64 r19..r28 are callee saved so we could use say r19 instead. C1 and C2 are caller save, so they will not have any valid data in r19 at the point of the call (this is the problem with using RFP, because RFP is not caller save). > > Stack walking relies on having the SP saved into FP for method handle > invokes (e.g., in frame::adjust_unextended_sp()). These would then need to be modified to recover the sp from r19. Would this work? All the best, Ed. From lois.foltan at oracle.com Wed Mar 25 17:00:35 2015 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 25 Mar 2015 13:00:35 -0400 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> References: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> Message-ID: <5512E9B3.6000509@oracle.com> On 3/25/2015 10:38 AM, Alexander Kulyakhtin wrote: > Hi > > Please, find the updated review for the bulk @modules change at the link below. > > We have fixed the copyrights and the files mentioned in the mail from Lois. > > http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html Thank you very much for adding the copyrights in this edit. I have reviewed and it all looks good. Just a minor comment: test/gc/arguments/TestUseCompressedOopsErgo.java test/serviceability/jvmti/GetObjectSizeOverflow.java Both of these tests need a comma between "2015 Oracle". I don't need to see another webrev for this. Thanks, Lois > > Best regards, > Alex > > > > ----- Original Message ----- > From: lois.foltan at oracle.com > To: yekaterina.kantserova at oracle.com > Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com > Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests > > > This looks good, thank you for making these changes! A couple of > comments that I don't feel need another webrev but should be fixed > before pushing. > > - copyrights on all the tests need to be updated > - the following tests have a blank comment line before the new > "@modules" line that could be removed > test/gc/metaspace/TestMetaspacePerfCounters.java > test/runtime/contended/Basic.java > test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java > test/compiler/cpuflags/RestoreMXCSR.java > test/compiler/debug/VerifyAdapterSharing.java > > Thanks, > Lois > > On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: >> Notifying hotspot-dev as well. >> >> // Katja >> >> >> >> On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >>> Could the reviewers, please, have a look at the proposed changes below? >>> >>> In addition, we are going to make a change to the TEST.ROOT file as >>> indicated by Staffan in the mail below. >>> >>> Do you think the changes (plus the one-line change to the TEST.ROOT) >>> can be pushed into the jdk? >>> >>> Best regards, >>> Alex >>> >>> ----- Original Message ----- >>> From: staffan.larsen at oracle.com >>> To: alexander.kulyakhtin at oracle.com >>> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >>> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>> hotspot tests >>> >>> I haven?t looked at the changes in detail, but please change the >>> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >>> >>> Thanks, >>> /Staffan >>> >>>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>>> wrote: >>>> >>>> Hi, >>>> >>>> Could you, please, review the fix below. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>>> webrev: >>>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>>> >>>> The fix adds @modules keyword to the existing hotspot tests, as >>>> needed, so that the tests can access the required API when the new >>>> modular architecture is in place. >>>> >>>> Best regards, >>>> Alex From vladimir.kozlov at oracle.com Wed Mar 25 17:34:10 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 Mar 2015 10:34:10 -0700 Subject: RFR: 8075860: aarch64: jdk9/dev fails to build In-Reply-To: <1427275648.7353.8.camel@mylittlepony.linaroharston> References: <1427275648.7353.8.camel@mylittlepony.linaroharston> Message-ID: <5512F192.9060401@oracle.com> Looks good. It is in JPRT queue for push. Thanks, Vladimir On 3/25/15 2:27 AM, Edward Nevill wrote: > Hi, > > The following webrev > > http://cr.openjdk.java.net/~enevill/8075860/webrev.00/ > > fixes issue > > https://bugs.openjdk.java.net/browse/JDK-8075860 > > aarch64 fails to build from jdk9/dev. > > It fails with an undefined symbol 'os::Linux::ucontext_set_pc' > > This was introduced in changset 7995:3eb61269f421 > > The change was not reflected in the aarch64 specific code. > > Could someone please review this change and if approved, push. > > Thanks, > Ed. > > From coleen.phillimore at oracle.com Wed Mar 25 17:53:04 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Mar 2015 13:53:04 -0400 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor Message-ID: <5512F600.9050102@oracle.com> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false for Zero Also, this fixes a couple other minor issues. Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests don't run because Zero doesn't support UseCompressedOops (not sure why) and CDS (know why). open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ bug link https://bugs.openjdk.java.net/browse/JDK-8075967 Thanks, Coleen From vladimir.kozlov at oracle.com Wed Mar 25 17:53:12 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 Mar 2015 10:53:12 -0700 Subject: RFR(L): 8075506: aix: improve handling of native memory In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB69B7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFB69B7@DEWDFEMB12A.global.corp.sap> Message-ID: <5512F608.6070709@oracle.com> Looks good. I only glanced through os_aix.cpp changes - they look fine from 'glance'. Could you explain a little about allocate_stack_guard_pages() returning false? The comment say that you are not using normal C stack. Is it true? Thanks, Vladimir On 3/25/15 1:22 AM, Lindenmaier, Goetz wrote: > Hi, > > this change improves handling of native memory on aix. It adds support for > 64K pages and allocation at requested addresses. This improves performance > by a few percent. > > Please review this change. It is aix-only. > http://cr.openjdk.java.net/~goetz/webrevs/8075506-aixMem/webrev.00/ > > Best regards, > Goetz. > From harold.seigel at oracle.com Wed Mar 25 18:22:17 2015 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 25 Mar 2015 14:22:17 -0400 Subject: RFR: 8074718: Merged templateTable_x86 header files for 32/64 bits. In-Reply-To: <55119F93.9000007@oracle.com> References: <55119F93.9000007@oracle.com> Message-ID: <5512FCD9.8000004@oracle.com> Hi Max, This looks good. Just one small comment about templateTable_x86.hpp. (No need for a new webrev) Could you combine this: 346 #elif defined TARGET_ARCH_MODEL_x86_32 347 # include "templateTable_x86.hpp" 348 #elif defined TARGET_ARCH_MODEL_x86_64 349 # include "templateTable_x86.hpp" 350 #elif defined TARGET_ARCH_MODEL_sparc Into: 346 #elif defined(TARGET_ARCH_MODEL_x86_32) || defined(TARGET_ARCH_MODEL_x86_64) 347 # include "templateTable_x86.hpp" 350 #elif defined TARGET_ARCH_MODEL_sparc Thanks, Harold On 3/24/2015 1:32 PM, Max Ockner wrote: > Hello all, > Please review this small change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074718 > Webrev: > http://cr.openjdk.java.net/~mockner/8074718/src/share/vm/interpreter/templateTable.hpp.cdiff.html > Summary: The templateTable_x86 hpp files for 32 and 64 bits have been > merged. Just a couple of notes: > > (1) I would prefer to combine the two conditions which include > templateTable_x86.hpp if possible, but I'm not comfortable fiddling > with the TARGET_ARCH_MODEL labels. > I was hoping to use TARGET_ARCH_MODEL_x86 to encompass both > TARGET_ARCH_MODEL_x86_64 and TARGET_ARCH_MODEL_x86_32, but I don't > think it exists. Any suggestions? > > (2) templateTable_x86.hpp is the updated file that will be kept. > templateTable_x86_32.hpp and templateTable_x86_64.hpp are copies of > templateTable_x86.hpp, and still exist for reviewing purposes. They > will be removed before this is committed. > > Tested with jtreg runtime tests. > > Thanks, > Max From sgehwolf at redhat.com Wed Mar 25 18:29:32 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 25 Mar 2015 19:29:32 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <5512F600.9050102@oracle.com> References: <5512F600.9050102@oracle.com> Message-ID: <1427308172.3470.82.camel@redhat.com> Hi Coleen, Thanks for this! On Wed, 2015-03-25 at 13:53 -0400, Coleen Phillimore wrote: > Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false > for Zero > > Also, this fixes a couple other minor issues. > > Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests don't > run because Zero doesn't support UseCompressedOops (not sure why) and > CDS (know why). > > open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ > bug link https://bugs.openjdk.java.net/browse/JDK-8075967 Disclaimer: Not a reviewer. While I'd have preferred correct (safe) SafeFetchX implementations (or remove them for Zero) I don't see how we could do this for Zero in an arch-independent way. AFAIK, getting/setting the PC via ucontext is machine dependent and Zero may be running on any linux architecture where GCC is available. Changes look fine to me. Cheers, Severin > Thanks, > Coleen From vladimir.kozlov at oracle.com Wed Mar 25 18:43:10 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 Mar 2015 11:43:10 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <55127C35.8000108@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> <55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com> <55127C35.8000108@redhat.com> Message-ID: <551301BE.2000307@oracle.com> Looks like only 32-bit is affected. Both Server (C2) and Client (C1) VMs. 64-bit VM pass all combinations: Tiered, C2 only (-TieredCompilation), C1 only (-XX:+TieredCompilation -XX:TieredStopAtLevel=1) with and without intrinsics. 32-bit Client VM (C1) fails with both, -XX:-UseUnalignedAccesses and -XX:+UseUnalignedAccesses. $ bin/java -client -XX:+UnlockDiagnosticVMOptions -XX:-UseUnalignedAccesses HeapByteBufferTest Exception in thread "main" java.lang.RuntimeException at MyByteBuffer.ck(HeapByteBufferTest.java:201) at MyByteBuffer.getLong(HeapByteBufferTest.java:211) at HeapByteBufferTest.step(HeapByteBufferTest.java:311) at HeapByteBufferTest.run(HeapByteBufferTest.java:347) at HeapByteBufferTest.main(HeapByteBufferTest.java:362) $ bin/java -client -XX:+UnlockDiagnosticVMOptions -XX:+UseUnalignedAccesses HeapByteBufferTest Exception in thread "main" java.lang.RuntimeException at MyByteBuffer.ck(HeapByteBufferTest.java:201) at MyByteBuffer.getLong(HeapByteBufferTest.java:211) at HeapByteBufferTest.step(HeapByteBufferTest.java:311) at HeapByteBufferTest.run(HeapByteBufferTest.java:347) at HeapByteBufferTest.main(HeapByteBufferTest.java:362) 32-bit Server VM without tiered (-TieredCompilation) FAILS too in both cases! Note, without intrinsics it failed in different place. $ bin/java -server -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:-UseUnalignedAccesses HeapByteBufferTest Exception in thread "main" java.lang.RuntimeException at MyByteBuffer.ck(HeapByteBufferTest.java:207) at MyByteBuffer.getDouble(HeapByteBufferTest.java:215) at HeapByteBufferTest.step(HeapByteBufferTest.java:329) at HeapByteBufferTest.run(HeapByteBufferTest.java:347) at HeapByteBufferTest.main(HeapByteBufferTest.java:362) $ bin/java -server -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+UseUnalignedAccesses HeapByteBufferTest Exception in thread "main" java.lang.RuntimeException at MyByteBuffer.ck(HeapByteBufferTest.java:201) at MyByteBuffer.getLong(HeapByteBufferTest.java:211) at HeapByteBufferTest.step(HeapByteBufferTest.java:311) at HeapByteBufferTest.run(HeapByteBufferTest.java:347) at HeapByteBufferTest.main(HeapByteBufferTest.java:362) For some reasons Server VM only pass when TieredCompilation is enabled. Looking on -XX:+PrintCompilation -XX:+PrintInlining output I see that UseUnalignedAccesses affects intrinsics as designed. Thanks, Vladimir On 3/25/15 2:13 AM, Andrew Haley wrote: > On 24/03/15 23:40, Vladimir Kozlov wrote: > >> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86: >> >> java.lang.RuntimeException >> at MyByteBuffer.ck(HeapByteBufferTest.java:201) >> at MyByteBuffer.getLong(HeapByteBufferTest.java:211) >> at HeapByteBufferTest.step(HeapByteBufferTest.java:311) >> at HeapByteBufferTest.run(HeapByteBufferTest.java:347) >> at HeapByteBufferTest.main(HeapByteBufferTest.java:362) >> >> Could be intrinsic in C1 does not work correctly? Please, look. > > I certainly will. That is odd: there's no reason I can think of why > this might happen, and I know that the test running on a server build > runs C1 code for a while so it has been tested. I guess it must be a > rare edge case. Still, I'm quite pleased that the test I wrote > detected the failure. > > Do you know if this was running with +UseUnalignedAccesses? > > I'm not going to be able to analyse this for a few days. Expect a > report (and hopefully a fix) next week. > > Thanks, > Andrew. > From jesper.wilhelmsson at oracle.com Wed Mar 25 19:10:26 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 Mar 2015 20:10:26 +0100 Subject: RFR(s): 8076012 - SA don't support flags of type size_t Message-ID: <55130822.4050702@oracle.com> Hi, Please review this fix for the serviceability agent to support flags of type size_t. Bug: https://bugs.openjdk.java.net/browse/JDK-8076012 Webrev: http://cr.openjdk.java.net/~jwilhelm/8076012/webrev.00/ This bug is currently blocking the GC repository from being synced with main after the change to make a bunch of flags size_t. The reason it wasn't found when doing that change was that the tests that now failed in our nightly testing needs privileged access to be able to attach to the test process. If it doesn't have the needed privileges the tests simply exits and reports a success. Local testing therefor did not see this as a failure. Why the tests aren't run in JPRT I don't know. I thought they were. (Or maybe they are but without the proper privileges.) Thanks! /Jesper From staffan.larsen at oracle.com Wed Mar 25 19:30:41 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 25 Mar 2015 20:30:41 +0100 Subject: RFR(s): 8076012 - SA don't support flags of type size_t In-Reply-To: <55130822.4050702@oracle.com> References: <55130822.4050702@oracle.com> Message-ID: <08352E0A-4E1D-4750-9936-9D64220CA80A@oracle.com> Looks good! Thanks, /Staffan > On 25 mar 2015, at 20:10, Jesper Wilhelmsson wrote: > > Hi, > > Please review this fix for the serviceability agent to support flags of type size_t. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076012 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8076012/webrev.00/ > > This bug is currently blocking the GC repository from being synced with main after the change to make a bunch of flags size_t. > > The reason it wasn't found when doing that change was that the tests that now failed in our nightly testing needs privileged access to be able to attach to the test process. If it doesn't have the needed privileges the tests simply exits and reports a success. Local testing therefor did not see this as a failure. > Why the tests aren't run in JPRT I don't know. I thought they were. (Or maybe they are but without the proper privileges.) > > Thanks! > /Jesper From jesper.wilhelmsson at oracle.com Wed Mar 25 20:17:24 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 Mar 2015 21:17:24 +0100 Subject: RFR(s): 8076012 - SA don't support flags of type size_t In-Reply-To: <08352E0A-4E1D-4750-9936-9D64220CA80A@oracle.com> References: <55130822.4050702@oracle.com> <08352E0A-4E1D-4750-9936-9D64220CA80A@oracle.com> Message-ID: <551317D4.5090402@oracle.com> Thanks for the review! /Jesper Staffan Larsen skrev den 25/3/15 20:30: > Looks good! > > Thanks, > /Staffan > >> On 25 mar 2015, at 20:10, Jesper Wilhelmsson wrote: >> >> Hi, >> >> Please review this fix for the serviceability agent to support flags of type size_t. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076012 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8076012/webrev.00/ >> >> This bug is currently blocking the GC repository from being synced with main after the change to make a bunch of flags size_t. >> >> The reason it wasn't found when doing that change was that the tests that now failed in our nightly testing needs privileged access to be able to attach to the test process. If it doesn't have the needed privileges the tests simply exits and reports a success. Local testing therefor did not see this as a failure. >> Why the tests aren't run in JPRT I don't know. I thought they were. (Or maybe they are but without the proper privileges.) >> >> Thanks! >> /Jesper > From vladimir.kozlov at oracle.com Wed Mar 25 21:00:37 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 Mar 2015 14:00:37 -0700 Subject: [8u60] request for approval: "8067923: AIX: link libjvm.so with -bernotok..." and "8075858: AIX: clean-up HotSpot make files" In-Reply-To: References: Message-ID: <551321F5.7020800@oracle.com> Hi, Since it is only hotspot changes they will go through jdk8u/hs-dev/hotspot. Alejandro will merge them to 8u after testing. No need for separate approval from jdk8u. Next time, please, ask for Hotspot changes backport on hotspot-dev mailing list. I'm sponsoring backport - it is in JPRT queue. Thanks, Vladimir On 3/25/15 10:48 AM, Volker Simonis wrote: > Hi, > > could you please approve and sponsor the backport of the following > two, AIX-only HotSpot fixes to jd8u-dev: > > 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols > at build time and suppress warning 1540-1639 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067923 > Webrev: http://cr.openjdk.java.net/~simonis/webrevs/8067923/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016568.html > URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c0f8994d6ee6 > > > 8075858: AIX: clean-up HotSpot make files > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075858 > Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2015/8075858/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017659.html > URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3891403eb18e > > Both changes cleanly apply to the current 8u-dev/hotspot repository > and only touch AIX-specific make files. > > Thank you and best regards, > Volker > From kim.barrett at oracle.com Wed Mar 25 21:25:14 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 25 Mar 2015 17:25:14 -0400 Subject: RFR(s): 8076012 - SA don't support flags of type size_t In-Reply-To: <55130822.4050702@oracle.com> References: <55130822.4050702@oracle.com> Message-ID: <5CB2AC96-1248-4ACE-8D78-3E4E9140F9FD@oracle.com> On Mar 25, 2015, at 3:10 PM, Jesper Wilhelmsson wrote: > > Hi, > > Please review this fix for the serviceability agent to support flags of type size_t. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076012 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8076012/webrev.00/ > > This bug is currently blocking the GC repository from being synced with main after the change to make a bunch of flags size_t. Looks good. ------------------------------------------------------------------------------ agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java Changing "a" to "an" 179 Assert.that(isIntx(), "not an intx flag!"); 190 Assert.that(isUIntx(), "not an uintx flag!"); Nit-picking: I think the first is correct, but not the second. And no, I don't need another webrev if you change this. ------------------------------------------------------------------------------ From jesper.wilhelmsson at oracle.com Wed Mar 25 21:28:20 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 Mar 2015 22:28:20 +0100 Subject: RFR(s): 8076012 - SA don't support flags of type size_t In-Reply-To: <5CB2AC96-1248-4ACE-8D78-3E4E9140F9FD@oracle.com> References: <55130822.4050702@oracle.com> <5CB2AC96-1248-4ACE-8D78-3E4E9140F9FD@oracle.com> Message-ID: <55132874.9090704@oracle.com> Thanks! I need to improve my grammar a bit I guess :) /Jesper Kim Barrett skrev den 25/3/15 22:25: > On Mar 25, 2015, at 3:10 PM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> Please review this fix for the serviceability agent to support flags of type size_t. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076012 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8076012/webrev.00/ >> >> This bug is currently blocking the GC repository from being synced with main after the change to make a bunch of flags size_t. > > > Looks good. > > ------------------------------------------------------------------------------ > agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > Changing "a" to "an" > 179 Assert.that(isIntx(), "not an intx flag!"); > 190 Assert.that(isUIntx(), "not an uintx flag!"); > > Nit-picking: I think the first is correct, but not the second. > > And no, I don't need another webrev if you change this. > > ------------------------------------------------------------------------------ > From sean.coffey at oracle.com Wed Mar 25 23:05:38 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 25 Mar 2015 23:05:38 +0000 Subject: [8u60] request for approval: "8067923: AIX: link libjvm.so with -bernotok..." and "8075858: AIX: clean-up HotSpot make files" In-Reply-To: <551321F5.7020800@oracle.com> References: <551321F5.7020800@oracle.com> Message-ID: <55133F42.8090100@oracle.com> Thanks Vladimir! regards, Sean. On 25/03/2015 21:00, Vladimir Kozlov wrote: > Hi, > > Since it is only hotspot changes they will go through > jdk8u/hs-dev/hotspot. Alejandro will merge them to 8u after testing. > No need for separate approval from jdk8u. > > Next time, please, ask for Hotspot changes backport on hotspot-dev > mailing list. > > I'm sponsoring backport - it is in JPRT queue. > > Thanks, > Vladimir > > On 3/25/15 10:48 AM, Volker Simonis wrote: >> Hi, >> >> could you please approve and sponsor the backport of the following >> two, AIX-only HotSpot fixes to jd8u-dev: >> >> 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols >> at build time and suppress warning 1540-1639 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067923 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/8067923/ >> Review: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016568.html >> URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c0f8994d6ee6 >> >> >> 8075858: AIX: clean-up HotSpot make files >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075858 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2015/8075858/ >> Review: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017659.html >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3891403eb18e >> >> Both changes cleanly apply to the current 8u-dev/hotspot repository >> and only touch AIX-specific make files. >> >> Thank you and best regards, >> Volker >> From mandy.chung at oracle.com Wed Mar 25 23:11:14 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 Mar 2015 16:11:14 -0700 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> References: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> Message-ID: <55134092.801@oracle.com> Alexandar, Shura, The dependency analysis is not up-to-date that sun.tools.jar has been moved to jdk.jartool module in jdk9 b55. It has been in jdk9/dev since 3/6. I have pointed out multiple times previously that jdk.dev/sun.tools.jar is wrong in the jdk side of change. Below includes an example. Mandy --- old/test/runtime/RedefineTests/RedefineAnnotations.java 2015-03-25 16:24:41.462038538 +0300 +++ new/test/runtime/RedefineTests/RedefineAnnotations.java 2015-03-25 16:24:41.386038539 +0300 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -25,6 +25,9 @@ * @test * @library /testlibrary * @summary Test that type annotations are retained after a retransform + * @modules java.base/jdk.internal.org.objectweb.asm + * java.instrument + * jdk.dev/sun.tools.jar * @run main RedefineAnnotations buildagent * @run main/othervm -javaagent:redefineagent.jar RedefineAnnotations */ On 3/25/15 7:38 AM, Alexander Kulyakhtin wrote: > Hi > > Please, find the updated review for the bulk @modules change at the link below. > > We have fixed the copyrights and the files mentioned in the mail from Lois. > > http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html > > Best regards, > Alex > > > > ----- Original Message ----- > From: lois.foltan at oracle.com > To: yekaterina.kantserova at oracle.com > Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com > Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests > > > This looks good, thank you for making these changes! A couple of > comments that I don't feel need another webrev but should be fixed > before pushing. > > - copyrights on all the tests need to be updated > - the following tests have a blank comment line before the new > "@modules" line that could be removed > test/gc/metaspace/TestMetaspacePerfCounters.java > test/runtime/contended/Basic.java > test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java > test/compiler/cpuflags/RestoreMXCSR.java > test/compiler/debug/VerifyAdapterSharing.java > > Thanks, > Lois > > On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: >> Notifying hotspot-dev as well. >> >> // Katja >> >> >> >> On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >>> Could the reviewers, please, have a look at the proposed changes below? >>> >>> In addition, we are going to make a change to the TEST.ROOT file as >>> indicated by Staffan in the mail below. >>> >>> Do you think the changes (plus the one-line change to the TEST.ROOT) >>> can be pushed into the jdk? >>> >>> Best regards, >>> Alex >>> >>> ----- Original Message ----- >>> From: staffan.larsen at oracle.com >>> To: alexander.kulyakhtin at oracle.com >>> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >>> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>> hotspot tests >>> >>> I haven?t looked at the changes in detail, but please change the >>> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >>> >>> Thanks, >>> /Staffan >>> >>>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>>> wrote: >>>> >>>> Hi, >>>> >>>> Could you, please, review the fix below. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>>> webrev: >>>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>>> >>>> The fix adds @modules keyword to the existing hotspot tests, as >>>> needed, so that the tests can access the required API when the new >>>> modular architecture is in place. >>>> >>>> Best regards, >>>> Alex From david.holmes at oracle.com Wed Mar 25 23:59:03 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 09:59:03 +1000 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <5512F600.9050102@oracle.com> References: <5512F600.9050102@oracle.com> Message-ID: <55134BC7.8070606@oracle.com> Hi Coleen, Why generate stubs that can't be used and then add zero-specific logic to the shared CanUseSafeFetchN instead of not generating the stubs so that CanUseSafeFetchN will return false anyway ?? Thanks, David On 26/03/2015 3:53 AM, Coleen Phillimore wrote: > Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false > for Zero > > Also, this fixes a couple other minor issues. > > Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests don't > run because Zero doesn't support UseCompressedOops (not sure why) and > CDS (know why). > > open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ > bug link https://bugs.openjdk.java.net/browse/JDK-8075967 > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Mar 26 00:04:01 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Mar 2015 20:04:01 -0400 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55134BC7.8070606@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> Message-ID: <55134CF1.2020909@oracle.com> On 3/25/15, 7:59 PM, David Holmes wrote: > Hi Coleen, > > Why generate stubs that can't be used and then add zero-specific logic > to the shared CanUseSafeFetchN instead of not generating the stubs so > that CanUseSafeFetchN will return false anyway ?? Because there is platform independent code in objectMonitor.cpp that uses SafeFetchX (both). I'd rather not burden the caller of this with testing CanUseSafeFetchX for each call. This code existed before SafeFetch was implemented, so I'm restoring previous behavior for Zero. We could file an RFE to either implement SafeFetch for Zero or rewrite this objectMonitor code to not need SafeFetch. I didn't want to do either of these things with this patch. Coleen > > Thanks, > David > > On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false >> for Zero >> >> Also, this fixes a couple other minor issues. >> >> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests don't >> run because Zero doesn't support UseCompressedOops (not sure why) and >> CDS (know why). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Thu Mar 26 00:08:43 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Mar 2015 20:08:43 -0400 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <1427308172.3470.82.camel@redhat.com> References: <5512F600.9050102@oracle.com> <1427308172.3470.82.camel@redhat.com> Message-ID: <55134E0B.7090600@oracle.com> On 3/25/15, 2:29 PM, Severin Gehwolf wrote: > Hi Coleen, > > Thanks for this! > > On Wed, 2015-03-25 at 13:53 -0400, Coleen Phillimore wrote: >> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false >> for Zero >> >> Also, this fixes a couple other minor issues. >> >> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests don't >> run because Zero doesn't support UseCompressedOops (not sure why) and >> CDS (know why). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 > Disclaimer: Not a reviewer. > > While I'd have preferred correct (safe) SafeFetchX implementations (or > remove them for Zero) I don't see how we could do this for Zero in an > arch-independent way. AFAIK, getting/setting the PC via ucontext is > machine dependent and Zero may be running on any linux architecture > where GCC is available. Thanks for reviewing the code. I suppose we should make implementing SafeFetch required for all platforms because it's called in platform independent code (or rewrite the platform independent code). My goal at the moment was to see how well Zero works. I don't know how well supported this variant is. It seems to be missing a lot. Thanks, Coleen > > Changes look fine to me. > > Cheers, > Severin > >> Thanks, >> Coleen > > From david.holmes at oracle.com Thu Mar 26 00:08:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 10:08:31 +1000 Subject: RFR(s): 8076012 - SA don't support flags of type size_t In-Reply-To: <5CB2AC96-1248-4ACE-8D78-3E4E9140F9FD@oracle.com> References: <55130822.4050702@oracle.com> <5CB2AC96-1248-4ACE-8D78-3E4E9140F9FD@oracle.com> Message-ID: <55134DFF.8090900@oracle.com> On 26/03/2015 7:25 AM, Kim Barrett wrote: > On Mar 25, 2015, at 3:10 PM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> Please review this fix for the serviceability agent to support flags of type size_t. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076012 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8076012/webrev.00/ >> >> This bug is currently blocking the GC repository from being synced with main after the change to make a bunch of flags size_t. > > > Looks good. > > ------------------------------------------------------------------------------ > agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > Changing "a" to "an" > 179 Assert.that(isIntx(), "not an intx flag!"); > 190 Assert.that(isUIntx(), "not an uintx flag!"); > > Nit-picking: I think the first is correct, but not the second. Depends on how you pronounce uintx :) David > And no, I don't need another webrev if you change this. > > ------------------------------------------------------------------------------ > From david.holmes at oracle.com Thu Mar 26 00:21:59 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 10:21:59 +1000 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55134CF1.2020909@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> Message-ID: <55135127.60205@oracle.com> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: > > On 3/25/15, 7:59 PM, David Holmes wrote: >> Hi Coleen, >> >> Why generate stubs that can't be used and then add zero-specific logic >> to the shared CanUseSafeFetchN instead of not generating the stubs so >> that CanUseSafeFetchN will return false anyway ?? > > Because there is platform independent code in objectMonitor.cpp that > uses SafeFetchX (both). I'd rather not burden the caller of this with > testing CanUseSafeFetchX for each call. This code existed before > SafeFetch was implemented, so I'm restoring previous behavior for Zero. Sorry Coleen I thought this was deal to with 8075533, I hadn't realized 8075533 broke the objectMonitor code and this was a follow up. What a mess. :( Thanks, David > We could file an RFE to either implement SafeFetch for Zero or rewrite > this objectMonitor code to not need SafeFetch. I didn't want to do > either of these things with this patch. > > Coleen > >> >> Thanks, >> David >> >> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false >>> for Zero >>> >>> Also, this fixes a couple other minor issues. >>> >>> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests don't >>> run because Zero doesn't support UseCompressedOops (not sure why) and >>> CDS (know why). >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 >>> >>> Thanks, >>> Coleen > From coleen.phillimore at oracle.com Thu Mar 26 01:00:18 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Mar 2015 21:00:18 -0400 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55135127.60205@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> Message-ID: <55135A22.3030309@oracle.com> On 3/25/15, 8:21 PM, David Holmes wrote: > On 26/03/2015 10:04 AM, Coleen Phillimore wrote: >> >> On 3/25/15, 7:59 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> Why generate stubs that can't be used and then add zero-specific logic >>> to the shared CanUseSafeFetchN instead of not generating the stubs so >>> that CanUseSafeFetchN will return false anyway ?? >> >> Because there is platform independent code in objectMonitor.cpp that >> uses SafeFetchX (both). I'd rather not burden the caller of this with >> testing CanUseSafeFetchX for each call. This code existed before >> SafeFetch was implemented, so I'm restoring previous behavior for Zero. > > Sorry Coleen I thought this was deal to with 8075533, I hadn't > realized 8075533 broke the objectMonitor code and this was a follow up. > > What a mess. :( Yes, it is. Is this a code Review? thanks! Coleen > > Thanks, > David > > > >> We could file an RFE to either implement SafeFetch for Zero or rewrite >> this objectMonitor code to not need SafeFetch. I didn't want to do >> either of these things with this patch. >> >> Coleen >> >>> >>> Thanks, >>> David >>> >>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >>>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false >>>> for Zero >>>> >>>> Also, this fixes a couple other minor issues. >>>> >>>> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests >>>> don't >>>> run because Zero doesn't support UseCompressedOops (not sure why) and >>>> CDS (know why). >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 >>>> >>>> Thanks, >>>> Coleen >> From serguei.spitsyn at oracle.com Thu Mar 26 01:16:21 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 25 Mar 2015 18:16:21 -0700 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match Message-ID: <55135DE5.2010705@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8066679 Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ Summary: There can be multiple concurrent RetransformClasses calls on different threads. So that, the assert "cache ptrs must match" is incorrect as it was based on wrong assumptions. The fix removes two related asserts and also frees the scratch_class cached_class_file_bytes if it is necessary to avoid leaking the memory. Testing: In progress: nsk redefine classes tests, JTREG java/lang/instrument Thanks, Serguei From david.holmes at oracle.com Thu Mar 26 02:15:58 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 12:15:58 +1000 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55135A22.3030309@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> Message-ID: <55136BDE.9040000@oracle.com> On 26/03/2015 11:00 AM, Coleen Phillimore wrote: > > On 3/25/15, 8:21 PM, David Holmes wrote: >> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: >>> >>> On 3/25/15, 7:59 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> Why generate stubs that can't be used and then add zero-specific logic >>>> to the shared CanUseSafeFetchN instead of not generating the stubs so >>>> that CanUseSafeFetchN will return false anyway ?? >>> >>> Because there is platform independent code in objectMonitor.cpp that >>> uses SafeFetchX (both). I'd rather not burden the caller of this with >>> testing CanUseSafeFetchX for each call. This code existed before >>> SafeFetch was implemented, so I'm restoring previous behavior for Zero. >> >> Sorry Coleen I thought this was deal to with 8075533, I hadn't >> realized 8075533 broke the objectMonitor code and this was a follow up. >> >> What a mess. :( > > Yes, it is. Is this a code Review? Let me work through this :) The original change for 8074552: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 added the extra error handling stuff related to SafeFetch and a new ErrorHandler test that was predicated on CanUseSafeFetch32 which returns true if the stubs exist. It also added testing of SafeFetch in StubRoutines::initialize2 which was excluded for windows-32-bit and which did not check CanUseSafeFetch32. That change broke zero as reported in 8075533 because you can't actually use the SafeFetch routines with an unsafe address on Zero, and the solution: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5c2bc6278fc4 was to remove the stubs so that CanUseSafeFetch32 would return false, and to include a check of CanUseSafeFetch32 in the tests used with StubRoutines::initialize2. And now we find that the SafeFetch routines are used unconditionally by the objectMonitor code, so we need to restore the stubs that were previously removed, but force CanUseSafeFetch32 to return false on zero. Ok. Only nit is that: return NOT_ZERO(true) ZERO_ONLY(false); would be more readable than the ifdefs. Thanks, David > thanks! > Coleen >> >> Thanks, >> David >> >> >> >>> We could file an RFE to either implement SafeFetch for Zero or rewrite >>> this objectMonitor code to not need SafeFetch. I didn't want to do >>> either of these things with this patch. >>> >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >>>>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false >>>>> for Zero >>>>> >>>>> Also, this fixes a couple other minor issues. >>>>> >>>>> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests >>>>> don't >>>>> run because Zero doesn't support UseCompressedOops (not sure why) and >>>>> CDS (know why). >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 >>>>> >>>>> Thanks, >>>>> Coleen >>> > From coleen.phillimore at oracle.com Thu Mar 26 02:29:37 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Mar 2015 22:29:37 -0400 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55136BDE.9040000@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> Message-ID: <55136F11.7010900@oracle.com> On 3/25/15, 10:15 PM, David Holmes wrote: > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: >> >> On 3/25/15, 8:21 PM, David Holmes wrote: >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: >>>> >>>> On 3/25/15, 7:59 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> Why generate stubs that can't be used and then add zero-specific >>>>> logic >>>>> to the shared CanUseSafeFetchN instead of not generating the stubs so >>>>> that CanUseSafeFetchN will return false anyway ?? >>>> >>>> Because there is platform independent code in objectMonitor.cpp that >>>> uses SafeFetchX (both). I'd rather not burden the caller of this with >>>> testing CanUseSafeFetchX for each call. This code existed before >>>> SafeFetch was implemented, so I'm restoring previous behavior for >>>> Zero. >>> >>> Sorry Coleen I thought this was deal to with 8075533, I hadn't >>> realized 8075533 broke the objectMonitor code and this was a follow up. >>> >>> What a mess. :( >> >> Yes, it is. Is this a code Review? > > Let me work through this :) The original change for 8074552: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 > > added the extra error handling stuff related to SafeFetch and a new > ErrorHandler test that was predicated on CanUseSafeFetch32 which > returns true if the stubs exist. It also added testing of SafeFetch in > StubRoutines::initialize2 which was excluded for windows-32-bit and > which did not check CanUseSafeFetch32. > > That change broke zero as reported in 8075533 because you can't > actually use the SafeFetch routines with an unsafe address on Zero, > and the solution: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5c2bc6278fc4 > > was to remove the stubs so that CanUseSafeFetch32 would return false, > and to include a check of CanUseSafeFetch32 in the tests used with > StubRoutines::initialize2. > > And now we find that the SafeFetch routines are used unconditionally > by the objectMonitor code, so we need to restore the stubs that were > previously removed, but force CanUseSafeFetch32 to return false on zero. Yes, exactly. > > Ok. Only nit is that: > > return NOT_ZERO(true) ZERO_ONLY(false); Yes, you're right. I'll make that change. Thanks! Coleen > > would be more readable than the ifdefs. > > Thanks, > David > >> thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>> >>> >>>> We could file an RFE to either implement SafeFetch for Zero or rewrite >>>> this objectMonitor code to not need SafeFetch. I didn't want to do >>>> either of these things with this patch. >>>> >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >>>>>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX >>>>>> false >>>>>> for Zero >>>>>> >>>>>> Also, this fixes a couple other minor issues. >>>>>> >>>>>> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests >>>>>> don't >>>>>> run because Zero doesn't support UseCompressedOops (not sure why) >>>>>> and >>>>>> CDS (know why). >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> From goetz.lindenmaier at sap.com Thu Mar 26 07:40:25 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 26 Mar 2015 07:40:25 +0000 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55136F11.7010900@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> Hi, sorry I only comment on this now ... I think it's rather strange that you can not use SafeFetch on zero, but it's there, and it's actually used ... which will be the situation after this change. Why not just change objectMonitor as the SafeFetch api is meant to be used? Obviously zero takes care that this access always succeeds: diff -r a35854c84d9d src/share/vm/runtime/objectMonitor.cpp --- a/src/share/vm/runtime/objectMonitor.cpp Wed Mar 25 12:36:28 2015 +0100 +++ b/src/share/vm/runtime/objectMonitor.cpp Thu Mar 26 08:19:53 2015 +0100 @@ -2241,7 +2241,12 @@ } assert(sizeof(((JavaThread *)ox)->_thread_state == sizeof(int)), "invariant"); - int jst = SafeFetch32((int *) &((JavaThread *) ox)->_thread_state, -1);; + int jst; + if (CanUseSafeFetch32()) { + jst = SafeFetch32((int *) &((JavaThread *) ox)->_thread_state, -1); + } else { + jst = ((JavaThread *)ox)->_thread_state; + } // consider also: jst != _thread_in_Java -- but that's overspecific. return jst == _thread_blocked || jst == _thread_in_native; } It's handled similarly in vmError.cpp. And no #ifdefs ;) But I'm also fine with the other change ... to get zero working again. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Thursday, March 26, 2015 3:30 AM To: David Holmes; hotspot-dev developers Subject: Re: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor On 3/25/15, 10:15 PM, David Holmes wrote: > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: >> >> On 3/25/15, 8:21 PM, David Holmes wrote: >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: >>>> >>>> On 3/25/15, 7:59 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> Why generate stubs that can't be used and then add zero-specific >>>>> logic >>>>> to the shared CanUseSafeFetchN instead of not generating the stubs so >>>>> that CanUseSafeFetchN will return false anyway ?? >>>> >>>> Because there is platform independent code in objectMonitor.cpp that >>>> uses SafeFetchX (both). I'd rather not burden the caller of this with >>>> testing CanUseSafeFetchX for each call. This code existed before >>>> SafeFetch was implemented, so I'm restoring previous behavior for >>>> Zero. >>> >>> Sorry Coleen I thought this was deal to with 8075533, I hadn't >>> realized 8075533 broke the objectMonitor code and this was a follow up. >>> >>> What a mess. :( >> >> Yes, it is. Is this a code Review? > > Let me work through this :) The original change for 8074552: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 > > added the extra error handling stuff related to SafeFetch and a new > ErrorHandler test that was predicated on CanUseSafeFetch32 which > returns true if the stubs exist. It also added testing of SafeFetch in > StubRoutines::initialize2 which was excluded for windows-32-bit and > which did not check CanUseSafeFetch32. > > That change broke zero as reported in 8075533 because you can't > actually use the SafeFetch routines with an unsafe address on Zero, > and the solution: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5c2bc6278fc4 > > was to remove the stubs so that CanUseSafeFetch32 would return false, > and to include a check of CanUseSafeFetch32 in the tests used with > StubRoutines::initialize2. > > And now we find that the SafeFetch routines are used unconditionally > by the objectMonitor code, so we need to restore the stubs that were > previously removed, but force CanUseSafeFetch32 to return false on zero. Yes, exactly. > > Ok. Only nit is that: > > return NOT_ZERO(true) ZERO_ONLY(false); Yes, you're right. I'll make that change. Thanks! Coleen > > would be more readable than the ifdefs. > > Thanks, > David > >> thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>> >>> >>>> We could file an RFE to either implement SafeFetch for Zero or rewrite >>>> this objectMonitor code to not need SafeFetch. I didn't want to do >>>> either of these things with this patch. >>>> >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >>>>>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX >>>>>> false >>>>>> for Zero >>>>>> >>>>>> Also, this fixes a couple other minor issues. >>>>>> >>>>>> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests >>>>>> don't >>>>>> run because Zero doesn't support UseCompressedOops (not sure why) >>>>>> and >>>>>> CDS (know why). >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> From goetz.lindenmaier at sap.com Thu Mar 26 08:10:16 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 26 Mar 2015 08:10:16 +0000 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB7D94@DEWDFEMB12A.global.corp.sap> I see it is pushed. No matter. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Thursday, March 26, 2015 8:40 AM To: 'Coleen Phillimore'; 'David Holmes'; 'hotspot-dev developers' Subject: RE: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor Hi, sorry I only comment on this now ... I think it's rather strange that you can not use SafeFetch on zero, but it's there, and it's actually used ... which will be the situation after this change. Why not just change objectMonitor as the SafeFetch api is meant to be used? Obviously zero takes care that this access always succeeds: diff -r a35854c84d9d src/share/vm/runtime/objectMonitor.cpp --- a/src/share/vm/runtime/objectMonitor.cpp Wed Mar 25 12:36:28 2015 +0100 +++ b/src/share/vm/runtime/objectMonitor.cpp Thu Mar 26 08:19:53 2015 +0100 @@ -2241,7 +2241,12 @@ } assert(sizeof(((JavaThread *)ox)->_thread_state == sizeof(int)), "invariant"); - int jst = SafeFetch32((int *) &((JavaThread *) ox)->_thread_state, -1);; + int jst; + if (CanUseSafeFetch32()) { + jst = SafeFetch32((int *) &((JavaThread *) ox)->_thread_state, -1); + } else { + jst = ((JavaThread *)ox)->_thread_state; + } // consider also: jst != _thread_in_Java -- but that's overspecific. return jst == _thread_blocked || jst == _thread_in_native; } It's handled similarly in vmError.cpp. And no #ifdefs ;) But I'm also fine with the other change ... to get zero working again. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Thursday, March 26, 2015 3:30 AM To: David Holmes; hotspot-dev developers Subject: Re: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor On 3/25/15, 10:15 PM, David Holmes wrote: > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: >> >> On 3/25/15, 8:21 PM, David Holmes wrote: >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: >>>> >>>> On 3/25/15, 7:59 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> Why generate stubs that can't be used and then add zero-specific >>>>> logic >>>>> to the shared CanUseSafeFetchN instead of not generating the stubs so >>>>> that CanUseSafeFetchN will return false anyway ?? >>>> >>>> Because there is platform independent code in objectMonitor.cpp that >>>> uses SafeFetchX (both). I'd rather not burden the caller of this with >>>> testing CanUseSafeFetchX for each call. This code existed before >>>> SafeFetch was implemented, so I'm restoring previous behavior for >>>> Zero. >>> >>> Sorry Coleen I thought this was deal to with 8075533, I hadn't >>> realized 8075533 broke the objectMonitor code and this was a follow up. >>> >>> What a mess. :( >> >> Yes, it is. Is this a code Review? > > Let me work through this :) The original change for 8074552: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 > > added the extra error handling stuff related to SafeFetch and a new > ErrorHandler test that was predicated on CanUseSafeFetch32 which > returns true if the stubs exist. It also added testing of SafeFetch in > StubRoutines::initialize2 which was excluded for windows-32-bit and > which did not check CanUseSafeFetch32. > > That change broke zero as reported in 8075533 because you can't > actually use the SafeFetch routines with an unsafe address on Zero, > and the solution: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5c2bc6278fc4 > > was to remove the stubs so that CanUseSafeFetch32 would return false, > and to include a check of CanUseSafeFetch32 in the tests used with > StubRoutines::initialize2. > > And now we find that the SafeFetch routines are used unconditionally > by the objectMonitor code, so we need to restore the stubs that were > previously removed, but force CanUseSafeFetch32 to return false on zero. Yes, exactly. > > Ok. Only nit is that: > > return NOT_ZERO(true) ZERO_ONLY(false); Yes, you're right. I'll make that change. Thanks! Coleen > > would be more readable than the ifdefs. > > Thanks, > David > >> thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>> >>> >>>> We could file an RFE to either implement SafeFetch for Zero or rewrite >>>> this objectMonitor code to not need SafeFetch. I didn't want to do >>>> either of these things with this patch. >>>> >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >>>>>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX >>>>>> false >>>>>> for Zero >>>>>> >>>>>> Also, this fixes a couple other minor issues. >>>>>> >>>>>> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests >>>>>> don't >>>>>> run because Zero doesn't support UseCompressedOops (not sure why) >>>>>> and >>>>>> CDS (know why). >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> From volker.simonis at gmail.com Thu Mar 26 08:27:51 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Mar 2015 09:27:51 +0100 Subject: [8u60] request for approval: "8067923: AIX: link libjvm.so with -bernotok..." and "8075858: AIX: clean-up HotSpot make files" In-Reply-To: <551321F5.7020800@oracle.com> References: <551321F5.7020800@oracle.com> Message-ID: On Wed, Mar 25, 2015 at 10:00 PM, Vladimir Kozlov wrote: > Hi, > > Since it is only hotspot changes they will go through jdk8u/hs-dev/hotspot. > Alejandro will merge them to 8u after testing. > No need for separate approval from jdk8u. > > Next time, please, ask for Hotspot changes backport on hotspot-dev mailing > list. > Sorry, I missed that. > I'm sponsoring backport - it is in JPRT queue. > Thanks a lot, Vladimir! Regards, Volker > Thanks, > Vladimir > > > On 3/25/15 10:48 AM, Volker Simonis wrote: >> >> Hi, >> >> could you please approve and sponsor the backport of the following >> two, AIX-only HotSpot fixes to jd8u-dev: >> >> 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols >> at build time and suppress warning 1540-1639 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067923 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/8067923/ >> Review: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016568.html >> URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c0f8994d6ee6 >> >> >> 8075858: AIX: clean-up HotSpot make files >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075858 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2015/8075858/ >> Review: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017659.html >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3891403eb18e >> >> Both changes cleanly apply to the current 8u-dev/hotspot repository >> and only touch AIX-specific make files. >> >> Thank you and best regards, >> Volker >> > From thomas.stuefe at gmail.com Thu Mar 26 08:35:18 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Mar 2015 09:35:18 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> Message-ID: Hi, I agree with Goetz. SafeFetch() was meant to be guarded with CanUseSafeFetch(), this is part of the contract, so using it without this guard is actually incorrect and would crash were the calling code ever called before Stub routine initialization. So now - CanUseSafeFetch really now means "SafeFetch will behave as excpected" - SafeFetch is softened to "will safely fetch content of address unless on zero, there it may crash the VM". I think this is more confusing than before. In objectMonitor, the logic we want is "use SafeFetch wherever possible but if not, just access the memory directly". This logic now is hidden behind a seemingly incorrect use of SafeFetch without CanUseSafeFetch, and I think Goetz proposal would have been far more clearer. Kind Regards, Thomas On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > sorry I only comment on this now ... > I think it's rather strange that you can not use SafeFetch on zero, but > it's there, > and it's actually used ... which will be the situation after this change. > > Why not just change objectMonitor as the SafeFetch api is meant to be used? > Obviously zero takes care that this access always succeeds: > > diff -r a35854c84d9d src/share/vm/runtime/objectMonitor.cpp > --- a/src/share/vm/runtime/objectMonitor.cpp Wed Mar 25 12:36:28 2015 > +0100 > +++ b/src/share/vm/runtime/objectMonitor.cpp Thu Mar 26 08:19:53 2015 > +0100 > @@ -2241,7 +2241,12 @@ > } > > assert(sizeof(((JavaThread *)ox)->_thread_state == sizeof(int)), > "invariant"); > - int jst = SafeFetch32((int *) &((JavaThread *) ox)->_thread_state, -1);; > + int jst; > + if (CanUseSafeFetch32()) { > + jst = SafeFetch32((int *) &((JavaThread *) ox)->_thread_state, -1); > + } else { > + jst = ((JavaThread *)ox)->_thread_state; > + } > // consider also: jst != _thread_in_Java -- but that's overspecific. > return jst == _thread_blocked || jst == _thread_in_native; > } > > It's handled similarly in vmError.cpp. And no #ifdefs ;) > > But I'm also fine with the other change ... to get zero working again. > > Best regards, > Goetz. > > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf > Of Coleen Phillimore > Sent: Thursday, March 26, 2015 3:30 AM > To: David Holmes; hotspot-dev developers > Subject: Re: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, > N> calls in ObjectMonitor > > > On 3/25/15, 10:15 PM, David Holmes wrote: > > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: > >> > >> On 3/25/15, 8:21 PM, David Holmes wrote: > >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: > >>>> > >>>> On 3/25/15, 7:59 PM, David Holmes wrote: > >>>>> Hi Coleen, > >>>>> > >>>>> Why generate stubs that can't be used and then add zero-specific > >>>>> logic > >>>>> to the shared CanUseSafeFetchN instead of not generating the stubs so > >>>>> that CanUseSafeFetchN will return false anyway ?? > >>>> > >>>> Because there is platform independent code in objectMonitor.cpp that > >>>> uses SafeFetchX (both). I'd rather not burden the caller of this with > >>>> testing CanUseSafeFetchX for each call. This code existed before > >>>> SafeFetch was implemented, so I'm restoring previous behavior for > >>>> Zero. > >>> > >>> Sorry Coleen I thought this was deal to with 8075533, I hadn't > >>> realized 8075533 broke the objectMonitor code and this was a follow up. > >>> > >>> What a mess. :( > >> > >> Yes, it is. Is this a code Review? > > > > Let me work through this :) The original change for 8074552: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 > > > > added the extra error handling stuff related to SafeFetch and a new > > ErrorHandler test that was predicated on CanUseSafeFetch32 which > > returns true if the stubs exist. It also added testing of SafeFetch in > > StubRoutines::initialize2 which was excluded for windows-32-bit and > > which did not check CanUseSafeFetch32. > > > > That change broke zero as reported in 8075533 because you can't > > actually use the SafeFetch routines with an unsafe address on Zero, > > and the solution: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5c2bc6278fc4 > > > > was to remove the stubs so that CanUseSafeFetch32 would return false, > > and to include a check of CanUseSafeFetch32 in the tests used with > > StubRoutines::initialize2. > > > > And now we find that the SafeFetch routines are used unconditionally > > by the objectMonitor code, so we need to restore the stubs that were > > previously removed, but force CanUseSafeFetch32 to return false on zero. > > Yes, exactly. > > > > Ok. Only nit is that: > > > > return NOT_ZERO(true) ZERO_ONLY(false); > > Yes, you're right. I'll make that change. > > Thanks! > Coleen > > > > > would be more readable than the ifdefs. > > > > Thanks, > > David > > > >> thanks! > >> Coleen > >>> > >>> Thanks, > >>> David > >>> > >>> > >>> > >>>> We could file an RFE to either implement SafeFetch for Zero or rewrite > >>>> this objectMonitor code to not need SafeFetch. I didn't want to do > >>>> either of these things with this patch. > >>>> > >>>> Coleen > >>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: > >>>>>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX > >>>>>> false > >>>>>> for Zero > >>>>>> > >>>>>> Also, this fixes a couple other minor issues. > >>>>>> > >>>>>> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests > >>>>>> don't > >>>>>> run because Zero doesn't support UseCompressedOops (not sure why) > >>>>>> and > >>>>>> CDS (know why). > >>>>>> > >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ > >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 > >>>>>> > >>>>>> Thanks, > >>>>>> Coleen > >>>> > >> > > From zoltan.majo at oracle.com Thu Mar 26 08:49:23 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 26 Mar 2015 09:49:23 +0100 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1427302783.14624.8.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1427302783.14624.8.camel@mylittlepony.linaroharston> Message-ID: <5513C813.1000006@oracle.com> Hi Ed, On 03/25/2015 05:59 PM, Edward Nevill wrote: > Hi Zolt?n, > > On Wed, 2015-03-25 at 14:28 +0100, Zolt?n Maj? wrote: >> On 03/25/2015 02:02 PM, Edward Nevill wrote: >>> The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation. >> It seems to me that the C2 compiler currently saves the SP into FP on >> method handle invokes. This functionality is encoded by >> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages >> of FrameMap::method_handle_invoke_SP_save_opr()). > Thanks! I had not spotted this usage. > > If my understanding is correct, it does not need to be RFP in > aarch64_enc_java_handle_call. It could be any callee saved register? On > aarch64 r19..r28 are callee saved so we could use say r19 instead. Yes, any callee-saved would be OK. > C1 and C2 are caller save, so they will not have any valid data in r19 > at the point of the call (this is the problem with using RFP, because > RFP is not caller save). > >> Stack walking relies on having the SP saved into FP for method handle >> invokes (e.g., in frame::adjust_unextended_sp()). > These would then need to be modified to recover the sp from r19. That is correct as well. As I mentioned earlier, I'm currently working on a patch that intends to disable saving SP into FP on method handle invokes on x86 (JDK-8068945). Maybe the same could be done for aarch64 as well and then you could use both fp and r19 as "general purpose" registers. I plan to send out the RFR this week or early next week and will let you know. But what you just proposed is also fine, I think. Best wishes, Zolt?n > > Would this work? > > All the best, > Ed. > > From aph at redhat.com Thu Mar 26 09:27:48 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Mar 2015 09:27:48 +0000 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5512C149.2060708@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <5512C149.2060708@redhat.com> Message-ID: <5513D114.6030303@redhat.com> On 25/03/15 14:08, Andrew Dinn wrote: > On 25/03/15 13:28, Zolt?n Maj? wrote: >> On 03/25/2015 02:02 PM, Edward Nevill wrote: >>> The aarch64 C2 compiler makes no use of the FP register even though >>> this register is saved on entry and restored on exit and is therefore >>> always available for allocation. >> >> It seems to me that the C2 compiler currently saves the SP into FP on >> method handle invokes. This functionality is encoded by >> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages >> of FrameMap::method_handle_invoke_SP_save_opr()). > > Yes, that's correct. aarch64_enc_java_handle relies on having FP > available to save SP. So, it looks like this fix will break that. I'm surprised it matters. If FP is live around a handle call I would have thought it would be spilled onto the stack. Andrew. From zoltan.majo at oracle.com Thu Mar 26 09:32:55 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 26 Mar 2015 10:32:55 +0100 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5513D114.6030303@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <5512C149.2060708@redhat.com> <5513D114.6030303@redhat.com> Message-ID: <5513D247.50303@oracle.com> Hi Andrew, On 03/26/2015 10:27 AM, Andrew Haley wrote: > On 25/03/15 14:08, Andrew Dinn wrote: >> On 25/03/15 13:28, Zolt?n Maj? wrote: >>> On 03/25/2015 02:02 PM, Edward Nevill wrote: >>>> The aarch64 C2 compiler makes no use of the FP register even though >>>> this register is saved on entry and restored on exit and is therefore >>>> always available for allocation. >>> It seems to me that the C2 compiler currently saves the SP into FP on >>> method handle invokes. This functionality is encoded by >>> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages >>> of FrameMap::method_handle_invoke_SP_save_opr()). >> Yes, that's correct. aarch64_enc_java_handle relies on having FP >> available to save SP. So, it looks like this fix will break that. > I'm surprised it matters. If FP is live around a handle call I would > have thought it would be spilled onto the stack. It seems to me that FP is currently not allocatable on aarch64. Best regards, Zoltan > > Andrew. > From aph at redhat.com Thu Mar 26 09:34:18 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Mar 2015 09:34:18 +0000 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5513D247.50303@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <5512C149.2060708@redhat.com> <5513D114.6030303@redhat.com> <5513D247.50303@oracle.com> Message-ID: <5513D29A.9070100@redhat.com> On 26/03/15 09:32, Zolt?n Maj? wrote: > Hi Andrew, > > > On 03/26/2015 10:27 AM, Andrew Haley wrote: >> On 25/03/15 14:08, Andrew Dinn wrote: >>> On 25/03/15 13:28, Zolt?n Maj? wrote: >>>> On 03/25/2015 02:02 PM, Edward Nevill wrote: >>>>> The aarch64 C2 compiler makes no use of the FP register even though >>>>> this register is saved on entry and restored on exit and is therefore >>>>> always available for allocation. >>>> It seems to me that the C2 compiler currently saves the SP into FP on >>>> method handle invokes. This functionality is encoded by >>>> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages >>>> of FrameMap::method_handle_invoke_SP_save_opr()). >>> Yes, that's correct. aarch64_enc_java_handle relies on having FP >>> available to save SP. So, it looks like this fix will break that. >> >> I'm surprised it matters. If FP is live around a handle call I would >> have thought it would be spilled onto the stack. > > It seems to me that FP is currently not allocatable on aarch64. It seems that way to me too. That's what we want to change. Andrew. From sgehwolf at redhat.com Thu Mar 26 10:22:06 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 26 Mar 2015 11:22:06 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55134E0B.7090600@oracle.com> References: <5512F600.9050102@oracle.com> <1427308172.3470.82.camel@redhat.com> <55134E0B.7090600@oracle.com> Message-ID: <1427365326.3339.35.camel@redhat.com> Hi Coleen, On Wed, 2015-03-25 at 20:08 -0400, Coleen Phillimore wrote: > On 3/25/15, 2:29 PM, Severin Gehwolf wrote: > > Hi Coleen, > > > > Thanks for this! > > > > On Wed, 2015-03-25 at 13:53 -0400, Coleen Phillimore wrote: > >> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false > >> for Zero > >> > >> Also, this fixes a couple other minor issues. > >> > >> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg tests don't > >> run because Zero doesn't support UseCompressedOops (not sure why) and > >> CDS (know why). > >> > >> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ > >> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 > > Disclaimer: Not a reviewer. > > > > While I'd have preferred correct (safe) SafeFetchX implementations (or > > remove them for Zero) I don't see how we could do this for Zero in an > > arch-independent way. AFAIK, getting/setting the PC via ucontext is > > machine dependent and Zero may be running on any linux architecture > > where GCC is available. > > Thanks for reviewing the code. I suppose we should make implementing > SafeFetch required for all platforms because it's called in platform > independent code (or rewrite the platform independent code). > My goal at the moment was to see how well Zero works. I don't know how > well supported this variant is. I'd be very interested to hear on how you determine how well Zero works. Use the TCK? Some other metric? As for jtreg tests, many of them fail trivially because they assume there is server and client JVMs only (e.g. tools/launcher/VersionCheck.java in JDK). With that being said, Zero should be in better shape now than it was a while ago. Back then, it wouldn't even compile in latest upstream trees... Depending on available cycles I'll try to help as much as I can. The best metric we have currently for Zero is its ability to build itself. I've never managed to go through all failing jtreg tests and determine exactly what's wrong (test or JVM failure). > It seems to be missing a lot. Right. A good starting point is making people aware that it exists so that no new compilation errors get introduced. You've been doing a great job at this. Thanks! My goal is to make Zero better over time, since it's been lacking basic maintainership for a while in upstream OpenJDK. Aside: Zero is using the C++ interpreter which AFAIK, isn't used much anywhere else. Most (all?) JIT ports use the template interpreter these days. Thanks, Severin > Thanks, > Coleen > > > > > Changes look fine to me. > > > > Cheers, > > Severin > > > >> Thanks, > >> Coleen > > > > > From david.holmes at oracle.com Thu Mar 26 10:42:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 20:42:46 +1000 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> Message-ID: <5513E2A6.30500@oracle.com> Hi Thomas, On 26/03/2015 6:35 PM, Thomas St?fe wrote: > Hi, > > I agree with Goetz. > > SafeFetch() was meant to be guarded with CanUseSafeFetch(), this is part > of the contract, so using it without this guard is actually incorrect > and would crash were the calling code ever called before Stub routine > initialization. That contract was already implicit - this API is for use after the stubs have been generated. There's no reason to expand the use of this API to situations before stubs are generated. So the assert captures that and CanUseSafeFetch is really unnecessary. > So now > - CanUseSafeFetch really now means "SafeFetch will behave as excpected" > - SafeFetch is softened to "will safely fetch content of address unless > on zero, there it may crash the VM". > > I think this is more confusing than before. In objectMonitor, the logic > we want is "use SafeFetch wherever possible but if not, just access the > memory directly". This logic now is hidden behind a seemingly incorrect > use of SafeFetch without CanUseSafeFetch, and I think Goetz proposal > would have been far more clearer. No the problem is that SafeFetch doesn't work on ZERO - if you give it a bad address it won't recover it will crash. The whole point is for it not to crash. The objectMonitor code is saying "here is a load that we know may be invalid, but if it is then we don't want to crash, so we use SafeFetch". The expectation is that SafeFetch actually is safe no matter what is fetched. The ZERO implementation just does a load and hopes it isn't asked for anything bad. The objectMonitor code will rarely actually trigger a bad load. But the newly introduced test does. So in my opinion to return to the status-quo where ZERO really doesn't implement SafeFetch safely but it "works okay in practice", we should disable those explicit tests when running on ZERO. Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is implemented explicitly or implicitly as an assert is a side-issue. David > Kind Regards, Thomas > > > > > > > > On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz > > wrote: > > Hi, > > sorry I only comment on this now ... > I think it's rather strange that you can not use SafeFetch on zero, > but it's there, > and it's actually used ... which will be the situation after this > change. > > Why not just change objectMonitor as the SafeFetch api is meant to > be used? > Obviously zero takes care that this access always succeeds: > > diff -r a35854c84d9d src/share/vm/runtime/objectMonitor.cpp > --- a/src/share/vm/runtime/objectMonitor.cpp Wed Mar 25 12:36:28 > 2015 +0100 > +++ b/src/share/vm/runtime/objectMonitor.cpp Thu Mar 26 08:19:53 > 2015 +0100 > @@ -2241,7 +2241,12 @@ > } > > assert(sizeof(((JavaThread *)ox)->_thread_state == sizeof(int)), > "invariant"); > - int jst = SafeFetch32((int *) &((JavaThread *) > ox)->_thread_state, -1);; > + int jst; > + if (CanUseSafeFetch32()) { > + jst = SafeFetch32((int *) &((JavaThread *) ox)->_thread_state, -1); > + } else { > + jst = ((JavaThread *)ox)->_thread_state; > + } > // consider also: jst != _thread_in_Java -- but that's overspecific. > return jst == _thread_blocked || jst == _thread_in_native; > } > > It's handled similarly in vmError.cpp. And no #ifdefs ;) > > But I'm also fine with the other change ... to get zero working again. > > Best regards, > Goetz. > > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net > ] On Behalf Of Coleen > Phillimore > Sent: Thursday, March 26, 2015 3:30 AM > To: David Holmes; hotspot-dev developers > Subject: Re: RFR (xs) 8075967: Zero interpreter asserts for > SafeFetch<32, N> calls in ObjectMonitor > > > On 3/25/15, 10:15 PM, David Holmes wrote: > > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: > >> > >> On 3/25/15, 8:21 PM, David Holmes wrote: > >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: > >>>> > >>>> On 3/25/15, 7:59 PM, David Holmes wrote: > >>>>> Hi Coleen, > >>>>> > >>>>> Why generate stubs that can't be used and then add zero-specific > >>>>> logic > >>>>> to the shared CanUseSafeFetchN instead of not generating the > stubs so > >>>>> that CanUseSafeFetchN will return false anyway ?? > >>>> > >>>> Because there is platform independent code in > objectMonitor.cpp that > >>>> uses SafeFetchX (both). I'd rather not burden the caller of > this with > >>>> testing CanUseSafeFetchX for each call. This code existed before > >>>> SafeFetch was implemented, so I'm restoring previous behavior for > >>>> Zero. > >>> > >>> Sorry Coleen I thought this was deal to with 8075533, I hadn't > >>> realized 8075533 broke the objectMonitor code and this was a > follow up. > >>> > >>> What a mess. :( > >> > >> Yes, it is. Is this a code Review? > > > > Let me work through this :) The original change for 8074552: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 > > > > added the extra error handling stuff related to SafeFetch and a new > > ErrorHandler test that was predicated on CanUseSafeFetch32 which > > returns true if the stubs exist. It also added testing of > SafeFetch in > > StubRoutines::initialize2 which was excluded for windows-32-bit and > > which did not check CanUseSafeFetch32. > > > > That change broke zero as reported in 8075533 because you can't > > actually use the SafeFetch routines with an unsafe address on Zero, > > and the solution: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5c2bc6278fc4 > > > > was to remove the stubs so that CanUseSafeFetch32 would return false, > > and to include a check of CanUseSafeFetch32 in the tests used with > > StubRoutines::initialize2. > > > > And now we find that the SafeFetch routines are used unconditionally > > by the objectMonitor code, so we need to restore the stubs that were > > previously removed, but force CanUseSafeFetch32 to return false > on zero. > > Yes, exactly. > > > > Ok. Only nit is that: > > > > return NOT_ZERO(true) ZERO_ONLY(false); > > Yes, you're right. I'll make that change. > > Thanks! > Coleen > > > > > would be more readable than the ifdefs. > > > > Thanks, > > David > > > >> thanks! > >> Coleen > >>> > >>> Thanks, > >>> David > >>> > >>> > >>> > >>>> We could file an RFE to either implement SafeFetch for Zero or > rewrite > >>>> this objectMonitor code to not need SafeFetch. I didn't want > to do > >>>> either of these things with this patch. > >>>> > >>>> Coleen > >>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: > >>>>>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX > >>>>>> false > >>>>>> for Zero > >>>>>> > >>>>>> Also, this fixes a couple other minor issues. > >>>>>> > >>>>>> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg > tests > >>>>>> don't > >>>>>> run because Zero doesn't support UseCompressedOops (not sure > why) > >>>>>> and > >>>>>> CDS (know why). > >>>>>> > >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ > >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 > >>>>>> > >>>>>> Thanks, > >>>>>> Coleen > >>>> > >> > > From thomas.stuefe at gmail.com Thu Mar 26 12:24:18 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Mar 2015 13:24:18 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <5513E2A6.30500@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> Message-ID: Hi David, On Thu, Mar 26, 2015 at 11:42 AM, David Holmes wrote: > Hi Thomas, > > On 26/03/2015 6:35 PM, Thomas St?fe wrote: > >> Hi, >> >> I agree with Goetz. >> >> SafeFetch() was meant to be guarded with CanUseSafeFetch(), this is part >> of the contract, so using it without this guard is actually incorrect >> and would crash were the calling code ever called before Stub routine >> initialization. >> > > That contract was already implicit - this API is for use after the stubs > have been generated. There's no reason to expand the use of this API to > situations before stubs are generated. So the assert captures that and > CanUseSafeFetch is really unnecessary. We had to introduce CanUseSafeFetch() exactly because we have situations where we may call SafeFetch before stub routine generation: 1) In os_aix.cpp, we use it to probe protected memory after doing mprotect(). This is a long story, but we had to add this workaround because on shortcomings in AIX's mprotect(). This code will get called during initialization before stub routines are set up. Note that right now, in the OpenJDK code base, the code still directly checks whether the stubroutine is NULL, because that mprotect workaround is older than 8074552. But I planned to change this to CanUseSafeFetch(). But with the new CanUseSafeFetch, this would just break AIX. 2) In SAPs code base, we also use it to harden error log writing (e.g. to make callstack dumping more reliable). This may can be invoked very early, if a crash happens very early, before stub routines are available. We planned to contribute those improvements piece by piece to the OpenJDK - my first change for 8074552 was actually supposed to prepare that. Now, however, this makes no sense, because using SafeFetch() to harden error log writing would actually be worse for error logs for early crashes. SafeFetch is a very basic function which could be useful in many more contexts, but only if you can really be sure it is safe. The contexts it is used in may be very low level where you cannot be sure at which point in VM initialization you are. When I introduced CanUseSafeFetch(), it was to safeguard the use of SafeFetch() for situations where SafeFetch was not safe to call. Exactly so that I would have not to think about "is this too early to use SafeFetch()?". This is broken now - instead of guarding me against using SafeFetch() in situations where it is not safe to use, it will assert(debug) or potentially lie(release), in which case SafeFetch itself may crash. > > So now >> - CanUseSafeFetch really now means "SafeFetch will behave as excpected" >> - SafeFetch is softened to "will safely fetch content of address unless >> on zero, there it may crash the VM". >> >> I think this is more confusing than before. In objectMonitor, the logic >> we want is "use SafeFetch wherever possible but if not, just access the >> memory directly". This logic now is hidden behind a seemingly incorrect >> use of SafeFetch without CanUseSafeFetch, and I think Goetz proposal >> would have been far more clearer. >> > > No the problem is that SafeFetch doesn't work on ZERO - if you give it a > bad address it won't recover it will crash. The whole point is for it not > to crash. The objectMonitor code is saying "here is a load that we know may > be invalid, but if it is then we don't want to crash, so we use SafeFetch". Yes! But the way it is coded, it does not. Because SafeFetch is now implemented on zero with a simple load, it is not safe at all. The code in objectMonitor.cpp appears to be safe, but it is not. And SafeFetch() promises to be safe, but it is not, and you would not know unless you know the zero implementation. It seems to be a bit inconsequent. Either one is really sure the pointer is accessible - in which case why use SafeFetch? - or it may be invalid, even if this is unusual - in which case why is the resulting crash not a problem for zero? In other words, if the original programmer thought it worth to guard the memory access with SafeFetch(), why is this not a concern for zero? The expectation is that SafeFetch actually is safe no matter what is > fetched. Yes, and that expectation is broken now. Before, if you used SafeFetch() and guarded it with CanUseSafeFetch(), you could be sure to be safe and not to break anything - regardless when in VM life you used the function or on which platform. Both SafeFetch and CanUseSafeFetch made promises: - CanUseSafeFetch promised to tell me if it is too early to call SafeFetch. Of course, it itself could be called at all times, that was the whole point of CanUseSafeFetch. - SafeFetch promised to be able to access a potentially invalid pointer and not to crash - if CanUseSafeFetch returned true. Both promises are broken now. CanUseSafeFetch is not safe to call if it is too early - ironically a condition it was designed to tell me. SafeFetch is not safe to call because it lies about being safe for zero. The result is that either if we continue to use SafeFetch, we risk crashes on zero and crashes if invoked too early. This makes the API useless for most cases. I am open to any other suggestions - renaming the APIs, maybe reshaping them - but I regret seeing SafeFetch being back to being quite unsafe again. Kind Regards, Thomas The ZERO implementation just does a load and hopes it isn't asked for > anything bad. The objectMonitor code will rarely actually trigger a bad > load. But the newly introduced test does. > > So in my opinion to return to the status-quo where ZERO really doesn't > implement SafeFetch safely but it "works okay in practice", we should > disable those explicit tests when running on ZERO. > > Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is implemented > explicitly or implicitly as an assert is a side-issue. > > David > > Kind Regards, Thomas >> >> >> >> >> >> >> >> On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz >> > wrote: >> >> Hi, >> >> sorry I only comment on this now ... >> I think it's rather strange that you can not use SafeFetch on zero, >> but it's there, >> and it's actually used ... which will be the situation after this >> change. >> >> Why not just change objectMonitor as the SafeFetch api is meant to >> be used? >> Obviously zero takes care that this access always succeeds: >> >> diff -r a35854c84d9d src/share/vm/runtime/objectMonitor.cpp >> --- a/src/share/vm/runtime/objectMonitor.cpp Wed Mar 25 12:36:28 >> 2015 +0100 >> +++ b/src/share/vm/runtime/objectMonitor.cpp Thu Mar 26 08:19:53 >> 2015 +0100 >> @@ -2241,7 +2241,12 @@ >> } >> >> assert(sizeof(((JavaThread *)ox)->_thread_state == sizeof(int)), >> "invariant"); >> - int jst = SafeFetch32((int *) &((JavaThread *) >> ox)->_thread_state, -1);; >> + int jst; >> + if (CanUseSafeFetch32()) { >> + jst = SafeFetch32((int *) &((JavaThread *) ox)->_thread_state, >> -1); >> + } else { >> + jst = ((JavaThread *)ox)->_thread_state; >> + } >> // consider also: jst != _thread_in_Java -- but that's >> overspecific. >> return jst == _thread_blocked || jst == _thread_in_native; >> } >> >> It's handled similarly in vmError.cpp. And no #ifdefs ;) >> >> But I'm also fine with the other change ... to get zero working again. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net >> ] On Behalf Of Coleen >> Phillimore >> Sent: Thursday, March 26, 2015 3:30 AM >> To: David Holmes; hotspot-dev developers >> Subject: Re: RFR (xs) 8075967: Zero interpreter asserts for >> SafeFetch<32, N> calls in ObjectMonitor >> >> >> On 3/25/15, 10:15 PM, David Holmes wrote: >> > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: >> >> >> >> On 3/25/15, 8:21 PM, David Holmes wrote: >> >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: >> >>>> >> >>>> On 3/25/15, 7:59 PM, David Holmes wrote: >> >>>>> Hi Coleen, >> >>>>> >> >>>>> Why generate stubs that can't be used and then add >> zero-specific >> >>>>> logic >> >>>>> to the shared CanUseSafeFetchN instead of not generating the >> stubs so >> >>>>> that CanUseSafeFetchN will return false anyway ?? >> >>>> >> >>>> Because there is platform independent code in >> objectMonitor.cpp that >> >>>> uses SafeFetchX (both). I'd rather not burden the caller of >> this with >> >>>> testing CanUseSafeFetchX for each call. This code existed >> before >> >>>> SafeFetch was implemented, so I'm restoring previous behavior >> for >> >>>> Zero. >> >>> >> >>> Sorry Coleen I thought this was deal to with 8075533, I hadn't >> >>> realized 8075533 broke the objectMonitor code and this was a >> follow up. >> >>> >> >>> What a mess. :( >> >> >> >> Yes, it is. Is this a code Review? >> > >> > Let me work through this :) The original change for 8074552: >> > >> > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 >> > >> > added the extra error handling stuff related to SafeFetch and a new >> > ErrorHandler test that was predicated on CanUseSafeFetch32 which >> > returns true if the stubs exist. It also added testing of >> SafeFetch in >> > StubRoutines::initialize2 which was excluded for windows-32-bit and >> > which did not check CanUseSafeFetch32. >> > >> > That change broke zero as reported in 8075533 because you can't >> > actually use the SafeFetch routines with an unsafe address on Zero, >> > and the solution: >> > >> > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5c2bc6278fc4 >> > >> > was to remove the stubs so that CanUseSafeFetch32 would return >> false, >> > and to include a check of CanUseSafeFetch32 in the tests used with >> > StubRoutines::initialize2. >> > >> > And now we find that the SafeFetch routines are used >> unconditionally >> > by the objectMonitor code, so we need to restore the stubs that >> were >> > previously removed, but force CanUseSafeFetch32 to return false >> on zero. >> >> Yes, exactly. >> > >> > Ok. Only nit is that: >> > >> > return NOT_ZERO(true) ZERO_ONLY(false); >> >> Yes, you're right. I'll make that change. >> >> Thanks! >> Coleen >> >> > >> > would be more readable than the ifdefs. >> > >> > Thanks, >> > David >> > >> >> thanks! >> >> Coleen >> >>> >> >>> Thanks, >> >>> David >> >>> >> >>> >> >>> >> >>>> We could file an RFE to either implement SafeFetch for Zero or >> rewrite >> >>>> this objectMonitor code to not need SafeFetch. I didn't want >> to do >> >>>> either of these things with this patch. >> >>>> >> >>>> Coleen >> >>>> >> >>>>> >> >>>>> Thanks, >> >>>>> David >> >>>>> >> >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >> >>>>>> Summary: Implement SafeFetchX unsafely and make >> CanUseSafeFetchX >> >>>>>> false >> >>>>>> for Zero >> >>>>>> >> >>>>>> Also, this fixes a couple other minor issues. >> >>>>>> >> >>>>>> Ran jdk9 jck tests with one timeout. hotspot/runtime jtreg >> tests >> >>>>>> don't >> >>>>>> run because Zero doesn't support UseCompressedOops (not sure >> why) >> >>>>>> and >> >>>>>> CDS (know why). >> >>>>>> >> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/ >> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967 >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Coleen >> >>>> >> >> >> >> >> From yekaterina.kantserova at oracle.com Thu Mar 26 12:38:14 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 26 Mar 2015 13:38:14 +0100 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <55134092.801@oracle.com> References: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> <55134092.801@oracle.com> Message-ID: <5513FDB6.6070606@oracle.com> Mandy, Thank you very much for the catch! The updated webrev can be found here: http://cr.openjdk.java.net/~ykantser/8075586/webrev.00/ Best regards, Katja On 03/26/2015 12:11 AM, Mandy Chung wrote: > Alexandar, Shura, > > The dependency analysis is not up-to-date that sun.tools.jar > has been moved to jdk.jartool module in jdk9 b55. It has been > in jdk9/dev since 3/6. > > I have pointed out multiple times previously that jdk.dev/sun.tools.jar > is wrong in the jdk side of change. > > Below includes an example. > Mandy > > --- old/test/runtime/RedefineTests/RedefineAnnotations.java 2015-03-25 > 16:24:41.462038538 +0300 > +++ new/test/runtime/RedefineTests/RedefineAnnotations.java 2015-03-25 > 16:24:41.386038539 +0300 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -25,6 +25,9 @@ > * @test > * @library /testlibrary > * @summary Test that type annotations are retained after a retransform > + * @modules java.base/jdk.internal.org.objectweb.asm > + * java.instrument > + * jdk.dev/sun.tools.jar > * @run main RedefineAnnotations buildagent > * @run main/othervm -javaagent:redefineagent.jar RedefineAnnotations > */ > > > On 3/25/15 7:38 AM, Alexander Kulyakhtin wrote: >> Hi >> >> Please, find the updated review for the bulk @modules change at the >> link below. >> >> We have fixed the copyrights and the files mentioned in the mail from >> Lois. >> >> http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html >> >> Best regards, >> Alex >> >> >> >> ----- Original Message ----- >> From: lois.foltan at oracle.com >> To: yekaterina.kantserova at oracle.com >> Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, >> hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, >> alexandre.iline at oracle.com >> Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> >> This looks good, thank you for making these changes! A couple of >> comments that I don't feel need another webrev but should be fixed >> before pushing. >> >> - copyrights on all the tests need to be updated >> - the following tests have a blank comment line before the new >> "@modules" line that could be removed >> test/gc/metaspace/TestMetaspacePerfCounters.java >> test/runtime/contended/Basic.java >> test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java >> test/compiler/cpuflags/RestoreMXCSR.java >> test/compiler/debug/VerifyAdapterSharing.java >> >> Thanks, >> Lois >> >> On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: >>> Notifying hotspot-dev as well. >>> >>> // Katja >>> >>> >>> >>> On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >>>> Could the reviewers, please, have a look at the proposed changes >>>> below? >>>> >>>> In addition, we are going to make a change to the TEST.ROOT file as >>>> indicated by Staffan in the mail below. >>>> >>>> Do you think the changes (plus the one-line change to the TEST.ROOT) >>>> can be pushed into the jdk? >>>> >>>> Best regards, >>>> Alex >>>> >>>> ----- Original Message ----- >>>> From: staffan.larsen at oracle.com >>>> To: alexander.kulyakhtin at oracle.com >>>> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >>>> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >>>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>>> hotspot tests >>>> >>>> I haven?t looked at the changes in detail, but please change the >>>> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could you, please, review the fix below. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>>>> >>>>> The fix adds @modules keyword to the existing hotspot tests, as >>>>> needed, so that the tests can access the required API when the new >>>>> modular architecture is in place. >>>>> >>>>> Best regards, >>>>> Alex > From david.holmes at oracle.com Thu Mar 26 12:38:06 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 22:38:06 +1000 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> Message-ID: <5513FDAE.4010608@oracle.com> On 26/03/2015 10:24 PM, Thomas St?fe wrote: > Hi David, > > On Thu, Mar 26, 2015 at 11:42 AM, David Holmes > wrote: > > Hi Thomas, > > On 26/03/2015 6:35 PM, Thomas St?fe wrote: > > Hi, > > I agree with Goetz. > > SafeFetch() was meant to be guarded with CanUseSafeFetch(), this > is part > of the contract, so using it without this guard is actually > incorrect > and would crash were the calling code ever called before Stub > routine > initialization. > > > That contract was already implicit - this API is for use after the > stubs have been generated. There's no reason to expand the use of > this API to situations before stubs are generated. So the assert > captures that and CanUseSafeFetch is really unnecessary. > > > We had to introduce CanUseSafeFetch() exactly because we have situations > where we may call SafeFetch before stub routine generation: > > 1) In os_aix.cpp, we use it to probe protected memory after doing > mprotect(). This is a long story, but we had to add this workaround > because on shortcomings in AIX's mprotect(). This code will get called > during initialization before stub routines are set up. > Note that right now, in the OpenJDK code base, the code still directly > checks whether the stubroutine is NULL, because that mprotect workaround > is older than 8074552. But I planned to change this to > CanUseSafeFetch(). But with the new CanUseSafeFetch, this would just > break AIX. > > 2) In SAPs code base, we also use it to harden error log writing (e.g. > to make callstack dumping more reliable). This may can be invoked very > early, if a crash happens very early, before stub routines are > available. We planned to contribute those improvements piece by piece to > the OpenJDK - my first change for 8074552 was actually supposed to > prepare that. Now, however, this makes no sense, because using > SafeFetch() to harden error log writing would actually be worse for > error logs for early crashes. > > SafeFetch is a very basic function which could be useful in many more > contexts, but only if you can really be sure it is safe. The contexts it > is used in may be very low level where you cannot be sure at which point > in VM initialization you are. > > When I introduced CanUseSafeFetch(), it was to safeguard the use of > SafeFetch() for situations where SafeFetch was not safe to call. Exactly > so that I would have not to think about "is this too early to use > SafeFetch()?". This is broken now - instead of guarding me against using > SafeFetch() in situations where it is not safe to use, it will > assert(debug) or potentially lie(release), in which case SafeFetch > itself may crash. Okay I see a case for adding a check for "can I use SafeFetch at this point in time" (though if what you are fetching is potentially not-safe then you are in trouble!). > So now > - CanUseSafeFetch really now means "SafeFetch will behave as > excpected" > - SafeFetch is softened to "will safely fetch content of address > unless on zero, there it may crash the VM". > > I think this is more confusing than before. In objectMonitor, > the logic > we want is "use SafeFetch wherever possible but if not, just > access the > memory directly". This logic now is hidden behind a seemingly > incorrect > use of SafeFetch without CanUseSafeFetch, and I think Goetz proposal > would have been far more clearer. > > > No the problem is that SafeFetch doesn't work on ZERO - if you give > it a bad address it won't recover it will crash. The whole point is > for it not to crash. The objectMonitor code is saying "here is a > load that we know may be invalid, but if it is then we don't want to > crash, so we use SafeFetch". > > > Yes! But the way it is coded, it does not. Because SafeFetch is now > implemented on zero with a simple load, it is not safe at all. The code > in objectMonitor.cpp appears to be safe, but it is not. And SafeFetch() > promises to be safe, but it is not, and you would not know unless you > know the zero implementation. Sorry did I miss something - has Zero ever implemented SafeFetch as other than a direct simple load? ie hasn't Zero always been broken wrt SafeFetch and that is the basic problem ? > It seems to be a bit inconsequent. Either one is really sure the pointer > is accessible - in which case why use SafeFetch? - or it may be invalid, > even if this is unusual - in which case why is the resulting crash not a > problem for zero? > In other words, if the original programmer thought it worth to guard the > memory access with SafeFetch(), why is this not a concern for zero? It is - which is why Zero is broken. > The expectation is that SafeFetch actually is safe no matter what is > fetched. > > > Yes, and that expectation is broken now. When was it not broken? > Before, if you used SafeFetch() and guarded it with CanUseSafeFetch(), > you could be sure to be safe and not to break anything - regardless when > in VM life you used the function or on which platform. No you only knew that a function called SafeFetch could be called - you didn't know it was actually implemented to actually always do a "safe fetch". > Both SafeFetch and CanUseSafeFetch made promises: > - CanUseSafeFetch promised to tell me if it is too early to call > SafeFetch. Of course, it itself could be called at all times, that was > the whole point of CanUseSafeFetch. > - SafeFetch promised to be able to access a potentially invalid pointer > and not to crash - if CanUseSafeFetch returned true. SafeFetch (if it exists) promises to be safe. The ZERO implementation breaks that. > Both promises are broken now. CanUseSafeFetch is not safe to call if it > is too early - ironically a condition it was designed to tell me. Okay we will re-fix that. > SafeFetch is not safe to call because it lies about being safe for zero. It never was safe to call as far as I can see, it was just never called with an invalid value. The new test exposed this. David ----- > The result is that either if we continue to use SafeFetch, we risk > crashes on zero and crashes if invoked too early. This makes the API > useless for most cases. > > I am open to any other suggestions - renaming the APIs, maybe reshaping > them - but I regret seeing SafeFetch being back to being quite unsafe again. > > Kind Regards, Thomas > > > The ZERO implementation just does a load and hopes it isn't asked > for anything bad. The objectMonitor code will rarely actually > trigger a bad load. But the newly introduced test does. > > So in my opinion to return to the status-quo where ZERO really > doesn't implement SafeFetch safely but it "works okay in practice", > we should disable those explicit tests when running on ZERO. > > Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is > implemented explicitly or implicitly as an assert is a side-issue. > > David > > Kind Regards, Thomas > > > > > > > > On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz > > >> wrote: > > Hi, > > sorry I only comment on this now ... > I think it's rather strange that you can not use SafeFetch > on zero, > but it's there, > and it's actually used ... which will be the situation > after this > change. > > Why not just change objectMonitor as the SafeFetch api is > meant to > be used? > Obviously zero takes care that this access always succeeds: > > diff -r a35854c84d9d src/share/vm/runtime/__objectMonitor.cpp > --- a/src/share/vm/runtime/__objectMonitor.cpp Wed Mar > 25 12:36:28 > 2015 +0100 > +++ b/src/share/vm/runtime/__objectMonitor.cpp Thu Mar > 26 08:19:53 > 2015 +0100 > @@ -2241,7 +2241,12 @@ > } > > assert(sizeof(((JavaThread *)ox)->_thread_state == > sizeof(int)), > "invariant"); > - int jst = SafeFetch32((int *) &((JavaThread *) > ox)->_thread_state, -1);; > + int jst; > + if (CanUseSafeFetch32()) { > + jst = SafeFetch32((int *) &((JavaThread *) > ox)->_thread_state, -1); > + } else { > + jst = ((JavaThread *)ox)->_thread_state; > + } > // consider also: jst != _thread_in_Java -- but that's > overspecific. > return jst == _thread_blocked || jst == _thread_in_native; > } > > It's handled similarly in vmError.cpp. And no #ifdefs ;) > > But I'm also fine with the other change ... to get zero > working again. > > Best regards, > Goetz. > > > > -----Original Message----- > From: hotspot-dev > [mailto:hotspot-dev-bounces at __openjdk.java.net > > >] On Behalf Of Coleen > Phillimore > Sent: Thursday, March 26, 2015 3:30 AM > To: David Holmes; hotspot-dev developers > Subject: Re: RFR (xs) 8075967: Zero interpreter asserts for > SafeFetch<32, N> calls in ObjectMonitor > > > On 3/25/15, 10:15 PM, David Holmes wrote: > > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: > >> > >> On 3/25/15, 8:21 PM, David Holmes wrote: > >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: > >>>> > >>>> On 3/25/15, 7:59 PM, David Holmes wrote: > >>>>> Hi Coleen, > >>>>> > >>>>> Why generate stubs that can't be used and then add > zero-specific > >>>>> logic > >>>>> to the shared CanUseSafeFetchN instead of not > generating the > stubs so > >>>>> that CanUseSafeFetchN will return false anyway ?? > >>>> > >>>> Because there is platform independent code in > objectMonitor.cpp that > >>>> uses SafeFetchX (both). I'd rather not burden the > caller of > this with > >>>> testing CanUseSafeFetchX for each call. This code > existed before > >>>> SafeFetch was implemented, so I'm restoring previous > behavior for > >>>> Zero. > >>> > >>> Sorry Coleen I thought this was deal to with 8075533, > I hadn't > >>> realized 8075533 broke the objectMonitor code and this > was a > follow up. > >>> > >>> What a mess. :( > >> > >> Yes, it is. Is this a code Review? > > > > Let me work through this :) The original change for 8074552: > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__3eb61269f421 > > > > > added the extra error handling stuff related to > SafeFetch and a new > > ErrorHandler test that was predicated on > CanUseSafeFetch32 which > > returns true if the stubs exist. It also added testing of > SafeFetch in > > StubRoutines::initialize2 which was excluded for > windows-32-bit and > > which did not check CanUseSafeFetch32. > > > > That change broke zero as reported in 8075533 because > you can't > > actually use the SafeFetch routines with an unsafe > address on Zero, > > and the solution: > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__5c2bc6278fc4 > > > > > was to remove the stubs so that CanUseSafeFetch32 would > return false, > > and to include a check of CanUseSafeFetch32 in the tests > used with > > StubRoutines::initialize2. > > > > And now we find that the SafeFetch routines are used > unconditionally > > by the objectMonitor code, so we need to restore the > stubs that were > > previously removed, but force CanUseSafeFetch32 to > return false > on zero. > > Yes, exactly. > > > > Ok. Only nit is that: > > > > return NOT_ZERO(true) ZERO_ONLY(false); > > Yes, you're right. I'll make that change. > > Thanks! > Coleen > > > > > would be more readable than the ifdefs. > > > > Thanks, > > David > > > >> thanks! > >> Coleen > >>> > >>> Thanks, > >>> David > >>> > >>> > >>> > >>>> We could file an RFE to either implement SafeFetch > for Zero or > rewrite > >>>> this objectMonitor code to not need SafeFetch. I > didn't want > to do > >>>> either of these things with this patch. > >>>> > >>>> Coleen > >>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: > >>>>>> Summary: Implement SafeFetchX unsafely and make > CanUseSafeFetchX > >>>>>> false > >>>>>> for Zero > >>>>>> > >>>>>> Also, this fixes a couple other minor issues. > >>>>>> > >>>>>> Ran jdk9 jck tests with one timeout. > hotspot/runtime jtreg > tests > >>>>>> don't > >>>>>> run because Zero doesn't support UseCompressedOops > (not sure > why) > >>>>>> and > >>>>>> CDS (know why). > >>>>>> > >>>>>> open webrev at > http://cr.openjdk.java.net/~__coleenp/8075967/ > > >>>>>> bug link > https://bugs.openjdk.java.net/__browse/JDK-8075967 > > >>>>>> > >>>>>> Thanks, > >>>>>> Coleen > >>>> > >> > > > From sgehwolf at redhat.com Thu Mar 26 13:00:25 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 26 Mar 2015 14:00:25 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <5513FDAE.4010608@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> Message-ID: <1427374825.3339.62.camel@redhat.com> Hi, On Thu, 2015-03-26 at 22:38 +1000, David Holmes wrote: > On 26/03/2015 10:24 PM, Thomas St?fe wrote: > > Hi David, > > > > On Thu, Mar 26, 2015 at 11:42 AM, David Holmes > > wrote: > > > > Hi Thomas, > > > > On 26/03/2015 6:35 PM, Thomas St?fe wrote: > > > > Hi, > > > > I agree with Goetz. > > > > SafeFetch() was meant to be guarded with CanUseSafeFetch(), this > > is part > > of the contract, so using it without this guard is actually > > incorrect > > and would crash were the calling code ever called before Stub > > routine > > initialization. > > > > > > That contract was already implicit - this API is for use after the > > stubs have been generated. There's no reason to expand the use of > > this API to situations before stubs are generated. So the assert > > captures that and CanUseSafeFetch is really unnecessary. > > > > > > We had to introduce CanUseSafeFetch() exactly because we have situations > > where we may call SafeFetch before stub routine generation: > > > > 1) In os_aix.cpp, we use it to probe protected memory after doing > > mprotect(). This is a long story, but we had to add this workaround > > because on shortcomings in AIX's mprotect(). This code will get called > > during initialization before stub routines are set up. > > Note that right now, in the OpenJDK code base, the code still directly > > checks whether the stubroutine is NULL, because that mprotect workaround > > is older than 8074552. But I planned to change this to > > CanUseSafeFetch(). But with the new CanUseSafeFetch, this would just > > break AIX. > > > > 2) In SAPs code base, we also use it to harden error log writing (e.g. > > to make callstack dumping more reliable). This may can be invoked very > > early, if a crash happens very early, before stub routines are > > available. We planned to contribute those improvements piece by piece to > > the OpenJDK - my first change for 8074552 was actually supposed to > > prepare that. Now, however, this makes no sense, because using > > SafeFetch() to harden error log writing would actually be worse for > > error logs for early crashes. > > > > SafeFetch is a very basic function which could be useful in many more > > contexts, but only if you can really be sure it is safe. The contexts it > > is used in may be very low level where you cannot be sure at which point > > in VM initialization you are. > > > > When I introduced CanUseSafeFetch(), it was to safeguard the use of > > SafeFetch() for situations where SafeFetch was not safe to call. Exactly > > so that I would have not to think about "is this too early to use > > SafeFetch()?". This is broken now - instead of guarding me against using > > SafeFetch() in situations where it is not safe to use, it will > > assert(debug) or potentially lie(release), in which case SafeFetch > > itself may crash. > > Okay I see a case for adding a check for "can I use SafeFetch at this > point in time" (though if what you are fetching is potentially not-safe > then you are in trouble!). > > > So now > > - CanUseSafeFetch really now means "SafeFetch will behave as > > excpected" > > - SafeFetch is softened to "will safely fetch content of address > > unless on zero, there it may crash the VM". > > > > I think this is more confusing than before. In objectMonitor, > > the logic > > we want is "use SafeFetch wherever possible but if not, just > > access the > > memory directly". This logic now is hidden behind a seemingly > > incorrect > > use of SafeFetch without CanUseSafeFetch, and I think Goetz proposal > > would have been far more clearer. > > > > > > No the problem is that SafeFetch doesn't work on ZERO - if you give > > it a bad address it won't recover it will crash. The whole point is > > for it not to crash. The objectMonitor code is saying "here is a > > load that we know may be invalid, but if it is then we don't want to > > crash, so we use SafeFetch". > > > > > > Yes! But the way it is coded, it does not. Because SafeFetch is now > > implemented on zero with a simple load, it is not safe at all. The code > > in objectMonitor.cpp appears to be safe, but it is not. And SafeFetch() > > promises to be safe, but it is not, and you would not know unless you > > know the zero implementation. > > Sorry did I miss something - has Zero ever implemented SafeFetch as > other than a direct simple load? ie hasn't Zero always been broken wrt > SafeFetch and that is the basic problem ? Yes, Zero's implementation was broken before and that's the basic problem. By re-introducing SafeFetch for Zero with the old code, that part of the code is of course not fixed. Here is the dilemma, though, how would a correct SafeFetch implementation for Zero look like? It *cannot* use ucontext's mcontext as this gets us into machine dependent code and a Zero JVM may be compiled on any architecture where there is a GCC (e.g. arm32, ppc32). That's the whole point of Zero: To get a JVM on an architecture where there is no JIT port. What's more, those architectures where Zero might get compiled on are not known ahead of time. > > It seems to be a bit inconsequent. Either one is really sure the pointer > > is accessible - in which case why use SafeFetch? - or it may be invalid, > > even if this is unusual - in which case why is the resulting crash not a > > problem for zero? > > In other words, if the original programmer thought it worth to guard the > > memory access with SafeFetch(), why is this not a concern for zero? > > It is - which is why Zero is broken. > > > The expectation is that SafeFetch actually is safe no matter what is > > fetched. > > > > > > Yes, and that expectation is broken now. > > When was it not broken? > > > Before, if you used SafeFetch() and guarded it with CanUseSafeFetch(), > > you could be sure to be safe and not to break anything - regardless when > > in VM life you used the function or on which platform. > > No you only knew that a function called SafeFetch could be called - you > didn't know it was actually implemented to actually always do a "safe > fetch". > > > Both SafeFetch and CanUseSafeFetch made promises: > > - CanUseSafeFetch promised to tell me if it is too early to call > > SafeFetch. Of course, it itself could be called at all times, that was > > the whole point of CanUseSafeFetch. > > - SafeFetch promised to be able to access a potentially invalid pointer > > and not to crash - if CanUseSafeFetch returned true. > > SafeFetch (if it exists) promises to be safe. The ZERO implementation > breaks that. > > > Both promises are broken now. CanUseSafeFetch is not safe to call if it > > is too early - ironically a condition it was designed to tell me. > > Okay we will re-fix that. > > > SafeFetch is not safe to call because it lies about being safe for zero. > > It never was safe to call as far as I can see, it was just never called > with an invalid value. The new test exposed this. I think the problem right now is that the current implementation of CanUseSafeFetch can no longer be called unconditionally at any point in time of JVM init on NotZero() JVMs. Cheers, Severin > David > ----- > > > The result is that either if we continue to use SafeFetch, we risk > > crashes on zero and crashes if invoked too early. This makes the API > > useless for most cases. > > > > I am open to any other suggestions - renaming the APIs, maybe reshaping > > them - but I regret seeing SafeFetch being back to being quite unsafe again. > > > > Kind Regards, Thomas > > > > > > The ZERO implementation just does a load and hopes it isn't asked > > for anything bad. The objectMonitor code will rarely actually > > trigger a bad load. But the newly introduced test does. > > > > So in my opinion to return to the status-quo where ZERO really > > doesn't implement SafeFetch safely but it "works okay in practice", > > we should disable those explicit tests when running on ZERO. > > > > Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is > > implemented explicitly or implicitly as an assert is a side-issue. > > > > David > > > > Kind Regards, Thomas > > > > > > > > > > > > > > > > On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz > > > > > >> wrote: > > > > Hi, > > > > sorry I only comment on this now ... > > I think it's rather strange that you can not use SafeFetch > > on zero, > > but it's there, > > and it's actually used ... which will be the situation > > after this > > change. > > > > Why not just change objectMonitor as the SafeFetch api is > > meant to > > be used? > > Obviously zero takes care that this access always succeeds: > > > > diff -r a35854c84d9d src/share/vm/runtime/__objectMonitor.cpp > > --- a/src/share/vm/runtime/__objectMonitor.cpp Wed Mar > > 25 12:36:28 > > 2015 +0100 > > +++ b/src/share/vm/runtime/__objectMonitor.cpp Thu Mar > > 26 08:19:53 > > 2015 +0100 > > @@ -2241,7 +2241,12 @@ > > } > > > > assert(sizeof(((JavaThread *)ox)->_thread_state == > > sizeof(int)), > > "invariant"); > > - int jst = SafeFetch32((int *) &((JavaThread *) > > ox)->_thread_state, -1);; > > + int jst; > > + if (CanUseSafeFetch32()) { > > + jst = SafeFetch32((int *) &((JavaThread *) > > ox)->_thread_state, -1); > > + } else { > > + jst = ((JavaThread *)ox)->_thread_state; > > + } > > // consider also: jst != _thread_in_Java -- but that's > > overspecific. > > return jst == _thread_blocked || jst == _thread_in_native; > > } > > > > It's handled similarly in vmError.cpp. And no #ifdefs ;) > > > > But I'm also fine with the other change ... to get zero > > working again. > > > > Best regards, > > Goetz. > > > > > > > > -----Original Message----- > > From: hotspot-dev > > [mailto:hotspot-dev-bounces at __openjdk.java.net > > > > > >] On Behalf Of Coleen > > Phillimore > > Sent: Thursday, March 26, 2015 3:30 AM > > To: David Holmes; hotspot-dev developers > > Subject: Re: RFR (xs) 8075967: Zero interpreter asserts for > > SafeFetch<32, N> calls in ObjectMonitor > > > > > > On 3/25/15, 10:15 PM, David Holmes wrote: > > > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: > > >> > > >> On 3/25/15, 8:21 PM, David Holmes wrote: > > >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: > > >>>> > > >>>> On 3/25/15, 7:59 PM, David Holmes wrote: > > >>>>> Hi Coleen, > > >>>>> > > >>>>> Why generate stubs that can't be used and then add > > zero-specific > > >>>>> logic > > >>>>> to the shared CanUseSafeFetchN instead of not > > generating the > > stubs so > > >>>>> that CanUseSafeFetchN will return false anyway ?? > > >>>> > > >>>> Because there is platform independent code in > > objectMonitor.cpp that > > >>>> uses SafeFetchX (both). I'd rather not burden the > > caller of > > this with > > >>>> testing CanUseSafeFetchX for each call. This code > > existed before > > >>>> SafeFetch was implemented, so I'm restoring previous > > behavior for > > >>>> Zero. > > >>> > > >>> Sorry Coleen I thought this was deal to with 8075533, > > I hadn't > > >>> realized 8075533 broke the objectMonitor code and this > > was a > > follow up. > > >>> > > >>> What a mess. :( > > >> > > >> Yes, it is. Is this a code Review? > > > > > > Let me work through this :) The original change for 8074552: > > > > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__3eb61269f421 > > > > > > > > added the extra error handling stuff related to > > SafeFetch and a new > > > ErrorHandler test that was predicated on > > CanUseSafeFetch32 which > > > returns true if the stubs exist. It also added testing of > > SafeFetch in > > > StubRoutines::initialize2 which was excluded for > > windows-32-bit and > > > which did not check CanUseSafeFetch32. > > > > > > That change broke zero as reported in 8075533 because > > you can't > > > actually use the SafeFetch routines with an unsafe > > address on Zero, > > > and the solution: > > > > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__5c2bc6278fc4 > > > > > > > > was to remove the stubs so that CanUseSafeFetch32 would > > return false, > > > and to include a check of CanUseSafeFetch32 in the tests > > used with > > > StubRoutines::initialize2. > > > > > > And now we find that the SafeFetch routines are used > > unconditionally > > > by the objectMonitor code, so we need to restore the > > stubs that were > > > previously removed, but force CanUseSafeFetch32 to > > return false > > on zero. > > > > Yes, exactly. > > > > > > Ok. Only nit is that: > > > > > > return NOT_ZERO(true) ZERO_ONLY(false); > > > > Yes, you're right. I'll make that change. > > > > Thanks! > > Coleen > > > > > > > > would be more readable than the ifdefs. > > > > > > Thanks, > > > David > > > > > >> thanks! > > >> Coleen > > >>> > > >>> Thanks, > > >>> David > > >>> > > >>> > > >>> > > >>>> We could file an RFE to either implement SafeFetch > > for Zero or > > rewrite > > >>>> this objectMonitor code to not need SafeFetch. I > > didn't want > > to do > > >>>> either of these things with this patch. > > >>>> > > >>>> Coleen > > >>>> > > >>>>> > > >>>>> Thanks, > > >>>>> David > > >>>>> > > >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: > > >>>>>> Summary: Implement SafeFetchX unsafely and make > > CanUseSafeFetchX > > >>>>>> false > > >>>>>> for Zero > > >>>>>> > > >>>>>> Also, this fixes a couple other minor issues. > > >>>>>> > > >>>>>> Ran jdk9 jck tests with one timeout. > > hotspot/runtime jtreg > > tests > > >>>>>> don't > > >>>>>> run because Zero doesn't support UseCompressedOops > > (not sure > > why) > > >>>>>> and > > >>>>>> CDS (know why). > > >>>>>> > > >>>>>> open webrev at > > http://cr.openjdk.java.net/~__coleenp/8075967/ > > > > >>>>>> bug link > > https://bugs.openjdk.java.net/__browse/JDK-8075967 > > > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Coleen > > >>>> > > >> > > > > > > From roland.westrelin at oracle.com Thu Mar 26 13:33:45 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 26 Mar 2015 14:33:45 +0100 Subject: RFR(S): 8007986: GrowableArray should implement binary search Message-ID: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> http://cr.openjdk.java.net/~roland/8007986/webrev.00/ The same binary search code on GrowableArray is used in 3 places (in the compilers). This moves that code in GrowableArray. Roland. From thomas.stuefe at gmail.com Thu Mar 26 13:37:34 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Mar 2015 14:37:34 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <1427374825.3339.62.camel@redhat.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> <1427374825.3339.62.camel@redhat.com> Message-ID: Hi Severin, I think a CanUseSafeFetch() which returns false on zero but which could be always called unconditionally would be fine. The user would have to guard SafeFetch() with CanUseSafeFetch() and think about what to do if SafeFetch() was not available. On Zero, for POSIX platforms one could implement SafeFetch with setjmp()/longjmp(). Before accessing the potentially invalid pointer, do a setjmp() and in the signal handler a longjmp() back to SafeFetch(). This would have to be threadsafe - by keeping the jmp_buf thread local or just by synchronizing access to SafeFetch(). For Zero on windows, it would be very easy, just guard SafeFetch with __try/__catch. ..Thomas On Thu, Mar 26, 2015 at 2:00 PM, Severin Gehwolf wrote: > Hi, > > On Thu, 2015-03-26 at 22:38 +1000, David Holmes wrote: > > On 26/03/2015 10:24 PM, Thomas St?fe wrote: > > > Hi David, > > > > > > On Thu, Mar 26, 2015 at 11:42 AM, David Holmes < > david.holmes at oracle.com > > > > wrote: > > > > > > Hi Thomas, > > > > > > On 26/03/2015 6:35 PM, Thomas St?fe wrote: > > > > > > Hi, > > > > > > I agree with Goetz. > > > > > > SafeFetch() was meant to be guarded with CanUseSafeFetch(), > this > > > is part > > > of the contract, so using it without this guard is actually > > > incorrect > > > and would crash were the calling code ever called before Stub > > > routine > > > initialization. > > > > > > > > > That contract was already implicit - this API is for use after the > > > stubs have been generated. There's no reason to expand the use of > > > this API to situations before stubs are generated. So the assert > > > captures that and CanUseSafeFetch is really unnecessary. > > > > > > > > > We had to introduce CanUseSafeFetch() exactly because we have > situations > > > where we may call SafeFetch before stub routine generation: > > > > > > 1) In os_aix.cpp, we use it to probe protected memory after doing > > > mprotect(). This is a long story, but we had to add this workaround > > > because on shortcomings in AIX's mprotect(). This code will get called > > > during initialization before stub routines are set up. > > > Note that right now, in the OpenJDK code base, the code still directly > > > checks whether the stubroutine is NULL, because that mprotect > workaround > > > is older than 8074552. But I planned to change this to > > > CanUseSafeFetch(). But with the new CanUseSafeFetch, this would just > > > break AIX. > > > > > > 2) In SAPs code base, we also use it to harden error log writing (e.g. > > > to make callstack dumping more reliable). This may can be invoked very > > > early, if a crash happens very early, before stub routines are > > > available. We planned to contribute those improvements piece by piece > to > > > the OpenJDK - my first change for 8074552 was actually supposed to > > > prepare that. Now, however, this makes no sense, because using > > > SafeFetch() to harden error log writing would actually be worse for > > > error logs for early crashes. > > > > > > SafeFetch is a very basic function which could be useful in many more > > > contexts, but only if you can really be sure it is safe. The contexts > it > > > is used in may be very low level where you cannot be sure at which > point > > > in VM initialization you are. > > > > > > When I introduced CanUseSafeFetch(), it was to safeguard the use of > > > SafeFetch() for situations where SafeFetch was not safe to call. > Exactly > > > so that I would have not to think about "is this too early to use > > > SafeFetch()?". This is broken now - instead of guarding me against > using > > > SafeFetch() in situations where it is not safe to use, it will > > > assert(debug) or potentially lie(release), in which case SafeFetch > > > itself may crash. > > > > Okay I see a case for adding a check for "can I use SafeFetch at this > > point in time" (though if what you are fetching is potentially not-safe > > then you are in trouble!). > > > > > So now > > > - CanUseSafeFetch really now means "SafeFetch will behave as > > > excpected" > > > - SafeFetch is softened to "will safely fetch content of > address > > > unless on zero, there it may crash the VM". > > > > > > I think this is more confusing than before. In objectMonitor, > > > the logic > > > we want is "use SafeFetch wherever possible but if not, just > > > access the > > > memory directly". This logic now is hidden behind a seemingly > > > incorrect > > > use of SafeFetch without CanUseSafeFetch, and I think Goetz > proposal > > > would have been far more clearer. > > > > > > > > > No the problem is that SafeFetch doesn't work on ZERO - if you give > > > it a bad address it won't recover it will crash. The whole point is > > > for it not to crash. The objectMonitor code is saying "here is a > > > load that we know may be invalid, but if it is then we don't want > to > > > crash, so we use SafeFetch". > > > > > > > > > Yes! But the way it is coded, it does not. Because SafeFetch is now > > > implemented on zero with a simple load, it is not safe at all. The code > > > in objectMonitor.cpp appears to be safe, but it is not. And SafeFetch() > > > promises to be safe, but it is not, and you would not know unless you > > > know the zero implementation. > > > > Sorry did I miss something - has Zero ever implemented SafeFetch as > > other than a direct simple load? ie hasn't Zero always been broken wrt > > SafeFetch and that is the basic problem ? > > Yes, Zero's implementation was broken before and that's the basic > problem. By re-introducing SafeFetch for Zero with the old code, that > part of the code is of course not fixed. > > Here is the dilemma, though, how would a correct SafeFetch > implementation for Zero look like? It *cannot* use ucontext's mcontext > as this gets us into machine dependent code and a Zero JVM may be > compiled on any architecture where there is a GCC (e.g. arm32, ppc32). > That's the whole point of Zero: To get a JVM on an architecture where > there is no JIT port. What's more, those architectures where Zero might > get compiled on are not known ahead of time. > > > > It seems to be a bit inconsequent. Either one is really sure the > pointer > > > is accessible - in which case why use SafeFetch? - or it may be > invalid, > > > even if this is unusual - in which case why is the resulting crash not > a > > > problem for zero? > > > In other words, if the original programmer thought it worth to guard > the > > > memory access with SafeFetch(), why is this not a concern for zero? > > > > It is - which is why Zero is broken. > > > > > The expectation is that SafeFetch actually is safe no matter what > is > > > fetched. > > > > > > > > > Yes, and that expectation is broken now. > > > > When was it not broken? > > > > > Before, if you used SafeFetch() and guarded it with CanUseSafeFetch(), > > > you could be sure to be safe and not to break anything - regardless > when > > > in VM life you used the function or on which platform. > > > > No you only knew that a function called SafeFetch could be called - you > > didn't know it was actually implemented to actually always do a "safe > > fetch". > > > > > Both SafeFetch and CanUseSafeFetch made promises: > > > - CanUseSafeFetch promised to tell me if it is too early to call > > > SafeFetch. Of course, it itself could be called at all times, that was > > > the whole point of CanUseSafeFetch. > > > - SafeFetch promised to be able to access a potentially invalid pointer > > > and not to crash - if CanUseSafeFetch returned true. > > > > SafeFetch (if it exists) promises to be safe. The ZERO implementation > > breaks that. > > > > > Both promises are broken now. CanUseSafeFetch is not safe to call if it > > > is too early - ironically a condition it was designed to tell me. > > > > Okay we will re-fix that. > > > > > SafeFetch is not safe to call because it lies about being safe for > zero. > > > > It never was safe to call as far as I can see, it was just never called > > with an invalid value. The new test exposed this. > > I think the problem right now is that the current implementation of > CanUseSafeFetch can no longer be called unconditionally at any point in > time of JVM init on NotZero() JVMs. > > Cheers, > Severin > > > David > > ----- > > > > > The result is that either if we continue to use SafeFetch, we risk > > > crashes on zero and crashes if invoked too early. This makes the API > > > useless for most cases. > > > > > > I am open to any other suggestions - renaming the APIs, maybe reshaping > > > them - but I regret seeing SafeFetch being back to being quite unsafe > again. > > > > > > Kind Regards, Thomas > > > > > > > > > The ZERO implementation just does a load and hopes it isn't asked > > > for anything bad. The objectMonitor code will rarely actually > > > trigger a bad load. But the newly introduced test does. > > > > > > So in my opinion to return to the status-quo where ZERO really > > > doesn't implement SafeFetch safely but it "works okay in practice", > > > we should disable those explicit tests when running on ZERO. > > > > > > Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is > > > implemented explicitly or implicitly as an assert is a side-issue. > > > > > > David > > > > > > Kind Regards, Thomas > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz > > > > > > > > >> wrote: > > > > > > Hi, > > > > > > sorry I only comment on this now ... > > > I think it's rather strange that you can not use SafeFetch > > > on zero, > > > but it's there, > > > and it's actually used ... which will be the situation > > > after this > > > change. > > > > > > Why not just change objectMonitor as the SafeFetch api is > > > meant to > > > be used? > > > Obviously zero takes care that this access always > succeeds: > > > > > > diff -r a35854c84d9d > src/share/vm/runtime/__objectMonitor.cpp > > > --- a/src/share/vm/runtime/__objectMonitor.cpp Wed Mar > > > 25 12:36:28 > > > 2015 +0100 > > > +++ b/src/share/vm/runtime/__objectMonitor.cpp Thu Mar > > > 26 08:19:53 > > > 2015 +0100 > > > @@ -2241,7 +2241,12 @@ > > > } > > > > > > assert(sizeof(((JavaThread *)ox)->_thread_state == > > > sizeof(int)), > > > "invariant"); > > > - int jst = SafeFetch32((int *) &((JavaThread *) > > > ox)->_thread_state, -1);; > > > + int jst; > > > + if (CanUseSafeFetch32()) { > > > + jst = SafeFetch32((int *) &((JavaThread *) > > > ox)->_thread_state, -1); > > > + } else { > > > + jst = ((JavaThread *)ox)->_thread_state; > > > + } > > > // consider also: jst != _thread_in_Java -- but that's > > > overspecific. > > > return jst == _thread_blocked || jst == > _thread_in_native; > > > } > > > > > > It's handled similarly in vmError.cpp. And no #ifdefs ;) > > > > > > But I'm also fine with the other change ... to get zero > > > working again. > > > > > > Best regards, > > > Goetz. > > > > > > > > > > > > -----Original Message----- > > > From: hotspot-dev > > > [mailto:hotspot-dev-bounces at __openjdk.java.net > > > > > > > > >] On Behalf Of > Coleen > > > Phillimore > > > Sent: Thursday, March 26, 2015 3:30 AM > > > To: David Holmes; hotspot-dev developers > > > Subject: Re: RFR (xs) 8075967: Zero interpreter asserts > for > > > SafeFetch<32, N> calls in ObjectMonitor > > > > > > > > > On 3/25/15, 10:15 PM, David Holmes wrote: > > > > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: > > > >> > > > >> On 3/25/15, 8:21 PM, David Holmes wrote: > > > >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: > > > >>>> > > > >>>> On 3/25/15, 7:59 PM, David Holmes wrote: > > > >>>>> Hi Coleen, > > > >>>>> > > > >>>>> Why generate stubs that can't be used and then add > > > zero-specific > > > >>>>> logic > > > >>>>> to the shared CanUseSafeFetchN instead of not > > > generating the > > > stubs so > > > >>>>> that CanUseSafeFetchN will return false anyway ?? > > > >>>> > > > >>>> Because there is platform independent code in > > > objectMonitor.cpp that > > > >>>> uses SafeFetchX (both). I'd rather not burden the > > > caller of > > > this with > > > >>>> testing CanUseSafeFetchX for each call. This code > > > existed before > > > >>>> SafeFetch was implemented, so I'm restoring previous > > > behavior for > > > >>>> Zero. > > > >>> > > > >>> Sorry Coleen I thought this was deal to with 8075533, > > > I hadn't > > > >>> realized 8075533 broke the objectMonitor code and > this > > > was a > > > follow up. > > > >>> > > > >>> What a mess. :( > > > >> > > > >> Yes, it is. Is this a code Review? > > > > > > > > Let me work through this :) The original change for > 8074552: > > > > > > > > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__3eb61269f421 > > > < > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421> > > > > > > > > added the extra error handling stuff related to > > > SafeFetch and a new > > > > ErrorHandler test that was predicated on > > > CanUseSafeFetch32 which > > > > returns true if the stubs exist. It also added testing > of > > > SafeFetch in > > > > StubRoutines::initialize2 which was excluded for > > > windows-32-bit and > > > > which did not check CanUseSafeFetch32. > > > > > > > > That change broke zero as reported in 8075533 because > > > you can't > > > > actually use the SafeFetch routines with an unsafe > > > address on Zero, > > > > and the solution: > > > > > > > > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__5c2bc6278fc4 > > > < > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5c2bc6278fc4> > > > > > > > > was to remove the stubs so that CanUseSafeFetch32 would > > > return false, > > > > and to include a check of CanUseSafeFetch32 in the > tests > > > used with > > > > StubRoutines::initialize2. > > > > > > > > And now we find that the SafeFetch routines are used > > > unconditionally > > > > by the objectMonitor code, so we need to restore the > > > stubs that were > > > > previously removed, but force CanUseSafeFetch32 to > > > return false > > > on zero. > > > > > > Yes, exactly. > > > > > > > > Ok. Only nit is that: > > > > > > > > return NOT_ZERO(true) ZERO_ONLY(false); > > > > > > Yes, you're right. I'll make that change. > > > > > > Thanks! > > > Coleen > > > > > > > > > > > would be more readable than the ifdefs. > > > > > > > > Thanks, > > > > David > > > > > > > >> thanks! > > > >> Coleen > > > >>> > > > >>> Thanks, > > > >>> David > > > >>> > > > >>> > > > >>> > > > >>>> We could file an RFE to either implement SafeFetch > > > for Zero or > > > rewrite > > > >>>> this objectMonitor code to not need SafeFetch. I > > > didn't want > > > to do > > > >>>> either of these things with this patch. > > > >>>> > > > >>>> Coleen > > > >>>> > > > >>>>> > > > >>>>> Thanks, > > > >>>>> David > > > >>>>> > > > >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: > > > >>>>>> Summary: Implement SafeFetchX unsafely and make > > > CanUseSafeFetchX > > > >>>>>> false > > > >>>>>> for Zero > > > >>>>>> > > > >>>>>> Also, this fixes a couple other minor issues. > > > >>>>>> > > > >>>>>> Ran jdk9 jck tests with one timeout. > > > hotspot/runtime jtreg > > > tests > > > >>>>>> don't > > > >>>>>> run because Zero doesn't support UseCompressedOops > > > (not sure > > > why) > > > >>>>>> and > > > >>>>>> CDS (know why). > > > >>>>>> > > > >>>>>> open webrev at > > > http://cr.openjdk.java.net/~__coleenp/8075967/ > > > > > > >>>>>> bug link > > > https://bugs.openjdk.java.net/__browse/JDK-8075967 > > > > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Coleen > > > >>>> > > > >> > > > > > > > > > > > > > From vitalyd at gmail.com Thu Mar 26 13:45:38 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 26 Mar 2015 09:45:38 -0400 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> Message-ID: Hi Roland, Just a couple of notes in passing. 1) may be worthwhile to compute mid in a way that avoids possible signed overflow? I'm guessing this class is not used with sizes that large, but just a precaution. 2) perhaps store the result of calling f() in a local to avoid calling it twice? $.02 sent from my phone On Mar 26, 2015 9:34 AM, "Roland Westrelin" wrote: http://cr.openjdk.java.net/~roland/8007986/webrev.00/ The same binary search code on GrowableArray is used in 3 places (in the compilers). This moves that code in GrowableArray. Roland. From thomas.stuefe at gmail.com Thu Mar 26 13:46:39 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Mar 2015 14:46:39 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <5513FDAE.4010608@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> Message-ID: Hi David, you are right, it was also broken before. I missed that Coleen just reintroduced an earlier version of the dummy SafeFetch() implementation, sorry for that. I would be happy with a CanUseSafeFetch() which returns always false on zero and false on other platforms before stub generation. That would be always safe to call. Kind Regards, Thomas On Thu, Mar 26, 2015 at 1:38 PM, David Holmes wrote: > On 26/03/2015 10:24 PM, Thomas St?fe wrote: > >> Hi David, >> >> On Thu, Mar 26, 2015 at 11:42 AM, David Holmes > > wrote: >> >> Hi Thomas, >> >> On 26/03/2015 6:35 PM, Thomas St?fe wrote: >> >> Hi, >> >> I agree with Goetz. >> >> SafeFetch() was meant to be guarded with CanUseSafeFetch(), this >> is part >> of the contract, so using it without this guard is actually >> incorrect >> and would crash were the calling code ever called before Stub >> routine >> initialization. >> >> >> That contract was already implicit - this API is for use after the >> stubs have been generated. There's no reason to expand the use of >> this API to situations before stubs are generated. So the assert >> captures that and CanUseSafeFetch is really unnecessary. >> >> >> We had to introduce CanUseSafeFetch() exactly because we have situations >> where we may call SafeFetch before stub routine generation: >> >> 1) In os_aix.cpp, we use it to probe protected memory after doing >> mprotect(). This is a long story, but we had to add this workaround >> because on shortcomings in AIX's mprotect(). This code will get called >> during initialization before stub routines are set up. >> Note that right now, in the OpenJDK code base, the code still directly >> checks whether the stubroutine is NULL, because that mprotect workaround >> is older than 8074552. But I planned to change this to >> CanUseSafeFetch(). But with the new CanUseSafeFetch, this would just >> break AIX. >> >> 2) In SAPs code base, we also use it to harden error log writing (e.g. >> to make callstack dumping more reliable). This may can be invoked very >> early, if a crash happens very early, before stub routines are >> available. We planned to contribute those improvements piece by piece to >> the OpenJDK - my first change for 8074552 was actually supposed to >> prepare that. Now, however, this makes no sense, because using >> SafeFetch() to harden error log writing would actually be worse for >> error logs for early crashes. >> >> SafeFetch is a very basic function which could be useful in many more >> contexts, but only if you can really be sure it is safe. The contexts it >> is used in may be very low level where you cannot be sure at which point >> in VM initialization you are. >> >> When I introduced CanUseSafeFetch(), it was to safeguard the use of >> SafeFetch() for situations where SafeFetch was not safe to call. Exactly >> so that I would have not to think about "is this too early to use >> SafeFetch()?". This is broken now - instead of guarding me against using >> SafeFetch() in situations where it is not safe to use, it will >> assert(debug) or potentially lie(release), in which case SafeFetch >> itself may crash. >> > > Okay I see a case for adding a check for "can I use SafeFetch at this > point in time" (though if what you are fetching is potentially not-safe > then you are in trouble!). > > So now >> - CanUseSafeFetch really now means "SafeFetch will behave as >> excpected" >> - SafeFetch is softened to "will safely fetch content of address >> unless on zero, there it may crash the VM". >> >> I think this is more confusing than before. In objectMonitor, >> the logic >> we want is "use SafeFetch wherever possible but if not, just >> access the >> memory directly". This logic now is hidden behind a seemingly >> incorrect >> use of SafeFetch without CanUseSafeFetch, and I think Goetz >> proposal >> would have been far more clearer. >> >> >> No the problem is that SafeFetch doesn't work on ZERO - if you give >> it a bad address it won't recover it will crash. The whole point is >> for it not to crash. The objectMonitor code is saying "here is a >> load that we know may be invalid, but if it is then we don't want to >> crash, so we use SafeFetch". >> >> >> Yes! But the way it is coded, it does not. Because SafeFetch is now >> implemented on zero with a simple load, it is not safe at all. The code >> in objectMonitor.cpp appears to be safe, but it is not. And SafeFetch() >> promises to be safe, but it is not, and you would not know unless you >> know the zero implementation. >> > > Sorry did I miss something - has Zero ever implemented SafeFetch as other > than a direct simple load? ie hasn't Zero always been broken wrt SafeFetch > and that is the basic problem ? > > It seems to be a bit inconsequent. Either one is really sure the pointer >> is accessible - in which case why use SafeFetch? - or it may be invalid, >> even if this is unusual - in which case why is the resulting crash not a >> problem for zero? >> In other words, if the original programmer thought it worth to guard the >> memory access with SafeFetch(), why is this not a concern for zero? >> > > It is - which is why Zero is broken. > > The expectation is that SafeFetch actually is safe no matter what is >> fetched. >> >> >> Yes, and that expectation is broken now. >> > > When was it not broken? > > Before, if you used SafeFetch() and guarded it with CanUseSafeFetch(), >> you could be sure to be safe and not to break anything - regardless when >> in VM life you used the function or on which platform. >> > > No you only knew that a function called SafeFetch could be called - you > didn't know it was actually implemented to actually always do a "safe > fetch". > > Both SafeFetch and CanUseSafeFetch made promises: >> - CanUseSafeFetch promised to tell me if it is too early to call >> SafeFetch. Of course, it itself could be called at all times, that was >> the whole point of CanUseSafeFetch. >> - SafeFetch promised to be able to access a potentially invalid pointer >> and not to crash - if CanUseSafeFetch returned true. >> > > SafeFetch (if it exists) promises to be safe. The ZERO implementation > breaks that. > > Both promises are broken now. CanUseSafeFetch is not safe to call if it >> is too early - ironically a condition it was designed to tell me. >> > > Okay we will re-fix that. > > SafeFetch is not safe to call because it lies about being safe for zero. >> > > It never was safe to call as far as I can see, it was just never called > with an invalid value. The new test exposed this. > > David > ----- > > The result is that either if we continue to use SafeFetch, we risk >> crashes on zero and crashes if invoked too early. This makes the API >> useless for most cases. >> >> I am open to any other suggestions - renaming the APIs, maybe reshaping >> them - but I regret seeing SafeFetch being back to being quite unsafe >> again. >> >> Kind Regards, Thomas >> >> >> The ZERO implementation just does a load and hopes it isn't asked >> for anything bad. The objectMonitor code will rarely actually >> trigger a bad load. But the newly introduced test does. >> >> So in my opinion to return to the status-quo where ZERO really >> doesn't implement SafeFetch safely but it "works okay in practice", >> we should disable those explicit tests when running on ZERO. >> >> Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is >> implemented explicitly or implicitly as an assert is a side-issue. >> >> David >> >> Kind Regards, Thomas >> >> >> >> >> >> >> >> On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz >> >> > >> wrote: >> >> Hi, >> >> sorry I only comment on this now ... >> I think it's rather strange that you can not use SafeFetch >> on zero, >> but it's there, >> and it's actually used ... which will be the situation >> after this >> change. >> >> Why not just change objectMonitor as the SafeFetch api is >> meant to >> be used? >> Obviously zero takes care that this access always succeeds: >> >> diff -r a35854c84d9d src/share/vm/runtime/__ >> objectMonitor.cpp >> --- a/src/share/vm/runtime/__objectMonitor.cpp Wed Mar >> 25 12:36:28 >> 2015 +0100 >> +++ b/src/share/vm/runtime/__objectMonitor.cpp Thu Mar >> >> 26 08:19:53 >> 2015 +0100 >> @@ -2241,7 +2241,12 @@ >> } >> >> assert(sizeof(((JavaThread *)ox)->_thread_state == >> sizeof(int)), >> "invariant"); >> - int jst = SafeFetch32((int *) &((JavaThread *) >> ox)->_thread_state, -1);; >> + int jst; >> + if (CanUseSafeFetch32()) { >> + jst = SafeFetch32((int *) &((JavaThread *) >> ox)->_thread_state, -1); >> + } else { >> + jst = ((JavaThread *)ox)->_thread_state; >> + } >> // consider also: jst != _thread_in_Java -- but that's >> overspecific. >> return jst == _thread_blocked || jst == >> _thread_in_native; >> } >> >> It's handled similarly in vmError.cpp. And no #ifdefs ;) >> >> But I'm also fine with the other change ... to get zero >> working again. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: hotspot-dev >> [mailto:hotspot-dev-bounces at __openjdk.java.net >> >> > >] On Behalf Of >> Coleen >> Phillimore >> Sent: Thursday, March 26, 2015 3:30 AM >> To: David Holmes; hotspot-dev developers >> Subject: Re: RFR (xs) 8075967: Zero interpreter asserts for >> SafeFetch<32, N> calls in ObjectMonitor >> >> >> On 3/25/15, 10:15 PM, David Holmes wrote: >> > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: >> >> >> >> On 3/25/15, 8:21 PM, David Holmes wrote: >> >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: >> >>>> >> >>>> On 3/25/15, 7:59 PM, David Holmes wrote: >> >>>>> Hi Coleen, >> >>>>> >> >>>>> Why generate stubs that can't be used and then add >> zero-specific >> >>>>> logic >> >>>>> to the shared CanUseSafeFetchN instead of not >> generating the >> stubs so >> >>>>> that CanUseSafeFetchN will return false anyway ?? >> >>>> >> >>>> Because there is platform independent code in >> objectMonitor.cpp that >> >>>> uses SafeFetchX (both). I'd rather not burden the >> caller of >> this with >> >>>> testing CanUseSafeFetchX for each call. This code >> existed before >> >>>> SafeFetch was implemented, so I'm restoring previous >> behavior for >> >>>> Zero. >> >>> >> >>> Sorry Coleen I thought this was deal to with 8075533, >> I hadn't >> >>> realized 8075533 broke the objectMonitor code and this >> was a >> follow up. >> >>> >> >>> What a mess. :( >> >> >> >> Yes, it is. Is this a code Review? >> > >> > Let me work through this :) The original change for >> 8074552: >> > >> > >> http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__ >> 3eb61269f421 >> >> > >> > added the extra error handling stuff related to >> SafeFetch and a new >> > ErrorHandler test that was predicated on >> CanUseSafeFetch32 which >> > returns true if the stubs exist. It also added testing of >> SafeFetch in >> > StubRoutines::initialize2 which was excluded for >> windows-32-bit and >> > which did not check CanUseSafeFetch32. >> > >> > That change broke zero as reported in 8075533 because >> you can't >> > actually use the SafeFetch routines with an unsafe >> address on Zero, >> > and the solution: >> > >> > >> http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__ >> 5c2bc6278fc4 >> >> >> > >> > was to remove the stubs so that CanUseSafeFetch32 would >> return false, >> > and to include a check of CanUseSafeFetch32 in the tests >> used with >> > StubRoutines::initialize2. >> > >> > And now we find that the SafeFetch routines are used >> unconditionally >> > by the objectMonitor code, so we need to restore the >> stubs that were >> > previously removed, but force CanUseSafeFetch32 to >> return false >> on zero. >> >> Yes, exactly. >> > >> > Ok. Only nit is that: >> > >> > return NOT_ZERO(true) ZERO_ONLY(false); >> >> Yes, you're right. I'll make that change. >> >> Thanks! >> Coleen >> >> > >> > would be more readable than the ifdefs. >> > >> > Thanks, >> > David >> > >> >> thanks! >> >> Coleen >> >>> >> >>> Thanks, >> >>> David >> >>> >> >>> >> >>> >> >>>> We could file an RFE to either implement SafeFetch >> for Zero or >> rewrite >> >>>> this objectMonitor code to not need SafeFetch. I >> didn't want >> to do >> >>>> either of these things with this patch. >> >>>> >> >>>> Coleen >> >>>> >> >>>>> >> >>>>> Thanks, >> >>>>> David >> >>>>> >> >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >> >>>>>> Summary: Implement SafeFetchX unsafely and make >> CanUseSafeFetchX >> >>>>>> false >> >>>>>> for Zero >> >>>>>> >> >>>>>> Also, this fixes a couple other minor issues. >> >>>>>> >> >>>>>> Ran jdk9 jck tests with one timeout. >> hotspot/runtime jtreg >> tests >> >>>>>> don't >> >>>>>> run because Zero doesn't support UseCompressedOops >> (not sure >> why) >> >>>>>> and >> >>>>>> CDS (know why). >> >>>>>> >> >>>>>> open webrev at >> http://cr.openjdk.java.net/~__coleenp/8075967/ >> >> >>>>>> bug link >> https://bugs.openjdk.java.net/__browse/JDK-8075967 >> >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Coleen >> >>>> >> >> >> >> >> >> From edward.nevill at linaro.org Thu Mar 26 15:17:21 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Thu, 26 Mar 2015 15:17:21 +0000 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5513C813.1000006@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1427302783.14624.8.camel@mylittlepony.linaroharston> <5513C813.1000006@oracle.com> Message-ID: <1427383041.31932.8.camel@mylittlepony.linaroharston> On Thu, 2015-03-26 at 09:49 +0100, Zolt?n Maj? wrote: > As I mentioned earlier, I'm currently working on a patch that intends to > disable saving SP into FP on method handle invokes on x86 (JDK-8068945). > Maybe the same could be done for aarch64 as well and then you could use > both fp and r19 as "general purpose" registers. I plan to send out the > RFR this week or early next week and will let you know. Thanks. This is a nastiness that needs cleaning up. I will wait for your patch before doing anything else on this. FWIW: The benefit on aarch64 is not so much that we get an extra register but that we get an extra callee saved register for free (ie there is no cost to saving and restoring it in the callee). On entry/exit aarch64 does 'stp x29, x30, [sp, #N]' and 'ldp x29, x30, [sp, #N]' (where x29==frame pointer and x30==return address), however x29 is unsed so is saved and restored redundantly. We could just save and restore x30, but there is no additional cost to saving x29. All the best, Ed. From thomas.stuefe at gmail.com Thu Mar 26 16:26:01 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Mar 2015 17:26:01 +0100 Subject: RFR(L): 8075506: aix: improve handling of native memory In-Reply-To: <5512F608.6070709@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFB69B7@DEWDFEMB12A.global.corp.sap> <5512F608.6070709@oracle.com> Message-ID: Hi Valdimir, Goetz, sorry, the comment is misleading. What was meant was that no explicit commit is needed, on AIX we have automatic commit on touch. Which is actually true for all memory, not just C heap. So though it is true that pthread stacks live in C heap, it does not matter here and the comment should be changed to "On AIX we need no explicit commit". @Goetz: Changes look ok, build ok and 64k pages are allocated now (tested with -XX:+Verbose). Thank you for porting this to the OpenJDK! There are some changes in there which have nothing to do with 64K page support: - anything in create_stack_guard_pages() and allocate_stack_guard_pages() - attachListener.cpp, interfaceSupport.hpp and perfMemory_aix.cpp this all could go to a separate patch. Or, we just label the patch as generic patch collection. Regards, Thomas On Wed, Mar 25, 2015 at 6:53 PM, Vladimir Kozlov wrote: > Looks good. I only glanced through os_aix.cpp changes - they look fine > from 'glance'. > > Could you explain a little about allocate_stack_guard_pages() returning > false? The comment say that you are not using normal C stack. Is it true? > > Thanks, > Vladimir > > > On 3/25/15 1:22 AM, Lindenmaier, Goetz wrote: > >> Hi, >> >> this change improves handling of native memory on aix. It adds support >> for >> 64K pages and allocation at requested addresses. This improves >> performance >> by a few percent. >> >> Please review this change. It is aix-only. >> http://cr.openjdk.java.net/~goetz/webrevs/8075506-aixMem/webrev.00/ >> >> Best regards, >> Goetz. >> >> From stefan.karlsson at oracle.com Thu Mar 26 16:35:23 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 26 Mar 2015 17:35:23 +0100 Subject: RFR: 8075955: Replace the macro based implementation of oop_oop_iterate with a template based solution Message-ID: <5514354B.6060505@oracle.com> Hi, Please review this patch to replace the macro based implementation of oop_oop_iterate with a template based solution. http://cr.openjdk.java.net/~stefank/8075955/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8075955 Summary of the changes: - Replace the macro implementation of the different oop_oop_iterate functions with template functions. The implementation is moved out from the *Klass.cpp files into the *Klass.inline.hpp files, to be able to generate the specialized oop_oop_iterate functions in suitable GC specific files. See the old macro implementation: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.cpp.udiff.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html That has now been converted into template functions: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.inline.hpp.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.inline.hpp.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.inline.hpp.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.inline.hpp.html http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.inline.hpp.udiff.html There's still a closure specialization layer implemented with macros to support the code to allows the code to pass down the concrete closure type, past the virtual Klass::oop_oop_iterate_nv(...) call. The macros just calls the new template functions: 191 #define InstanceKlass_OOP_OOP_ITERATE_DEFN(OopClosureType, nv_suffix) \ 192 int InstanceKlass::oop_oop_iterate##nv_suffix(oop obj, OopClosureType* closure) { \ 193 return oop_oop_iterate(obj, closure); \ 194 } We might want to remove this in a future patch, by providing our own dispatch mechanism. - Split the generation of the specialized oop_oop_iterate definitions, so that we keep code from different GCs separated. Before this patch, code from all GCs were generated into instanceKlass.cpp, instanceMirrorKlass.cpp, instanceClassLoaderKlass.cpp, instanceRefKlass.cpp, typeArrayKlass.cpp, and objArrayKlass.cpp. Now the definitions are generated into: G1: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/g1/g1OopClosures.cpp.udiff.html CMS: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.cpp.html ParNew: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.cpp.html Serial: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/genOopClosures.cpp.html - The other GCs don't use use the above mentioned closure specialization, that is, they don't call obj->oop_iterate(&cl) to follow the objects. Instead they have their own "visitor" functions located in the oopDesc and *Klass classes. For example, Parallel Scavenge calls obj->push_contents(...), which calls Klass::oop_push_contents(...), to follow outgoing pointers after an object has been moved. These visitor functions used to use the oop iterate macros and pass down snippets of code to be applied to each oop*. This has now been changed to use use closures and the new oop_oop_iterate template functions. The implementation of these object visitor functions have been moved out from the *Klass.cpp files and into the GCs that the functions support. Using Parallel Scavenge as and example: The implementation to handle the references out of a copied object was located in: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html -void InstanceKlass::oop_push_contents(PSPromotionManager* pm, oop obj) { - InstanceKlass_OOP_MAP_REVERSE_ITERATE( \ - obj, \ - if (PSScavenge::should_scavenge(p)) { \ - pm->claim_or_forward_depth(p); \ - }, \ - assert_nothing ) -} and has now been moved to: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html +void InstanceKlass::oop_ps_push_contents(oop obj, PSPromotionManager* pm) { + PushContentsClosure cl(pm); + oop_oop_iterate_oop_maps_reverse(obj, &cl); +} where the do_oop function is implemented as: + + template void do_oop_nv(T* p) { + if (PSScavenge::should_scavenge(p)) { + _pm->claim_or_forward_depth(p); + } From the same file, it can be seen how that the implementation to follow the references in the mirrors are using the same closure: +void InstanceMirrorKlass::oop_ps_push_contents(oop obj, PSPromotionManager* pm) { ... + InstanceKlass::oop_ps_push_contents(obj, pm); + + PushContentsClosure cl(pm); + oop_oop_iterate_statics(obj, &cl); +} As can be seen above, the functions are still members of the different Klasses, but only the declaration is put in the klass.hpp files. The actual implementation is put in the GC files. This helps decoupling the different GCs and the Klasses. We could move the functions over to a GC specific "visitor" and have a generic "accept" function in the Klasses, but that approach would require two virtual calls, while the current implementation only needs one. In the future we might want to remove these functions from the *Klasses and reuse the already existing code in the oop_oop_iterate framework. If we take the InstanceMirrorKlass::oop_ps_push_contents function above as an example, it could be implemented with InstanceMirrorKlass::oop_oop_iterate, since they share the same structure: 54 template 55 int InstanceMirrorKlass::oop_oop_iterate(oop obj, OopClosureType* closure) { 56 InstanceKlass::oop_oop_iterate(obj, closure); 57 58 if (Devirtualizer::do_metadata(closure)) { 59 Klass* klass = java_lang_Class::as_Klass(obj); 60 // We'll get NULL for primitive mirrors. 61 if (klass != NULL) { 62 Devirtualizer::do_klass(closure, klass); 63 } 64 } 65 66 oop_oop_iterate_statics(obj, closure); 67 68 return oop_size(obj); 69 } Parallel Scavenge doesn't visit the klass pointers and do_metadata returns false, so that code path will be eliminated by the compiler. We would have to do something about the return oop_size(obj), since we don't want to do that unnecessarily. To change the GC object visitors to entirely use the oop_oop_iterator framework is out of scope for this patch. The object visitor functions were renamed and moved as follows: oop_follow_contents(opp) -> oop_ms_follow_contents(oop) in markSweep.cpp oop_adjust_pointers(oop) -> oop_ms_adjust_pointers(oop) in markSweep.cpp oop_follow_contents(oop, ParCompactionManager*) -> oop_pc_follow_contents(...) in psCompactionManager.cpp oop_update_pointers(oop) -> oop_pc_update_pointers(oop) in psParallelCompact.cpp oop_push_contents(oop, PSPromotionManager*) -> oop_ps_push_contents(...) in psPromotionManager.cpp - The oop iterate macros used to take an assert parameter to be applied to oop* that were visited. By default, the check was assert_is_in_closed_subset, but MS, PS and PC provided their own asserts. ExtendedOopClosure has been handed the task to provide the default verification, but also a way to turn it off for individual closures, so that they can provide their own asserts. See: ExtendedOopClosure::verify() and ExtendedOopClosure::should_verify_oops() and how the Devirtualizer dispatch class calls the verification code: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/iterator.inline.hpp.udiff.html +template +inline void Devirtualizer::do_oop(OopClosureType* closure, T* p) { + debug_only(closure->verify(p)); + closure->do_oop_nv(p); +} - Moved PSParallelCompact::MarkAndPushClosure::do_oop, PSParallelCompact::AdjustPointerClosure::do_oop, mark_and_push, adjust pointer, and follow_klass to psParallelCompact.inline.hpp http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html - Add seemingly incorrect includes between GCs. This is needed since we currently have no separation between GCs when we generate the oop_since_save_marks_iterate functions. See: http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/defNewGeneration.cpp.udiff.html and the include of ParNew specific closures: 51 #if INCLUDE_ALL_GCS 52 #include "gc_implementation/parNew/parOopClosures.hpp" 53 #endif which is needed to be able to generate: 856 ALL_SINCE_SAVE_MARKS_CLOSURES(DefNew_SINCE_SAVE_MARKS_DEFN) This should be changed in a separate patch, so that DefNew only generates oop_since_save_marks_iterate that takes DefNew specfic closures. The initial performance runs showed a slight increase of the GC times on some benchmarks on Solaris and Windows. The reason for this increase was that the these compilers didn't inline as much as the hand-inlined macros used to do. To remedy this I've increased the inlining in to ways: - Turned on extra inlining for psPromotionManager.cpp when compiling with the Solaris Studio Compiler http://cr.openjdk.java.net/~stefank/8075955/webrev.01/make/solaris/makefiles/product.make.udiff.html - Added __forceinline to the InstanceKlass::oop_oop_iterate functions when compiling with the MS compiler. http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html A previous version of this patch has been run through our testing, but I've recently done changes and extracted smaller patches, so I'll have to rerun all testing. Any requests for extra testing to be done? Thanks, StefanK From coleen.phillimore at oracle.com Thu Mar 26 17:41:40 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 26 Mar 2015 13:41:40 -0400 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> Message-ID: <551444D4.3040706@oracle.com> So I thought of changing the objectMonitor code to do if (CanUseSafeFetchN) { SafeFetchN(...) } else { just fetch unsafely } There's also a SafeFetch32 call around that same place that would also have to be changed this way. But I thought it was messy to add this conditional code since the result for Zero would be the exactly the same in this place. So I chose CanUseSafeFetch to mean SafeFetch isn't safe and protected code the test code that way and not the ObjectMonitor code. I don't mind if this is reversed as long as it's not messy and is tested. Coleen On 3/26/15, 9:46 AM, Thomas St?fe wrote: > Hi David, > > you are right, it was also broken before. I missed that Coleen just > reintroduced an earlier version of the dummy SafeFetch() > implementation, sorry for that. > > I would be happy with a CanUseSafeFetch() which returns always false > on zero and false on other platforms before stub generation. That > would be always safe to call. > > Kind Regards, Thomas > > > On Thu, Mar 26, 2015 at 1:38 PM, David Holmes > wrote: > > On 26/03/2015 10:24 PM, Thomas St?fe wrote: > > Hi David, > > On Thu, Mar 26, 2015 at 11:42 AM, David Holmes > > >> wrote: > > Hi Thomas, > > On 26/03/2015 6:35 PM, Thomas St?fe wrote: > > Hi, > > I agree with Goetz. > > SafeFetch() was meant to be guarded with > CanUseSafeFetch(), this > is part > of the contract, so using it without this guard is > actually > incorrect > and would crash were the calling code ever called > before Stub > routine > initialization. > > > That contract was already implicit - this API is for use > after the > stubs have been generated. There's no reason to expand the > use of > this API to situations before stubs are generated. So the > assert > captures that and CanUseSafeFetch is really unnecessary. > > > We had to introduce CanUseSafeFetch() exactly because we have > situations > where we may call SafeFetch before stub routine generation: > > 1) In os_aix.cpp, we use it to probe protected memory after doing > mprotect(). This is a long story, but we had to add this > workaround > because on shortcomings in AIX's mprotect(). This code will > get called > during initialization before stub routines are set up. > Note that right now, in the OpenJDK code base, the code still > directly > checks whether the stubroutine is NULL, because that mprotect > workaround > is older than 8074552. But I planned to change this to > CanUseSafeFetch(). But with the new CanUseSafeFetch, this > would just > break AIX. > > 2) In SAPs code base, we also use it to harden error log > writing (e.g. > to make callstack dumping more reliable). This may can be > invoked very > early, if a crash happens very early, before stub routines are > available. We planned to contribute those improvements piece > by piece to > the OpenJDK - my first change for 8074552 was actually supposed to > prepare that. Now, however, this makes no sense, because using > SafeFetch() to harden error log writing would actually be > worse for > error logs for early crashes. > > SafeFetch is a very basic function which could be useful in > many more > contexts, but only if you can really be sure it is safe. The > contexts it > is used in may be very low level where you cannot be sure at > which point > in VM initialization you are. > > When I introduced CanUseSafeFetch(), it was to safeguard the > use of > SafeFetch() for situations where SafeFetch was not safe to > call. Exactly > so that I would have not to think about "is this too early to use > SafeFetch()?". This is broken now - instead of guarding me > against using > SafeFetch() in situations where it is not safe to use, it will > assert(debug) or potentially lie(release), in which case SafeFetch > itself may crash. > > > Okay I see a case for adding a check for "can I use SafeFetch at > this point in time" (though if what you are fetching is > potentially not-safe then you are in trouble!). > > So now > - CanUseSafeFetch really now means "SafeFetch will > behave as > excpected" > - SafeFetch is softened to "will safely fetch content > of address > unless on zero, there it may crash the VM". > > I think this is more confusing than before. In > objectMonitor, > the logic > we want is "use SafeFetch wherever possible but if > not, just > access the > memory directly". This logic now is hidden behind a > seemingly > incorrect > use of SafeFetch without CanUseSafeFetch, and I think > Goetz proposal > would have been far more clearer. > > > No the problem is that SafeFetch doesn't work on ZERO - if > you give > it a bad address it won't recover it will crash. The whole > point is > for it not to crash. The objectMonitor code is saying > "here is a > load that we know may be invalid, but if it is then we > don't want to > crash, so we use SafeFetch". > > > Yes! But the way it is coded, it does not. Because SafeFetch > is now > implemented on zero with a simple load, it is not safe at all. > The code > in objectMonitor.cpp appears to be safe, but it is not. And > SafeFetch() > promises to be safe, but it is not, and you would not know > unless you > know the zero implementation. > > > Sorry did I miss something - has Zero ever implemented SafeFetch > as other than a direct simple load? ie hasn't Zero always been > broken wrt SafeFetch and that is the basic problem ? > > It seems to be a bit inconsequent. Either one is really sure > the pointer > is accessible - in which case why use SafeFetch? - or it may > be invalid, > even if this is unusual - in which case why is the resulting > crash not a > problem for zero? > In other words, if the original programmer thought it worth to > guard the > memory access with SafeFetch(), why is this not a concern for > zero? > > > It is - which is why Zero is broken. > > The expectation is that SafeFetch actually is safe no > matter what is > fetched. > > > Yes, and that expectation is broken now. > > > When was it not broken? > > Before, if you used SafeFetch() and guarded it with > CanUseSafeFetch(), > you could be sure to be safe and not to break anything - > regardless when > in VM life you used the function or on which platform. > > > No you only knew that a function called SafeFetch could be called > - you didn't know it was actually implemented to actually always > do a "safe fetch". > > Both SafeFetch and CanUseSafeFetch made promises: > - CanUseSafeFetch promised to tell me if it is too early to call > SafeFetch. Of course, it itself could be called at all times, > that was > the whole point of CanUseSafeFetch. > - SafeFetch promised to be able to access a potentially > invalid pointer > and not to crash - if CanUseSafeFetch returned true. > > > SafeFetch (if it exists) promises to be safe. The ZERO > implementation breaks that. > > Both promises are broken now. CanUseSafeFetch is not safe to > call if it > is too early - ironically a condition it was designed to tell me. > > > Okay we will re-fix that. > > SafeFetch is not safe to call because it lies about being safe > for zero. > > > It never was safe to call as far as I can see, it was just never > called with an invalid value. The new test exposed this. > > David > ----- > > The result is that either if we continue to use SafeFetch, we risk > crashes on zero and crashes if invoked too early. This makes > the API > useless for most cases. > > I am open to any other suggestions - renaming the APIs, maybe > reshaping > them - but I regret seeing SafeFetch being back to being quite > unsafe again. > > Kind Regards, Thomas > > > The ZERO implementation just does a load and hopes it > isn't asked > for anything bad. The objectMonitor code will rarely actually > trigger a bad load. But the newly introduced test does. > > So in my opinion to return to the status-quo where ZERO really > doesn't implement SafeFetch safely but it "works okay in > practice", > we should disable those explicit tests when running on ZERO. > > Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is > implemented explicitly or implicitly as an assert is a > side-issue. > > David > > Kind Regards, Thomas > > > > > > > > On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz > > > > __com > >>> wrote: > > Hi, > > sorry I only comment on this now ... > I think it's rather strange that you can not use > SafeFetch > on zero, > but it's there, > and it's actually used ... which will be the > situation > after this > change. > > Why not just change objectMonitor as the > SafeFetch api is > meant to > be used? > Obviously zero takes care that this access always > succeeds: > > diff -r a35854c84d9d > src/share/vm/runtime/__objectMonitor.cpp > --- a/src/share/vm/runtime/__objectMonitor.cpp > Wed Mar > 25 12:36:28 > 2015 +0100 > +++ b/src/share/vm/runtime/__objectMonitor.cpp > Thu Mar > > 26 08:19:53 > 2015 +0100 > @@ -2241,7 +2241,12 @@ > } > > assert(sizeof(((JavaThread > *)ox)->_thread_state == > sizeof(int)), > "invariant"); > - int jst = SafeFetch32((int *) &((JavaThread *) > ox)->_thread_state, -1);; > + int jst; > + if (CanUseSafeFetch32()) { > + jst = SafeFetch32((int *) &((JavaThread *) > ox)->_thread_state, -1); > + } else { > + jst = ((JavaThread *)ox)->_thread_state; > + } > // consider also: jst != _thread_in_Java -- > but that's > overspecific. > return jst == _thread_blocked || jst == > _thread_in_native; > } > > It's handled similarly in vmError.cpp. And no > #ifdefs ;) > > But I'm also fine with the other change ... to > get zero > working again. > > Best regards, > Goetz. > > > > -----Original Message----- > From: hotspot-dev > [mailto:hotspot-dev-bounces@ > __openjdk.java.net > > > > __openjdk.java.net > > >>] On Behalf Of > Coleen > Phillimore > Sent: Thursday, March 26, 2015 3:30 AM > To: David Holmes; hotspot-dev developers > Subject: Re: RFR (xs) 8075967: Zero interpreter > asserts for > SafeFetch<32, N> calls in ObjectMonitor > > > On 3/25/15, 10:15 PM, David Holmes wrote: > > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: > >> > >> On 3/25/15, 8:21 PM, David Holmes wrote: > >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: > >>>> > >>>> On 3/25/15, 7:59 PM, David Holmes wrote: > >>>>> Hi Coleen, > >>>>> > >>>>> Why generate stubs that can't be used and > then add > zero-specific > >>>>> logic > >>>>> to the shared CanUseSafeFetchN instead of not > generating the > stubs so > >>>>> that CanUseSafeFetchN will return false > anyway ?? > >>>> > >>>> Because there is platform independent code in > objectMonitor.cpp that > >>>> uses SafeFetchX (both). I'd rather not > burden the > caller of > this with > >>>> testing CanUseSafeFetchX for each call. > This code > existed before > >>>> SafeFetch was implemented, so I'm restoring > previous > behavior for > >>>> Zero. > >>> > >>> Sorry Coleen I thought this was deal to with > 8075533, > I hadn't > >>> realized 8075533 broke the objectMonitor > code and this > was a > follow up. > >>> > >>> What a mess. :( > >> > >> Yes, it is. Is this a code Review? > > > > Let me work through this :) The original > change for 8074552: > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__3eb61269f421 > > > > > > added the extra error handling stuff related to > SafeFetch and a new > > ErrorHandler test that was predicated on > CanUseSafeFetch32 which > > returns true if the stubs exist. It also added > testing of > SafeFetch in > > StubRoutines::initialize2 which was excluded for > windows-32-bit and > > which did not check CanUseSafeFetch32. > > > > That change broke zero as reported in 8075533 > because > you can't > > actually use the SafeFetch routines with an unsafe > address on Zero, > > and the solution: > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__5c2bc6278fc4 > > > > > > > > was to remove the stubs so that > CanUseSafeFetch32 would > return false, > > and to include a check of CanUseSafeFetch32 in > the tests > used with > > StubRoutines::initialize2. > > > > And now we find that the SafeFetch routines > are used > unconditionally > > by the objectMonitor code, so we need to > restore the > stubs that were > > previously removed, but force CanUseSafeFetch32 to > return false > on zero. > > Yes, exactly. > > > > Ok. Only nit is that: > > > > return NOT_ZERO(true) ZERO_ONLY(false); > > Yes, you're right. I'll make that change. > > Thanks! > Coleen > > > > > would be more readable than the ifdefs. > > > > Thanks, > > David > > > >> thanks! > >> Coleen > >>> > >>> Thanks, > >>> David > >>> > >>> > >>> > >>>> We could file an RFE to either implement > SafeFetch > for Zero or > rewrite > >>>> this objectMonitor code to not need > SafeFetch. I > didn't want > to do > >>>> either of these things with this patch. > >>>> > >>>> Coleen > >>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore > wrote: > >>>>>> Summary: Implement SafeFetchX unsafely > and make > CanUseSafeFetchX > >>>>>> false > >>>>>> for Zero > >>>>>> > >>>>>> Also, this fixes a couple other minor issues. > >>>>>> > >>>>>> Ran jdk9 jck tests with one timeout. > hotspot/runtime jtreg > tests > >>>>>> don't > >>>>>> run because Zero doesn't support > UseCompressedOops > (not sure > why) > >>>>>> and > >>>>>> CDS (know why). > >>>>>> > >>>>>> open webrev at > http://cr.openjdk.java.net/~__coleenp/8075967/ > > > > >>>>>> bug link > https://bugs.openjdk.java.net/__browse/JDK-8075967 > > >>>>>> > >>>>>> Thanks, > >>>>>> Coleen > >>>> > >> > > > > From alexander.kulyakhtin at oracle.com Wed Mar 25 14:38:15 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 25 Mar 2015 07:38:15 -0700 (PDT) Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Message-ID: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> Hi Please, find the updated review for the bulk @modules change at the link below. We have fixed the copyrights and the files mentioned in the mail from Lois. http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html Best regards, Alex ----- Original Message ----- From: lois.foltan at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From coleen.phillimore at oracle.com Thu Mar 26 18:15:39 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 26 Mar 2015 14:15:39 -0400 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> Message-ID: <55144CCB.5010204@oracle.com> On 3/26/15, 9:46 AM, Thomas St?fe wrote: > Hi David, > > you are right, it was also broken before. I missed that Coleen just > reintroduced an earlier version of the dummy SafeFetch() > implementation, sorry for that. > > I would be happy with a CanUseSafeFetch() which returns always false > on zero and false on other platforms before stub generation. That > would be always safe to call. Yes, I missed the case where you were using CanUseSafeFetch also to mean that the stub has been generated. It should be something like this: inline bool CanUseSafeFetch32() { return NOT_ZERO(StubRoutines::SafeFetch32_stub() != NULL) ZERO_ONLY(false); } I don't know if you want to fix this when you introduce calls to SafeFetch before initialization is complete or now. Sorry for the problems. Coleen > > Kind Regards, Thomas > > > On Thu, Mar 26, 2015 at 1:38 PM, David Holmes > wrote: > > On 26/03/2015 10:24 PM, Thomas St?fe wrote: > > Hi David, > > On Thu, Mar 26, 2015 at 11:42 AM, David Holmes > > >> wrote: > > Hi Thomas, > > On 26/03/2015 6:35 PM, Thomas St?fe wrote: > > Hi, > > I agree with Goetz. > > SafeFetch() was meant to be guarded with > CanUseSafeFetch(), this > is part > of the contract, so using it without this guard is > actually > incorrect > and would crash were the calling code ever called > before Stub > routine > initialization. > > > That contract was already implicit - this API is for use > after the > stubs have been generated. There's no reason to expand the > use of > this API to situations before stubs are generated. So the > assert > captures that and CanUseSafeFetch is really unnecessary. > > > We had to introduce CanUseSafeFetch() exactly because we have > situations > where we may call SafeFetch before stub routine generation: > > 1) In os_aix.cpp, we use it to probe protected memory after doing > mprotect(). This is a long story, but we had to add this > workaround > because on shortcomings in AIX's mprotect(). This code will > get called > during initialization before stub routines are set up. > Note that right now, in the OpenJDK code base, the code still > directly > checks whether the stubroutine is NULL, because that mprotect > workaround > is older than 8074552. But I planned to change this to > CanUseSafeFetch(). But with the new CanUseSafeFetch, this > would just > break AIX. > > 2) In SAPs code base, we also use it to harden error log > writing (e.g. > to make callstack dumping more reliable). This may can be > invoked very > early, if a crash happens very early, before stub routines are > available. We planned to contribute those improvements piece > by piece to > the OpenJDK - my first change for 8074552 was actually supposed to > prepare that. Now, however, this makes no sense, because using > SafeFetch() to harden error log writing would actually be > worse for > error logs for early crashes. > > SafeFetch is a very basic function which could be useful in > many more > contexts, but only if you can really be sure it is safe. The > contexts it > is used in may be very low level where you cannot be sure at > which point > in VM initialization you are. > > When I introduced CanUseSafeFetch(), it was to safeguard the > use of > SafeFetch() for situations where SafeFetch was not safe to > call. Exactly > so that I would have not to think about "is this too early to use > SafeFetch()?". This is broken now - instead of guarding me > against using > SafeFetch() in situations where it is not safe to use, it will > assert(debug) or potentially lie(release), in which case SafeFetch > itself may crash. > > > Okay I see a case for adding a check for "can I use SafeFetch at > this point in time" (though if what you are fetching is > potentially not-safe then you are in trouble!). > > So now > - CanUseSafeFetch really now means "SafeFetch will > behave as > excpected" > - SafeFetch is softened to "will safely fetch content > of address > unless on zero, there it may crash the VM". > > I think this is more confusing than before. In > objectMonitor, > the logic > we want is "use SafeFetch wherever possible but if > not, just > access the > memory directly". This logic now is hidden behind a > seemingly > incorrect > use of SafeFetch without CanUseSafeFetch, and I think > Goetz proposal > would have been far more clearer. > > > No the problem is that SafeFetch doesn't work on ZERO - if > you give > it a bad address it won't recover it will crash. The whole > point is > for it not to crash. The objectMonitor code is saying > "here is a > load that we know may be invalid, but if it is then we > don't want to > crash, so we use SafeFetch". > > > Yes! But the way it is coded, it does not. Because SafeFetch > is now > implemented on zero with a simple load, it is not safe at all. > The code > in objectMonitor.cpp appears to be safe, but it is not. And > SafeFetch() > promises to be safe, but it is not, and you would not know > unless you > know the zero implementation. > > > Sorry did I miss something - has Zero ever implemented SafeFetch > as other than a direct simple load? ie hasn't Zero always been > broken wrt SafeFetch and that is the basic problem ? > > It seems to be a bit inconsequent. Either one is really sure > the pointer > is accessible - in which case why use SafeFetch? - or it may > be invalid, > even if this is unusual - in which case why is the resulting > crash not a > problem for zero? > In other words, if the original programmer thought it worth to > guard the > memory access with SafeFetch(), why is this not a concern for > zero? > > > It is - which is why Zero is broken. > > The expectation is that SafeFetch actually is safe no > matter what is > fetched. > > > Yes, and that expectation is broken now. > > > When was it not broken? > > Before, if you used SafeFetch() and guarded it with > CanUseSafeFetch(), > you could be sure to be safe and not to break anything - > regardless when > in VM life you used the function or on which platform. > > > No you only knew that a function called SafeFetch could be called > - you didn't know it was actually implemented to actually always > do a "safe fetch". > > Both SafeFetch and CanUseSafeFetch made promises: > - CanUseSafeFetch promised to tell me if it is too early to call > SafeFetch. Of course, it itself could be called at all times, > that was > the whole point of CanUseSafeFetch. > - SafeFetch promised to be able to access a potentially > invalid pointer > and not to crash - if CanUseSafeFetch returned true. > > > SafeFetch (if it exists) promises to be safe. The ZERO > implementation breaks that. > > Both promises are broken now. CanUseSafeFetch is not safe to > call if it > is too early - ironically a condition it was designed to tell me. > > > Okay we will re-fix that. > > SafeFetch is not safe to call because it lies about being safe > for zero. > > > It never was safe to call as far as I can see, it was just never > called with an invalid value. The new test exposed this. > > David > ----- > > The result is that either if we continue to use SafeFetch, we risk > crashes on zero and crashes if invoked too early. This makes > the API > useless for most cases. > > I am open to any other suggestions - renaming the APIs, maybe > reshaping > them - but I regret seeing SafeFetch being back to being quite > unsafe again. > > Kind Regards, Thomas > > > The ZERO implementation just does a load and hopes it > isn't asked > for anything bad. The objectMonitor code will rarely actually > trigger a bad load. But the newly introduced test does. > > So in my opinion to return to the status-quo where ZERO really > doesn't implement SafeFetch safely but it "works okay in > practice", > we should disable those explicit tests when running on ZERO. > > Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is > implemented explicitly or implicitly as an assert is a > side-issue. > > David > > Kind Regards, Thomas > > > > > > > > On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz > > > > __com > >>> wrote: > > Hi, > > sorry I only comment on this now ... > I think it's rather strange that you can not use > SafeFetch > on zero, > but it's there, > and it's actually used ... which will be the > situation > after this > change. > > Why not just change objectMonitor as the > SafeFetch api is > meant to > be used? > Obviously zero takes care that this access always > succeeds: > > diff -r a35854c84d9d > src/share/vm/runtime/__objectMonitor.cpp > --- a/src/share/vm/runtime/__objectMonitor.cpp > Wed Mar > 25 12:36:28 > 2015 +0100 > +++ b/src/share/vm/runtime/__objectMonitor.cpp > Thu Mar > > 26 08:19:53 > 2015 +0100 > @@ -2241,7 +2241,12 @@ > } > > assert(sizeof(((JavaThread > *)ox)->_thread_state == > sizeof(int)), > "invariant"); > - int jst = SafeFetch32((int *) &((JavaThread *) > ox)->_thread_state, -1);; > + int jst; > + if (CanUseSafeFetch32()) { > + jst = SafeFetch32((int *) &((JavaThread *) > ox)->_thread_state, -1); > + } else { > + jst = ((JavaThread *)ox)->_thread_state; > + } > // consider also: jst != _thread_in_Java -- > but that's > overspecific. > return jst == _thread_blocked || jst == > _thread_in_native; > } > > It's handled similarly in vmError.cpp. And no > #ifdefs ;) > > But I'm also fine with the other change ... to > get zero > working again. > > Best regards, > Goetz. > > > > -----Original Message----- > From: hotspot-dev > [mailto:hotspot-dev-bounces@ > __openjdk.java.net > > > > __openjdk.java.net > > >>] On Behalf Of > Coleen > Phillimore > Sent: Thursday, March 26, 2015 3:30 AM > To: David Holmes; hotspot-dev developers > Subject: Re: RFR (xs) 8075967: Zero interpreter > asserts for > SafeFetch<32, N> calls in ObjectMonitor > > > On 3/25/15, 10:15 PM, David Holmes wrote: > > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: > >> > >> On 3/25/15, 8:21 PM, David Holmes wrote: > >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: > >>>> > >>>> On 3/25/15, 7:59 PM, David Holmes wrote: > >>>>> Hi Coleen, > >>>>> > >>>>> Why generate stubs that can't be used and > then add > zero-specific > >>>>> logic > >>>>> to the shared CanUseSafeFetchN instead of not > generating the > stubs so > >>>>> that CanUseSafeFetchN will return false > anyway ?? > >>>> > >>>> Because there is platform independent code in > objectMonitor.cpp that > >>>> uses SafeFetchX (both). I'd rather not > burden the > caller of > this with > >>>> testing CanUseSafeFetchX for each call. > This code > existed before > >>>> SafeFetch was implemented, so I'm restoring > previous > behavior for > >>>> Zero. > >>> > >>> Sorry Coleen I thought this was deal to with > 8075533, > I hadn't > >>> realized 8075533 broke the objectMonitor > code and this > was a > follow up. > >>> > >>> What a mess. :( > >> > >> Yes, it is. Is this a code Review? > > > > Let me work through this :) The original > change for 8074552: > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__3eb61269f421 > > > > > > added the extra error handling stuff related to > SafeFetch and a new > > ErrorHandler test that was predicated on > CanUseSafeFetch32 which > > returns true if the stubs exist. It also added > testing of > SafeFetch in > > StubRoutines::initialize2 which was excluded for > windows-32-bit and > > which did not check CanUseSafeFetch32. > > > > That change broke zero as reported in 8075533 > because > you can't > > actually use the SafeFetch routines with an unsafe > address on Zero, > > and the solution: > > > > > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__5c2bc6278fc4 > > > > > > > > was to remove the stubs so that > CanUseSafeFetch32 would > return false, > > and to include a check of CanUseSafeFetch32 in > the tests > used with > > StubRoutines::initialize2. > > > > And now we find that the SafeFetch routines > are used > unconditionally > > by the objectMonitor code, so we need to > restore the > stubs that were > > previously removed, but force CanUseSafeFetch32 to > return false > on zero. > > Yes, exactly. > > > > Ok. Only nit is that: > > > > return NOT_ZERO(true) ZERO_ONLY(false); > > Yes, you're right. I'll make that change. > > Thanks! > Coleen > > > > > would be more readable than the ifdefs. > > > > Thanks, > > David > > > >> thanks! > >> Coleen > >>> > >>> Thanks, > >>> David > >>> > >>> > >>> > >>>> We could file an RFE to either implement > SafeFetch > for Zero or > rewrite > >>>> this objectMonitor code to not need > SafeFetch. I > didn't want > to do > >>>> either of these things with this patch. > >>>> > >>>> Coleen > >>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore > wrote: > >>>>>> Summary: Implement SafeFetchX unsafely > and make > CanUseSafeFetchX > >>>>>> false > >>>>>> for Zero > >>>>>> > >>>>>> Also, this fixes a couple other minor issues. > >>>>>> > >>>>>> Ran jdk9 jck tests with one timeout. > hotspot/runtime jtreg > tests > >>>>>> don't > >>>>>> run because Zero doesn't support > UseCompressedOops > (not sure > why) > >>>>>> and > >>>>>> CDS (know why). > >>>>>> > >>>>>> open webrev at > http://cr.openjdk.java.net/~__coleenp/8075967/ > > > > >>>>>> bug link > https://bugs.openjdk.java.net/__browse/JDK-8075967 > > >>>>>> > >>>>>> Thanks, > >>>>>> Coleen > >>>> > >> > > > > From thomas.stuefe at gmail.com Thu Mar 26 18:29:59 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Mar 2015 19:29:59 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55144CCB.5010204@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> <55144CCB.5010204@oracle.com> Message-ID: Hi Coleen, No problem, I can fix this next time I touch that code. I am happy that we all agree on a solution. Kind regards, Thomas On Mar 26, 2015 7:14 PM, "Coleen Phillimore" wrote: > > On 3/26/15, 9:46 AM, Thomas St?fe wrote: > > Hi David, > > you are right, it was also broken before. I missed that Coleen just > reintroduced an earlier version of the dummy SafeFetch() implementation, > sorry for that. > > I would be happy with a CanUseSafeFetch() which returns always false on > zero and false on other platforms before stub generation. That would be > always safe to call. > > > Yes, I missed the case where you were using CanUseSafeFetch also to mean > that the stub has been generated. It should be something like this: > > inline bool CanUseSafeFetch32() { > return NOT_ZERO(StubRoutines::SafeFetch32_stub() != NULL) > ZERO_ONLY(false); > } > > I don't know if you want to fix this when you introduce calls to SafeFetch > before initialization is complete or now. > > Sorry for the problems. > > Coleen > > > Kind Regards, Thomas > > > On Thu, Mar 26, 2015 at 1:38 PM, David Holmes > wrote: > >> On 26/03/2015 10:24 PM, Thomas St?fe wrote: >> >>> Hi David, >>> >>> On Thu, Mar 26, 2015 at 11:42 AM, David Holmes >> > wrote: >>> >>> Hi Thomas, >>> >>> On 26/03/2015 6:35 PM, Thomas St?fe wrote: >>> >>> Hi, >>> >>> I agree with Goetz. >>> >>> SafeFetch() was meant to be guarded with CanUseSafeFetch(), this >>> is part >>> of the contract, so using it without this guard is actually >>> incorrect >>> and would crash were the calling code ever called before Stub >>> routine >>> initialization. >>> >>> >>> That contract was already implicit - this API is for use after the >>> stubs have been generated. There's no reason to expand the use of >>> this API to situations before stubs are generated. So the assert >>> captures that and CanUseSafeFetch is really unnecessary. >>> >>> >>> We had to introduce CanUseSafeFetch() exactly because we have situations >>> where we may call SafeFetch before stub routine generation: >>> >>> 1) In os_aix.cpp, we use it to probe protected memory after doing >>> mprotect(). This is a long story, but we had to add this workaround >>> because on shortcomings in AIX's mprotect(). This code will get called >>> during initialization before stub routines are set up. >>> Note that right now, in the OpenJDK code base, the code still directly >>> checks whether the stubroutine is NULL, because that mprotect workaround >>> is older than 8074552. But I planned to change this to >>> CanUseSafeFetch(). But with the new CanUseSafeFetch, this would just >>> break AIX. >>> >>> 2) In SAPs code base, we also use it to harden error log writing (e.g. >>> to make callstack dumping more reliable). This may can be invoked very >>> early, if a crash happens very early, before stub routines are >>> available. We planned to contribute those improvements piece by piece to >>> the OpenJDK - my first change for 8074552 was actually supposed to >>> prepare that. Now, however, this makes no sense, because using >>> SafeFetch() to harden error log writing would actually be worse for >>> error logs for early crashes. >>> >>> SafeFetch is a very basic function which could be useful in many more >>> contexts, but only if you can really be sure it is safe. The contexts it >>> is used in may be very low level where you cannot be sure at which point >>> in VM initialization you are. >>> >>> When I introduced CanUseSafeFetch(), it was to safeguard the use of >>> SafeFetch() for situations where SafeFetch was not safe to call. Exactly >>> so that I would have not to think about "is this too early to use >>> SafeFetch()?". This is broken now - instead of guarding me against using >>> SafeFetch() in situations where it is not safe to use, it will >>> assert(debug) or potentially lie(release), in which case SafeFetch >>> itself may crash. >>> >> >> Okay I see a case for adding a check for "can I use SafeFetch at this >> point in time" (though if what you are fetching is potentially not-safe >> then you are in trouble!). >> >> So now >>> - CanUseSafeFetch really now means "SafeFetch will behave as >>> excpected" >>> - SafeFetch is softened to "will safely fetch content of address >>> unless on zero, there it may crash the VM". >>> >>> I think this is more confusing than before. In objectMonitor, >>> the logic >>> we want is "use SafeFetch wherever possible but if not, just >>> access the >>> memory directly". This logic now is hidden behind a seemingly >>> incorrect >>> use of SafeFetch without CanUseSafeFetch, and I think Goetz >>> proposal >>> would have been far more clearer. >>> >>> >>> No the problem is that SafeFetch doesn't work on ZERO - if you give >>> it a bad address it won't recover it will crash. The whole point is >>> for it not to crash. The objectMonitor code is saying "here is a >>> load that we know may be invalid, but if it is then we don't want to >>> crash, so we use SafeFetch". >>> >>> >>> Yes! But the way it is coded, it does not. Because SafeFetch is now >>> implemented on zero with a simple load, it is not safe at all. The code >>> in objectMonitor.cpp appears to be safe, but it is not. And SafeFetch() >>> promises to be safe, but it is not, and you would not know unless you >>> know the zero implementation. >>> >> >> Sorry did I miss something - has Zero ever implemented SafeFetch as >> other than a direct simple load? ie hasn't Zero always been broken wrt >> SafeFetch and that is the basic problem ? >> >> It seems to be a bit inconsequent. Either one is really sure the pointer >>> is accessible - in which case why use SafeFetch? - or it may be invalid, >>> even if this is unusual - in which case why is the resulting crash not a >>> problem for zero? >>> In other words, if the original programmer thought it worth to guard the >>> memory access with SafeFetch(), why is this not a concern for zero? >>> >> >> It is - which is why Zero is broken. >> >> The expectation is that SafeFetch actually is safe no matter what is >>> fetched. >>> >>> >>> Yes, and that expectation is broken now. >>> >> >> When was it not broken? >> >> Before, if you used SafeFetch() and guarded it with CanUseSafeFetch(), >>> you could be sure to be safe and not to break anything - regardless when >>> in VM life you used the function or on which platform. >>> >> >> No you only knew that a function called SafeFetch could be called - you >> didn't know it was actually implemented to actually always do a "safe >> fetch". >> >> Both SafeFetch and CanUseSafeFetch made promises: >>> - CanUseSafeFetch promised to tell me if it is too early to call >>> SafeFetch. Of course, it itself could be called at all times, that was >>> the whole point of CanUseSafeFetch. >>> - SafeFetch promised to be able to access a potentially invalid pointer >>> and not to crash - if CanUseSafeFetch returned true. >>> >> >> SafeFetch (if it exists) promises to be safe. The ZERO implementation >> breaks that. >> >> Both promises are broken now. CanUseSafeFetch is not safe to call if it >>> is too early - ironically a condition it was designed to tell me. >>> >> >> Okay we will re-fix that. >> >> SafeFetch is not safe to call because it lies about being safe for zero. >>> >> >> It never was safe to call as far as I can see, it was just never called >> with an invalid value. The new test exposed this. >> >> David >> ----- >> >> The result is that either if we continue to use SafeFetch, we risk >>> crashes on zero and crashes if invoked too early. This makes the API >>> useless for most cases. >>> >>> I am open to any other suggestions - renaming the APIs, maybe reshaping >>> them - but I regret seeing SafeFetch being back to being quite unsafe >>> again. >>> >>> Kind Regards, Thomas >>> >>> >>> The ZERO implementation just does a load and hopes it isn't asked >>> for anything bad. The objectMonitor code will rarely actually >>> trigger a bad load. But the newly introduced test does. >>> >>> So in my opinion to return to the status-quo where ZERO really >>> doesn't implement SafeFetch safely but it "works okay in practice", >>> we should disable those explicit tests when running on ZERO. >>> >>> Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is >>> implemented explicitly or implicitly as an assert is a side-issue. >>> >>> David >>> >>> Kind Regards, Thomas >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz >>> >>> >> >> wrote: >>> >>> Hi, >>> >>> sorry I only comment on this now ... >>> I think it's rather strange that you can not use SafeFetch >>> on zero, >>> but it's there, >>> and it's actually used ... which will be the situation >>> after this >>> change. >>> >>> Why not just change objectMonitor as the SafeFetch api is >>> meant to >>> be used? >>> Obviously zero takes care that this access always succeeds: >>> >>> diff -r a35854c84d9d >>> src/share/vm/runtime/__objectMonitor.cpp >>> --- a/src/share/vm/runtime/__objectMonitor.cpp Wed Mar >>> 25 12:36:28 >>> 2015 +0100 >>> +++ b/src/share/vm/runtime/__objectMonitor.cpp Thu Mar >>> >>> 26 08:19:53 >>> 2015 +0100 >>> @@ -2241,7 +2241,12 @@ >>> } >>> >>> assert(sizeof(((JavaThread *)ox)->_thread_state == >>> sizeof(int)), >>> "invariant"); >>> - int jst = SafeFetch32((int *) &((JavaThread *) >>> ox)->_thread_state, -1);; >>> + int jst; >>> + if (CanUseSafeFetch32()) { >>> + jst = SafeFetch32((int *) &((JavaThread *) >>> ox)->_thread_state, -1); >>> + } else { >>> + jst = ((JavaThread *)ox)->_thread_state; >>> + } >>> // consider also: jst != _thread_in_Java -- but that's >>> overspecific. >>> return jst == _thread_blocked || jst == >>> _thread_in_native; >>> } >>> >>> It's handled similarly in vmError.cpp. And no #ifdefs ;) >>> >>> But I'm also fine with the other change ... to get zero >>> working again. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: hotspot-dev >>> [mailto:hotspot-dev-bounces at __openjdk.java.net >>> >>> >> >] On Behalf Of >>> Coleen >>> Phillimore >>> Sent: Thursday, March 26, 2015 3:30 AM >>> To: David Holmes; hotspot-dev developers >>> Subject: Re: RFR (xs) 8075967: Zero interpreter asserts for >>> SafeFetch<32, N> calls in ObjectMonitor >>> >>> >>> On 3/25/15, 10:15 PM, David Holmes wrote: >>> > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: >>> >> >>> >> On 3/25/15, 8:21 PM, David Holmes wrote: >>> >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: >>> >>>> >>> >>>> On 3/25/15, 7:59 PM, David Holmes wrote: >>> >>>>> Hi Coleen, >>> >>>>> >>> >>>>> Why generate stubs that can't be used and then add >>> zero-specific >>> >>>>> logic >>> >>>>> to the shared CanUseSafeFetchN instead of not >>> generating the >>> stubs so >>> >>>>> that CanUseSafeFetchN will return false anyway ?? >>> >>>> >>> >>>> Because there is platform independent code in >>> objectMonitor.cpp that >>> >>>> uses SafeFetchX (both). I'd rather not burden the >>> caller of >>> this with >>> >>>> testing CanUseSafeFetchX for each call. This code >>> existed before >>> >>>> SafeFetch was implemented, so I'm restoring previous >>> behavior for >>> >>>> Zero. >>> >>> >>> >>> Sorry Coleen I thought this was deal to with 8075533, >>> I hadn't >>> >>> realized 8075533 broke the objectMonitor code and this >>> was a >>> follow up. >>> >>> >>> >>> What a mess. :( >>> >> >>> >> Yes, it is. Is this a code Review? >>> > >>> > Let me work through this :) The original change for >>> 8074552: >>> > >>> > >>> >>> http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__3eb61269f421 >>> >>> > >>> > added the extra error handling stuff related to >>> SafeFetch and a new >>> > ErrorHandler test that was predicated on >>> CanUseSafeFetch32 which >>> > returns true if the stubs exist. It also added testing of >>> SafeFetch in >>> > StubRoutines::initialize2 which was excluded for >>> windows-32-bit and >>> > which did not check CanUseSafeFetch32. >>> > >>> > That change broke zero as reported in 8075533 because >>> you can't >>> > actually use the SafeFetch routines with an unsafe >>> address on Zero, >>> > and the solution: >>> > >>> > >>> >>> http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__5c2bc6278fc4 >>> >>> >>> > >>> > was to remove the stubs so that CanUseSafeFetch32 would >>> return false, >>> > and to include a check of CanUseSafeFetch32 in the tests >>> used with >>> > StubRoutines::initialize2. >>> > >>> > And now we find that the SafeFetch routines are used >>> unconditionally >>> > by the objectMonitor code, so we need to restore the >>> stubs that were >>> > previously removed, but force CanUseSafeFetch32 to >>> return false >>> on zero. >>> >>> Yes, exactly. >>> > >>> > Ok. Only nit is that: >>> > >>> > return NOT_ZERO(true) ZERO_ONLY(false); >>> >>> Yes, you're right. I'll make that change. >>> >>> Thanks! >>> Coleen >>> >>> > >>> > would be more readable than the ifdefs. >>> > >>> > Thanks, >>> > David >>> > >>> >> thanks! >>> >> Coleen >>> >>> >>> >>> Thanks, >>> >>> David >>> >>> >>> >>> >>> >>> >>> >>>> We could file an RFE to either implement SafeFetch >>> for Zero or >>> rewrite >>> >>>> this objectMonitor code to not need SafeFetch. I >>> didn't want >>> to do >>> >>>> either of these things with this patch. >>> >>>> >>> >>>> Coleen >>> >>>> >>> >>>>> >>> >>>>> Thanks, >>> >>>>> David >>> >>>>> >>> >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote: >>> >>>>>> Summary: Implement SafeFetchX unsafely and make >>> CanUseSafeFetchX >>> >>>>>> false >>> >>>>>> for Zero >>> >>>>>> >>> >>>>>> Also, this fixes a couple other minor issues. >>> >>>>>> >>> >>>>>> Ran jdk9 jck tests with one timeout. >>> hotspot/runtime jtreg >>> tests >>> >>>>>> don't >>> >>>>>> run because Zero doesn't support UseCompressedOops >>> (not sure >>> why) >>> >>>>>> and >>> >>>>>> CDS (know why). >>> >>>>>> >>> >>>>>> open webrev at >>> http://cr.openjdk.java.net/~__coleenp/8075967/ >>> >>> >>>>>> bug link >>> https://bugs.openjdk.java.net/__browse/JDK-8075967 >>> >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> Coleen >>> >>>> >>> >> >>> >>> >>> >>> > > From coleen.phillimore at oracle.com Thu Mar 26 18:39:07 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 26 Mar 2015 14:39:07 -0400 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <1427365326.3339.35.camel@redhat.com> References: <5512F600.9050102@oracle.com> <1427308172.3470.82.camel@redhat.com> <55134E0B.7090600@oracle.com> <1427365326.3339.35.camel@redhat.com> Message-ID: <5514524B.7030802@oracle.com> >> My goal at the moment was to see how well Zero works. I don't know how >> well supported this variant is. > I'd be very interested to hear on how you determine how well Zero works. > Use the TCK? Some other metric? As for jtreg tests, many of them fail > trivially because they assume there is server and client JVMs only (e.g. > tools/launcher/VersionCheck.java in JDK). I ran the JCK9 tests with one timeout, which is sort of expected since Zero is interpreted only without Shark. The hotspot runtime jtreg tests do poorly because CompressedOops aren't supported. I don't know why they aren't supported. When I took out the code to disable CompressedOops, more tests passed. Zero doesn't support CDS because metaspaceShared_zero.cpp needs some generated code that isn't done with Zero. > > With that being said, Zero should be in better shape now than it was a > while ago. Back then, it wouldn't even compile in latest upstream > trees... Yes, I heard that it works fairly well in jdk8 so getting it to work for jdk9 was just accounting for new changes. > > Depending on available cycles I'll try to help as much as I can. The > best metric we have currently for Zero is its ability to build itself. > I've never managed to go through all failing jtreg tests and determine > exactly what's wrong (test or JVM failure). > >> It seems to be missing a lot. > Right. A good starting point is making people aware that it exists so > that no new compilation errors get introduced. You've been doing a great > job at this. Thanks! My goal is to make Zero better over time, since > it's been lacking basic maintainership for a while in upstream OpenJDK. > > Aside: Zero is using the C++ interpreter which AFAIK, isn't used much > anywhere else. Most (all?) JIT ports use the template interpreter these > days. Most ports use the template interpreter because it's significantly faster, but the Zero interpreter by not having any generated native code makes getting a new port running faster. It also may be nice to prototype new bytecodes in C++ rather than as macro assembler. And it's sort of cool. Yes, Zero uses interpreter/bytecodeInterpreter.cpp which is written in C++. What we call the C++ interpreter is something else that also uses bytecodeInterpreter.cpp. https://bugs.openjdk.java.net/browse/JDK-8074457 Keeping Zero compiling and running is not part of our normal testing, so most of the contributions are coming from outside Oracle for this. Coleen > > Thanks, > Severin > >> Thanks, >> Coleen >> >>> Changes look fine to me. >>> >>> Cheers, >>> Severin >>> >>>> Thanks, >>>> Coleen >>> > > From max.ockner at oracle.com Thu Mar 26 19:53:10 2015 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 26 Mar 2015 15:53:10 -0400 Subject: RFR: 8074718: Merged templateTable_x86 header files for 32/64 bits. In-Reply-To: <5511C9BE.2070304@oracle.com> References: <55119F93.9000007@oracle.com> <5511C9BE.2070304@oracle.com> Message-ID: <551463A6.80802@oracle.com> Dean, On 3/24/2015 4:31 PM, Dean Long wrote: > On 3/24/2015 10:32 AM, Max Ockner wrote: >> Hello all, >> Please review this small change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074718 >> Webrev: >> http://cr.openjdk.java.net/~mockner/8074718/src/share/vm/interpreter/templateTable.hpp.cdiff.html >> Summary: The templateTable_x86 hpp files for 32 and 64 bits have been >> merged. Just a couple of notes: >> >> (1) I would prefer to combine the two conditions which include >> templateTable_x86.hpp if possible, but I'm not comfortable fiddling >> with the TARGET_ARCH_MODEL labels. >> I was hoping to use TARGET_ARCH_MODEL_x86 to encompass both >> TARGET_ARCH_MODEL_x86_64 and TARGET_ARCH_MODEL_x86_32, but I don't >> think it exists. Any suggestions? >> > > You could use TARGET_ARCH_x86, but then it doesn't match all the > platforms using TARGET_ARCH_MODEL. Or you could define > TEMPLATETABLE_MD_HPP and not worry about TARGET macros at all. > > dl > The main reason I had hoped for a better label was to avoid breaking the symmetry of the existing list. Unless anyone disagrees, I will keep this section as is. Thanks, Max >> (2) templateTable_x86.hpp is the updated file that will be kept. >> templateTable_x86_32.hpp and templateTable_x86_64.hpp are copies of >> templateTable_x86.hpp, and still exist for reviewing purposes. They >> will be removed before this is committed. >> >> Tested with jtreg runtime tests. >> >> Thanks, >> Max > From david.holmes at oracle.com Thu Mar 26 20:18:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Mar 2015 06:18:12 +1000 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <551444D4.3040706@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> <551444D4.3040706@oracle.com> Message-ID: <55146984.7090709@oracle.com> On 27/03/2015 3:41 AM, Coleen Phillimore wrote: > > So I thought of changing the objectMonitor code to do > if (CanUseSafeFetchN) { > SafeFetchN(...) > } else { > just fetch unsafely > } This serves no purpose and adds overheads in the monitor code. We don't need the "have the stubs been generated" check for this code. And the "can I use ZERO" check would be pointless: if safefetch on zero doesn't work then SafeFetch may crash; if you take the else then it may also crash - same result both code paths, so no point. David > There's also a SafeFetch32 call around that same place that would also > have to be changed this way. > > But I thought it was messy to add this conditional code since the result > for Zero would be the exactly the same in this place. So I chose > CanUseSafeFetch to mean SafeFetch isn't safe and protected code the test > code that way and not the ObjectMonitor code. > > I don't mind if this is reversed as long as it's not messy and is tested. > > Coleen > > On 3/26/15, 9:46 AM, Thomas St?fe wrote: >> Hi David, >> >> you are right, it was also broken before. I missed that Coleen just >> reintroduced an earlier version of the dummy SafeFetch() >> implementation, sorry for that. >> >> I would be happy with a CanUseSafeFetch() which returns always false >> on zero and false on other platforms before stub generation. That >> would be always safe to call. >> >> Kind Regards, Thomas >> >> >> On Thu, Mar 26, 2015 at 1:38 PM, David Holmes > > wrote: >> >> On 26/03/2015 10:24 PM, Thomas St?fe wrote: >> >> Hi David, >> >> On Thu, Mar 26, 2015 at 11:42 AM, David Holmes >> >> > >> wrote: >> >> Hi Thomas, >> >> On 26/03/2015 6:35 PM, Thomas St?fe wrote: >> >> Hi, >> >> I agree with Goetz. >> >> SafeFetch() was meant to be guarded with >> CanUseSafeFetch(), this >> is part >> of the contract, so using it without this guard is >> actually >> incorrect >> and would crash were the calling code ever called >> before Stub >> routine >> initialization. >> >> >> That contract was already implicit - this API is for use >> after the >> stubs have been generated. There's no reason to expand the >> use of >> this API to situations before stubs are generated. So the >> assert >> captures that and CanUseSafeFetch is really unnecessary. >> >> >> We had to introduce CanUseSafeFetch() exactly because we have >> situations >> where we may call SafeFetch before stub routine generation: >> >> 1) In os_aix.cpp, we use it to probe protected memory after doing >> mprotect(). This is a long story, but we had to add this >> workaround >> because on shortcomings in AIX's mprotect(). This code will >> get called >> during initialization before stub routines are set up. >> Note that right now, in the OpenJDK code base, the code still >> directly >> checks whether the stubroutine is NULL, because that mprotect >> workaround >> is older than 8074552. But I planned to change this to >> CanUseSafeFetch(). But with the new CanUseSafeFetch, this >> would just >> break AIX. >> >> 2) In SAPs code base, we also use it to harden error log >> writing (e.g. >> to make callstack dumping more reliable). This may can be >> invoked very >> early, if a crash happens very early, before stub routines are >> available. We planned to contribute those improvements piece >> by piece to >> the OpenJDK - my first change for 8074552 was actually supposed to >> prepare that. Now, however, this makes no sense, because using >> SafeFetch() to harden error log writing would actually be >> worse for >> error logs for early crashes. >> >> SafeFetch is a very basic function which could be useful in >> many more >> contexts, but only if you can really be sure it is safe. The >> contexts it >> is used in may be very low level where you cannot be sure at >> which point >> in VM initialization you are. >> >> When I introduced CanUseSafeFetch(), it was to safeguard the >> use of >> SafeFetch() for situations where SafeFetch was not safe to >> call. Exactly >> so that I would have not to think about "is this too early to use >> SafeFetch()?". This is broken now - instead of guarding me >> against using >> SafeFetch() in situations where it is not safe to use, it will >> assert(debug) or potentially lie(release), in which case SafeFetch >> itself may crash. >> >> >> Okay I see a case for adding a check for "can I use SafeFetch at >> this point in time" (though if what you are fetching is >> potentially not-safe then you are in trouble!). >> >> So now >> - CanUseSafeFetch really now means "SafeFetch will >> behave as >> excpected" >> - SafeFetch is softened to "will safely fetch content >> of address >> unless on zero, there it may crash the VM". >> >> I think this is more confusing than before. In >> objectMonitor, >> the logic >> we want is "use SafeFetch wherever possible but if >> not, just >> access the >> memory directly". This logic now is hidden behind a >> seemingly >> incorrect >> use of SafeFetch without CanUseSafeFetch, and I think >> Goetz proposal >> would have been far more clearer. >> >> >> No the problem is that SafeFetch doesn't work on ZERO - if >> you give >> it a bad address it won't recover it will crash. The whole >> point is >> for it not to crash. The objectMonitor code is saying >> "here is a >> load that we know may be invalid, but if it is then we >> don't want to >> crash, so we use SafeFetch". >> >> >> Yes! But the way it is coded, it does not. Because SafeFetch >> is now >> implemented on zero with a simple load, it is not safe at all. >> The code >> in objectMonitor.cpp appears to be safe, but it is not. And >> SafeFetch() >> promises to be safe, but it is not, and you would not know >> unless you >> know the zero implementation. >> >> >> Sorry did I miss something - has Zero ever implemented SafeFetch >> as other than a direct simple load? ie hasn't Zero always been >> broken wrt SafeFetch and that is the basic problem ? >> >> It seems to be a bit inconsequent. Either one is really sure >> the pointer >> is accessible - in which case why use SafeFetch? - or it may >> be invalid, >> even if this is unusual - in which case why is the resulting >> crash not a >> problem for zero? >> In other words, if the original programmer thought it worth to >> guard the >> memory access with SafeFetch(), why is this not a concern for >> zero? >> >> >> It is - which is why Zero is broken. >> >> The expectation is that SafeFetch actually is safe no >> matter what is >> fetched. >> >> >> Yes, and that expectation is broken now. >> >> >> When was it not broken? >> >> Before, if you used SafeFetch() and guarded it with >> CanUseSafeFetch(), >> you could be sure to be safe and not to break anything - >> regardless when >> in VM life you used the function or on which platform. >> >> >> No you only knew that a function called SafeFetch could be called >> - you didn't know it was actually implemented to actually always >> do a "safe fetch". >> >> Both SafeFetch and CanUseSafeFetch made promises: >> - CanUseSafeFetch promised to tell me if it is too early to call >> SafeFetch. Of course, it itself could be called at all times, >> that was >> the whole point of CanUseSafeFetch. >> - SafeFetch promised to be able to access a potentially >> invalid pointer >> and not to crash - if CanUseSafeFetch returned true. >> >> >> SafeFetch (if it exists) promises to be safe. The ZERO >> implementation breaks that. >> >> Both promises are broken now. CanUseSafeFetch is not safe to >> call if it >> is too early - ironically a condition it was designed to tell me. >> >> >> Okay we will re-fix that. >> >> SafeFetch is not safe to call because it lies about being safe >> for zero. >> >> >> It never was safe to call as far as I can see, it was just never >> called with an invalid value. The new test exposed this. >> >> David >> ----- >> >> The result is that either if we continue to use SafeFetch, we risk >> crashes on zero and crashes if invoked too early. This makes >> the API >> useless for most cases. >> >> I am open to any other suggestions - renaming the APIs, maybe >> reshaping >> them - but I regret seeing SafeFetch being back to being quite >> unsafe again. >> >> Kind Regards, Thomas >> >> >> The ZERO implementation just does a load and hopes it >> isn't asked >> for anything bad. The objectMonitor code will rarely actually >> trigger a bad load. But the newly introduced test does. >> >> So in my opinion to return to the status-quo where ZERO really >> doesn't implement SafeFetch safely but it "works okay in >> practice", >> we should disable those explicit tests when running on ZERO. >> >> Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is >> implemented explicitly or implicitly as an assert is a >> side-issue. >> >> David >> >> Kind Regards, Thomas >> >> >> >> >> >> >> >> On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz >> > >> > > >> > __com >> > >>> wrote: >> >> Hi, >> >> sorry I only comment on this now ... >> I think it's rather strange that you can not use >> SafeFetch >> on zero, >> but it's there, >> and it's actually used ... which will be the >> situation >> after this >> change. >> >> Why not just change objectMonitor as the >> SafeFetch api is >> meant to >> be used? >> Obviously zero takes care that this access always >> succeeds: >> >> diff -r a35854c84d9d >> src/share/vm/runtime/__objectMonitor.cpp >> --- a/src/share/vm/runtime/__objectMonitor.cpp >> Wed Mar >> 25 12:36:28 >> 2015 +0100 >> +++ b/src/share/vm/runtime/__objectMonitor.cpp >> Thu Mar >> >> 26 08:19:53 >> 2015 +0100 >> @@ -2241,7 +2241,12 @@ >> } >> >> assert(sizeof(((JavaThread >> *)ox)->_thread_state == >> sizeof(int)), >> "invariant"); >> - int jst = SafeFetch32((int *) &((JavaThread *) >> ox)->_thread_state, -1);; >> + int jst; >> + if (CanUseSafeFetch32()) { >> + jst = SafeFetch32((int *) &((JavaThread *) >> ox)->_thread_state, -1); >> + } else { >> + jst = ((JavaThread *)ox)->_thread_state; >> + } >> // consider also: jst != _thread_in_Java -- >> but that's >> overspecific. >> return jst == _thread_blocked || jst == >> _thread_in_native; >> } >> >> It's handled similarly in vmError.cpp. And no >> #ifdefs ;) >> >> But I'm also fine with the other change ... to >> get zero >> working again. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: hotspot-dev >> [mailto:hotspot-dev-bounces@ >> __openjdk.java.net >> >> > > >> > __openjdk.java.net >> >> > >>] On Behalf Of >> Coleen >> Phillimore >> Sent: Thursday, March 26, 2015 3:30 AM >> To: David Holmes; hotspot-dev developers >> Subject: Re: RFR (xs) 8075967: Zero interpreter >> asserts for >> SafeFetch<32, N> calls in ObjectMonitor >> >> >> On 3/25/15, 10:15 PM, David Holmes wrote: >> > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: >> >> >> >> On 3/25/15, 8:21 PM, David Holmes wrote: >> >>> On 26/03/2015 10:04 AM, Coleen Phillimore wrote: >> >>>> >> >>>> On 3/25/15, 7:59 PM, David Holmes wrote: >> >>>>> Hi Coleen, >> >>>>> >> >>>>> Why generate stubs that can't be used and >> then add >> zero-specific >> >>>>> logic >> >>>>> to the shared CanUseSafeFetchN instead of not >> generating the >> stubs so >> >>>>> that CanUseSafeFetchN will return false >> anyway ?? >> >>>> >> >>>> Because there is platform independent code in >> objectMonitor.cpp that >> >>>> uses SafeFetchX (both). I'd rather not >> burden the >> caller of >> this with >> >>>> testing CanUseSafeFetchX for each call. >> This code >> existed before >> >>>> SafeFetch was implemented, so I'm restoring >> previous >> behavior for >> >>>> Zero. >> >>> >> >>> Sorry Coleen I thought this was deal to with >> 8075533, >> I hadn't >> >>> realized 8075533 broke the objectMonitor >> code and this >> was a >> follow up. >> >>> >> >>> What a mess. :( >> >> >> >> Yes, it is. Is this a code Review? >> > >> > Let me work through this :) The original >> change for 8074552: >> > >> > >> http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__3eb61269f421 >> >> >> > >> > added the extra error handling stuff related to >> SafeFetch and a new >> > ErrorHandler test that was predicated on >> CanUseSafeFetch32 which >> > returns true if the stubs exist. It also added >> testing of >> SafeFetch in >> > StubRoutines::initialize2 which was excluded for >> windows-32-bit and >> > which did not check CanUseSafeFetch32. >> > >> > That change broke zero as reported in 8075533 >> because >> you can't >> > actually use the SafeFetch routines with an unsafe >> address on Zero, >> > and the solution: >> > >> > >> http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__5c2bc6278fc4 >> >> >> >> >> > >> > was to remove the stubs so that >> CanUseSafeFetch32 would >> return false, >> > and to include a check of CanUseSafeFetch32 in >> the tests >> used with >> > StubRoutines::initialize2. >> > >> > And now we find that the SafeFetch routines >> are used >> unconditionally >> > by the objectMonitor code, so we need to >> restore the >> stubs that were >> > previously removed, but force CanUseSafeFetch32 to >> return false >> on zero. >> >> Yes, exactly. >> > >> > Ok. Only nit is that: >> > >> > return NOT_ZERO(true) ZERO_ONLY(false); >> >> Yes, you're right. I'll make that change. >> >> Thanks! >> Coleen >> >> > >> > would be more readable than the ifdefs. >> > >> > Thanks, >> > David >> > >> >> thanks! >> >> Coleen >> >>> >> >>> Thanks, >> >>> David >> >>> >> >>> >> >>> >> >>>> We could file an RFE to either implement >> SafeFetch >> for Zero or >> rewrite >> >>>> this objectMonitor code to not need >> SafeFetch. I >> didn't want >> to do >> >>>> either of these things with this patch. >> >>>> >> >>>> Coleen >> >>>> >> >>>>> >> >>>>> Thanks, >> >>>>> David >> >>>>> >> >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore >> wrote: >> >>>>>> Summary: Implement SafeFetchX unsafely >> and make >> CanUseSafeFetchX >> >>>>>> false >> >>>>>> for Zero >> >>>>>> >> >>>>>> Also, this fixes a couple other minor issues. >> >>>>>> >> >>>>>> Ran jdk9 jck tests with one timeout. >> hotspot/runtime jtreg >> tests >> >>>>>> don't >> >>>>>> run because Zero doesn't support >> UseCompressedOops >> (not sure >> why) >> >>>>>> and >> >>>>>> CDS (know why). >> >>>>>> >> >>>>>> open webrev at >> http://cr.openjdk.java.net/~__coleenp/8075967/ >> >> > > >> >>>>>> bug link >> https://bugs.openjdk.java.net/__browse/JDK-8075967 >> >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Coleen >> >>>> >> >> >> >> >> >> > From coleen.phillimore at oracle.com Thu Mar 26 20:19:34 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 26 Mar 2015 16:19:34 -0400 Subject: RFR: 8074718: Merged templateTable_x86 header files for 32/64 bits. In-Reply-To: <5512FCD9.8000004@oracle.com> References: <55119F93.9000007@oracle.com> <5512FCD9.8000004@oracle.com> Message-ID: <551469D6.9030303@oracle.com> This looks like a good suggestion! Coleen On 3/25/15, 2:22 PM, harold seigel wrote: > Hi Max, > > This looks good. Just one small comment about templateTable_x86.hpp. > (No need for a new webrev) > > Could you combine this: > > 346 #elif defined TARGET_ARCH_MODEL_x86_32 > 347 # include "templateTable_x86.hpp" > 348 #elif defined TARGET_ARCH_MODEL_x86_64 > 349 # include "templateTable_x86.hpp" > 350 #elif defined TARGET_ARCH_MODEL_sparc > > Into: > > 346 #elif defined(TARGET_ARCH_MODEL_x86_32) || > defined(TARGET_ARCH_MODEL_x86_64) > 347 # include "templateTable_x86.hpp" > 350 #elif defined TARGET_ARCH_MODEL_sparc > > > Thanks, Harold > > On 3/24/2015 1:32 PM, Max Ockner wrote: >> Hello all, >> Please review this small change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074718 >> Webrev: >> http://cr.openjdk.java.net/~mockner/8074718/src/share/vm/interpreter/templateTable.hpp.cdiff.html >> Summary: The templateTable_x86 hpp files for 32 and 64 bits have been >> merged. Just a couple of notes: >> >> (1) I would prefer to combine the two conditions which include >> templateTable_x86.hpp if possible, but I'm not comfortable fiddling >> with the TARGET_ARCH_MODEL labels. >> I was hoping to use TARGET_ARCH_MODEL_x86 to encompass both >> TARGET_ARCH_MODEL_x86_64 and TARGET_ARCH_MODEL_x86_32, but I don't >> think it exists. Any suggestions? >> >> (2) templateTable_x86.hpp is the updated file that will be kept. >> templateTable_x86_32.hpp and templateTable_x86_64.hpp are copies of >> templateTable_x86.hpp, and still exist for reviewing purposes. They >> will be removed before this is committed. >> >> Tested with jtreg runtime tests. >> >> Thanks, >> Max > From mandy.chung at oracle.com Thu Mar 26 20:18:05 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 Mar 2015 13:18:05 -0700 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <5513FDB6.6070606@oracle.com> References: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> <55134092.801@oracle.com> <5513FDB6.6070606@oracle.com> Message-ID: <5514697D.3020308@oracle.com> On 3/26/15 5:38 AM, Yekaterina Kantserova wrote: > Mandy, > > Thank you very much for the catch! The updated webrev can be found here: > > http://cr.openjdk.java.net/~ykantser/8075586/webrev.00/ > Thanks for fixing this. Lois and other have reviewed it. I only tried to spot anything stick out. This looks okay and good to push. + * @modules java.base/sun.misc + * java.management I don't have the cycle to find out where the dependencies for this patch. looks like they are mostly from the testlibrary. Per our offline discussion, it'd be desirable to update the testlibrary and tests to assist the dependency analysis process or eliminate the dependency. One more thing to mention is that the testlibrary depending java.management to get the process ID can soon be removed once the new Process API getting pid is integrated into JDK 9. thanks Mandy > Best regards, > Katja > > > On 03/26/2015 12:11 AM, Mandy Chung wrote: >> Alexandar, Shura, >> >> The dependency analysis is not up-to-date that sun.tools.jar >> has been moved to jdk.jartool module in jdk9 b55. It has been >> in jdk9/dev since 3/6. >> >> I have pointed out multiple times previously that jdk.dev/sun.tools.jar >> is wrong in the jdk side of change. >> >> Below includes an example. >> Mandy >> >> --- old/test/runtime/RedefineTests/RedefineAnnotations.java >> 2015-03-25 16:24:41.462038538 +0300 >> +++ new/test/runtime/RedefineTests/RedefineAnnotations.java >> 2015-03-25 16:24:41.386038539 +0300 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2014, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -25,6 +25,9 @@ >> * @test >> * @library /testlibrary >> * @summary Test that type annotations are retained after a retransform >> + * @modules java.base/jdk.internal.org.objectweb.asm >> + * java.instrument >> + * jdk.dev/sun.tools.jar >> * @run main RedefineAnnotations buildagent >> * @run main/othervm -javaagent:redefineagent.jar RedefineAnnotations >> */ >> >> >> On 3/25/15 7:38 AM, Alexander Kulyakhtin wrote: >>> Hi >>> >>> Please, find the updated review for the bulk @modules change at the >>> link below. >>> >>> We have fixed the copyrights and the files mentioned in the mail >>> from Lois. >>> >>> http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html >>> >>> Best regards, >>> Alex >>> >>> >>> >>> ----- Original Message ----- >>> From: lois.foltan at oracle.com >>> To: yekaterina.kantserova at oracle.com >>> Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, >>> hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, >>> alexandre.iline at oracle.com >>> Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat >>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>> hotspot tests >>> >>> >>> This looks good, thank you for making these changes! A couple of >>> comments that I don't feel need another webrev but should be fixed >>> before pushing. >>> >>> - copyrights on all the tests need to be updated >>> - the following tests have a blank comment line before the new >>> "@modules" line that could be removed >>> test/gc/metaspace/TestMetaspacePerfCounters.java >>> test/runtime/contended/Basic.java >>> test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java >>> test/compiler/cpuflags/RestoreMXCSR.java >>> test/compiler/debug/VerifyAdapterSharing.java >>> >>> Thanks, >>> Lois >>> >>> On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: >>>> Notifying hotspot-dev as well. >>>> >>>> // Katja >>>> >>>> >>>> >>>> On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >>>>> Could the reviewers, please, have a look at the proposed changes >>>>> below? >>>>> >>>>> In addition, we are going to make a change to the TEST.ROOT file as >>>>> indicated by Staffan in the mail below. >>>>> >>>>> Do you think the changes (plus the one-line change to the TEST.ROOT) >>>>> can be pushed into the jdk? >>>>> >>>>> Best regards, >>>>> Alex >>>>> >>>>> ----- Original Message ----- >>>>> From: staffan.larsen at oracle.com >>>>> To: alexander.kulyakhtin at oracle.com >>>>> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >>>>> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >>>>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>>>> hotspot tests >>>>> >>>>> I haven?t looked at the changes in detail, but please change the >>>>> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Could you, please, review the fix below. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>>>>> >>>>>> The fix adds @modules keyword to the existing hotspot tests, as >>>>>> needed, so that the tests can access the required API when the new >>>>>> modular architecture is in place. >>>>>> >>>>>> Best regards, >>>>>> Alex >> > From coleen.phillimore at oracle.com Thu Mar 26 20:21:12 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 26 Mar 2015 16:21:12 -0400 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <5512376C.9050509@oracle.com> References: <55117B1C.5080602@oracle.com> <55119244.6020309@oracle.com> <55119880.5040407@oracle.com> <55119B46.4090909@oracle.com> <5512376C.9050509@oracle.com> Message-ID: <55146A38.8090501@oracle.com> Goetz or Volker, did you see this? thanks! Coleen On 3/25/15, 12:19 AM, David Holmes wrote: > On 25/03/2015 3:13 AM, harold seigel wrote: >> Hi Max, >> >> Should this comment be removed from both files? >> >> // Glibc-2.0 libdl is not MT safe. If you are building with any >> glibc, >> // chances are you might want to run the generated bits against >> glibc-2.0 >> // libdl.so, so always use locking for any version of glibc. > > Yes that should also be deleted - it was part of the incorrect copy > done by 6721093. And as per 6626677 glibc was fixed at version 2.1 > back in 1997. > > Since this was all investigated we had the AIX code added, so we need > to get one of the AIX folk to confirm that no locking is needed around > dlsym on that platform. (I would be very surprised if it were needed :) ) > > Thanks, > David > >> Thanks, Harold >> >> On 3/24/2015 1:01 PM, Max Ockner wrote: >>> This was not intentional. I thought the comment was referring to the >>> line containing dl_mutex, but it was not. I put the comment back in. >>> New webrev: http://cr.openjdk.java.net/~mockner/6983747.2/ >>> Thanks, >>> Max >>> >>> On 3/24/2015 12:35 PM, Dmitry Dmitriev wrote: >>>> Hi Max, >>>> >>>> Can you please tell me, you intentionally delete following comment >>>> from os_linux.cpp file: >>>> 4680 // else it defaults to CLOCK_REALTIME >>>> >>>> It seems that this comment should be leaved. What you think about >>>> that? >>>> >>>> I am not a reviewer. >>>> >>>> Thanks, >>>> Dmitry >>>> >>>> On 24.03.2015 17:56, Max Ockner wrote: >>>>> Hello, >>>>> please review my clean up of the unused dl_mutex lock. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 >>>>> Webrev: http://cr.openjdk.java.net/~mockner/6983747/ >>>>> Summary: Deleted all references to the dl_mutex lock which was no >>>>> longer used. >>>>> >>>>> Tested with jtreg runtime tests. >>>>> >>>>> >>>>> Thanks, >>>>> Max Ockner >>>> >>> >> From serguei.spitsyn at oracle.com Fri Mar 27 00:50:01 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 26 Mar 2015 17:50:01 -0700 Subject: RFR (S) 8073705: jvmtiRedefineClasses.cpp assert cache ptrs must match Message-ID: <5514A939.1090200@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8073705 Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ Summary: This is the 2-nd round of performance/calability fixes in class redefinition. This time, the two remaining issues that were left alone in the first round fix: - optimized ConstantPoolCache::adjust_method_entries() is used for previous versions - the MemberNameTable::adjust_method_entries() has been optimized too - some cleanup Testing: In progress: nsk redefine classes tests, JTREG java/lang/instrument, com/sun/jdi Thanks, Serguei From dean.long at oracle.com Fri Mar 27 01:00:08 2015 From: dean.long at oracle.com (Dean Long) Date: Thu, 26 Mar 2015 18:00:08 -0700 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5513D114.6030303@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <5512C149.2060708@redhat.com> <5513D114.6030303@redhat.com> Message-ID: <5514AB98.3030209@oracle.com> On 3/26/2015 2:27 AM, Andrew Haley wrote: > On 25/03/15 14:08, Andrew Dinn wrote: >> On 25/03/15 13:28, Zolt?n Maj? wrote: >>> On 03/25/2015 02:02 PM, Edward Nevill wrote: >>>> The aarch64 C2 compiler makes no use of the FP register even though >>>> this register is saved on entry and restored on exit and is therefore >>>> always available for allocation. >>> It seems to me that the C2 compiler currently saves the SP into FP on >>> method handle invokes. This functionality is encoded by >>> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages >>> of FrameMap::method_handle_invoke_SP_save_opr()). >> Yes, that's correct. aarch64_enc_java_handle relies on having FP >> available to save SP. So, it looks like this fix will break that. > I'm surprised it matters. If FP is live around a handle call I would > have thought it would be spilled onto the stack. If you can confirm that it is indeed spilled, then I would think the proposed change is good. You probabably want to double-check what happens at safepoints as well. I don't think "NS" registers are spilled at safepoints, which may be OK as long as stack walking still works. dl > Andrew. > From serguei.spitsyn at oracle.com Fri Mar 27 02:36:21 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 26 Mar 2015 19:36:21 -0700 Subject: RFR (S) 8073705: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <5514A939.1090200@oracle.com> References: <5514A939.1090200@oracle.com> Message-ID: <5514C225.1030701@oracle.com> Sorry, please, skip this email. The subject was copied from another bug. I'll re-post the RFR shortly. Thanks, Serguei On 3/26/15 5:50 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8073705 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ > > > > Summary: > > This is the 2-nd round of performance/calability fixes in class > redefinition. > This time, the two remaining issues that were left alone in the > first round fix: > - optimized ConstantPoolCache::adjust_method_entries() is used > for previous versions > - the MemberNameTable::adjust_method_entries() has been optimized > too > - some cleanup > > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument, > com/sun/jdi > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Fri Mar 27 02:38:57 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 26 Mar 2015 19:38:57 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition Message-ID: <5514C2C1.9040302@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8073705 Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ Summary: This is the 2-nd round of performance/calability fixes in class redefinition. This time, the two remaining issues that were left alone in the first round fix: - optimized ConstantPoolCache::adjust_method_entries() is used for previous versions - the MemberNameTable::adjust_method_entries() has been optimized too - some cleanup Testing: In progress: nsk redefine classes tests, JTREG java/lang/instrument, com/sun/jdi Thanks, Serguei From thomas.stuefe at gmail.com Fri Mar 27 06:46:34 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2015 07:46:34 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55146984.7090709@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> <551444D4.3040706@oracle.com> <55146984.7090709@oracle.com> Message-ID: Colleen, David, can we all agree an Colleens proposal: inline bool CanUseSafeFetch32() { return NOT_ZERO(StubRoutines::SafeFetch32_stub() != NULL) ZERO_ONLY(false); } ? If that is ok, I make a patch for that. As for objectMonitor: >> So I thought of changing the objectMonitor code to do >> if (CanUseSafeFetchN) { >> SafeFetchN(...) >> } else { >> just fetch unsafely >> } >> > > This serves no purpose and adds overheads in the monitor code. We don't > need the "have the stubs been generated" check for this code. And the "can > I use ZERO" check would be pointless: if safefetch on zero doesn't work > then SafeFetch may crash; if you take the else then it may also crash - > same result both code paths, so no point. > > But this documents the intent clearly. We want to access the memory safely, unless we cannot do SafeFetch, then we risk a direct load. That said, I have not many emotions here. I think in the long run SafeFetch can/will be implemented on zero. Kind Regards, Thomas David > > There's also a SafeFetch32 call around that same place that would also >> have to be changed this way. >> >> But I thought it was messy to add this conditional code since the result >> for Zero would be the exactly the same in this place. So I chose >> CanUseSafeFetch to mean SafeFetch isn't safe and protected code the test >> code that way and not the ObjectMonitor code. >> >> I don't mind if this is reversed as long as it's not messy and is tested. >> >> Coleen >> >> On 3/26/15, 9:46 AM, Thomas St?fe wrote: >> >>> Hi David, >>> >>> you are right, it was also broken before. I missed that Coleen just >>> reintroduced an earlier version of the dummy SafeFetch() >>> implementation, sorry for that. >>> >>> I would be happy with a CanUseSafeFetch() which returns always false >>> on zero and false on other platforms before stub generation. That >>> would be always safe to call. >>> >>> Kind Regards, Thomas >>> >>> >>> On Thu, Mar 26, 2015 at 1:38 PM, David Holmes >> > wrote: >>> >>> On 26/03/2015 10:24 PM, Thomas St?fe wrote: >>> >>> Hi David, >>> >>> On Thu, Mar 26, 2015 at 11:42 AM, David Holmes >>> >>> >> >>> >> wrote: >>> >>> Hi Thomas, >>> >>> On 26/03/2015 6:35 PM, Thomas St?fe wrote: >>> >>> Hi, >>> >>> I agree with Goetz. >>> >>> SafeFetch() was meant to be guarded with >>> CanUseSafeFetch(), this >>> is part >>> of the contract, so using it without this guard is >>> actually >>> incorrect >>> and would crash were the calling code ever called >>> before Stub >>> routine >>> initialization. >>> >>> >>> That contract was already implicit - this API is for use >>> after the >>> stubs have been generated. There's no reason to expand the >>> use of >>> this API to situations before stubs are generated. So the >>> assert >>> captures that and CanUseSafeFetch is really unnecessary. >>> >>> >>> We had to introduce CanUseSafeFetch() exactly because we have >>> situations >>> where we may call SafeFetch before stub routine generation: >>> >>> 1) In os_aix.cpp, we use it to probe protected memory after doing >>> mprotect(). This is a long story, but we had to add this >>> workaround >>> because on shortcomings in AIX's mprotect(). This code will >>> get called >>> during initialization before stub routines are set up. >>> Note that right now, in the OpenJDK code base, the code still >>> directly >>> checks whether the stubroutine is NULL, because that mprotect >>> workaround >>> is older than 8074552. But I planned to change this to >>> CanUseSafeFetch(). But with the new CanUseSafeFetch, this >>> would just >>> break AIX. >>> >>> 2) In SAPs code base, we also use it to harden error log >>> writing (e.g. >>> to make callstack dumping more reliable). This may can be >>> invoked very >>> early, if a crash happens very early, before stub routines are >>> available. We planned to contribute those improvements piece >>> by piece to >>> the OpenJDK - my first change for 8074552 was actually supposed >>> to >>> prepare that. Now, however, this makes no sense, because using >>> SafeFetch() to harden error log writing would actually be >>> worse for >>> error logs for early crashes. >>> >>> SafeFetch is a very basic function which could be useful in >>> many more >>> contexts, but only if you can really be sure it is safe. The >>> contexts it >>> is used in may be very low level where you cannot be sure at >>> which point >>> in VM initialization you are. >>> >>> When I introduced CanUseSafeFetch(), it was to safeguard the >>> use of >>> SafeFetch() for situations where SafeFetch was not safe to >>> call. Exactly >>> so that I would have not to think about "is this too early to use >>> SafeFetch()?". This is broken now - instead of guarding me >>> against using >>> SafeFetch() in situations where it is not safe to use, it will >>> assert(debug) or potentially lie(release), in which case >>> SafeFetch >>> itself may crash. >>> >>> >>> Okay I see a case for adding a check for "can I use SafeFetch at >>> this point in time" (though if what you are fetching is >>> potentially not-safe then you are in trouble!). >>> >>> So now >>> - CanUseSafeFetch really now means "SafeFetch will >>> behave as >>> excpected" >>> - SafeFetch is softened to "will safely fetch content >>> of address >>> unless on zero, there it may crash the VM". >>> >>> I think this is more confusing than before. In >>> objectMonitor, >>> the logic >>> we want is "use SafeFetch wherever possible but if >>> not, just >>> access the >>> memory directly". This logic now is hidden behind a >>> seemingly >>> incorrect >>> use of SafeFetch without CanUseSafeFetch, and I think >>> Goetz proposal >>> would have been far more clearer. >>> >>> >>> No the problem is that SafeFetch doesn't work on ZERO - if >>> you give >>> it a bad address it won't recover it will crash. The whole >>> point is >>> for it not to crash. The objectMonitor code is saying >>> "here is a >>> load that we know may be invalid, but if it is then we >>> don't want to >>> crash, so we use SafeFetch". >>> >>> >>> Yes! But the way it is coded, it does not. Because SafeFetch >>> is now >>> implemented on zero with a simple load, it is not safe at all. >>> The code >>> in objectMonitor.cpp appears to be safe, but it is not. And >>> SafeFetch() >>> promises to be safe, but it is not, and you would not know >>> unless you >>> know the zero implementation. >>> >>> >>> Sorry did I miss something - has Zero ever implemented SafeFetch >>> as other than a direct simple load? ie hasn't Zero always been >>> broken wrt SafeFetch and that is the basic problem ? >>> >>> It seems to be a bit inconsequent. Either one is really sure >>> the pointer >>> is accessible - in which case why use SafeFetch? - or it may >>> be invalid, >>> even if this is unusual - in which case why is the resulting >>> crash not a >>> problem for zero? >>> In other words, if the original programmer thought it worth to >>> guard the >>> memory access with SafeFetch(), why is this not a concern for >>> zero? >>> >>> >>> It is - which is why Zero is broken. >>> >>> The expectation is that SafeFetch actually is safe no >>> matter what is >>> fetched. >>> >>> >>> Yes, and that expectation is broken now. >>> >>> >>> When was it not broken? >>> >>> Before, if you used SafeFetch() and guarded it with >>> CanUseSafeFetch(), >>> you could be sure to be safe and not to break anything - >>> regardless when >>> in VM life you used the function or on which platform. >>> >>> >>> No you only knew that a function called SafeFetch could be called >>> - you didn't know it was actually implemented to actually always >>> do a "safe fetch". >>> >>> Both SafeFetch and CanUseSafeFetch made promises: >>> - CanUseSafeFetch promised to tell me if it is too early to call >>> SafeFetch. Of course, it itself could be called at all times, >>> that was >>> the whole point of CanUseSafeFetch. >>> - SafeFetch promised to be able to access a potentially >>> invalid pointer >>> and not to crash - if CanUseSafeFetch returned true. >>> >>> >>> SafeFetch (if it exists) promises to be safe. The ZERO >>> implementation breaks that. >>> >>> Both promises are broken now. CanUseSafeFetch is not safe to >>> call if it >>> is too early - ironically a condition it was designed to tell me. >>> >>> >>> Okay we will re-fix that. >>> >>> SafeFetch is not safe to call because it lies about being safe >>> for zero. >>> >>> >>> It never was safe to call as far as I can see, it was just never >>> called with an invalid value. The new test exposed this. >>> >>> David >>> ----- >>> >>> The result is that either if we continue to use SafeFetch, we >>> risk >>> crashes on zero and crashes if invoked too early. This makes >>> the API >>> useless for most cases. >>> >>> I am open to any other suggestions - renaming the APIs, maybe >>> reshaping >>> them - but I regret seeing SafeFetch being back to being quite >>> unsafe again. >>> >>> Kind Regards, Thomas >>> >>> >>> The ZERO implementation just does a load and hopes it >>> isn't asked >>> for anything bad. The objectMonitor code will rarely actually >>> trigger a bad load. But the newly introduced test does. >>> >>> So in my opinion to return to the status-quo where ZERO >>> really >>> doesn't implement SafeFetch safely but it "works okay in >>> practice", >>> we should disable those explicit tests when running on ZERO. >>> >>> Whether CanUseSafeFetch (aka is SafeFetchStubAvailable) is >>> implemented explicitly or implicitly as an assert is a >>> side-issue. >>> >>> David >>> >>> Kind Regards, Thomas >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Mar 26, 2015 at 8:40 AM, Lindenmaier, Goetz >>> >> >>> >> > >>> >> __com >>> >> >>> >>> wrote: >>> >>> Hi, >>> >>> sorry I only comment on this now ... >>> I think it's rather strange that you can not use >>> SafeFetch >>> on zero, >>> but it's there, >>> and it's actually used ... which will be the >>> situation >>> after this >>> change. >>> >>> Why not just change objectMonitor as the >>> SafeFetch api is >>> meant to >>> be used? >>> Obviously zero takes care that this access always >>> succeeds: >>> >>> diff -r a35854c84d9d >>> src/share/vm/runtime/__objectMonitor.cpp >>> --- a/src/share/vm/runtime/__objectMonitor.cpp >>> Wed Mar >>> 25 12:36:28 >>> 2015 +0100 >>> +++ b/src/share/vm/runtime/__objectMonitor.cpp >>> Thu Mar >>> >>> 26 08:19:53 >>> 2015 +0100 >>> @@ -2241,7 +2241,12 @@ >>> } >>> >>> assert(sizeof(((JavaThread >>> *)ox)->_thread_state == >>> sizeof(int)), >>> "invariant"); >>> - int jst = SafeFetch32((int *) &((JavaThread *) >>> ox)->_thread_state, -1);; >>> + int jst; >>> + if (CanUseSafeFetch32()) { >>> + jst = SafeFetch32((int *) &((JavaThread *) >>> ox)->_thread_state, -1); >>> + } else { >>> + jst = ((JavaThread *)ox)->_thread_state; >>> + } >>> // consider also: jst != _thread_in_Java -- >>> but that's >>> overspecific. >>> return jst == _thread_blocked || jst == >>> _thread_in_native; >>> } >>> >>> It's handled similarly in vmError.cpp. And no >>> #ifdefs ;) >>> >>> But I'm also fine with the other change ... to >>> get zero >>> working again. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: hotspot-dev >>> [mailto:hotspot-dev-bounces@ >>> __openjdk.java.net >>> >>> >> > >>> >> __openjdk.java.net >>> >>> >> >>> >>] On Behalf Of >>> Coleen >>> Phillimore >>> Sent: Thursday, March 26, 2015 3:30 AM >>> To: David Holmes; hotspot-dev developers >>> Subject: Re: RFR (xs) 8075967: Zero interpreter >>> asserts for >>> SafeFetch<32, N> calls in ObjectMonitor >>> >>> >>> On 3/25/15, 10:15 PM, David Holmes wrote: >>> > On 26/03/2015 11:00 AM, Coleen Phillimore wrote: >>> >> >>> >> On 3/25/15, 8:21 PM, David Holmes wrote: >>> >>> On 26/03/2015 10:04 AM, Coleen Phillimore >>> wrote: >>> >>>> >>> >>>> On 3/25/15, 7:59 PM, David Holmes wrote: >>> >>>>> Hi Coleen, >>> >>>>> >>> >>>>> Why generate stubs that can't be used and >>> then add >>> zero-specific >>> >>>>> logic >>> >>>>> to the shared CanUseSafeFetchN instead of not >>> generating the >>> stubs so >>> >>>>> that CanUseSafeFetchN will return false >>> anyway ?? >>> >>>> >>> >>>> Because there is platform independent code in >>> objectMonitor.cpp that >>> >>>> uses SafeFetchX (both). I'd rather not >>> burden the >>> caller of >>> this with >>> >>>> testing CanUseSafeFetchX for each call. >>> This code >>> existed before >>> >>>> SafeFetch was implemented, so I'm restoring >>> previous >>> behavior for >>> >>>> Zero. >>> >>> >>> >>> Sorry Coleen I thought this was deal to with >>> 8075533, >>> I hadn't >>> >>> realized 8075533 broke the objectMonitor >>> code and this >>> was a >>> follow up. >>> >>> >>> >>> What a mess. :( >>> >> >>> >> Yes, it is. Is this a code Review? >>> > >>> > Let me work through this :) The original >>> change for 8074552: >>> > >>> > >>> http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__ >>> 3eb61269f421 >>> >>> >>> > >>> > added the extra error handling stuff related to >>> SafeFetch and a new >>> > ErrorHandler test that was predicated on >>> CanUseSafeFetch32 which >>> > returns true if the stubs exist. It also added >>> testing of >>> SafeFetch in >>> > StubRoutines::initialize2 which was excluded for >>> windows-32-bit and >>> > which did not check CanUseSafeFetch32. >>> > >>> > That change broke zero as reported in 8075533 >>> because >>> you can't >>> > actually use the SafeFetch routines with an >>> unsafe >>> address on Zero, >>> > and the solution: >>> > >>> > >>> http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__ >>> 5c2bc6278fc4 >>> >>> >>> >>> >>> > >>> > was to remove the stubs so that >>> CanUseSafeFetch32 would >>> return false, >>> > and to include a check of CanUseSafeFetch32 in >>> the tests >>> used with >>> > StubRoutines::initialize2. >>> > >>> > And now we find that the SafeFetch routines >>> are used >>> unconditionally >>> > by the objectMonitor code, so we need to >>> restore the >>> stubs that were >>> > previously removed, but force CanUseSafeFetch32 >>> to >>> return false >>> on zero. >>> >>> Yes, exactly. >>> > >>> > Ok. Only nit is that: >>> > >>> > return NOT_ZERO(true) ZERO_ONLY(false); >>> >>> Yes, you're right. I'll make that change. >>> >>> Thanks! >>> Coleen >>> >>> > >>> > would be more readable than the ifdefs. >>> > >>> > Thanks, >>> > David >>> > >>> >> thanks! >>> >> Coleen >>> >>> >>> >>> Thanks, >>> >>> David >>> >>> >>> >>> >>> >>> >>> >>>> We could file an RFE to either implement >>> SafeFetch >>> for Zero or >>> rewrite >>> >>>> this objectMonitor code to not need >>> SafeFetch. I >>> didn't want >>> to do >>> >>>> either of these things with this patch. >>> >>>> >>> >>>> Coleen >>> >>>> >>> >>>>> >>> >>>>> Thanks, >>> >>>>> David >>> >>>>> >>> >>>>> On 26/03/2015 3:53 AM, Coleen Phillimore >>> wrote: >>> >>>>>> Summary: Implement SafeFetchX unsafely >>> and make >>> CanUseSafeFetchX >>> >>>>>> false >>> >>>>>> for Zero >>> >>>>>> >>> >>>>>> Also, this fixes a couple other minor >>> issues. >>> >>>>>> >>> >>>>>> Ran jdk9 jck tests with one timeout. >>> hotspot/runtime jtreg >>> tests >>> >>>>>> don't >>> >>>>>> run because Zero doesn't support >>> UseCompressedOops >>> (not sure >>> why) >>> >>>>>> and >>> >>>>>> CDS (know why). >>> >>>>>> >>> >>>>>> open webrev at >>> http://cr.openjdk.java.net/~__coleenp/8075967/ >>> >>> >> > >>> >>>>>> bug link >>> https://bugs.openjdk.java.net/__browse/JDK-8075967 >>> >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> Coleen >>> >>>> >>> >> >>> >>> >>> >>> >>> >> From david.holmes at oracle.com Fri Mar 27 07:11:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Mar 2015 17:11:16 +1000 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> <551444D4.3040706@oracle.com> <55146984.7090709@oracle.com> Message-ID: <55150294.9040308@oracle.com> On 27/03/2015 4:46 PM, Thomas St?fe wrote: > Colleen, David, > > can we all agree an Colleens proposal: > > inline bool CanUseSafeFetch32() { > return NOT_ZERO(StubRoutines::SafeFetch32_stub() != NULL) > ZERO_ONLY(false); > } > > ? > > If that is ok, I make a patch for that. I can accept the above as a way to stop the test code from being executed on ZERO - but it is really conflating two issues: are the safefetch routines available for use yet; do they work. The real intent for this method was the former only. The latter for ZERO is just a workaround. > As for objectMonitor: > > > So I thought of changing the objectMonitor code to do > if (CanUseSafeFetchN) { > SafeFetchN(...) > } else { > just fetch unsafely > } > > > This serves no purpose and adds overheads in the monitor code. We > don't need the "have the stubs been generated" check for this code. > And the "can I use ZERO" check would be pointless: if safefetch on > zero doesn't work then SafeFetch may crash; if you take the else > then it may also crash - same result both code paths, so no point. > > > But this documents the intent clearly. We want to access the memory > safely, unless we cannot do SafeFetch, then we risk a direct load. The existence of the stubs is not relevant to this code. This says I need to do a SafeFetch - end of story. SafeFetch is assumed to be implemented correctly - if it can't be then that is an internal matter for SafeFetch on that platform. The users of SafeFetch should not have to be concerned about whether it has been implemented correctly. > That said, I have not many emotions here. I think in the long run > SafeFetch can/will be implemented on zero. Good to hear. Thanks, David > Kind Regards, Thomas > > David > > There's also a SafeFetch32 call around that same place that > would also > have to be changed this way. > > But I thought it was messy to add this conditional code since > the result > for Zero would be the exactly the same in this place. So I chose > CanUseSafeFetch to mean SafeFetch isn't safe and protected code > the test > code that way and not the ObjectMonitor code. > > I don't mind if this is reversed as long as it's not messy and > is tested. > > Coleen > > On 3/26/15, 9:46 AM, Thomas St?fe wrote: > > Hi David, > > you are right, it was also broken before. I missed that > Coleen just > reintroduced an earlier version of the dummy SafeFetch() > implementation, sorry for that. > > I would be happy with a CanUseSafeFetch() which returns > always false > on zero and false on other platforms before stub generation. > That > would be always safe to call. > > Kind Regards, Thomas > > > On Thu, Mar 26, 2015 at 1:38 PM, David Holmes > > >> wrote: > > On 26/03/2015 10:24 PM, Thomas St?fe wrote: > > Hi David, > > On Thu, Mar 26, 2015 at 11:42 AM, David Holmes > > > > > > >>> wrote: > > Hi Thomas, > > On 26/03/2015 6:35 PM, Thomas St?fe wrote: > > Hi, > > I agree with Goetz. > > SafeFetch() was meant to be guarded with > CanUseSafeFetch(), this > is part > of the contract, so using it without this > guard is > actually > incorrect > and would crash were the calling code ever > called > before Stub > routine > initialization. > > > That contract was already implicit - this API > is for use > after the > stubs have been generated. There's no reason to > expand the > use of > this API to situations before stubs are > generated. So the > assert > captures that and CanUseSafeFetch is really > unnecessary. > > > We had to introduce CanUseSafeFetch() exactly > because we have > situations > where we may call SafeFetch before stub routine > generation: > > 1) In os_aix.cpp, we use it to probe protected > memory after doing > mprotect(). This is a long story, but we had to add > this > workaround > because on shortcomings in AIX's mprotect(). This > code will > get called > during initialization before stub routines are set up. > Note that right now, in the OpenJDK code base, the > code still > directly > checks whether the stubroutine is NULL, because > that mprotect > workaround > is older than 8074552. But I planned to change this to > CanUseSafeFetch(). But with the new > CanUseSafeFetch, this > would just > break AIX. > > 2) In SAPs code base, we also use it to harden > error log > writing (e.g. > to make callstack dumping more reliable). This may > can be > invoked very > early, if a crash happens very early, before stub > routines are > available. We planned to contribute those > improvements piece > by piece to > the OpenJDK - my first change for 8074552 was > actually supposed to > prepare that. Now, however, this makes no sense, > because using > SafeFetch() to harden error log writing would > actually be > worse for > error logs for early crashes. > > SafeFetch is a very basic function which could be > useful in > many more > contexts, but only if you can really be sure it is > safe. The > contexts it > is used in may be very low level where you cannot > be sure at > which point > in VM initialization you are. > > When I introduced CanUseSafeFetch(), it was to > safeguard the > use of > SafeFetch() for situations where SafeFetch was not > safe to > call. Exactly > so that I would have not to think about "is this > too early to use > SafeFetch()?". This is broken now - instead of > guarding me > against using > SafeFetch() in situations where it is not safe to > use, it will > assert(debug) or potentially lie(release), in which > case SafeFetch > itself may crash. > > > Okay I see a case for adding a check for "can I use > SafeFetch at > this point in time" (though if what you are fetching is > potentially not-safe then you are in trouble!). > > So now > - CanUseSafeFetch really now means > "SafeFetch will > behave as > excpected" > - SafeFetch is softened to "will safely > fetch content > of address > unless on zero, there it may crash the VM". > > I think this is more confusing than before. In > objectMonitor, > the logic > we want is "use SafeFetch wherever possible > but if > not, just > access the > memory directly". This logic now is hidden > behind a > seemingly > incorrect > use of SafeFetch without CanUseSafeFetch, > and I think > Goetz proposal > would have been far more clearer. > > > No the problem is that SafeFetch doesn't work > on ZERO - if > you give > it a bad address it won't recover it will > crash. The whole > point is > for it not to crash. The objectMonitor code is > saying > "here is a > load that we know may be invalid, but if it is > then we > don't want to > crash, so we use SafeFetch". > > > Yes! But the way it is coded, it does not. Because > SafeFetch > is now > implemented on zero with a simple load, it is not > safe at all. > The code > in objectMonitor.cpp appears to be safe, but it is > not. And > SafeFetch() > promises to be safe, but it is not, and you would > not know > unless you > know the zero implementation. > > > Sorry did I miss something - has Zero ever implemented > SafeFetch > as other than a direct simple load? ie hasn't Zero > always been > broken wrt SafeFetch and that is the basic problem ? > > It seems to be a bit inconsequent. Either one is > really sure > the pointer > is accessible - in which case why use SafeFetch? - > or it may > be invalid, > even if this is unusual - in which case why is the > resulting > crash not a > problem for zero? > In other words, if the original programmer thought > it worth to > guard the > memory access with SafeFetch(), why is this not a > concern for > zero? > > > It is - which is why Zero is broken. > > The expectation is that SafeFetch actually is > safe no > matter what is > fetched. > > > Yes, and that expectation is broken now. > > > When was it not broken? > > Before, if you used SafeFetch() and guarded it with > CanUseSafeFetch(), > you could be sure to be safe and not to break > anything - > regardless when > in VM life you used the function or on which platform. > > > No you only knew that a function called SafeFetch could > be called > - you didn't know it was actually implemented to > actually always > do a "safe fetch". > > Both SafeFetch and CanUseSafeFetch made promises: > - CanUseSafeFetch promised to tell me if it is too > early to call > SafeFetch. Of course, it itself could be called at > all times, > that was > the whole point of CanUseSafeFetch. > - SafeFetch promised to be able to access a potentially > invalid pointer > and not to crash - if CanUseSafeFetch returned true. > > > SafeFetch (if it exists) promises to be safe. The ZERO > implementation breaks that. > > Both promises are broken now. CanUseSafeFetch is > not safe to > call if it > is too early - ironically a condition it was > designed to tell me. > > > Okay we will re-fix that. > > SafeFetch is not safe to call because it lies about > being safe > for zero. > > > It never was safe to call as far as I can see, it was > just never > called with an invalid value. The new test exposed this. > > David > ----- > > The result is that either if we continue to use > SafeFetch, we risk > crashes on zero and crashes if invoked too early. > This makes > the API > useless for most cases. > > I am open to any other suggestions - renaming the > APIs, maybe > reshaping > them - but I regret seeing SafeFetch being back to > being quite > unsafe again. > > Kind Regards, Thomas > > > The ZERO implementation just does a load and > hopes it > isn't asked > for anything bad. The objectMonitor code will > rarely actually > trigger a bad load. But the newly introduced > test does. > > So in my opinion to return to the status-quo > where ZERO really > doesn't implement SafeFetch safely but it > "works okay in > practice", > we should disable those explicit tests when > running on ZERO. > > Whether CanUseSafeFetch (aka is > SafeFetchStubAvailable) is > implemented explicitly or implicitly as an > assert is a > side-issue. > > David > > Kind Regards, Thomas > > > > > > > > On Thu, Mar 26, 2015 at 8:40 AM, > Lindenmaier, Goetz > > > > > >> > . > .__>__com > > > >>>> wrote: > > Hi, > > sorry I only comment on this now ... > I think it's rather strange that you > can not use > SafeFetch > on zero, > but it's there, > and it's actually used ... which will > be the > situation > after this > change. > > Why not just change objectMonitor as the > SafeFetch api is > meant to > be used? > Obviously zero takes care that this > access always > succeeds: > > diff -r a35854c84d9d > src/share/vm/runtime/____objectMonitor.cpp > --- > a/src/share/vm/runtime/____objectMonitor.cpp > Wed Mar > 25 12:36:28 > 2015 +0100 > +++ > b/src/share/vm/runtime/____objectMonitor.cpp > Thu Mar > > 26 08:19:53 > 2015 +0100 > @@ -2241,7 +2241,12 @@ > } > > assert(sizeof(((JavaThread > *)ox)->_thread_state == > sizeof(int)), > "invariant"); > - int jst = SafeFetch32((int *) > &((JavaThread *) > ox)->_thread_state, -1);; > + int jst; > + if (CanUseSafeFetch32()) { > + jst = SafeFetch32((int *) > &((JavaThread *) > ox)->_thread_state, -1); > + } else { > + jst = ((JavaThread > *)ox)->_thread_state; > + } > // consider also: jst != > _thread_in_Java -- > but that's > overspecific. > return jst == _thread_blocked || > jst == > _thread_in_native; > } > > It's handled similarly in vmError.cpp. > And no > #ifdefs ;) > > But I'm also fine with the other > change ... to > get zero > working again. > > Best regards, > Goetz. > > > > -----Original Message----- > From: hotspot-dev > [mailto:hotspot-dev-bounces@ > > >____openjdk.java.net > > > > > >> > > >____openjdk.java.net > > > > > > >>>] On Behalf Of > Coleen > Phillimore > Sent: Thursday, March 26, 2015 3:30 AM > To: David Holmes; hotspot-dev developers > Subject: Re: RFR (xs) 8075967: Zero > interpreter > asserts for > SafeFetch<32, N> calls in ObjectMonitor > > > On 3/25/15, 10:15 PM, David Holmes wrote: > > On 26/03/2015 11:00 AM, Coleen > Phillimore wrote: > >> > >> On 3/25/15, 8:21 PM, David Holmes > wrote: > >>> On 26/03/2015 10:04 AM, Coleen > Phillimore wrote: > >>>> > >>>> On 3/25/15, 7:59 PM, David > Holmes wrote: > >>>>> Hi Coleen, > >>>>> > >>>>> Why generate stubs that can't > be used and > then add > zero-specific > >>>>> logic > >>>>> to the shared CanUseSafeFetchN > instead of not > generating the > stubs so > >>>>> that CanUseSafeFetchN will > return false > anyway ?? > >>>> > >>>> Because there is platform > independent code in > objectMonitor.cpp that > >>>> uses SafeFetchX (both). I'd > rather not > burden the > caller of > this with > >>>> testing CanUseSafeFetchX for > each call. > This code > existed before > >>>> SafeFetch was implemented, so > I'm restoring > previous > behavior for > >>>> Zero. > >>> > >>> Sorry Coleen I thought this was > deal to with > 8075533, > I hadn't > >>> realized 8075533 broke the > objectMonitor > code and this > was a > follow up. > >>> > >>> What a mess. :( > >> > >> Yes, it is. Is this a code Review? > > > > Let me work through this :) The > original > change for 8074552: > > > > > http://hg.openjdk.java.net/____jdk9/hs-rt/hotspot/rev/____3eb61269f421 > > > > > > > > > added the extra error handling > stuff related to > SafeFetch and a new > > ErrorHandler test that was > predicated on > CanUseSafeFetch32 which > > returns true if the stubs exist. It > also added > testing of > SafeFetch in > > StubRoutines::initialize2 which was > excluded for > windows-32-bit and > > which did not check CanUseSafeFetch32. > > > > That change broke zero as reported > in 8075533 > because > you can't > > actually use the SafeFetch routines > with an unsafe > address on Zero, > > and the solution: > > > > > http://hg.openjdk.java.net/____jdk9/hs-rt/hotspot/rev/____5c2bc6278fc4 > > > > > > > > > > > was to remove the stubs so that > CanUseSafeFetch32 would > return false, > > and to include a check of > CanUseSafeFetch32 in > the tests > used with > > StubRoutines::initialize2. > > > > And now we find that the SafeFetch > routines > are used > unconditionally > > by the objectMonitor code, so we > need to > restore the > stubs that were > > previously removed, but force > CanUseSafeFetch32 to > return false > on zero. > > Yes, exactly. > > > > Ok. Only nit is that: > > > > return NOT_ZERO(true) ZERO_ONLY(false); > > Yes, you're right. I'll make that change. > > Thanks! > Coleen > > > > > would be more readable than the ifdefs. > > > > Thanks, > > David > > > >> thanks! > >> Coleen > >>> > >>> Thanks, > >>> David > >>> > >>> > >>> > >>>> We could file an RFE to either > implement > SafeFetch > for Zero or > rewrite > >>>> this objectMonitor code to not need > SafeFetch. I > didn't want > to do > >>>> either of these things with this > patch. > >>>> > >>>> Coleen > >>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 26/03/2015 3:53 AM, Coleen > Phillimore > wrote: > >>>>>> Summary: Implement SafeFetchX > unsafely > and make > CanUseSafeFetchX > >>>>>> false > >>>>>> for Zero > >>>>>> > >>>>>> Also, this fixes a couple > other minor issues. > >>>>>> > >>>>>> Ran jdk9 jck tests with one > timeout. > hotspot/runtime jtreg > tests > >>>>>> don't > >>>>>> run because Zero doesn't support > UseCompressedOops > (not sure > why) > >>>>>> and > >>>>>> CDS (know why). > >>>>>> > >>>>>> open webrev at > http://cr.openjdk.java.net/~____coleenp/8075967/ > > > > > > >> > >>>>>> bug link > https://bugs.openjdk.java.net/____browse/JDK-8075967 > > > > > >>>>>> > >>>>>> Thanks, > >>>>>> Coleen > >>>> > >> > > > > > > From goetz.lindenmaier at sap.com Fri Mar 27 07:58:45 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Mar 2015 07:58:45 +0000 Subject: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB8DBE@DEWDFEMB12A.global.corp.sap> Hi, on Aix, we don't support large pages. This needs to be manifested in arguments.cpp. The change simply reuses a #ifdef BSD for AIX, too. Please review this tiny change, and I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8076057-aixULP/webrev.00/ Best regards, Goetz. From goetz.lindenmaier at sap.com Fri Mar 27 08:06:22 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Mar 2015 08:06:22 +0000 Subject: RFR(L): 8075506: aix: improve handling of native memory In-Reply-To: <5512F608.6070709@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFB69B7@DEWDFEMB12A.global.corp.sap> <5512F608.6070709@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB8DDC@DEWDFEMB12A.global.corp.sap> Thanks Vladimir! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Mittwoch, 25. M?rz 2015 18:53 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(L): 8075506: aix: improve handling of native memory Looks good. I only glanced through os_aix.cpp changes - they look fine from 'glance'. Could you explain a little about allocate_stack_guard_pages() returning false? The comment say that you are not using normal C stack. Is it true? Thanks, Vladimir On 3/25/15 1:22 AM, Lindenmaier, Goetz wrote: > Hi, > > this change improves handling of native memory on aix. It adds support for > 64K pages and allocation at requested addresses. This improves performance > by a few percent. > > Please review this change. It is aix-only. > http://cr.openjdk.java.net/~goetz/webrevs/8075506-aixMem/webrev.00/ > > Best regards, > Goetz. > From thomas.stuefe at gmail.com Fri Mar 27 08:37:02 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2015 09:37:02 +0100 Subject: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB8DBE@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFB8DBE@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, looks fine. Regards, Thomas On Fri, Mar 27, 2015 at 8:58 AM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > on Aix, we don't support large pages. > This needs to be manifested in arguments.cpp. > The change simply reuses a #ifdef BSD for AIX, too. > > Please review this tiny change, and I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8076057-aixULP/webrev.00/ > > Best regards, > Goetz. > From thomas.stuefe at gmail.com Fri Mar 27 08:45:06 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2015 09:45:06 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <55150294.9040308@oracle.com> References: <5512F600.9050102@oracle.com> <55134BC7.8070606@oracle.com> <55134CF1.2020909@oracle.com> <55135127.60205@oracle.com> <55135A22.3030309@oracle.com> <55136BDE.9040000@oracle.com> <55136F11.7010900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFB7D11@DEWDFEMB12A.global.corp.sap> <5513E2A6.30500@oracle.com> <5513FDAE.4010608@oracle.com> <551444D4.3040706@oracle.com> <55146984.7090709@oracle.com> <55150294.9040308@oracle.com> Message-ID: Hi David, On Fri, Mar 27, 2015 at 8:11 AM, David Holmes wrote: > On 27/03/2015 4:46 PM, Thomas St?fe wrote: > >> Colleen, David, >> >> can we all agree an Colleens proposal: >> >> inline bool CanUseSafeFetch32() { >> return NOT_ZERO(StubRoutines::SafeFetch32_stub() != NULL) >> ZERO_ONLY(false); >> } >> >> ? >> >> If that is ok, I make a patch for that. >> > > I can accept the above as a way to stop the test code from being executed > on ZERO - but it is really conflating two issues: are the safefetch > routines available for use yet; do they work. The real intent for this > method was the former only. The latter for ZERO is just a workaround. > > ok, I can live with that. We can leave this as workaround instead of fixing up all uses of SafeFetch with "#ifdef ZERO" and when SafeFetch is implemented, just remove the is-zero condition. > As for objectMonitor: >> >> >> So I thought of changing the objectMonitor code to do >> if (CanUseSafeFetchN) { >> SafeFetchN(...) >> } else { >> just fetch unsafely >> } >> >> >> This serves no purpose and adds overheads in the monitor code. We >> don't need the "have the stubs been generated" check for this code. >> And the "can I use ZERO" check would be pointless: if safefetch on >> zero doesn't work then SafeFetch may crash; if you take the else >> then it may also crash - same result both code paths, so no point. >> >> >> But this documents the intent clearly. We want to access the memory >> safely, unless we cannot do SafeFetch, then we risk a direct load. >> > > The existence of the stubs is not relevant to this code. This says I need > to do a SafeFetch - end of story. SafeFetch is assumed to be implemented > correctly - if it can't be then that is an internal matter for SafeFetch on > that platform. The users of SafeFetch should not have to be concerned about > whether it has been implemented correctly. > > ok, you convince me. > That said, I have not many emotions here. I think in the long run >> SafeFetch can/will be implemented on zero. >> > > Good to hear. > > I'll experiment a bit and will try to make SafeFetch work on zero, as soon as I get zero to build... ..Thomas Thanks, > David > > Kind Regards, Thomas >> >> David >> >> There's also a SafeFetch32 call around that same place that >> would also >> have to be changed this way. >> >> But I thought it was messy to add this conditional code since >> the result >> for Zero would be the exactly the same in this place. So I chose >> CanUseSafeFetch to mean SafeFetch isn't safe and protected code >> the test >> code that way and not the ObjectMonitor code. >> >> I don't mind if this is reversed as long as it's not messy and >> is tested. >> >> Coleen >> >> On 3/26/15, 9:46 AM, Thomas St?fe wrote: >> >> Hi David, >> >> you are right, it was also broken before. I missed that >> Coleen just >> reintroduced an earlier version of the dummy SafeFetch() >> implementation, sorry for that. >> >> I would be happy with a CanUseSafeFetch() which returns >> always false >> on zero and false on other platforms before stub generation. >> That >> would be always safe to call. >> >> Kind Regards, Thomas >> >> >> On Thu, Mar 26, 2015 at 1:38 PM, David Holmes >> >> > >> wrote: >> >> On 26/03/2015 10:24 PM, Thomas St?fe wrote: >> >> Hi David, >> >> On Thu, Mar 26, 2015 at 11:42 AM, David Holmes >> > >> > > >> > >> >> > >> >>> wrote: >> >> Hi Thomas, >> >> On 26/03/2015 6:35 PM, Thomas St?fe wrote: >> >> Hi, >> >> I agree with Goetz. >> >> SafeFetch() was meant to be guarded with >> CanUseSafeFetch(), this >> is part >> of the contract, so using it without this >> guard is >> actually >> incorrect >> and would crash were the calling code ever >> called >> before Stub >> routine >> initialization. >> >> >> That contract was already implicit - this API >> is for use >> after the >> stubs have been generated. There's no reason to >> expand the >> use of >> this API to situations before stubs are >> generated. So the >> assert >> captures that and CanUseSafeFetch is really >> unnecessary. >> >> >> We had to introduce CanUseSafeFetch() exactly >> because we have >> situations >> where we may call SafeFetch before stub routine >> generation: >> >> 1) In os_aix.cpp, we use it to probe protected >> memory after doing >> mprotect(). This is a long story, but we had to add >> this >> workaround >> because on shortcomings in AIX's mprotect(). This >> code will >> get called >> during initialization before stub routines are set >> up. >> Note that right now, in the OpenJDK code base, the >> code still >> directly >> checks whether the stubroutine is NULL, because >> that mprotect >> workaround >> is older than 8074552. But I planned to change this >> to >> CanUseSafeFetch(). But with the new >> CanUseSafeFetch, this >> would just >> break AIX. >> >> 2) In SAPs code base, we also use it to harden >> error log >> writing (e.g. >> to make callstack dumping more reliable). This may >> can be >> invoked very >> early, if a crash happens very early, before stub >> routines are >> available. We planned to contribute those >> improvements piece >> by piece to >> the OpenJDK - my first change for 8074552 was >> actually supposed to >> prepare that. Now, however, this makes no sense, >> because using >> SafeFetch() to harden error log writing would >> actually be >> worse for >> error logs for early crashes. >> >> SafeFetch is a very basic function which could be >> useful in >> many more >> contexts, but only if you can really be sure it is >> safe. The >> contexts it >> is used in may be very low level where you cannot >> be sure at >> which point >> in VM initialization you are. >> >> When I introduced CanUseSafeFetch(), it was to >> safeguard the >> use of >> SafeFetch() for situations where SafeFetch was not >> safe to >> call. Exactly >> so that I would have not to think about "is this >> too early to use >> SafeFetch()?". This is broken now - instead of >> guarding me >> against using >> SafeFetch() in situations where it is not safe to >> use, it will >> assert(debug) or potentially lie(release), in which >> case SafeFetch >> itself may crash. >> >> >> Okay I see a case for adding a check for "can I use >> SafeFetch at >> this point in time" (though if what you are fetching is >> potentially not-safe then you are in trouble!). >> >> So now >> - CanUseSafeFetch really now means >> "SafeFetch will >> behave as >> excpected" >> - SafeFetch is softened to "will safely >> fetch content >> of address >> unless on zero, there it may crash the VM". >> >> I think this is more confusing than before. >> In >> objectMonitor, >> the logic >> we want is "use SafeFetch wherever possible >> but if >> not, just >> access the >> memory directly". This logic now is hidden >> behind a >> seemingly >> incorrect >> use of SafeFetch without CanUseSafeFetch, >> and I think >> Goetz proposal >> would have been far more clearer. >> >> >> No the problem is that SafeFetch doesn't work >> on ZERO - if >> you give >> it a bad address it won't recover it will >> crash. The whole >> point is >> for it not to crash. The objectMonitor code is >> saying >> "here is a >> load that we know may be invalid, but if it is >> then we >> don't want to >> crash, so we use SafeFetch". >> >> >> Yes! But the way it is coded, it does not. Because >> SafeFetch >> is now >> implemented on zero with a simple load, it is not >> safe at all. >> The code >> in objectMonitor.cpp appears to be safe, but it is >> not. And >> SafeFetch() >> promises to be safe, but it is not, and you would >> not know >> unless you >> know the zero implementation. >> >> >> Sorry did I miss something - has Zero ever implemented >> SafeFetch >> as other than a direct simple load? ie hasn't Zero >> always been >> broken wrt SafeFetch and that is the basic problem ? >> >> It seems to be a bit inconsequent. Either one is >> really sure >> the pointer >> is accessible - in which case why use SafeFetch? - >> or it may >> be invalid, >> even if this is unusual - in which case why is the >> resulting >> crash not a >> problem for zero? >> In other words, if the original programmer thought >> it worth to >> guard the >> memory access with SafeFetch(), why is this not a >> concern for >> zero? >> >> >> It is - which is why Zero is broken. >> >> The expectation is that SafeFetch actually is >> safe no >> matter what is >> fetched. >> >> >> Yes, and that expectation is broken now. >> >> >> When was it not broken? >> >> Before, if you used SafeFetch() and guarded it with >> CanUseSafeFetch(), >> you could be sure to be safe and not to break >> anything - >> regardless when >> in VM life you used the function or on which >> platform. >> >> >> No you only knew that a function called SafeFetch could >> be called >> - you didn't know it was actually implemented to >> actually always >> do a "safe fetch". >> >> Both SafeFetch and CanUseSafeFetch made promises: >> - CanUseSafeFetch promised to tell me if it is too >> early to call >> SafeFetch. Of course, it itself could be called at >> all times, >> that was >> the whole point of CanUseSafeFetch. >> - SafeFetch promised to be able to access a >> potentially >> invalid pointer >> and not to crash - if CanUseSafeFetch returned true. >> >> >> SafeFetch (if it exists) promises to be safe. The ZERO >> implementation breaks that. >> >> Both promises are broken now. CanUseSafeFetch is >> not safe to >> call if it >> is too early - ironically a condition it was >> designed to tell me. >> >> >> Okay we will re-fix that. >> >> SafeFetch is not safe to call because it lies about >> being safe >> for zero. >> >> >> It never was safe to call as far as I can see, it was >> just never >> called with an invalid value. The new test exposed this. >> >> David >> ----- >> >> The result is that either if we continue to use >> SafeFetch, we risk >> crashes on zero and crashes if invoked too early. >> This makes >> the API >> useless for most cases. >> >> I am open to any other suggestions - renaming the >> APIs, maybe >> reshaping >> them - but I regret seeing SafeFetch being back to >> being quite >> unsafe again. >> >> Kind Regards, Thomas >> >> >> The ZERO implementation just does a load and >> hopes it >> isn't asked >> for anything bad. The objectMonitor code will >> rarely actually >> trigger a bad load. But the newly introduced >> test does. >> >> So in my opinion to return to the status-quo >> where ZERO really >> doesn't implement SafeFetch safely but it >> "works okay in >> practice", >> we should disable those explicit tests when >> running on ZERO. >> >> Whether CanUseSafeFetch (aka is >> SafeFetchStubAvailable) is >> implemented explicitly or implicitly as an >> assert is a >> side-issue. >> >> David >> >> Kind Regards, Thomas >> >> >> >> >> >> >> >> On Thu, Mar 26, 2015 at 8:40 AM, >> Lindenmaier, Goetz >> > >> > > >> > >> > >> >> > . >> > .__>__com >> > >> >> > >>>> wrote: >> >> Hi, >> >> sorry I only comment on this now ... >> I think it's rather strange that you >> can not use >> SafeFetch >> on zero, >> but it's there, >> and it's actually used ... which will >> be the >> situation >> after this >> change. >> >> Why not just change objectMonitor as the >> SafeFetch api is >> meant to >> be used? >> Obviously zero takes care that this >> access always >> succeeds: >> >> diff -r a35854c84d9d >> src/share/vm/runtime/____objectMonitor.cpp >> --- >> a/src/share/vm/runtime/____objectMonitor.cpp >> Wed Mar >> 25 12:36:28 >> 2015 +0100 >> +++ >> b/src/share/vm/runtime/____objectMonitor.cpp >> >> Thu Mar >> >> 26 08:19:53 >> 2015 +0100 >> @@ -2241,7 +2241,12 @@ >> } >> >> assert(sizeof(((JavaThread >> *)ox)->_thread_state == >> sizeof(int)), >> "invariant"); >> - int jst = SafeFetch32((int *) >> &((JavaThread *) >> ox)->_thread_state, -1);; >> + int jst; >> + if (CanUseSafeFetch32()) { >> + jst = SafeFetch32((int *) >> &((JavaThread *) >> ox)->_thread_state, -1); >> + } else { >> + jst = ((JavaThread >> *)ox)->_thread_state; >> + } >> // consider also: jst != >> _thread_in_Java -- >> but that's >> overspecific. >> return jst == _thread_blocked || >> jst == >> _thread_in_native; >> } >> >> It's handled similarly in vmError.cpp. >> And no >> #ifdefs ;) >> >> But I'm also fine with the other >> change ... to >> get zero >> working again. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: hotspot-dev >> [mailto:hotspot-dev-bounces@ >> >> > >____openjdk.java.net >> >> >> >> > >> > >> >> > >> > >____openjdk.java.net >> >> >> >> > >> >> > >>>] On Behalf >> Of >> Coleen >> Phillimore >> Sent: Thursday, March 26, 2015 3:30 AM >> To: David Holmes; hotspot-dev developers >> Subject: Re: RFR (xs) 8075967: Zero >> interpreter >> asserts for >> SafeFetch<32, N> calls in ObjectMonitor >> >> >> On 3/25/15, 10:15 PM, David Holmes >> wrote: >> > On 26/03/2015 11:00 AM, Coleen >> Phillimore wrote: >> >> >> >> On 3/25/15, 8:21 PM, David Holmes >> wrote: >> >>> On 26/03/2015 10:04 AM, Coleen >> Phillimore wrote: >> >>>> >> >>>> On 3/25/15, 7:59 PM, David >> Holmes wrote: >> >>>>> Hi Coleen, >> >>>>> >> >>>>> Why generate stubs that can't >> be used and >> then add >> zero-specific >> >>>>> logic >> >>>>> to the shared CanUseSafeFetchN >> instead of not >> generating the >> stubs so >> >>>>> that CanUseSafeFetchN will >> return false >> anyway ?? >> >>>> >> >>>> Because there is platform >> independent code in >> objectMonitor.cpp that >> >>>> uses SafeFetchX (both). I'd >> rather not >> burden the >> caller of >> this with >> >>>> testing CanUseSafeFetchX for >> each call. >> This code >> existed before >> >>>> SafeFetch was implemented, so >> I'm restoring >> previous >> behavior for >> >>>> Zero. >> >>> >> >>> Sorry Coleen I thought this was >> deal to with >> 8075533, >> I hadn't >> >>> realized 8075533 broke the >> objectMonitor >> code and this >> was a >> follow up. >> >>> >> >>> What a mess. :( >> >> >> >> Yes, it is. Is this a code Review? >> > >> > Let me work through this :) The >> original >> change for 8074552: >> > >> > >> http://hg.openjdk.java.net/____jdk9/hs-rt/hotspot/rev/____ >> 3eb61269f421 >> > 3eb61269f421> >> >> >> > 3eb61269f421 >> > 3eb61269f421>> >> > >> > added the extra error handling >> stuff related to >> SafeFetch and a new >> > ErrorHandler test that was >> predicated on >> CanUseSafeFetch32 which >> > returns true if the stubs exist. It >> also added >> testing of >> SafeFetch in >> > StubRoutines::initialize2 which was >> excluded for >> windows-32-bit and >> > which did not check >> CanUseSafeFetch32. >> > >> > That change broke zero as reported >> in 8075533 >> because >> you can't >> > actually use the SafeFetch routines >> with an unsafe >> address on Zero, >> > and the solution: >> > >> > >> http://hg.openjdk.java.net/____jdk9/hs-rt/hotspot/rev/____ >> 5c2bc6278fc4 >> > 5c2bc6278fc4> >> >> >> >> >> >> > 5c2bc6278fc4 >> > 5c2bc6278fc4>> >> > >> > was to remove the stubs so that >> CanUseSafeFetch32 would >> return false, >> > and to include a check of >> CanUseSafeFetch32 in >> the tests >> used with >> > StubRoutines::initialize2. >> > >> > And now we find that the SafeFetch >> routines >> are used >> unconditionally >> > by the objectMonitor code, so we >> need to >> restore the >> stubs that were >> > previously removed, but force >> CanUseSafeFetch32 to >> return false >> on zero. >> >> Yes, exactly. >> > >> > Ok. Only nit is that: >> > >> > return NOT_ZERO(true) >> ZERO_ONLY(false); >> >> Yes, you're right. I'll make that >> change. >> >> Thanks! >> Coleen >> >> > >> > would be more readable than the >> ifdefs. >> > >> > Thanks, >> > David >> > >> >> thanks! >> >> Coleen >> >>> >> >>> Thanks, >> >>> David >> >>> >> >>> >> >>> >> >>>> We could file an RFE to either >> implement >> SafeFetch >> for Zero or >> rewrite >> >>>> this objectMonitor code to not >> need >> SafeFetch. I >> didn't want >> to do >> >>>> either of these things with this >> patch. >> >>>> >> >>>> Coleen >> >>>> >> >>>>> >> >>>>> Thanks, >> >>>>> David >> >>>>> >> >>>>> On 26/03/2015 3:53 AM, Coleen >> Phillimore >> wrote: >> >>>>>> Summary: Implement SafeFetchX >> unsafely >> and make >> CanUseSafeFetchX >> >>>>>> false >> >>>>>> for Zero >> >>>>>> >> >>>>>> Also, this fixes a couple >> other minor issues. >> >>>>>> >> >>>>>> Ran jdk9 jck tests with one >> timeout. >> hotspot/runtime jtreg >> tests >> >>>>>> don't >> >>>>>> run because Zero doesn't support >> UseCompressedOops >> (not sure >> why) >> >>>>>> and >> >>>>>> CDS (know why). >> >>>>>> >> >>>>>> open webrev at >> http://cr.openjdk.java.net/~____coleenp/8075967/ >> >> > > >> >> > >> > >> >> >>>>>> bug link >> https://bugs.openjdk.java.net/____browse/JDK-8075967 >> >> >> > > >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Coleen >> >>>> >> >> >> >> >> >> >> >> >> From thomas.stuefe at gmail.com Fri Mar 27 09:16:53 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2015 10:16:53 +0100 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> <1ddc090f-0196-4d53-a755-c81bf12c662e@default> <5c66c663-9106-427e-830a-2585f45ab906@default> Message-ID: Posting this to hotspot-dev in the hope of attracting one more reviewer and a sponsor. Th,ank you, Thomas On Wed, Mar 25, 2015 at 5:20 PM, Thomas St?fe wrote: > ping... > > I still need a sponsor and another reviewer for this issue. Thank you! > > Thomas > > On Wed, Mar 18, 2015 at 11:13 AM, Thomas St?fe > wrote: > >> Hi Markus, >> >> the way to do this cleanly would be to use Vectored Exceptions, which >> would give us the same control flow as on Unix signal. However, Vectored >> Exception handling was explicitly removed from the hotspot ages ago. >> I guess because too many third party libraries install their own VE >> handlers. >> >> To all: I still need one more reviewer and a sponsor. Thanks! >> >> Thomas >> >> >> On Tue, Mar 17, 2015 at 9:40 AM, Markus Gronlund < >> markus.gronlund at oracle.com> wrote: >> > >> > I don?t think it is worth it. But thanks for thinking about it. >> > >> > >> > >> > I was thinking if we could maybe do some callback trickery to set up >> the SEH in Windows specific code only inside Threads::create_vm() ? but >> again, probably not worth it. >> > >> > >> > >> > I am ok with the suggestion as it stands. >> > >> > >> > >> > /Markus >> > >> > >> > >> > >> > >> > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> > Sent: den 17 mars 2015 09:34 >> > To: Markus Gronlund >> > Cc: hotspot-runtime-dev at openjdk.java.net; David Holmes >> > >> > >> > Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing >> around CreateJavaVM on Windows >> > >> > >> > >> > Hi Markus, David, >> > >> > >> > >> > thanks for reviewing this! >> > >> > >> > >> > yes, I also do not like the #ifdefs _WIN32. >> > >> > >> > >> > We could pretty it up a bit with macros: >> > >> > >> > >> > #define GUARD_SEH_START __try { >> > >> > #define GUARD_SEH_END } __except... >> > >> > >> > >> > and defining those empty on non-windows platforms? >> > >> > >> > >> > What do you think? >> > >> > >> > >> > Kind Regards, Thomas >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > On Tue, Mar 17, 2015 at 9:24 AM, Markus Gronlund < >> markus.gronlund at oracle.com> wrote: >> > >> > Hi Thomas, >> > >> > This looks good, thank you for fixing this! >> > >> > I didn't know that the entire Threads::create_vm() routine is currently >> unguarded - interesting. >> > >> > Small point: I agree with David about the annoyance of having platform >> specific #ifdefs in the shared code, but I can't find any other position >> where we could solve this better (we still need to reach through to the >> ExceptionFilter). >> > >> > Let me know when you start to dig into the SEH (or lack of) for >> attaching threads :-) >> > >> > Thanks again >> > Markus >> > >> > >> > -----Original Message----- >> > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> > Sent: den 16 mars 2015 12:32 >> > To: David Holmes >> > Cc: hotspot-runtime-dev at openjdk.java.net >> > Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing >> around CreateJavaVM on Windows >> > >> > Hi, >> > >> > I still need one or two reviewers and a sponsor. >> > >> > Thank you! >> > >> > Thomas >> > >> > On Thu, Mar 12, 2015 at 10:41 AM, David Holmes > > >> > wrote: >> > >> > > Hi Thomas, >> > > >> > > Thanks for the added info. I have no further comments. Hopefully >> > > someone with SEH knowledge will also respond. >> > > >> > > David >> > > >> > > On 12/03/2015 7:18 PM, Thomas St?fe wrote: >> > > >> > >> Hi David, >> > >> >> > >> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes >> > >> > wrote: >> > >> >> > >> On 12/03/2015 8:03 AM, Thomas St?fe wrote: >> > >> >> > >> Hi David, >> > >> >> > >> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes >> > >> >> > >> > > >> >> > >> >> wrote: >> > >> >> > >> Hi Thomas, >> > >> >> > >> I'm not really familiar with Windows SEH. Won't this >> break >> > >> custom >> > >> launchers that already provide their own try/catch >> around >> > >> Crate_JavaVM ? >> > >> >> > >> >> > >> No. Windows SEH works stack based: any exception - e.g. a >> crash - >> > >> between __try and __except will be handled by the handler >> given >> > >> in the >> > >> __except clause. Because they are stack based, they can be >> > >> nested. If an >> > >> exception is raised inside the inner __try/__except, first >> > >> the inner >> > >> handler is used, if that one feels not responsible, the next >> > >> outer one >> > >> and so on. >> > >> >> > >> With my fix, any exception raised inside CreateJavaVM will be >> > >> handler by >> > >> our handler topLevelExceptionFilter; only if our handler >> feels not >> > >> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user >> > >> handler will >> > >> be called. >> > >> >> > >> >> > >> My lack of knowledge about when our handler "feels responsible" >> > >> still leaves me a little nervous here. :) >> > >> >> > >> >> > >> I think the patch is quite safe. I added this patch to our code base >> > >> in >> > >> 2011 and since then this is active in productive code for SAP >> customers. >> > >> The SAP jvm gets heavily used with custom launchers which do their >> > >> own error handling, so this is a well tested scenario. >> > >> >> > >> I would like to get a similar signal handling coverage as on UNIX: >> > >> >> > >> On Unix, we have global signal handling. The moment signal handling >> > >> is established early in os::init(), every signal from everywhere is >> > >> covered, even user code. We even have to take care that user handlers >> > >> get also in the loop via signal chaining, libjsig.so etc. >> > >> >> > >> On Windows, it is the other way around: we have stack based signal >> > >> handling , so we need __try/__except on every thread, and this means >> > >> there are parts of jvm code which run without signal handling: >> > >> - the whole initialization >> > >> - attached threads (I think?) >> > >> which means that on those cases, user handler gets signals which the >> > >> libjvm should handle. >> > >> >> > >> This was "fixed" partly by surrounding small code which we know >> > >> beforehand causes signals - how convenient - with __try/__except. For >> > >> example, the code which handles "-XX:ErrorHandlerTest" to trigger a >> > >> crash. But you want error handling to always work. I also do not know >> > >> if stuff like polling pages, implicit nulltests etc could be used in >> > >> unprotected code. >> > >> >> > >> As a side note, there is a UNIX-like signal handling mode on Windows >> > >> too, "vectored exception handling", which was used in the jvm but >> > >> removed some time ago for reasons I do not really know. >> > >> >> > >> Any exception raised in the launcher itself outside of >> > >> CreateJavaVM will >> > >> still be handled by the user handler. >> > >> >> > >> (And I hate seeing the win32 ifdefs in the shared code >> :( ). >> > >> >> > >> >> > >> Yes I know, I kind of expected that feedback :( - I did not >> find a >> > >> better way of doing this. One could try to hide the >> __try/__except >> > >> behind macros, but that would be kind of unwieldy and I >> don't like >> > >> abstractiing something which only has meaning on one >> platform. >> > >> >> > >> >> > >> Does it help if we make the caller responsible for SEH and then >> put >> > >> the try/catch in the launcher code (hopefully in a windows >> specific >> > >> part thereof) ? >> > >> >> > >> >> > >> No, because the caller would need access to "topLevelExceptionFilter" >> > >> - you would need to export that function from the libjvm and then >> > >> tell the caller "always call topLevelExceptionFilter() if a signal >> > >> happens on Windows", which is quite awkward and different than on >> UNIX. >> > >> >> > >> Thomas >> > >> >> > >> Thanks, >> > >> David >> > >> >> > >> >> > >> Thanks, >> > >> David >> > >> >> > >> >> > >> >> > >> Kind regards, Thomas >> > >> >> > >> On 12/03/2015 1:40 AM, Thomas St?fe wrote: >> > >> >> > >> Hi all, >> > >> >> > >> please review this smallish change: >> > >> >> > >> webrev: >> > >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ >> > >> webrev.____01/webrev/ >> > >> > > >> webrev.__01/webrev/> >> > >> >> > >> > > >> webrev.__01/webrev/ >> > >> > > >> 01/webrev/>> >> > >> bug: >> > >> https://bugs.openjdk.java.net/____browse/JDK-8074860 >> > >> >> > >> >> > >> > > >> >> > >> > >> > >> >> > >> This change adds SEH guards around >> JNI_CreateJavaVM(). >> > >> Without >> > >> the change, >> > >> on Windows, the VM initialization runs without crash >> > >> protection: >> > >> crashes >> > >> will terminate VM immediately without writing an >> > >> error log; >> > >> also, any >> > >> techniques relying on signals will not work, e.g. >> > >> SafeFetch(). >> > >> >> > >> This was partly solved before on a case-by-case >> base by >> > >> wrapping >> > >> code >> > >> sections which may crash in their own __try/__except >> > >> wrappers - >> > >> e.g. CPU >> > >> feature probing. >> > >> >> > >> The change guards the whole of JNI_CreateJavaVM >> > >> invocation in >> > >> __try/__except. Unfortunately, for that to compile, >> I >> > >> needed to >> > >> introduce a >> > >> wrapper around JNI_CreateJavaVM and move the whole >> of >> > >> JNI_CreateJavaVM to a >> > >> new function "JNI_CreateJavaVM_inner". >> > >> >> > >> This fix also gets rid of various workarounds which >> > >> were used >> > >> before to >> > >> guard code sections. >> > >> >> > >> Thanks for reviewing! >> > >> >> > >> Oh, on a side note: I tried to figure out if threads >> > >> which are >> > >> attached >> > >> from the outside via JNI AttachCurrentThread() are >> in >> > >> any way >> > >> guarded with >> > >> SEH protection. Newly created threads are guarded >> > >> because they >> > >> run thru >> > >> java_start() in os_windows.cpp, which adds SEH >> guards >> > >> to all >> > >> frames below. >> > >> But for attached threads, I did not find any SEH >> guards >> > >> - or >> > >> maybe I am >> > >> blind? What does that mean for java code running >> inside >> > >> attached >> > >> threads? >> > >> >> > >> Regards, >> > >> >> > >> Thomas Stuefe >> > >> >> > >> >> > >> >> > >> >> > >> > >> > > From goetz.lindenmaier at sap.com Fri Mar 27 09:19:43 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Mar 2015 09:19:43 +0000 Subject: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFB8DBE@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB8E40@DEWDFEMB12A.global.corp.sap> Thanks Thomas! Best regards, Goetz. From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Freitag, 27. M?rz 2015 09:37 To: Lindenmaier, Goetz Cc: hotspot-dev developers Subject: Re: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. Hi Goetz, looks fine. Regards, Thomas On Fri, Mar 27, 2015 at 8:58 AM, Lindenmaier, Goetz > wrote: Hi, on Aix, we don't support large pages. This needs to be manifested in arguments.cpp. The change simply reuses a #ifdef BSD for AIX, too. Please review this tiny change, and I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8076057-aixULP/webrev.00/ Best regards, Goetz. From goetz.lindenmaier at sap.com Fri Mar 27 09:28:19 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Mar 2015 09:28:19 +0000 Subject: RFR(L): 8075506: aix: improve handling of native memory In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFB69B7@DEWDFEMB12A.global.corp.sap> <5512F608.6070709@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB8E6D@DEWDFEMB12A.global.corp.sap> Hi Thomas, I adapted the comment. Thanks for looking at this! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe Sent: Donnerstag, 26. M?rz 2015 17:26 To: Vladimir Kozlov Cc: HotSpot Open Source Developers Subject: Re: RFR(L): 8075506: aix: improve handling of native memory Hi Valdimir, Goetz, sorry, the comment is misleading. What was meant was that no explicit commit is needed, on AIX we have automatic commit on touch. Which is actually true for all memory, not just C heap. So though it is true that pthread stacks live in C heap, it does not matter here and the comment should be changed to "On AIX we need no explicit commit". @Goetz: Changes look ok, build ok and 64k pages are allocated now (tested with -XX:+Verbose). Thank you for porting this to the OpenJDK! There are some changes in there which have nothing to do with 64K page support: - anything in create_stack_guard_pages() and allocate_stack_guard_pages() - attachListener.cpp, interfaceSupport.hpp and perfMemory_aix.cpp this all could go to a separate patch. Or, we just label the patch as generic patch collection. Regards, Thomas On Wed, Mar 25, 2015 at 6:53 PM, Vladimir Kozlov wrote: > Looks good. I only glanced through os_aix.cpp changes - they look fine > from 'glance'. > > Could you explain a little about allocate_stack_guard_pages() returning > false? The comment say that you are not using normal C stack. Is it true? > > Thanks, > Vladimir > > > On 3/25/15 1:22 AM, Lindenmaier, Goetz wrote: > >> Hi, >> >> this change improves handling of native memory on aix. It adds support >> for >> 64K pages and allocation at requested addresses. This improves >> performance >> by a few percent. >> >> Please review this change. It is aix-only. >> http://cr.openjdk.java.net/~goetz/webrevs/8075506-aixMem/webrev.00/ >> >> Best regards, >> Goetz. >> >> From sgehwolf at redhat.com Fri Mar 27 09:30:21 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 27 Mar 2015 10:30:21 +0100 Subject: RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor In-Reply-To: <5514524B.7030802@oracle.com> References: <5512F600.9050102@oracle.com> <1427308172.3470.82.camel@redhat.com> <55134E0B.7090600@oracle.com> <1427365326.3339.35.camel@redhat.com> <5514524B.7030802@oracle.com> Message-ID: <1427448621.3497.10.camel@redhat.com> On Thu, 2015-03-26 at 14:39 -0400, Coleen Phillimore wrote: [...] > The hotspot runtime jtreg tests do poorly because CompressedOops aren't > supported. I don't know why they aren't supported. When I took out the > code to disable CompressedOops, more tests passed. OK. What's your reproducer for this? > Zero doesn't support CDS because metaspaceShared_zero.cpp needs some > generated code that isn't done with Zero. > > > > With that being said, Zero should be in better shape now than it was a > > while ago. Back then, it wouldn't even compile in latest upstream > > trees... > > Yes, I heard that it works fairly well in jdk8 so getting it to work for > jdk9 was just accounting for new changes. > > > > Depending on available cycles I'll try to help as much as I can. The > > best metric we have currently for Zero is its ability to build itself. > > I've never managed to go through all failing jtreg tests and determine > > exactly what's wrong (test or JVM failure). > > > >> It seems to be missing a lot. > > Right. A good starting point is making people aware that it exists so > > that no new compilation errors get introduced. You've been doing a great > > job at this. Thanks! My goal is to make Zero better over time, since > > it's been lacking basic maintainership for a while in upstream OpenJDK. > > > > Aside: Zero is using the C++ interpreter which AFAIK, isn't used much > > anywhere else. Most (all?) JIT ports use the template interpreter these > > days. > > Most ports use the template interpreter because it's significantly > faster, but the Zero interpreter by not having any generated native code > makes getting a new port running faster. It also may be nice to > prototype new bytecodes in C++ rather than as macro assembler. And it's > sort of cool. > > Yes, Zero uses interpreter/bytecodeInterpreter.cpp which is written in > C++. What we call the C++ interpreter is something else that also uses > bytecodeInterpreter.cpp. > > https://bugs.openjdk.java.net/browse/JDK-8074457 Thanks for this pointer. That explains why I wasn't able to get a basic build --with-jvm-interpreter=cpp working. > Keeping Zero compiling and running is not part of our normal testing, so > most of the contributions are coming from outside Oracle for this. Indeed :) Cheers, Severin > Coleen > > > > Thanks, > > Severin > > > >> Thanks, > >> Coleen > >> > >>> Changes look fine to me. > >>> > >>> Cheers, > >>> Severin > >>> > >>>> Thanks, > >>>> Coleen > >>> > > > > > From david.holmes at oracle.com Fri Mar 27 12:04:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Mar 2015 22:04:24 +1000 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> <1ddc090f-0196-4d53-a755-c81bf12c662e@default> <5c66c663-9106-427e-830a-2585f45ab906@default> Message-ID: <55154748.6030309@oracle.com> Hi Thomas, On 27/03/2015 7:16 PM, Thomas St?fe wrote: > Posting this to hotspot-dev in the hope of attracting one more reviewer and > a sponsor. I can sponsor if required, but am still hoping for someone more knowledgeable in Windows SEH to do the review. David > Th,ank you, > > Thomas > > > On Wed, Mar 25, 2015 at 5:20 PM, Thomas St?fe > wrote: > >> ping... >> >> I still need a sponsor and another reviewer for this issue. Thank you! >> >> Thomas >> >> On Wed, Mar 18, 2015 at 11:13 AM, Thomas St?fe >> wrote: >> >>> Hi Markus, >>> >>> the way to do this cleanly would be to use Vectored Exceptions, which >>> would give us the same control flow as on Unix signal. However, Vectored >>> Exception handling was explicitly removed from the hotspot ages ago. >>> I guess because too many third party libraries install their own VE >>> handlers. >>> >>> To all: I still need one more reviewer and a sponsor. Thanks! >>> >>> Thomas >>> >>> >>> On Tue, Mar 17, 2015 at 9:40 AM, Markus Gronlund < >>> markus.gronlund at oracle.com> wrote: >>>> >>>> I don?t think it is worth it. But thanks for thinking about it. >>>> >>>> >>>> >>>> I was thinking if we could maybe do some callback trickery to set up >>> the SEH in Windows specific code only inside Threads::create_vm() ? but >>> again, probably not worth it. >>>> >>>> >>>> >>>> I am ok with the suggestion as it stands. >>>> >>>> >>>> >>>> /Markus >>>> >>>> >>>> >>>> >>>> >>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>>> Sent: den 17 mars 2015 09:34 >>>> To: Markus Gronlund >>>> Cc: hotspot-runtime-dev at openjdk.java.net; David Holmes >>>> >>>> >>>> Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing >>> around CreateJavaVM on Windows >>>> >>>> >>>> >>>> Hi Markus, David, >>>> >>>> >>>> >>>> thanks for reviewing this! >>>> >>>> >>>> >>>> yes, I also do not like the #ifdefs _WIN32. >>>> >>>> >>>> >>>> We could pretty it up a bit with macros: >>>> >>>> >>>> >>>> #define GUARD_SEH_START __try { >>>> >>>> #define GUARD_SEH_END } __except... >>>> >>>> >>>> >>>> and defining those empty on non-windows platforms? >>>> >>>> >>>> >>>> What do you think? >>>> >>>> >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Mar 17, 2015 at 9:24 AM, Markus Gronlund < >>> markus.gronlund at oracle.com> wrote: >>>> >>>> Hi Thomas, >>>> >>>> This looks good, thank you for fixing this! >>>> >>>> I didn't know that the entire Threads::create_vm() routine is currently >>> unguarded - interesting. >>>> >>>> Small point: I agree with David about the annoyance of having platform >>> specific #ifdefs in the shared code, but I can't find any other position >>> where we could solve this better (we still need to reach through to the >>> ExceptionFilter). >>>> >>>> Let me know when you start to dig into the SEH (or lack of) for >>> attaching threads :-) >>>> >>>> Thanks again >>>> Markus >>>> >>>> >>>> -----Original Message----- >>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>>> Sent: den 16 mars 2015 12:32 >>>> To: David Holmes >>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing >>> around CreateJavaVM on Windows >>>> >>>> Hi, >>>> >>>> I still need one or two reviewers and a sponsor. >>>> >>>> Thank you! >>>> >>>> Thomas >>>> >>>> On Thu, Mar 12, 2015 at 10:41 AM, David Holmes >>> >>>> wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> Thanks for the added info. I have no further comments. Hopefully >>>>> someone with SEH knowledge will also respond. >>>>> >>>>> David >>>>> >>>>> On 12/03/2015 7:18 PM, Thomas St?fe wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes >>>>>> > wrote: >>>>>> >>>>>> On 12/03/2015 8:03 AM, Thomas St?fe wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes >>>>>> >>>>>> >>>>> >>>>>> >> wrote: >>>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> I'm not really familiar with Windows SEH. Won't this >>> break >>>>>> custom >>>>>> launchers that already provide their own try/catch >>> around >>>>>> Crate_JavaVM ? >>>>>> >>>>>> >>>>>> No. Windows SEH works stack based: any exception - e.g. a >>> crash - >>>>>> between __try and __except will be handled by the handler >>> given >>>>>> in the >>>>>> __except clause. Because they are stack based, they can be >>>>>> nested. If an >>>>>> exception is raised inside the inner __try/__except, first >>>>>> the inner >>>>>> handler is used, if that one feels not responsible, the next >>>>>> outer one >>>>>> and so on. >>>>>> >>>>>> With my fix, any exception raised inside CreateJavaVM will be >>>>>> handler by >>>>>> our handler topLevelExceptionFilter; only if our handler >>> feels not >>>>>> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user >>>>>> handler will >>>>>> be called. >>>>>> >>>>>> >>>>>> My lack of knowledge about when our handler "feels responsible" >>>>>> still leaves me a little nervous here. :) >>>>>> >>>>>> >>>>>> I think the patch is quite safe. I added this patch to our code base >>>>>> in >>>>>> 2011 and since then this is active in productive code for SAP >>> customers. >>>>>> The SAP jvm gets heavily used with custom launchers which do their >>>>>> own error handling, so this is a well tested scenario. >>>>>> >>>>>> I would like to get a similar signal handling coverage as on UNIX: >>>>>> >>>>>> On Unix, we have global signal handling. The moment signal handling >>>>>> is established early in os::init(), every signal from everywhere is >>>>>> covered, even user code. We even have to take care that user handlers >>>>>> get also in the loop via signal chaining, libjsig.so etc. >>>>>> >>>>>> On Windows, it is the other way around: we have stack based signal >>>>>> handling , so we need __try/__except on every thread, and this means >>>>>> there are parts of jvm code which run without signal handling: >>>>>> - the whole initialization >>>>>> - attached threads (I think?) >>>>>> which means that on those cases, user handler gets signals which the >>>>>> libjvm should handle. >>>>>> >>>>>> This was "fixed" partly by surrounding small code which we know >>>>>> beforehand causes signals - how convenient - with __try/__except. For >>>>>> example, the code which handles "-XX:ErrorHandlerTest" to trigger a >>>>>> crash. But you want error handling to always work. I also do not know >>>>>> if stuff like polling pages, implicit nulltests etc could be used in >>>>>> unprotected code. >>>>>> >>>>>> As a side note, there is a UNIX-like signal handling mode on Windows >>>>>> too, "vectored exception handling", which was used in the jvm but >>>>>> removed some time ago for reasons I do not really know. >>>>>> >>>>>> Any exception raised in the launcher itself outside of >>>>>> CreateJavaVM will >>>>>> still be handled by the user handler. >>>>>> >>>>>> (And I hate seeing the win32 ifdefs in the shared code >>> :( ). >>>>>> >>>>>> >>>>>> Yes I know, I kind of expected that feedback :( - I did not >>> find a >>>>>> better way of doing this. One could try to hide the >>> __try/__except >>>>>> behind macros, but that would be kind of unwieldy and I >>> don't like >>>>>> abstractiing something which only has meaning on one >>> platform. >>>>>> >>>>>> >>>>>> Does it help if we make the caller responsible for SEH and then >>> put >>>>>> the try/catch in the launcher code (hopefully in a windows >>> specific >>>>>> part thereof) ? >>>>>> >>>>>> >>>>>> No, because the caller would need access to "topLevelExceptionFilter" >>>>>> - you would need to export that function from the libjvm and then >>>>>> tell the caller "always call topLevelExceptionFilter() if a signal >>>>>> happens on Windows", which is quite awkward and different than on >>> UNIX. >>>>>> >>>>>> Thomas >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> >>>>>> Kind regards, Thomas >>>>>> >>>>>> On 12/03/2015 1:40 AM, Thomas St?fe wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> please review this smallish change: >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ >>>>>> webrev.____01/webrev/ >>>>>> >>>>> webrev.__01/webrev/> >>>>>> >>>>>> >>>>> webrev.__01/webrev/ >>>>>> >>>>> 01/webrev/>> >>>>>> bug: >>>>>> https://bugs.openjdk.java.net/____browse/JDK-8074860 >>>>>> >>>>>> >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> This change adds SEH guards around >>> JNI_CreateJavaVM(). >>>>>> Without >>>>>> the change, >>>>>> on Windows, the VM initialization runs without crash >>>>>> protection: >>>>>> crashes >>>>>> will terminate VM immediately without writing an >>>>>> error log; >>>>>> also, any >>>>>> techniques relying on signals will not work, e.g. >>>>>> SafeFetch(). >>>>>> >>>>>> This was partly solved before on a case-by-case >>> base by >>>>>> wrapping >>>>>> code >>>>>> sections which may crash in their own __try/__except >>>>>> wrappers - >>>>>> e.g. CPU >>>>>> feature probing. >>>>>> >>>>>> The change guards the whole of JNI_CreateJavaVM >>>>>> invocation in >>>>>> __try/__except. Unfortunately, for that to compile, >>> I >>>>>> needed to >>>>>> introduce a >>>>>> wrapper around JNI_CreateJavaVM and move the whole >>> of >>>>>> JNI_CreateJavaVM to a >>>>>> new function "JNI_CreateJavaVM_inner". >>>>>> >>>>>> This fix also gets rid of various workarounds which >>>>>> were used >>>>>> before to >>>>>> guard code sections. >>>>>> >>>>>> Thanks for reviewing! >>>>>> >>>>>> Oh, on a side note: I tried to figure out if threads >>>>>> which are >>>>>> attached >>>>>> from the outside via JNI AttachCurrentThread() are >>> in >>>>>> any way >>>>>> guarded with >>>>>> SEH protection. Newly created threads are guarded >>>>>> because they >>>>>> run thru >>>>>> java_start() in os_windows.cpp, which adds SEH >>> guards >>>>>> to all >>>>>> frames below. >>>>>> But for attached threads, I did not find any SEH >>> guards >>>>>> - or >>>>>> maybe I am >>>>>> blind? What does that mean for java code running >>> inside >>>>>> attached >>>>>> threads? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Thomas Stuefe >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >> >> From goetz.lindenmaier at sap.com Fri Mar 27 13:22:52 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Mar 2015 13:22:52 +0000 Subject: RFR(M): 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> Hi, This change ports the platform changes required after "8074345: Enable RewriteBytecodes when VM runs with CDS" to ppc. Ppc does not support CDS, but the changes are required anyways, as new methods need to be implemented. Please review this change. It would be great if I can push this soon, if possible before 8074345 is transported to jdk9/hs. http://cr.openjdk.java.net/~goetz/webrevs/8076163-tmpTbl/webrev.00/ Best regards, Goetz. From yekaterina.kantserova at oracle.com Fri Mar 27 14:21:43 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 27 Mar 2015 15:21:43 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <743A07B6-736B-43FE-8961-6F6FB218AF63@oracle.com> References: <550A9DFB.1070204@oracle.com> <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> <550FF107.5030504@oracle.com> <743A07B6-736B-43FE-8961-6F6FB218AF63@oracle.com> Message-ID: <55156777.9030203@oracle.com> The tests looks good! Thank you very much for fixing. // Katja On 03/23/2015 12:41 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 23 mar 2015, at 11:55, Jaroslav Bachorik wrote: >> >> On 23.3.2015 08:50, Staffan Larsen wrote: >>> diagnosticCommand.cpp: >>> - Should SetVMFlagDCmd really be inside "#if INCLUDE_SERVICES? ? >> Probably not. On the other hand, the JVMTIDataDumpDCmd registration should probably be guarded by #if INCLUDE_JVMTI >> >>> - L227-234: strange indentation >> Fixed. >> >> Updated webrev (+ removing the extraneous #include "services/attachListener.hpp" in diagnosticCommand.hpp) : http://cr.openjdk.java.net/~jbachorik/8054890/webrev.01 >> >> -JB- >> >> >>> >>> /Staffan >>> >>> >>>> On 19 mar 2015, at 10:59, Jaroslav Bachorik wrote: >>>> >>>> Please, review the following change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 >>>> >>>> This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. >>>> >>>> VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. >>>> >>>> JVMTI.data_dump will send the data dump request to JVMTI. >>>> >>>> Both of these commands are covered by the corresponding tests. >>>> >>>> Thanks, >>>> >>>> -JB- From martin.doerr at sap.com Fri Mar 27 15:17:53 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 27 Mar 2015 15:17:53 +0000 Subject: RFR(M): 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116566AD1D8DA@DEWDFEMB19C.global.corp.sap> This change looks good. Best regards, Martin -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Freitag, 27. M?rz 2015 14:23 To: HotSpot Open Source Developers; hotspot-runtime-dev at openjdk.java.net Subject: RFR(M): 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" Hi, This change ports the platform changes required after "8074345: Enable RewriteBytecodes when VM runs with CDS" to ppc. Ppc does not support CDS, but the changes are required anyways, as new methods need to be implemented. Please review this change. It would be great if I can push this soon, if possible before 8074345 is transported to jdk9/hs. http://cr.openjdk.java.net/~goetz/webrevs/8076163-tmpTbl/webrev.00/ Best regards, Goetz. From volker.simonis at gmail.com Fri Mar 27 15:30:40 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 27 Mar 2015 16:30:40 +0100 Subject: RFR(M): 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> Message-ID: The change looks good! Thanks, Volker On Fri, Mar 27, 2015 at 2:22 PM, Lindenmaier, Goetz wrote: > Hi, > > This change ports the platform changes required after "8074345: Enable RewriteBytecodes > when VM runs with CDS" to ppc. Ppc does not support CDS, but the changes are required > anyways, as new methods need to be implemented. > > Please review this change. It would be great if I can push this soon, if possible before > 8074345 is transported to jdk9/hs. > http://cr.openjdk.java.net/~goetz/webrevs/8076163-tmpTbl/webrev.00/ > > Best regards, > Goetz. From max.ockner at oracle.com Fri Mar 27 16:26:42 2015 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 27 Mar 2015 12:26:42 -0400 Subject: RFR: 8074718: Merged templateTable_x86 header files for 32/64 bits. In-Reply-To: <551469D6.9030303@oracle.com> References: <55119F93.9000007@oracle.com> <5512FCD9.8000004@oracle.com> <551469D6.9030303@oracle.com> Message-ID: <551584C2.6070604@oracle.com> I have made this change. It seems like the cleanest option. -Max On 3/26/2015 4:19 PM, Coleen Phillimore wrote: > > This looks like a good suggestion! > Coleen > > On 3/25/15, 2:22 PM, harold seigel wrote: >> Hi Max, >> >> This looks good. Just one small comment about >> templateTable_x86.hpp. (No need for a new webrev) >> >> Could you combine this: >> >> 346 #elif defined TARGET_ARCH_MODEL_x86_32 >> 347 # include "templateTable_x86.hpp" >> 348 #elif defined TARGET_ARCH_MODEL_x86_64 >> 349 # include "templateTable_x86.hpp" >> 350 #elif defined TARGET_ARCH_MODEL_sparc >> >> Into: >> >> 346 #elif defined(TARGET_ARCH_MODEL_x86_32) || >> defined(TARGET_ARCH_MODEL_x86_64) >> 347 # include "templateTable_x86.hpp" >> 350 #elif defined TARGET_ARCH_MODEL_sparc >> >> >> Thanks, Harold >> >> On 3/24/2015 1:32 PM, Max Ockner wrote: >>> Hello all, >>> Please review this small change. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074718 >>> Webrev: >>> http://cr.openjdk.java.net/~mockner/8074718/src/share/vm/interpreter/templateTable.hpp.cdiff.html >>> Summary: The templateTable_x86 hpp files for 32 and 64 bits have >>> been merged. Just a couple of notes: >>> >>> (1) I would prefer to combine the two conditions which include >>> templateTable_x86.hpp if possible, but I'm not comfortable fiddling >>> with the TARGET_ARCH_MODEL labels. >>> I was hoping to use TARGET_ARCH_MODEL_x86 to encompass both >>> TARGET_ARCH_MODEL_x86_64 and TARGET_ARCH_MODEL_x86_32, but I don't >>> think it exists. Any suggestions? >>> >>> (2) templateTable_x86.hpp is the updated file that will be kept. >>> templateTable_x86_32.hpp and templateTable_x86_64.hpp are copies of >>> templateTable_x86.hpp, and still exist for reviewing purposes. They >>> will be removed before this is committed. >>> >>> Tested with jtreg runtime tests. >>> >>> Thanks, >>> Max >> > From jaroslav.bachorik at oracle.com Fri Mar 27 16:29:50 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 27 Mar 2015 17:29:50 +0100 Subject: RFR 8023093: Add ManagementAgent.status diagnostic command Message-ID: <5515857E.9080902@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8023093 Webrev: http://cr.openjdk.java.net/~jbachorik/8023093/webrev.00 (hotspot, jdk) This change adds a new 'ManagementAgent.status' diagnostic command. This command will output the current status of the management agent in the following format ``` Agent: ( ConnectionType: Protocol: Host: URL: ( Properties: ( = )+ )? )+ ``` Where: means an arbitrary value | means 'or' ( and ) denote a block + block repeats one or more times ? block appears at most once A new test is added exercising this diagnostic command. While adding the test I factored out the shared functionality from the JMXStartStopTest class and caused the changes in the test area to be a bit more extensive than just adding a new test class. Thanks, -JB- From thomas.stuefe at gmail.com Fri Mar 27 18:00:37 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2015 19:00:37 +0100 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero Message-ID: Hi all, Please review this change which provides a real SafeFetch implementation on zero. webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8076185/webrev.01/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8076185 It works like this: Before a load is attempted from a potentially unsafe address, we set up a jump buffer with sigsetjmp(). In the signal handler, for SIGSEGV and SIGBUS, we test whether there is a jump buffer set and if yes, take this as an indication that the crash was an attempted SafeFetch. In this case we jump back via longjmp(). Coding is a bit more difficult because we need to be threadsafe. We keep the jump buffer on the thread stack - this is ok, because that stack never gets unwinded - either we crash, in which case signal handler stack frames are built up below us, or we don't crash, in which case we never leave the SafeFetch function. In both cases, we never loose the jump buffer. To communicate the jump buffer location to the signal handler, TLS is used. I use POSIX tls, because that always works and is not dependend on VM infrastructure. --- I built and tested this on Linux x64 zero (Ubuntu 14.4). It works and the initialization tests for SafeFetch in the stub routine initialization now work for zero too. Note that I do not have a BSD system right now, so I cannot check whether this change builds and works for BSD. But the change only requires POSIX Apis, so BSD should probably be ok. Someone from the zero team should definitly check and test this for other zero platforms, but the chances are good that this just works. Thanks and Kind Regards, Thomas Stuefe From coleen.phillimore at oracle.com Fri Mar 27 18:46:58 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Mar 2015 14:46:58 -0400 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <55135DE5.2010705@oracle.com> References: <55135DE5.2010705@oracle.com> Message-ID: <5515A5A2.5020908@oracle.com> This fix looks correct. Is there any way to write a test for this? thanks, Coleen On 3/25/15, 9:16 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8066679 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ > > > > Summary: > > There can be multiple concurrent RetransformClasses calls on > different threads. > So that, the assert "cache ptrs must match" is incorrect as it was > based on wrong assumptions. > The fix removes two related asserts and also frees the scratch_class > cached_class_file_bytes > if it is necessary to avoid leaking the memory. > > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Fri Mar 27 18:57:08 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 27 Mar 2015 11:57:08 -0700 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <5515A5A2.5020908@oracle.com> References: <55135DE5.2010705@oracle.com> <5515A5A2.5020908@oracle.com> Message-ID: <5515A804.6030204@oracle.com> Thanks, Coleen! I'll check about test. Thanks, Serguei On 3/27/15 11:46 AM, Coleen Phillimore wrote: > > This fix looks correct. Is there any way to write a test for this? > thanks, > Coleen > > On 3/25/15, 9:16 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8066679 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ >> >> >> >> Summary: >> >> There can be multiple concurrent RetransformClasses calls on >> different threads. >> So that, the assert "cache ptrs must match" is incorrect as it was >> based on wrong assumptions. >> The fix removes two related asserts and also frees the >> scratch_class cached_class_file_bytes >> if it is necessary to avoid leaking the memory. >> >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei > From coleen.phillimore at oracle.com Fri Mar 27 19:17:15 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Mar 2015 15:17:15 -0400 Subject: RFR: 8075955: Replace the macro based implementation of oop_oop_iterate with a template based solution In-Reply-To: <5514354B.6060505@oracle.com> References: <5514354B.6060505@oracle.com> Message-ID: <5515ACBB.1010108@oracle.com> Stefan, This is a huge change and I've never pretended to know how these macros work. I won't pretend I can read these templates quickly either. From my runtime perspective, the change looks fine. Actually, they look great. I have a couple minor comments but nothing deep. http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp.udiff.html +void InstanceKlass::oop_pc_follow_contents(oop obj, ParCompactionManager* cm) { It seems like these functions never belonged in InstanceKlass, etc and with your change, can you make them actually owned by the GC function they call? Like this one seems that it should be owned by PSParallelCompact. Or do they all have to have the same name? http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.hpp.udiff.html + // Iterate over oop elements with indices within [start, end), and metadata. + // Iterate over oop elements within [start, end), and metadata. These have the wrong sort of closed bracket (messes up 'vi') - should be ']' That's all. Coleen On 3/26/15, 12:35 PM, Stefan Karlsson wrote: > Hi, > > Please review this patch to replace the macro based implementation of > oop_oop_iterate with a template based solution. > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075955 > > Summary of the changes: > > - Replace the macro implementation of the different oop_oop_iterate > functions with template functions. The implementation is moved out > from the *Klass.cpp files into the *Klass.inline.hpp files, to be able > to generate the specialized oop_oop_iterate functions in suitable GC > specific files. > > See the old macro implementation: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html > > > That has now been converted into template functions: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.inline.hpp.udiff.html > > > There's still a closure specialization layer implemented with macros > to support the code to allows the code to pass down the concrete > closure type, past the virtual Klass::oop_oop_iterate_nv(...) call. > The macros just calls the new template functions: > > 191 #define InstanceKlass_OOP_OOP_ITERATE_DEFN(OopClosureType, > nv_suffix) \ > 192 int InstanceKlass::oop_oop_iterate##nv_suffix(oop obj, > OopClosureType* closure) { \ > 193 return oop_oop_iterate(obj, > closure); \ > 194 } > > We might want to remove this in a future patch, by providing our own > dispatch mechanism. > > > - Split the generation of the specialized oop_oop_iterate definitions, > so that we keep code from different GCs separated. Before this patch, > code from all GCs were generated into instanceKlass.cpp, > instanceMirrorKlass.cpp, instanceClassLoaderKlass.cpp, > instanceRefKlass.cpp, typeArrayKlass.cpp, and objArrayKlass.cpp. > > Now the definitions are generated into: > G1: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/g1/g1OopClosures.cpp.udiff.html > CMS: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.cpp.html > ParNew: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.cpp.html > Serial: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/genOopClosures.cpp.html > > > - The other GCs don't use use the above mentioned closure > specialization, that is, they don't call obj->oop_iterate(&cl) to > follow the objects. Instead they have their own "visitor" functions > located in the oopDesc and *Klass classes. For example, Parallel > Scavenge calls obj->push_contents(...), which calls > Klass::oop_push_contents(...), to follow outgoing pointers after an > object has been moved. These visitor functions used to use the oop > iterate macros and pass down snippets of code to be applied to each > oop*. This has now been changed to use use closures and the new > oop_oop_iterate template functions. > > The implementation of these object visitor functions have been moved > out from the *Klass.cpp files and into the GCs that the functions > support. > > Using Parallel Scavenge as and example: > > The implementation to handle the references out of a copied object was > located in: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html > > > -void InstanceKlass::oop_push_contents(PSPromotionManager* pm, oop obj) { > - InstanceKlass_OOP_MAP_REVERSE_ITERATE( \ > - obj, \ > - if (PSScavenge::should_scavenge(p)) { \ > - pm->claim_or_forward_depth(p); \ > - }, \ > - assert_nothing ) > -} > > and has now been moved to: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html > > > +void InstanceKlass::oop_ps_push_contents(oop obj, PSPromotionManager* > pm) { > + PushContentsClosure cl(pm); > + oop_oop_iterate_oop_maps_reverse(obj, &cl); > +} > > where the do_oop function is implemented as: > + > + template void do_oop_nv(T* p) { > + if (PSScavenge::should_scavenge(p)) { > + _pm->claim_or_forward_depth(p); > + } > > From the same file, it can be seen how that the implementation to > follow the references in the mirrors are using the same closure: > > +void InstanceMirrorKlass::oop_ps_push_contents(oop obj, > PSPromotionManager* pm) { > ... > + InstanceKlass::oop_ps_push_contents(obj, pm); > + > + PushContentsClosure cl(pm); > + oop_oop_iterate_statics(obj, &cl); > +} > > As can be seen above, the functions are still members of the different > Klasses, but only the declaration is put in the klass.hpp files. The > actual implementation is put in the GC files. This helps decoupling > the different GCs and the Klasses. We could move the functions over to > a GC specific "visitor" and have a generic "accept" function in the > Klasses, but that approach would require two virtual calls, while the > current implementation only needs one. > > In the future we might want to remove these functions from the > *Klasses and reuse the already existing code in the oop_oop_iterate > framework. > > If we take the InstanceMirrorKlass::oop_ps_push_contents function > above as an example, it could be implemented with > InstanceMirrorKlass::oop_oop_iterate, since they share the same > structure: > > 54 template > 55 int InstanceMirrorKlass::oop_oop_iterate(oop obj, OopClosureType* > closure) { > 56 InstanceKlass::oop_oop_iterate(obj, closure); > 57 > 58 if (Devirtualizer::do_metadata(closure)) { > 59 Klass* klass = java_lang_Class::as_Klass(obj); > 60 // We'll get NULL for primitive mirrors. > 61 if (klass != NULL) { > 62 Devirtualizer::do_klass(closure, klass); > 63 } > 64 } > 65 > 66 oop_oop_iterate_statics(obj, closure); > 67 > 68 return oop_size(obj); > 69 } > > Parallel Scavenge doesn't visit the klass pointers and do_metadata > returns false, so that code path will be eliminated by the compiler. > We would have to do something about the return oop_size(obj), since we > don't want to do that unnecessarily. To change the GC object visitors > to entirely use the oop_oop_iterator framework is out of scope for > this patch. > > The object visitor functions were renamed and moved as follows: > oop_follow_contents(opp) -> oop_ms_follow_contents(oop) in markSweep.cpp > oop_adjust_pointers(oop) -> oop_ms_adjust_pointers(oop) in markSweep.cpp > oop_follow_contents(oop, ParCompactionManager*) -> > oop_pc_follow_contents(...) in psCompactionManager.cpp > oop_update_pointers(oop) -> oop_pc_update_pointers(oop) in > psParallelCompact.cpp > oop_push_contents(oop, PSPromotionManager*) -> > oop_ps_push_contents(...) in psPromotionManager.cpp > > > - The oop iterate macros used to take an assert parameter to be > applied to oop* that were visited. By default, the check was > assert_is_in_closed_subset, but MS, PS and PC provided their own > asserts. ExtendedOopClosure has been handed the task to provide the > default verification, but also a way to turn it off for individual > closures, so that they can provide their own asserts. See: > ExtendedOopClosure::verify() and > ExtendedOopClosure::should_verify_oops() and how the Devirtualizer > dispatch class calls the verification code: > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/iterator.inline.hpp.udiff.html > > > +template > +inline void Devirtualizer::do_oop(OopClosureType* closure, T* p) { > + debug_only(closure->verify(p)); > + closure->do_oop_nv(p); > +} > > > - Moved PSParallelCompact::MarkAndPushClosure::do_oop, > PSParallelCompact::AdjustPointerClosure::do_oop, mark_and_push, adjust > pointer, and follow_klass to psParallelCompact.inline.hpp > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html > > > > - Add seemingly incorrect includes between GCs. This is needed since > we currently have no separation between GCs when we generate the > oop_since_save_marks_iterate functions. See: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/defNewGeneration.cpp.udiff.html > > > and the include of ParNew specific closures: > 51 #if INCLUDE_ALL_GCS > 52 #include "gc_implementation/parNew/parOopClosures.hpp" > 53 #endif > > which is needed to be able to generate: > 856 ALL_SINCE_SAVE_MARKS_CLOSURES(DefNew_SINCE_SAVE_MARKS_DEFN) > > This should be changed in a separate patch, so that DefNew only > generates oop_since_save_marks_iterate that takes DefNew specfic > closures. > > > The initial performance runs showed a slight increase of the GC times > on some benchmarks on Solaris and Windows. The reason for this > increase was that the these compilers didn't inline as much as the > hand-inlined macros used to do. To remedy this I've increased the > inlining in to ways: > > - Turned on extra inlining for psPromotionManager.cpp when compiling > with the Solaris Studio Compiler > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/make/solaris/makefiles/product.make.udiff.html > > > > - Added __forceinline to the InstanceKlass::oop_oop_iterate functions > when compiling with the MS compiler. > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html > > > > A previous version of this patch has been run through our testing, but > I've recently done changes and extracted smaller patches, so I'll have > to rerun all testing. > > Any requests for extra testing to be done? > > Thanks, > StefanK > From sergey.sprogis at oracle.com Fri Mar 27 20:59:40 2015 From: sergey.sprogis at oracle.com (Sergey Sprogis) Date: Fri, 27 Mar 2015 12:59:40 -0800 Subject: How to build HS with Oracle Studio Compiler on Oracle Linux platform? In-Reply-To: <54CAD441.8030307@oracle.com> References: <54CAD441.8030307@oracle.com> Message-ID: <5515C4BC.7000004@oracle.com> Compiler QA team needs to test newly developed Oracle Studio C++ Compiler (64-bit version): /ws/ntrunk/builds/trunk/biweekly/latest/inst/intel-Linux/bin/CC with latest Hotspot sources (in fastdebug mode) which I downloaded from: /net/koori.us.oracle.com/onestop/jdk/9/promoted/all/b56/ws I can build those sources on solaris-sparcv9 or on solaris-x64 by defining ALT_COMPILER_PATH, but on linux-x64 it seems does not work and gcc has been invoked instead of CC. Could anyone give me some suggestions what should be changed in HS build environment to switch from gcc to CC on linux-x64? Thanks, Sergey From stefan.karlsson at oracle.com Mon Mar 30 07:38:27 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 30 Mar 2015 09:38:27 +0200 Subject: RFR: 8075955: Replace the macro based implementation of oop_oop_iterate with a template based solution In-Reply-To: <5515ACBB.1010108@oracle.com> References: <5514354B.6060505@oracle.com> <5515ACBB.1010108@oracle.com> Message-ID: <5518FD73.6020602@oracle.com> Hi Coleen, On 2015-03-27 20:17, Coleen Phillimore wrote: > > Stefan, > This is a huge change and I've never pretended to know how these > macros work. I won't pretend I can read these templates quickly > either. From my runtime perspective, the change looks fine. Actually, > they look great. Thanks for looking at this patch. > I have a couple minor comments but nothing deep. > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp.udiff.html > > > +void InstanceKlass::oop_pc_follow_contents(oop obj, > ParCompactionManager* cm) { > > It seems like these functions never belonged in InstanceKlass, etc and > with your change, can you make them actually owned by the GC function > they call? Like this one seems that it should be owned by > PSParallelCompact. Or do they all have to have the same name? I agree that we want to get rid of these functions from the *Klasses, but I don't see a small, incremental change that I could do to solve it. Two alternatives that I tried to explain further down in the mail: 1) Reuse the oop_oop_iterate framework. That will be quite a large change by itself, but hopefully doable. 2) Make a common object visitor function, say Klass::oop_accept(ObjectVisitor* visitor), and then have the GC code do: PCFollowContents follow_contents(cm); obj->klass()->oop_accept(&follow_contents); The drawback of that solution is that we get two virtual calls: The first is when calling Klass::oop_accept to get "inside" the correct sub-Klass, and the second is the call to ObjectVisitor::visit(this /* the sub-Klass */) from the dispatched sub-Klass. Getting rid of the second virtual call is exactly what we accomplish by having the oop_pc_follow_contents in the *Klasses. > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.hpp.udiff.html > > > + // Iterate over oop elements with indices within [start, end), and > metadata. > > + // Iterate over oop elements within [start, end), and metadata. > > > These have the wrong sort of closed bracket (messes up 'vi') - should > be ']' I'm not sure I understand what you mean. The [ bracket means inclusive, while the ) bracket is supposed to mean exclusive. Just like what's described in: http://en.wikipedia.org/wiki/Bracket_(mathematics)#Intervals > > That's all. Thanks! StefanK > Coleen > > On 3/26/15, 12:35 PM, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to replace the macro based implementation of >> oop_oop_iterate with a template based solution. >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075955 >> >> Summary of the changes: >> >> - Replace the macro implementation of the different oop_oop_iterate >> functions with template functions. The implementation is moved out >> from the *Klass.cpp files into the *Klass.inline.hpp files, to be >> able to generate the specialized oop_oop_iterate functions in >> suitable GC specific files. >> >> See the old macro implementation: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html >> >> >> That has now been converted into template functions: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.inline.hpp.udiff.html >> >> >> There's still a closure specialization layer implemented with macros >> to support the code to allows the code to pass down the concrete >> closure type, past the virtual Klass::oop_oop_iterate_nv(...) call. >> The macros just calls the new template functions: >> >> 191 #define InstanceKlass_OOP_OOP_ITERATE_DEFN(OopClosureType, >> nv_suffix) \ >> 192 int InstanceKlass::oop_oop_iterate##nv_suffix(oop obj, >> OopClosureType* closure) { \ >> 193 return oop_oop_iterate(obj, >> closure); \ >> 194 } >> >> We might want to remove this in a future patch, by providing our own >> dispatch mechanism. >> >> >> - Split the generation of the specialized oop_oop_iterate >> definitions, so that we keep code from different GCs separated. >> Before this patch, code from all GCs were generated into >> instanceKlass.cpp, instanceMirrorKlass.cpp, >> instanceClassLoaderKlass.cpp, instanceRefKlass.cpp, >> typeArrayKlass.cpp, and objArrayKlass.cpp. >> >> Now the definitions are generated into: >> G1: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/g1/g1OopClosures.cpp.udiff.html >> CMS: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.cpp.html >> ParNew: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.cpp.html >> Serial: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/genOopClosures.cpp.html >> >> >> - The other GCs don't use use the above mentioned closure >> specialization, that is, they don't call obj->oop_iterate(&cl) to >> follow the objects. Instead they have their own "visitor" functions >> located in the oopDesc and *Klass classes. For example, Parallel >> Scavenge calls obj->push_contents(...), which calls >> Klass::oop_push_contents(...), to follow outgoing pointers after an >> object has been moved. These visitor functions used to use the oop >> iterate macros and pass down snippets of code to be applied to each >> oop*. This has now been changed to use use closures and the new >> oop_oop_iterate template functions. >> >> The implementation of these object visitor functions have been moved >> out from the *Klass.cpp files and into the GCs that the functions >> support. >> >> Using Parallel Scavenge as and example: >> >> The implementation to handle the references out of a copied object >> was located in: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html >> >> >> -void InstanceKlass::oop_push_contents(PSPromotionManager* pm, oop >> obj) { >> - InstanceKlass_OOP_MAP_REVERSE_ITERATE( \ >> - obj, \ >> - if (PSScavenge::should_scavenge(p)) { \ >> - pm->claim_or_forward_depth(p); \ >> - }, \ >> - assert_nothing ) >> -} >> >> and has now been moved to: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html >> >> >> +void InstanceKlass::oop_ps_push_contents(oop obj, >> PSPromotionManager* pm) { >> + PushContentsClosure cl(pm); >> + oop_oop_iterate_oop_maps_reverse(obj, &cl); >> +} >> >> where the do_oop function is implemented as: >> + >> + template void do_oop_nv(T* p) { >> + if (PSScavenge::should_scavenge(p)) { >> + _pm->claim_or_forward_depth(p); >> + } >> >> From the same file, it can be seen how that the implementation to >> follow the references in the mirrors are using the same closure: >> >> +void InstanceMirrorKlass::oop_ps_push_contents(oop obj, >> PSPromotionManager* pm) { >> ... >> + InstanceKlass::oop_ps_push_contents(obj, pm); >> + >> + PushContentsClosure cl(pm); >> + oop_oop_iterate_statics(obj, &cl); >> +} >> >> As can be seen above, the functions are still members of the >> different Klasses, but only the declaration is put in the klass.hpp >> files. The actual implementation is put in the GC files. This helps >> decoupling the different GCs and the Klasses. We could move the >> functions over to a GC specific "visitor" and have a generic "accept" >> function in the Klasses, but that approach would require two virtual >> calls, while the current implementation only needs one. >> >> In the future we might want to remove these functions from the >> *Klasses and reuse the already existing code in the oop_oop_iterate >> framework. >> >> If we take the InstanceMirrorKlass::oop_ps_push_contents function >> above as an example, it could be implemented with >> InstanceMirrorKlass::oop_oop_iterate, since they share the same >> structure: >> >> 54 template >> 55 int InstanceMirrorKlass::oop_oop_iterate(oop obj, >> OopClosureType* closure) { >> 56 InstanceKlass::oop_oop_iterate(obj, closure); >> 57 >> 58 if (Devirtualizer::do_metadata(closure)) { >> 59 Klass* klass = java_lang_Class::as_Klass(obj); >> 60 // We'll get NULL for primitive mirrors. >> 61 if (klass != NULL) { >> 62 Devirtualizer::do_klass(closure, klass); >> 63 } >> 64 } >> 65 >> 66 oop_oop_iterate_statics(obj, closure); >> 67 >> 68 return oop_size(obj); >> 69 } >> >> Parallel Scavenge doesn't visit the klass pointers and do_metadata >> returns false, so that code path will be eliminated by the compiler. >> We would have to do something about the return oop_size(obj), since >> we don't want to do that unnecessarily. To change the GC object >> visitors to entirely use the oop_oop_iterator framework is out of >> scope for this patch. >> >> The object visitor functions were renamed and moved as follows: >> oop_follow_contents(opp) -> oop_ms_follow_contents(oop) in >> markSweep.cpp >> oop_adjust_pointers(oop) -> oop_ms_adjust_pointers(oop) in >> markSweep.cpp >> oop_follow_contents(oop, ParCompactionManager*) -> >> oop_pc_follow_contents(...) in psCompactionManager.cpp >> oop_update_pointers(oop) -> oop_pc_update_pointers(oop) in >> psParallelCompact.cpp >> oop_push_contents(oop, PSPromotionManager*) -> >> oop_ps_push_contents(...) in psPromotionManager.cpp >> >> >> - The oop iterate macros used to take an assert parameter to be >> applied to oop* that were visited. By default, the check was >> assert_is_in_closed_subset, but MS, PS and PC provided their own >> asserts. ExtendedOopClosure has been handed the task to provide the >> default verification, but also a way to turn it off for individual >> closures, so that they can provide their own asserts. See: >> ExtendedOopClosure::verify() and >> ExtendedOopClosure::should_verify_oops() and how the Devirtualizer >> dispatch class calls the verification code: >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/iterator.inline.hpp.udiff.html >> >> >> +template >> +inline void Devirtualizer::do_oop(OopClosureType* closure, T* >> p) { >> + debug_only(closure->verify(p)); >> + closure->do_oop_nv(p); >> +} >> >> >> - Moved PSParallelCompact::MarkAndPushClosure::do_oop, >> PSParallelCompact::AdjustPointerClosure::do_oop, mark_and_push, >> adjust pointer, and follow_klass to psParallelCompact.inline.hpp >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html >> >> >> >> - Add seemingly incorrect includes between GCs. This is needed since >> we currently have no separation between GCs when we generate the >> oop_since_save_marks_iterate functions. See: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/defNewGeneration.cpp.udiff.html >> >> >> and the include of ParNew specific closures: >> 51 #if INCLUDE_ALL_GCS >> 52 #include "gc_implementation/parNew/parOopClosures.hpp" >> 53 #endif >> >> which is needed to be able to generate: >> 856 ALL_SINCE_SAVE_MARKS_CLOSURES(DefNew_SINCE_SAVE_MARKS_DEFN) >> >> This should be changed in a separate patch, so that DefNew only >> generates oop_since_save_marks_iterate that takes DefNew specfic >> closures. >> >> >> The initial performance runs showed a slight increase of the GC times >> on some benchmarks on Solaris and Windows. The reason for this >> increase was that the these compilers didn't inline as much as the >> hand-inlined macros used to do. To remedy this I've increased the >> inlining in to ways: >> >> - Turned on extra inlining for psPromotionManager.cpp when compiling >> with the Solaris Studio Compiler >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/make/solaris/makefiles/product.make.udiff.html >> >> >> >> - Added __forceinline to the InstanceKlass::oop_oop_iterate functions >> when compiling with the MS compiler. >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html >> >> >> >> A previous version of this patch has been run through our testing, >> but I've recently done changes and extracted smaller patches, so I'll >> have to rerun all testing. >> >> Any requests for extra testing to be done? >> >> Thanks, >> StefanK >> > From staffan.larsen at oracle.com Mon Mar 30 08:34:58 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 30 Mar 2015 10:34:58 +0200 Subject: RFR 8023093: Add ManagementAgent.status diagnostic command In-Reply-To: <5515857E.9080902@oracle.com> References: <5515857E.9080902@oracle.com> Message-ID: <8E71E422-8372-455F-93E0-27ED36BCBE3B@oracle.com> Looks good! Thanks for splitting up the test file. This test has been known to be unstable - what platforms have you verified the changes on? Thanks, /Staffan > On 27 mar 2015, at 17:29, Jaroslav Bachorik wrote: > > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8023093 > Webrev: http://cr.openjdk.java.net/~jbachorik/8023093/webrev.00 (hotspot, jdk) > > This change adds a new 'ManagementAgent.status' diagnostic command. This command will output the current status of the management agent in the following format > > ``` > Agent: > > ( > ConnectionType: > Protocol: > Host: > URL: > > ( > Properties: > ( > = > )+ > )? > )+ > ``` > > Where: > means an arbitrary value > | means 'or' > ( and ) denote a block > + block repeats one or more times > ? block appears at most once > > A new test is added exercising this diagnostic command. While adding the test I factored out the shared functionality from the JMXStartStopTest class and caused the changes in the test area to be a bit more extensive than just adding a new test class. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Mar 30 10:47:49 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 30 Mar 2015 12:47:49 +0200 Subject: RFR 8023093: Add ManagementAgent.status diagnostic command In-Reply-To: <8E71E422-8372-455F-93E0-27ED36BCBE3B@oracle.com> References: <5515857E.9080902@oracle.com> <8E71E422-8372-455F-93E0-27ED36BCBE3B@oracle.com> Message-ID: <551929D5.2060509@oracle.com> On 30.3.2015 10:34, Staffan Larsen wrote: > Looks good! > > Thanks for splitting up the test file. This test has been known to be unstable - what platforms have you verified the changes on? I ran the tests on all the available platforms in JPRT. So far so good. -JB- > > Thanks, > /Staffan > >> On 27 mar 2015, at 17:29, Jaroslav Bachorik wrote: >> >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8023093 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8023093/webrev.00 (hotspot, jdk) >> >> This change adds a new 'ManagementAgent.status' diagnostic command. This command will output the current status of the management agent in the following format >> >> ``` >> Agent: >> >> ( >> ConnectionType: >> Protocol: >> Host: >> URL: >> >> ( >> Properties: >> ( >> = >> )+ >> )? >> )+ >> ``` >> >> Where: >> means an arbitrary value >> | means 'or' >> ( and ) denote a block >> + block repeats one or more times >> ? block appears at most once >> >> A new test is added exercising this diagnostic command. While adding the test I factored out the shared functionality from the JMXStartStopTest class and caused the changes in the test area to be a bit more extensive than just adding a new test class. >> >> Thanks, >> >> -JB- > From sgehwolf at redhat.com Mon Mar 30 11:07:22 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 30 Mar 2015 13:07:22 +0200 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: References: Message-ID: <1427713642.3437.27.camel@redhat.com> Hi Thomas, On Fri, 2015-03-27 at 19:00 +0100, Thomas St?fe wrote: > Hi all, > > > Please review this change which provides a real SafeFetch > implementation > on zero. > > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8076185/webrev.01/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8076185 > > > It works like this: > > > Before a load is attempted from a potentially unsafe address, we set > up a > jump buffer with sigsetjmp(). In the signal handler, for SIGSEGV and > SIGBUS, > we test whether there is a jump buffer set and if yes, take this as an > indication > that the crash was an attempted SafeFetch. In this case we jump back > via longjmp(). > > > Coding is a bit more difficult because we need to be threadsafe. We > keep the jump > buffer on the thread stack - this is ok, because that stack never gets > unwinded > - either we crash, in which case signal handler stack frames are > built up below > us, or we don't crash, in which case we never leave the SafeFetch > function. In > both cases, we never loose the jump buffer. > > > To communicate the jump buffer location to the signal handler, TLS is > used. I > use POSIX tls, because that always works and is not dependend on VM > infrastructure. > > > --- > > > I built and tested this on Linux x64 zero (Ubuntu 14.4). It works and > the > initialization tests for SafeFetch in the stub routine initialization > now work for > zero too. > > > Note that I do not have a BSD system right now, so I cannot check > whether this > change builds and works for BSD. But the change only requires POSIX > Apis, so > BSD should probably be ok. > > > Someone from the zero team should definitly check and test this for > other zero > platforms, but the chances are good that this just works. Thomas, thanks very much for this patch! It works fine for me on x86_64 F21, but I'd also like to test on non-x86. Zero is notoriously stack hungry and having the jump buffer on the stack too is a bit of a concern (but probably fine). Testing that too, though, will take a while, since I don't have such hardware readily available. As for the patch (I'm not a reviewer): It looks fine to me. It's certainly a lot better than this unsafe SafeFetch that we currently use for Zero. Thanks, Severin > Thanks and Kind Regards, > > > Thomas Stuefe > > From thomas.stuefe at gmail.com Mon Mar 30 12:32:36 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 30 Mar 2015 14:32:36 +0200 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: <1427713642.3437.27.camel@redhat.com> References: <1427713642.3437.27.camel@redhat.com> Message-ID: Hi Severin, thanks for testing! I am pretty sure the coding is POSIX compliant and therefore should work fine on all POSIX platforms. If stack space is a problem, jump buffer could be moved to C-Heap. However, this might not be necessary. I checked some sizes on some platforms: x64 linux ucontext_t 936 sigjmp_buf 200 ia64 linux ucontext_t 2656 sigjmp_buf 704 ia64 hpux ucontext_t 48640 sigjmp_buf 1280 power AIX ucontext_t 688 sigjmp_buf 680 largest sigjmp_buf I saw was HP-UX with 1.2K. I think we routinely do worse than that e.g. during error reporting. (Note, in comparison, that ucontext_t can be monstrous :-) - but then, it wants to do much more than unwinding the stack in a single thread). So, advantage of less stack is offset by performance (malloc) and potentially errors (if C heap is corrupted we might still want to do SafeFetch()). I don't know. I think leaving that thing on the stack is fine unless you want very small stacks. Kind Regards, Thomas On Mon, Mar 30, 2015 at 1:07 PM, Severin Gehwolf wrote: > Hi Thomas, > > On Fri, 2015-03-27 at 19:00 +0100, Thomas St?fe wrote: > > Hi all, > > > > > > Please review this change which provides a real SafeFetch > > implementation > > on zero. > > > > > > webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8076185/webrev.01/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8076185 > > > > > > It works like this: > > > > > > Before a load is attempted from a potentially unsafe address, we set > > up a > > jump buffer with sigsetjmp(). In the signal handler, for SIGSEGV and > > SIGBUS, > > we test whether there is a jump buffer set and if yes, take this as an > > indication > > that the crash was an attempted SafeFetch. In this case we jump back > > via longjmp(). > > > > > > Coding is a bit more difficult because we need to be threadsafe. We > > keep the jump > > buffer on the thread stack - this is ok, because that stack never gets > > unwinded > > - either we crash, in which case signal handler stack frames are > > built up below > > us, or we don't crash, in which case we never leave the SafeFetch > > function. In > > both cases, we never loose the jump buffer. > > > > > > To communicate the jump buffer location to the signal handler, TLS is > > used. I > > use POSIX tls, because that always works and is not dependend on VM > > infrastructure. > > > > > > --- > > > > > > I built and tested this on Linux x64 zero (Ubuntu 14.4). It works and > > the > > initialization tests for SafeFetch in the stub routine initialization > > now work for > > zero too. > > > > > > Note that I do not have a BSD system right now, so I cannot check > > whether this > > change builds and works for BSD. But the change only requires POSIX > > Apis, so > > BSD should probably be ok. > > > > > > Someone from the zero team should definitly check and test this for > > other zero > > platforms, but the chances are good that this just works. > > Thomas, thanks very much for this patch! It works fine for me on x86_64 > F21, but I'd also like to test on non-x86. Zero is notoriously stack > hungry and having the jump buffer on the stack too is a bit of a concern > (but probably fine). Testing that too, though, will take a while, since > I don't have such hardware readily available. > > As for the patch (I'm not a reviewer): It looks fine to me. It's > certainly a lot better than this unsafe SafeFetch that we currently use > for Zero. > > Thanks, > Severin > > > Thanks and Kind Regards, > > > > > > Thomas Stuefe > > > > > > > > From dmitry.samersoff at oracle.com Mon Mar 30 13:37:05 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 30 Mar 2015 16:37:05 +0300 Subject: RFR(s): 8076012 - SA don't support flags of type size_t In-Reply-To: <55130822.4050702@oracle.com> References: <55130822.4050702@oracle.com> Message-ID: <55195181.40204@oracle.com> Jesper, Looks good for me. -Dmitry On 2015-03-25 22:10, Jesper Wilhelmsson wrote: > Hi, > > Please review this fix for the serviceability agent to support flags of > type size_t. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076012 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8076012/webrev.00/ > > This bug is currently blocking the GC repository from being synced with > main after the change to make a bunch of flags size_t. > > The reason it wasn't found when doing that change was that the tests > that now failed in our nightly testing needs privileged access to be > able to attach to the test process. If it doesn't have the needed > privileges the tests simply exits and reports a success. Local testing > therefor did not see this as a failure. > Why the tests aren't run in JPRT I don't know. I thought they were. (Or > maybe they are but without the proper privileges.) > > Thanks! > /Jesper -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jesper.wilhelmsson at oracle.com Mon Mar 30 13:42:41 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 30 Mar 2015 15:42:41 +0200 Subject: RFR(s): 8076012 - SA don't support flags of type size_t In-Reply-To: <55195181.40204@oracle.com> References: <55130822.4050702@oracle.com> <55195181.40204@oracle.com> Message-ID: <551952D1.7020703@oracle.com> Thanks! /Jesper Dmitry Samersoff skrev den 30/3/15 15:37: > Jesper, > > Looks good for me. > > -Dmitry > > On 2015-03-25 22:10, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this fix for the serviceability agent to support flags of >> type size_t. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076012 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8076012/webrev.00/ >> >> This bug is currently blocking the GC repository from being synced with >> main after the change to make a bunch of flags size_t. >> >> The reason it wasn't found when doing that change was that the tests >> that now failed in our nightly testing needs privileged access to be >> able to attach to the test process. If it doesn't have the needed >> privileges the tests simply exits and reports a success. Local testing >> therefor did not see this as a failure. >> Why the tests aren't run in JPRT I don't know. I thought they were. (Or >> maybe they are but without the proper privileges.) >> >> Thanks! >> /Jesper > > From sgehwolf at redhat.com Mon Mar 30 14:22:00 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 30 Mar 2015 16:22:00 +0200 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: References: <1427713642.3437.27.camel@redhat.com> Message-ID: <1427725320.3437.36.camel@redhat.com> Hi Thomas, I think it should be fine to keep the jump buffer on the stack. Thanks for the numbers! Cheers, Severin On Mon, 2015-03-30 at 14:32 +0200, Thomas St?fe wrote: > Hi Severin, > > > thanks for testing! I am pretty sure the coding is POSIX compliant and > therefore should work fine on all POSIX platforms. > > > If stack space is a problem, jump buffer could be moved to C-Heap. > However, this might not be necessary. I checked some sizes on some > platforms: > > > x64 linux > ucontext_t 936 > sigjmp_buf 200 > > > ia64 linux > ucontext_t 2656 > sigjmp_buf 704 > > > ia64 hpux > ucontext_t 48640 > sigjmp_buf 1280 > > > power AIX > ucontext_t 688 > sigjmp_buf 680 > > > largest sigjmp_buf I saw was HP-UX with 1.2K. I think we routinely do > worse than that e.g. during error reporting. > > > (Note, in comparison, that ucontext_t can be monstrous :-) - but then, > it wants to do much more than unwinding the stack in a single thread). > > > So, advantage of less stack is offset by performance (malloc) and > potentially errors (if C heap is corrupted we might still want to do > SafeFetch()). I don't know. I think leaving that thing on the stack is > fine unless you want very small stacks. > > > Kind Regards, Thomas > > > > > > > > > > > > > > > On Mon, Mar 30, 2015 at 1:07 PM, Severin Gehwolf > wrote: > Hi Thomas, > > On Fri, 2015-03-27 at 19:00 +0100, Thomas St?fe wrote: > > Hi all, > > > > > > Please review this change which provides a real SafeFetch > > implementation > > on zero. > > > > > > webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8076185/webrev.01/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8076185 > > > > > > It works like this: > > > > > > Before a load is attempted from a potentially unsafe > address, we set > > up a > > jump buffer with sigsetjmp(). In the signal handler, for > SIGSEGV and > > SIGBUS, > > we test whether there is a jump buffer set and if yes, take > this as an > > indication > > that the crash was an attempted SafeFetch. In this case we > jump back > > via longjmp(). > > > > > > Coding is a bit more difficult because we need to be > threadsafe. We > > keep the jump > > buffer on the thread stack - this is ok, because that stack > never gets > > unwinded > > - either we crash, in which case signal handler stack > frames are > > built up below > > us, or we don't crash, in which case we never leave the > SafeFetch > > function. In > > both cases, we never loose the jump buffer. > > > > > > To communicate the jump buffer location to the signal > handler, TLS is > > used. I > > use POSIX tls, because that always works and is not > dependend on VM > > infrastructure. > > > > > > --- > > > > > > I built and tested this on Linux x64 zero (Ubuntu 14.4). It > works and > > the > > initialization tests for SafeFetch in the stub routine > initialization > > now work for > > zero too. > > > > > > Note that I do not have a BSD system right now, so I cannot > check > > whether this > > change builds and works for BSD. But the change only > requires POSIX > > Apis, so > > BSD should probably be ok. > > > > > > Someone from the zero team should definitly check and test > this for > > other zero > > platforms, but the chances are good that this just works. > > > Thomas, thanks very much for this patch! It works fine for me > on x86_64 > F21, but I'd also like to test on non-x86. Zero is notoriously > stack > hungry and having the jump buffer on the stack too is a bit of > a concern > (but probably fine). Testing that too, though, will take a > while, since > I don't have such hardware readily available. > > As for the patch (I'm not a reviewer): It looks fine to me. > It's > certainly a lot better than this unsafe SafeFetch that we > currently use > for Zero. > > Thanks, > Severin > > > Thanks and Kind Regards, > > > > > > Thomas Stuefe > > > > > > > > > > From vladimir.kozlov at oracle.com Mon Mar 30 16:55:53 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 Mar 2015 09:55:53 -0700 Subject: How to build HS with Oracle Studio Compiler on Oracle Linux platform? In-Reply-To: <5515C4BC.7000004@oracle.com> References: <54CAD441.8030307@oracle.com> <5515C4BC.7000004@oracle.com> Message-ID: <55198019.7080208@oracle.com> Hi Sergey, How are you building Hotspot? You can try to pass USE_SUNCC=1 parameter and add your CC bin/ directory to PATH. I tried and got: /ws/ntrunk/builds/trunk/biweekly/build11.0/intel-Linux/install/lib/compilers/ccfe: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory Regards, Vladimir On 3/27/15 1:59 PM, Sergey Sprogis wrote: > Compiler QA team needs to test newly developed Oracle Studio C++ > Compiler (64-bit version): > > /ws/ntrunk/builds/trunk/biweekly/latest/inst/intel-Linux/bin/CC > > with latest Hotspot sources (in fastdebug mode) which I downloaded from: > > /net/koori.us.oracle.com/onestop/jdk/9/promoted/all/b56/ws > > I can build those sources on solaris-sparcv9 or on solaris-x64 by > defining ALT_COMPILER_PATH, > but on linux-x64 it seems does not work and gcc has been invoked > instead of CC. > > Could anyone give me some suggestions what should be changed in HS build > environment to switch from gcc to CC on linux-x64? > > Thanks, > > Sergey From max.ockner at oracle.com Mon Mar 30 18:08:08 2015 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 30 Mar 2015 14:08:08 -0400 Subject: RFR: 8073989: Deprecated integer options are now recognized as obsolete. Message-ID: <55199108.9030102@oracle.com> Hello all, Please review this change involving the handling of obsolete command line flags. Bug: https://bugs.openjdk.java.net/browse/JDK-8073989 Webrev: http://cr.openjdk.java.net/~mockner/8073989.2/ Summary: Three key components to this bug: (1) When is_newly_obsolete() checks for "SomeObsoleteIntegerFlag=100" in the flag table, it is not recognized as a match with "SomeObsoleteIntegerFlag" because the lengths are different. This has been fixed. Arguments:process_argument() now strips everything except for the arguments name. (example: -XX:+SomeBooleanFlag -> "SomeBooleanFlag", and -XX:SomeIntegerFlag=100 -> "SomeIntegerFlag") This stripped argument name (fittingly called stripped_argname) is now passed into is_newly_obsolete, preventing the length check from failing on obsolete (but formeerly valid) arguments. It also eliminates the need for any case work and other string gymnastics from the the body of is_newly_obsolete. If the argument is found to be newly obsolete, the warning message now prints stripped_argname instead of argname to avoid suggesting that "SomeBooleanFlag=100" was ever a supported option. (2) Some flags used to be defined in both the flags table and the obsolete flags table. Because of this, those obsolete flags which were also defined in the flags table could be fuzzy matched to provide better error messages. Now that no flag is allowed to be in both tables, it is pointless to attempt to fuzzy match an obsolete flag, since fuzzy matching only looks in the flags table (not the obsolete flags table). The section at the end of Arguments:process_argument in which fuzzy matching is attempted on obsolete arguments no longer makes sense and has been removed. (3) ObsoleteFlagErrorMessage.java has been modified. The existing test for an obsolete flag with appended junk no longer tests for fuzzy matching, and a second test case has been added for integer valued flags. Tested with jtreg runtime tests. Thanks, Max Ockner From christian.thalinger at oracle.com Mon Mar 30 18:29:14 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 30 Mar 2015 11:29:14 -0700 Subject: RFR: 8075735: Missing include causes minimal build failure In-Reply-To: References: <55102BF7.7010604@oracle.com> <55112BF8.4070500@oracle.com> <55114206.1070704@oracle.com> Message-ID: <0304D1B5-B52F-40DB-922B-67B276998434@oracle.com> > On Mar 24, 2015, at 6:29 AM, Volker Simonis wrote: > > When do we finally run NON-PCH builds in JPRT? I second that. > > That's long overdue. I think it will save us from a lot of problems > llike this one at the minimal cost of some cpu-cycles. > > Regards, > Volker > > > On Tue, Mar 24, 2015 at 11:52 AM, Stefan Johansson > wrote: >> Thanks for the reviews Joe, David and Stefan. >> >> I've updated the bug with info on when this was introduced. The reason it >> was not caught by JPRT is because it uses pre-compiled headers, and it >> probably hides the problem. In my local builds I disable pre-compiled >> headers and for minimal that shows the problem. >> >> Thanks, >> Stefan >> >> >> On 2015-03-24 10:18, Stefan Karlsson wrote: >>> >>> On 2015-03-23 16:06, Stefan Johansson wrote: >>>> >>>> Hi, >>>> >>>> Please review this small change to fix: >>>> https://bugs.openjdk.java.net/browse/JDK-8075735 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sjohanss/8075735/hotspot.00/ >>> >>> >>> Looks good. >>> >>> StefanK >>> >>>> >>>> Summary: >>>> Minimal1 currently does not build in the hs-gc repo. The cause is a >>>> missing include in thread.cpp, which is added by the proposed change. >>>> >>>> Testing: >>>> Verified that minimal1 builds and run after the change. >>>> >>>> Thanks, >>>> Stefan >>> >>> >> From vladimir.kozlov at oracle.com Mon Mar 30 20:56:32 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 Mar 2015 13:56:32 -0700 Subject: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB8DBE@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFB8DBE@DEWDFEMB12A.global.corp.sap> Message-ID: <5519B880.20106@oracle.com> Good. Thanks, Vladimir On 3/27/15 12:58 AM, Lindenmaier, Goetz wrote: > Hi, > > on Aix, we don't support large pages. > This needs to be manifested in arguments.cpp. > The change simply reuses a #ifdef BSD for AIX, too. > > Please review this tiny change, and I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8076057-aixULP/webrev.00/ > > Best regards, > Goetz. > From coleen.phillimore at oracle.com Mon Mar 30 23:18:55 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 30 Mar 2015 19:18:55 -0400 Subject: RFR: 8075955: Replace the macro based implementation of oop_oop_iterate with a template based solution In-Reply-To: <5518FD73.6020602@oracle.com> References: <5514354B.6060505@oracle.com> <5515ACBB.1010108@oracle.com> <5518FD73.6020602@oracle.com> Message-ID: <5519D9DF.4060908@oracle.com> On 3/30/15, 3:38 AM, Stefan Karlsson wrote: > Hi Coleen, > > On 2015-03-27 20:17, Coleen Phillimore wrote: >> >> Stefan, >> This is a huge change and I've never pretended to know how these >> macros work. I won't pretend I can read these templates quickly >> either. From my runtime perspective, the change looks fine. >> Actually, they look great. > > Thanks for looking at this patch. > >> I have a couple minor comments but nothing deep. >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp.udiff.html >> >> >> +void InstanceKlass::oop_pc_follow_contents(oop obj, >> ParCompactionManager* cm) { >> >> It seems like these functions never belonged in InstanceKlass, etc >> and with your change, can you make them actually owned by the GC >> function they call? Like this one seems that it should be owned by >> PSParallelCompact. Or do they all have to have the same name? > > I agree that we want to get rid of these functions from the *Klasses, > but I don't see a small, incremental change that I could do to solve > it. Two alternatives that I tried to explain further down in the mail: > > 1) Reuse the oop_oop_iterate framework. That will be quite a large > change by itself, but hopefully doable. > > 2) Make a common object visitor function, say > Klass::oop_accept(ObjectVisitor* visitor), and then have the GC code do: > > PCFollowContents follow_contents(cm); > > obj->klass()->oop_accept(&follow_contents); > > The drawback of that solution is that we get two virtual calls: The > first is when calling Klass::oop_accept to get "inside" the correct > sub-Klass, and the second is the call to ObjectVisitor::visit(this /* > the sub-Klass */) from the dispatched sub-Klass. > > Getting rid of the second virtual call is exactly what we accomplish > by having the oop_pc_follow_contents in the *Klasses. This was really just a comment and question. I don't think you should change this. It's a big enough change! > >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.hpp.udiff.html >> >> >> + // Iterate over oop elements with indices within [start, end), and >> metadata. >> >> + // Iterate over oop elements within [start, end), and metadata. >> >> >> These have the wrong sort of closed bracket (messes up 'vi') - should >> be ']' > > I'm not sure I understand what you mean. The [ bracket means > inclusive, while the ) bracket is supposed to mean exclusive. Just > like what's described in: > http://en.wikipedia.org/wiki/Bracket_(mathematics)#Intervals Ok. Sure, it just looked odd to me and my non-mathematical editor. Coleen > >> >> That's all. > > Thanks! > StefanK > >> Coleen >> >> On 3/26/15, 12:35 PM, Stefan Karlsson wrote: >>> Hi, >>> >>> Please review this patch to replace the macro based implementation >>> of oop_oop_iterate with a template based solution. >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8075955 >>> >>> Summary of the changes: >>> >>> - Replace the macro implementation of the different oop_oop_iterate >>> functions with template functions. The implementation is moved out >>> from the *Klass.cpp files into the *Klass.inline.hpp files, to be >>> able to generate the specialized oop_oop_iterate functions in >>> suitable GC specific files. >>> >>> See the old macro implementation: >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.cpp.udiff.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html >>> >>> >>> That has now been converted into template functions: >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.inline.hpp.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.inline.hpp.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.inline.hpp.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.inline.hpp.html >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.inline.hpp.udiff.html >>> >>> >>> There's still a closure specialization layer implemented with macros >>> to support the code to allows the code to pass down the concrete >>> closure type, past the virtual Klass::oop_oop_iterate_nv(...) call. >>> The macros just calls the new template functions: >>> >>> 191 #define InstanceKlass_OOP_OOP_ITERATE_DEFN(OopClosureType, >>> nv_suffix) \ >>> 192 int InstanceKlass::oop_oop_iterate##nv_suffix(oop obj, >>> OopClosureType* closure) { \ >>> 193 return oop_oop_iterate(obj, >>> closure); \ >>> 194 } >>> >>> We might want to remove this in a future patch, by providing our >>> own dispatch mechanism. >>> >>> >>> - Split the generation of the specialized oop_oop_iterate >>> definitions, so that we keep code from different GCs separated. >>> Before this patch, code from all GCs were generated into >>> instanceKlass.cpp, instanceMirrorKlass.cpp, >>> instanceClassLoaderKlass.cpp, instanceRefKlass.cpp, >>> typeArrayKlass.cpp, and objArrayKlass.cpp. >>> >>> Now the definitions are generated into: >>> G1: >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/g1/g1OopClosures.cpp.udiff.html >>> CMS: >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.cpp.html >>> ParNew: >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.cpp.html >>> Serial: >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/genOopClosures.cpp.html >>> >>> >>> - The other GCs don't use use the above mentioned closure >>> specialization, that is, they don't call obj->oop_iterate(&cl) to >>> follow the objects. Instead they have their own "visitor" functions >>> located in the oopDesc and *Klass classes. For example, Parallel >>> Scavenge calls obj->push_contents(...), which calls >>> Klass::oop_push_contents(...), to follow outgoing pointers after an >>> object has been moved. These visitor functions used to use the oop >>> iterate macros and pass down snippets of code to be applied to each >>> oop*. This has now been changed to use use closures and the new >>> oop_oop_iterate template functions. >>> >>> The implementation of these object visitor functions have been moved >>> out from the *Klass.cpp files and into the GCs that the functions >>> support. >>> >>> Using Parallel Scavenge as and example: >>> >>> The implementation to handle the references out of a copied object >>> was located in: >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html >>> >>> >>> -void InstanceKlass::oop_push_contents(PSPromotionManager* pm, oop >>> obj) { >>> - InstanceKlass_OOP_MAP_REVERSE_ITERATE( \ >>> - obj, \ >>> - if (PSScavenge::should_scavenge(p)) { \ >>> - pm->claim_or_forward_depth(p); \ >>> - }, \ >>> - assert_nothing ) >>> -} >>> >>> and has now been moved to: >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html >>> >>> >>> +void InstanceKlass::oop_ps_push_contents(oop obj, >>> PSPromotionManager* pm) { >>> + PushContentsClosure cl(pm); >>> + oop_oop_iterate_oop_maps_reverse(obj, &cl); >>> +} >>> >>> where the do_oop function is implemented as: >>> + >>> + template void do_oop_nv(T* p) { >>> + if (PSScavenge::should_scavenge(p)) { >>> + _pm->claim_or_forward_depth(p); >>> + } >>> >>> From the same file, it can be seen how that the implementation to >>> follow the references in the mirrors are using the same closure: >>> >>> +void InstanceMirrorKlass::oop_ps_push_contents(oop obj, >>> PSPromotionManager* pm) { >>> ... >>> + InstanceKlass::oop_ps_push_contents(obj, pm); >>> + >>> + PushContentsClosure cl(pm); >>> + oop_oop_iterate_statics(obj, &cl); >>> +} >>> >>> As can be seen above, the functions are still members of the >>> different Klasses, but only the declaration is put in the klass.hpp >>> files. The actual implementation is put in the GC files. This helps >>> decoupling the different GCs and the Klasses. We could move the >>> functions over to a GC specific "visitor" and have a generic >>> "accept" function in the Klasses, but that approach would require >>> two virtual calls, while the current implementation only needs one. >>> >>> In the future we might want to remove these functions from the >>> *Klasses and reuse the already existing code in the oop_oop_iterate >>> framework. >>> >>> If we take the InstanceMirrorKlass::oop_ps_push_contents function >>> above as an example, it could be implemented with >>> InstanceMirrorKlass::oop_oop_iterate, since they share the same >>> structure: >>> >>> 54 template >>> 55 int InstanceMirrorKlass::oop_oop_iterate(oop obj, >>> OopClosureType* closure) { >>> 56 InstanceKlass::oop_oop_iterate(obj, closure); >>> 57 >>> 58 if (Devirtualizer::do_metadata(closure)) { >>> 59 Klass* klass = java_lang_Class::as_Klass(obj); >>> 60 // We'll get NULL for primitive mirrors. >>> 61 if (klass != NULL) { >>> 62 Devirtualizer::do_klass(closure, klass); >>> 63 } >>> 64 } >>> 65 >>> 66 oop_oop_iterate_statics(obj, closure); >>> 67 >>> 68 return oop_size(obj); >>> 69 } >>> >>> Parallel Scavenge doesn't visit the klass pointers and do_metadata >>> returns false, so that code path will be eliminated by the compiler. >>> We would have to do something about the return oop_size(obj), since >>> we don't want to do that unnecessarily. To change the GC object >>> visitors to entirely use the oop_oop_iterator framework is out of >>> scope for this patch. >>> >>> The object visitor functions were renamed and moved as follows: >>> oop_follow_contents(opp) -> oop_ms_follow_contents(oop) in >>> markSweep.cpp >>> oop_adjust_pointers(oop) -> oop_ms_adjust_pointers(oop) in >>> markSweep.cpp >>> oop_follow_contents(oop, ParCompactionManager*) -> >>> oop_pc_follow_contents(...) in psCompactionManager.cpp >>> oop_update_pointers(oop) -> oop_pc_update_pointers(oop) in >>> psParallelCompact.cpp >>> oop_push_contents(oop, PSPromotionManager*) -> >>> oop_ps_push_contents(...) in psPromotionManager.cpp >>> >>> >>> - The oop iterate macros used to take an assert parameter to be >>> applied to oop* that were visited. By default, the check was >>> assert_is_in_closed_subset, but MS, PS and PC provided their own >>> asserts. ExtendedOopClosure has been handed the task to provide the >>> default verification, but also a way to turn it off for individual >>> closures, so that they can provide their own asserts. See: >>> ExtendedOopClosure::verify() and >>> ExtendedOopClosure::should_verify_oops() and how the Devirtualizer >>> dispatch class calls the verification code: >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/iterator.inline.hpp.udiff.html >>> >>> >>> +template >>> +inline void Devirtualizer::do_oop(OopClosureType* closure, T* >>> p) { >>> + debug_only(closure->verify(p)); >>> + closure->do_oop_nv(p); >>> +} >>> >>> >>> - Moved PSParallelCompact::MarkAndPushClosure::do_oop, >>> PSParallelCompact::AdjustPointerClosure::do_oop, mark_and_push, >>> adjust pointer, and follow_klass to psParallelCompact.inline.hpp >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html >>> >>> >>> >>> - Add seemingly incorrect includes between GCs. This is needed since >>> we currently have no separation between GCs when we generate the >>> oop_since_save_marks_iterate functions. See: >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/defNewGeneration.cpp.udiff.html >>> >>> >>> and the include of ParNew specific closures: >>> 51 #if INCLUDE_ALL_GCS >>> 52 #include "gc_implementation/parNew/parOopClosures.hpp" >>> 53 #endif >>> >>> which is needed to be able to generate: >>> 856 ALL_SINCE_SAVE_MARKS_CLOSURES(DefNew_SINCE_SAVE_MARKS_DEFN) >>> >>> This should be changed in a separate patch, so that DefNew only >>> generates oop_since_save_marks_iterate that takes DefNew specfic >>> closures. >>> >>> >>> The initial performance runs showed a slight increase of the GC >>> times on some benchmarks on Solaris and Windows. The reason for this >>> increase was that the these compilers didn't inline as much as the >>> hand-inlined macros used to do. To remedy this I've increased the >>> inlining in to ways: >>> >>> - Turned on extra inlining for psPromotionManager.cpp when compiling >>> with the Solaris Studio Compiler >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/make/solaris/makefiles/product.make.udiff.html >>> >>> >>> >>> - Added __forceinline to the InstanceKlass::oop_oop_iterate >>> functions when compiling with the MS compiler. >>> >>> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html >>> >>> >>> >>> A previous version of this patch has been run through our testing, >>> but I've recently done changes and extracted smaller patches, so >>> I'll have to rerun all testing. >>> >>> Any requests for extra testing to be done? >>> >>> Thanks, >>> StefanK >>> >> > From david.holmes at oracle.com Tue Mar 31 00:40:06 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Mar 2015 10:40:06 +1000 Subject: Potential build problem in jdk9/hs-* forests Message-ID: <5519ECE6.7030905@oracle.com> The hotspot forests did a sync up with jdk9/dev which included the following changeset: changeset: 1407:e805c9330c7a user: ihse date: Thu Mar 26 16:17:30 2015 +0100 summary: 8076060: Improve make bootstrap process Unfortunately that changeset has a number of issues which were fixed in a follow up: changeset: 1405:f077ae77feb1 tag: tip user: erikj date: Fri Mar 27 14:11:26 2015 +0100 summary: 8076123: 9-dev build fail: make/Init.gmk:142: *** multiple target patterns. Stop. but that won't be pulled in until this week's sync up. One way you may be affected is if you run configure from the top-level of the forest. Then when you run make you might get: Error: SPEC mismatch. $(TOPDIR) does not match current directory A workaround is to not run configure from the top directory but to add a subdirectory (eg builds) and run configure from there. Of course in your local repos you could also pull in the fixed changeset from jdk9/dev. Cheers, David From david.holmes at oracle.com Tue Mar 31 01:45:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Mar 2015 11:45:34 +1000 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: References: Message-ID: <5519FC3E.2070409@oracle.com> Hi Thomas, If you are happy with Severin's review I can add my Review to the shared part (Zero part looks okay too) and sponsor it. David On 28/03/2015 4:00 AM, Thomas St?fe wrote: > Hi all, > > Please review this change which provides a real SafeFetch implementation > on zero. > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8076185/webrev.01/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8076185 > > It works like this: > > Before a load is attempted from a potentially unsafe address, we set up a > jump buffer with sigsetjmp(). In the signal handler, for SIGSEGV and SIGBUS, > we test whether there is a jump buffer set and if yes, take this as an > indication > that the crash was an attempted SafeFetch. In this case we jump back via > longjmp(). > > Coding is a bit more difficult because we need to be threadsafe. We keep > the jump > buffer on the thread stack - this is ok, because that stack never gets > unwinded > - either we crash, in which case signal handler stack frames are built up > below > us, or we don't crash, in which case we never leave the SafeFetch function. > In > both cases, we never loose the jump buffer. > > To communicate the jump buffer location to the signal handler, TLS is used. > I > use POSIX tls, because that always works and is not dependend on VM > infrastructure. > > --- > > I built and tested this on Linux x64 zero (Ubuntu 14.4). It works and the > initialization tests for SafeFetch in the stub routine initialization now > work for > zero too. > > Note that I do not have a BSD system right now, so I cannot check whether > this > change builds and works for BSD. But the change only requires POSIX Apis, so > BSD should probably be ok. > > Someone from the zero team should definitly check and test this for other > zero > platforms, but the chances are good that this just works. > > Thanks and Kind Regards, > > Thomas Stuefe > From david.holmes at oracle.com Tue Mar 31 02:01:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Mar 2015 12:01:24 +1000 Subject: RFR: 8073989: Deprecated integer options are now recognized as obsolete. In-Reply-To: <55199108.9030102@oracle.com> References: <55199108.9030102@oracle.com> Message-ID: <5519FFF4.1050507@oracle.com> Hi Max, On 31/03/2015 4:08 AM, Max Ockner wrote: > Hello all, > Please review this change involving the handling of obsolete command > line flags. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073989 > Webrev: http://cr.openjdk.java.net/~mockner/8073989.2/ Argument processing seems to be a never ending source of bugs. > Summary: Three key components to this bug: Thanks for the detailed description! > (1) When is_newly_obsolete() checks for "SomeObsoleteIntegerFlag=100" in > the flag table, it is not recognized as a match with > "SomeObsoleteIntegerFlag" because the lengths are different. This has > been fixed. Arguments:process_argument() now strips everything except > for the arguments name. (example: -XX:+SomeBooleanFlag -> > "SomeBooleanFlag", and -XX:SomeIntegerFlag=100 -> "SomeIntegerFlag") > This stripped argument name (fittingly called stripped_argname) is now > passed into is_newly_obsolete, preventing the length check from failing > on obsolete (but formeerly valid) arguments. It also eliminates the need > for any case work and other string gymnastics from the the body of > is_newly_obsolete. If the argument is found to be newly obsolete, the > warning message now prints stripped_argname instead of argname to avoid > suggesting that "SomeBooleanFlag=100" was ever a supported option. So previously is_newly_obsolete handled +/- but despite the comment didn't really handle the flag=xxx form. So now before calling is_newly_obsolete the leading +/- or trailing = is stripped, so only the base argument name is actually checked. Ok. I think these comments were misplaced originally, and seem more so now: 874 // For locked flags, report a custom error message if available. 875 // Otherwise, report the standard unrecognized VM option. they belong after the is_newly_obsolete calling block, prior to: 883 Flag* found_flag = Flag::find_flag((const char*)argname, arg_len, true, true); 884 if (found_flag != NULL) { > (2) Some flags used to be defined in both the flags table and the > obsolete flags table. Because of this, those obsolete flags which were > also defined in the flags table could be fuzzy matched to provide better > error messages. Now that no flag is allowed to be in both tables, it is > pointless to attempt to fuzzy match an obsolete flag, since fuzzy > matching only looks in the flags table (not the obsolete flags table). > The section at the end of Arguments:process_argument in which fuzzy > matching is attempted on obsolete arguments no longer makes sense and > has been removed. Ok. > (3) ObsoleteFlagErrorMessage.java has been modified. The existing test > for an obsolete flag with appended junk no longer tests for fuzzy > matching, and a second test case has been added for integer valued flags. Ok. The test will need to use a new "newly obsolete" flag in JDK 10. :) Reviewed! Thanks, David > Tested with jtreg runtime tests. > > Thanks, > Max Ockner From thomas.stuefe at gmail.com Tue Mar 31 08:38:03 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 31 Mar 2015 10:38:03 +0200 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: <5519FC3E.2070409@oracle.com> References: <5519FC3E.2070409@oracle.com> Message-ID: Hi David. I am fine with that, thanks! But Severin should give his ok, too. We also should accept that my SafeFetch implementation will be slower than the standard one using inline assembly, because setjmp() does a lot of stores. As far as I can see now, we do not use SafeFetch extensivly anywhere, so this should be ok, but something to keep in mind. So far, I only tested this on Linux x64. Because of the build error after 8074345, I was not able to test a product build of zero, only a slowdebug. I ran a number of JTReg tests with it and got a number of errors, but I got the same errors without my patch, so I assume the errors stem from the slowdebug VM just being too slow. When I have time, I will try to build a BSD zero VM to do more tests. Regards, Thomas On Tue, Mar 31, 2015 at 3:45 AM, David Holmes wrote: > Hi Thomas, > > If you are happy with Severin's review I can add my Review to the shared > part (Zero part looks okay too) and sponsor it. > > David > > > On 28/03/2015 4:00 AM, Thomas St?fe wrote: > >> Hi all, >> >> Please review this change which provides a real SafeFetch implementation >> on zero. >> >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8076185/webrev.01/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8076185 >> >> It works like this: >> >> Before a load is attempted from a potentially unsafe address, we set up a >> jump buffer with sigsetjmp(). In the signal handler, for SIGSEGV and >> SIGBUS, >> we test whether there is a jump buffer set and if yes, take this as an >> indication >> that the crash was an attempted SafeFetch. In this case we jump back via >> longjmp(). >> >> Coding is a bit more difficult because we need to be threadsafe. We keep >> the jump >> buffer on the thread stack - this is ok, because that stack never gets >> unwinded >> - either we crash, in which case signal handler stack frames are built >> up >> below >> us, or we don't crash, in which case we never leave the SafeFetch >> function. >> In >> both cases, we never loose the jump buffer. >> >> To communicate the jump buffer location to the signal handler, TLS is >> used. >> I >> use POSIX tls, because that always works and is not dependend on VM >> infrastructure. >> >> --- >> >> I built and tested this on Linux x64 zero (Ubuntu 14.4). It works and the >> initialization tests for SafeFetch in the stub routine initialization now >> work for >> zero too. >> >> Note that I do not have a BSD system right now, so I cannot check whether >> this >> change builds and works for BSD. But the change only requires POSIX Apis, >> so >> BSD should probably be ok. >> >> Someone from the zero team should definitly check and test this for other >> zero >> platforms, but the chances are good that this just works. >> >> Thanks and Kind Regards, >> >> Thomas Stuefe >> >> From david.holmes at oracle.com Tue Mar 31 08:39:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Mar 2015 18:39:30 +1000 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: References: <5519FC3E.2070409@oracle.com> Message-ID: <551A5D42.6040809@oracle.com> On 31/03/2015 6:38 PM, Thomas St?fe wrote: > Hi David. > > I am fine with that, thanks! > > But Severin should give his ok, too. > > We also should accept that my SafeFetch implementation will be slower > than the standard one using inline assembly, because setjmp() does a lot > of stores. As far as I can see now, we do not use SafeFetch extensivly > anywhere, so this should be ok, but something to keep in mind. > > So far, I only tested this on Linux x64. Because of the build error > after 8074345, I was not able to test a product build of zero, only a > slowdebug. I ran a number of JTReg tests with it and got a number of > errors, but I got the same errors without my patch, so I assume the > errors stem from the slowdebug VM just being too slow. > > When I have time, I will try to build a BSD zero VM to do more tests. Okay - just let me know when you want it pushed. (I have a very long Easter weekend break coming up :) ) Thanks, David > Regards, Thomas > > > > On Tue, Mar 31, 2015 at 3:45 AM, David Holmes > wrote: > > Hi Thomas, > > If you are happy with Severin's review I can add my Review to the > shared part (Zero part looks okay too) and sponsor it. > > David > > > On 28/03/2015 4:00 AM, Thomas St?fe wrote: > > Hi all, > > Please review this change which provides a real SafeFetch > implementation > on zero. > > webrev: > http://cr.openjdk.java.net/~__stuefe/webrevs/8076185/webrev.__01/webrev/ > > bug: https://bugs.openjdk.java.net/__browse/JDK-8076185 > > > It works like this: > > Before a load is attempted from a potentially unsafe address, we > set up a > jump buffer with sigsetjmp(). In the signal handler, for SIGSEGV > and SIGBUS, > we test whether there is a jump buffer set and if yes, take this > as an > indication > that the crash was an attempted SafeFetch. In this case we jump > back via > longjmp(). > > Coding is a bit more difficult because we need to be threadsafe. > We keep > the jump > buffer on the thread stack - this is ok, because that stack > never gets > unwinded > - either we crash, in which case signal handler stack frames > are built up > below > us, or we don't crash, in which case we never leave the > SafeFetch function. > In > both cases, we never loose the jump buffer. > > To communicate the jump buffer location to the signal handler, > TLS is used. > I > use POSIX tls, because that always works and is not dependend on VM > infrastructure. > > --- > > I built and tested this on Linux x64 zero (Ubuntu 14.4). It > works and the > initialization tests for SafeFetch in the stub routine > initialization now > work for > zero too. > > Note that I do not have a BSD system right now, so I cannot > check whether > this > change builds and works for BSD. But the change only requires > POSIX Apis, so > BSD should probably be ok. > > Someone from the zero team should definitly check and test this > for other > zero > platforms, but the chances are good that this just works. > > Thanks and Kind Regards, > > Thomas Stuefe > > From aph at redhat.com Tue Mar 31 08:42:24 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 Mar 2015 09:42:24 +0100 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: References: <5519FC3E.2070409@oracle.com> Message-ID: <551A5DF0.2090109@redhat.com> On 31/03/15 09:38, Thomas St?fe wrote: > We also should accept that my SafeFetch implementation will be slower than > the standard one using inline assembly, because setjmp() does a lot of > stores. As far as I can see now, we do not use SafeFetch extensivly > anywhere, so this should be ok, but something to keep in mind. Sure. On most GNU/Linux targets I know about we can do much better than this POSIXly portable implementation by using a thread-local variable and C++ catch/throw, but (as you say)n there's probably no need. Andrew. From sgehwolf at redhat.com Tue Mar 31 08:52:48 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 31 Mar 2015 10:52:48 +0200 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: References: <5519FC3E.2070409@oracle.com> Message-ID: <1427791968.6988.29.camel@redhat.com> Hi Thomas, On Tue, 2015-03-31 at 10:38 +0200, Thomas St?fe wrote: > Hi David. > > > I am fine with that, thanks! > > > But Severin should give his ok, too. You have my OK. > We also should accept that my SafeFetch implementation will be slower > than the standard one using inline assembly, because setjmp() does a > lot of stores. As far as I can see now, we do not use SafeFetch > extensivly anywhere, so this should be ok, but something to keep in > mind. This is expected. The only use of SafeFetch I'm aware is in src/share/vm/runtime/objectMonitor.cpp and the error handler. Speaking of which: $ java -XX:+UnlockDiagnosticVMOptions -Xmx100M -XX:ErrorHandlerTest=14 -XX:+TestSafeFetchInErrorHandler -version Does not yet work as expected. But that's a separate issue. > So far, I only tested this on Linux x64. Because of the build error > after 8074345, I was not able to test a product build of zero, only a > slowdebug. I ran a number of JTReg tests with it and got a number of > errors, but I got the same errors without my patch, so I assume the > errors stem from the slowdebug VM just being too slow. JDK-8076181 should have fixed this. FWIW, I've built this with your patch and JDK-8076181 using a product build and I've seen no issues. Cheers, Severin > On Tue, Mar 31, 2015 at 3:45 AM, David Holmes > wrote: > Hi Thomas, > > If you are happy with Severin's review I can add my Review to > the shared part (Zero part looks okay too) and sponsor it. > > David > > > On 28/03/2015 4:00 AM, Thomas St?fe wrote: > Hi all, > > Please review this change which provides a real > SafeFetch implementation > on zero. > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8076185/webrev.01/webrev/ > bug: > https://bugs.openjdk.java.net/browse/JDK-8076185 > > It works like this: > > Before a load is attempted from a potentially unsafe > address, we set up a > jump buffer with sigsetjmp(). In the signal handler, > for SIGSEGV and SIGBUS, > we test whether there is a jump buffer set and if yes, > take this as an > indication > that the crash was an attempted SafeFetch. In this > case we jump back via > longjmp(). > > Coding is a bit more difficult because we need to be > threadsafe. We keep > the jump > buffer on the thread stack - this is ok, because that > stack never gets > unwinded > - either we crash, in which case signal handler > stack frames are built up > below > us, or we don't crash, in which case we never leave > the SafeFetch function. > In > both cases, we never loose the jump buffer. > > To communicate the jump buffer location to the signal > handler, TLS is used. > I > use POSIX tls, because that always works and is not > dependend on VM > infrastructure. > > --- > > I built and tested this on Linux x64 zero (Ubuntu > 14.4). It works and the > initialization tests for SafeFetch in the stub routine > initialization now > work for > zero too. > > Note that I do not have a BSD system right now, so I > cannot check whether > this > change builds and works for BSD. But the change only > requires POSIX Apis, so > BSD should probably be ok. > > Someone from the zero team should definitly check and > test this for other > zero > platforms, but the chances are good that this just > works. > > Thanks and Kind Regards, > > Thomas Stuefe > > > From thomas.stuefe at gmail.com Tue Mar 31 09:08:52 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 31 Mar 2015 11:08:52 +0200 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: <1427791968.6988.29.camel@redhat.com> References: <5519FC3E.2070409@oracle.com> <1427791968.6988.29.camel@redhat.com> Message-ID: Hi Severin, David, In that case, lets push the change. On Tue, Mar 31, 2015 at 10:52 AM, Severin Gehwolf wrote: > Hi Thomas, > > On Tue, 2015-03-31 at 10:38 +0200, Thomas St?fe wrote: > > Hi David. > > > > > > I am fine with that, thanks! > > > > > > But Severin should give his ok, too. > > You have my OK. > > > We also should accept that my SafeFetch implementation will be slower > > than the standard one using inline assembly, because setjmp() does a > > lot of stores. As far as I can see now, we do not use SafeFetch > > extensivly anywhere, so this should be ok, but something to keep in > > mind. > > This is expected. The only use of SafeFetch I'm aware is in > src/share/vm/runtime/objectMonitor.cpp and the error handler. Speaking > of which: > > $ java -XX:+UnlockDiagnosticVMOptions -Xmx100M -XX:ErrorHandlerTest=14 > -XX:+TestSafeFetchInErrorHandler -version > > Does not yet work as expected. But that's a separate issue. > > That is ok. For -XX:+TestSafeFetchInErrorHandler to work, we would need to handle SafeFetch faults in the secondary signal handlers too (see vmError_.cpp). That could be easily added but we would leave POSIX territory. Using longjmp() is not guaranteed to work from nested signal handlers ("However, if longjmp() is invoked from a nested signal handler (that is, from a function invoked as a result of a signal raised during the handling of another signal), the behaviour is undefined."). I think that use case is not that important for zero. > > So far, I only tested this on Linux x64. Because of the build error > > after 8074345, I was not able to test a product build of zero, only a > > slowdebug. I ran a number of JTReg tests with it and got a number of > > errors, but I got the same errors without my patch, so I assume the > > errors stem from the slowdebug VM just being too slow. > > JDK-8076181 should have fixed this. FWIW, I've built this with your > patch and JDK-8076181 using a product build and I've seen no issues. > > nice, thanks! ..:Thomas > Cheers, > Severin > > > On Tue, Mar 31, 2015 at 3:45 AM, David Holmes > > wrote: > > Hi Thomas, > > > > If you are happy with Severin's review I can add my Review to > > the shared part (Zero part looks okay too) and sponsor it. > > > > David > > > > > > On 28/03/2015 4:00 AM, Thomas St?fe wrote: > > Hi all, > > > > Please review this change which provides a real > > SafeFetch implementation > > on zero. > > > > webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8076185/webrev.01/webrev/ > > bug: > > https://bugs.openjdk.java.net/browse/JDK-8076185 > > > > It works like this: > > > > Before a load is attempted from a potentially unsafe > > address, we set up a > > jump buffer with sigsetjmp(). In the signal handler, > > for SIGSEGV and SIGBUS, > > we test whether there is a jump buffer set and if yes, > > take this as an > > indication > > that the crash was an attempted SafeFetch. In this > > case we jump back via > > longjmp(). > > > > Coding is a bit more difficult because we need to be > > threadsafe. We keep > > the jump > > buffer on the thread stack - this is ok, because that > > stack never gets > > unwinded > > - either we crash, in which case signal handler > > stack frames are built up > > below > > us, or we don't crash, in which case we never leave > > the SafeFetch function. > > In > > both cases, we never loose the jump buffer. > > > > To communicate the jump buffer location to the signal > > handler, TLS is used. > > I > > use POSIX tls, because that always works and is not > > dependend on VM > > infrastructure. > > > > --- > > > > I built and tested this on Linux x64 zero (Ubuntu > > 14.4). It works and the > > initialization tests for SafeFetch in the stub routine > > initialization now > > work for > > zero too. > > > > Note that I do not have a BSD system right now, so I > > cannot check whether > > this > > change builds and works for BSD. But the change only > > requires POSIX Apis, so > > BSD should probably be ok. > > > > Someone from the zero team should definitly check and > > test this for other > > zero > > platforms, but the chances are good that this just > > works. > > > > Thanks and Kind Regards, > > > > Thomas Stuefe > > > > > > > > > > From david.holmes at oracle.com Tue Mar 31 09:37:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Mar 2015 19:37:24 +1000 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: References: <5519FC3E.2070409@oracle.com> <1427791968.6988.29.camel@redhat.com> Message-ID: <551A6AD4.5040400@oracle.com> On 31/03/2015 7:08 PM, Thomas St?fe wrote: > Hi Severin, David, > > In that case, lets push the change. It is on its way. :) BTW Thomas - you should request jdk9 Author status. Cheers, David > On Tue, Mar 31, 2015 at 10:52 AM, Severin Gehwolf > wrote: > > Hi Thomas, > > On Tue, 2015-03-31 at 10:38 +0200, Thomas St?fe wrote: > > Hi David. > > > > > > I am fine with that, thanks! > > > > > > But Severin should give his ok, too. > > You have my OK. > > > We also should accept that my SafeFetch implementation will be slower > > than the standard one using inline assembly, because setjmp() does a > > lot of stores. As far as I can see now, we do not use SafeFetch > > extensivly anywhere, so this should be ok, but something to keep in > > mind. > > This is expected. The only use of SafeFetch I'm aware is in > src/share/vm/runtime/objectMonitor.cpp and the error handler. Speaking > of which: > > $ java -XX:+UnlockDiagnosticVMOptions -Xmx100M > -XX:ErrorHandlerTest=14 -XX:+TestSafeFetchInErrorHandler -version > > Does not yet work as expected. But that's a separate issue. > > > That is ok. > > For -XX:+TestSafeFetchInErrorHandler to work, we would need to handle > SafeFetch faults in the secondary signal handlers too (see > vmError_.cpp). That could be easily added but we would leave POSIX > territory. Using longjmp() is not guaranteed to work from nested signal > handlers ("However, if longjmp() is invoked from a nested signal handler > (that is, from a function invoked as a result of a signal raised during > the handling of another signal), the behaviour is undefined."). > > I think that use case is not that important for zero. > > > So far, I only tested this on Linux x64. Because of the build error > > after 8074345, I was not able to test a product build of zero, only a > > slowdebug. I ran a number of JTReg tests with it and got a number of > > errors, but I got the same errors without my patch, so I assume the > > errors stem from the slowdebug VM just being too slow. > > JDK-8076181 should have fixed this. FWIW, I've built this with your > patch and JDK-8076181 using a product build and I've seen no issues. > > > nice, thanks! > > ..:Thomas > > Cheers, > Severin > > > On Tue, Mar 31, 2015 at 3:45 AM, David Holmes > > > wrote: > > Hi Thomas, > > > > If you are happy with Severin's review I can add my Review to > > the shared part (Zero part looks okay too) and sponsor it. > > > > David > > > > > > On 28/03/2015 4:00 AM, Thomas St?fe wrote: > > Hi all, > > > > Please review this change which provides a real > > SafeFetch implementation > > on zero. > > > > webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8076185/webrev.01/webrev/ > > bug: > > https://bugs.openjdk.java.net/browse/JDK-8076185 > > > > It works like this: > > > > Before a load is attempted from a potentially unsafe > > address, we set up a > > jump buffer with sigsetjmp(). In the signal handler, > > for SIGSEGV and SIGBUS, > > we test whether there is a jump buffer set and if > yes, > > take this as an > > indication > > that the crash was an attempted SafeFetch. In this > > case we jump back via > > longjmp(). > > > > Coding is a bit more difficult because we need to be > > threadsafe. We keep > > the jump > > buffer on the thread stack - this is ok, because that > > stack never gets > > unwinded > > - either we crash, in which case signal handler > > stack frames are built up > > below > > us, or we don't crash, in which case we never leave > > the SafeFetch function. > > In > > both cases, we never loose the jump buffer. > > > > To communicate the jump buffer location to the signal > > handler, TLS is used. > > I > > use POSIX tls, because that always works and is not > > dependend on VM > > infrastructure. > > > > --- > > > > I built and tested this on Linux x64 zero (Ubuntu > > 14.4). It works and the > > initialization tests for SafeFetch in the stub > routine > > initialization now > > work for > > zero too. > > > > Note that I do not have a BSD system right now, so I > > cannot check whether > > this > > change builds and works for BSD. But the change only > > requires POSIX Apis, so > > BSD should probably be ok. > > > > Someone from the zero team should definitly check and > > test this for other > > zero > > platforms, but the chances are good that this just > > works. > > > > Thanks and Kind Regards, > > > > Thomas Stuefe > > > > > > > > > > From sgehwolf at redhat.com Tue Mar 31 09:45:54 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 31 Mar 2015 11:45:54 +0200 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: References: <5519FC3E.2070409@oracle.com> <1427791968.6988.29.camel@redhat.com> Message-ID: <1427795154.6988.33.camel@redhat.com> Hi, On Tue, 2015-03-31 at 11:08 +0200, Thomas St?fe wrote > > We also should accept that my SafeFetch implementation will > be slower > > than the standard one using inline assembly, because > setjmp() does a > > lot of stores. As far as I can see now, we do not use > SafeFetch > > extensivly anywhere, so this should be ok, but something to > keep in > > mind. > > This is expected. The only use of SafeFetch I'm aware is in > src/share/vm/runtime/objectMonitor.cpp and the error handler. > Speaking > of which: > > $ java -XX:+UnlockDiagnosticVMOptions -Xmx100M > -XX:ErrorHandlerTest=14 -XX:+TestSafeFetchInErrorHandler > -version > > Does not yet work as expected. But that's a separate issue. > > > > That is ok. > > > For -XX:+TestSafeFetchInErrorHandler to work, we would need to handle > SafeFetch faults in the secondary signal handlers too (see > vmError_.cpp). That could be easily added but we would leave POSIX > territory. Using longjmp() is not guaranteed to work from nested > signal handlers ("However, if longjmp() is invoked from a nested > signal handler (that is, from a function invoked as a result of a > signal raised during the handling of another signal), the behaviour is > undefined."). > > > I think that use case is not that important for zero. I agree. Should we make note of this in JDK-8074552? Thanks, Severin From thomas.stuefe at gmail.com Tue Mar 31 11:57:37 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 31 Mar 2015 13:57:37 +0200 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: <1427795154.6988.33.camel@redhat.com> References: <5519FC3E.2070409@oracle.com> <1427791968.6988.29.camel@redhat.com> <1427795154.6988.33.camel@redhat.com> Message-ID: On Tue, Mar 31, 2015 at 11:45 AM, Severin Gehwolf wrote: > Hi, > > On Tue, 2015-03-31 at 11:08 +0200, Thomas St?fe wrote > > > > > We also should accept that my SafeFetch implementation will > > be slower > > > than the standard one using inline assembly, because > > setjmp() does a > > > lot of stores. As far as I can see now, we do not use > > SafeFetch > > > extensivly anywhere, so this should be ok, but something to > > keep in > > > mind. > > > > This is expected. The only use of SafeFetch I'm aware is in > > src/share/vm/runtime/objectMonitor.cpp and the error handler. > > Speaking > > of which: > > > > $ java -XX:+UnlockDiagnosticVMOptions -Xmx100M > > -XX:ErrorHandlerTest=14 -XX:+TestSafeFetchInErrorHandler > > -version > > > > Does not yet work as expected. But that's a separate issue. > > > > > > > > That is ok. > > > > > > For -XX:+TestSafeFetchInErrorHandler to work, we would need to handle > > SafeFetch faults in the secondary signal handlers too (see > > vmError_.cpp). That could be easily added but we would leave POSIX > > territory. Using longjmp() is not guaranteed to work from nested > > signal handlers ("However, if longjmp() is invoked from a nested > > signal handler (that is, from a function invoked as a result of a > > signal raised during the handling of another signal), the behaviour is > > undefined."). > > > > > > I think that use case is not that important for zero. > > I agree. Should we make note of this in JDK-8074552? > > I added a note to JDK-8074552. ..Thomas > Thanks, > Severin > > > From thomas.stuefe at gmail.com Tue Mar 31 11:58:44 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 31 Mar 2015 13:58:44 +0200 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: <551A5DF0.2090109@redhat.com> References: <5519FC3E.2070409@oracle.com> <551A5DF0.2090109@redhat.com> Message-ID: On Tue, Mar 31, 2015 at 10:42 AM, Andrew Haley wrote: > On 31/03/15 09:38, Thomas St?fe wrote: > > We also should accept that my SafeFetch implementation will be slower > than > > the standard one using inline assembly, because setjmp() does a lot of > > stores. As far as I can see now, we do not use SafeFetch extensivly > > anywhere, so this should be ok, but something to keep in mind. > > Sure. On most GNU/Linux targets I know about we can do much better than > this POSIXly portable implementation by using a thread-local variable and > C++ catch/throw, but (as you say)n there's probably no need. > > Interesting, can you catch signals with C++ try/catch? Is that gcc specific? ..Thomas > Andrew. > > From aph at redhat.com Tue Mar 31 13:51:11 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 Mar 2015 14:51:11 +0100 Subject: RFR(s): 8076185: Provide SafeFetchX implementation for zero In-Reply-To: References: <5519FC3E.2070409@oracle.com> <551A5DF0.2090109@redhat.com> Message-ID: <551AA64F.608@redhat.com> On 03/31/2015 12:58 PM, Thomas St?fe wrote: > On Tue, Mar 31, 2015 at 10:42 AM, Andrew Haley wrote: > >> On 31/03/15 09:38, Thomas St?fe wrote: >>> We also should accept that my SafeFetch implementation will be slower >> than >>> the standard one using inline assembly, because setjmp() does a lot of >>> stores. As far as I can see now, we do not use SafeFetch extensivly >>> anywhere, so this should be ok, but something to keep in mind. >> >> Sure. On most GNU/Linux targets I know about we can do much better than >> this POSIXly portable implementation by using a thread-local variable and >> C++ catch/throw, but (as you say)n there's probably no need. >> > Interesting, can you catch signals with C++ try/catch? That's right. > Is that gcc specific? And glibc, and IIRC perhaps the kernel. Andrew. From aph at redhat.com Tue Mar 31 14:33:16 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 Mar 2015 15:33:16 +0100 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <55127C35.8000108@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> <55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com> <55127C35.8000108@redhat.com> Message-ID: <551AB02C.60202@redhat.com> On 03/25/2015 09:13 AM, Andrew Haley wrote: > On 24/03/15 23:40, Vladimir Kozlov wrote: > >> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86: >> >> java.lang.RuntimeException >> at MyByteBuffer.ck(HeapByteBufferTest.java:201) >> at MyByteBuffer.getLong(HeapByteBufferTest.java:211) >> at HeapByteBufferTest.step(HeapByteBufferTest.java:311) >> at HeapByteBufferTest.run(HeapByteBufferTest.java:347) >> at HeapByteBufferTest.main(HeapByteBufferTest.java:362) >> >> Could be intrinsic in C1 does not work correctly? Please, look. > > I certainly will. That is odd: there's no reason I can think of why > this might happen, and I know that the test running on a server build > runs C1 code for a while so it has been tested. I guess it must be a > rare edge case. It's not what I expected, and maybe not what you expected either. My test case fails on 32-bit x86 before any of my patches have been applied. It turns out that the problem is due to the handling of floating-point NaNs on legacy 32-bit x86 systems. The template interpreter uses 80x87 floating point but the compilers use XMM registers. XMM is transparent to all floating-point data: you can load and store any bit pattern and it is not altered. The same is not true of 80x87: if the operand of an operation is a signaling NaN, the default action is to silently convert it to a quiet NaN. This means that interpreted and compiled code will do different things with signaling NaNs. While I'm not sure if this is a specification violation, it certainly is a breach of the Write Once, Run Anywhere principle, albeit a very unimportant one. I've altered the test code so that when generating random bit patterns it never generates a signaling NaN. This makes for a clean run on 32-bit x86 systems. http://cr.openjdk.java.net/~aph/unaligned.jdk.9/ http://cr.openjdk.java.net/~aph/unaligned.hotspot.9/ Andrew. From vladimir.kozlov at oracle.com Tue Mar 31 15:59:37 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 31 Mar 2015 08:59:37 -0700 Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods In-Reply-To: <551AB02C.60202@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> <55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com> <55127C35.8000108@redhat.com> <551AB02C.60202@redhat.com> Message-ID: <551AC469.4090502@oracle.com> Thank you, Andrew I will file a separate bug to address this issue - Interpreter and compiled code should produce the same result! And I will push your changes today. Regards, Vladimir On 3/31/15 7:33 AM, Andrew Haley wrote: > On 03/25/2015 09:13 AM, Andrew Haley wrote: >> On 24/03/15 23:40, Vladimir Kozlov wrote: >> >>> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86: >>> >>> java.lang.RuntimeException >>> at MyByteBuffer.ck(HeapByteBufferTest.java:201) >>> at MyByteBuffer.getLong(HeapByteBufferTest.java:211) >>> at HeapByteBufferTest.step(HeapByteBufferTest.java:311) >>> at HeapByteBufferTest.run(HeapByteBufferTest.java:347) >>> at HeapByteBufferTest.main(HeapByteBufferTest.java:362) >>> >>> Could be intrinsic in C1 does not work correctly? Please, look. >> >> I certainly will. That is odd: there's no reason I can think of why >> this might happen, and I know that the test running on a server build >> runs C1 code for a while so it has been tested. I guess it must be a >> rare edge case. > > It's not what I expected, and maybe not what you expected either. My > test case fails on 32-bit x86 before any of my patches have been > applied. > > It turns out that the problem is due to the handling of floating-point > NaNs on legacy 32-bit x86 systems. The template interpreter uses > 80x87 floating point but the compilers use XMM registers. XMM is > transparent to all floating-point data: you can load and store any bit > pattern and it is not altered. The same is not true of 80x87: if the > operand of an operation is a signaling NaN, the default action is to > silently convert it to a quiet NaN. > > This means that interpreted and compiled code will do different things > with signaling NaNs. While I'm not sure if this is a specification > violation, it certainly is a breach of the Write Once, Run Anywhere > principle, albeit a very unimportant one. > > I've altered the test code so that when generating random bit patterns > it never generates a signaling NaN. This makes for a clean run on > 32-bit x86 systems. > > http://cr.openjdk.java.net/~aph/unaligned.jdk.9/ > http://cr.openjdk.java.net/~aph/unaligned.hotspot.9/ > > Andrew. > From max.ockner at oracle.com Tue Mar 31 18:01:37 2015 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 31 Mar 2015 14:01:37 -0400 Subject: RFR: 8068349: Removed unused fast_iagetfield() function. Message-ID: <551AE101.2070600@oracle.com> Hello all, please review yet another code removal. This is the Open portion of the fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8068349 Webrev: http://cr.openjdk.java.net/~mockner/8068349/ Summary: The function fast_iagetfield() is never used, and has been removed. Tested with jtreg runtime tests. Thanks, Max Ockner From coleen.phillimore at oracle.com Tue Mar 31 18:05:44 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 31 Mar 2015 14:05:44 -0400 Subject: RFR: 8068349: Removed unused fast_iagetfield() function. In-Reply-To: <551AE101.2070600@oracle.com> References: <551AE101.2070600@oracle.com> Message-ID: <551AE1F8.1040504@oracle.com> Looks good! Coleen On 3/31/15, 2:01 PM, Max Ockner wrote: > Hello all, > please review yet another code removal. This is the Open portion of > the fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068349 > Webrev: http://cr.openjdk.java.net/~mockner/8068349/ > > Summary: The function fast_iagetfield() is never used, and has been > removed. > > Tested with jtreg runtime tests. > > Thanks, > Max Ockner > From harold.seigel at oracle.com Tue Mar 31 18:09:49 2015 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 31 Mar 2015 14:09:49 -0400 Subject: RFR: 8068349: Removed unused fast_iagetfield() function. In-Reply-To: <551AE101.2070600@oracle.com> References: <551AE101.2070600@oracle.com> Message-ID: <551AE2ED.6000106@oracle.com> Hi Max, The change looks good. Can you update the copyrights? Thanks, Harold On 3/31/2015 2:01 PM, Max Ockner wrote: > Hello all, > please review yet another code removal. This is the Open portion of > the fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068349 > Webrev: http://cr.openjdk.java.net/~mockner/8068349/ > > Summary: The function fast_iagetfield() is never used, and has been > removed. > > Tested with jtreg runtime tests. > > Thanks, > Max Ockner >