From david.holmes at oracle.com Fri Jul 1 03:22:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Jul 2016 13:22:06 +1000 Subject: RFR(XS): 8160119: Utils.tryFindJvmPid sometimes find incorrect pid In-Reply-To: <57754B8C.5040801@oracle.com> References: <57754B8C.5040801@oracle.com> Message-ID: Hi Boris, On 1/07/2016 2:40 AM, Boris Molodenkov wrote: > Hi All, > > Could you please review fix? > > Utils.tryFindJvmPid incorrectly determines process id from jcmd output > if line which contains desired PID is just after line which ends with > numbers. > Fixed pattern. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160119 > Webrev: http://cr.openjdk.java.net/~bmoloden/8160119/webrev.00 I'm no regex expert but that revised pattern seems good to me - it constrains the pattern to a line at a time, with only starting digits allowed. Can you fix the typo in the comment preceding that line please - follwed. Also copyright year needs updating. No need for updated webrev. Thanks, David > Thanks, > Boris > From goetz.lindenmaier at sap.com Fri Jul 1 11:00:21 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 1 Jul 2016 11:00:21 +0000 Subject: s390x port progress: patch queue for hotspot assembled. Message-ID: Hi Java and s390x fans! I want to report about the progress in the s390x port project. I have been working internally on the port of hotspot. I arranged a preliminary patch queue that adds all required hotspot to build openJdk hotspot from our internal s390x port. As expected, the amount of shared changes required is very low. I need the following 9 changes, annotated with the known T-shirt sizes: L: All the required includes of s390x files in shared files and all places where the string s390x is needed. M: A row of S390_ONLY() macros in shared code, e.g. C1 requires some of them. 6xS: Six 'X' size changes are currently needed that add a new field to a shared datastructure or an argument to a method. XL: The s390x and linux_s390x files. TODOs: - I probably need to do some fixes in hotspot, and adapt some functionality as our internal port is at jdk9 b107. - Get the jdk build working. - Run tests and fix issues. Best regards, Goetz. From boris.molodenkov at oracle.com Fri Jul 1 12:25:25 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Fri, 1 Jul 2016 15:25:25 +0300 Subject: RFR(XS): 8160119: Utils.tryFindJvmPid sometimes find incorrect pid In-Reply-To: References: <57754B8C.5040801@oracle.com> Message-ID: <57766135.9060109@oracle.com> Hi David, Thank you for comment. Copyright was updated. Typo was fixed. I updated webrev because want to have complete webrev for 8u backporting. http://cr.openjdk.java.net/~bmoloden/8160119/webrev.01 Thanks, Boris On 01.07.2016 06:22, David Holmes wrote: > Hi Boris, > > On 1/07/2016 2:40 AM, Boris Molodenkov wrote: >> Hi All, >> >> Could you please review fix? >> >> Utils.tryFindJvmPid incorrectly determines process id from jcmd output >> if line which contains desired PID is just after line which ends with >> numbers. >> Fixed pattern. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8160119 >> Webrev: http://cr.openjdk.java.net/~bmoloden/8160119/webrev.00 > > I'm no regex expert but that revised pattern seems good to me - it > constrains the pattern to a line at a time, with only starting digits > allowed. > > Can you fix the typo in the comment preceding that line please - follwed. > > Also copyright year needs updating. > > No need for updated webrev. > > Thanks, > David > >> Thanks, >> Boris >> From Alan.Burlison at oracle.com Fri Jul 1 13:29:13 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 1 Jul 2016 14:29:13 +0100 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] Message-ID: <57767029.6060800@oracle.com> Summary: Microstate accounting has been always-on on Solaris since Solaris 9, the use of /proc/self/ctl to enable it is redundant and has the side-effect of breaking the use of truss on JVM processes. Microstate accounting code removed and other now-redundant *vtime* methods also removed. Tested with JPRT hostpot testset, all tests passed Webrev: http://cr.openjdk.java.net/~coleenp/JDK-8160350/ Bug link: https://bugs.openjdk.java.net/browse/JDK-8160350 -- Alan Burlison -- From gerald.thornbrugh at oracle.com Fri Jul 1 13:56:14 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 01 Jul 2016 07:56:14 -0600 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <57767029.6060800@oracle.com> References: <57767029.6060800@oracle.com> Message-ID: <5776767E.2050302@oracle.com> Hi Alan, So the only possible negative aspect of this fix is that customers running JDK9 on a Solaris 8 (or older) will not be able to truss unless they enable microstate accounting manually? I am ok with this but it might be nice to add a JDK9 release note about this change. Your changes look good to me. Jerry > Summary: > > Microstate accounting has been always-on on Solaris since Solaris 9, > the use of /proc/self/ctl to enable it is redundant and has the > side-effect of breaking the use of truss on JVM processes. Microstate > accounting code removed and other now-redundant *vtime* methods also > removed. > > Tested with JPRT hostpot testset, all tests passed > > Webrev: http://cr.openjdk.java.net/~coleenp/JDK-8160350/ > Bug link: https://bugs.openjdk.java.net/browse/JDK-8160350 > From yasuenag at gmail.com Fri Jul 1 14:17:24 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 1 Jul 2016 23:17:24 +0900 Subject: Status of building problem with GCC 6 Message-ID: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> Hi all, I want to share task list for building OpenJDK with GCC 6. * jdk: - JDK-8160294: reviewing * hotspot Subtasks of JDK-8160310: - JDK-8160353: reviewing (includes patch for JDK-8156980) - JDK-8160354: reviewing (a part of fix depends on JDK-8156980) - JDK-8160356: waiting to push - JDK-8160357: might be discarded if JDK-8156980 will be resolved. - JDK-8160361: waiting to push - JDK-8160363: might be discarded if JDK-8156980 will be resolved. For HotSpot, I think JDK-8156980 should be fixed at first. I've proposed changes as below: ----------- diff -r ba08710f3b6c make/lib/CompileJvm.gmk --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 @@ -187,6 +187,11 @@ JVM_OPTIMIZATION ?= HIGHEST_JVM +JVM_CXXFLAGS := $(JVM_CFLAGS) +ifeq ($(TOOLCHAIN_TYPE), gcc) + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse +endif + ################################################################################ # Now set up the actual compilation of the main hotspot native library @@ -202,6 +207,7 @@ CFLAGS := $(JVM_CFLAGS), \ CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ + CXXFLAGS := $(JVM_CXXFLAGS), \ vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ empty-body format logical-op-parentheses parentheses \ ----------- I guess GCC 6 (or later) will be provided from several Linux Distros in near future. In fact, Fedora 24 already provides it. I'm sure this work helps many developers who use Linux. Thanks, Yasumasa From Alan.Burlison at oracle.com Fri Jul 1 14:28:58 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 1 Jul 2016 15:28:58 +0100 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <5776767E.2050302@oracle.com> References: <57767029.6060800@oracle.com> <5776767E.2050302@oracle.com> Message-ID: <57767E2A.6080304@oracle.com> On 01/07/2016 14:56, Gerald Thornbrugh wrote: > So the only possible negative aspect of this fix is that customers > running JDK9 on a Solaris 8 (or older) will not be able to truss > unless they enable microstate accounting manually? No, truss does not need microstate accounting enabled in order to work. It is the JVM's attempt to turn on microstate accounting that causes the problem for truss, not whether it's turned on or off in the first place. The promotion of G1 to the default GC in Java9 has caused this issue to become more visible as it is the only thing in the JVM that uses the (to-be-removed) code in question. > I am ok with this but it might be nice to add a JDK9 release note about > this change. AFAIK Java9 won't be supported on Solaris 9 anyway, so I'm not sure there is any benefit in doing that, it's more likely to cause confusion than anything else. > Your changes look good to me. Thanks! -- Alan Burlison -- From gerald.thornbrugh at oracle.com Fri Jul 1 14:29:40 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 01 Jul 2016 08:29:40 -0600 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <57767E2A.6080304@oracle.com> References: <57767029.6060800@oracle.com> <5776767E.2050302@oracle.com> <57767E2A.6080304@oracle.com> Message-ID: <57767E54.40609@oracle.com> Hi Alan, > On 01/07/2016 14:56, Gerald Thornbrugh wrote: > >> So the only possible negative aspect of this fix is that customers >> running JDK9 on a Solaris 8 (or older) will not be able to truss >> unless they enable microstate accounting manually? > > No, truss does not need microstate accounting enabled in order to > work. It is the JVM's attempt to turn on microstate accounting that > causes the problem for truss, not whether it's turned on or off in the > first place. The promotion of G1 to the default GC in Java9 has caused > this issue to become more visible as it is the only thing in the JVM > that uses the (to-be-removed) code in question. Thanks for the clarification. > >> I am ok with this but it might be nice to add a JDK9 release note about >> this change. > > AFAIK Java9 won't be supported on Solaris 9 anyway, so I'm not sure > there is any benefit in doing that, it's more likely to cause > confusion than anything else. OK, I agree. > >> Your changes look good to me. > > Thanks! > Your change looks fine without any additional changes. Jerry From kim.barrett at oracle.com Fri Jul 1 19:13:59 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Jul 2016 15:13:59 -0400 Subject: Status of building problem with GCC 6 In-Reply-To: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> References: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> Message-ID: <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> > On Jul 1, 2016, at 10:17 AM, Yasumasa Suenaga wrote: > For HotSpot, I think JDK-8156980 should be fixed at first. > I've proposed changes as below: > > ----------- > diff -r ba08710f3b6c make/lib/CompileJvm.gmk > --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 > +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 > @@ -187,6 +187,11 @@ > > JVM_OPTIMIZATION ?= HIGHEST_JVM > > +JVM_CXXFLAGS := $(JVM_CFLAGS) > +ifeq ($(TOOLCHAIN_TYPE), gcc) > + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse > +endif > + > ################################################################################ > # Now set up the actual compilation of the main hotspot native library > > @@ -202,6 +207,7 @@ > CFLAGS := $(JVM_CFLAGS), \ > CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > + CXXFLAGS := $(JVM_CXXFLAGS), \ > vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ > DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ > empty-body format logical-op-parentheses parentheses \ > ????? Please keep in mind that my understanding of the new build system is pretty weak. That said, this doesn't look to me like the right way to fix JDK-8156980. There is already code that is supposed to deal with both the -std option and the additional code generation options, which seems to work for some of the packages that we build, but is not affecting the Hotspot build for some reason. Adding a completely separate way to deal with this just for Hotspot seems contrary to the unification effort that was part of the new build system. -fno-lifetime-dse is a relatively recent option, and needs to be conditionalized. And discussion during the review of JDK-8151841 led to the additional code generation options being limited to gcc6+. The existing code mentioned above is conditionalizing that way, except it's just not working for Hotspot. From kim.barrett at oracle.com Fri Jul 1 19:16:17 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Jul 2016 15:16:17 -0400 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 In-Reply-To: <7c5f113d-b5ae-2e49-ee7b-fb9a19227585@gmail.com> References: <7c5f113d-b5ae-2e49-ee7b-fb9a19227585@gmail.com> Message-ID: <7C3A3110-FE75-4C49-BD6D-E9E8423E2A0B@oracle.com> > On Jun 27, 2016, at 11:36 PM, Yasumasa Suenaga wrote: > > Hi Kim, > >> I would prefer that compiler configuration issue got fixed and these kinds of issues be deferred to a future modernization project. > > IMHO, src/os/linux/vm/os_linux.cpp should be fixed at least because elf_class > and endianess is defined as unsigned char. ------------------------------------------------------------------------------ src/os/linux/vm/os_linux.cpp Looks good. ------------------------------------------------------------------------------ src/share/vm/classfile/altHashing.cpp Much as I dislike casts, this change is culturally compatible with the surrounding code. Cleaning that up is a task for another time. Looks good. ------------------------------------------------------------------------------ src/share/vm/opto/type.cpp There seems to be inconsistency about whether these register categories are signed or unsigned. The Node class defines "uint ideal_reg()" and NotAMachineReg is a special value that must be > max. machine register. The Type class has "int ideal_reg()" which deals in the same values. So the proposed casts seem to me to be just papering over a deeper problem. I suggest separating this into a different CR for later cleanup, since it's not an immediate problem once the build problem is fixed. ------------------------------------------------------------------------------ > > In other point, I confirmed that we can avoid -std=gnu++98 as below: Replied in another thread. From kim.barrett at oracle.com Fri Jul 1 19:44:23 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Jul 2016 15:44:23 -0400 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <57767029.6060800@oracle.com> References: <57767029.6060800@oracle.com> Message-ID: > On Jul 1, 2016, at 9:29 AM, Alan Burlison wrote: > > Summary: > > Microstate accounting has been always-on on Solaris since Solaris 9, the use of /proc/self/ctl to enable it is redundant and has the side-effect of breaking the use of truss on JVM processes. Microstate accounting code removed and other now-redundant *vtime* methods also removed. > > Tested with JPRT hostpot testset, all tests passed > > Webrev: http://cr.openjdk.java.net/~coleenp/JDK-8160350/ > Bug link: https://bugs.openjdk.java.net/browse/JDK-8160350 > > -- > Alan Burlison > -- This doesn't look right to me. The BSD implementation of os::elapsedVTime presently just calls elapsedTime, with a comment "better than nothing, but not much". I think it's worse than nothing, and should actually fail, with os::supports_vtime returning false for this platform. Similarly, elapsedVtime on some other platforms falls back to elapsedTime, which I suspect is a mistake. The problem is that the way one deals with vtime is different from the way one deals with elapsedTime values. The predicate is needed so that code that wants to use vtime if available can be properly written to fall back to something else when it's not. (Note that I think there might be bugs in how G1 is attempting to do that in some places.) I have a note to self to look into this and probably report some bugs, but haven't gotten around to doing so. So while we might no longer need os::enable_vtime and os::vtime_enabled, I think getting rid of os::supports_vtime isn't right. OTOH, the present usage of vtime is quite limited. As noted, it's only used by G1, and there I think only for some logging / stats reporting. Maybe we don't really need it at all? I don't have an opinion on that, but other folks in the GC team (at least) might. From philip.race at oracle.com Fri Jul 1 20:17:42 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 01 Jul 2016 13:17:42 -0700 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: <57746B6D.5030405@oracle.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> <57746B6D.5030405@oracle.com> Message-ID: <5776CFE6.4000206@oracle.com> Hi, You have 3 reviewers (2 client, 1 build) so I am OK for this to be pushed. If Kim comes back with some more information the a new fix can be devised .. -phil. On 06/29/2016 05:44 PM, Philip Race wrote: > Hi, > > Not just yet. Whilst I am OK with it ... > > 1) We like 2 (two) reviewers to approve. > 2) I would like Kim to reply to the questions so I understand > his concerns first. > > -phil. > > On 6/29/16, 4:30 PM, Yasumasa Suenaga wrote: >> Hi Kim, Phil, >> >> Can I push this patch? >> It has been reviewed. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/29 2:38, Phil Race wrote: >>> On 06/27/2016 08:50 PM, Yasumasa Suenaga wrote: >>>> Hi Kim, >>>> >>>> The newest changes for jdk repos is [1]. >>>> Erik points we should use DISABLED_WARNINGS_gcc to handle unknown >>>> warning tags. [2] >>>> [1] is implemented with it. >>>> >>>> This change is already reviewed by 2d folks. >>>> So I want to merge it ASAP. >>>> >>>> Do you have any objection? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html >>>> >>>> >>>> On 2016/06/28 8:37, Kim Barrett wrote: >>>>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> This review request relates to [1]. >>>>>> >>>>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>>>> >>>>>> I fixed build error and several issues (VM crash and internal >>>>>> error) as below: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>>>>> >>>>>> Does someone work for it? >>>>>> If no one works for it, I will file it to JBS and will send >>>>>> review request. >>>>>> >>>>>> For jdk repos, I've sent review request [2]. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>>>> >>>>>> [2] >>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>>>> >>>>> Having gone through these, I think all of them are arising due to >>>>> build system problems, where we seem to have lost the compiler >>>>> configuration to use explicit selection of the language standard and >>>>> some additional options. >>> >>> Do tell more about what this means. Where would this previously have >>> been seen ? >>> Different versions of Visual Studio / CLANG / GCC all emit different >>> warnings >>> and it is not always monotonically increasing with compiler version, >>> and I >>> can imagine someone might want to have different sets of flags in >>> general >>> depending on compiler version in use, but I have not seen a pattern >>> of this >>> being applied to the warnings on any of the platforms. >>> >>> in the makefile here there is just one special case of this .. >>> >>> 474 # Suppress gcc warnings like "variable might be clobbered by >>> 'longjmp' >>> 475 # or 'vfork'": this warning indicates that some variable is >>> placed to >>> 476 # a register by optimized compiler and it's value might be lost >>> on longjmp(). >>> 477 # Recommended way to avoid such warning is to declare the >>> variable as >>> 478 # volatile to prevent the optimization. However, this approach >>> does not >>> 479 # work because we have to declare all variables as volatile in >>> result. >>> 480 #ifndef CROSS_COMPILE_ARCH >>> 481 # CC_43_OR_NEWER := \ >>> 482 # $(shell $(EXPR) $(CC_MAJORVER) \> 4 \| \ >>> 483 # \( $(CC_MAJORVER) = 4 \& $(CC_MINORVER) \>= 3 \) ) >>> 484 # ifeq ($(CC_43_OR_NEWER), 1) >>> 485 # BUILD_LIBJAVAJPEG_CFLAGS_linux += -Wno-clobbered >>> 486 # endif >>> 487 #endif >>> >>> >>>>> >>>>> For now I think we should fix the build system problems, and file >>>>> additional bugs or update existing ones as needed to fix the root >>>>> causes of the problems encountered. I think many of the proposed >>>>> changes do not address the root causes, and should not be made. See >>>>> my comments for the specific bugs. >>>>> >>>>> I'm not on the mailing list where the jdk RFR was submitted. I >>>>> took a >>>>> look at them though, and >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> make/lib/Awt2dLibraries.gmk >>>>> 407 # Avoid warning for GCC 6 >>>>> 408 ifeq ($(TOOLCHAIN_TYPE), gcc) >>>>> 409 LCMS_CFLAGS += -Wno-misleading-indentation >>>>> 410 endif >>>>> >>>>> 926 # Avoid warning for GCC 6 >>>>> 927 ifeq ($(TOOLCHAIN_TYPE), gcc) >>>>> 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += >>>>> -Wno-shift-negative-value >>>>> 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += >>>>> -Wno-shift-negative-value >>>>> 930 endif >>>>> >>>>> The -Wmisleading-indentation and -Wshift-negative-value options are >>>>> new in gcc 6. gcc has for some time (starting with gcc 4.4) silently >>>>> ignored unrecognized -Wno-XXX options. But some folks (like SAP) are >>>>> still using older versions. So these will need to be conditionalized >>>>> on the gcc version. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp >>>>> >>>>> 154 if (min < 0) min = 0; >>>>> 155 if (max < min) max = min; /* defensive coding */ >>>>> >>>>> [splitting the line] >>>>> >>>>> Seems like this would be suppressed by -Wno-misleading-indentation, >>>>> especially since the reported warning is for that. Why change both >>>>> the code and the build configuration? >>> >>> Was that something seen in the original fix ? It is not in the >>> version I reviewed. >>> The current version of the fix does not update the makefile to add this >>> .. except for LCMS - which is a different library. >>> >>> >>> -phil. >>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> The changes in AlphaMath.c and splashscreen_jpeg.c look ok. >>>>> >>> From Alan.Burlison at oracle.com Fri Jul 1 20:31:51 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 1 Jul 2016 21:31:51 +0100 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: References: <57767029.6060800@oracle.com> Message-ID: <5776D337.9090203@oracle.com> On 01/07/2016 20:44, Kim Barrett wrote: > This doesn't look right to me. > > The BSD implementation of os::elapsedVTime presently just calls > elapsedTime, with a comment "better than nothing, but not much". I > think it's worse than nothing, and should actually fail, with > os::supports_vtime returning false for this platform. Similarly, > elapsedVtime on some other platforms falls back to elapsedTime, which > I suspect is a mistake. I think os::elapsedVTime() is right on Windows, AIX, Solaris and Linux, and could be made right on OSX as well if the Mach APIs were used, and on FreeBSD it could use getrusage(). I think the problem is the other BSDs, I couldn't find anything suitable to use for those. And I agree the fallback to elapsedTime() also seems suspect as it's only ever done if the vtime mechanism for a given platform fails. If there was ever a transient failure and elapsedVTime() switched between vtime and elapsed time, you'd get some *very* bizarre values. > The problem is that the way one deals with vtime is different from the > way one deals with elapsedTime values. The predicate is needed so > that code that wants to use vtime if available can be properly written > to fall back to something else when it's not. (Note that I think > there might be bugs in how G1 is attempting to do that in some > places.) I agree what's there at present is a bit of a mess, which is why the first version of the patch (attached to the bug) just addressed the Solaris issue that caused truss to fail - that *definitely* needs fixing as it will cause a significant observability issue on Solaris. > I have a note to self to look into this and probably report some bugs, > but haven't gotten around to doing so. > > So while we might no longer need os::enable_vtime and > os::vtime_enabled, I think getting rid of os::supports_vtime isn't > right. Two main options seem feasible: 1. Revert to the V1 patch which just fixes the Solaris issue and leaves everything else alone. 2. Respin the V2 patch and leave os::supports_vtime() in place, and the two calls to it (from g1CollectedHeap.cpp and g1YoungRemSetSamplingThread.cpp). Remove os::enable_vtime() and os::vtime_enabled(). For #2 we could in addition change BSD code so it returns the correct value from os::supports_vtime() (false) but I'm cautious about doing that as it would start using a new codepath that hasn't previously been exercised. Also for #2 we could remove the fallback code, the question being what to replace it with? Returning 0 could potentially cause the generation of negative values elsewhere, if the call to os::elapsedVTime() had previously succeeded. > OTOH, the present usage of vtime is quite limited. As noted, it's > only used by G1, and there I think only for some logging / stats > reporting. Maybe we don't really need it at all? I don't have an > opinion on that, but other folks in the GC team (at least) might. Who should we ask for a GC opinion? I'm leaning towards switching back to the V1 of the patch which just fixes the Solaris issue, and in addition logging another bug which covers the larger cross-platform issues. That seems like the lowest-risk approach whist still fixing a problem on Solaris that *absolutely* needs to be addressed, but I'll welcome any advice. Thanks, -- Alan Burlison -- From daniel.daugherty at oracle.com Fri Jul 1 20:32:30 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Jul 2016 14:32:30 -0600 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <5776D337.9090203@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> Message-ID: <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> > I'm leaning towards switching back to the V1 of the patch which just > fixes the Solaris issue, and in addition logging another bug which > covers the larger cross-platform issues. That seems like the lowest-risk > approach whist still fixing a problem on Solaris that *absolutely* needs > to be addressed, but I'll welcome any advice. Vote: Use JDK-8160350 to fix Solaris and file a new bug for the larger cross-platform issues. Dan On 7/1/16 2:31 PM, Alan Burlison wrote: > On 01/07/2016 20:44, Kim Barrett wrote: > >> This doesn't look right to me. >> >> The BSD implementation of os::elapsedVTime presently just calls >> elapsedTime, with a comment "better than nothing, but not much". I >> think it's worse than nothing, and should actually fail, with >> os::supports_vtime returning false for this platform. Similarly, >> elapsedVtime on some other platforms falls back to elapsedTime, which >> I suspect is a mistake. > > I think os::elapsedVTime() is right on Windows, AIX, Solaris and > Linux, and could be made right on OSX as well if the Mach APIs were > used, and on FreeBSD it could use getrusage(). I think the problem is > the other BSDs, I couldn't find anything suitable to use for those. > > And I agree the fallback to elapsedTime() also seems suspect as it's > only ever done if the vtime mechanism for a given platform fails. If > there was ever a transient failure and elapsedVTime() switched between > vtime and elapsed time, you'd get some *very* bizarre values. > >> The problem is that the way one deals with vtime is different from the >> way one deals with elapsedTime values. The predicate is needed so >> that code that wants to use vtime if available can be properly written >> to fall back to something else when it's not. (Note that I think >> there might be bugs in how G1 is attempting to do that in some >> places.) > > I agree what's there at present is a bit of a mess, which is why the > first version of the patch (attached to the bug) just addressed the > Solaris issue that caused truss to fail - that *definitely* needs > fixing as it will cause a significant observability issue on Solaris. > >> I have a note to self to look into this and probably report some bugs, >> but haven't gotten around to doing so. >> >> So while we might no longer need os::enable_vtime and >> os::vtime_enabled, I think getting rid of os::supports_vtime isn't >> right. > > Two main options seem feasible: > > 1. Revert to the V1 patch which just fixes the Solaris issue and > leaves everything else alone. > > 2. Respin the V2 patch and leave os::supports_vtime() in place, and > the two calls to it (from g1CollectedHeap.cpp and > g1YoungRemSetSamplingThread.cpp). Remove os::enable_vtime() and > os::vtime_enabled(). > > For #2 we could in addition change BSD code so it returns the correct > value from os::supports_vtime() (false) but I'm cautious about doing > that as it would start using a new codepath that hasn't previously > been exercised. > > Also for #2 we could remove the fallback code, the question being what > to replace it with? Returning 0 could potentially cause the generation > of negative values elsewhere, if the call to os::elapsedVTime() had > previously succeeded. > >> OTOH, the present usage of vtime is quite limited. As noted, it's >> only used by G1, and there I think only for some logging / stats >> reporting. Maybe we don't really need it at all? I don't have an >> opinion on that, but other folks in the GC team (at least) might. > > Who should we ask for a GC opinion? > > I'm leaning towards switching back to the V1 of the patch which just > fixes the Solaris issue, and in addition logging another bug which > covers the larger cross-platform issues. That seems like the > lowest-risk approach whist still fixing a problem on Solaris that > *absolutely* needs to be addressed, but I'll welcome any advice. > > Thanks, > From kim.barrett at oracle.com Fri Jul 1 20:35:32 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Jul 2016 16:35:32 -0400 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: <5776CFE6.4000206@oracle.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> <57746B6D.5030405@oracle.com> <5776CFE6.4000206@oracle.com> Message-ID: > On Jul 1, 2016, at 4:17 PM, Phil Race wrote: > > Hi, > > You have 3 reviewers (2 client, 1 build) so I am OK for this to be pushed. > If Kim comes back with some more information the a new fix can be devised .. http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ looks ok to me too. From kim.barrett at oracle.com Fri Jul 1 20:40:41 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Jul 2016 16:40:41 -0400 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> Message-ID: <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> > On Jul 1, 2016, at 4:32 PM, Daniel D. Daugherty wrote: > > > I'm leaning towards switching back to the V1 of the patch which just > > fixes the Solaris issue, and in addition logging another bug which > > covers the larger cross-platform issues. That seems like the lowest-risk > > approach whist still fixing a problem on Solaris that *absolutely* needs > > to be addressed, but I'll welcome any advice. > > Vote: Use JDK-8160350 to fix Solaris and file a new bug for the > larger cross-platform issues. > > Dan That seems like the right approach to me as well. From david.holmes at oracle.com Sat Jul 2 02:23:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 2 Jul 2016 12:23:16 +1000 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: References: <57767029.6060800@oracle.com> Message-ID: On 2/07/2016 5:44 AM, Kim Barrett wrote: >> On Jul 1, 2016, at 9:29 AM, Alan Burlison wrote: >> >> Summary: >> >> Microstate accounting has been always-on on Solaris since Solaris 9, the use of /proc/self/ctl to enable it is redundant and has the side-effect of breaking the use of truss on JVM processes. Microstate accounting code removed and other now-redundant *vtime* methods also removed. >> >> Tested with JPRT hostpot testset, all tests passed >> >> Webrev: http://cr.openjdk.java.net/~coleenp/JDK-8160350/ >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8160350 >> >> -- >> Alan Burlison >> -- > > This doesn't look right to me. > > The BSD implementation of os::elapsedVTime presently just calls > elapsedTime, with a comment "better than nothing, but not much". I > think it's worse than nothing, and should actually fail, with > os::supports_vtime returning false for this platform. Similarly, > elapsedVtime on some other platforms falls back to elapsedTime, which > I suspect is a mistake. As I commented in the pre-review for this our use of elapsedVTime is currently broken because it is not always guarded with a check for VTime being enabled. If we added those checks then BSD/OSX could simply report that VTime is not supported and not enabled. Otherwise we can choose to unconditionally use elapsedVTime and it is simply a "best effort" approximation of thread-execution time. Alan took this latter path. Seems the general opinion now is to perhaps go the other path, or at least look more closely at the issue before deciding. But one has to question what the code using elapsedVTime will do if VTime is not available? If it still has to report something and instead uses elapsedTime() then we may as well go first the path and have elapsedVTime be a best effort attempt which falls back to regular elapsedTime. The main thing is to fix the truss issue on Solaris 11+ asap, so I'm okay with splitting this as described. David ----- > The problem is that the way one deals with vtime is different from the > way one deals with elapsedTime values. The predicate is needed so > that code that wants to use vtime if available can be properly written > to fall back to something else when it's not. (Note that I think > there might be bugs in how G1 is attempting to do that in some > places.) > > I have a note to self to look into this and probably report some bugs, > but haven't gotten around to doing so. > > So while we might no longer need os::enable_vtime and > os::vtime_enabled, I think getting rid of os::supports_vtime isn't > right. > > OTOH, the present usage of vtime is quite limited. As noted, it's > only used by G1, and there I think only for some logging / stats > reporting. Maybe we don't really need it at all? I don't have an > opinion on that, but other folks in the GC team (at least) might. > From aph at redhat.com Sat Jul 2 09:18:30 2016 From: aph at redhat.com (Andrew Haley) Date: Sat, 2 Jul 2016 10:18:30 +0100 Subject: Status of building problem with GCC 6 In-Reply-To: <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> References: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> Message-ID: <577786E6.7090606@redhat.com> On 01/07/16 20:13, Kim Barrett wrote: > -fno-lifetime-dse is a relatively recent option, and needs to be > conditionalized. I think that we don't need -fno-lifetime-dse any more because the bug which needed it was fixed by 8034812. Andrew. From david.holmes at oracle.com Sat Jul 2 11:53:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 2 Jul 2016 21:53:36 +1000 Subject: Status of building problem with GCC 6 In-Reply-To: <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> References: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> Message-ID: <9f772d6d-88a6-55be-5fab-7654f7d8f558@oracle.com> cc'ing build-dev - don't understand why they are not part of this. The build team now owns the hotspot build. Unfortunately Erik J. is now on vacation for a couple of weeks. David On 2/07/2016 5:13 AM, Kim Barrett wrote: >> On Jul 1, 2016, at 10:17 AM, Yasumasa Suenaga wrote: >> For HotSpot, I think JDK-8156980 should be fixed at first. >> I've proposed changes as below: >> >> ----------- >> diff -r ba08710f3b6c make/lib/CompileJvm.gmk >> --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 >> +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 >> @@ -187,6 +187,11 @@ >> >> JVM_OPTIMIZATION ?= HIGHEST_JVM >> >> +JVM_CXXFLAGS := $(JVM_CFLAGS) >> +ifeq ($(TOOLCHAIN_TYPE), gcc) >> + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse >> +endif >> + >> ################################################################################ >> # Now set up the actual compilation of the main hotspot native library >> >> @@ -202,6 +207,7 @@ >> CFLAGS := $(JVM_CFLAGS), \ >> CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >> CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >> + CXXFLAGS := $(JVM_CXXFLAGS), \ >> vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ >> empty-body format logical-op-parentheses parentheses \ >> ????? > > Please keep in mind that my understanding of the new build system is > pretty weak. That said, this doesn't look to me like the right way to > fix JDK-8156980. > > There is already code that is supposed to deal with both the -std > option and the additional code generation options, which seems to work > for some of the packages that we build, but is not affecting the > Hotspot build for some reason. Adding a completely separate way to > deal with this just for Hotspot seems contrary to the unification > effort that was part of the new build system. > > -fno-lifetime-dse is a relatively recent option, and needs to be > conditionalized. And discussion during the review of JDK-8151841 led > to the additional code generation options being limited to gcc6+. > The existing code mentioned above is conditionalizing that way, except > it's just not working for Hotspot. > From yasuenag at gmail.com Sat Jul 2 12:53:32 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 2 Jul 2016 21:53:32 +0900 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 In-Reply-To: <7C3A3110-FE75-4C49-BD6D-E9E8423E2A0B@oracle.com> References: <7c5f113d-b5ae-2e49-ee7b-fb9a19227585@gmail.com> <7C3A3110-FE75-4C49-BD6D-E9E8423E2A0B@oracle.com> Message-ID: <69faa3dd-610a-0106-0d2c-a9b02648f6d3@gmail.com> Hi Kim, > So the proposed casts seem to me to be just papering over a deeper > problem. I suggest separating this into a different CR for later > cleanup, since it's not an immediate problem once the build problem is > fixed. I removed change for type.hpp in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.01/ If JDK-8156980 is resolved, this error will be gone. IMHO, it should be fixed. Thanks, Yasumasa On 2016/07/02 4:16, Kim Barrett wrote: >> On Jun 27, 2016, at 11:36 PM, Yasumasa Suenaga wrote: >> >> Hi Kim, >> >>> I would prefer that compiler configuration issue got fixed and these kinds of issues be deferred to a future modernization project. >> >> IMHO, src/os/linux/vm/os_linux.cpp should be fixed at least because elf_class >> and endianess is defined as unsigned char. > > ------------------------------------------------------------------------------ > src/os/linux/vm/os_linux.cpp > Looks good. > > ------------------------------------------------------------------------------ > src/share/vm/classfile/altHashing.cpp > Much as I dislike casts, this change is culturally compatible with the > surrounding code. Cleaning that up is a task for another time. > > Looks good. > > ------------------------------------------------------------------------------ > src/share/vm/opto/type.cpp > > There seems to be inconsistency about whether these register > categories are signed or unsigned. The Node class defines "uint > ideal_reg()" and NotAMachineReg is a special value that must be > max. > machine register. The Type class has "int ideal_reg()" which deals in > the same values. > > So the proposed casts seem to me to be just papering over a deeper > problem. I suggest separating this into a different CR for later > cleanup, since it's not an immediate problem once the build problem is > fixed. > > ------------------------------------------------------------------------------ > > >> >> In other point, I confirmed that we can avoid -std=gnu++98 as below: > > Replied in another thread. > From yasuenag at gmail.com Sat Jul 2 13:35:22 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 2 Jul 2016 22:35:22 +0900 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> <57746B6D.5030405@oracle.com> <5776CFE6.4000206@oracle.com> Message-ID: <3f9789b3-2370-ac48-1f7a-2d2ab32b039b@gmail.com> Thank you for reviewing! I pushed: http://hg.openjdk.java.net/jdk9/client/jdk/rev/38185af88d22 Yasumasa On 2016/07/02 5:35, Kim Barrett wrote: >> On Jul 1, 2016, at 4:17 PM, Phil Race wrote: >> >> Hi, >> >> You have 3 reviewers (2 client, 1 build) so I am OK for this to be pushed. >> If Kim comes back with some more information the a new fix can be devised .. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ > looks ok to me too. > From kim.barrett at oracle.com Sat Jul 2 15:41:10 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 2 Jul 2016 11:41:10 -0400 Subject: Status of building problem with GCC 6 In-Reply-To: <577786E6.7090606@redhat.com> References: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> <577786E6.7090606@redhat.com> Message-ID: > On Jul 2, 2016, at 5:18 AM, Andrew Haley wrote: > > On 01/07/16 20:13, Kim Barrett wrote: >> -fno-lifetime-dse is a relatively recent option, and needs to be >> conditionalized. > > I think that we don't need -fno-lifetime-dse any more because the > bug which needed it was fixed by 8034812. My understanding was that -fno-lifetime-dse was needed to prevent elimination of code like that in the #ifdef ASSERT block in Node::operator new, e.g. treating storage as an object before the constructor has been called. There was also some non-ASSERT code there that was removed by 8034812. And as I mentioned in 8160742, I?m pretty sure I?ve seen other occurrences of this ?pattern?. From aph at redhat.com Sat Jul 2 15:45:23 2016 From: aph at redhat.com (Andrew Haley) Date: Sat, 2 Jul 2016 16:45:23 +0100 Subject: Status of building problem with GCC 6 In-Reply-To: References: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> <577786E6.7090606@redhat.com> Message-ID: <5777E193.20708@redhat.com> On 02/07/16 16:41, Kim Barrett wrote: >> On Jul 2, 2016, at 5:18 AM, Andrew Haley wrote: >> >> On 01/07/16 20:13, Kim Barrett wrote: >>> -fno-lifetime-dse is a relatively recent option, and needs to be >>> conditionalized. >> >> I think that we don't need -fno-lifetime-dse any more because the >> bug which needed it was fixed by 8034812. > > My understanding was that -fno-lifetime-dse was needed to prevent > elimination of code like that in the #ifdef ASSERT block in > Node::operator new, e.g. treating storage as an object before the > constructor has been called. There was also some non-ASSERT > code there that was removed by 8034812. And as I mentioned in > 8160742, I?m pretty sure I?ve seen other occurrences of this ?pattern?. I see. I thought that it was all gone. Andrew. From kim.barrett at oracle.com Sat Jul 2 16:02:54 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 2 Jul 2016 12:02:54 -0400 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 In-Reply-To: <69faa3dd-610a-0106-0d2c-a9b02648f6d3@gmail.com> References: <7c5f113d-b5ae-2e49-ee7b-fb9a19227585@gmail.com> <7C3A3110-FE75-4C49-BD6D-E9E8423E2A0B@oracle.com> <69faa3dd-610a-0106-0d2c-a9b02648f6d3@gmail.com> Message-ID: <85170BAF-F55C-4475-ADD4-0FD529D38219@oracle.com> > On Jul 2, 2016, at 8:53 AM, Yasumasa Suenaga wrote: > > Hi Kim, > >> So the proposed casts seem to me to be just papering over a deeper >> problem. I suggest separating this into a different CR for later >> cleanup, since it's not an immediate problem once the build problem is >> fixed. > > I removed change for type.hpp in new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.01/ This looks good. I can sponsor, once there?s a second review. > If JDK-8156980 is resolved, this error will be gone. > IMHO, it should be fixed. https://bugs.openjdk.java.net/browse/JDK-8160748 From david.holmes at oracle.com Sun Jul 3 12:16:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 3 Jul 2016 22:16:54 +1000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: Message-ID: Hi Goetz, On 1/07/2016 9:00 PM, Lindenmaier, Goetz wrote: > Hi Java and s390x fans! > > I want to report about the progress in the s390x port project. > > I have been working internally on the port of hotspot. > I arranged a preliminary patch queue that adds all required > hotspot to build openJdk hotspot from our internal s390x port. > As expected, the amount of shared changes required is very low. > > I need the following 9 changes, annotated with the known T-shirt sizes: > > L: All the required includes of s390x files in shared files and all places > where the string s390x is needed. I'd really like us to collectively expend some brain cycles on figuring out how to do away with the explicit platform include lists. The ever expanding list of platforms really bugs me (as it has since it was introduced). Cheers, David > M: A row of S390_ONLY() macros in shared code, e.g. C1 requires some > of them. > 6xS: Six 'X' size changes are currently needed that add a new field to a > shared datastructure or an argument to a method. > > XL: The s390x and linux_s390x files. > > TODOs: > > - I probably need to do some fixes in hotspot, and adapt some functionality > > as our internal port is at jdk9 b107. > > - Get the jdk build working. > > - Run tests and fix issues. > > Best regards, > Goetz. > > From yasuenag at gmail.com Sun Jul 3 14:56:28 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 3 Jul 2016 23:56:28 +0900 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 In-Reply-To: <85170BAF-F55C-4475-ADD4-0FD529D38219@oracle.com> References: <7c5f113d-b5ae-2e49-ee7b-fb9a19227585@gmail.com> <7C3A3110-FE75-4C49-BD6D-E9E8423E2A0B@oracle.com> <69faa3dd-610a-0106-0d2c-a9b02648f6d3@gmail.com> <85170BAF-F55C-4475-ADD4-0FD529D38219@oracle.com> Message-ID: Hi Kim, On 2016/07/03 1:02, Kim Barrett wrote: >> On Jul 2, 2016, at 8:53 AM, Yasumasa Suenaga wrote: >> >> Hi Kim, >> >>> So the proposed casts seem to me to be just papering over a deeper >>> problem. I suggest separating this into a different CR for later >>> cleanup, since it's not an immediate problem once the build problem is >>> fixed. >> >> I removed change for type.hpp in new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.01/ > > This looks good. > > I can sponsor, once there?s a second review. Thanks! I'm waiting a second reviewer. >> If JDK-8156980 is resolved, this error will be gone. >> IMHO, it should be fixed. > > https://bugs.openjdk.java.net/browse/JDK-8160748 Thanks! I've posted a email about this: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-July/023611.html Yasumasa From kim.barrett at oracle.com Sun Jul 3 16:11:33 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 3 Jul 2016 12:11:33 -0400 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 In-Reply-To: References: <7c5f113d-b5ae-2e49-ee7b-fb9a19227585@gmail.com> <7C3A3110-FE75-4C49-BD6D-E9E8423E2A0B@oracle.com> <69faa3dd-610a-0106-0d2c-a9b02648f6d3@gmail.com> <85170BAF-F55C-4475-ADD4-0FD529D38219@oracle.com> Message-ID: <982DFF02-1ADE-42DF-8E82-541B76EB98BE@oracle.com> > On Jul 3, 2016, at 10:56 AM, Yasumasa Suenaga wrote: > > Hi Kim, > > On 2016/07/03 1:02, Kim Barrett wrote: >>> On Jul 2, 2016, at 8:53 AM, Yasumasa Suenaga wrote: >>> >>> Hi Kim, >>> >>>> So the proposed casts seem to me to be just papering over a deeper >>>> problem. I suggest separating this into a different CR for later >>>> cleanup, since it's not an immediate problem once the build problem is >>>> fixed. >>> >>> I removed change for type.hpp in new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.01/ >> >> This looks good. >> >> I can sponsor, once there?s a second review. > > Thanks! > I'm waiting a second reviewer. > > >>> If JDK-8156980 is resolved, this error will be gone. >>> IMHO, it should be fixed. >> >> https://bugs.openjdk.java.net/browse/JDK-8160748 > > Thanks! > I've posted a email about this: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-July/023611.html I?m not going to review that, but I took a very brief look and: --------------- src/share/vm/opto/opcodes.hpp 30 enum Opcodes : uint { This is not valid C++98 code. It is using a C++11 feature. --------------- My intent in separating was to allow JDK-8160748 to be dealt with later, probably not in JDK 9 at all, since the implicit narrowing is not a problem with C++98. From kim.barrett at oracle.com Sun Jul 3 16:36:15 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 3 Jul 2016 12:36:15 -0400 Subject: Status of building problem with GCC 6 In-Reply-To: <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> References: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> Message-ID: <60B65F56-1958-4619-983E-11DD4C94BA61@oracle.com> > On Jul 1, 2016, at 3:13 PM, Kim Barrett wrote: > >> On Jul 1, 2016, at 10:17 AM, Yasumasa Suenaga wrote: >> For HotSpot, I think JDK-8156980 should be fixed at first. >> I've proposed changes as below: >> >> ----------- >> diff -r ba08710f3b6c make/lib/CompileJvm.gmk >> --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 >> +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 >> @@ -187,6 +187,11 @@ >> >> JVM_OPTIMIZATION ?= HIGHEST_JVM >> >> +JVM_CXXFLAGS := $(JVM_CFLAGS) >> +ifeq ($(TOOLCHAIN_TYPE), gcc) >> + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse >> +endif >> + >> ################################################################################ >> # Now set up the actual compilation of the main hotspot native library >> >> @@ -202,6 +207,7 @@ >> CFLAGS := $(JVM_CFLAGS), \ >> CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >> CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >> + CXXFLAGS := $(JVM_CXXFLAGS), \ >> vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ >> empty-body format logical-op-parentheses parentheses \ >> ????? > > Please keep in mind that my understanding of the new build system is > pretty weak. That said, this doesn't look to me like the right way to > fix JDK-8156980. > > There is already code that is supposed to deal with both the -std > option and the additional code generation options, which seems to work > for some of the packages that we build, but is not affecting the > Hotspot build for some reason. Adding a completely separate way to > deal with this just for Hotspot seems contrary to the unification > effort that was part of the new build system. > > -fno-lifetime-dse is a relatively recent option, and needs to be > conditionalized. And discussion during the review of JDK-8151841 led > to the additional code generation options being limited to gcc6+. > The existing code mentioned above is conditionalizing that way, except > it's just not working for Hotspot. I looked into why the additional code generation options aren?t being added, and think I found 3-4 different problems, each of which would interfere with that part. I?m working on a patch, which I hope to send to Yasumasa in next couple of days for a gcc6 test, since I don?t have easy access to that compiler right now. I?ve not (re)explored why -std=gnu++98 isn?t making it to Hotspot builds yet, though what I?ve learned in the process of investigating the code generation options problem has given me a possible lead. From yasuenag at gmail.com Sun Jul 3 23:29:41 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 4 Jul 2016 08:29:41 +0900 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 In-Reply-To: <982DFF02-1ADE-42DF-8E82-541B76EB98BE@oracle.com> References: <7c5f113d-b5ae-2e49-ee7b-fb9a19227585@gmail.com> <7C3A3110-FE75-4C49-BD6D-E9E8423E2A0B@oracle.com> <69faa3dd-610a-0106-0d2c-a9b02648f6d3@gmail.com> <85170BAF-F55C-4475-ADD4-0FD529D38219@oracle.com> <982DFF02-1ADE-42DF-8E82-541B76EB98BE@oracle.com> Message-ID: <4700bdd7-b488-d1e5-abaf-d02f12b9a2cc@gmail.com> Hi Kim, > src/share/vm/opto/opcodes.hpp > 30 enum Opcodes : uint { > > This is not valid C++98 code. It is using a C++11 feature. According to JDK-8160748, the type which is related to Opcodes are inconsistent. To check all of them, I added ": uint" to Opcodes. > My intent in separating was to allow JDK-8160748 to be dealt with later, > probably not in JDK 9 at all, since the implicit narrowing is not a problem > with C++98. Okay, I see. Thanks, Yasumasa On 2016/07/04 1:11, Kim Barrett wrote: >> On Jul 3, 2016, at 10:56 AM, Yasumasa Suenaga wrote: >> >> Hi Kim, >> >> On 2016/07/03 1:02, Kim Barrett wrote: >>>> On Jul 2, 2016, at 8:53 AM, Yasumasa Suenaga wrote: >>>> >>>> Hi Kim, >>>> >>>>> So the proposed casts seem to me to be just papering over a deeper >>>>> problem. I suggest separating this into a different CR for later >>>>> cleanup, since it's not an immediate problem once the build problem is >>>>> fixed. >>>> >>>> I removed change for type.hpp in new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.01/ >>> >>> This looks good. >>> >>> I can sponsor, once there?s a second review. >> >> Thanks! >> I'm waiting a second reviewer. >> >> >>>> If JDK-8156980 is resolved, this error will be gone. >>>> IMHO, it should be fixed. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160748 >> >> Thanks! >> I've posted a email about this: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-July/023611.html > > I?m not going to review that, but I took a very brief look and: > > --------------- > src/share/vm/opto/opcodes.hpp > 30 enum Opcodes : uint { > > This is not valid C++98 code. It is using a C++11 feature. > > --------------- > > My intent in separating was to allow JDK-8160748 to be dealt with later, > probably not in JDK 9 at all, since the implicit narrowing is not a problem > with C++98. > > > From david.holmes at oracle.com Mon Jul 4 01:08:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 11:08:03 +1000 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 In-Reply-To: <69faa3dd-610a-0106-0d2c-a9b02648f6d3@gmail.com> References: <7c5f113d-b5ae-2e49-ee7b-fb9a19227585@gmail.com> <7C3A3110-FE75-4C49-BD6D-E9E8423E2A0B@oracle.com> <69faa3dd-610a-0106-0d2c-a9b02648f6d3@gmail.com> Message-ID: On 2/07/2016 10:53 PM, Yasumasa Suenaga wrote: > Hi Kim, > >> So the proposed casts seem to me to be just papering over a deeper >> problem. I suggest separating this into a different CR for later >> cleanup, since it's not an immediate problem once the build problem is >> fixed. > > I removed change for type.hpp in new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.01/ These changes seem fine to me. Thanks, David > > If JDK-8156980 is resolved, this error will be gone. > IMHO, it should be fixed. > > > Thanks, > > Yasumasa > > > On 2016/07/02 4:16, Kim Barrett wrote: >>> On Jun 27, 2016, at 11:36 PM, Yasumasa Suenaga >>> wrote: >>> >>> Hi Kim, >>> >>>> I would prefer that compiler configuration issue got fixed and these >>>> kinds of issues be deferred to a future modernization project. >>> >>> IMHO, src/os/linux/vm/os_linux.cpp should be fixed at least because >>> elf_class >>> and endianess is defined as unsigned char. >> >> ------------------------------------------------------------------------------ >> >> src/os/linux/vm/os_linux.cpp >> Looks good. >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/classfile/altHashing.cpp >> Much as I dislike casts, this change is culturally compatible with the >> surrounding code. Cleaning that up is a task for another time. >> >> Looks good. >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/opto/type.cpp >> >> There seems to be inconsistency about whether these register >> categories are signed or unsigned. The Node class defines "uint >> ideal_reg()" and NotAMachineReg is a special value that must be > max. >> machine register. The Type class has "int ideal_reg()" which deals in >> the same values. >> >> So the proposed casts seem to me to be just papering over a deeper >> problem. I suggest separating this into a different CR for later >> cleanup, since it's not an immediate problem once the build problem is >> fixed. >> >> ------------------------------------------------------------------------------ >> >> >> >>> >>> In other point, I confirmed that we can avoid -std=gnu++98 as below: >> >> Replied in another thread. >> From david.holmes at oracle.com Mon Jul 4 01:14:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 11:14:50 +1000 Subject: Status of building problem with GCC 6 In-Reply-To: <60B65F56-1958-4619-983E-11DD4C94BA61@oracle.com> References: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> <60B65F56-1958-4619-983E-11DD4C94BA61@oracle.com> Message-ID: Please include the build team on this discussion - cc'd Thanks, David On 4/07/2016 2:36 AM, Kim Barrett wrote: >> On Jul 1, 2016, at 3:13 PM, Kim Barrett wrote: >> >>> On Jul 1, 2016, at 10:17 AM, Yasumasa Suenaga wrote: >>> For HotSpot, I think JDK-8156980 should be fixed at first. >>> I've proposed changes as below: >>> >>> ----------- >>> diff -r ba08710f3b6c make/lib/CompileJvm.gmk >>> --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 >>> +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 >>> @@ -187,6 +187,11 @@ >>> >>> JVM_OPTIMIZATION ?= HIGHEST_JVM >>> >>> +JVM_CXXFLAGS := $(JVM_CFLAGS) >>> +ifeq ($(TOOLCHAIN_TYPE), gcc) >>> + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse >>> +endif >>> + >>> ################################################################################ >>> # Now set up the actual compilation of the main hotspot native library >>> >>> @@ -202,6 +207,7 @@ >>> CFLAGS := $(JVM_CFLAGS), \ >>> CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >>> CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >>> + CXXFLAGS := $(JVM_CXXFLAGS), \ >>> vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >>> DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ >>> empty-body format logical-op-parentheses parentheses \ >>> ????? >> >> Please keep in mind that my understanding of the new build system is >> pretty weak. That said, this doesn't look to me like the right way to >> fix JDK-8156980. >> >> There is already code that is supposed to deal with both the -std >> option and the additional code generation options, which seems to work >> for some of the packages that we build, but is not affecting the >> Hotspot build for some reason. Adding a completely separate way to >> deal with this just for Hotspot seems contrary to the unification >> effort that was part of the new build system. >> >> -fno-lifetime-dse is a relatively recent option, and needs to be >> conditionalized. And discussion during the review of JDK-8151841 led >> to the additional code generation options being limited to gcc6+. >> The existing code mentioned above is conditionalizing that way, except >> it's just not working for Hotspot. > > I looked into why the additional code generation options aren?t being > added, and think I found 3-4 different problems, each of which would > interfere with that part. I?m working on a patch, which I hope to send > to Yasumasa in next couple of days for a gcc6 test, since I don?t have > easy access to that compiler right now. > > I?ve not (re)explored why -std=gnu++98 isn?t making it to Hotspot builds > yet, though what I?ve learned in the process of investigating the code > generation options problem has given me a possible lead. > > From goetz.lindenmaier at sap.com Mon Jul 4 06:41:26 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Jul 2016 06:41:26 +0000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: Message-ID: Hi David, well, to reduce the includes I had cleaned up the includes last year, so that every platform file must be included only once in shared files. But you're right, that's still not really nice. Best regrads, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Sonntag, 3. Juli 2016 14:17 > To: Lindenmaier, Goetz ; s390x-port- > dev at mail.openjdk.java.net; HotSpot Open Source Developers dev at openjdk.java.net> > Subject: Re: s390x port progress: patch queue for hotspot assembled. > > Hi Goetz, > > On 1/07/2016 9:00 PM, Lindenmaier, Goetz wrote: > > Hi Java and s390x fans! > > > > I want to report about the progress in the s390x port project. > > > > I have been working internally on the port of hotspot. > > I arranged a preliminary patch queue that adds all required > > hotspot to build openJdk hotspot from our internal s390x port. > > As expected, the amount of shared changes required is very low. > > > > I need the following 9 changes, annotated with the known T-shirt sizes: > > > > L: All the required includes of s390x files in shared files and all places > > where the string s390x is needed. > > I'd really like us to collectively expend some brain cycles on figuring > out how to do away with the explicit platform include lists. The ever > expanding list of platforms really bugs me (as it has since it was > introduced). > > Cheers, > David > > > > M: A row of S390_ONLY() macros in shared code, e.g. C1 requires some > > of them. > > 6xS: Six 'X' size changes are currently needed that add a new field to a > > shared datastructure or an argument to a method. > > > > XL: The s390x and linux_s390x files. > > > > TODOs: > > > > - I probably need to do some fixes in hotspot, and adapt some > functionality > > > > as our internal port is at jdk9 b107. > > > > - Get the jdk build working. > > > > - Run tests and fix issues. > > > > Best regards, > > Goetz. > > > > From volker.simonis at gmail.com Mon Jul 4 07:10:33 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Jul 2016 09:10:33 +0200 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: Message-ID: On Sun, Jul 3, 2016 at 2:16 PM, David Holmes wrote: > Hi Goetz, > > On 1/07/2016 9:00 PM, Lindenmaier, Goetz wrote: >> >> Hi Java and s390x fans! >> >> I want to report about the progress in the s390x port project. >> >> I have been working internally on the port of hotspot. >> I arranged a preliminary patch queue that adds all required >> hotspot to build openJdk hotspot from our internal s390x port. >> As expected, the amount of shared changes required is very low. >> >> I need the following 9 changes, annotated with the known T-shirt sizes: >> >> L: All the required includes of s390x files in shared files and all places >> where the string s390x is needed. > > > I'd really like us to collectively expend some brain cycles on figuring out > how to do away with the explicit platform include lists. The ever expanding > list of platforms really bugs me (as it has since it was introduced). > An obvious solution to this problem would be to simply remove the os/arch parts from the corresponding filenames (they are encoded in the directory path anyway) and only use the correct include path for every platform while building (I think we already do that). E.g. Rename all instances of "assembler_.hpp" to "assembler_cpu.hpp" (i.e. cpu/x86/vm/assembler_x86.hpp -> cpu/x86/vm/assembler_cpu.hpp) in which case: #ifdef TARGET_ARCH_x86 # include "assembler_x86.hpp" #endif #ifdef TARGET_ARCH_sparc # include "assembler_sparc.hpp" #endif #ifdef TARGET_ARCH_zero # include "assembler_zero.hpp" #endif #ifdef TARGET_ARCH_arm # include "assembler_arm.hpp" #endif #ifdef TARGET_ARCH_ppc # include "assembler_ppc.hpp" #endif #ifdef TARGET_ARCH_aarch64 # include "assembler_aarch64.hpp" #endif could be simply replaced by: # include "assembler_cpu.hpp" The only drawback would be that we may have to create some empty files for some platforms, but in my eyes that's not that bad. The current naming schema is probably a reminiscence of the old includeDB days which only very aged hotspot developers can remember :) > Cheers, > David > > > >> M: A row of S390_ONLY() macros in shared code, e.g. C1 requires some >> of them. >> 6xS: Six 'X' size changes are currently needed that add a new field to a >> shared datastructure or an argument to a method. >> >> XL: The s390x and linux_s390x files. >> >> TODOs: >> >> - I probably need to do some fixes in hotspot, and adapt some >> functionality >> >> as our internal port is at jdk9 b107. >> >> - Get the jdk build working. >> >> - Run tests and fix issues. >> >> Best regards, >> Goetz. >> >> > From david.holmes at oracle.com Mon Jul 4 07:35:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 17:35:14 +1000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: Message-ID: On 4/07/2016 5:10 PM, Volker Simonis wrote: > On Sun, Jul 3, 2016 at 2:16 PM, David Holmes wrote: >> Hi Goetz, >> >> On 1/07/2016 9:00 PM, Lindenmaier, Goetz wrote: >>> >>> Hi Java and s390x fans! >>> >>> I want to report about the progress in the s390x port project. >>> >>> I have been working internally on the port of hotspot. >>> I arranged a preliminary patch queue that adds all required >>> hotspot to build openJdk hotspot from our internal s390x port. >>> As expected, the amount of shared changes required is very low. >>> >>> I need the following 9 changes, annotated with the known T-shirt sizes: >>> >>> L: All the required includes of s390x files in shared files and all places >>> where the string s390x is needed. >> >> >> I'd really like us to collectively expend some brain cycles on figuring out >> how to do away with the explicit platform include lists. The ever expanding >> list of platforms really bugs me (as it has since it was introduced). >> > > An obvious solution to this problem would be to simply remove the > os/arch parts from the corresponding filenames (they are encoded in > the directory path anyway) and only use the correct include path for > every platform while building (I think we already do that). E.g. I'm sure that was proposed originally but rejected for some reason ... Need to do some archaeology :) David ------ > Rename all instances of "assembler_.hpp" to "assembler_cpu.hpp" > (i.e. cpu/x86/vm/assembler_x86.hpp -> cpu/x86/vm/assembler_cpu.hpp) in > which case: > > #ifdef TARGET_ARCH_x86 > # include "assembler_x86.hpp" > #endif > #ifdef TARGET_ARCH_sparc > # include "assembler_sparc.hpp" > #endif > #ifdef TARGET_ARCH_zero > # include "assembler_zero.hpp" > #endif > #ifdef TARGET_ARCH_arm > # include "assembler_arm.hpp" > #endif > #ifdef TARGET_ARCH_ppc > # include "assembler_ppc.hpp" > #endif > #ifdef TARGET_ARCH_aarch64 > # include "assembler_aarch64.hpp" > #endif > > could be simply replaced by: > > # include "assembler_cpu.hpp" > > The only drawback would be that we may have to create some empty files > for some platforms, but in my eyes that's not that bad. > > The current naming schema is probably a reminiscence of the old > includeDB days which only very aged hotspot developers can remember :) > >> Cheers, >> David >> >> >> >>> M: A row of S390_ONLY() macros in shared code, e.g. C1 requires some >>> of them. >>> 6xS: Six 'X' size changes are currently needed that add a new field to a >>> shared datastructure or an argument to a method. >>> >>> XL: The s390x and linux_s390x files. >>> >>> TODOs: >>> >>> - I probably need to do some fixes in hotspot, and adapt some >>> functionality >>> >>> as our internal port is at jdk9 b107. >>> >>> - Get the jdk build working. >>> >>> - Run tests and fix issues. >>> >>> Best regards, >>> Goetz. >>> >>> >> From aph at redhat.com Mon Jul 4 07:48:29 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jul 2016 08:48:29 +0100 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: Message-ID: <577A14CD.8020704@redhat.com> On 04/07/16 08:35, David Holmes wrote: >> An obvious solution to this problem would be to simply remove the >> > os/arch parts from the corresponding filenames (they are encoded in >> > the directory path anyway) and only use the correct include path for >> > every platform while building (I think we already do that). E.g. > I'm sure that was proposed originally but rejected for some reason ... > > Need to do some archaeology :) I would think it better to leave the filenames as they are but add "assembler_cpu.hpp" to the target CPU directory. And then "assembler_cpu.hpp" includes, say, "assembler_aarch64.hpp". That's a much less intrusive change, and doesn't end up confusing any debugging and searching tools. Andrew. From lutz.schmidt at sap.com Mon Jul 4 08:44:20 2016 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 4 Jul 2016 08:44:20 +0000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <577A14CD.8020704@redhat.com> References: <577A14CD.8020704@redhat.com> Message-ID: >From a daily work perspective, I would really like to keep the platform-specific file names. Thus, I am in favor of Andrew?s idea, at least until somebody comes up with an even better Solution. Lutz. P.S.: As I didn?t appear much on the OpenJDK lists so far, here is some very brief background info about me: long-time SAP employee, 10+ years SAPJVM, mainframe exposure 30+ years, office distance to Goetz < 10ft, to Volker < 30ft. On 04.07.16, 09:48, "hotspot-dev on behalf of Andrew Haley" wrote: >On 04/07/16 08:35, David Holmes wrote: >>> An obvious solution to this problem would be to simply remove the >>> > os/arch parts from the corresponding filenames (they are encoded in >>> > the directory path anyway) and only use the correct include path for >>> > every platform while building (I think we already do that). E.g. >> I'm sure that was proposed originally but rejected for some reason ... >> >> Need to do some archaeology :) > >I would think it better to leave the filenames as they are but add >"assembler_cpu.hpp" to the target CPU directory. And then >"assembler_cpu.hpp" includes, say, "assembler_aarch64.hpp". That's a >much less intrusive change, and doesn't end up confusing any debugging >and searching tools. > >Andrew. From david.holmes at oracle.com Mon Jul 4 11:22:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 21:22:46 +1000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <577A14CD.8020704@redhat.com> References: <577A14CD.8020704@redhat.com> Message-ID: On 4/07/2016 5:48 PM, Andrew Haley wrote: > On 04/07/16 08:35, David Holmes wrote: >>> An obvious solution to this problem would be to simply remove the >>>> os/arch parts from the corresponding filenames (they are encoded in >>>> the directory path anyway) and only use the correct include path for >>>> every platform while building (I think we already do that). E.g. >> I'm sure that was proposed originally but rejected for some reason ... >> >> Need to do some archaeology :) > > I would think it better to leave the filenames as they are but add > "assembler_cpu.hpp" to the target CPU directory. And then > "assembler_cpu.hpp" includes, say, "assembler_aarch64.hpp". That's a > much less intrusive change, and doesn't end up confusing any debugging > and searching tools. Unless the files are included into more than one other file then adding a level of indirection doesn't really help anything. ?? I'd love it if the include name could be parameterized somehow but I don't see how that would be possible. But I don't see why the platform part of the name needs to be kept when it is already part of the path? David > Andrew. > From boris.molodenkov at oracle.com Mon Jul 4 11:53:00 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Mon, 4 Jul 2016 14:53:00 +0300 Subject: RFR(XS): 8160119: Utils.tryFindJvmPid sometimes find incorrect pid In-Reply-To: <57766135.9060109@oracle.com> References: <57754B8C.5040801@oracle.com> <57766135.9060109@oracle.com> Message-ID: <577A4E1C.7000403@oracle.com> Please review. Thanks, Boris On 07/01/2016 03:25 PM, Boris Molodenkov wrote: > Hi David, > > Thank you for comment. > Copyright was updated. Typo was fixed. > > I updated webrev because want to have complete webrev for 8u backporting. > http://cr.openjdk.java.net/~bmoloden/8160119/webrev.01 > > Thanks, > Boris > > On 01.07.2016 06:22, David Holmes wrote: >> Hi Boris, >> >> On 1/07/2016 2:40 AM, Boris Molodenkov wrote: >>> Hi All, >>> >>> Could you please review fix? >>> >>> Utils.tryFindJvmPid incorrectly determines process id from jcmd output >>> if line which contains desired PID is just after line which ends with >>> numbers. >>> Fixed pattern. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8160119 >>> Webrev: http://cr.openjdk.java.net/~bmoloden/8160119/webrev.00 >> >> I'm no regex expert but that revised pattern seems good to me - it >> constrains the pattern to a line at a time, with only starting digits >> allowed. >> >> Can you fix the typo in the comment preceding that line please - >> follwed. >> >> Also copyright year needs updating. >> >> No need for updated webrev. >> >> Thanks, >> David >> >>> Thanks, >>> Boris >>> > From aph at redhat.com Mon Jul 4 13:17:21 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jul 2016 14:17:21 +0100 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: <577A14CD.8020704@redhat.com> Message-ID: <577A61E1.3010803@redhat.com> On 04/07/16 12:22, David Holmes wrote: > Unless the files are included into more than one other file then adding > a level of indirection doesn't really help anything. I'm not sure what this means. > But I don't see why the platform part of the name needs to be kept when > it is already part of the path? When switching between files in an editor, one doesn't usually type in the full path, but the filename. I'd be very sad to lose that, and I think that unique filenames are a nice thing to have. Andrew. From volker.simonis at gmail.com Mon Jul 4 14:07:46 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Jul 2016 16:07:46 +0200 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <577A61E1.3010803@redhat.com> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> Message-ID: On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley wrote: > On 04/07/16 12:22, David Holmes wrote: > >> Unless the files are included into more than one other file then adding >> a level of indirection doesn't really help anything. > > I'm not sure what this means. > >> But I don't see why the platform part of the name needs to be kept when >> it is already part of the path? > > When switching between files in an editor, one doesn't usually > type in the full path, but the filename. I'd be very sad to lose > that, and I think that unique filenames are a nice thing to have. > In Emacs you can try the uniquify [1] extension which would solve the problem. I already use it for editing various hotspot version (i.e. hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is probably not a practical solution for everybody :) [1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify.html > Andrew. > We could try something like this (adapted from [2]) although I'm not sure if that's really a good solution (i.e. if it is treated right by various IDEs): include_test.cpp ============ #define xstr(x) #x #define str(x) xstr(x) #define sub(x) x #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) #define os_header(x) str(sub(x)sub(_)OS.hpp) #define os_cpu_header(x) str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) #include cpu_header(assembler) #include os_header(assembler) #include os_cpu_header(assembler) assembler_s390x.hpp ================ #pragma message ("including \"assembler_s390x.h\"") assembler_linux.hpp =============== #pragma message ("including \"assembler_linux.h\"") assembler_linux_s390x.hpp ==================== #pragma message ("including \"assembler_linux_s390x.h\"") It works on all the platforms I have tested so far (see below) except Linux where it needs some tweaks (see comments below): Solaris: ====== /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E include_test.cpp #1 "include_test.cpp" #1 "assembler_s390x.hpp" #pragma message ( "including \"assembler_s390x.h\"" ) #1 "assembler_linux.hpp" #pragma message ( "including \"assembler_linux.h\"" ) #1 "assembler_linux_s390x.hpp" #pragma message ( "including \"assembler_linux_s390x.h\"" ) AIX: === /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c include_test.cpp "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown "pragma message" is specified. "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma message" is specified. "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown "pragma message" is specified. MacOS X ======= /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp In file included from include_test.cpp:8: ./assembler_s390x.hpp:1:9: warning: including "assembler_s390x.h" [-W#pragma-messages] #pragma message ("including \"assembler_s390x.h\"") ^ In file included from include_test.cpp:9: ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" [-W#pragma-messages] #pragma message ("including \"assembler_linux.h\"") ^ In file included from include_test.cpp:10: ./assembler_linux_s390x.hpp:1:9: warning: including "assembler_linux_s390x.h" [-W#pragma-messages] #pragma message ("including \"assembler_linux_s390x.h\"") ^ 3 warnings generated. Windows: ======= $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x -DOS=linux -c include_test. cpp Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. include_test.cpp including "assembler_s390x.h" including "assembler_linux.h" including "assembler_linux_s390x.h" HPUX: ===== $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp Info #4087-D: "including \"assembler_s390x.h\"" Info #4087-D: "including \"assembler_linux.h\"" Info #4087-D: "including \"assembler_linux_s390x.h\"" Linux: ===== g++ -DCPU=s390x -DOS=linux -c include_test.cpp include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or directory compilation terminated. The problem on Linux is that 'linux' is already predefined to '1' but that could be easily fixed for example by slightly changing the name or by adding the underscore to the definiton of the OS macro (i.e. -DOS=_linux). As I said, I'm still not sure if this looks nice? I just wanted to post my findings for discussion :) Regards, Volker [2] http://stackoverflow.com/questions/1852652/how-can-i-include-a-file-whose-name-is-built-up-from-a-macro From aph at redhat.com Mon Jul 4 15:13:06 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jul 2016 16:13:06 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C394A0.2010606@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> Message-ID: <577A7D02.2070300@redhat.com> I'm writing the AArch64 intrinsics for the weak entry points, and the generated code for volatile compare&swap looks wrong to me. I'm seeing this: membar_release cmpxchg membar_acquire ... but this is not enough for volatile. It is enough for AcquireRelease, but for Volatile It needs a trailing membar_volatile to make the store visible to observers in other threads. Looking at LibraryCallKit::inline_unsafe_access, it seems to me that the same code is generated for both Release and Volatile: switch (access_kind) { case Relaxed: case Release: break; // do nothing case Acquire: case Volatile: insert_mem_bar(Op_MemBarVolatile); // !support_IRIW_for_not_multiple_copy_atomic_cpu handled in platform code break; default: ShouldNotReachHere(); } But it really shouldn't be: a volatile store should be followed by MemBarVolatile, like so: switch (access_kind) { case Relaxed: case Release: break; // do nothing case Acquire: insert_mem_bar(Op_MemBarAcquire); break; case Volatile: insert_mem_bar(Op_MemBarVolatile); break; default: ShouldNotReachHere(); } ... and this does indeed generate the correct code. There is a problem, though: this is going to generate suboptimal code for x86: lock cmpxchg lock addl $0x0,-0x40(%rsp) So I suppose we're going to have to kludge around this in the AArch64 back end. Andrew. From aph at redhat.com Mon Jul 4 15:16:42 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jul 2016 16:16:42 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C394A0.2010606@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> Message-ID: <577A7DDA.4000304@redhat.com> [CORRECTED. Please igfnore previous version.] I'm writing the AArch64 intrinsics for the weak entry points, and the generated code for volatile compare&swap looks wrong to me. I'm seeing this: membar_release cmpxchg membar_acquire ... but this is not enough for volatile. It is enough for AcquireRelease, but for Volatile It needs a trailing membar_volatile to make the store visible to observers in other threads. Looking at LibraryCallKit::inline_unsafe_access, it seems to me that the same code is generated for both Release and Volatile: // Add the trailing membar surrounding the access insert_mem_bar(Op_MemBarCPUOrder); switch (access_kind) { case Relaxed: case Release: break; // do nothing case Acquire: case Volatile: insert_mem_bar(Op_MemBarAcquire); // !support_IRIW_for_not_multiple_copy_atomic_cpu handled in platform code break; default: ShouldNotReachHere(); } But it really shouldn't be: a volatile store should be followed by MemBarVolatile, like so: switch (access_kind) { case Relaxed: case Release: break; // do nothing case Acquire: insert_mem_bar(Op_MemBarAcquire); break; case Volatile: insert_mem_bar(Op_MemBarVolatile); break; default: ShouldNotReachHere(); } ... and this does indeed generate the correct code. There is a problem, though: this is going to generate suboptimal code for x86: lock cmpxchg lock addl $0x0,-0x40(%rsp) So I suppose we're going to have to kludge around this in the AArch64 back end. Andrew. From daniel.daugherty at oracle.com Mon Jul 4 15:33:05 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 4 Jul 2016 09:33:05 -0600 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: Message-ID: On 7/4/16 1:10 AM, Volker Simonis wrote: > On Sun, Jul 3, 2016 at 2:16 PM, David Holmes wrote: >> Hi Goetz, >> >> On 1/07/2016 9:00 PM, Lindenmaier, Goetz wrote: >>> Hi Java and s390x fans! >>> >>> I want to report about the progress in the s390x port project. >>> >>> I have been working internally on the port of hotspot. >>> I arranged a preliminary patch queue that adds all required >>> hotspot to build openJdk hotspot from our internal s390x port. >>> As expected, the amount of shared changes required is very low. >>> >>> I need the following 9 changes, annotated with the known T-shirt sizes: >>> >>> L: All the required includes of s390x files in shared files and all places >>> where the string s390x is needed. >> >> I'd really like us to collectively expend some brain cycles on figuring out >> how to do away with the explicit platform include lists. The ever expanding >> list of platforms really bugs me (as it has since it was introduced). >> > An obvious solution to this problem would be to simply remove the > os/arch parts from the corresponding filenames (they are encoded in > the directory path anyway) and only use the correct include path for > every platform while building (I think we already do that). E.g. > > Rename all instances of "assembler_.hpp" to "assembler_cpu.hpp" Don't know if this is still true, but at one point the various IDEs were not happy with multiple files with the same name (ignoring the path that got you there)... Dan > (i.e. cpu/x86/vm/assembler_x86.hpp -> cpu/x86/vm/assembler_cpu.hpp) in > which case: > > #ifdef TARGET_ARCH_x86 > # include "assembler_x86.hpp" > #endif > #ifdef TARGET_ARCH_sparc > # include "assembler_sparc.hpp" > #endif > #ifdef TARGET_ARCH_zero > # include "assembler_zero.hpp" > #endif > #ifdef TARGET_ARCH_arm > # include "assembler_arm.hpp" > #endif > #ifdef TARGET_ARCH_ppc > # include "assembler_ppc.hpp" > #endif > #ifdef TARGET_ARCH_aarch64 > # include "assembler_aarch64.hpp" > #endif > > could be simply replaced by: > > # include "assembler_cpu.hpp" > > The only drawback would be that we may have to create some empty files > for some platforms, but in my eyes that's not that bad. > > The current naming schema is probably a reminiscence of the old > includeDB days which only very aged hotspot developers can remember :) > >> Cheers, >> David >> >> >> >>> M: A row of S390_ONLY() macros in shared code, e.g. C1 requires some >>> of them. >>> 6xS: Six 'X' size changes are currently needed that add a new field to a >>> shared datastructure or an argument to a method. >>> >>> XL: The s390x and linux_s390x files. >>> >>> TODOs: >>> >>> - I probably need to do some fixes in hotspot, and adapt some >>> functionality >>> >>> as our internal port is at jdk9 b107. >>> >>> - Get the jdk build working. >>> >>> - Run tests and fix issues. >>> >>> Best regards, >>> Goetz. >>> >>> From volker.simonis at gmail.com Mon Jul 4 15:58:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Jul 2016 17:58:05 +0200 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: Message-ID: On Mon, Jul 4, 2016 at 5:33 PM, Daniel D. Daugherty wrote: > On 7/4/16 1:10 AM, Volker Simonis wrote: >> >> On Sun, Jul 3, 2016 at 2:16 PM, David Holmes >> wrote: >>> >>> Hi Goetz, >>> >>> On 1/07/2016 9:00 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi Java and s390x fans! >>>> >>>> I want to report about the progress in the s390x port project. >>>> >>>> I have been working internally on the port of hotspot. >>>> I arranged a preliminary patch queue that adds all required >>>> hotspot to build openJdk hotspot from our internal s390x port. >>>> As expected, the amount of shared changes required is very low. >>>> >>>> I need the following 9 changes, annotated with the known T-shirt sizes: >>>> >>>> L: All the required includes of s390x files in shared files and all >>>> places >>>> where the string s390x is needed. >>> >>> >>> I'd really like us to collectively expend some brain cycles on figuring >>> out >>> how to do away with the explicit platform include lists. The ever >>> expanding >>> list of platforms really bugs me (as it has since it was introduced). >>> >> An obvious solution to this problem would be to simply remove the >> os/arch parts from the corresponding filenames (they are encoded in >> the directory path anyway) and only use the correct include path for >> every platform while building (I think we already do that). E.g. >> >> Rename all instances of "assembler_.hpp" to "assembler_cpu.hpp" > > > Don't know if this is still true, but at one point the various > IDEs were not happy with multiple files with the same name > (ignoring the path that got you there)... > At one point various IDEs were not happy with multiple functions with the same name and we definitely have this situation now. This was one of the main reasons why I switched from NetBeans to Eclipse a few years ago (and I don't know if NetBeans has fixed this by now). Users usually have two kind of project setups: 1. You set up a distinct project/configuration for each platform. In such a setup there are no problems with the current file layout and there won't be with the renamed files as every project/configuration will only contain a single instance from every set of files with the same name. From my experience, such a setup works quite well in current versions of Eclipse. 2. You want to set up a project/configuration which contains the sources from all platforms. This is already complicated today because you have to define all the different ARCH and OS variables and you will inevitably get multiple instances of the same classes, methods etc. Code navigation will not be optimal but for example Eclipse will usually offer you a list of possible targets from which you can choose. Such a setup is quite shaky today already and I don't use it often anymore. Getting this right is complicated and I suppose that having different files with the same filenames won't change the situation dramatically to the worse. > Dan > > > >> (i.e. cpu/x86/vm/assembler_x86.hpp -> cpu/x86/vm/assembler_cpu.hpp) in >> which case: >> >> #ifdef TARGET_ARCH_x86 >> # include "assembler_x86.hpp" >> #endif >> #ifdef TARGET_ARCH_sparc >> # include "assembler_sparc.hpp" >> #endif >> #ifdef TARGET_ARCH_zero >> # include "assembler_zero.hpp" >> #endif >> #ifdef TARGET_ARCH_arm >> # include "assembler_arm.hpp" >> #endif >> #ifdef TARGET_ARCH_ppc >> # include "assembler_ppc.hpp" >> #endif >> #ifdef TARGET_ARCH_aarch64 >> # include "assembler_aarch64.hpp" >> #endif >> >> could be simply replaced by: >> >> # include "assembler_cpu.hpp" >> >> The only drawback would be that we may have to create some empty files >> for some platforms, but in my eyes that's not that bad. >> >> The current naming schema is probably a reminiscence of the old >> includeDB days which only very aged hotspot developers can remember :) >> >>> Cheers, >>> David >>> >>> >>> >>>> M: A row of S390_ONLY() macros in shared code, e.g. C1 requires some >>>> of them. >>>> 6xS: Six 'X' size changes are currently needed that add a new field to a >>>> shared datastructure or an argument to a method. >>>> >>>> XL: The s390x and linux_s390x files. >>>> >>>> TODOs: >>>> >>>> - I probably need to do some fixes in hotspot, and adapt some >>>> functionality >>>> >>>> as our internal port is at jdk9 b107. >>>> >>>> - Get the jdk build working. >>>> >>>> - Run tests and fix issues. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> > From david.holmes at oracle.com Mon Jul 4 21:03:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Jul 2016 07:03:56 +1000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> Message-ID: <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> On 5/07/2016 12:07 AM, Volker Simonis wrote: > On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley wrote: >> On 04/07/16 12:22, David Holmes wrote: >> >>> Unless the files are included into more than one other file then adding >>> a level of indirection doesn't really help anything. >> >> I'm not sure what this means. >> >>> But I don't see why the platform part of the name needs to be kept when >>> it is already part of the path? >> >> When switching between files in an editor, one doesn't usually >> type in the full path, but the filename. I'd be very sad to lose >> that, and I think that unique filenames are a nice thing to have. >> > > In Emacs you can try the uniquify [1] extension which would solve the > problem. I already use it for editing various hotspot version (i.e. > hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is probably > not a practical solution for everybody :) > > [1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify.html > >> Andrew. >> > > We could try something like this (adapted from [2]) although I'm not > sure if that's really a good solution (i.e. if it is treated right by > various IDEs): > > include_test.cpp > ============ > > #define xstr(x) #x > #define str(x) xstr(x) > #define sub(x) x > #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) > #define os_header(x) str(sub(x)sub(_)OS.hpp) > #define os_cpu_header(x) str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) > > #include cpu_header(assembler) > #include os_header(assembler) > #include os_cpu_header(assembler) This is the parameterization I thought was not possible. For some reason I thought #define'd values could not be used within #include directives. This looks very workable to me. Thanks, David > assembler_s390x.hpp > ================ > #pragma message ("including \"assembler_s390x.h\"") > > assembler_linux.hpp > =============== > #pragma message ("including \"assembler_linux.h\"") > > assembler_linux_s390x.hpp > ==================== > #pragma message ("including \"assembler_linux_s390x.h\"") > > > It works on all the platforms I have tested so far (see below) except > Linux where it needs some tweaks (see comments below): > > > Solaris: > ====== > /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E include_test.cpp > #1 "include_test.cpp" > #1 "assembler_s390x.hpp" > #pragma message ( "including \"assembler_s390x.h\"" ) > #1 "assembler_linux.hpp" > #pragma message ( "including \"assembler_linux.h\"" ) > #1 "assembler_linux_s390x.hpp" > #pragma message ( "including \"assembler_linux_s390x.h\"" ) > > AIX: > === > /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c include_test.cpp > "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown "pragma > message" is specified. > "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma > message" is specified. > "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown > "pragma message" is specified. > > MacOS X > ======= > /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp > In file included from include_test.cpp:8: > ./assembler_s390x.hpp:1:9: warning: including "assembler_s390x.h" > [-W#pragma-messages] > #pragma message ("including \"assembler_s390x.h\"") > ^ > In file included from include_test.cpp:9: > ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" > [-W#pragma-messages] > #pragma message ("including \"assembler_linux.h\"") > ^ > In file included from include_test.cpp:10: > ./assembler_linux_s390x.hpp:1:9: warning: including > "assembler_linux_s390x.h" [-W#pragma-messages] > #pragma message ("including \"assembler_linux_s390x.h\"") > ^ > 3 warnings generated. > > Windows: > ======= > $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x > -DOS=linux -c include_test. > cpp > Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 > Copyright (C) Microsoft Corporation. All rights reserved. > > include_test.cpp > including "assembler_s390x.h" > including "assembler_linux.h" > including "assembler_linux_s390x.h" > > HPUX: > ===== > $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp > Info #4087-D: "including \"assembler_s390x.h\"" > > Info #4087-D: "including \"assembler_linux.h\"" > > Info #4087-D: "including \"assembler_linux_s390x.h\"" > > Linux: > ===== > g++ -DCPU=s390x -DOS=linux -c include_test.cpp > include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or directory > compilation terminated. > > The problem on Linux is that 'linux' is already predefined to '1' but > that could be easily fixed for example by slightly changing the name > or by adding the underscore to the definiton of the OS macro (i.e. > -DOS=_linux). > > As I said, I'm still not sure if this looks nice? I just wanted to > post my findings for discussion :) > > Regards, > Volker > > [2] http://stackoverflow.com/questions/1852652/how-can-i-include-a-file-whose-name-is-built-up-from-a-macro > From david.holmes at oracle.com Mon Jul 4 21:09:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Jul 2016 07:09:09 +1000 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <577A7DDA.4000304@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <577A7DDA.4000304@redhat.com> Message-ID: On 5/07/2016 1:16 AM, Andrew Haley wrote: > [CORRECTED. Please igfnore previous version.] > > I'm writing the AArch64 intrinsics for the weak entry points, and > the generated code for volatile compare&swap looks wrong to me. > > I'm seeing this: > > membar_release > cmpxchg > membar_acquire > > ... but this is not enough for volatile. It is enough for > AcquireRelease, but for Volatile It needs a trailing membar_volatile > to make the store visible to observers in other threads. Surely cmpxchg already ensures the store (if it happens) is visible in other threads - else the cmpxchg would not even operate correctly. David ----- Looking at > LibraryCallKit::inline_unsafe_access, it seems to me that the same > code is generated for both Release and Volatile: > > // Add the trailing membar surrounding the access > insert_mem_bar(Op_MemBarCPUOrder); > > switch (access_kind) { > case Relaxed: > case Release: > break; // do nothing > case Acquire: > case Volatile: > insert_mem_bar(Op_MemBarAcquire); > // !support_IRIW_for_not_multiple_copy_atomic_cpu handled in platform code > break; > default: > ShouldNotReachHere(); > } > > But it really shouldn't be: a volatile store should be followed by > MemBarVolatile, like so: > > switch (access_kind) { > case Relaxed: > case Release: > break; // do nothing > case Acquire: > insert_mem_bar(Op_MemBarAcquire); > break; > case Volatile: > insert_mem_bar(Op_MemBarVolatile); > break; > default: > ShouldNotReachHere(); > } > > ... and this does indeed generate the correct code. > > There is a problem, though: this is going to generate suboptimal code > for x86: > > lock cmpxchg > lock addl $0x0,-0x40(%rsp) > > So I suppose we're going to have to kludge around this in the AArch64 > back end. > > Andrew. > From stefan.karlsson at oracle.com Mon Jul 4 21:44:29 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 4 Jul 2016 23:44:29 +0200 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> Message-ID: On 2016-07-04 23:03, David Holmes wrote: > On 5/07/2016 12:07 AM, Volker Simonis wrote: >> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley wrote: >>> On 04/07/16 12:22, David Holmes wrote: >>> >>>> Unless the files are included into more than one other file then >>>> adding >>>> a level of indirection doesn't really help anything. >>> >>> I'm not sure what this means. >>> >>>> But I don't see why the platform part of the name needs to be kept >>>> when >>>> it is already part of the path? >>> >>> When switching between files in an editor, one doesn't usually >>> type in the full path, but the filename. I'd be very sad to lose >>> that, and I think that unique filenames are a nice thing to have. >>> >> >> In Emacs you can try the uniquify [1] extension which would solve the >> problem. I already use it for editing various hotspot version (i.e. >> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is probably >> not a practical solution for everybody :) >> >> [1] >> https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify.html >> >>> Andrew. >>> >> >> We could try something like this (adapted from [2]) although I'm not >> sure if that's really a good solution (i.e. if it is treated right by >> various IDEs): >> >> include_test.cpp >> ============ >> >> #define xstr(x) #x >> #define str(x) xstr(x) >> #define sub(x) x >> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) >> #define os_header(x) str(sub(x)sub(_)OS.hpp) >> #define os_cpu_header(x) str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) >> >> #include cpu_header(assembler) >> #include os_header(assembler) >> #include os_cpu_header(assembler) > > This is the parameterization I thought was not possible. For some > reason I thought #define'd values could not be used within #include > directives. FWIW, we tried a similar approach when includeDB was removed, but abandoned it because of the problem described below with the 'linux' define. StefanK > > This looks very workable to me. > > Thanks, > David > >> assembler_s390x.hpp >> ================ >> #pragma message ("including \"assembler_s390x.h\"") >> >> assembler_linux.hpp >> =============== >> #pragma message ("including \"assembler_linux.h\"") >> >> assembler_linux_s390x.hpp >> ==================== >> #pragma message ("including \"assembler_linux_s390x.h\"") >> >> >> It works on all the platforms I have tested so far (see below) except >> Linux where it needs some tweaks (see comments below): >> >> >> Solaris: >> ====== >> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E include_test.cpp >> #1 "include_test.cpp" >> #1 "assembler_s390x.hpp" >> #pragma message ( "including \"assembler_s390x.h\"" ) >> #1 "assembler_linux.hpp" >> #pragma message ( "including \"assembler_linux.h\"" ) >> #1 "assembler_linux_s390x.hpp" >> #pragma message ( "including \"assembler_linux_s390x.h\"" ) >> >> AIX: >> === >> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c >> include_test.cpp >> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >> message" is specified. >> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >> message" is specified. >> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >> "pragma message" is specified. >> >> MacOS X >> ======= >> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp >> In file included from include_test.cpp:8: >> ./assembler_s390x.hpp:1:9: warning: including "assembler_s390x.h" >> [-W#pragma-messages] >> #pragma message ("including \"assembler_s390x.h\"") >> ^ >> In file included from include_test.cpp:9: >> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" >> [-W#pragma-messages] >> #pragma message ("including \"assembler_linux.h\"") >> ^ >> In file included from include_test.cpp:10: >> ./assembler_linux_s390x.hpp:1:9: warning: including >> "assembler_linux_s390x.h" [-W#pragma-messages] >> #pragma message ("including \"assembler_linux_s390x.h\"") >> ^ >> 3 warnings generated. >> >> Windows: >> ======= >> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x >> -DOS=linux -c include_test. >> cpp >> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> include_test.cpp >> including "assembler_s390x.h" >> including "assembler_linux.h" >> including "assembler_linux_s390x.h" >> >> HPUX: >> ===== >> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp >> Info #4087-D: "including \"assembler_s390x.h\"" >> >> Info #4087-D: "including \"assembler_linux.h\"" >> >> Info #4087-D: "including \"assembler_linux_s390x.h\"" >> >> Linux: >> ===== >> g++ -DCPU=s390x -DOS=linux -c include_test.cpp >> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or >> directory >> compilation terminated. >> >> The problem on Linux is that 'linux' is already predefined to '1' but >> that could be easily fixed for example by slightly changing the name >> or by adding the underscore to the definiton of the OS macro (i.e. >> -DOS=_linux). >> >> As I said, I'm still not sure if this looks nice? I just wanted to >> post my findings for discussion :) >> >> Regards, >> Volker >> >> [2] >> http://stackoverflow.com/questions/1852652/how-can-i-include-a-file-whose-name-is-built-up-from-a-macro >> From david.holmes at oracle.com Mon Jul 4 21:59:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Jul 2016 07:59:12 +1000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> Message-ID: On 5/07/2016 7:44 AM, Stefan Karlsson wrote: > On 2016-07-04 23:03, David Holmes wrote: >> On 5/07/2016 12:07 AM, Volker Simonis wrote: >>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley wrote: >>>> On 04/07/16 12:22, David Holmes wrote: >>>> >>>>> Unless the files are included into more than one other file then >>>>> adding >>>>> a level of indirection doesn't really help anything. >>>> >>>> I'm not sure what this means. >>>> >>>>> But I don't see why the platform part of the name needs to be kept >>>>> when >>>>> it is already part of the path? >>>> >>>> When switching between files in an editor, one doesn't usually >>>> type in the full path, but the filename. I'd be very sad to lose >>>> that, and I think that unique filenames are a nice thing to have. >>>> >>> >>> In Emacs you can try the uniquify [1] extension which would solve the >>> problem. I already use it for editing various hotspot version (i.e. >>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is probably >>> not a practical solution for everybody :) >>> >>> [1] >>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify.html >>> >>>> Andrew. >>>> >>> >>> We could try something like this (adapted from [2]) although I'm not >>> sure if that's really a good solution (i.e. if it is treated right by >>> various IDEs): >>> >>> include_test.cpp >>> ============ >>> >>> #define xstr(x) #x >>> #define str(x) xstr(x) >>> #define sub(x) x >>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) >>> #define os_header(x) str(sub(x)sub(_)OS.hpp) >>> #define os_cpu_header(x) str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) >>> >>> #include cpu_header(assembler) >>> #include os_header(assembler) >>> #include os_cpu_header(assembler) >> >> This is the parameterization I thought was not possible. For some >> reason I thought #define'd values could not be used within #include >> directives. > > FWIW, we tried a similar approach when includeDB was removed, but > abandoned it because of the problem described below with the 'linux' > define. Give we have in the build (eg for linux x86) presently: -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_MODEL_x86_32 -DTARGET_ARCH_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_32 -DTARGET_OS_ARCH_linux_x86 I wonder if we can simply replace the above with: -DTARGET_OS_FAMILY=linux -DTARGET_ARCH_MODEL=x86_32 -DTARGET_ARCH=x86 -DTARGET_OS_ARCH_MODEL=linux_x86_32 -DTARGET_OS_ARCH=linux_x86 and use those variables for the include directives? David > StefanK > >> >> This looks very workable to me. >> >> Thanks, >> David >> >>> assembler_s390x.hpp >>> ================ >>> #pragma message ("including \"assembler_s390x.h\"") >>> >>> assembler_linux.hpp >>> =============== >>> #pragma message ("including \"assembler_linux.h\"") >>> >>> assembler_linux_s390x.hpp >>> ==================== >>> #pragma message ("including \"assembler_linux_s390x.h\"") >>> >>> >>> It works on all the platforms I have tested so far (see below) except >>> Linux where it needs some tweaks (see comments below): >>> >>> >>> Solaris: >>> ====== >>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E include_test.cpp >>> #1 "include_test.cpp" >>> #1 "assembler_s390x.hpp" >>> #pragma message ( "including \"assembler_s390x.h\"" ) >>> #1 "assembler_linux.hpp" >>> #pragma message ( "including \"assembler_linux.h\"" ) >>> #1 "assembler_linux_s390x.hpp" >>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) >>> >>> AIX: >>> === >>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c >>> include_test.cpp >>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>> message" is specified. >>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>> message" is specified. >>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >>> "pragma message" is specified. >>> >>> MacOS X >>> ======= >>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp >>> In file included from include_test.cpp:8: >>> ./assembler_s390x.hpp:1:9: warning: including "assembler_s390x.h" >>> [-W#pragma-messages] >>> #pragma message ("including \"assembler_s390x.h\"") >>> ^ >>> In file included from include_test.cpp:9: >>> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" >>> [-W#pragma-messages] >>> #pragma message ("including \"assembler_linux.h\"") >>> ^ >>> In file included from include_test.cpp:10: >>> ./assembler_linux_s390x.hpp:1:9: warning: including >>> "assembler_linux_s390x.h" [-W#pragma-messages] >>> #pragma message ("including \"assembler_linux_s390x.h\"") >>> ^ >>> 3 warnings generated. >>> >>> Windows: >>> ======= >>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x >>> -DOS=linux -c include_test. >>> cpp >>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 >>> Copyright (C) Microsoft Corporation. All rights reserved. >>> >>> include_test.cpp >>> including "assembler_s390x.h" >>> including "assembler_linux.h" >>> including "assembler_linux_s390x.h" >>> >>> HPUX: >>> ===== >>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp >>> Info #4087-D: "including \"assembler_s390x.h\"" >>> >>> Info #4087-D: "including \"assembler_linux.h\"" >>> >>> Info #4087-D: "including \"assembler_linux_s390x.h\"" >>> >>> Linux: >>> ===== >>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp >>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or >>> directory >>> compilation terminated. >>> >>> The problem on Linux is that 'linux' is already predefined to '1' but >>> that could be easily fixed for example by slightly changing the name >>> or by adding the underscore to the definiton of the OS macro (i.e. >>> -DOS=_linux). >>> >>> As I said, I'm still not sure if this looks nice? I just wanted to >>> post my findings for discussion :) >>> >>> Regards, >>> Volker >>> >>> [2] >>> http://stackoverflow.com/questions/1852652/how-can-i-include-a-file-whose-name-is-built-up-from-a-macro >>> >>> > From gnu.andrew at redhat.com Tue Jul 5 05:27:21 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jul 2016 01:27:21 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1992594910.2166672.1467695195527.JavaMail.zimbra@redhat.com> Message-ID: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> Webrev: http://cr.openjdk.java.net/~andrew/8156980/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8156980 With "8151841: Build needs additional flags to compile with GCC 6", we added a number of compiler flags which were needed to build OpenJDK with GCC 6. Checks for these flags were added to configure, and the flags passed to the JDK and HotSpot builds by CFLAGS/CXXFLAGS_JDK and hotspot-spec.gmk.in respectively. Following "8152666: The new Hotspot Build System" and "8150601: Remove the old Hotspot build system", the hotspot-spec.gmk.in file was removed, so the flags were no longer passed to the HotSpot build. HotSpot now uses JVM_CFLAGS via the same configure process as the JDK obtains CFLAGS_JDK and CXXFLAGS_JDK[*]. This webrev fixes the regression introduced by 8152666 by adding the flags to JVM_CFLAGS. It also adapts FLAGS_SETUP_GCC6_COMPILER_FLAGS to take a prefix, as other macros in flags.m4 do, and calls TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS before the version check. The lack of the latter lead to configure executing: if test $OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION -ge $COMPARABLE_REFERENCE_VERSION with OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION ever being set, causing test to print an error. With this fix, the flags again make it into the build. [*] It should really be CXXFLAGS_JVM as they are flags for the C++ compiler. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From erik.joelsson at oracle.com Tue Jul 5 06:58:40 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Jul 2016 08:58:40 +0200 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> Message-ID: <577B5AA0.8050207@oracle.com> Hello, In general it looks good. It's nice to see that this also fixes that warning output from configure. My only nit is the comment describing the parameters for FLAGS_SETUP_GCC6_COMPILER_FLAGS. It indicates that it takes named parameters while it actually just takes positional. Please either change it to named parameters or fix the comment. Thanks for fixing this! /Erik On 2016-07-05 07:27, Andrew Hughes wrote: > Webrev: http://cr.openjdk.java.net/~andrew/8156980/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8156980 > > With "8151841: Build needs additional flags to compile with GCC 6", > we added a number of compiler flags which were needed to build > OpenJDK with GCC 6. Checks for these flags were added to configure, > and the flags passed to the JDK and HotSpot builds by CFLAGS/CXXFLAGS_JDK > and hotspot-spec.gmk.in respectively. > > Following "8152666: The new Hotspot Build System" and > "8150601: Remove the old Hotspot build system", the hotspot-spec.gmk.in > file was removed, so the flags were no longer passed to the HotSpot > build. HotSpot now uses JVM_CFLAGS via the same configure process > as the JDK obtains CFLAGS_JDK and CXXFLAGS_JDK[*]. > > This webrev fixes the regression introduced by 8152666 by adding > the flags to JVM_CFLAGS. It also adapts FLAGS_SETUP_GCC6_COMPILER_FLAGS > to take a prefix, as other macros in flags.m4 do, and calls > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS before the version check. > The lack of the latter lead to configure executing: > > if test $OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION -ge $COMPARABLE_REFERENCE_VERSION > > with OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION ever being set, causing > test to print an error. > > With this fix, the flags again make it into the build. > > [*] It should really be CXXFLAGS_JVM as they are flags for the C++ compiler. From adinn at redhat.com Tue Jul 5 07:55:37 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 5 Jul 2016 08:55:37 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <577A7DDA.4000304@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <577A7DDA.4000304@redhat.com> Message-ID: <577B67F9.7080900@redhat.com> On 04/07/16 16:16, Andrew Haley wrote: > [CORRECTED. Please igfnore previous version.] > > I'm writing the AArch64 intrinsics for the weak entry points, and > the generated code for volatile compare&swap looks wrong to me. > > I'm seeing this: > > membar_release > cmpxchg > membar_acquire > > ... but this is not enough for volatile. It is enough for > AcquireRelease, but for Volatile It needs a trailing membar_volatile > to make the store visible to observers in other threads. Looking at > LibraryCallKit::inline_unsafe_access, it seems to me that the same > code is generated for both Release and Volatile: > > // Add the trailing membar surrounding the access > insert_mem_bar(Op_MemBarCPUOrder); > > switch (access_kind) { > case Relaxed: > case Release: > break; // do nothing > case Acquire: > case Volatile: > insert_mem_bar(Op_MemBarAcquire); > // !support_IRIW_for_not_multiple_copy_atomic_cpu handled in platform code > break; > default: > ShouldNotReachHere(); > } > > But it really shouldn't be: a volatile store should be followed by > MemBarVolatile, like so: > > switch (access_kind) { > case Relaxed: > case Release: > break; // do nothing > case Acquire: > insert_mem_bar(Op_MemBarAcquire); > break; > case Volatile: > insert_mem_bar(Op_MemBarVolatile); > break; > default: > ShouldNotReachHere(); > } > > ... and this does indeed generate the correct code. Hmm, logically I think you are correct that in terms of what the barrier nodes are /meant/ to represent there should be a MemBarVolatile in the sequence. However, the code Alexei wrote was written to follow the existing pattern of usage which was established to avoid the double use of a locked instruction that would result on x86. So, when we have a CompareAndSwapX operation the AArch64 back end has always expected to see MembarRelease ConpareAndSwapX MembarAcquire well, that or the variant MembarRelease MembarCPUOrder ConpareAndSwapX MembarCPUOrder MembarAcquire Originally AArch64 handled the need to order stores /following/ the exchange store by naively translating the above to dmb (LoadStore|StoreStore) ... ldrx ... stlrx .. dmb (LoadLoad|LoadStore) Of course with that translation the initial store barrier is redundant. So, we then added optimising rules which spot this pattern and improve the generated code. They inhibit the translation of the MembarRelease/Acquire and plant a ldarx stlrx pair ... ldarx ... stlrx .. which does all we need. If you are not seeing an stlrx then we have a problem. Is that the case? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Tue Jul 5 09:09:22 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jul 2016 10:09:22 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <577A7DDA.4000304@redhat.com> Message-ID: <577B7942.5090801@redhat.com> On 04/07/16 22:09, David Holmes wrote: > Surely cmpxchg already ensures the store (if it happens) is visible in > other threads - else the cmpxchg would not even operate correctly. No, it doesn't. Semantically, the cmpxchg is no more than an atomic operation on a single word: it has no other memory ordering effects. If you want the store to be observed before some other memory access you have to do something to make that happen. Andrew. From aph at redhat.com Tue Jul 5 09:17:01 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jul 2016 10:17:01 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <577B67F9.7080900@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <577A7DDA.4000304@redhat.com> <577B67F9.7080900@redhat.com> Message-ID: <577B7B0D.3080505@redhat.com> On 05/07/16 08:55, Andrew Dinn wrote: > Hmm, logically I think you are correct that in terms of what the > barrier nodes are /meant/ to represent there should be a > MemBarVolatile in the sequence. Yeah, exactly. I am of the (rather quaint?) opinion that the IR should be an accurate representation of what we want to happen. > However, the code Alexei wrote was written to follow the existing > pattern of usage which was established to avoid the double use of a > locked instruction that would result on x86. OK, right. > Originally AArch64 handled the need to order stores /following/ the > exchange store by naively translating the above to > > dmb (LoadStore|StoreStore) > ... > ldrx > ... > stlrx > .. > dmb (LoadLoad|LoadStore) Right, I can do that, then. That seems like a solution for now. > So, we then added optimising rules which spot this pattern and improve > the generated code. They inhibit the translation of the > MembarRelease/Acquire and plant a ldarx stlrx pair > > > ... > ldarx > ... > stlrx > .. > > which does all we need. If you are not seeing an stlrx then we have a > problem. Is that the case? Yes, because the rewrite rules don't know about the new CAS nodes which I'm defining. Besides that, the AArch64 back end is supposed to work correctly even when using +UseBarriersForVolatile. Andrew. From adinn at redhat.com Tue Jul 5 09:47:52 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 5 Jul 2016 10:47:52 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <577B7B0D.3080505@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <577A7DDA.4000304@redhat.com> <577B67F9.7080900@redhat.com> <577B7B0D.3080505@redhat.com> Message-ID: <577B8248.5090009@redhat.com> On 05/07/16 10:17, Andrew Haley wrote: > On 05/07/16 08:55, Andrew Dinn wrote: > . . . >> So, we then added optimising rules which spot this pattern and improve >> the generated code. They inhibit the translation of the >> MembarRelease/Acquire and plant a ldarx stlrx pair >> >> >> ... >> ldarx >> ... >> stlrx >> .. >> >> which does all we need. If you are not seeing an stlrx then we have a >> problem. Is that the case? > > Yes, because the rewrite rules don't know about the new CAS nodes > which I'm defining. Besides that, the AArch64 back end is supposed to > work correctly even when using +UseBarriersForVolatile. The intention was always to update the rewrite predicates so that they do recognise these new configurations. I think we ought to do that so we can profit form the weaker memory model semantics. Whatever we do the current predicates ought at least to be corrected so that they consistently omit barriers and plant ldaxr+stlxr or plant barriers and rely on ldxr+stlxr. If the current predicates implement some half-way house for the new nodes that has the wrong semantics then they are borked. I don't see why the +UseBarriersForVolatile option presents a problem. If the Release barrier is omitted then that means we don't generate a Release before the cmpxchg because the caller is supposed to have taken care of that. However, we still use stlxr in the exchange to ensure that the swap is ordered wrt later writes. Ditto, if the Acquire barrier is omitted that's also because the caller is supposed to take care of that. So, our use of ldxr when we have +UseBarriersForVolatile ought to be fine. What are you seeing with +UseBarriersForVolatile that is problematic? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From david.holmes at oracle.com Tue Jul 5 12:17:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Jul 2016 22:17:17 +1000 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <577B7942.5090801@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <577A7DDA.4000304@redhat.com> <577B7942.5090801@redhat.com> Message-ID: On 5/07/2016 7:09 PM, Andrew Haley wrote: > On 04/07/16 22:09, David Holmes wrote: >> Surely cmpxchg already ensures the store (if it happens) is visible in >> other threads - else the cmpxchg would not even operate correctly. > > No, it doesn't. Semantically, the cmpxchg is no more than an atomic > operation on a single word: it has no other memory ordering effects. > If you want the store to be observed before some other memory access > you have to do something to make that happen. You seem to be confusing ordering with visibility. The cmpxchg must be visible to other threads else cmpxchg can't function. But that doesn't imply any ordering constraints with anything before/after the cmpxchg. Cheers, David > Andrew. > From aph at redhat.com Tue Jul 5 12:46:58 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jul 2016 13:46:58 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <577A7DDA.4000304@redhat.com> <577B7942.5090801@redhat.com> Message-ID: <577BAC42.80708@redhat.com> On 05/07/16 13:17, David Holmes wrote: > On 5/07/2016 7:09 PM, Andrew Haley wrote: >> On 04/07/16 22:09, David Holmes wrote: >>> Surely cmpxchg already ensures the store (if it happens) is visible in >>> other threads - else the cmpxchg would not even operate correctly. >> >> No, it doesn't. Semantically, the cmpxchg is no more than an atomic >> operation on a single word: it has no other memory ordering effects. >> If you want the store to be observed before some other memory access >> you have to do something to make that happen. > > You seem to be confusing ordering with visibility. I hope not. > The cmpxchg must be visible to other threads else cmpxchg can't > function. But that doesn't imply any ordering constraints with > anything before/after the cmpxchg. Indeed not, but a volatile store -- the case I'm talking about -- is supposed to be part of the total order. So, the store must be sequenced before any following volatile loads. It makes no difference whether the operation is a simple store or is a cmpxchg: we need the trailing StoreLoad barrier. Andrew. From aph at redhat.com Tue Jul 5 12:50:40 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jul 2016 13:50:40 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <577B8248.5090009@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <577A7DDA.4000304@redhat.com> <577B67F9.7080900@redhat.com> <577B7B0D.3080505@redhat.com> <577B8248.5090009@redhat.com> Message-ID: <577BAD20.5080909@redhat.com> On 05/07/16 10:47, Andrew Dinn wrote: > However, we still use stlxr in the exchange to ensure that > the swap is ordered wrt later writes. OK, I haven't been doing that. In the case of a volatile CAS I'll use stlxr. Andrew. From Alan.Bateman at oracle.com Tue Jul 5 13:11:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jul 2016 14:11:01 +0100 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <57749331.2030701@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> <5774661A.3080500@oracle.com> <263e1aac-5876-111b-0ee8-7ea5a3f9d883@oracle.com> <57749331.2030701@oracle.com> Message-ID: <64011c81-d4b1-80dd-181b-6321f782d496@oracle.com> Just catching up on this thread, I assume this is the current patch: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ For the description then it might be clearer to say "for a named module" rather than "for a module" so that the first paragraph is clear than this is function to obtain a reference to a named module. For the class_loader description then it might be clearer to say is not NULL and a not a subclass of ... At some point then I assume the version="9.0.0" changes should be collapsed into one change element. The rest looks okay to me. -Alan From gnu.andrew at redhat.com Tue Jul 5 15:22:25 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jul 2016 11:22:25 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <577B5AA0.8050207@oracle.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> Message-ID: <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > In general it looks good. It's nice to see that this also fixes that > warning output from configure. My only nit is the comment describing the > parameters for FLAGS_SETUP_GCC6_COMPILER_FLAGS. It indicates that it > takes named parameters while it actually just takes positional. Please > either change it to named parameters or fix the comment. > Ah, that's because it was named parameters for a while, then I changed it because it was easier than trying to get ARG_PREFIX instead of $1 into [$]$1CFLAGS_JDK and friends. Fixed in: http://cr.openjdk.java.net/~andrew/8156980/webrev.02/ I'll let someone on your side push it through so you can regenerate your internal configure script at the same time. > Thanks for fixing this! > Thanks :) > /Erik > > On 2016-07-05 07:27, Andrew Hughes wrote: > > Webrev: http://cr.openjdk.java.net/~andrew/8156980/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156980 > > > > With "8151841: Build needs additional flags to compile with GCC 6", > > we added a number of compiler flags which were needed to build > > OpenJDK with GCC 6. Checks for these flags were added to configure, > > and the flags passed to the JDK and HotSpot builds by CFLAGS/CXXFLAGS_JDK > > and hotspot-spec.gmk.in respectively. > > > > Following "8152666: The new Hotspot Build System" and > > "8150601: Remove the old Hotspot build system", the hotspot-spec.gmk.in > > file was removed, so the flags were no longer passed to the HotSpot > > build. HotSpot now uses JVM_CFLAGS via the same configure process > > as the JDK obtains CFLAGS_JDK and CXXFLAGS_JDK[*]. > > > > This webrev fixes the regression introduced by 8152666 by adding > > the flags to JVM_CFLAGS. It also adapts FLAGS_SETUP_GCC6_COMPILER_FLAGS > > to take a prefix, as other macros in flags.m4 do, and calls > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS before the version check. > > The lack of the latter lead to configure executing: > > > > if test $OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION -ge > > $COMPARABLE_REFERENCE_VERSION > > > > with OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION ever being set, causing > > test to print an error. > > > > With this fix, the flags again make it into the build. > > > > [*] It should really be CXXFLAGS_JVM as they are flags for the C++ > > compiler. > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From kim.barrett at oracle.com Tue Jul 5 15:44:46 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 Jul 2016 11:44:46 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> Message-ID: > On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: > > ----- Original Message ----- >> Hello, >> >> In general it looks good. It's nice to see that this also fixes that >> warning output from configure. My only nit is the comment describing the >> parameters for FLAGS_SETUP_GCC6_COMPILER_FLAGS. It indicates that it >> takes named parameters while it actually just takes positional. Please >> either change it to named parameters or fix the comment. >> > > Ah, that's because it was named parameters for a while, then I changed it > because it was easier than trying to get ARG_PREFIX instead of $1 into > [$]$1CFLAGS_JDK and friends. > > Fixed in: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.02/ > > I'll let someone on your side push it through so you can regenerate > your internal configure script at the same time. I've also been looking at this area. It looks like we've found pretty much the same set of problems and have similar solutions, so that's good. I have a few suggestions or possible improvements. ------------------------------------------------------------------------------ common/autoconf/flags.m4 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about the BUILD/TARGET distinction. Note that this also doesn't seem to affect some non-VM chunks of code, such as adlc (in hotspot/src/share/vm/adlc). I don't know whether that matters. ------------------------------------------------------------------------------ common/autoconf/flags.m4 771 if test "x$1" = xTARGET; then 772 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS 773 else 774 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS(BUILD_,$2) 775 fi This is a fix for https://bugs.openjdk.java.net/browse/JDK-8157358 Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION I think the change I suggested in that CR is better. ------------------------------------------------------------------------------ common/autoconf/flags.m4 1458 AC_DEFUN([FLAGS_SETUP_GCC6_COMPILER_FLAGS], Changing from AC_DEFUN_ONCE to AC_DEFUN is good. It's needed in order to pass in the prefix. Even ignoring that issue, something needed to be done because the defun_once defined later was not being expanded where used. ------------------------------------------------------------------------------ common/autoconf/flags.m4 1470 $1CFLAGS_JDK="[$]$1CFLAGS_JDK ${NO_NULL_POINTER_CHECK_CFLAG} ${NO_LIFETIME_DSE_CFLAG}" 1471 $1JVM_CFLAGS="[$]$1JVM_CFLAGS ${NO_NULL_POINTER_CHECK_CFLAG} ${NO_LIFETIME_DSE_CFLAG}" Adding the prefix to the CFLAGS variables is good. Since we've already determined we're using gcc6+ to get here, I don't think there's any benefit to the pre-existing argument checks. More importantly, FLAGS_COMPILER_CHECK_ARGUMENTS doesn't account for the BUILD / TARGET distinction, so may produce the wrong answer if the build and target compilers are different versions of gcc. So I think those checks should be eliminated. Also, I think the variables capturing the options probably also need to be prefixed, if they are retained. Aside: I also think the variable name for -fno-delete-null-pointer-checks is mildly confusing, as the absence of "DELETE" inverts the apparent meaning. ------------------------------------------------------------------------------ common/autoconf/spec.gmk [removed] 395 NO_NULL_POINTER_CHECK_FLAG=@NO_NULL_POINTER_CHECK_CFLAG@ 396 NO_LIFETIME_DSE_CFLAG=@NO_LIFETIME_DSE_CFLAG@ 397 CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ These removals are good. This also eliminates the "FLAG" for "CFLAG" typo in NO_NULL_POINTER_CHECK_FLAG=. ------------------------------------------------------------------------------ From BLebeda at luxoft.com Mon Jul 4 15:10:35 2016 From: BLebeda at luxoft.com (Lebeda, Borys) Date: Mon, 4 Jul 2016 15:10:35 +0000 Subject: Exceptions on using Java on ARM Message-ID: <6AE91074EA3C3E49BD0F843608814648BB35932C@oro-mbox-02.luxoft.com> Hello everyone, I get following errors when run tomcat 6 on server with Java 8 on ARM device: I have once already reported the problem with the same environment which not reproduced with -Xint, however this time there was no -Xint option: root at phyFLEX-i:~ uname -a Linux phyFLEX-i.MX6 3.0.43-tpcom_run2-PD13.2.4 #1 SMP PREEMPT Fri Jun 10 11:55:37 CEST 2016 armv7l GNU/Linux root at phyFLEX-i:/usr/tomcat/lib /usr/java/ejre1.8.0_65/bin/java -cp catalina.jar org.apache.catalina.util.ServerInfo Server version: Apache Tomcat/6.0.36 Server built: Oct 16 2012 09:59:09 Server number: 6.0.36.0 OS Name: Linux OS Version: 3.0.43-tpcom_run2-PD13.2.4 Architecture: arm JVM Version: 1.8.0_65-b17 JVM Vendor: Oracle Corporation root at phyFLEX-i:~ /usr/java/ejre1.8.0_65/bin/java -version java version "1.8.0_65" Java(TM) SE Embedded Runtime Environment (build 1.8.0_65-b17, headless) Java HotSpot(TM) Embedded Client VM (build 25.65-b01, mixed mode) My assumption that these two crashes somehow connected, but I might be wrong: the connection is that test case and environment is the same Kind regards, Borys Lebeda ________________________________ This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. From serguei.spitsyn at oracle.com Tue Jul 5 16:55:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Jul 2016 09:55:33 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <64011c81-d4b1-80dd-181b-6321f782d496@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> <5774661A.3080500@oracle.com> <263e1aac-5876-111b-0ee8-7ea5a3f9d883@oracle.com> <57749331.2030701@oracle.com> <64011c81-d4b1-80dd-181b-6321f782d496@oracle.com> Message-ID: <577BE685.7010101@oracle.com> On 7/5/16 06:11, Alan Bateman wrote: > Just catching up on this thread, I assume this is the current patch: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ > > > For the description then it might be clearer to say "for a named > module" rather than "for a module" so that the first paragraph is > clear than this is function to obtain a reference to a named module. Fixed. > > For the class_loader description then it might be clearer to say is > not NULL and a not a subclass of ... Fixed. > > At some point then I assume the version="9.0.0" changes should be > collapsed into one change element. Fixed. > > The rest looks okay to me. Thanks, Alan! Serguei > > -Alan > > From gnu.andrew at redhat.com Tue Jul 5 17:33:59 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jul 2016 13:33:59 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> Message-ID: <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: > > > > ----- Original Message ----- > >> Hello, > >> > >> In general it looks good. It's nice to see that this also fixes that > >> warning output from configure. My only nit is the comment describing the > >> parameters for FLAGS_SETUP_GCC6_COMPILER_FLAGS. It indicates that it > >> takes named parameters while it actually just takes positional. Please > >> either change it to named parameters or fix the comment. > >> > > > > Ah, that's because it was named parameters for a while, then I changed it > > because it was easier than trying to get ARG_PREFIX instead of $1 into > > [$]$1CFLAGS_JDK and friends. > > > > Fixed in: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.02/ > > > > I'll let someone on your side push it through so you can regenerate > > your internal configure script at the same time. > > I've also been looking at this area. It looks like we've found pretty > much the same set of problems and have similar solutions, so that's > good. I have a few suggestions or possible improvements. > > ------------------------------------------------------------------------------ > common/autoconf/flags.m4 > 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" > > There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It > is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about > the BUILD/TARGET distinction. This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used in several places. I think this is outside the scope of this patch and something which should be fixed by completing the current half-hearted cross-compilation support. My aim here is just to fix the regression which breaks the GCC 6 support on build==target builds, and I'd rather whoever was working on the cross-compilation build continued that work. There is a solution already in the handling of the warning argument check, but it needs to be generalised to the other cases. > > Note that this also doesn't seem to affect some non-VM chunks of code, > such as adlc (in hotspot/src/share/vm/adlc). I don't know whether > that matters. Ugh, yes, so I see. It seems a couple of parts of the HotSpot build just blithely ignore all this and set their own flags unconditionally. For example, they also set -m64 regardless of whether it was successfully tested for or not. I've added a patch to pass the std setting down to these parts of the HotSpot build again, but they more generally need to be brought in line with everything else and respect the configure checks. > > ------------------------------------------------------------------------------ > common/autoconf/flags.m4 > 771 if test "x$1" = xTARGET; then > 772 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS > 773 else > 774 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS(BUILD_,$2) > 775 fi > > This is a fix for > https://bugs.openjdk.java.net/browse/JDK-8157358 > Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION > > I think the change I suggested in that CR is better. > I agree. I've reverted this part of my patch. I didn't realise it was already being worked on and it was getting in the way of working on this fix. I just went with the most local fix that got rid of the broken test invocations. > ------------------------------------------------------------------------------ > common/autoconf/flags.m4 > 1458 AC_DEFUN([FLAGS_SETUP_GCC6_COMPILER_FLAGS], > > Changing from AC_DEFUN_ONCE to AC_DEFUN is good. > > It's needed in order to pass in the prefix. Even ignoring that issue, > something needed to be done because the defun_once defined later was > not being expanded where used. It was being expanded once before, which was appropriate for a block of code that didn't take any arguments and was only used because it made the source file easier to read than trying to add that logic inside the TOOLCHAIN_CHECK_COMPILER_VERSION invocation. Now we do need to call it for both the build and target compilers, AC_DEFUN is more appropriate. > > ------------------------------------------------------------------------------ > common/autoconf/flags.m4 > 1470 $1CFLAGS_JDK="[$]$1CFLAGS_JDK ${NO_NULL_POINTER_CHECK_CFLAG} > ${NO_LIFETIME_DSE_CFLAG}" > 1471 $1JVM_CFLAGS="[$]$1JVM_CFLAGS ${NO_NULL_POINTER_CHECK_CFLAG} > ${NO_LIFETIME_DSE_CFLAG}" > > Adding the prefix to the CFLAGS variables is good. > > Since we've already determined we're using gcc6+ to get here, I don't > think there's any benefit to the pre-existing argument checks. > > More importantly, FLAGS_COMPILER_CHECK_ARGUMENTS doesn't account for > the BUILD / TARGET distinction, so may produce the wrong answer if the > build and target compilers are different versions of gcc. > > So I think those checks should be eliminated. As you may recall, these checks were originally called in all instances and we decided to limit it to GCC 6 or later in review. I still think keeping the checks is wise, as these options may not work with future compilers. If I was to eliminate anything, it would be the version check, but I realise HotSpot developers are pretty conservative about turning off these optimisations on existing builds. FLAGS_COMPILER_CHECK_ARGUMENTS does need fixing for the cross compilation case as mentioned above, and that's a more general issue that affects other calls too: $ cat common/autoconf/flags.m4|grep 'FLAGS_COMPILER_CHECK_ARGUMENTS('|grep -v '^#' FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG -Werror], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$ZERO_ARCHFLAG], IF_FALSE: [ZERO_ARCHFLAG=""]) FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}], FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [-Wno-this-is-a-warning-that-do-not-exist], FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [-Wno-this-is-a-warning-that-do-not-exist], FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$NO_NULL_POINTER_CHECK_CFLAG -Werror], FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$NO_LIFETIME_DSE_CFLAG -Werror], In the case of -Wno-this-is-a-warning-that-do-not-exist, there are two invocations because the target and build compilers are both checked by switching the value of CXX: # Repeate the check for the BUILD_CC and BUILD_CXX. Need to also reset # CFLAGS since any target specific flags will likely not work with the # build compiler CC_OLD="$CC" CXX_OLD="$CXX" CC="$BUILD_CC" CXX="$BUILD_CXX" CFLAGS_OLD="$CFLAGS" CFLAGS="" That really needs to be factored into a macro and applied to all these calls. > > Also, I think the variables capturing the options probably also need > to be prefixed, if they are retained. > With AC_SUBST gone, these variables are only temporary. They are reset at the start and their values are not used again once they are added to the CFLAGS. > Aside: I also think the variable name for > -fno-delete-null-pointer-checks is mildly confusing, as the absence of > "DELETE" inverts the apparent meaning. I was trying to keep it short for brevity, but I agree and have renamed it. > > ------------------------------------------------------------------------------ > common/autoconf/spec.gmk > [removed] > 395 NO_NULL_POINTER_CHECK_FLAG=@NO_NULL_POINTER_CHECK_CFLAG@ > 396 NO_LIFETIME_DSE_CFLAG=@NO_LIFETIME_DSE_CFLAG@ > 397 CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ > > These removals are good. This also eliminates the "FLAG" for "CFLAG" > typo in NO_NULL_POINTER_CHECK_FLAG=. > > ------------------------------------------------------------------------------ > > I've had to bring back CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ for the renegade parts of the HotSpot build. New webrevs: http://cr.openjdk.java.net/~andrew/8156980/webrev.03/root/ http://cr.openjdk.java.net/~andrew/8156980/webrev.03/hotspot/ -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From vladimir.kozlov at oracle.com Tue Jul 5 18:56:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jul 2016 11:56:55 -0700 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: In CheckCompileThresholdScaling.java fix spacing for "double CompileThresholdScaling" lines (it was wrong in original code too). Otherwise looks good. No need for updated webrev. Thanks, Vladimir On 6/29/16 9:55 AM, Jesper Wilhelmsson wrote: > After some more testing I made a few smaller updates: > > * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() > Looking at other code, it seemed to be the right thing to do. > > * Using size_t instead of int for the size and used counter in > Flag::print_kind_and_origin() > Windows compiler complained. > > * ORIG_COMMAND_LINE = 1 << 19 > > * Fixed some tests that was surprised by the new output from > PrintFlagsFinal. > > New webrev: > http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ > > Thanks, > /Jesper > > > Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>> why you skipped 19?: >>> >>> ORIG_COMMAND_LINE = 1 << 20, >> >> No good reason really, just leaving some space since ORIG_COMMAND_LINE >> is not a >> kind. I can change it to 19 if you think that's better. >> >>> >>> Otherwise looks good. >> >> Thanks for reviewing! >> >> /Jesper >> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>> >>>>> >>>>> I agree with Vladimir. There's no way I'm going to remember that a >>>>> colon >>>>> mean that the value was changed. >>>> The colon is what we have today to indicate that a value was changed :) >>>> >>>> I made a different solution in which I explicitly print the origin >>>> with words. >>>> To make it look better I changed the >>>> printing routine somewhat. The origin is currently at the end of the >>>> line. >>>> This version will also print other origins like config file, >>>> environment, and >>>> management as suggested by Dan. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>> >>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>> >>>> This is the new version: >>>> >>>> ccstr AbortVMOnExceptionMessage = >>>> {diagnostic} {default} >>>> uintx AdaptiveSizeDecrementScaleFactor = >>>> 4 {product} {default} >>>> intx AliasLevel = >>>> 3 {C2 product} {default} >>>> intx CMSAbortablePrecleanWaitMillis = >>>> 100 {manageable} {default} >>>> bool CMSClassUnloadingEnabled = >>>> false {product} {command line} >>>> intx ConditionalMoveLimit = >>>> 3 {C2 pd product} {default} >>>> size_t InitialHeapSize = >>>> 134217728 {product} {ergonomic} >>>> size_t MaxMetaspaceSize = >>>> 18446744073709547520 {product} {default} >>>> size_t NewSize = >>>> 1966080 {product} {command line, >>>> ergonomic} >>>> ccstrlist OnError = >>>> {product} {default} >>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>> -1 {develop} {default} >>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>> true {product} {default} >>>> bool UseCISCSpill = >>>> true {C2 pd develop} {default} >>>> bool UseCLMUL = >>>> true {ARCH product} {default} >>>> bool UseCompressedOops = >>>> true {lp64_product} {ergonomic} >>>> bool UseConcMarkSweepGC = >>>> true {product} {command line} >>>> >>>> This is the old (current) version: >>>> >>>> ccstr AbortVMOnExceptionMessage = >>>> {diagnostic} >>>> uintx AdaptiveSizeDecrementScaleFactor = >>>> 4 {product} >>>> intx AliasLevel = >>>> 3 {C2 product} >>>> intx CMSAbortablePrecleanWaitMillis = >>>> 100 {manageable} >>>> bool CMSClassUnloadingEnabled := >>>> false {product} >>>> intx ConditionalMoveLimit = >>>> 3 {C2 pd product} >>>> size_t InitialHeapSize := >>>> 134217728 {product} >>>> size_t MaxMetaspaceSize = >>>> 18446744073709547520 {product} >>>> size_t NewSize := >>>> 1966080 {product} >>>> ccstrlist OnError = {product} >>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>> -1 {develop} >>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>> true {product} >>>> bool UseCISCSpill = >>>> true {C2 pd develop} >>>> bool UseCompressedOops := >>>> true {lp64_product} >>>> bool UseConcMarkSweepGC := >>>> true {product} >>>> >>>> /Jesper >>>> >>>>> Coleen >>>>> >>>>> >>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>> Nobody will remember the meaning of such marking. You should use >>>>>> normal words. >>>>>> The output already have flag's type as, for example, "{C2 >>>>>> product}". You can >>>>>> add an other word there to indicate type >>>>>> of initialization: default|command|ergo. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this change to make -XX:+PrintFlagsFinal >>>>>>> distinguish between >>>>>>> flags changed on the command line and flags >>>>>>> changed by the ergonomics. >>>>>>> >>>>>>> To enable us to remember if a flag was set on the command line or >>>>>>> not after >>>>>>> having been changed by the ergonomics I use >>>>>>> another bit in the Flag struct. >>>>>>> >>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat >>>>>>> arbitrary >>>>>>> and I'm open to suggestions (bike sheding) >>>>>>> about how to visualize this the best. >>>>>>> >>>>>>> The old decorations are: >>>>>>> >>>>>>> ' =' - Default value (no decoration) >>>>>>> ':=' - Value was changed, either by command line or ergonomics or >>>>>>> other >>>>>>> >>>>>>> The new decorations are: >>>>>>> >>>>>>> ' =' - Default value (no decoration) >>>>>>> ':=' - Set on the command line >>>>>>> '?=' - Changed by the ergonomics >>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>> '-=' - Any other origin, like changed by management API or taken >>>>>>> from a >>>>>>> config file >>>>>>> >>>>>>> My reasoning behind selecting these characters are that ':=' >>>>>>> looks like a >>>>>>> solid assignment and will therefore represent >>>>>>> the command line. You never know what you get from the >>>>>>> ergonomics, so '?=' >>>>>>> seems appropriate. '!=' because you'd >>>>>>> want to >>>>>>> know that the ergonomics changed a value you had set on the >>>>>>> command line. >>>>>>> >>>>>>> Another option could be to use a colon ':=' for the command line, >>>>>>> and a >>>>>>> comma ',=' for the ergonomics. That would >>>>>>> naturally give us the semi-colon ';=' for something set on the >>>>>>> command line >>>>>>> and changed by the ergonomics. I didn't go >>>>>>> with this because the colon and semi-colon can be hard to >>>>>>> distinguish from >>>>>>> each other. >>>>>>> >>>>>>> As mentioned above there are other origins, the enum contains >>>>>>> eight values. >>>>>>> There is no mention of the other types in >>>>>>> the bug and there are no is_...() for the other types in >>>>>>> globals.cpp, so >>>>>>> they didn't seem as important. If the general >>>>>>> opinion is that these other origins are as important, or we might as >>>>>>> well..., I'd suggest that we use letters as >>>>>>> decorations. Let me know if you have an opinion. >>>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Jesper >>>>> >>>> From jesper.wilhelmsson at oracle.com Tue Jul 5 19:09:39 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 5 Jul 2016 21:09:39 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: <900bfd35-3ec9-ecf7-0c5b-2cf9ace46c7e@oracle.com> Den 5/7/16 kl. 20:56, skrev Vladimir Kozlov: > In CheckCompileThresholdScaling.java fix spacing for "double > CompileThresholdScaling" lines (it was wrong in original code too). Are you referring to the number of spaces between the flag and the '='? It matches the output from PrintFlagsFinal. It looks skewed in the test because in the test the lines are aligned starting at the first character in the type name, but in the flag output it is aligned on the space between the type and the flag name: intx CompileThreshold = 10000 double CompileThresholdScaling = 1.000000 Please clarify if this was not what you meant. > > Otherwise looks good. No need for updated webrev. Thanks! /Jesper > > Thanks, > Vladimir > > On 6/29/16 9:55 AM, Jesper Wilhelmsson wrote: >> After some more testing I made a few smaller updates: >> >> * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() >> Looking at other code, it seemed to be the right thing to do. >> >> * Using size_t instead of int for the size and used counter in >> Flag::print_kind_and_origin() >> Windows compiler complained. >> >> * ORIG_COMMAND_LINE = 1 << 19 >> >> * Fixed some tests that was surprised by the new output from >> PrintFlagsFinal. >> >> New webrev: >> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ >> >> Thanks, >> /Jesper >> >> >> Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >>> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>>> why you skipped 19?: >>>> >>>> ORIG_COMMAND_LINE = 1 << 20, >>> >>> No good reason really, just leaving some space since ORIG_COMMAND_LINE >>> is not a >>> kind. I can change it to 19 if you think that's better. >>> >>>> >>>> Otherwise looks good. >>> >>> Thanks for reviewing! >>> >>> /Jesper >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>>> >>>>>> >>>>>> I agree with Vladimir. There's no way I'm going to remember that a >>>>>> colon >>>>>> mean that the value was changed. >>>>> The colon is what we have today to indicate that a value was changed :) >>>>> >>>>> I made a different solution in which I explicitly print the origin >>>>> with words. >>>>> To make it look better I changed the >>>>> printing routine somewhat. The origin is currently at the end of the >>>>> line. >>>>> This version will also print other origins like config file, >>>>> environment, and >>>>> management as suggested by Dan. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>>> >>>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>>> >>>>> This is the new version: >>>>> >>>>> ccstr AbortVMOnExceptionMessage = >>>>> {diagnostic} {default} >>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>> 4 {product} {default} >>>>> intx AliasLevel = >>>>> 3 {C2 product} {default} >>>>> intx CMSAbortablePrecleanWaitMillis = >>>>> 100 {manageable} {default} >>>>> bool CMSClassUnloadingEnabled = >>>>> false {product} {command line} >>>>> intx ConditionalMoveLimit = >>>>> 3 {C2 pd product} {default} >>>>> size_t InitialHeapSize = >>>>> 134217728 {product} {ergonomic} >>>>> size_t MaxMetaspaceSize = >>>>> 18446744073709547520 {product} {default} >>>>> size_t NewSize = >>>>> 1966080 {product} {command line, >>>>> ergonomic} >>>>> ccstrlist OnError = >>>>> {product} {default} >>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>> -1 {develop} {default} >>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>> true {product} {default} >>>>> bool UseCISCSpill = >>>>> true {C2 pd develop} {default} >>>>> bool UseCLMUL = >>>>> true {ARCH product} {default} >>>>> bool UseCompressedOops = >>>>> true {lp64_product} {ergonomic} >>>>> bool UseConcMarkSweepGC = >>>>> true {product} {command line} >>>>> >>>>> This is the old (current) version: >>>>> >>>>> ccstr AbortVMOnExceptionMessage = >>>>> {diagnostic} >>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>> 4 {product} >>>>> intx AliasLevel = >>>>> 3 {C2 product} >>>>> intx CMSAbortablePrecleanWaitMillis = >>>>> 100 {manageable} >>>>> bool CMSClassUnloadingEnabled := >>>>> false {product} >>>>> intx ConditionalMoveLimit = >>>>> 3 {C2 pd product} >>>>> size_t InitialHeapSize := >>>>> 134217728 {product} >>>>> size_t MaxMetaspaceSize = >>>>> 18446744073709547520 {product} >>>>> size_t NewSize := >>>>> 1966080 {product} >>>>> ccstrlist OnError = {product} >>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>> -1 {develop} >>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>> true {product} >>>>> bool UseCISCSpill = >>>>> true {C2 pd develop} >>>>> bool UseCompressedOops := >>>>> true {lp64_product} >>>>> bool UseConcMarkSweepGC := >>>>> true {product} >>>>> >>>>> /Jesper >>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>>> Nobody will remember the meaning of such marking. You should use >>>>>>> normal words. >>>>>>> The output already have flag's type as, for example, "{C2 >>>>>>> product}". You can >>>>>>> add an other word there to indicate type >>>>>>> of initialization: default|command|ergo. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this change to make -XX:+PrintFlagsFinal >>>>>>>> distinguish between >>>>>>>> flags changed on the command line and flags >>>>>>>> changed by the ergonomics. >>>>>>>> >>>>>>>> To enable us to remember if a flag was set on the command line or >>>>>>>> not after >>>>>>>> having been changed by the ergonomics I use >>>>>>>> another bit in the Flag struct. >>>>>>>> >>>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat >>>>>>>> arbitrary >>>>>>>> and I'm open to suggestions (bike sheding) >>>>>>>> about how to visualize this the best. >>>>>>>> >>>>>>>> The old decorations are: >>>>>>>> >>>>>>>> ' =' - Default value (no decoration) >>>>>>>> ':=' - Value was changed, either by command line or ergonomics or >>>>>>>> other >>>>>>>> >>>>>>>> The new decorations are: >>>>>>>> >>>>>>>> ' =' - Default value (no decoration) >>>>>>>> ':=' - Set on the command line >>>>>>>> '?=' - Changed by the ergonomics >>>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>>> '-=' - Any other origin, like changed by management API or taken >>>>>>>> from a >>>>>>>> config file >>>>>>>> >>>>>>>> My reasoning behind selecting these characters are that ':=' >>>>>>>> looks like a >>>>>>>> solid assignment and will therefore represent >>>>>>>> the command line. You never know what you get from the >>>>>>>> ergonomics, so '?=' >>>>>>>> seems appropriate. '!=' because you'd >>>>>>>> want to >>>>>>>> know that the ergonomics changed a value you had set on the >>>>>>>> command line. >>>>>>>> >>>>>>>> Another option could be to use a colon ':=' for the command line, >>>>>>>> and a >>>>>>>> comma ',=' for the ergonomics. That would >>>>>>>> naturally give us the semi-colon ';=' for something set on the >>>>>>>> command line >>>>>>>> and changed by the ergonomics. I didn't go >>>>>>>> with this because the colon and semi-colon can be hard to >>>>>>>> distinguish from >>>>>>>> each other. >>>>>>>> >>>>>>>> As mentioned above there are other origins, the enum contains >>>>>>>> eight values. >>>>>>>> There is no mention of the other types in >>>>>>>> the bug and there are no is_...() for the other types in >>>>>>>> globals.cpp, so >>>>>>>> they didn't seem as important. If the general >>>>>>>> opinion is that these other origins are as important, or we might as >>>>>>>> well..., I'd suggest that we use letters as >>>>>>>> decorations. Let me know if you have an opinion. >>>>>>>> >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Jesper >>>>>> >>>>> From vladimir.kozlov at oracle.com Tue Jul 5 19:37:39 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jul 2016 12:37:39 -0700 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: <900bfd35-3ec9-ecf7-0c5b-2cf9ace46c7e@oracle.com> References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> <900bfd35-3ec9-ecf7-0c5b-2cf9ace46c7e@oracle.com> Message-ID: <0b255e86-2779-1d11-90e7-e3c8cb565a63@oracle.com> On 7/5/16 12:09 PM, Jesper Wilhelmsson wrote: > Den 5/7/16 kl. 20:56, skrev Vladimir Kozlov: >> In CheckCompileThresholdScaling.java fix spacing for "double >> CompileThresholdScaling" lines (it was wrong in original code too). > > Are you referring to the number of spaces between the flag and the '='? yes > It matches the output from PrintFlagsFinal. It looks skewed in the test > because in the test the lines are aligned starting at the first > character in the type name, but in the flag output it is aligned on the > space between the type and the flag name: > > intx CompileThreshold = 10000 > double CompileThresholdScaling = 1.000000 Got it. Ignore my comment then. Changes are good. Thanks, Vladimir > > Please clarify if this was not what you meant. > >> >> Otherwise looks good. No need for updated webrev. > > Thanks! > > /Jesper > >> >> Thanks, >> Vladimir >> >> On 6/29/16 9:55 AM, Jesper Wilhelmsson wrote: >>> After some more testing I made a few smaller updates: >>> >>> * Using jio_snprintf instead of snprintf in >>> Flag::print_kind_and_origin() >>> Looking at other code, it seemed to be the right thing to do. >>> >>> * Using size_t instead of int for the size and used counter in >>> Flag::print_kind_and_origin() >>> Windows compiler complained. >>> >>> * ORIG_COMMAND_LINE = 1 << 19 >>> >>> * Fixed some tests that was surprised by the new output from >>> PrintFlagsFinal. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ >>> >>> Thanks, >>> /Jesper >>> >>> >>> Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >>>> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>>>> why you skipped 19?: >>>>> >>>>> ORIG_COMMAND_LINE = 1 << 20, >>>> >>>> No good reason really, just leaving some space since ORIG_COMMAND_LINE >>>> is not a >>>> kind. I can change it to 19 if you think that's better. >>>> >>>>> >>>>> Otherwise looks good. >>>> >>>> Thanks for reviewing! >>>> >>>> /Jesper >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>>>> >>>>>>> >>>>>>> I agree with Vladimir. There's no way I'm going to remember that a >>>>>>> colon >>>>>>> mean that the value was changed. >>>>>> The colon is what we have today to indicate that a value was >>>>>> changed :) >>>>>> >>>>>> I made a different solution in which I explicitly print the origin >>>>>> with words. >>>>>> To make it look better I changed the >>>>>> printing routine somewhat. The origin is currently at the end of the >>>>>> line. >>>>>> This version will also print other origins like config file, >>>>>> environment, and >>>>>> management as suggested by Dan. >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>>>> >>>>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>>>> >>>>>> This is the new version: >>>>>> >>>>>> ccstr AbortVMOnExceptionMessage = >>>>>> {diagnostic} {default} >>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>> 4 {product} {default} >>>>>> intx AliasLevel = >>>>>> 3 {C2 product} {default} >>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>> 100 {manageable} {default} >>>>>> bool CMSClassUnloadingEnabled = >>>>>> false {product} {command line} >>>>>> intx ConditionalMoveLimit = >>>>>> 3 {C2 pd product} {default} >>>>>> size_t InitialHeapSize = >>>>>> 134217728 {product} {ergonomic} >>>>>> size_t MaxMetaspaceSize = >>>>>> 18446744073709547520 {product} {default} >>>>>> size_t NewSize = >>>>>> 1966080 {product} {command line, >>>>>> ergonomic} >>>>>> ccstrlist OnError = >>>>>> {product} {default} >>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>> -1 {develop} {default} >>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>> true {product} {default} >>>>>> bool UseCISCSpill = >>>>>> true {C2 pd develop} {default} >>>>>> bool UseCLMUL = >>>>>> true {ARCH product} {default} >>>>>> bool UseCompressedOops = >>>>>> true {lp64_product} {ergonomic} >>>>>> bool UseConcMarkSweepGC = >>>>>> true {product} {command line} >>>>>> >>>>>> This is the old (current) version: >>>>>> >>>>>> ccstr AbortVMOnExceptionMessage = >>>>>> {diagnostic} >>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>> 4 {product} >>>>>> intx AliasLevel = >>>>>> 3 {C2 product} >>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>> 100 {manageable} >>>>>> bool CMSClassUnloadingEnabled := >>>>>> false {product} >>>>>> intx ConditionalMoveLimit = >>>>>> 3 {C2 pd product} >>>>>> size_t InitialHeapSize := >>>>>> 134217728 {product} >>>>>> size_t MaxMetaspaceSize = >>>>>> 18446744073709547520 {product} >>>>>> size_t NewSize := >>>>>> 1966080 {product} >>>>>> ccstrlist OnError = {product} >>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>> -1 {develop} >>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>> true {product} >>>>>> bool UseCISCSpill = >>>>>> true {C2 pd develop} >>>>>> bool UseCompressedOops := >>>>>> true {lp64_product} >>>>>> bool UseConcMarkSweepGC := >>>>>> true {product} >>>>>> >>>>>> /Jesper >>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>>>> Nobody will remember the meaning of such marking. You should use >>>>>>>> normal words. >>>>>>>> The output already have flag's type as, for example, "{C2 >>>>>>>> product}". You can >>>>>>>> add an other word there to indicate type >>>>>>>> of initialization: default|command|ergo. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review this change to make -XX:+PrintFlagsFinal >>>>>>>>> distinguish between >>>>>>>>> flags changed on the command line and flags >>>>>>>>> changed by the ergonomics. >>>>>>>>> >>>>>>>>> To enable us to remember if a flag was set on the command line or >>>>>>>>> not after >>>>>>>>> having been changed by the ergonomics I use >>>>>>>>> another bit in the Flag struct. >>>>>>>>> >>>>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat >>>>>>>>> arbitrary >>>>>>>>> and I'm open to suggestions (bike sheding) >>>>>>>>> about how to visualize this the best. >>>>>>>>> >>>>>>>>> The old decorations are: >>>>>>>>> >>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>> ':=' - Value was changed, either by command line or ergonomics or >>>>>>>>> other >>>>>>>>> >>>>>>>>> The new decorations are: >>>>>>>>> >>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>> ':=' - Set on the command line >>>>>>>>> '?=' - Changed by the ergonomics >>>>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>>>> '-=' - Any other origin, like changed by management API or taken >>>>>>>>> from a >>>>>>>>> config file >>>>>>>>> >>>>>>>>> My reasoning behind selecting these characters are that ':=' >>>>>>>>> looks like a >>>>>>>>> solid assignment and will therefore represent >>>>>>>>> the command line. You never know what you get from the >>>>>>>>> ergonomics, so '?=' >>>>>>>>> seems appropriate. '!=' because you'd >>>>>>>>> want to >>>>>>>>> know that the ergonomics changed a value you had set on the >>>>>>>>> command line. >>>>>>>>> >>>>>>>>> Another option could be to use a colon ':=' for the command line, >>>>>>>>> and a >>>>>>>>> comma ',=' for the ergonomics. That would >>>>>>>>> naturally give us the semi-colon ';=' for something set on the >>>>>>>>> command line >>>>>>>>> and changed by the ergonomics. I didn't go >>>>>>>>> with this because the colon and semi-colon can be hard to >>>>>>>>> distinguish from >>>>>>>>> each other. >>>>>>>>> >>>>>>>>> As mentioned above there are other origins, the enum contains >>>>>>>>> eight values. >>>>>>>>> There is no mention of the other types in >>>>>>>>> the bug and there are no is_...() for the other types in >>>>>>>>> globals.cpp, so >>>>>>>>> they didn't seem as important. If the general >>>>>>>>> opinion is that these other origins are as important, or we >>>>>>>>> might as >>>>>>>>> well..., I'd suggest that we use letters as >>>>>>>>> decorations. Let me know if you have an opinion. >>>>>>>>> >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Jesper >>>>>>> >>>>>> From kim.barrett at oracle.com Tue Jul 5 20:54:08 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 Jul 2016 16:54:08 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> Message-ID: > On Jul 5, 2016, at 1:33 PM, Andrew Hughes wrote: > > ----- Original Message ----- >>> On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: >> common/autoconf/flags.m4 >> 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" >> >> There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It >> is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about >> the BUILD/TARGET distinction. > > This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS > and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the > FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used > in several places. I think this is outside the scope of this patch and > something which should be fixed by completing the current half-hearted > cross-compilation support. My aim here is just to fix the regression > which breaks the GCC 6 support on build==target builds, and I'd rather > whoever was working on the cross-compilation build continued that work. > There is a solution already in the handling of the warning argument > check, but it needs to be generalised to the other cases. I totally agree that fixing the xxx_CHECK_ARGUMENTS is out of scope for this patch. What I'm worried about is that by keeping those checks we might get and use the wrong answer in some cases where the BUILD and TARGET compilers are of different vintage. Maybe that will just encourage someone to fix them... In the specific case of -std=gnu++98, it seems unlikely we'll see such a misconfiguration any time soon. That option was introduced in gcc3.3, and it seems unlikely to me that anyone is building the JDK with such an old compiler (though it wouldn't be the first time I've been surprised in that way). OTOH, if the compiler is very new and has dropped support for that standard (e.g. some as yet not even announced version of gcc), we actually want a build failure, since our code was written for that standard and not some later one. So we're unlikely to be hurt by the use of xxx_CHECK_ARGUMENTS here. For the gcc6-specific options, see below. >> Note that this also doesn't seem to affect some non-VM chunks of code, >> such as adlc (in hotspot/src/share/vm/adlc). I don't know whether >> that matters. > > Ugh, yes, so I see. It seems a couple of parts of the HotSpot build > just blithely ignore all this and set their own flags unconditionally. > For example, they also set -m64 regardless of whether it was successfully > tested for or not. > > I've added a patch to pass the std setting down to these parts of the > HotSpot build again, but they more generally need to be brought in line > with everything else and respect the configure checks. I think there are some more that are outside of HotSpot. Searching the build directory for *.o.cmdline files that don?t contain -std=gnu++98, e.g. find . -name "*.o.cmdline" ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print | xargs dirname | uniq produces a lot of stuff in ./support/native, the afore mentioned adlc, and a smattering of others. I think those might be better addressed by more followups, to get what we?ve got so far in. >> common/autoconf/flags.m4 >> 771 if test "x$1" = xTARGET; then >> 772 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS >> 773 else >> 774 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS(BUILD_,$2) >> 775 fi >> >> This is a fix for >> https://bugs.openjdk.java.net/browse/JDK-8157358 >> Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION >> >> I think the change I suggested in that CR is better. >> > > I agree. I've reverted this part of my patch. I didn't realise it > was already being worked on and it was getting in the way of working on > this fix. I just went with the most local fix that got rid of the broken > test invocations. I wasn't planning to work on any of this, but was feeling annoyed about the situation, and then events conspired to leave me at loose ends for a bit this weekend. Though if I'd remembered how much I dislike autoconf, I might have looked harder for alternatives. But you will need that fix for JDK-8157358. I guess I should post an RFR for it... or you can just incorporate it into this patch if I don?t get that RFR done soon. >> common/autoconf/flags.m4 >> 1458 AC_DEFUN([FLAGS_SETUP_GCC6_COMPILER_FLAGS], >> >> Changing from AC_DEFUN_ONCE to AC_DEFUN is good. >> >> It's needed in order to pass in the prefix. Even ignoring that issue, >> something needed to be done because the defun_once defined later was >> not being expanded where used. > > It was being expanded once before, which was appropriate for a block of > code that didn't take any arguments and was only used because it made the > source file easier to read than trying to add that logic inside the > TOOLCHAIN_CHECK_COMPILER_VERSION invocation. You are right about it being expanded once. I must have been remembering one of the unsuccessful attempts I tried, where no code was generated at all for it. > Now we do need to call it for both the build and target compilers, AC_DEFUN > is more appropriate. Yes. >> common/autoconf/flags.m4 >> 1470 $1CFLAGS_JDK="[$]$1CFLAGS_JDK ${NO_NULL_POINTER_CHECK_CFLAG} >> ${NO_LIFETIME_DSE_CFLAG}" >> 1471 $1JVM_CFLAGS="[$]$1JVM_CFLAGS ${NO_NULL_POINTER_CHECK_CFLAG} >> ${NO_LIFETIME_DSE_CFLAG}" >> >> Adding the prefix to the CFLAGS variables is good. >> >> Since we've already determined we're using gcc6+ to get here, I don't >> think there's any benefit to the pre-existing argument checks. >> >> More importantly, FLAGS_COMPILER_CHECK_ARGUMENTS doesn't account for >> the BUILD / TARGET distinction, so may produce the wrong answer if the >> build and target compilers are different versions of gcc. >> >> So I think those checks should be eliminated. > > As you may recall, these checks were originally called in all > instances and we decided to limit it to GCC 6 or later in review. > I still think keeping the checks is wise, as these options may > not work with future compilers. If I was to eliminate anything, > it would be the version check, but I realise HotSpot developers > are pretty conservative about turning off these optimisations > on existing builds. I'm much more worried about getting and using the wrong answer for these options. Since we're already in a context where we're known to be using gcc6+, we know we're not using a too-old compiler that doesn't support them for that reason. -f[no-]delete-null-pointer-checks has been around since gcc 3.0, and seems unlikely to go away, since it has a real documented purpose (address zero isn't so special on some platforms). -f[no-]lifetime-dse is fairly new (introduced in gcc 4.9), so seems unlikely to go away soon, and if it did we would want a build failure anyway, at least until we've fixed the code that gets broken by that optimization. > FLAGS_COMPILER_CHECK_ARGUMENTS does need fixing for the cross > compilation case as mentioned above, and that's a more general > issue that affects other calls too: Yes. > > $ cat common/autoconf/flags.m4|grep 'FLAGS_COMPILER_CHECK_ARGUMENTS('|grep -v '^#' > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG -Werror], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$ZERO_ARCHFLAG], IF_FALSE: [ZERO_ARCHFLAG=""]) > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}], > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [-Wno-this-is-a-warning-that-do-not-exist], > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [-Wno-this-is-a-warning-that-do-not-exist], > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$NO_NULL_POINTER_CHECK_CFLAG -Werror], > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$NO_LIFETIME_DSE_CFLAG -Werror], > > In the case of -Wno-this-is-a-warning-that-do-not-exist, there are two > invocations because the target and build compilers are both checked > by switching the value of CXX: > > # Repeate the check for the BUILD_CC and BUILD_CXX. Need to also reset > # CFLAGS since any target specific flags will likely not work with the > # build compiler > CC_OLD="$CC" > CXX_OLD="$CXX" > CC="$BUILD_CC" > CXX="$BUILD_CXX" > CFLAGS_OLD="$CFLAGS" > CFLAGS="" > > That really needs to be factored into a macro and applied to all these calls. Yes. >> Also, I think the variables capturing the options probably also need >> to be prefixed, if they are retained. >> > > With AC_SUBST gone, these variables are only temporary. They are reset at > the start and their values are not used again once they are added to the CFLAGS. Oh, right, no more AC_SUBST here. > I've had to bring back CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ for the renegade parts > of the HotSpot build. > > New webrevs: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.03/root/ > http://cr.openjdk.java.net/~andrew/8156980/webrev.03/hotspot/ ------------------------------------------------------------------------------ hotspot/make/lib/CompileDtracePostJvm.gmk 90 JVM_OFFSETS_CFLAGS := $(CXXSTD_CXXFLAG) -m64 This appears to be in a solaris-specific block, so I don't think this change should be made. ------------------------------------------------------------------------------ hotspot/make/gensrc/GensrcAdlc.gmk 54 # Set the C++ standard if supported 55 ADLC_CFLAGS += $(CXXSTD_CXXFLAG) This appears to be in a platform-independent block; I think it needs to be moved to a different location, probably the linux block starting at line 37. From vladimir.kozlov at oracle.com Tue Jul 5 21:18:19 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jul 2016 14:18:19 -0700 Subject: Result: New hotspot Group Member: Zoltan Majo Message-ID: <7ef53306-3321-fde3-2de8-b773eda58ac0@oracle.com> The vote for Zoltan Majo [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Vladimir Kozlov [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-June/023436.html From vladimir.kozlov at oracle.com Tue Jul 5 21:19:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jul 2016 14:19:05 -0700 Subject: Result: New hotspot Group Member: Tobias Hartmann Message-ID: The vote for Tobias Hartmann [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Vladimir Kozlov [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-June/023437.html From gnu.andrew at redhat.com Wed Jul 6 05:23:03 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 6 Jul 2016 01:23:03 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> Message-ID: <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 5, 2016, at 1:33 PM, Andrew Hughes wrote: > > > > ----- Original Message ----- > >>> On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: > >> common/autoconf/flags.m4 > >> 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" > >> > >> There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It > >> is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about > >> the BUILD/TARGET distinction. > > > > This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS > > and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the > > FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used > > in several places. I think this is outside the scope of this patch and > > something which should be fixed by completing the current half-hearted > > cross-compilation support. My aim here is just to fix the regression > > which breaks the GCC 6 support on build==target builds, and I'd rather > > whoever was working on the cross-compilation build continued that work. > > There is a solution already in the handling of the warning argument > > check, but it needs to be generalised to the other cases. > > I totally agree that fixing the xxx_CHECK_ARGUMENTS is out of scope > for this patch. > > What I'm worried about is that by keeping those checks we might get > and use the wrong answer in some cases where the BUILD and TARGET > compilers are of different vintage. Maybe that will just encourage > someone to fix them... Thanks. I agree it's an issue. I just don't think I'm the right person to undertake rewiring all that, as I've never even used the cross-compilation support so far. Do you know if there's already a bug for this? If not, I'll file one. > > In the specific case of -std=gnu++98, it seems unlikely we'll see such > a misconfiguration any time soon. That option was introduced in > gcc3.3, and it seems unlikely to me that anyone is building the JDK > with such an old compiler (though it wouldn't be the first time I've > been surprised in that way). OTOH, if the compiler is very new and has > dropped support for that standard (e.g. some as yet not even announced > version of gcc), we actually want a build failure, since our code was > written for that standard and not some later one. So we're unlikely to > be hurt by the use of xxx_CHECK_ARGUMENTS here. > I agree it's more likely that gnu++98 is going to be dropped at some point, than we had a compiler that doesn't support the -std option. Hopefully, making what was an implicit default before now explicit will encourage developers to look at moving the code forward to a later version of the standard. That's probably something for JDK 10+ though. > For the gcc6-specific options, see below. > > >> Note that this also doesn't seem to affect some non-VM chunks of code, > >> such as adlc (in hotspot/src/share/vm/adlc). I don't know whether > >> that matters. > > > > Ugh, yes, so I see. It seems a couple of parts of the HotSpot build > > just blithely ignore all this and set their own flags unconditionally. > > For example, they also set -m64 regardless of whether it was successfully > > tested for or not. > > > > I've added a patch to pass the std setting down to these parts of the > > HotSpot build again, but they more generally need to be brought in line > > with everything else and respect the configure checks. > > I think there are some more that are outside of HotSpot. > > Searching the build directory for *.o.cmdline files that don?t contain > -std=gnu++98, e.g. > > find . -name "*.o.cmdline" ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print > | xargs dirname | uniq > > produces a lot of stuff in ./support/native, the afore mentioned adlc, and a > smattering of others. > > I think those might be better addressed by more followups, to get what we?ve > got so far in. Thanks for the .cmdline trick. I wasn't aware of that. The -std=gnu++98 switch is only appropriate for the C++ compiler. Most of the support/native object files are C files. C++ code is used in the following: hotspot/variant-server/tools/adlc/objs hotspot/variant-server/libjvm/gtest/objs hotspot/variant-server/libjvm/gtest/launcher-objs hotspot/variant-server/libjvm/objs support/native/java.base/libjimage support/native/jdk.crypto.ec/libsunec support/native/java.desktop/libfontmanager support/native/jdk.pack200/unpackexe support/native/jdk.pack200/libunpack support/demos/native/jvmti/waiters Using find . -name "*.o.cmdline" -exec egrep -q -e "g\+\+" {} \; ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print I don't see any remaining files with the latest patch. snip... > >> common/autoconf/flags.m4 > >> 771 if test "x$1" = xTARGET; then > >> 772 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS > >> 773 else > >> 774 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS(BUILD_,$2) > >> 775 fi > >> > >> This is a fix for > >> https://bugs.openjdk.java.net/browse/JDK-8157358 > >> Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION > >> > >> I think the change I suggested in that CR is better. > >> > > > > I agree. I've reverted this part of my patch. I didn't realise it > > was already being worked on and it was getting in the way of working on > > this fix. I just went with the most local fix that got rid of the broken > > test invocations. > > I wasn't planning to work on any of this, but was feeling annoyed > about the situation, and then events conspired to leave me at loose > ends for a bit this weekend. Though if I'd remembered how much I > dislike autoconf, I might have looked harder for alternatives. > > But you will need that fix for JDK-8157358. I guess I should post an > RFR for it... or you can just incorporate it into this patch if I don?t get > that RFR done soon. I wasn't planning to either, but it was likewise bugging me when I was trying to fix the GCC 6 issue. Ironically, it took much longer to work out what was going on there than it did to realise I needed to add the flags to JVM_CFLAGS :( I've included the fix in this patch, assuming that's ok with you. > > >> common/autoconf/flags.m4 > >> 1470 $1CFLAGS_JDK="[$]$1CFLAGS_JDK ${NO_NULL_POINTER_CHECK_CFLAG} > >> ${NO_LIFETIME_DSE_CFLAG}" > >> 1471 $1JVM_CFLAGS="[$]$1JVM_CFLAGS ${NO_NULL_POINTER_CHECK_CFLAG} > >> ${NO_LIFETIME_DSE_CFLAG}" > >> > >> Adding the prefix to the CFLAGS variables is good. > >> > >> Since we've already determined we're using gcc6+ to get here, I don't > >> think there's any benefit to the pre-existing argument checks. > >> > >> More importantly, FLAGS_COMPILER_CHECK_ARGUMENTS doesn't account for > >> the BUILD / TARGET distinction, so may produce the wrong answer if the > >> build and target compilers are different versions of gcc. > >> > >> So I think those checks should be eliminated. > > > > As you may recall, these checks were originally called in all > > instances and we decided to limit it to GCC 6 or later in review. > > I still think keeping the checks is wise, as these options may > > not work with future compilers. If I was to eliminate anything, > > it would be the version check, but I realise HotSpot developers > > are pretty conservative about turning off these optimisations > > on existing builds. > > I'm much more worried about getting and using the wrong answer for > these options. Since we're already in a context where we're known to > be using gcc6+, we know we're not using a too-old compiler that > doesn't support them for that reason. > > -f[no-]delete-null-pointer-checks has been around since gcc 3.0, and > seems unlikely to go away, since it has a real documented purpose > (address zero isn't so special on some platforms). > > -f[no-]lifetime-dse is fairly new (introduced in gcc 4.9), so seems > unlikely to go away soon, and if it did we would want a build failure > anyway, at least until we've fixed the code that gets broken by that > optimization. > I see your concern; potentially, we could check that one compiler is >= GCC 6, but then run the argument checks on an older compiler. As a compromise, I've commented out the argument checks rather than removing them. I'm generally wary about trusting version checks alone rather than behaviour checks, and so I would prefer these were re-enabled when the macro is fixed. We've actually been quite lucky that the macro is only used for options which aren't enabled in every build at present (stack-protector for slowdebug, options for the Zero assembler port and the GCC 6 options). The Zero ones are particularly troublesome, because cross-compiling to a target using the Zero assembler port seems one of the most likely scenarios, as it allows a JDK to be built for a new target that doesn't yet have a boot JDK. Incidentally, both these flags are mentioned in the GCC 6 release notes [0]. snip... > > > I've had to bring back CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ for the renegade > > parts > > of the HotSpot build. > > > > New webrevs: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.03/root/ > > http://cr.openjdk.java.net/~andrew/8156980/webrev.03/hotspot/ > > ------------------------------------------------------------------------------ > hotspot/make/lib/CompileDtracePostJvm.gmk > 90 JVM_OFFSETS_CFLAGS := $(CXXSTD_CXXFLAG) -m64 > > This appears to be in a solaris-specific block, so I don't think this > change should be made. Ah, good catch. Removed. I was looking for CFLAGS that weren't using JVM_CFLAGS or CFLAGS_JDK and didn't check the full context on that one. > > ------------------------------------------------------------------------------ > hotspot/make/gensrc/GensrcAdlc.gmk > 54 # Set the C++ standard if supported > 55 ADLC_CFLAGS += $(CXXSTD_CXXFLAG) > > This appears to be in a platform-independent block; I think it needs > to be moved to a different location, probably the linux block starting > at line 37. I had it in the Linux block to begin with, but GCC is not specific to Linux. This distinction between toolchains and platforms is held in the main autotools code, but not in these Makefiles. From toolchain.gmk, it can be seen that gcc on MacOS X is also supported: # These toolchains are valid on different platforms VALID_TOOLCHAINS_linux="gcc clang" VALID_TOOLCHAINS_solaris="solstudio" VALID_TOOLCHAINS_macosx="gcc clang" VALID_TOOLCHAINS_aix="xlc" VALID_TOOLCHAINS_windows="microsoft" and there is the potential for gcc to be used on other platforms too (*BSD springs to mind). If gcc is not being used, CXXSTD_CXXFLAG won't be set so this should be a safe no-op. > > > Revised webrevs: http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot I'm also now seeing a problem with GCC 6 only that is unique to the latest OpenJDK 9 and what looks like the gtest code. It seems to be the result of the header changes also documented in [0] which were introduced in January [1] (and so probably weren't in earlier test versions of GCC 6). I'm able to work around it and get a completed build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be something to do with the changes to stdlib.h in GCC 6. Something for a separate bug. [0] https://gcc.gnu.org/gcc-6/porting_to.html [1] https://github.com/gcc-mirror/gcc/commit/6c8ced3f4f867b72a623fe2f23efa204c5786a28 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From dean.long at oracle.com Wed Jul 6 05:42:04 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 5 Jul 2016 22:42:04 -0700 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> Message-ID: <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> On 7/4/16 2:59 PM, David Holmes wrote: > On 5/07/2016 7:44 AM, Stefan Karlsson wrote: >> On 2016-07-04 23:03, David Holmes wrote: >>> On 5/07/2016 12:07 AM, Volker Simonis wrote: >>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley wrote: >>>>> On 04/07/16 12:22, David Holmes wrote: >>>>> >>>>>> Unless the files are included into more than one other file then >>>>>> adding >>>>>> a level of indirection doesn't really help anything. >>>>> >>>>> I'm not sure what this means. >>>>> >>>>>> But I don't see why the platform part of the name needs to be kept >>>>>> when >>>>>> it is already part of the path? >>>>> >>>>> When switching between files in an editor, one doesn't usually >>>>> type in the full path, but the filename. I'd be very sad to lose >>>>> that, and I think that unique filenames are a nice thing to have. >>>>> >>>> >>>> In Emacs you can try the uniquify [1] extension which would solve the >>>> problem. I already use it for editing various hotspot version (i.e. >>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is probably >>>> not a practical solution for everybody :) >>>> >>>> [1] >>>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify.html >>>> >>>> >>>>> Andrew. >>>>> >>>> >>>> We could try something like this (adapted from [2]) although I'm not >>>> sure if that's really a good solution (i.e. if it is treated right by >>>> various IDEs): >>>> >>>> include_test.cpp >>>> ============ >>>> >>>> #define xstr(x) #x >>>> #define str(x) xstr(x) >>>> #define sub(x) x >>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) >>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) >>>> #define os_cpu_header(x) str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) >>>> >>>> #include cpu_header(assembler) >>>> #include os_header(assembler) >>>> #include os_cpu_header(assembler) >>> >>> This is the parameterization I thought was not possible. For some >>> reason I thought #define'd values could not be used within #include >>> directives. >> >> FWIW, we tried a similar approach when includeDB was removed, but >> abandoned it because of the problem described below with the 'linux' >> define. > > Give we have in the build (eg for linux x86) presently: > > -DTARGET_OS_FAMILY_linux > -DTARGET_ARCH_MODEL_x86_32 > -DTARGET_ARCH_x86 > -DTARGET_OS_ARCH_MODEL_linux_x86_32 > -DTARGET_OS_ARCH_linux_x86 > > I wonder if we can simply replace the above with: > > -DTARGET_OS_FAMILY=linux > -DTARGET_ARCH_MODEL=x86_32 > -DTARGET_ARCH=x86 > -DTARGET_OS_ARCH_MODEL=linux_x86_32 > -DTARGET_OS_ARCH=linux_x86 > > and use those variables for the include directives? > I remember experimenting with that idea, but gave up because I couldn't get it work. What I ended up doing was something like this: #*include* C1_LIRGENERATOR_MD_HPP where, using x86 as an example, macros like C1_LIRGENERATOR_MD_HPP are defined inglobalDefinitions_x86.hpp: #define *C1_LIRGENERATOR_MD_HPP* "c1_LIRGenerator_x86.hpp" I don't know if this confuses IDEs or not. dl > David > >> StefanK >> >>> >>> This looks very workable to me. >>> >>> Thanks, >>> David >>> >>>> assembler_s390x.hpp >>>> ================ >>>> #pragma message ("including \"assembler_s390x.h\"") >>>> >>>> assembler_linux.hpp >>>> =============== >>>> #pragma message ("including \"assembler_linux.h\"") >>>> >>>> assembler_linux_s390x.hpp >>>> ==================== >>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>> >>>> >>>> It works on all the platforms I have tested so far (see below) except >>>> Linux where it needs some tweaks (see comments below): >>>> >>>> >>>> Solaris: >>>> ====== >>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E include_test.cpp >>>> #1 "include_test.cpp" >>>> #1 "assembler_s390x.hpp" >>>> #pragma message ( "including \"assembler_s390x.h\"" ) >>>> #1 "assembler_linux.hpp" >>>> #pragma message ( "including \"assembler_linux.h\"" ) >>>> #1 "assembler_linux_s390x.hpp" >>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) >>>> >>>> AIX: >>>> === >>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c >>>> include_test.cpp >>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>>> message" is specified. >>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>>> message" is specified. >>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >>>> "pragma message" is specified. >>>> >>>> MacOS X >>>> ======= >>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>> In file included from include_test.cpp:8: >>>> ./assembler_s390x.hpp:1:9: warning: including "assembler_s390x.h" >>>> [-W#pragma-messages] >>>> #pragma message ("including \"assembler_s390x.h\"") >>>> ^ >>>> In file included from include_test.cpp:9: >>>> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" >>>> [-W#pragma-messages] >>>> #pragma message ("including \"assembler_linux.h\"") >>>> ^ >>>> In file included from include_test.cpp:10: >>>> ./assembler_linux_s390x.hpp:1:9: warning: including >>>> "assembler_linux_s390x.h" [-W#pragma-messages] >>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>> ^ >>>> 3 warnings generated. >>>> >>>> Windows: >>>> ======= >>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x >>>> -DOS=linux -c include_test. >>>> cpp >>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 >>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>> >>>> include_test.cpp >>>> including "assembler_s390x.h" >>>> including "assembler_linux.h" >>>> including "assembler_linux_s390x.h" >>>> >>>> HPUX: >>>> ===== >>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp >>>> Info #4087-D: "including \"assembler_s390x.h\"" >>>> >>>> Info #4087-D: "including \"assembler_linux.h\"" >>>> >>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" >>>> >>>> Linux: >>>> ===== >>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or >>>> directory >>>> compilation terminated. >>>> >>>> The problem on Linux is that 'linux' is already predefined to '1' but >>>> that could be easily fixed for example by slightly changing the name >>>> or by adding the underscore to the definiton of the OS macro (i.e. >>>> -DOS=_linux). >>>> >>>> As I said, I'm still not sure if this looks nice? I just wanted to >>>> post my findings for discussion :) >>>> >>>> Regards, >>>> Volker >>>> >>>> [2] >>>> http://stackoverflow.com/questions/1852652/how-can-i-include-a-file-whose-name-is-built-up-from-a-macro >>>> >>>> >>>> >> From dean.long at oracle.com Wed Jul 6 05:48:53 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 5 Jul 2016 22:48:53 -0700 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> Message-ID: <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> On 7/5/16 10:42 PM, dean.long at oracle.com wrote: > On 7/4/16 2:59 PM, David Holmes wrote: > >> On 5/07/2016 7:44 AM, Stefan Karlsson wrote: >>> On 2016-07-04 23:03, David Holmes wrote: >>>> On 5/07/2016 12:07 AM, Volker Simonis wrote: >>>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley wrote: >>>>>> On 04/07/16 12:22, David Holmes wrote: >>>>>> >>>>>>> Unless the files are included into more than one other file then >>>>>>> adding >>>>>>> a level of indirection doesn't really help anything. >>>>>> >>>>>> I'm not sure what this means. >>>>>> >>>>>>> But I don't see why the platform part of the name needs to be kept >>>>>>> when >>>>>>> it is already part of the path? >>>>>> >>>>>> When switching between files in an editor, one doesn't usually >>>>>> type in the full path, but the filename. I'd be very sad to lose >>>>>> that, and I think that unique filenames are a nice thing to have. >>>>>> >>>>> >>>>> In Emacs you can try the uniquify [1] extension which would solve the >>>>> problem. I already use it for editing various hotspot version (i.e. >>>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is probably >>>>> not a practical solution for everybody :) >>>>> >>>>> [1] >>>>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify.html >>>>> >>>>> >>>>>> Andrew. >>>>>> >>>>> >>>>> We could try something like this (adapted from [2]) although I'm not >>>>> sure if that's really a good solution (i.e. if it is treated right by >>>>> various IDEs): >>>>> >>>>> include_test.cpp >>>>> ============ >>>>> >>>>> #define xstr(x) #x >>>>> #define str(x) xstr(x) >>>>> #define sub(x) x >>>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) >>>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) >>>>> #define os_cpu_header(x) str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) >>>>> >>>>> #include cpu_header(assembler) >>>>> #include os_header(assembler) >>>>> #include os_cpu_header(assembler) >>>> >>>> This is the parameterization I thought was not possible. For some >>>> reason I thought #define'd values could not be used within #include >>>> directives. >>> >>> FWIW, we tried a similar approach when includeDB was removed, but >>> abandoned it because of the problem described below with the 'linux' >>> define. >> >> Give we have in the build (eg for linux x86) presently: >> >> -DTARGET_OS_FAMILY_linux >> -DTARGET_ARCH_MODEL_x86_32 >> -DTARGET_ARCH_x86 >> -DTARGET_OS_ARCH_MODEL_linux_x86_32 >> -DTARGET_OS_ARCH_linux_x86 >> >> I wonder if we can simply replace the above with: >> >> -DTARGET_OS_FAMILY=linux >> -DTARGET_ARCH_MODEL=x86_32 >> -DTARGET_ARCH=x86 >> -DTARGET_OS_ARCH_MODEL=linux_x86_32 >> -DTARGET_OS_ARCH=linux_x86 >> >> and use those variables for the include directives? >> > > I remember experimenting with that idea, but gave up because I > couldn't get it work. > What I ended up doing was something like this: > > #*include* C1_LIRGENERATOR_MD_HPP > Oops, let's try that again: #include C1_LIRGENERATOR_MD_HPP where, using x86 as an example, macros like C1_LIRGENERATOR_MD_HPP are defined in globalDefinitions_x86.hpp: #define C1_LIRGENERATOR_MD_HPP "c1_LIRGenerator_x86.hpp" dl > I don't know if this confuses IDEs or not. > > dl > >> David >> >>> StefanK >>> >>>> >>>> This looks very workable to me. >>>> >>>> Thanks, >>>> David >>>> >>>>> assembler_s390x.hpp >>>>> ================ >>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>> >>>>> assembler_linux.hpp >>>>> =============== >>>>> #pragma message ("including \"assembler_linux.h\"") >>>>> >>>>> assembler_linux_s390x.hpp >>>>> ==================== >>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>> >>>>> >>>>> It works on all the platforms I have tested so far (see below) except >>>>> Linux where it needs some tweaks (see comments below): >>>>> >>>>> >>>>> Solaris: >>>>> ====== >>>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E include_test.cpp >>>>> #1 "include_test.cpp" >>>>> #1 "assembler_s390x.hpp" >>>>> #pragma message ( "including \"assembler_s390x.h\"" ) >>>>> #1 "assembler_linux.hpp" >>>>> #pragma message ( "including \"assembler_linux.h\"" ) >>>>> #1 "assembler_linux_s390x.hpp" >>>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) >>>>> >>>>> AIX: >>>>> === >>>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c >>>>> include_test.cpp >>>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>>>> message" is specified. >>>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>>>> message" is specified. >>>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >>>>> "pragma message" is specified. >>>>> >>>>> MacOS X >>>>> ======= >>>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>> In file included from include_test.cpp:8: >>>>> ./assembler_s390x.hpp:1:9: warning: including "assembler_s390x.h" >>>>> [-W#pragma-messages] >>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>> ^ >>>>> In file included from include_test.cpp:9: >>>>> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" >>>>> [-W#pragma-messages] >>>>> #pragma message ("including \"assembler_linux.h\"") >>>>> ^ >>>>> In file included from include_test.cpp:10: >>>>> ./assembler_linux_s390x.hpp:1:9: warning: including >>>>> "assembler_linux_s390x.h" [-W#pragma-messages] >>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>> ^ >>>>> 3 warnings generated. >>>>> >>>>> Windows: >>>>> ======= >>>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x >>>>> -DOS=linux -c include_test. >>>>> cpp >>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for >>>>> x64 >>>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>>> >>>>> include_test.cpp >>>>> including "assembler_s390x.h" >>>>> including "assembler_linux.h" >>>>> including "assembler_linux_s390x.h" >>>>> >>>>> HPUX: >>>>> ===== >>>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp >>>>> Info #4087-D: "including \"assembler_s390x.h\"" >>>>> >>>>> Info #4087-D: "including \"assembler_linux.h\"" >>>>> >>>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" >>>>> >>>>> Linux: >>>>> ===== >>>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or >>>>> directory >>>>> compilation terminated. >>>>> >>>>> The problem on Linux is that 'linux' is already predefined to '1' but >>>>> that could be easily fixed for example by slightly changing the name >>>>> or by adding the underscore to the definiton of the OS macro (i.e. >>>>> -DOS=_linux). >>>>> >>>>> As I said, I'm still not sure if this looks nice? I just wanted to >>>>> post my findings for discussion :) >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> [2] >>>>> http://stackoverflow.com/questions/1852652/how-can-i-include-a-file-whose-name-is-built-up-from-a-macro >>>>> >>>>> >>>>> >>> > From aph at redhat.com Wed Jul 6 11:01:10 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jul 2016 12:01:10 +0100 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> Message-ID: <577CE4F6.3050608@redhat.com> I'm baffled by @ForceInline public final float compareAndExchangeFloatAcquire(Object o, long offset, float expected, float x) { int w = compareAndExchangeIntVolatile(o, offset, Float.floatToRawIntBits(expected), Float.floatToRawIntBits(x)); return Float.intBitsToFloat(w); } Why does it use compareAndExchangeIntVolatile? It's a minor inefficiency, but it does generate an unnecessary write fence on a machine with relaxed memory consistency. Andrew. From aph at redhat.com Wed Jul 6 12:23:45 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jul 2016 13:23:45 +0100 Subject: RFR: 8141633: Implement VarHandles/Unsafe intrinsics on AArch64 Message-ID: <577CF851.80206@redhat.com> http://cr.openjdk.java.net/~aph/8141633-1/ Andrew Dinn: I haven't done the rewrite rules to get rid of the unnecessary fences. Every possible combination of acquire/release/ volatile is required, so we'd have to decode the various fences and convert them into ld{a}xr, st{l}xr. It'd be nice to get this done, but perhaps not the highest priority. Thanks, Andrew. From paul.sandoz at oracle.com Wed Jul 6 12:27:20 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Jul 2016 14:27:20 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <577CE4F6.3050608@redhat.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <577CE4F6.3050608@redhat.com> Message-ID: <713F1244-5213-4F44-84ED-59085848B57D@oracle.com> > On 6 Jul 2016, at 13:01, Andrew Haley wrote: > > I'm baffled by > > @ForceInline > public final float compareAndExchangeFloatAcquire(Object o, long offset, > float expected, > float x) { > int w = compareAndExchangeIntVolatile(o, offset, > Float.floatToRawIntBits(expected), > Float.floatToRawIntBits(x)); > return Float.intBitsToFloat(w); > } > > Why does it use compareAndExchangeIntVolatile? It's a minor > inefficiency, but it does generate an unnecessary write fence on a > machine with relaxed memory consistency. > Opps, that?s an oversight (probably a copy/paste one, since the other methods are as expected). Thanks for noticing that. I?ll fix once the changes get integrated into jdk9/dev (which i hope should occur soon). https://bugs.openjdk.java.net/browse/JDK-8160885 Paul. From aph at redhat.com Wed Jul 6 12:33:47 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jul 2016 13:33:47 +0100 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <713F1244-5213-4F44-84ED-59085848B57D@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <577CE4F6.3050608@redhat.com> <713F1244-5213-4F44-84ED-59085848B57D@oracle.com> Message-ID: <577CFAAB.4000308@redhat.com> On 06/07/16 13:27, Paul Sandoz wrote: > Opps, that?s an oversight (probably a copy/paste one, since the other methods are as expected). Thanks for noticing that. The same bug is in Double. I guess you'll check them all. Thanks, Andrew. From aph at redhat.com Wed Jul 6 12:34:58 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jul 2016 13:34:58 +0100 Subject: RFR: 8141633: Implement VarHandles/Unsafe intrinsics on AArch64 In-Reply-To: References: <577CF851.80206@redhat.com> Message-ID: <577CFAF2.4030702@redhat.com> On 06/07/16 13:32, Andrej Golovnin wrote: > Hi Andrew, > > src/cpu/aarch64/vm/macroAssembler_aarch64.cpp > > 2144 // A generic CAS; success or failure is in the EQ flag. > 2145 // A generic CAS; success or failure is in the EQ flag. A weak CAS > > I think the line 2144 can be removed. Oh bah, merge error. Will fix. I'll wait for any more comments. Thanks, Andrew. From Alan.Burlison at oracle.com Wed Jul 6 13:15:37 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 6 Jul 2016 14:15:37 +0100 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> Message-ID: <577D0479.1070907@oracle.com> On 01/07/2016 21:40, Kim Barrett wrote: >> Vote: Use JDK-8160350 to fix Solaris and file a new bug for the >> larger cross-platform issues. >> >> Dan > > That seems like the right approach to me as well. I've logged https://bugs.openjdk.java.net/browse/JDK-8160887 and linked it to JDK-8160350. For JDK-8160350 I have rolled back to version 1 of the patch which just fixes the Solaris truss issue and have prepared a new webrev which I'll get uploaded shortly. I've also run it through the hotspot testset, all tests pass. -- Alan Burlison -- From paul.sandoz at oracle.com Wed Jul 6 13:19:42 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Jul 2016 15:19:42 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <577CFAAB.4000308@redhat.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <577CE4F6.3050608@redhat.com> <713F1244-5213-4F44-84ED-59085848B57D@oracle.com> <577CFAAB.4000308@redhat.com> Message-ID: <2F54C926-83D7-449B-8BD2-6DCA80AEC10A@oracle.com> > On 6 Jul 2016, at 14:33, Andrew Haley wrote: > > On 06/07/16 13:27, Paul Sandoz wrote: >> Opps, that?s an oversight (probably a copy/paste one, since the other methods are as expected). Thanks for noticing that. > > The same bug is in Double. Yes, i made note that in the bug so i don?t forget. > I guess you'll check them all. > Indeed, already have :-) Thanks, Paul. From coleen.phillimore at oracle.com Wed Jul 6 14:30:03 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 6 Jul 2016 10:30:03 -0400 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <577D0479.1070907@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> Message-ID: <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> I uploaded it here: http://cr.openjdk.java.net/~coleenp/JDK-8160350.02/index.html Coleen On 7/6/16 9:15 AM, Alan Burlison wrote: > On 01/07/2016 21:40, Kim Barrett wrote: > >>> Vote: Use JDK-8160350 to fix Solaris and file a new bug for the >>> larger cross-platform issues. >>> >>> Dan >> >> That seems like the right approach to me as well. > > I've logged https://bugs.openjdk.java.net/browse/JDK-8160887 and > linked it to JDK-8160350. For JDK-8160350 I have rolled back to > version 1 of the patch which just fixes the Solaris truss issue and > have prepared a new webrev which I'll get uploaded shortly. I've also > run it through the hotspot testset, all tests pass. > From gerard.ziemski at oracle.com Wed Jul 6 15:09:25 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 6 Jul 2016 10:09:25 -0500 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: hi Jesper, I?m currently in the process of reviewing your change. Can you help me and provide me with a test case, where a command line option is later overridden by ergonomic code (ie. where we see ?command line,? followed by different origin in the output)? cheers > On Jun 29, 2016, at 11:55 AM, Jesper Wilhelmsson wrote: > > After some more testing I made a few smaller updates: > > * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() > Looking at other code, it seemed to be the right thing to do. > > * Using size_t instead of int for the size and used counter in Flag::print_kind_and_origin() > Windows compiler complained. > > * ORIG_COMMAND_LINE = 1 << 19 > > * Fixed some tests that was surprised by the new output from PrintFlagsFinal. > > New webrev: > http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ > > Thanks, > /Jesper > > > Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>> why you skipped 19?: >>> >>> ORIG_COMMAND_LINE = 1 << 20, >> >> No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a >> kind. I can change it to 19 if you think that's better. >> >>> >>> Otherwise looks good. >> >> Thanks for reviewing! >> >> /Jesper >> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>> >>>>> >>>>> I agree with Vladimir. There's no way I'm going to remember that a colon >>>>> mean that the value was changed. >>>> The colon is what we have today to indicate that a value was changed :) >>>> >>>> I made a different solution in which I explicitly print the origin with words. >>>> To make it look better I changed the >>>> printing routine somewhat. The origin is currently at the end of the line. >>>> This version will also print other origins like config file, environment, and >>>> management as suggested by Dan. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>> >>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>> >>>> This is the new version: >>>> >>>> ccstr AbortVMOnExceptionMessage = >>>> {diagnostic} {default} >>>> uintx AdaptiveSizeDecrementScaleFactor = >>>> 4 {product} {default} >>>> intx AliasLevel = >>>> 3 {C2 product} {default} >>>> intx CMSAbortablePrecleanWaitMillis = >>>> 100 {manageable} {default} >>>> bool CMSClassUnloadingEnabled = >>>> false {product} {command line} >>>> intx ConditionalMoveLimit = >>>> 3 {C2 pd product} {default} >>>> size_t InitialHeapSize = >>>> 134217728 {product} {ergonomic} >>>> size_t MaxMetaspaceSize = >>>> 18446744073709547520 {product} {default} >>>> size_t NewSize = >>>> 1966080 {product} {command line, >>>> ergonomic} >>>> ccstrlist OnError = {product} {default} >>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>> -1 {develop} {default} >>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>> true {product} {default} >>>> bool UseCISCSpill = >>>> true {C2 pd develop} {default} >>>> bool UseCLMUL = >>>> true {ARCH product} {default} >>>> bool UseCompressedOops = >>>> true {lp64_product} {ergonomic} >>>> bool UseConcMarkSweepGC = >>>> true {product} {command line} >>>> >>>> This is the old (current) version: >>>> >>>> ccstr AbortVMOnExceptionMessage = >>>> {diagnostic} >>>> uintx AdaptiveSizeDecrementScaleFactor = >>>> 4 {product} >>>> intx AliasLevel = >>>> 3 {C2 product} >>>> intx CMSAbortablePrecleanWaitMillis = >>>> 100 {manageable} >>>> bool CMSClassUnloadingEnabled := >>>> false {product} >>>> intx ConditionalMoveLimit = >>>> 3 {C2 pd product} >>>> size_t InitialHeapSize := >>>> 134217728 {product} >>>> size_t MaxMetaspaceSize = >>>> 18446744073709547520 {product} >>>> size_t NewSize := >>>> 1966080 {product} >>>> ccstrlist OnError = {product} >>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>> -1 {develop} >>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>> true {product} >>>> bool UseCISCSpill = >>>> true {C2 pd develop} >>>> bool UseCompressedOops := >>>> true {lp64_product} >>>> bool UseConcMarkSweepGC := >>>> true {product} >>>> >>>> /Jesper >>>> >>>>> Coleen >>>>> >>>>> >>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>> Nobody will remember the meaning of such marking. You should use normal words. >>>>>> The output already have flag's type as, for example, "{C2 product}". You can >>>>>> add an other word there to indicate type >>>>>> of initialization: default|command|ergo. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>>>> flags changed on the command line and flags >>>>>>> changed by the ergonomics. >>>>>>> >>>>>>> To enable us to remember if a flag was set on the command line or not after >>>>>>> having been changed by the ergonomics I use >>>>>>> another bit in the Flag struct. >>>>>>> >>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>>>> and I'm open to suggestions (bike sheding) >>>>>>> about how to visualize this the best. >>>>>>> >>>>>>> The old decorations are: >>>>>>> >>>>>>> ' =' - Default value (no decoration) >>>>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>>>> >>>>>>> The new decorations are: >>>>>>> >>>>>>> ' =' - Default value (no decoration) >>>>>>> ':=' - Set on the command line >>>>>>> '?=' - Changed by the ergonomics >>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>>>> config file >>>>>>> >>>>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>>>> solid assignment and will therefore represent >>>>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>>>> seems appropriate. '!=' because you'd >>>>>>> want to >>>>>>> know that the ergonomics changed a value you had set on the command line. >>>>>>> >>>>>>> Another option could be to use a colon ':=' for the command line, and a >>>>>>> comma ',=' for the ergonomics. That would >>>>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>>>> and changed by the ergonomics. I didn't go >>>>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>>>> each other. >>>>>>> >>>>>>> As mentioned above there are other origins, the enum contains eight values. >>>>>>> There is no mention of the other types in >>>>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>>>> they didn't seem as important. If the general >>>>>>> opinion is that these other origins are as important, or we might as >>>>>>> well..., I'd suggest that we use letters as >>>>>>> decorations. Let me know if you have an opinion. >>>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Jesper >>>>> >>>> From jesper.wilhelmsson at oracle.com Wed Jul 6 15:22:09 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 6 Jul 2016 17:22:09 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: Den 6/7/16 kl. 17:09, skrev Gerard Ziemski: > hi Jesper, > > I?m currently in the process of reviewing your change. Thanks! > > Can you help me and provide me with a test case, where a command line option is later overridden by ergonomic code (ie. where we see ?command line,? followed by different origin in the output)? The two compiler tests that I change in this patch both exhibit this behavior. If you want something to test on the command line you can set some heap flag to an unaligned value for instance: $ java -XX:+PrintFlagsFinal -XX:InitialHeapSize=3000000 -version size_t InitialHeapSize = 4194304 {product} {command line, ergonomic} Thanks, /Jesper > > > cheers > >> On Jun 29, 2016, at 11:55 AM, Jesper Wilhelmsson wrote: >> >> After some more testing I made a few smaller updates: >> >> * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() >> Looking at other code, it seemed to be the right thing to do. >> >> * Using size_t instead of int for the size and used counter in Flag::print_kind_and_origin() >> Windows compiler complained. >> >> * ORIG_COMMAND_LINE = 1 << 19 >> >> * Fixed some tests that was surprised by the new output from PrintFlagsFinal. >> >> New webrev: >> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ >> >> Thanks, >> /Jesper >> >> >> Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >>> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>>> why you skipped 19?: >>>> >>>> ORIG_COMMAND_LINE = 1 << 20, >>> >>> No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a >>> kind. I can change it to 19 if you think that's better. >>> >>>> >>>> Otherwise looks good. >>> >>> Thanks for reviewing! >>> >>> /Jesper >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>>> >>>>>> >>>>>> I agree with Vladimir. There's no way I'm going to remember that a colon >>>>>> mean that the value was changed. >>>>> The colon is what we have today to indicate that a value was changed :) >>>>> >>>>> I made a different solution in which I explicitly print the origin with words. >>>>> To make it look better I changed the >>>>> printing routine somewhat. The origin is currently at the end of the line. >>>>> This version will also print other origins like config file, environment, and >>>>> management as suggested by Dan. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>>> >>>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>>> >>>>> This is the new version: >>>>> >>>>> ccstr AbortVMOnExceptionMessage = >>>>> {diagnostic} {default} >>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>> 4 {product} {default} >>>>> intx AliasLevel = >>>>> 3 {C2 product} {default} >>>>> intx CMSAbortablePrecleanWaitMillis = >>>>> 100 {manageable} {default} >>>>> bool CMSClassUnloadingEnabled = >>>>> false {product} {command line} >>>>> intx ConditionalMoveLimit = >>>>> 3 {C2 pd product} {default} >>>>> size_t InitialHeapSize = >>>>> 134217728 {product} {ergonomic} >>>>> size_t MaxMetaspaceSize = >>>>> 18446744073709547520 {product} {default} >>>>> size_t NewSize = >>>>> 1966080 {product} {command line, >>>>> ergonomic} >>>>> ccstrlist OnError = {product} {default} >>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>> -1 {develop} {default} >>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>> true {product} {default} >>>>> bool UseCISCSpill = >>>>> true {C2 pd develop} {default} >>>>> bool UseCLMUL = >>>>> true {ARCH product} {default} >>>>> bool UseCompressedOops = >>>>> true {lp64_product} {ergonomic} >>>>> bool UseConcMarkSweepGC = >>>>> true {product} {command line} >>>>> >>>>> This is the old (current) version: >>>>> >>>>> ccstr AbortVMOnExceptionMessage = >>>>> {diagnostic} >>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>> 4 {product} >>>>> intx AliasLevel = >>>>> 3 {C2 product} >>>>> intx CMSAbortablePrecleanWaitMillis = >>>>> 100 {manageable} >>>>> bool CMSClassUnloadingEnabled := >>>>> false {product} >>>>> intx ConditionalMoveLimit = >>>>> 3 {C2 pd product} >>>>> size_t InitialHeapSize := >>>>> 134217728 {product} >>>>> size_t MaxMetaspaceSize = >>>>> 18446744073709547520 {product} >>>>> size_t NewSize := >>>>> 1966080 {product} >>>>> ccstrlist OnError = {product} >>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>> -1 {develop} >>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>> true {product} >>>>> bool UseCISCSpill = >>>>> true {C2 pd develop} >>>>> bool UseCompressedOops := >>>>> true {lp64_product} >>>>> bool UseConcMarkSweepGC := >>>>> true {product} >>>>> >>>>> /Jesper >>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>>> Nobody will remember the meaning of such marking. You should use normal words. >>>>>>> The output already have flag's type as, for example, "{C2 product}". You can >>>>>>> add an other word there to indicate type >>>>>>> of initialization: default|command|ergo. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>>>>> flags changed on the command line and flags >>>>>>>> changed by the ergonomics. >>>>>>>> >>>>>>>> To enable us to remember if a flag was set on the command line or not after >>>>>>>> having been changed by the ergonomics I use >>>>>>>> another bit in the Flag struct. >>>>>>>> >>>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>>>>> and I'm open to suggestions (bike sheding) >>>>>>>> about how to visualize this the best. >>>>>>>> >>>>>>>> The old decorations are: >>>>>>>> >>>>>>>> ' =' - Default value (no decoration) >>>>>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>>>>> >>>>>>>> The new decorations are: >>>>>>>> >>>>>>>> ' =' - Default value (no decoration) >>>>>>>> ':=' - Set on the command line >>>>>>>> '?=' - Changed by the ergonomics >>>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>>>>> config file >>>>>>>> >>>>>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>>>>> solid assignment and will therefore represent >>>>>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>>>>> seems appropriate. '!=' because you'd >>>>>>>> want to >>>>>>>> know that the ergonomics changed a value you had set on the command line. >>>>>>>> >>>>>>>> Another option could be to use a colon ':=' for the command line, and a >>>>>>>> comma ',=' for the ergonomics. That would >>>>>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>>>>> and changed by the ergonomics. I didn't go >>>>>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>>>>> each other. >>>>>>>> >>>>>>>> As mentioned above there are other origins, the enum contains eight values. >>>>>>>> There is no mention of the other types in >>>>>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>>>>> they didn't seem as important. If the general >>>>>>>> opinion is that these other origins are as important, or we might as >>>>>>>> well..., I'd suggest that we use letters as >>>>>>>> decorations. Let me know if you have an opinion. >>>>>>>> >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Jesper >>>>>> >>>>> > From adinn at redhat.com Wed Jul 6 15:59:17 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 6 Jul 2016 16:59:17 +0100 Subject: RFR: 8141633: Implement VarHandles/Unsafe intrinsics on AArch64 In-Reply-To: <577CF851.80206@redhat.com> References: <577CF851.80206@redhat.com> Message-ID: <577D2AD5.6080804@redhat.com> On 06/07/16 13:23, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8141633-1/ > > Andrew Dinn: I haven't done the rewrite rules to get rid of the > unnecessary fences. Every possible combination of acquire/release/ > volatile is required, so we'd have to decode the various fences and > convert them into ld{a}xr, st{l}xr. It'd be nice to get this done, > but perhaps not the highest priority. The current patch looks good to me. I don't think it will be too hard to tweak this to use the correct acquire/release semantics. I'll take a look at that and propose it as a follow-up. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From boris.molodenkov at oracle.com Wed Jul 6 16:06:30 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Wed, 6 Jul 2016 19:06:30 +0300 Subject: RFR(XS): 8160119: Utils.tryFindJvmPid sometimes find incorrect pid In-Reply-To: <57766135.9060109@oracle.com> References: <57754B8C.5040801@oracle.com> <57766135.9060109@oracle.com> Message-ID: <577D2C86.3070204@oracle.com> Simplified regex according to Igor's comment. "^([0-9]+)\\s.*(" + key + ").*$" -> "^([0-9]+)\\s.*(" + key + ")" Updated webrev: http://cr.openjdk.java.net/~bmoloden/8160119/webrev.02/ Thanks, Boris On 01.07.2016 15:25, Boris Molodenkov wrote: > Hi David, > > Thank you for comment. > Copyright was updated. Typo was fixed. > > I updated webrev because want to have complete webrev for 8u backporting. > http://cr.openjdk.java.net/~bmoloden/8160119/webrev.01 > > Thanks, > Boris > > On 01.07.2016 06:22, David Holmes wrote: >> Hi Boris, >> >> On 1/07/2016 2:40 AM, Boris Molodenkov wrote: >>> Hi All, >>> >>> Could you please review fix? >>> >>> Utils.tryFindJvmPid incorrectly determines process id from jcmd output >>> if line which contains desired PID is just after line which ends with >>> numbers. >>> Fixed pattern. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8160119 >>> Webrev: http://cr.openjdk.java.net/~bmoloden/8160119/webrev.00 >> >> I'm no regex expert but that revised pattern seems good to me - it >> constrains the pattern to a line at a time, with only starting digits >> allowed. >> >> Can you fix the typo in the comment preceding that line please - >> follwed. >> >> Also copyright year needs updating. >> >> No need for updated webrev. >> >> Thanks, >> David >> >>> Thanks, >>> Boris >>> > From andrej.golovnin at gmail.com Wed Jul 6 12:32:49 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 6 Jul 2016 14:32:49 +0200 Subject: RFR: 8141633: Implement VarHandles/Unsafe intrinsics on AArch64 In-Reply-To: <577CF851.80206@redhat.com> References: <577CF851.80206@redhat.com> Message-ID: Hi Andrew, src/cpu/aarch64/vm/macroAssembler_aarch64.cpp 2144 // A generic CAS; success or failure is in the EQ flag. 2145 // A generic CAS; success or failure is in the EQ flag. A weak CAS I think the line 2144 can be removed. Best regards, Andrej Golovnin From igor.ignatyev at oracle.com Wed Jul 6 16:32:31 2016 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Wed, 06 Jul 2016 19:32:31 +0300 Subject: =?utf-8?B?UmU6IFJGUihYUyk6IDgxNjAxMTk6IFV0aWxzLnRyeUZpbmRKdm1QaWQgc29tZXRp?= =?utf-8?B?bWVzIGZpbmQgaW5jb3JyZWN0IHBpZA==?= Message-ID: <201607061632.u66GWSbI004281@userv0122.oracle.com> Boris, Looks good to me. Thanks -- II ----- Reply message ----- From: "Boris Molodenkov" To: "David Holmes" , , "Igor Ignatyev" Subject: RFR(XS): 8160119: Utils.tryFindJvmPid sometimes find incorrect pid Date: Wed, Jul 6, 2016 19:06 Simplified regex according to Igor's comment. "^([0-9]+)\\s.*(" + key + ").*$" -> "^([0-9]+)\\s.*(" + key + ")" Updated webrev: http://cr.openjdk.java.net/~bmoloden/8160119/webrev.02/ Thanks, Boris On 01.07.2016 15:25, Boris Molodenkov wrote: > Hi David, > > Thank you for comment. > Copyright was updated. Typo was fixed. > > I updated webrev because want to have complete webrev for 8u backporting. > http://cr.openjdk.java.net/~bmoloden/8160119/webrev.01 > > Thanks, > Boris > > On 01.07.2016 06:22, David Holmes wrote: >> Hi Boris, >> >> On 1/07/2016 2:40 AM, Boris Molodenkov wrote: >>> Hi All, >>> >>> Could you please review fix? >>> >>> Utils.tryFindJvmPid incorrectly determines process id from jcmd output >>> if line which contains desired PID is just after line which ends with >>> numbers. >>> Fixed pattern. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8160119 >>> Webrev: http://cr.openjdk.java.net/~bmoloden/8160119/webrev.00 >> >> I'm no regex expert but that revised pattern seems good to me - it >> constrains the pattern to a line at a time, with only starting digits >> allowed. >> >> Can you fix the typo in the comment preceding that line please - >> follwed. >> >> Also copyright year needs updating. >> >> No need for updated webrev. >> >> Thanks, >> David >> >>> Thanks, >>> Boris >>> > From gerard.ziemski at oracle.com Wed Jul 6 17:17:15 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 6 Jul 2016 12:17:15 -0500 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: hi Jesper, I really like the new output - very good job, but have a few feedbacks regarding the implemention: # 1 This point is just my opinion: In general, whouldn't it have been easier, from the implementation point of view, to add a new "bool" field tracking whether the "command line" was overriden? Tacking the "original command line" bit, though clever, in the Flag.Flags enum seems to have complicated the code handling that field quite a bit with numerous modifications of existing code required. # 2 1 void Flag::set_origin(Flags origin) { 2 assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); 3 origin = (origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin; 4 _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | origin); 5 } I don't like that the assert on line 2 - it is immediately invalidated on line 3. With an addition of "bool" field as I pointed out in feedback #1, this wouldn't be an issue. # 3 The names of functions don't quite match what we are doing, ex: bool Flag::is_command_line() should be perhaps renamed as: bool Flag::is_orig_command_line() ? Similar for "Flag::set_command_line()" and "CommandLineFlagsEx::setOnCmdLine()" Here we're not using the "COMMAND_LINE" value, but "ORIG_COMMAND_LINE" instead. # 4 Trivial issue - shouldn't the assert: // Size - 2 here because we want to fit } and \0 in there as well. assert(buffer_used < (buffer_size - 2), "Too small buffer"); be applied right before: jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}"); ie, taken outside the "for (int i = 0; data[i].flag != -1; i++)" loop? cheers > On Jun 29, 2016, at 11:55 AM, Jesper Wilhelmsson wrote: > > After some more testing I made a few smaller updates: > > * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() > Looking at other code, it seemed to be the right thing to do. > > * Using size_t instead of int for the size and used counter in Flag::print_kind_and_origin() > Windows compiler complained. > > * ORIG_COMMAND_LINE = 1 << 19 > > * Fixed some tests that was surprised by the new output from PrintFlagsFinal. > > New webrev: > http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ > > Thanks, > /Jesper > > > Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>> why you skipped 19?: >>> >>> ORIG_COMMAND_LINE = 1 << 20, >> >> No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a >> kind. I can change it to 19 if you think that's better. >> >>> >>> Otherwise looks good. >> >> Thanks for reviewing! >> >> /Jesper >> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>> >>>>> >>>>> I agree with Vladimir. There's no way I'm going to remember that a colon >>>>> mean that the value was changed. >>>> The colon is what we have today to indicate that a value was changed :) >>>> >>>> I made a different solution in which I explicitly print the origin with words. >>>> To make it look better I changed the >>>> printing routine somewhat. The origin is currently at the end of the line. >>>> This version will also print other origins like config file, environment, and >>>> management as suggested by Dan. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>> >>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>> >>>> This is the new version: >>>> >>>> ccstr AbortVMOnExceptionMessage = >>>> {diagnostic} {default} >>>> uintx AdaptiveSizeDecrementScaleFactor = >>>> 4 {product} {default} >>>> intx AliasLevel = >>>> 3 {C2 product} {default} >>>> intx CMSAbortablePrecleanWaitMillis = >>>> 100 {manageable} {default} >>>> bool CMSClassUnloadingEnabled = >>>> false {product} {command line} >>>> intx ConditionalMoveLimit = >>>> 3 {C2 pd product} {default} >>>> size_t InitialHeapSize = >>>> 134217728 {product} {ergonomic} >>>> size_t MaxMetaspaceSize = >>>> 18446744073709547520 {product} {default} >>>> size_t NewSize = >>>> 1966080 {product} {command line, >>>> ergonomic} >>>> ccstrlist OnError = {product} {default} >>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>> -1 {develop} {default} >>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>> true {product} {default} >>>> bool UseCISCSpill = >>>> true {C2 pd develop} {default} >>>> bool UseCLMUL = >>>> true {ARCH product} {default} >>>> bool UseCompressedOops = >>>> true {lp64_product} {ergonomic} >>>> bool UseConcMarkSweepGC = >>>> true {product} {command line} >>>> >>>> This is the old (current) version: >>>> >>>> ccstr AbortVMOnExceptionMessage = >>>> {diagnostic} >>>> uintx AdaptiveSizeDecrementScaleFactor = >>>> 4 {product} >>>> intx AliasLevel = >>>> 3 {C2 product} >>>> intx CMSAbortablePrecleanWaitMillis = >>>> 100 {manageable} >>>> bool CMSClassUnloadingEnabled := >>>> false {product} >>>> intx ConditionalMoveLimit = >>>> 3 {C2 pd product} >>>> size_t InitialHeapSize := >>>> 134217728 {product} >>>> size_t MaxMetaspaceSize = >>>> 18446744073709547520 {product} >>>> size_t NewSize := >>>> 1966080 {product} >>>> ccstrlist OnError = {product} >>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>> -1 {develop} >>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>> true {product} >>>> bool UseCISCSpill = >>>> true {C2 pd develop} >>>> bool UseCompressedOops := >>>> true {lp64_product} >>>> bool UseConcMarkSweepGC := >>>> true {product} >>>> >>>> /Jesper >>>> >>>>> Coleen >>>>> >>>>> >>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>> Nobody will remember the meaning of such marking. You should use normal words. >>>>>> The output already have flag's type as, for example, "{C2 product}". You can >>>>>> add an other word there to indicate type >>>>>> of initialization: default|command|ergo. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>>>> flags changed on the command line and flags >>>>>>> changed by the ergonomics. >>>>>>> >>>>>>> To enable us to remember if a flag was set on the command line or not after >>>>>>> having been changed by the ergonomics I use >>>>>>> another bit in the Flag struct. >>>>>>> >>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>>>> and I'm open to suggestions (bike sheding) >>>>>>> about how to visualize this the best. >>>>>>> >>>>>>> The old decorations are: >>>>>>> >>>>>>> ' =' - Default value (no decoration) >>>>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>>>> >>>>>>> The new decorations are: >>>>>>> >>>>>>> ' =' - Default value (no decoration) >>>>>>> ':=' - Set on the command line >>>>>>> '?=' - Changed by the ergonomics >>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>>>> config file >>>>>>> >>>>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>>>> solid assignment and will therefore represent >>>>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>>>> seems appropriate. '!=' because you'd >>>>>>> want to >>>>>>> know that the ergonomics changed a value you had set on the command line. >>>>>>> >>>>>>> Another option could be to use a colon ':=' for the command line, and a >>>>>>> comma ',=' for the ergonomics. That would >>>>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>>>> and changed by the ergonomics. I didn't go >>>>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>>>> each other. >>>>>>> >>>>>>> As mentioned above there are other origins, the enum contains eight values. >>>>>>> There is no mention of the other types in >>>>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>>>> they didn't seem as important. If the general >>>>>>> opinion is that these other origins are as important, or we might as >>>>>>> well..., I'd suggest that we use letters as >>>>>>> decorations. Let me know if you have an opinion. >>>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Jesper >>>>> >>>> From Alan.Burlison at oracle.com Wed Jul 6 17:33:38 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 6 Jul 2016 18:33:38 +0100 Subject: RFR(XS): 8160119: Utils.tryFindJvmPid sometimes find incorrect pid In-Reply-To: <577D2C86.3070204@oracle.com> References: <57754B8C.5040801@oracle.com> <57766135.9060109@oracle.com> <577D2C86.3070204@oracle.com> Message-ID: <577D40F2.8030508@oracle.com> On 06/07/2016 17:06, Boris Molodenkov wrote: > Simplified regex according to Igor's comment. > "^([0-9]+)\\s.*(" + key + ").*$" -> "^([0-9]+)\\s.*(" + key + ")" Or even: ^(\\d+)\\s.*(" + key + ") -- Alan Burlison -- From daniel.daugherty at oracle.com Wed Jul 6 17:45:52 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Jul 2016 11:45:52 -0600 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> Message-ID: <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> On 7/6/16 8:30 AM, Coleen Phillimore wrote: > > I uploaded it here: > > http://cr.openjdk.java.net/~coleenp/JDK-8160350.02/index.html src/os/solaris/vm/os_solaris.cpp L1322: bool os::supports_vtime() { return true; } L1323: bool os::enable_vtime() { return false; } L1324: bool os::vtime_enabled() { return false; } Seems like supports_vtime() should return 'false'. If there is a reason that it shouldn't, then we need a comment. Thumbs up modulo changing the return of supports_vtime() or adding a comment. I don't need to see a new webrev. Dan > > Coleen > > On 7/6/16 9:15 AM, Alan Burlison wrote: >> On 01/07/2016 21:40, Kim Barrett wrote: >> >>>> Vote: Use JDK-8160350 to fix Solaris and file a new bug for the >>>> larger cross-platform issues. >>>> >>>> Dan >>> >>> That seems like the right approach to me as well. >> >> I've logged https://bugs.openjdk.java.net/browse/JDK-8160887 and >> linked it to JDK-8160350. For JDK-8160350 I have rolled back to >> version 1 of the patch which just fixes the Solaris truss issue and >> have prepared a new webrev which I'll get uploaded shortly. I've also >> run it through the hotspot testset, all tests pass. >> > From kim.barrett at oracle.com Wed Jul 6 18:36:26 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 6 Jul 2016 14:36:26 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> Message-ID: > On Jul 6, 2016, at 1:23 AM, Andrew Hughes wrote: > > ----- Original Message ----- >>> On Jul 5, 2016, at 1:33 PM, Andrew Hughes wrote: >>> >>> ----- Original Message ----- >>>>> On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: >>>> common/autoconf/flags.m4 >>>> 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" >>>> >>>> There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It >>>> is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about >>>> the BUILD/TARGET distinction. >>> >>> This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS >>> and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the >>> FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used >>> in several places. I think this is outside the scope of this patch and >>> something which should be fixed by completing the current half-hearted >>> cross-compilation support. My aim here is just to fix the regression >>> which breaks the GCC 6 support on build==target builds, and I'd rather >>> whoever was working on the cross-compilation build continued that work. >>> There is a solution already in the handling of the warning argument >>> check, but it needs to be generalised to the other cases. >> >> I totally agree that fixing the xxx_CHECK_ARGUMENTS is out of scope >> for this patch. >> >> What I'm worried about is that by keeping those checks we might get >> and use the wrong answer in some cases where the BUILD and TARGET >> compilers are of different vintage. Maybe that will just encourage >> someone to fix them... > > Thanks. I agree it's an issue. I just don't think I'm the right person > to undertake rewiring all that, as I've never even used the cross-compilation > support so far. Yeah, I feel the same way. While I've dealt with cross-compilation issues of this sort enough to recognize the presence of problems, that work wasn't with this build system. > Do you know if there's already a bug for this? If not, I'll file one. I didn't find any relevant bugs. >> In the specific case of -std=gnu++98, it seems unlikely we'll see such >> a misconfiguration any time soon. That option was introduced in >> gcc3.3, and it seems unlikely to me that anyone is building the JDK >> with such an old compiler (though it wouldn't be the first time I've >> been surprised in that way). OTOH, if the compiler is very new and has >> dropped support for that standard (e.g. some as yet not even announced >> version of gcc), we actually want a build failure, since our code was >> written for that standard and not some later one. So we're unlikely to >> be hurt by the use of xxx_CHECK_ARGUMENTS here. >> > > I agree it's more likely that gnu++98 is going to be dropped at some point, > than we had a compiler that doesn't support the -std option. Hopefully, > making what was an implicit default before now explicit will encourage > developers to look at moving the code forward to a later version of the > standard. That's probably something for JDK 10+ though. I think there is interest in that direction. >> I think there are some more that are outside of HotSpot. >> >> Searching the build directory for *.o.cmdline files that don?t contain >> -std=gnu++98, e.g. >> >> find . -name "*.o.cmdline" ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print >> | xargs dirname | uniq >> >> produces a lot of stuff in ./support/native, the afore mentioned adlc, and a >> smattering of others. >> >> I think those might be better addressed by more followups, to get what we?ve >> got so far in. > > Thanks for the .cmdline trick. I wasn't aware of that. The .o.cmdline files are a feature of the new build system that I like a lot. > The -std=gnu++98 switch is only appropriate for the C++ compiler. Most of the > support/native object files are C files. > > C++ code is used in the following: > [?] > Using find . -name "*.o.cmdline" -exec egrep -q -e "g\+\+" {} \; ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print > I don't see any remaining files with the latest patch. Yay! >> But you will need that fix for JDK-8157358. I guess I should post an >> RFR for it... or you can just incorporate it into this patch if I don?t get >> that RFR done soon. > > I wasn't planning to either, but it was likewise bugging me when I > was trying to fix the GCC 6 issue. Ironically, it took much longer to > work out what was going on there than it did to realise I needed to > add the flags to JVM_CFLAGS :( > > I've included the fix in this patch, assuming that's ok with you. Yes, that?s fine with me. > If gcc is not being used, CXXSTD_CXXFLAG won't be set so this should be a safe no-op. Oh, right. > Revised webrevs: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot These look good to me. > I'm also now seeing a problem with GCC 6 only that is unique to the latest OpenJDK 9 > and what looks like the gtest code. It seems to be the result of the header changes > also documented in [0] which were introduced in January [1] (and so probably weren't > in earlier test versions of GCC 6). I'm able to work around it and get a completed > build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be something > to do with the changes to stdlib.h in GCC 6. Something for a separate bug. What fun! > [0] https://gcc.gnu.org/gcc-6/porting_to.html > [1] https://github.com/gcc-mirror/gcc/commit/6c8ced3f4f867b72a623fe2f23efa204c5786a28 > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From kim.barrett at oracle.com Wed Jul 6 18:41:16 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 6 Jul 2016 14:41:16 -0400 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> Message-ID: <598A74D0-B746-4AE0-B413-605F410593D7@oracle.com> > On Jul 6, 2016, at 1:45 PM, Daniel D. Daugherty wrote: > > On 7/6/16 8:30 AM, Coleen Phillimore wrote: >> >> I uploaded it here: >> >> http://cr.openjdk.java.net/~coleenp/JDK-8160350.02/index.html > > src/os/solaris/vm/os_solaris.cpp > L1322: bool os::supports_vtime() { return true; } > L1323: bool os::enable_vtime() { return false; } > L1324: bool os::vtime_enabled() { return false; } > > Seems like supports_vtime() should return 'false'. > If there is a reason that it shouldn't, then we > need a comment. > > Thumbs up modulo changing the return of supports_vtime() > or adding a comment. I don't need to see a new webrev. I?m confused. Why would we want supports_vtime to return false? From Alan.Burlison at oracle.com Wed Jul 6 19:04:49 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 6 Jul 2016 20:04:49 +0100 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> Message-ID: <577D5651.7080404@oracle.com> On 06/07/2016 18:45, Daniel D. Daugherty wrote: > src/os/solaris/vm/os_solaris.cpp > L1322: bool os::supports_vtime() { return true; } > L1323: bool os::enable_vtime() { return false; } > L1324: bool os::vtime_enabled() { return false; } > > Seems like supports_vtime() should return 'false'. > If there is a reason that it shouldn't, then we > need a comment. > > Thumbs up modulo changing the return of supports_vtime() > or adding a comment. I don't need to see a new webrev. It's that way on all the other platforms, I simply made it the same on Solaris as everywhere else. If I change it to return true on Solaris then it will be different to everywhere else. $ grep supports_vtime */*/* aix/vm/os_aix.cpp:bool os::supports_vtime() { return true; } bsd/vm/os_bsd.cpp:bool os::supports_vtime() { return true; } linux/vm/os_linux.cpp:bool os::supports_vtime() { return true; } solaris/vm/os_solaris.cpp:bool os::supports_vtime() { return true; } windows/vm/os_windows.cpp:bool os::supports_vtime() { return true; } -- Alan Burlison -- From daniel.daugherty at oracle.com Wed Jul 6 20:03:59 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Jul 2016 14:03:59 -0600 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <598A74D0-B746-4AE0-B413-605F410593D7@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> <598A74D0-B746-4AE0-B413-605F410593D7@oracle.com> Message-ID: <0e76af4b-3f2d-e1bf-979f-34b549e13778@oracle.com> On 7/6/16 12:41 PM, Kim Barrett wrote: >> On Jul 6, 2016, at 1:45 PM, Daniel D. Daugherty wrote: >> >> On 7/6/16 8:30 AM, Coleen Phillimore wrote: >>> I uploaded it here: >>> >>> http://cr.openjdk.java.net/~coleenp/JDK-8160350.02/index.html >> src/os/solaris/vm/os_solaris.cpp >> L1322: bool os::supports_vtime() { return true; } >> L1323: bool os::enable_vtime() { return false; } >> L1324: bool os::vtime_enabled() { return false; } >> >> Seems like supports_vtime() should return 'false'. >> If there is a reason that it shouldn't, then we >> need a comment. >> >> Thumbs up modulo changing the return of supports_vtime() >> or adding a comment. I don't need to see a new webrev. > I?m confused. Why would we want supports_vtime to return false? Went back and looked again. supports_vtime() should return true because os::elapsedVTime() still does something. enable_vtime() and vtime_enabled() return false because vtime support is always there and doesn't need to be enabled. Slightly confusing (to me at least) and will be more clear when the follow on bug (https://bugs.openjdk.java.net/browse/JDK-8160887) is fixed. Thumbs up as it is. Dan From daniel.daugherty at oracle.com Wed Jul 6 20:04:41 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Jul 2016 14:04:41 -0600 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <577D5651.7080404@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> <577D5651.7080404@oracle.com> Message-ID: On 7/6/16 1:04 PM, Alan Burlison wrote: > On 06/07/2016 18:45, Daniel D. Daugherty wrote: > >> src/os/solaris/vm/os_solaris.cpp >> L1322: bool os::supports_vtime() { return true; } >> L1323: bool os::enable_vtime() { return false; } >> L1324: bool os::vtime_enabled() { return false; } >> >> Seems like supports_vtime() should return 'false'. >> If there is a reason that it shouldn't, then we >> need a comment. >> >> Thumbs up modulo changing the return of supports_vtime() >> or adding a comment. I don't need to see a new webrev. > > It's that way on all the other platforms, I simply made it the same on > Solaris as everywhere else. If I change it to return true on Solaris > then it will be different to everywhere else. > > $ grep supports_vtime */*/* > aix/vm/os_aix.cpp:bool os::supports_vtime() { return true; } > bsd/vm/os_bsd.cpp:bool os::supports_vtime() { return true; } > linux/vm/os_linux.cpp:bool os::supports_vtime() { return true; } > solaris/vm/os_solaris.cpp:bool os::supports_vtime() { return true; } > windows/vm/os_windows.cpp:bool os::supports_vtime() { return true; } > I corrected myself in my reply to Kim B. Sorry for the confusion. Dan From kim.barrett at oracle.com Wed Jul 6 20:14:08 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 6 Jul 2016 16:14:08 -0400 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <0e76af4b-3f2d-e1bf-979f-34b549e13778@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> <598A74D0-B746-4AE0-B413-605F410593D7@oracle.com> <0e76af4b-3f2d-e1bf-979f-34b549e13778@oracle.com> Message-ID: > On Jul 6, 2016, at 4:03 PM, Daniel D. Daugherty wrote: > > On 7/6/16 12:41 PM, Kim Barrett wrote: >>> On Jul 6, 2016, at 1:45 PM, Daniel D. Daugherty wrote: >>> >>> On 7/6/16 8:30 AM, Coleen Phillimore wrote: >>>> I uploaded it here: >>>> >>>> http://cr.openjdk.java.net/~coleenp/JDK-8160350.02/index.html >>> src/os/solaris/vm/os_solaris.cpp >>> L1322: bool os::supports_vtime() { return true; } >>> L1323: bool os::enable_vtime() { return false; } >>> L1324: bool os::vtime_enabled() { return false; } >>> >>> Seems like supports_vtime() should return 'false'. >>> If there is a reason that it shouldn't, then we >>> need a comment. >>> >>> Thumbs up modulo changing the return of supports_vtime() >>> or adding a comment. I don't need to see a new webrev. >> I?m confused. Why would we want supports_vtime to return false? > > Went back and looked again. > > supports_vtime() should return true because os::elapsedVTime() > still does something. enable_vtime() and vtime_enabled() return > false because vtime support is always there and doesn't need to > be enabled. > > Slightly confusing (to me at least) and will be more clear when > the follow on bug (https://bugs.openjdk.java.net/browse/JDK-8160887) > is fixed. > > Thumbs up as it is. Looks good to me too. From Alan.Burlison at oracle.com Wed Jul 6 20:24:35 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 6 Jul 2016 21:24:35 +0100 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> <598A74D0-B746-4AE0-B413-605F410593D7@oracle.com> <0e76af4b-3f2d-e1bf-979f-34b549e13778@oracle.com> Message-ID: On 06/07/16 21:14, Kim Barrett wrote: >> Thumbs up as it is. > > Looks good to me too. Thanks. What happens next? -- Alan Burlison -- From kim.barrett at oracle.com Wed Jul 6 20:48:38 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 6 Jul 2016 16:48:38 -0400 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> <598A74D0-B746-4AE0-B413-605F410593D7@oracle.com> <0e76af4b-3f2d-e1bf-979f-34b549e13778@oracle.com> Message-ID: <19584BC6-0F85-4B30-A736-20A02543C11D@oracle.com> > On Jul 6, 2016, at 4:24 PM, Alan Burlison wrote: > > On 06/07/16 21:14, Kim Barrett wrote: > >>> Thumbs up as it is. >> >> Looks good to me too. > > Thanks. What happens next? > > -- > Alan Burlison > -- Your sponsor (which I guess is me now) pushes the change, possibly with a bit of a delay to see if any other conversent wants to chime in. From Alan.Burlison at oracle.com Wed Jul 6 21:56:28 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 6 Jul 2016 22:56:28 +0100 Subject: RFR: JDK-8160350 cannot truss jdk9 [solaris] In-Reply-To: <19584BC6-0F85-4B30-A736-20A02543C11D@oracle.com> References: <57767029.6060800@oracle.com> <5776D337.9090203@oracle.com> <59a20653-a046-7c6d-4d5f-221cf063eb2f@oracle.com> <83279473-30CA-47AD-B6E2-0682D835D586@oracle.com> <577D0479.1070907@oracle.com> <8ed88843-472b-5b4a-3ce5-f2027c901ddf@oracle.com> <4284b5c4-18d2-6c5e-041c-ef41c161156d@oracle.com> <598A74D0-B746-4AE0-B413-605F410593D7@oracle.com> <0e76af4b-3f2d-e1bf-979f-34b549e13778@oracle.com> <19584BC6-0F85-4B30-A736-20A02543C11D@oracle.com> Message-ID: On 06/07/16 21:48, Kim Barrett wrote: > Your sponsor (which I guess is me now) pushes the change, possibly with a bit of a > delay to see if any other conversent wants to chime in. Cool, thanks. One down... ;-) -- Alan Burlison -- From gnu.andrew at redhat.com Thu Jul 7 03:51:08 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 6 Jul 2016 23:51:08 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> Message-ID: <1356840573.2734504.1467863468986.JavaMail.zimbra@redhat.com> snip... > >> > >> What I'm worried about is that by keeping those checks we might get > >> and use the wrong answer in some cases where the BUILD and TARGET > >> compilers are of different vintage. Maybe that will just encourage > >> someone to fix them... > > > > Thanks. I agree it's an issue. I just don't think I'm the right person > > to undertake rewiring all that, as I've never even used the > > cross-compilation > > support so far. > > Yeah, I feel the same way. While I've dealt with cross-compilation > issues of this sort enough to recognize the presence of problems, that > work wasn't with this build system. > > > Do you know if there's already a bug for this? If not, I'll file one. > > I didn't find any relevant bugs. > I've filed one: https://bugs.openjdk.java.net/browse/JDK-8160926 snip... > > > Revised webrevs: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot > > These look good to me. > Thanks. I need someone at Oracle to push this one through, as the configure script for the closed code needs regenerating too. Apparently, I broke things last time :( > > I'm also now seeing a problem with GCC 6 only that is unique to the latest > > OpenJDK 9 > > and what looks like the gtest code. It seems to be the result of the header > > changes > > also documented in [0] which were introduced in January [1] (and so > > probably weren't > > in earlier test versions of GCC 6). I'm able to work around it and get a > > completed > > build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be > > something > > to do with the changes to stdlib.h in GCC 6. Something for a separate bug. > > What fun! A new batch of changes just came through which seems to have fixed it. I'm guessing this one: http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7862a718ec47 Either way, I'm happy I don't have to debug it :-) > > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > > [1] > > https://github.com/gcc-mirror/gcc/commit/6c8ced3f4f867b72a623fe2f23efa204c5786a28 > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > Thanks for the great feedback on this patch, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From rwestrel at redhat.com Thu Jul 7 10:01:03 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 07 Jul 2016 12:01:03 +0200 Subject: RFR: 8141633: Implement VarHandles/Unsafe intrinsics on AArch64 In-Reply-To: <577CF851.80206@redhat.com> References: <577CF851.80206@redhat.com> Message-ID: > http://cr.openjdk.java.net/~aph/8141633-1/ That looks good to me. Roland. From jdcrowley at gmail.com Thu Jul 7 11:29:54 2016 From: jdcrowley at gmail.com (John Crowley) Date: Thu, 7 Jul 2016 07:29:54 -0400 Subject: Make load/store of 64-bit long and double atomic Message-ID: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> All: Would like to make a suggestion re the JVM and non-atomic load/store for long and double values since both are 64-bit. (Sec 17.7 of the JLS version 8 - have not been able to find a JLS V9 yet). Did some searching through JSRs and mailing lists, but did not see this addressed - please send me a link if it has been and I just missed it. Right now, in a multi-threaded environment the developer must make these volatile to ensure correct operation - which I would suspect that 95% of Java developers do not realize. (I certainly didn?t for over 20 years!) Worse, in most cases these will in fact be atomic on any 64-bit server, and non-atomic on a 32-bit architecture - so you may suddenly get very strange differences running the same codebase. [Are there any 64-bit JVMs in which these load/store operations are done in 32-bit chunks?] I would propose pushing this decision down into the JVM - along roughly this plan: Define a new JVM option: -DatomicLong=[true|false] For any JVM with a 64-bit architecture this would be ignored (or issue a warning if explicitly set to false) For a 32-bit JVM, the default would be false (see below) If true for a 32-bit JVM, then the JVM itself would execute a memory barrier as required to perform atomic load/store of a long or double from/to application memory. A JVM option is suggested because there are probably still many applications running on 32-bit servers, and using a lot of long/double variables, that would suffer a major performance hit if the 32-bit JVM suddenly started implementing atomic load/store operations. Examples: financial models, simulations, weather forecasting. Also many applications may not be multi-threaded and would prefer to eliminate the overhead. Having a default of false preserves the current semantics of a 32-bit JVM. You could also drop the JVM option and have 32-bit JVMs compiled with two flavors: JVM (old semantics) and JVMAtomic (new semantics). This would eliminate any possible runtime overhead and allow the user to invoke the desired version at runtime. Best, John Crowley Westport, CT 203-856-2396 From aph at redhat.com Thu Jul 7 11:58:41 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jul 2016 12:58:41 +0100 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> Message-ID: <577E43F1.2080200@redhat.com> On 07/07/16 12:29, John Crowley wrote: > Would like to make a suggestion re the JVM and non-atomic load/store > for long and double values since both are 64-bit. (Sec 17.7 of the > JLS version 8 - have not been able to find a JLS V9 yet). Did some > searching through JSRs and mailing lists, but did not see this > addressed - please send me a link if it has been and I just missed > it. See http://mail.openjdk.java.net/pipermail/jmm-dev/2014-February/000008.html Please reply on that list. Andrew. From aph at redhat.com Thu Jul 7 14:05:00 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jul 2016 15:05:00 +0100 Subject: RFR: 8160969: aarch64: CDS is broken after 8079507 In-Reply-To: <576902F3.6020108@redhat.com> References: <5768FCE9.4020808@redhat.com> <576902F3.6020108@redhat.com> Message-ID: <577E618C.8070402@redhat.com> This one was reported by Ningsheng Jian at Linaro. It's a simple error which happened when merging the x86 changes for CDS. http://cr.openjdk.java.net/~aph/8160969/ OK? Andrew. From gnu.andrew at redhat.com Thu Jul 7 15:53:06 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Jul 2016 11:53:06 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1356840573.2734504.1467863468986.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1356840573.2734504.1467863468986.JavaMail.zimbra@redhat.com> Message-ID: <1801967885.2914575.1467906786428.JavaMail.zimbra@redhat.com> snip... > > > I'm also now seeing a problem with GCC 6 only that is unique to the > > > latest > > > OpenJDK 9 > > > and what looks like the gtest code. It seems to be the result of the > > > header > > > changes > > > also documented in [0] which were introduced in January [1] (and so > > > probably weren't > > > in earlier test versions of GCC 6). I'm able to work around it and get a > > > completed > > > build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be > > > something > > > to do with the changes to stdlib.h in GCC 6. Something for a separate > > > bug. > > > > What fun! > > A new batch of changes just came through which seems to have fixed it. > I'm guessing this one: > > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7862a718ec47 > > Either way, I'm happy I don't have to debug it :-) > Sadly, I celebrated too soon; it seems that change just delayed the failure until much later in the build. I've found the problem though. In src/share/vm/utilities/globalDefinitions.hpp, we have: #ifdef max #undef max #endif #ifdef min #undef min #endif #define max(a,b) Do_not_use_max_use_MAX2_instead #define min(a,b) Do_not_use_min_use_MIN2_instead The problem is that max and min are now longer macros in the GCC 6 C++ library. So they can't be undefined. The build succeeds if I disable (#if 0) the definition of max and min. So we need to consider either removing them or _GLIBCXX_INCLUDE_NEXT_C_HEADERS needs to be defined to get the old behaviour. I prefer the former. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From aph at redhat.com Thu Jul 7 15:57:36 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jul 2016 16:57:36 +0100 Subject: PING: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <576DF4CD.502@oracle.com> References: <576AD768.3070005@redhat.com> <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> <576C0BD6.4000106@redhat.com> <576DB611.4030408@oracle.com> <576DF4CD.502@oracle.com> Message-ID: <577E7BF0.1080807@redhat.com> Hi Vladimir, The current status: This patch fixes a serious bug in AArch64 and perhaps other targets. It's blocked because you discovered that an assertion (added by this patch) was triggered by some tests. I do not believe that anything this patch does could cause whatever problem the assertion reveals. I have not been able to reproduce the problem that you saw. Therefore there is nothing that I can do to fix it. May I simply take the assertion out and resubmit the patch? This bug in C2 is real, and serious. This patch is a blocker for AArch64. Thanks, Andrew. From ivan.gerasimov at oracle.com Wed Jul 6 16:55:45 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 6 Jul 2016 19:55:45 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out Message-ID: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> Hello! When fixing JDK-8069048 a potential race was overlooked: 1) Thread A wants to call _endthreadex() and registers itself, 2) Thread B wants to call exit(), takes its turn and raises the flag `process_exiting`, 3) Thread A continues, and gets captured in the loop at 4020, in SuspendThread(GetCurrentThread()), 4) Now, the thread B will have to wait for all the registered threads, including the thread A, which will never wake up. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ With kind regards, Ivan From jiangli.zhou at oracle.com Thu Jul 7 17:28:34 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 7 Jul 2016 10:28:34 -0700 Subject: RFR: 8160969: aarch64: CDS is broken after 8079507 In-Reply-To: <577E618C.8070402@redhat.com> References: <5768FCE9.4020808@redhat.com> <576902F3.6020108@redhat.com> <577E618C.8070402@redhat.com> Message-ID: <9C57E12A-4E1B-4D0A-BF8A-D21EA3D0B598@oracle.com> Hi Andrew, > On Jul 7, 2016, at 7:05 AM, Andrew Haley wrote: > > This one was reported by Ningsheng Jian at Linaro. > > It's a simple error which happened when merging the x86 changes for CDS. > > http://cr.openjdk.java.net/~aph/8160969/ Just curious, what failure did it run into with SharedStrings. JDK-8160969 doesn?t give much detail. Thanks, Jiangli > > OK? > > Andrew. > From aph at redhat.com Thu Jul 7 17:32:23 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jul 2016 18:32:23 +0100 Subject: RFR: 8160969: aarch64: CDS is broken after 8079507 In-Reply-To: <9C57E12A-4E1B-4D0A-BF8A-D21EA3D0B598@oracle.com> References: <5768FCE9.4020808@redhat.com> <576902F3.6020108@redhat.com> <577E618C.8070402@redhat.com> <9C57E12A-4E1B-4D0A-BF8A-D21EA3D0B598@oracle.com> Message-ID: <577E9227.2090602@redhat.com> On 07/07/16 18:28, Jiangli Zhou wrote: > Hi Andrew, > >> On Jul 7, 2016, at 7:05 AM, Andrew Haley wrote: >> >> This one was reported by Ningsheng Jian at Linaro. >> >> It's a simple error which happened when merging the x86 changes for CDS. >> >> http://cr.openjdk.java.net/~aph/8160969/ > > > Just curious, what failure did it run into with SharedStrings. JDK-8160969 doesn?t give much detail. # # Internal Error (/home/aph/hs-comp/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:2336), pid=17631, tid=17634 # assert(false) failed: DEBUG MESSAGE: patching the wrong bytecode This is because it is trying to patch an unpatchable bytecode. Andrew. From gnu.andrew at redhat.com Thu Jul 7 17:48:02 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Jul 2016 13:48:02 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> Message-ID: <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> snip... > > > Revised webrevs: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot > > These look good to me. > Minor revision: http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot I spotted that jsig is just a single C file and so doesn't need the -std flag. In fact, it complains about it: Compiling jsig.c (for libjsig.so) ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\ MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\ rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\ g.o.log) 2> >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( exitcode=$? && /bin/cp /home/and\ rew/builder/dev/hotspot/libjsig/objs/jsig.o.log /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\ .log && exit $exitcode ) ) && wait ) cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C So just ADLC is fixed now. The root webrev is the same as before. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From jiangli.zhou at oracle.com Thu Jul 7 18:14:50 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 7 Jul 2016 11:14:50 -0700 Subject: RFR: 8160969: aarch64: CDS is broken after 8079507 In-Reply-To: <577E9227.2090602@redhat.com> References: <5768FCE9.4020808@redhat.com> <576902F3.6020108@redhat.com> <577E618C.8070402@redhat.com> <9C57E12A-4E1B-4D0A-BF8A-D21EA3D0B598@oracle.com> <577E9227.2090602@redhat.com> Message-ID: <6B5C982E-0F83-45EC-870C-5ABDB1971529@oracle.com> > On Jul 7, 2016, at 10:32 AM, Andrew Haley wrote: > > On 07/07/16 18:28, Jiangli Zhou wrote: >> Hi Andrew, >> >>> On Jul 7, 2016, at 7:05 AM, Andrew Haley wrote: >>> >>> This one was reported by Ningsheng Jian at Linaro. >>> >>> It's a simple error which happened when merging the x86 changes for CDS. >>> >>> http://cr.openjdk.java.net/~aph/8160969/ >> >> >> Just curious, what failure did it run into with SharedStrings. JDK-8160969 doesn?t give much detail. > > # > # Internal Error (/home/aph/hs-comp/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:2336), pid=17631, tid=17634 > # assert(false) failed: DEBUG MESSAGE: patching the wrong bytecode > > This is because it is trying to patch an unpatchable byte code. Ok, thanks. The changes look okay to me. But someone who?s familiar with the aarch64 specific code should also review it. Thanks, Jiangli > > Andrew. > From kim.barrett at oracle.com Thu Jul 7 19:10:34 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 7 Jul 2016 19:10:34 +0000 (UTC) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> Message-ID: <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> > On Jul 7, 2016, at 1:48 PM, Andrew Hughes wrote: >>> Revised webrevs: >>> >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot >> >> These look good to me. >> > > Minor revision: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot > > I spotted that jsig is just a single C file and so doesn't > need the -std flag. In fact, it complains about it: > > Compiling jsig.c (for libjsig.so) > ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\ > MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\ > rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\ > g.o.log) 2> >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( exitcode=$? && /bin/cp /home/and\ > rew/builder/dev/hotspot/libjsig/objs/jsig.o.log /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\ > .log && exit $exitcode ) ) && wait ) > cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C > > So just ADLC is fixed now. > > The root webrev is the same as before. Oops, glad you caught that. Looks even better. From gnu.andrew at redhat.com Thu Jul 7 20:21:02 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Jul 2016 16:21:02 -0400 (EDT) Subject: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <690318825.2951922.1467919292598.JavaMail.zimbra@redhat.com> Message-ID: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 This is a backport of the original fix to support building OpenJDK with GCC 6. It was necessary to cherry-pick parts of a number of earlier fixes to make this work with the build system in 8: 8149647: Incremental enhancements from build-infra 8032045: Enable compiler and linker safety switches for debug builds and so I'm requesting a review of the 8 version of the patch here as well as approval for 8u. In brief, the patch makes OpenJDK build with GCC 6 by explicitly specifying the C++ standard to use (-std=gnu++98) and disabling two optimisations with -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further information on the changes is available in the GCC 6 release notes [0]. GCC 6 uses a newer C++ standard, C++14, with which the OpenJDK codebase is not yet compliant. The simplest way to fix this, especially for existing releases, is to explicitly request the previous default, gnu++98. The deletion of null pointer checks and more aggressive lifetime dead store elimination in 6 lead to a crashing virtual machine being built, so we disable them if GCC >= 6 is used. To make the original patch work with 8u, a number of changes from other fixes had to also be brought over: * We need to check we are using GCC 6 or above, so we need to bring over the TOOLCHAIN_CHECK_COMPILER_VERSION and TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional numbered rather than named argument macro so we don't need to backport BASIC_DEFUN_NAMED. * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 as we need to apply the -std option only to the C++ compiler, not the C compiler. If passed to the C compiler, it will produce a warning, and this is converted to an error at one point in the build (a -Werror in libsctp). Generally, we've kept things in toolchain.m4 (8034788 introduced flags.m4, separating out some code, and so many of these changes are in that file in 9) and avoid named argument macros. Otherwise, it's largely the same as the 9 version. We have adopted the longer name for the -fno-delete-null-pointer-checks flag variable as suggested in the review of the update to this patch for the new HotSpot build [1]. [0] https://gcc.gnu.org/gcc-6/porting_to.html [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Jul 7 20:42:30 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Jul 2016 16:42:30 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> Message-ID: <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 7, 2016, at 1:48 PM, Andrew Hughes wrote: > >>> Revised webrevs: > >>> > >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root > >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot > >> > >> These look good to me. > >> > > > > Minor revision: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root > > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot > > > > I spotted that jsig is just a single C file and so doesn't > > need the -std flag. In fact, it complains about it: > > > > Compiling jsig.c (for libjsig.so) > > ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 > > -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\ > > MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o > > /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\ > > rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > > > >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\ > > g.o.log) 2> >(/usr/bin/tee > > /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( > > exitcode=$? && /bin/cp /home/and\ > > rew/builder/dev/hotspot/libjsig/objs/jsig.o.log > > /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\ > > .log && exit $exitcode ) ) && wait ) > > cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ > > but not for C > > > > So just ADLC is fixed now. > > > > The root webrev is the same as before. > > Oops, glad you caught that. > > Looks even better. > > The same warning was causing an error in the OpenJDK 8 backport of the original GCC 6 patch, so I double-checked the logs for 9 and spotted this :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From jesper.wilhelmsson at oracle.com Fri Jul 8 02:09:54 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 8 Jul 2016 04:09:54 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: Hi Gerard, Thanks for reviewing! Den 6/7/16 kl. 19:17, skrev Gerard Ziemski: > hi Jesper, > > I really like the new output - very good job, but have a few feedbacks regarding the implemention: > > # 1 > > This point is just my opinion: > > In general, whouldn't it have been easier, from the implementation point of view, to add a new "bool" field tracking whether the "command line" was overriden? > > Tacking the "original command line" bit, though clever, in the Flag.Flags enum seems to have complicated the code handling that field quite a bit with numerous modifications of existing code required. I guess that is a matter of taste. :) Unless you have a strong objection to this style I'd prefer to keep it the way it is. > > > # 2 > > 1 void Flag::set_origin(Flags origin) { > 2 assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); > 3 origin = (origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin; > 4 _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | origin); > 5 } > > I don't like that the assert on line 2 - it is immediately invalidated on line 3. Right, this is not optimal. The problem is that the input variable is reused as a temporary. This is more clear: void Flag::set_origin(Flags origin) { assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); Flags new_origin = Flags((origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin); _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | new_origin); } > > With an addition of "bool" field as I pointed out in feedback #1, this wouldn't be an issue. > > > # 3 > > The names of functions don't quite match what we are doing, ex: > > bool Flag::is_command_line() > > should be perhaps renamed as: > > bool Flag::is_orig_command_line() ? > > Similar for "Flag::set_command_line()" and "CommandLineFlagsEx::setOnCmdLine()" > > Here we're not using the "COMMAND_LINE" value, but "ORIG_COMMAND_LINE" instead. There is no practical difference between is_command_line and is_orig_command_line. The old meaning of is_command_line does not exist anymore, once a flag has been set on the command line it will always be set on the command line. So I don't see any increased value in using a longer name. The fact that we use a different flag to see where the flag originated is an implementation detail that doesn't need to leak outside of is/set_command_line() imho. > > > # 4 > > Trivial issue - shouldn't the assert: > > // Size - 2 here because we want to fit } and \0 in there as well. > assert(buffer_used < (buffer_size - 2), "Too small buffer"); > > be applied right before: > > jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}"); > > ie, taken outside the "for (int i = 0; data[i].flag != -1; i++)" loop? The intention was to catch a too small buffer already in the loop. If we continue to write outside the buffer and the assert is outside the loop we might crash before reaching the assert. I see now that my version can exhibit the same behavior since we could actually write outside the buffer before the assert here as well. I changed it to: size_t length = strlen(d.name); // Size - 2 here because we want to fit } and \0 in there as well. assert(buffer_used - length < (buffer_size - 2), "Too small buffer"); jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "%s", d.name); buffer_used += length; Are you OK with this version? New webrev is here: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03/ Diff to previous version: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03-incremental/ Thanks, /Jesper > > > cheers > >> On Jun 29, 2016, at 11:55 AM, Jesper Wilhelmsson wrote: >> >> After some more testing I made a few smaller updates: >> >> * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() >> Looking at other code, it seemed to be the right thing to do. >> >> * Using size_t instead of int for the size and used counter in Flag::print_kind_and_origin() >> Windows compiler complained. >> >> * ORIG_COMMAND_LINE = 1 << 19 >> >> * Fixed some tests that was surprised by the new output from PrintFlagsFinal. >> >> New webrev: >> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ >> >> Thanks, >> /Jesper >> >> >> Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >>> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>>> why you skipped 19?: >>>> >>>> ORIG_COMMAND_LINE = 1 << 20, >>> >>> No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a >>> kind. I can change it to 19 if you think that's better. >>> >>>> >>>> Otherwise looks good. >>> >>> Thanks for reviewing! >>> >>> /Jesper >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>>> >>>>>> >>>>>> I agree with Vladimir. There's no way I'm going to remember that a colon >>>>>> mean that the value was changed. >>>>> The colon is what we have today to indicate that a value was changed :) >>>>> >>>>> I made a different solution in which I explicitly print the origin with words. >>>>> To make it look better I changed the >>>>> printing routine somewhat. The origin is currently at the end of the line. >>>>> This version will also print other origins like config file, environment, and >>>>> management as suggested by Dan. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>>> >>>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>>> >>>>> This is the new version: >>>>> >>>>> ccstr AbortVMOnExceptionMessage = >>>>> {diagnostic} {default} >>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>> 4 {product} {default} >>>>> intx AliasLevel = >>>>> 3 {C2 product} {default} >>>>> intx CMSAbortablePrecleanWaitMillis = >>>>> 100 {manageable} {default} >>>>> bool CMSClassUnloadingEnabled = >>>>> false {product} {command line} >>>>> intx ConditionalMoveLimit = >>>>> 3 {C2 pd product} {default} >>>>> size_t InitialHeapSize = >>>>> 134217728 {product} {ergonomic} >>>>> size_t MaxMetaspaceSize = >>>>> 18446744073709547520 {product} {default} >>>>> size_t NewSize = >>>>> 1966080 {product} {command line, >>>>> ergonomic} >>>>> ccstrlist OnError = {product} {default} >>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>> -1 {develop} {default} >>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>> true {product} {default} >>>>> bool UseCISCSpill = >>>>> true {C2 pd develop} {default} >>>>> bool UseCLMUL = >>>>> true {ARCH product} {default} >>>>> bool UseCompressedOops = >>>>> true {lp64_product} {ergonomic} >>>>> bool UseConcMarkSweepGC = >>>>> true {product} {command line} >>>>> >>>>> This is the old (current) version: >>>>> >>>>> ccstr AbortVMOnExceptionMessage = >>>>> {diagnostic} >>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>> 4 {product} >>>>> intx AliasLevel = >>>>> 3 {C2 product} >>>>> intx CMSAbortablePrecleanWaitMillis = >>>>> 100 {manageable} >>>>> bool CMSClassUnloadingEnabled := >>>>> false {product} >>>>> intx ConditionalMoveLimit = >>>>> 3 {C2 pd product} >>>>> size_t InitialHeapSize := >>>>> 134217728 {product} >>>>> size_t MaxMetaspaceSize = >>>>> 18446744073709547520 {product} >>>>> size_t NewSize := >>>>> 1966080 {product} >>>>> ccstrlist OnError = {product} >>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>> -1 {develop} >>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>> true {product} >>>>> bool UseCISCSpill = >>>>> true {C2 pd develop} >>>>> bool UseCompressedOops := >>>>> true {lp64_product} >>>>> bool UseConcMarkSweepGC := >>>>> true {product} >>>>> >>>>> /Jesper >>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>>> Nobody will remember the meaning of such marking. You should use normal words. >>>>>>> The output already have flag's type as, for example, "{C2 product}". You can >>>>>>> add an other word there to indicate type >>>>>>> of initialization: default|command|ergo. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>>>>> flags changed on the command line and flags >>>>>>>> changed by the ergonomics. >>>>>>>> >>>>>>>> To enable us to remember if a flag was set on the command line or not after >>>>>>>> having been changed by the ergonomics I use >>>>>>>> another bit in the Flag struct. >>>>>>>> >>>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>>>>> and I'm open to suggestions (bike sheding) >>>>>>>> about how to visualize this the best. >>>>>>>> >>>>>>>> The old decorations are: >>>>>>>> >>>>>>>> ' =' - Default value (no decoration) >>>>>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>>>>> >>>>>>>> The new decorations are: >>>>>>>> >>>>>>>> ' =' - Default value (no decoration) >>>>>>>> ':=' - Set on the command line >>>>>>>> '?=' - Changed by the ergonomics >>>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>>>>> config file >>>>>>>> >>>>>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>>>>> solid assignment and will therefore represent >>>>>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>>>>> seems appropriate. '!=' because you'd >>>>>>>> want to >>>>>>>> know that the ergonomics changed a value you had set on the command line. >>>>>>>> >>>>>>>> Another option could be to use a colon ':=' for the command line, and a >>>>>>>> comma ',=' for the ergonomics. That would >>>>>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>>>>> and changed by the ergonomics. I didn't go >>>>>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>>>>> each other. >>>>>>>> >>>>>>>> As mentioned above there are other origins, the enum contains eight values. >>>>>>>> There is no mention of the other types in >>>>>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>>>>> they didn't seem as important. If the general >>>>>>>> opinion is that these other origins are as important, or we might as >>>>>>>> well..., I'd suggest that we use letters as >>>>>>>> decorations. Let me know if you have an opinion. >>>>>>>> >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Jesper >>>>>> >>>>> > From erik.joelsson at oracle.com Fri Jul 8 06:38:31 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Jul 2016 08:38:31 +0200 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> Message-ID: <577F4A67.7000801@oracle.com> Hello, This looks good except for the change in toolchain.m4, which looks like it might actually break cross compilation by overriding the value for compiler version for the build compiler using the target compiler. With this change we basically have: if cross compilation TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) else ... fi TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) The problem you are trying to solve is that in the case of not cross compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in the else clause. I would instead suggest the following: if cross compilation ... else ... fi TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) Just move it out of the conditional blocks and always call it the same way. /Erik ( - on vacation and only sporadically checking email) On 2016-07-07 22:42, Andrew Hughes wrote: > > ----- Original Message ----- >>> On Jul 7, 2016, at 1:48 PM, Andrew Hughes wrote: >>>>> Revised webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root >>>>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot >>>> These look good to me. >>>> >>> Minor revision: >>> >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot >>> >>> I spotted that jsig is just a single C file and so doesn't >>> need the -std flag. In fact, it complains about it: >>> >>> Compiling jsig.c (for libjsig.so) >>> ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 >>> -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\ >>> MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o >>> /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\ >>> rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > >>>> (/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\ >>> g.o.log) 2> >(/usr/bin/tee >>> /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( >>> exitcode=$? && /bin/cp /home/and\ >>> rew/builder/dev/hotspot/libjsig/objs/jsig.o.log >>> /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\ >>> .log && exit $exitcode ) ) && wait ) >>> cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ >>> but not for C >>> >>> So just ADLC is fixed now. >>> >>> The root webrev is the same as before. >> Oops, glad you caught that. >> >> Looks even better. >> >> > The same warning was causing an error in the OpenJDK 8 backport of the original > GCC 6 patch, so I double-checked the logs for 9 and spotted this :-) From erik.joelsson at oracle.com Fri Jul 8 06:46:48 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Jul 2016 08:46:48 +0200 Subject: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> Message-ID: <577F4C58.6060101@oracle.com> Hello, It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always returning yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and C++ checks. /Erik On 2016-07-07 22:21, Andrew Hughes wrote: > Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 > > This is a backport of the original fix to support building OpenJDK > with GCC 6. It was necessary to cherry-pick parts of a number of > earlier fixes to make this work with the build system in 8: > > 8149647: Incremental enhancements from build-infra > 8032045: Enable compiler and linker safety switches for debug builds > > and so I'm requesting a review of the 8 version of the patch here as well > as approval for 8u. > > In brief, the patch makes OpenJDK build with GCC 6 by explicitly specifying > the C++ standard to use (-std=gnu++98) and disabling two optimisations with > -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further information > on the changes is available in the GCC 6 release notes [0]. GCC 6 uses > a newer C++ standard, C++14, with which the OpenJDK codebase is not yet > compliant. The simplest way to fix this, especially for existing releases, > is to explicitly request the previous default, gnu++98. The deletion > of null pointer checks and more aggressive lifetime dead store elimination > in 6 lead to a crashing virtual machine being built, so we disable them > if GCC >= 6 is used. > > To make the original patch work with 8u, a number of changes from other > fixes had to also be brought over: > > * We need to check we are using GCC 6 or above, so we need to bring > over the TOOLCHAIN_CHECK_COMPILER_VERSION and > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. > TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional > numbered rather than named argument macro so we don't need to backport > BASIC_DEFUN_NAMED. > * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 > as we need to apply the -std option only to the C++ compiler, not the > C compiler. If passed to the C compiler, it will produce a warning, > and this is converted to an error at one point in the build > (a -Werror in libsctp). > > Generally, we've kept things in toolchain.m4 (8034788 introduced flags.m4, > separating out some code, and so many of these changes are in that file > in 9) and avoid named argument macros. Otherwise, it's largely the > same as the 9 version. We have adopted the longer name for > the -fno-delete-null-pointer-checks flag variable as suggested in the > review of the update to this patch for the new HotSpot build [1]. > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html From aph at redhat.com Fri Jul 8 16:16:01 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Jul 2016 17:16:01 +0100 Subject: RFR: 8161072: AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure Message-ID: <577FD1C1.9040000@redhat.com> We get an assertion failure in fastdebug builds: DEBUG MESSAGE: InterpreterMacroAssembler::call_VM_leaf_base: last_sp != NULL This is because TemplateInterpreterGenerator::generate_deopt_entry_for() is all messed up: it calls InterpreterRuntime::throw_pending_exception() before the interpreter state has been restored. The simple fix is to restore all of the interpreter state before calling throw_pending_exception(). http://cr.openjdk.java.net/~aph/8161072/ Andrew. From rwestrel at redhat.com Fri Jul 8 16:24:56 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 8 Jul 2016 18:24:56 +0200 Subject: RFR: 8161072: AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure In-Reply-To: <577FD1C1.9040000@redhat.com> References: <577FD1C1.9040000@redhat.com> Message-ID: <577FD3D8.6000900@redhat.com> > http://cr.openjdk.java.net/~aph/8161072/ That looks good to me. Roland. From gerard.ziemski at oracle.com Fri Jul 8 17:07:15 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 8 Jul 2016 12:07:15 -0500 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: <1C1BBBB7-0873-4DDD-9E1B-064729D4956F@oracle.com> hi Jesper, > On Jul 7, 2016, at 9:09 PM, Jesper Wilhelmsson wrote: > > Hi Gerard, > > Thanks for reviewing! > > Den 6/7/16 kl. 19:17, skrev Gerard Ziemski: >> hi Jesper, >> >> I really like the new output - very good job, but have a few feedbacks regarding the implemention: >> >> # 1 >> >> This point is just my opinion: >> >> In general, whouldn't it have been easier, from the implementation point of view, to add a new "bool" field tracking whether the "command line" was overriden? >> >> Tacking the "original command line" bit, though clever, in the Flag.Flags enum seems to have complicated the code handling that field quite a bit with numerous modifications of existing code required. > > I guess that is a matter of taste. :) > Unless you have a strong objection to this style I'd prefer to keep it the way it is. Fair enough. I?d have done things differently, but at least your way we don?t use any more memory. > >> >> >> # 2 >> >> 1 void Flag::set_origin(Flags origin) { >> 2 assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); >> 3 origin = (origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin; >> 4 _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | origin); >> 5 } >> >> I don't like that the assert on line 2 - it is immediately invalidated on line 3. > > Right, this is not optimal. The problem is that the input variable is reused as a temporary. This is more clear: > > void Flag::set_origin(Flags origin) { > assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); > Flags new_origin = Flags((origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin); > _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | new_origin); > } That helps, thanks. > >> >> With an addition of "bool" field as I pointed out in feedback #1, this wouldn't be an issue. >> >> >> # 3 >> >> The names of functions don't quite match what we are doing, ex: >> >> bool Flag::is_command_line() >> >> should be perhaps renamed as: >> >> bool Flag::is_orig_command_line() ? >> >> Similar for "Flag::set_command_line()" and "CommandLineFlagsEx::setOnCmdLine()" >> >> Here we're not using the "COMMAND_LINE" value, but "ORIG_COMMAND_LINE" instead. > > There is no practical difference between is_command_line and is_orig_command_line. The old meaning of is_command_line does not exist anymore, once a flag has been set on the command line it will always be set on the command line. So I don't see any increased value in using a longer name. > The fact that we use a different flag to see where the flag originated is an implementation detail that doesn't need to leak outside of is/set_command_line() imho. > >> >> >> # 4 >> >> Trivial issue - shouldn't the assert: >> >> // Size - 2 here because we want to fit } and \0 in there as well. >> assert(buffer_used < (buffer_size - 2), "Too small buffer"); >> >> be applied right before: >> >> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}"); >> >> ie, taken outside the "for (int i = 0; data[i].flag != -1; i++)" loop? > > The intention was to catch a too small buffer already in the loop. If we continue to write outside the buffer and the assert is outside the loop we might crash before reaching the assert. I see now that my version can exhibit the same behavior since we could actually write outside the buffer before the assert here as well. I changed it to: > > size_t length = strlen(d.name); > // Size - 2 here because we want to fit } and \0 in there as well. > assert(buffer_used - length < (buffer_size - 2), "Too small buffer"); > jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "%s", d.name); > buffer_used += length; Looking at the assert more, I think you got the sign wrong, ie. instead of assert(buffer_used - length < (buffer_size - 2), "Too small buffer"); I think it should be: assert(buffer_used + length < (buffer_size - 2), "Too small buffer?); or I have been staring at the code for too long. Also, I disagree about that assert that checks whether ?}\0? fits. I think assert should be single purpose and check one thing at the time - the way it?s written right now it checks whether the ?d.name? AND ?}\0? both fit. I believe the code should be more something like: if ((_flags & KIND_MASK) != 0) { bool is_first = true; const size_t buffer_size = 64; size_t buffer_used = 1; char kind[buffer_size] = ?{"; for (int i = 0; data[i].flag != -1; i++) { Data d = data[i]; if ((_flags & d.flag) != 0) { if (is_first) { is_first = false; } else { assert(buffer_used + 1 < buffer_size, "Too small buffer"); jio_snprintf(kind + buffer_used, buffer_size - buffer_used, " "); buffer_used++; } size_t length = strlen(d.name); assert(buffer_used + length < buffer_size, "Too small buffer"); jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "%s", d.name); buffer_used += length; } } assert(buffer_used + 2 < buffer_size, "Too small buffer"); jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}?); st->print("%20s", kind); } Lastly, probably another personal preference, but I prefer ?buffer_used+2 < buffer_size? over ?buffer_used < buffer_size-2? since ?buffer_used? is the one advancing and ?buffer_size" is constant. cheers > > Are you OK with this version? > > New webrev is here: > http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03/ > > Diff to previous version: > http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03-incremental/ > > Thanks, > /Jesper > >> >> >> cheers >> >>> On Jun 29, 2016, at 11:55 AM, Jesper Wilhelmsson wrote: >>> >>> After some more testing I made a few smaller updates: >>> >>> * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() >>> Looking at other code, it seemed to be the right thing to do. >>> >>> * Using size_t instead of int for the size and used counter in Flag::print_kind_and_origin() >>> Windows compiler complained. >>> >>> * ORIG_COMMAND_LINE = 1 << 19 >>> >>> * Fixed some tests that was surprised by the new output from PrintFlagsFinal. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ >>> >>> Thanks, >>> /Jesper >>> >>> >>> Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >>>> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>>>> why you skipped 19?: >>>>> >>>>> ORIG_COMMAND_LINE = 1 << 20, >>>> >>>> No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a >>>> kind. I can change it to 19 if you think that's better. >>>> >>>>> >>>>> Otherwise looks good. >>>> >>>> Thanks for reviewing! >>>> >>>> /Jesper >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>>>> >>>>>>> >>>>>>> I agree with Vladimir. There's no way I'm going to remember that a colon >>>>>>> mean that the value was changed. >>>>>> The colon is what we have today to indicate that a value was changed :) >>>>>> >>>>>> I made a different solution in which I explicitly print the origin with words. >>>>>> To make it look better I changed the >>>>>> printing routine somewhat. The origin is currently at the end of the line. >>>>>> This version will also print other origins like config file, environment, and >>>>>> management as suggested by Dan. >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>>>> >>>>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>>>> >>>>>> This is the new version: >>>>>> >>>>>> ccstr AbortVMOnExceptionMessage = >>>>>> {diagnostic} {default} >>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>> 4 {product} {default} >>>>>> intx AliasLevel = >>>>>> 3 {C2 product} {default} >>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>> 100 {manageable} {default} >>>>>> bool CMSClassUnloadingEnabled = >>>>>> false {product} {command line} >>>>>> intx ConditionalMoveLimit = >>>>>> 3 {C2 pd product} {default} >>>>>> size_t InitialHeapSize = >>>>>> 134217728 {product} {ergonomic} >>>>>> size_t MaxMetaspaceSize = >>>>>> 18446744073709547520 {product} {default} >>>>>> size_t NewSize = >>>>>> 1966080 {product} {command line, >>>>>> ergonomic} >>>>>> ccstrlist OnError = {product} {default} >>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>> -1 {develop} {default} >>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>> true {product} {default} >>>>>> bool UseCISCSpill = >>>>>> true {C2 pd develop} {default} >>>>>> bool UseCLMUL = >>>>>> true {ARCH product} {default} >>>>>> bool UseCompressedOops = >>>>>> true {lp64_product} {ergonomic} >>>>>> bool UseConcMarkSweepGC = >>>>>> true {product} {command line} >>>>>> >>>>>> This is the old (current) version: >>>>>> >>>>>> ccstr AbortVMOnExceptionMessage = >>>>>> {diagnostic} >>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>> 4 {product} >>>>>> intx AliasLevel = >>>>>> 3 {C2 product} >>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>> 100 {manageable} >>>>>> bool CMSClassUnloadingEnabled := >>>>>> false {product} >>>>>> intx ConditionalMoveLimit = >>>>>> 3 {C2 pd product} >>>>>> size_t InitialHeapSize := >>>>>> 134217728 {product} >>>>>> size_t MaxMetaspaceSize = >>>>>> 18446744073709547520 {product} >>>>>> size_t NewSize := >>>>>> 1966080 {product} >>>>>> ccstrlist OnError = {product} >>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>> -1 {develop} >>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>> true {product} >>>>>> bool UseCISCSpill = >>>>>> true {C2 pd develop} >>>>>> bool UseCompressedOops := >>>>>> true {lp64_product} >>>>>> bool UseConcMarkSweepGC := >>>>>> true {product} >>>>>> >>>>>> /Jesper >>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>>>> Nobody will remember the meaning of such marking. You should use normal words. >>>>>>>> The output already have flag's type as, for example, "{C2 product}". You can >>>>>>>> add an other word there to indicate type >>>>>>>> of initialization: default|command|ergo. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>>>>>> flags changed on the command line and flags >>>>>>>>> changed by the ergonomics. >>>>>>>>> >>>>>>>>> To enable us to remember if a flag was set on the command line or not after >>>>>>>>> having been changed by the ergonomics I use >>>>>>>>> another bit in the Flag struct. >>>>>>>>> >>>>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>>>>>> and I'm open to suggestions (bike sheding) >>>>>>>>> about how to visualize this the best. >>>>>>>>> >>>>>>>>> The old decorations are: >>>>>>>>> >>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>>>>>> >>>>>>>>> The new decorations are: >>>>>>>>> >>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>> ':=' - Set on the command line >>>>>>>>> '?=' - Changed by the ergonomics >>>>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>>>>>> config file >>>>>>>>> >>>>>>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>>>>>> solid assignment and will therefore represent >>>>>>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>>>>>> seems appropriate. '!=' because you'd >>>>>>>>> want to >>>>>>>>> know that the ergonomics changed a value you had set on the command line. >>>>>>>>> >>>>>>>>> Another option could be to use a colon ':=' for the command line, and a >>>>>>>>> comma ',=' for the ergonomics. That would >>>>>>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>>>>>> and changed by the ergonomics. I didn't go >>>>>>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>>>>>> each other. >>>>>>>>> >>>>>>>>> As mentioned above there are other origins, the enum contains eight values. >>>>>>>>> There is no mention of the other types in >>>>>>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>>>>>> they didn't seem as important. If the general >>>>>>>>> opinion is that these other origins are as important, or we might as >>>>>>>>> well..., I'd suggest that we use letters as >>>>>>>>> decorations. Let me know if you have an opinion. >>>>>>>>> >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Jesper From kim.barrett at oracle.com Fri Jul 8 19:18:01 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 8 Jul 2016 15:18:01 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <577F4A67.7000801@oracle.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> Message-ID: <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> > On Jul 8, 2016, at 2:38 AM, Erik Joelsson wrote: > > Hello, > > This looks good except for the change in toolchain.m4, which looks like it might actually break cross compilation by overriding the value for compiler version for the build compiler using the target compiler. With this change we basically have: > > if cross compilation > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) > else > ... > fi > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) > > The problem you are trying to solve is that in the case of not cross compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in the else clause. Good catch! I totally missed that when reviewing. From gnu.andrew at redhat.com Sun Jul 10 21:05:15 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sun, 10 Jul 2016 17:05:15 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> Message-ID: <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 8, 2016, at 2:38 AM, Erik Joelsson wrote: > > > > Hello, > > > > This looks good except for the change in toolchain.m4, which looks like it > > might actually break cross compilation by overriding the value for > > compiler version for the build compiler using the target compiler. With > > this change we basically have: > > > > if cross compilation > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) > > else > > ... > > fi > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) > > > > The problem you are trying to solve is that in the case of not cross > > compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't > > called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in > > the else clause. > > Good catch! I totally missed that when reviewing. > > Yes, good catch! The indenting on the bug report must have confused me. Fixed version: http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot HotSpot webrev is unchanged. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jul 11 04:56:49 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 Jul 2016 00:56:49 -0400 (EDT) Subject: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <577F4C58.6060101@oracle.com> References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> <577F4C58.6060101@oracle.com> Message-ID: <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always returning > yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and > C++ checks. > Ugh, merged a block in the wrong place by the looks of it. Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/ configure:29739: checking if the C++ compiler supports "-std=gnu++98 " configure:29755: /usr/bin/g++ -c -std=gnu++98 conftest.cpp >&5 configure:29755: $? = 0 configure:29769: result: yes configure:29815: checking if the C compiler supports "-fno-delete-null-pointer-checks -Werror" configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks -Werror conftest.c >&5 configure:29832: $? = 0 configure:29846: result: yes configure:29855: checking if the C++ compiler supports "-fno-delete-null-pointer-checks -Werror" configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks -Werror conftest.cpp >&5 configure:29871: $? = 0 configure:29885: result: yes configure:29894: checking if both compilers support "-fno-delete-null-pointer-checks -Werror" configure:29899: result: yes configure:29911: checking if the C compiler supports "-fno-lifetime-dse -Werror" configure:29927: /usr/bin/gcc -c -fno-lifetime-dse -Werror conftest.c >&5 configure:29927: $? = 0 configure:29941: result: yes configure:29950: checking if the C++ compiler supports "-fno-lifetime-dse -Werror" configure:29966: /usr/bin/g++ -c -fno-lifetime-dse -Werror conftest.cpp >&5 configure:29966: $? = 0 configure:29980: result: yes configure:29989: checking if both compilers support "-fno-lifetime-dse -Werror" configure:29994: result: yes > /Erik > > On 2016-07-07 22:21, Andrew Hughes wrote: > > Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 > > > > This is a backport of the original fix to support building OpenJDK > > with GCC 6. It was necessary to cherry-pick parts of a number of > > earlier fixes to make this work with the build system in 8: > > > > 8149647: Incremental enhancements from build-infra > > 8032045: Enable compiler and linker safety switches for debug builds > > > > and so I'm requesting a review of the 8 version of the patch here as well > > as approval for 8u. > > > > In brief, the patch makes OpenJDK build with GCC 6 by explicitly specifying > > the C++ standard to use (-std=gnu++98) and disabling two optimisations with > > -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further information > > on the changes is available in the GCC 6 release notes [0]. GCC 6 uses > > a newer C++ standard, C++14, with which the OpenJDK codebase is not yet > > compliant. The simplest way to fix this, especially for existing releases, > > is to explicitly request the previous default, gnu++98. The deletion > > of null pointer checks and more aggressive lifetime dead store elimination > > in 6 lead to a crashing virtual machine being built, so we disable them > > if GCC >= 6 is used. > > > > To make the original patch work with 8u, a number of changes from other > > fixes had to also be brought over: > > > > * We need to check we are using GCC 6 or above, so we need to bring > > over the TOOLCHAIN_CHECK_COMPILER_VERSION and > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. > > TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional > > numbered rather than named argument macro so we don't need to backport > > BASIC_DEFUN_NAMED. > > * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 > > as we need to apply the -std option only to the C++ compiler, not the > > C compiler. If passed to the C compiler, it will produce a warning, > > and this is converted to an error at one point in the build > > (a -Werror in libsctp). > > > > Generally, we've kept things in toolchain.m4 (8034788 introduced flags.m4, > > separating out some code, and so many of these changes are in that file > > in 9) and avoid named argument macros. Otherwise, it's largely the > > same as the 9 version. We have adopted the longer name for > > the -fno-delete-null-pointer-checks flag variable as suggested in the > > review of the update to this patch for the new HotSpot build [1]. > > > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > > [1] > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From adinn at redhat.com Mon Jul 11 08:35:48 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 11 Jul 2016 09:35:48 +0100 Subject: RFR: 8161072: AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure In-Reply-To: <577FD3D8.6000900@redhat.com> References: <577FD1C1.9040000@redhat.com> <577FD3D8.6000900@redhat.com> Message-ID: <57835A64.3070205@redhat.com> On 08/07/16 17:24, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~aph/8161072/ > > That looks good to me. Yes, also looks good to me. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jesper.wilhelmsson at oracle.com Mon Jul 11 10:56:51 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 11 Jul 2016 12:56:51 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: <1C1BBBB7-0873-4DDD-9E1B-064729D4956F@oracle.com> References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> <1C1BBBB7-0873-4DDD-9E1B-064729D4956F@oracle.com> Message-ID: <2609d23e-f4d3-40c8-ce5e-f7afe5df6e06@oracle.com> Hi Gerard, Den 8/7/16 kl. 19:07, skrev Gerard Ziemski: > hi Jesper, > >> On Jul 7, 2016, at 9:09 PM, Jesper Wilhelmsson wrote: >> >> Hi Gerard, >> >> Thanks for reviewing! >> >> Den 6/7/16 kl. 19:17, skrev Gerard Ziemski: >>> hi Jesper, >>> >>> I really like the new output - very good job, but have a few feedbacks regarding the implemention: >>> >>> # 1 >>> >>> This point is just my opinion: >>> >>> In general, whouldn't it have been easier, from the implementation point of view, to add a new "bool" field tracking whether the "command line" was overriden? >>> >>> Tacking the "original command line" bit, though clever, in the Flag.Flags enum seems to have complicated the code handling that field quite a bit with numerous modifications of existing code required. >> >> I guess that is a matter of taste. :) >> Unless you have a strong objection to this style I'd prefer to keep it the way it is. > > Fair enough. I?d have done things differently, but at least your way we don?t use any more memory. Yes, that's one of my main motivations to do it this way. >>> # 2 >>> >>> 1 void Flag::set_origin(Flags origin) { >>> 2 assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); >>> 3 origin = (origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin; >>> 4 _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | origin); >>> 5 } >>> >>> I don't like that the assert on line 2 - it is immediately invalidated on line 3. >> >> Right, this is not optimal. The problem is that the input variable is reused as a temporary. This is more clear: >> >> void Flag::set_origin(Flags origin) { >> assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); >> Flags new_origin = Flags((origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin); >> _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | new_origin); >> } > > That helps, thanks. > > >> >>> >>> With an addition of "bool" field as I pointed out in feedback #1, this wouldn't be an issue. >>> >>> >>> # 3 >>> >>> The names of functions don't quite match what we are doing, ex: >>> >>> bool Flag::is_command_line() >>> >>> should be perhaps renamed as: >>> >>> bool Flag::is_orig_command_line() ? >>> >>> Similar for "Flag::set_command_line()" and "CommandLineFlagsEx::setOnCmdLine()" >>> >>> Here we're not using the "COMMAND_LINE" value, but "ORIG_COMMAND_LINE" instead. >> >> There is no practical difference between is_command_line and is_orig_command_line. The old meaning of is_command_line does not exist anymore, once a flag has been set on the command line it will always be set on the command line. So I don't see any increased value in using a longer name. >> The fact that we use a different flag to see where the flag originated is an implementation detail that doesn't need to leak outside of is/set_command_line() imho. >> >>> >>> >>> # 4 >>> >>> Trivial issue - shouldn't the assert: >>> >>> // Size - 2 here because we want to fit } and \0 in there as well. >>> assert(buffer_used < (buffer_size - 2), "Too small buffer"); >>> >>> be applied right before: >>> >>> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}"); >>> >>> ie, taken outside the "for (int i = 0; data[i].flag != -1; i++)" loop? >> >> The intention was to catch a too small buffer already in the loop. If we continue to write outside the buffer and the assert is outside the loop we might crash before reaching the assert. I see now that my version can exhibit the same behavior since we could actually write outside the buffer before the assert here as well. I changed it to: >> >> size_t length = strlen(d.name); >> // Size - 2 here because we want to fit } and \0 in there as well. >> assert(buffer_used - length < (buffer_size - 2), "Too small buffer"); >> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "%s", d.name); >> buffer_used += length; > > Looking at the assert more, I think you got the sign wrong, ie. instead of > > assert(buffer_used - length < (buffer_size - 2), "Too small buffer"); > > I think it should be: > > assert(buffer_used + length < (buffer_size - 2), "Too small buffer?); > > or I have been staring at the code for too long. You are right. Good catch! > > Also, I disagree about that assert that checks whether ?}\0? fits. I think assert should be single purpose and check one thing at the time - the way it?s written right now it checks whether the ?d.name? AND ?}\0? both fit. I believe the code should be more something like: I'm fine with that. It definitely makes the code easier to read. > > if ((_flags & KIND_MASK) != 0) { > bool is_first = true; > const size_t buffer_size = 64; > size_t buffer_used = 1; > char kind[buffer_size] = ?{"; > > for (int i = 0; data[i].flag != -1; i++) { > Data d = data[i]; > if ((_flags & d.flag) != 0) { > if (is_first) { > is_first = false; > } else { > assert(buffer_used + 1 < buffer_size, "Too small buffer"); > jio_snprintf(kind + buffer_used, buffer_size - buffer_used, " "); > buffer_used++; > } > size_t length = strlen(d.name); > assert(buffer_used + length < buffer_size, "Too small buffer"); > jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "%s", d.name); > buffer_used += length; > } > } > assert(buffer_used + 2 < buffer_size, "Too small buffer"); > jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}?); > > st->print("%20s", kind); > } > > Lastly, probably another personal preference, but I prefer ?buffer_used+2 < buffer_size? over ?buffer_used < buffer_size-2? since ?buffer_used? is the one advancing and ?buffer_size" is constant. Agreed. I have made the changes suggested with a small modification to the last assert. I use <= instead of < in the last assert since it would be OK to actually fill the entire size of the buffer here. New version: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.04/ Increment: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.04-incremental/ Thanks, /Jesper > > > cheers > >> >> Are you OK with this version? >> >> New webrev is here: >> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03/ >> >> Diff to previous version: >> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03-incremental/ >> >> Thanks, >> /Jesper >> >>> >>> >>> cheers >>> >>>> On Jun 29, 2016, at 11:55 AM, Jesper Wilhelmsson wrote: >>>> >>>> After some more testing I made a few smaller updates: >>>> >>>> * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() >>>> Looking at other code, it seemed to be the right thing to do. >>>> >>>> * Using size_t instead of int for the size and used counter in Flag::print_kind_and_origin() >>>> Windows compiler complained. >>>> >>>> * ORIG_COMMAND_LINE = 1 << 19 >>>> >>>> * Fixed some tests that was surprised by the new output from PrintFlagsFinal. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ >>>> >>>> Thanks, >>>> /Jesper >>>> >>>> >>>> Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >>>>> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>>>>> why you skipped 19?: >>>>>> >>>>>> ORIG_COMMAND_LINE = 1 << 20, >>>>> >>>>> No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a >>>>> kind. I can change it to 19 if you think that's better. >>>>> >>>>>> >>>>>> Otherwise looks good. >>>>> >>>>> Thanks for reviewing! >>>>> >>>>> /Jesper >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>>>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>>>>> >>>>>>>> >>>>>>>> I agree with Vladimir. There's no way I'm going to remember that a colon >>>>>>>> mean that the value was changed. >>>>>>> The colon is what we have today to indicate that a value was changed :) >>>>>>> >>>>>>> I made a different solution in which I explicitly print the origin with words. >>>>>>> To make it look better I changed the >>>>>>> printing routine somewhat. The origin is currently at the end of the line. >>>>>>> This version will also print other origins like config file, environment, and >>>>>>> management as suggested by Dan. >>>>>>> >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>>>>> >>>>>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>>>>> >>>>>>> This is the new version: >>>>>>> >>>>>>> ccstr AbortVMOnExceptionMessage = >>>>>>> {diagnostic} {default} >>>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>>> 4 {product} {default} >>>>>>> intx AliasLevel = >>>>>>> 3 {C2 product} {default} >>>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>>> 100 {manageable} {default} >>>>>>> bool CMSClassUnloadingEnabled = >>>>>>> false {product} {command line} >>>>>>> intx ConditionalMoveLimit = >>>>>>> 3 {C2 pd product} {default} >>>>>>> size_t InitialHeapSize = >>>>>>> 134217728 {product} {ergonomic} >>>>>>> size_t MaxMetaspaceSize = >>>>>>> 18446744073709547520 {product} {default} >>>>>>> size_t NewSize = >>>>>>> 1966080 {product} {command line, >>>>>>> ergonomic} >>>>>>> ccstrlist OnError = {product} {default} >>>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>>> -1 {develop} {default} >>>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>>> true {product} {default} >>>>>>> bool UseCISCSpill = >>>>>>> true {C2 pd develop} {default} >>>>>>> bool UseCLMUL = >>>>>>> true {ARCH product} {default} >>>>>>> bool UseCompressedOops = >>>>>>> true {lp64_product} {ergonomic} >>>>>>> bool UseConcMarkSweepGC = >>>>>>> true {product} {command line} >>>>>>> >>>>>>> This is the old (current) version: >>>>>>> >>>>>>> ccstr AbortVMOnExceptionMessage = >>>>>>> {diagnostic} >>>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>>> 4 {product} >>>>>>> intx AliasLevel = >>>>>>> 3 {C2 product} >>>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>>> 100 {manageable} >>>>>>> bool CMSClassUnloadingEnabled := >>>>>>> false {product} >>>>>>> intx ConditionalMoveLimit = >>>>>>> 3 {C2 pd product} >>>>>>> size_t InitialHeapSize := >>>>>>> 134217728 {product} >>>>>>> size_t MaxMetaspaceSize = >>>>>>> 18446744073709547520 {product} >>>>>>> size_t NewSize := >>>>>>> 1966080 {product} >>>>>>> ccstrlist OnError = {product} >>>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>>> -1 {develop} >>>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>>> true {product} >>>>>>> bool UseCISCSpill = >>>>>>> true {C2 pd develop} >>>>>>> bool UseCompressedOops := >>>>>>> true {lp64_product} >>>>>>> bool UseConcMarkSweepGC := >>>>>>> true {product} >>>>>>> >>>>>>> /Jesper >>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>>>>> Nobody will remember the meaning of such marking. You should use normal words. >>>>>>>>> The output already have flag's type as, for example, "{C2 product}". You can >>>>>>>>> add an other word there to indicate type >>>>>>>>> of initialization: default|command|ergo. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>>>>>>> flags changed on the command line and flags >>>>>>>>>> changed by the ergonomics. >>>>>>>>>> >>>>>>>>>> To enable us to remember if a flag was set on the command line or not after >>>>>>>>>> having been changed by the ergonomics I use >>>>>>>>>> another bit in the Flag struct. >>>>>>>>>> >>>>>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>>>>>>> and I'm open to suggestions (bike sheding) >>>>>>>>>> about how to visualize this the best. >>>>>>>>>> >>>>>>>>>> The old decorations are: >>>>>>>>>> >>>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>>>>>>> >>>>>>>>>> The new decorations are: >>>>>>>>>> >>>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>>> ':=' - Set on the command line >>>>>>>>>> '?=' - Changed by the ergonomics >>>>>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>>>>>>> config file >>>>>>>>>> >>>>>>>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>>>>>>> solid assignment and will therefore represent >>>>>>>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>>>>>>> seems appropriate. '!=' because you'd >>>>>>>>>> want to >>>>>>>>>> know that the ergonomics changed a value you had set on the command line. >>>>>>>>>> >>>>>>>>>> Another option could be to use a colon ':=' for the command line, and a >>>>>>>>>> comma ',=' for the ergonomics. That would >>>>>>>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>>>>>>> and changed by the ergonomics. I didn't go >>>>>>>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>>>>>>> each other. >>>>>>>>>> >>>>>>>>>> As mentioned above there are other origins, the enum contains eight values. >>>>>>>>>> There is no mention of the other types in >>>>>>>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>>>>>>> they didn't seem as important. If the general >>>>>>>>>> opinion is that these other origins are as important, or we might as >>>>>>>>>> well..., I'd suggest that we use letters as >>>>>>>>>> decorations. Let me know if you have an opinion. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> /Jesper > From gerard.ziemski at oracle.com Mon Jul 11 14:06:04 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 11 Jul 2016 09:06:04 -0500 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: <2609d23e-f4d3-40c8-ce5e-f7afe5df6e06@oracle.com> References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> <1C1BBBB7-0873-4DDD-9E1B-064729D4956F@oracle.com> <2609d23e-f4d3-40c8-ce5e-f7afe5df6e06@oracle.com> Message-ID: Looks good - (r)eviewed. cheers > On Jul 11, 2016, at 5:56 AM, Jesper Wilhelmsson wrote: > > Hi Gerard, > > Den 8/7/16 kl. 19:07, skrev Gerard Ziemski: >> hi Jesper, >> >>> On Jul 7, 2016, at 9:09 PM, Jesper Wilhelmsson wrote: >>> >>> Hi Gerard, >>> >>> Thanks for reviewing! >>> >>> Den 6/7/16 kl. 19:17, skrev Gerard Ziemski: >>>> hi Jesper, >>>> >>>> I really like the new output - very good job, but have a few feedbacks regarding the implemention: >>>> >>>> # 1 >>>> >>>> This point is just my opinion: >>>> >>>> In general, whouldn't it have been easier, from the implementation point of view, to add a new "bool" field tracking whether the "command line" was overriden? >>>> >>>> Tacking the "original command line" bit, though clever, in the Flag.Flags enum seems to have complicated the code handling that field quite a bit with numerous modifications of existing code required. >>> >>> I guess that is a matter of taste. :) >>> Unless you have a strong objection to this style I'd prefer to keep it the way it is. >> >> Fair enough. I?d have done things differently, but at least your way we don?t use any more memory. > > Yes, that's one of my main motivations to do it this way. > >>>> # 2 >>>> >>>> 1 void Flag::set_origin(Flags origin) { >>>> 2 assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); >>>> 3 origin = (origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin; >>>> 4 _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | origin); >>>> 5 } >>>> >>>> I don't like that the assert on line 2 - it is immediately invalidated on line 3. >>> >>> Right, this is not optimal. The problem is that the input variable is reused as a temporary. This is more clear: >>> >>> void Flag::set_origin(Flags origin) { >>> assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); >>> Flags new_origin = Flags((origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin); >>> _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | new_origin); >>> } >> >> That helps, thanks. >> >> >>> >>>> >>>> With an addition of "bool" field as I pointed out in feedback #1, this wouldn't be an issue. >>>> >>>> >>>> # 3 >>>> >>>> The names of functions don't quite match what we are doing, ex: >>>> >>>> bool Flag::is_command_line() >>>> >>>> should be perhaps renamed as: >>>> >>>> bool Flag::is_orig_command_line() ? >>>> >>>> Similar for "Flag::set_command_line()" and "CommandLineFlagsEx::setOnCmdLine()" >>>> >>>> Here we're not using the "COMMAND_LINE" value, but "ORIG_COMMAND_LINE" instead. >>> >>> There is no practical difference between is_command_line and is_orig_command_line. The old meaning of is_command_line does not exist anymore, once a flag has been set on the command line it will always be set on the command line. So I don't see any increased value in using a longer name. >>> The fact that we use a different flag to see where the flag originated is an implementation detail that doesn't need to leak outside of is/set_command_line() imho. >>> >>>> >>>> >>>> # 4 >>>> >>>> Trivial issue - shouldn't the assert: >>>> >>>> // Size - 2 here because we want to fit } and \0 in there as well. >>>> assert(buffer_used < (buffer_size - 2), "Too small buffer"); >>>> >>>> be applied right before: >>>> >>>> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}"); >>>> >>>> ie, taken outside the "for (int i = 0; data[i].flag != -1; i++)" loop? >>> >>> The intention was to catch a too small buffer already in the loop. If we continue to write outside the buffer and the assert is outside the loop we might crash before reaching the assert. I see now that my version can exhibit the same behavior since we could actually write outside the buffer before the assert here as well. I changed it to: >>> >>> size_t length = strlen(d.name); >>> // Size - 2 here because we want to fit } and \0 in there as well. >>> assert(buffer_used - length < (buffer_size - 2), "Too small buffer"); >>> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "%s", d.name); >>> buffer_used += length; >> >> Looking at the assert more, I think you got the sign wrong, ie. instead of >> >> assert(buffer_used - length < (buffer_size - 2), "Too small buffer"); >> >> I think it should be: >> >> assert(buffer_used + length < (buffer_size - 2), "Too small buffer?); >> >> or I have been staring at the code for too long. > > You are right. Good catch! > >> >> Also, I disagree about that assert that checks whether ?}\0? fits. I think assert should be single purpose and check one thing at the time - the way it?s written right now it checks whether the ?d.name? AND ?}\0? both fit. I believe the code should be more something like: > > I'm fine with that. It definitely makes the code easier to read. > >> >> if ((_flags & KIND_MASK) != 0) { >> bool is_first = true; >> const size_t buffer_size = 64; >> size_t buffer_used = 1; >> char kind[buffer_size] = ?{"; >> >> for (int i = 0; data[i].flag != -1; i++) { >> Data d = data[i]; >> if ((_flags & d.flag) != 0) { >> if (is_first) { >> is_first = false; >> } else { >> assert(buffer_used + 1 < buffer_size, "Too small buffer"); >> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, " "); >> buffer_used++; >> } >> size_t length = strlen(d.name); >> assert(buffer_used + length < buffer_size, "Too small buffer"); >> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "%s", d.name); >> buffer_used += length; >> } >> } >> assert(buffer_used + 2 < buffer_size, "Too small buffer"); >> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}?); >> >> st->print("%20s", kind); >> } >> >> Lastly, probably another personal preference, but I prefer ?buffer_used+2 < buffer_size? over ?buffer_used < buffer_size-2? since ?buffer_used? is the one advancing and ?buffer_size" is constant. > > Agreed. > > I have made the changes suggested with a small modification to the last assert. I use <= instead of < in the last assert since it would be OK to actually fill the entire size of the buffer here. > > New version: > http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.04/ > > Increment: > http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.04-incremental/ > > > Thanks, > /Jesper > > >> >> >> cheers >> >>> >>> Are you OK with this version? >>> >>> New webrev is here: >>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03/ >>> >>> Diff to previous version: >>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03-incremental/ >>> >>> Thanks, >>> /Jesper >>> >>>> >>>> >>>> cheers >>>> >>>>> On Jun 29, 2016, at 11:55 AM, Jesper Wilhelmsson wrote: >>>>> >>>>> After some more testing I made a few smaller updates: >>>>> >>>>> * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() >>>>> Looking at other code, it seemed to be the right thing to do. >>>>> >>>>> * Using size_t instead of int for the size and used counter in Flag::print_kind_and_origin() >>>>> Windows compiler complained. >>>>> >>>>> * ORIG_COMMAND_LINE = 1 << 19 >>>>> >>>>> * Fixed some tests that was surprised by the new output from PrintFlagsFinal. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ >>>>> >>>>> Thanks, >>>>> /Jesper >>>>> >>>>> >>>>> Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >>>>>> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>>>>>> why you skipped 19?: >>>>>>> >>>>>>> ORIG_COMMAND_LINE = 1 << 20, >>>>>> >>>>>> No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a >>>>>> kind. I can change it to 19 if you think that's better. >>>>>> >>>>>>> >>>>>>> Otherwise looks good. >>>>>> >>>>>> Thanks for reviewing! >>>>>> >>>>>> /Jesper >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>>>>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>>>>>> >>>>>>>>> >>>>>>>>> I agree with Vladimir. There's no way I'm going to remember that a colon >>>>>>>>> mean that the value was changed. >>>>>>>> The colon is what we have today to indicate that a value was changed :) >>>>>>>> >>>>>>>> I made a different solution in which I explicitly print the origin with words. >>>>>>>> To make it look better I changed the >>>>>>>> printing routine somewhat. The origin is currently at the end of the line. >>>>>>>> This version will also print other origins like config file, environment, and >>>>>>>> management as suggested by Dan. >>>>>>>> >>>>>>>> New webrev: >>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>>>>>> >>>>>>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>>>>>> >>>>>>>> This is the new version: >>>>>>>> >>>>>>>> ccstr AbortVMOnExceptionMessage = >>>>>>>> {diagnostic} {default} >>>>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>>>> 4 {product} {default} >>>>>>>> intx AliasLevel = >>>>>>>> 3 {C2 product} {default} >>>>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>>>> 100 {manageable} {default} >>>>>>>> bool CMSClassUnloadingEnabled = >>>>>>>> false {product} {command line} >>>>>>>> intx ConditionalMoveLimit = >>>>>>>> 3 {C2 pd product} {default} >>>>>>>> size_t InitialHeapSize = >>>>>>>> 134217728 {product} {ergonomic} >>>>>>>> size_t MaxMetaspaceSize = >>>>>>>> 18446744073709547520 {product} {default} >>>>>>>> size_t NewSize = >>>>>>>> 1966080 {product} {command line, >>>>>>>> ergonomic} >>>>>>>> ccstrlist OnError = {product} {default} >>>>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>>>> -1 {develop} {default} >>>>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>>>> true {product} {default} >>>>>>>> bool UseCISCSpill = >>>>>>>> true {C2 pd develop} {default} >>>>>>>> bool UseCLMUL = >>>>>>>> true {ARCH product} {default} >>>>>>>> bool UseCompressedOops = >>>>>>>> true {lp64_product} {ergonomic} >>>>>>>> bool UseConcMarkSweepGC = >>>>>>>> true {product} {command line} >>>>>>>> >>>>>>>> This is the old (current) version: >>>>>>>> >>>>>>>> ccstr AbortVMOnExceptionMessage = >>>>>>>> {diagnostic} >>>>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>>>> 4 {product} >>>>>>>> intx AliasLevel = >>>>>>>> 3 {C2 product} >>>>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>>>> 100 {manageable} >>>>>>>> bool CMSClassUnloadingEnabled := >>>>>>>> false {product} >>>>>>>> intx ConditionalMoveLimit = >>>>>>>> 3 {C2 pd product} >>>>>>>> size_t InitialHeapSize := >>>>>>>> 134217728 {product} >>>>>>>> size_t MaxMetaspaceSize = >>>>>>>> 18446744073709547520 {product} >>>>>>>> size_t NewSize := >>>>>>>> 1966080 {product} >>>>>>>> ccstrlist OnError = {product} >>>>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>>>> -1 {develop} >>>>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>>>> true {product} >>>>>>>> bool UseCISCSpill = >>>>>>>> true {C2 pd develop} >>>>>>>> bool UseCompressedOops := >>>>>>>> true {lp64_product} >>>>>>>> bool UseConcMarkSweepGC := >>>>>>>> true {product} >>>>>>>> >>>>>>>> /Jesper >>>>>>>> >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>>>>>> Nobody will remember the meaning of such marking. You should use normal words. >>>>>>>>>> The output already have flag's type as, for example, "{C2 product}". You can >>>>>>>>>> add an other word there to indicate type >>>>>>>>>> of initialization: default|command|ergo. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>>>>>>>> flags changed on the command line and flags >>>>>>>>>>> changed by the ergonomics. >>>>>>>>>>> >>>>>>>>>>> To enable us to remember if a flag was set on the command line or not after >>>>>>>>>>> having been changed by the ergonomics I use >>>>>>>>>>> another bit in the Flag struct. >>>>>>>>>>> >>>>>>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>>>>>>>> and I'm open to suggestions (bike sheding) >>>>>>>>>>> about how to visualize this the best. >>>>>>>>>>> >>>>>>>>>>> The old decorations are: >>>>>>>>>>> >>>>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>>>>>>>> >>>>>>>>>>> The new decorations are: >>>>>>>>>>> >>>>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>>>> ':=' - Set on the command line >>>>>>>>>>> '?=' - Changed by the ergonomics >>>>>>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>>>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>>>>>>>> config file >>>>>>>>>>> >>>>>>>>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>>>>>>>> solid assignment and will therefore represent >>>>>>>>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>>>>>>>> seems appropriate. '!=' because you'd >>>>>>>>>>> want to >>>>>>>>>>> know that the ergonomics changed a value you had set on the command line. >>>>>>>>>>> >>>>>>>>>>> Another option could be to use a colon ':=' for the command line, and a >>>>>>>>>>> comma ',=' for the ergonomics. That would >>>>>>>>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>>>>>>>> and changed by the ergonomics. I didn't go >>>>>>>>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>>>>>>>> each other. >>>>>>>>>>> >>>>>>>>>>> As mentioned above there are other origins, the enum contains eight values. >>>>>>>>>>> There is no mention of the other types in >>>>>>>>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>>>>>>>> they didn't seem as important. If the general >>>>>>>>>>> opinion is that these other origins are as important, or we might as >>>>>>>>>>> well..., I'd suggest that we use letters as >>>>>>>>>>> decorations. Let me know if you have an opinion. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> /Jesper From michael.haupt at oracle.com Mon Jul 11 14:11:04 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 11 Jul 2016 16:11:04 +0200 Subject: RFR(XS): 8161032: GPL header incorrect - address wrong - not swapped Message-ID: <9B3A2719-0473-4F0C-A60A-61226896D793@oracle.com> Dear all, Please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8161032 Webrev: http://javaweb.us.oracle.com/~mhaupt/8161032/webrev/ As it's a doc-only fix, I have not run any tests. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Mon Jul 11 14:31:03 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 11 Jul 2016 16:31:03 +0200 Subject: RFR(XS): 8161032: GPL header incorrect - address wrong - not swapped In-Reply-To: <9B3A2719-0473-4F0C-A60A-61226896D793@oracle.com> References: <9B3A2719-0473-4F0C-A60A-61226896D793@oracle.com> Message-ID: <552ED192-DB7A-46D0-807F-64C23FC053D2@oracle.com> ... corrected link for webrev: http://cr.openjdk.java.net/~mhaupt/8161032/webrev.00/ Best, Michael > Am 11.07.2016 um 16:11 schrieb Michael Haupt : > > Dear all, > > Please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8161032 > Webrev: http://javaweb.us.oracle.com/~mhaupt/8161032/webrev/ > > As it's a doc-only fix, I have not run any tests. > > Thanks, > > Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From jesper.wilhelmsson at oracle.com Mon Jul 11 16:37:46 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 11 Jul 2016 18:37:46 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> <1C1BBBB7-0873-4DDD-9E1B-064729D4956F@oracle.com> <2609d23e-f4d3-40c8-ce5e-f7afe5df6e06@oracle.com> Message-ID: Thanks Gerard! /Jesper Den 11/7/16 kl. 16:06, skrev Gerard Ziemski: > Looks good - (r)eviewed. > > > cheers > >> On Jul 11, 2016, at 5:56 AM, Jesper Wilhelmsson wrote: >> >> Hi Gerard, >> >> Den 8/7/16 kl. 19:07, skrev Gerard Ziemski: >>> hi Jesper, >>> >>>> On Jul 7, 2016, at 9:09 PM, Jesper Wilhelmsson wrote: >>>> >>>> Hi Gerard, >>>> >>>> Thanks for reviewing! >>>> >>>> Den 6/7/16 kl. 19:17, skrev Gerard Ziemski: >>>>> hi Jesper, >>>>> >>>>> I really like the new output - very good job, but have a few feedbacks regarding the implemention: >>>>> >>>>> # 1 >>>>> >>>>> This point is just my opinion: >>>>> >>>>> In general, whouldn't it have been easier, from the implementation point of view, to add a new "bool" field tracking whether the "command line" was overriden? >>>>> >>>>> Tacking the "original command line" bit, though clever, in the Flag.Flags enum seems to have complicated the code handling that field quite a bit with numerous modifications of existing code required. >>>> >>>> I guess that is a matter of taste. :) >>>> Unless you have a strong objection to this style I'd prefer to keep it the way it is. >>> >>> Fair enough. I?d have done things differently, but at least your way we don?t use any more memory. >> >> Yes, that's one of my main motivations to do it this way. >> >>>>> # 2 >>>>> >>>>> 1 void Flag::set_origin(Flags origin) { >>>>> 2 assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); >>>>> 3 origin = (origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin; >>>>> 4 _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | origin); >>>>> 5 } >>>>> >>>>> I don't like that the assert on line 2 - it is immediately invalidated on line 3. >>>> >>>> Right, this is not optimal. The problem is that the input variable is reused as a temporary. This is more clear: >>>> >>>> void Flag::set_origin(Flags origin) { >>>> assert((origin & VALUE_ORIGIN_MASK) == origin, "sanity"); >>>> Flags new_origin = Flags((origin == COMMAND_LINE) ? Flags(origin | ORIG_COMMAND_LINE) : origin); >>>> _flags = Flags((_flags & ~VALUE_ORIGIN_MASK) | new_origin); >>>> } >>> >>> That helps, thanks. >>> >>> >>>> >>>>> >>>>> With an addition of "bool" field as I pointed out in feedback #1, this wouldn't be an issue. >>>>> >>>>> >>>>> # 3 >>>>> >>>>> The names of functions don't quite match what we are doing, ex: >>>>> >>>>> bool Flag::is_command_line() >>>>> >>>>> should be perhaps renamed as: >>>>> >>>>> bool Flag::is_orig_command_line() ? >>>>> >>>>> Similar for "Flag::set_command_line()" and "CommandLineFlagsEx::setOnCmdLine()" >>>>> >>>>> Here we're not using the "COMMAND_LINE" value, but "ORIG_COMMAND_LINE" instead. >>>> >>>> There is no practical difference between is_command_line and is_orig_command_line. The old meaning of is_command_line does not exist anymore, once a flag has been set on the command line it will always be set on the command line. So I don't see any increased value in using a longer name. >>>> The fact that we use a different flag to see where the flag originated is an implementation detail that doesn't need to leak outside of is/set_command_line() imho. >>>> >>>>> >>>>> >>>>> # 4 >>>>> >>>>> Trivial issue - shouldn't the assert: >>>>> >>>>> // Size - 2 here because we want to fit } and \0 in there as well. >>>>> assert(buffer_used < (buffer_size - 2), "Too small buffer"); >>>>> >>>>> be applied right before: >>>>> >>>>> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}"); >>>>> >>>>> ie, taken outside the "for (int i = 0; data[i].flag != -1; i++)" loop? >>>> >>>> The intention was to catch a too small buffer already in the loop. If we continue to write outside the buffer and the assert is outside the loop we might crash before reaching the assert. I see now that my version can exhibit the same behavior since we could actually write outside the buffer before the assert here as well. I changed it to: >>>> >>>> size_t length = strlen(d.name); >>>> // Size - 2 here because we want to fit } and \0 in there as well. >>>> assert(buffer_used - length < (buffer_size - 2), "Too small buffer"); >>>> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "%s", d.name); >>>> buffer_used += length; >>> >>> Looking at the assert more, I think you got the sign wrong, ie. instead of >>> >>> assert(buffer_used - length < (buffer_size - 2), "Too small buffer"); >>> >>> I think it should be: >>> >>> assert(buffer_used + length < (buffer_size - 2), "Too small buffer?); >>> >>> or I have been staring at the code for too long. >> >> You are right. Good catch! >> >>> >>> Also, I disagree about that assert that checks whether ?}\0? fits. I think assert should be single purpose and check one thing at the time - the way it?s written right now it checks whether the ?d.name? AND ?}\0? both fit. I believe the code should be more something like: >> >> I'm fine with that. It definitely makes the code easier to read. >> >>> >>> if ((_flags & KIND_MASK) != 0) { >>> bool is_first = true; >>> const size_t buffer_size = 64; >>> size_t buffer_used = 1; >>> char kind[buffer_size] = ?{"; >>> >>> for (int i = 0; data[i].flag != -1; i++) { >>> Data d = data[i]; >>> if ((_flags & d.flag) != 0) { >>> if (is_first) { >>> is_first = false; >>> } else { >>> assert(buffer_used + 1 < buffer_size, "Too small buffer"); >>> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, " "); >>> buffer_used++; >>> } >>> size_t length = strlen(d.name); >>> assert(buffer_used + length < buffer_size, "Too small buffer"); >>> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "%s", d.name); >>> buffer_used += length; >>> } >>> } >>> assert(buffer_used + 2 < buffer_size, "Too small buffer"); >>> jio_snprintf(kind + buffer_used, buffer_size - buffer_used, "}?); >>> >>> st->print("%20s", kind); >>> } >>> >>> Lastly, probably another personal preference, but I prefer ?buffer_used+2 < buffer_size? over ?buffer_used < buffer_size-2? since ?buffer_used? is the one advancing and ?buffer_size" is constant. >> >> Agreed. >> >> I have made the changes suggested with a small modification to the last assert. I use <= instead of < in the last assert since it would be OK to actually fill the entire size of the buffer here. >> >> New version: >> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.04/ >> >> Increment: >> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.04-incremental/ >> >> >> Thanks, >> /Jesper >> >> >>> >>> >>> cheers >>> >>>> >>>> Are you OK with this version? >>>> >>>> New webrev is here: >>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03/ >>>> >>>> Diff to previous version: >>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.03-incremental/ >>>> >>>> Thanks, >>>> /Jesper >>>> >>>>> >>>>> >>>>> cheers >>>>> >>>>>> On Jun 29, 2016, at 11:55 AM, Jesper Wilhelmsson wrote: >>>>>> >>>>>> After some more testing I made a few smaller updates: >>>>>> >>>>>> * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() >>>>>> Looking at other code, it seemed to be the right thing to do. >>>>>> >>>>>> * Using size_t instead of int for the size and used counter in Flag::print_kind_and_origin() >>>>>> Windows compiler complained. >>>>>> >>>>>> * ORIG_COMMAND_LINE = 1 << 19 >>>>>> >>>>>> * Fixed some tests that was surprised by the new output from PrintFlagsFinal. >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> /Jesper >>>>>> >>>>>> >>>>>> Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: >>>>>>> Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >>>>>>>> why you skipped 19?: >>>>>>>> >>>>>>>> ORIG_COMMAND_LINE = 1 << 20, >>>>>>> >>>>>>> No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a >>>>>>> kind. I can change it to 19 if you think that's better. >>>>>>> >>>>>>>> >>>>>>>> Otherwise looks good. >>>>>>> >>>>>>> Thanks for reviewing! >>>>>>> >>>>>>> /Jesper >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>>>>>>>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I agree with Vladimir. There's no way I'm going to remember that a colon >>>>>>>>>> mean that the value was changed. >>>>>>>>> The colon is what we have today to indicate that a value was changed :) >>>>>>>>> >>>>>>>>> I made a different solution in which I explicitly print the origin with words. >>>>>>>>> To make it look better I changed the >>>>>>>>> printing routine somewhat. The origin is currently at the end of the line. >>>>>>>>> This version will also print other origins like config file, environment, and >>>>>>>>> management as suggested by Dan. >>>>>>>>> >>>>>>>>> New webrev: >>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>>>>>>>> >>>>>>>>> Examples of -XX:+PrintFlagsFinal with and without the change: >>>>>>>>> >>>>>>>>> This is the new version: >>>>>>>>> >>>>>>>>> ccstr AbortVMOnExceptionMessage = >>>>>>>>> {diagnostic} {default} >>>>>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>>>>> 4 {product} {default} >>>>>>>>> intx AliasLevel = >>>>>>>>> 3 {C2 product} {default} >>>>>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>>>>> 100 {manageable} {default} >>>>>>>>> bool CMSClassUnloadingEnabled = >>>>>>>>> false {product} {command line} >>>>>>>>> intx ConditionalMoveLimit = >>>>>>>>> 3 {C2 pd product} {default} >>>>>>>>> size_t InitialHeapSize = >>>>>>>>> 134217728 {product} {ergonomic} >>>>>>>>> size_t MaxMetaspaceSize = >>>>>>>>> 18446744073709547520 {product} {default} >>>>>>>>> size_t NewSize = >>>>>>>>> 1966080 {product} {command line, >>>>>>>>> ergonomic} >>>>>>>>> ccstrlist OnError = {product} {default} >>>>>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>>>>> -1 {develop} {default} >>>>>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>>>>> true {product} {default} >>>>>>>>> bool UseCISCSpill = >>>>>>>>> true {C2 pd develop} {default} >>>>>>>>> bool UseCLMUL = >>>>>>>>> true {ARCH product} {default} >>>>>>>>> bool UseCompressedOops = >>>>>>>>> true {lp64_product} {ergonomic} >>>>>>>>> bool UseConcMarkSweepGC = >>>>>>>>> true {product} {command line} >>>>>>>>> >>>>>>>>> This is the old (current) version: >>>>>>>>> >>>>>>>>> ccstr AbortVMOnExceptionMessage = >>>>>>>>> {diagnostic} >>>>>>>>> uintx AdaptiveSizeDecrementScaleFactor = >>>>>>>>> 4 {product} >>>>>>>>> intx AliasLevel = >>>>>>>>> 3 {C2 product} >>>>>>>>> intx CMSAbortablePrecleanWaitMillis = >>>>>>>>> 100 {manageable} >>>>>>>>> bool CMSClassUnloadingEnabled := >>>>>>>>> false {product} >>>>>>>>> intx ConditionalMoveLimit = >>>>>>>>> 3 {C2 pd product} >>>>>>>>> size_t InitialHeapSize := >>>>>>>>> 134217728 {product} >>>>>>>>> size_t MaxMetaspaceSize = >>>>>>>>> 18446744073709547520 {product} >>>>>>>>> size_t NewSize := >>>>>>>>> 1966080 {product} >>>>>>>>> ccstrlist OnError = {product} >>>>>>>>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>>>>>>>> -1 {develop} >>>>>>>>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>>>>>>>> true {product} >>>>>>>>> bool UseCISCSpill = >>>>>>>>> true {C2 pd develop} >>>>>>>>> bool UseCompressedOops := >>>>>>>>> true {lp64_product} >>>>>>>>> bool UseConcMarkSweepGC := >>>>>>>>> true {product} >>>>>>>>> >>>>>>>>> /Jesper >>>>>>>>> >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Nobody will remember the meaning of such marking. You should use normal words. >>>>>>>>>>> The output already have flag's type as, for example, "{C2 product}". You can >>>>>>>>>>> add an other word there to indicate type >>>>>>>>>>> of initialization: default|command|ergo. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>>>>>>>>> flags changed on the command line and flags >>>>>>>>>>>> changed by the ergonomics. >>>>>>>>>>>> >>>>>>>>>>>> To enable us to remember if a flag was set on the command line or not after >>>>>>>>>>>> having been changed by the ergonomics I use >>>>>>>>>>>> another bit in the Flag struct. >>>>>>>>>>>> >>>>>>>>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>>>>>>>>> and I'm open to suggestions (bike sheding) >>>>>>>>>>>> about how to visualize this the best. >>>>>>>>>>>> >>>>>>>>>>>> The old decorations are: >>>>>>>>>>>> >>>>>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>>>>>>>>> >>>>>>>>>>>> The new decorations are: >>>>>>>>>>>> >>>>>>>>>>>> ' =' - Default value (no decoration) >>>>>>>>>>>> ':=' - Set on the command line >>>>>>>>>>>> '?=' - Changed by the ergonomics >>>>>>>>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>>>>>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>>>>>>>>> config file >>>>>>>>>>>> >>>>>>>>>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>>>>>>>>> solid assignment and will therefore represent >>>>>>>>>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>>>>>>>>> seems appropriate. '!=' because you'd >>>>>>>>>>>> want to >>>>>>>>>>>> know that the ergonomics changed a value you had set on the command line. >>>>>>>>>>>> >>>>>>>>>>>> Another option could be to use a colon ':=' for the command line, and a >>>>>>>>>>>> comma ',=' for the ergonomics. That would >>>>>>>>>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>>>>>>>>> and changed by the ergonomics. I didn't go >>>>>>>>>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>>>>>>>>> each other. >>>>>>>>>>>> >>>>>>>>>>>> As mentioned above there are other origins, the enum contains eight values. >>>>>>>>>>>> There is no mention of the other types in >>>>>>>>>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>>>>>>>>> they didn't seem as important. If the general >>>>>>>>>>>> opinion is that these other origins are as important, or we might as >>>>>>>>>>>> well..., I'd suggest that we use letters as >>>>>>>>>>>> decorations. Let me know if you have an opinion. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> /Jesper > From vladimir.kozlov at oracle.com Mon Jul 11 17:36:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jul 2016 10:36:35 -0700 Subject: RFR(XS): 8161032: GPL header incorrect - address wrong - not swapped In-Reply-To: <552ED192-DB7A-46D0-807F-64C23FC053D2@oracle.com> References: <9B3A2719-0473-4F0C-A60A-61226896D793@oracle.com> <552ED192-DB7A-46D0-807F-64C23FC053D2@oracle.com> Message-ID: <8a1d4140-2825-0e3a-f9ea-9c19adb7f809@oracle.com> Changes are good. Thanks, Vladimir On 7/11/16 7:31 AM, Michael Haupt wrote: > ... corrected link for webrev: http://cr.openjdk.java.net/~mhaupt/8161032/webrev.00/ > > Best, > > Michael > >> Am 11.07.2016 um 16:11 schrieb Michael Haupt : >> >> Dear all, >> >> Please review this fix. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161032 >> Webrev: http://javaweb.us.oracle.com/~mhaupt/8161032/webrev/ >> >> As it's a doc-only fix, I have not run any tests. >> >> Thanks, >> >> Michael > From omajid at redhat.com Mon Jul 11 18:45:14 2016 From: omajid at redhat.com (Omair Majid) Date: Mon, 11 Jul 2016 14:45:14 -0400 Subject: RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6 Message-ID: <20160711184513.GA1485@redhat.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8161145 Webrev: http://cr.openjdk.java.net/~omajid/webrevs/8161145-gcc6-min-max-macros/00/ This patch fixes hotspot to build with GCC6 for me. With this patch, I can build jdk9/hotspot forests with: $ bash ../configure --disable-warnings-as-errors --with-extra-cxxflags='-Wno-error -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse -fpermissive' --with-extra-cflags='-Wno-error -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse' $ make WARNINGS_ARE_ERRORS="-Wno-error" CFLAGS_WARNINGS_ARE_ERRORS="-Wno-error" all Some of the -fno- options may not be needed anymore; I had them leftover from previous builds. My gcc version is: gcc version 6.1.1 20160621 (Red Hat 6.1.1-3) (GCC) Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Mon Jul 11 18:48:49 2016 From: omajid at redhat.com (Omair Majid) Date: Mon, 11 Jul 2016 14:48:49 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1801967885.2914575.1467906786428.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1356840573.2734504.1467863468986.JavaMail.zimbra@redhat.com> <1801967885.2914575.1467906786428.JavaMail.zimbra@redhat.com> Message-ID: <20160711184848.GB1485@redhat.com> * Andrew Hughes [2016-07-07 11:53]: > Sadly, I celebrated too soon; it seems that change just delayed the failure > until much later in the build. > > I've found the problem though. In src/share/vm/utilities/globalDefinitions.hpp, > we have: > > #ifdef max > #undef max > #endif > > #ifdef min > #undef min > #endif > > #define max(a,b) Do_not_use_max_use_MAX2_instead > #define min(a,b) Do_not_use_min_use_MIN2_instead > > The problem is that max and min are now longer macros in the GCC 6 C++ library. > So they can't be undefined. > > The build succeeds if I disable (#if 0) the definition of max and min. So > we need to consider either removing them or _GLIBCXX_INCLUDE_NEXT_C_HEADERS > needs to be defined to get the old behaviour. I prefer the former. I ran into this too and I posted a separate patch to work around this issue that just involves changing the ordering of the includes: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023910.html Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From kim.barrett at oracle.com Mon Jul 11 21:28:35 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 11 Jul 2016 17:28:35 -0400 Subject: RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6 In-Reply-To: <20160711184513.GA1485@redhat.com> References: <20160711184513.GA1485@redhat.com> Message-ID: <20D15A8D-1C0A-4D44-9E83-A99B38622A6C@oracle.com> > On Jul 11, 2016, at 2:45 PM, Omair Majid wrote: > > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161145 > Webrev: http://cr.openjdk.java.net/~omajid/webrevs/8161145-gcc6-min-max-macros/00/ https://wiki.openjdk.java.net/display/HotSpot/StyleGuide All .cpp files include precompiled.hpp as the first include line. Also, fixing include order problems by tweaking the order of the includes rarely leads to a happy ending. I wonder whether runtime/test_arguments.cpp is already suffering from such tweaking, as it presently #includes unittest.hpp before utilities/globalDefinitions.hpp, which seems odd. I think a different approach is needed. Perhaps don't provided the poisoned definitions at all. Or maybe we can use blue paint, e.g. #define min min #define max max > This patch fixes hotspot to build with GCC6 for me. With this patch, I > can build jdk9/hotspot forests with: > > $ bash ../configure --disable-warnings-as-errors --with-extra-cxxflags='-Wno-error -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse -fpermissive' --with-extra-cflags='-Wno-error -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse' > $ make WARNINGS_ARE_ERRORS="-Wno-error" CFLAGS_WARNINGS_ARE_ERRORS="-Wno-error" all > > Some of the -fno- options may not be needed anymore; I had them leftover > from previous builds. > > My gcc version is: gcc version 6.1.1 20160621 (Red Hat 6.1.1-3) (GCC) > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From kim.barrett at oracle.com Mon Jul 11 21:31:07 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 11 Jul 2016 17:31:07 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> Message-ID: <6311F66F-390D-491A-9D30-92CDF9316DD4@oracle.com> > On Jul 10, 2016, at 5:05 PM, Andrew Hughes wrote: > > > > ----- Original Message ----- >>> On Jul 8, 2016, at 2:38 AM, Erik Joelsson wrote: >>> >>> Hello, >>> >>> This looks good except for the change in toolchain.m4, which looks like it >>> might actually break cross compilation by overriding the value for >>> compiler version for the build compiler using the target compiler. With >>> this change we basically have: >>> >>> if cross compilation >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) >>> else >>> ... >>> fi >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) >>> >>> The problem you are trying to solve is that in the case of not cross >>> compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't >>> called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in >>> the else clause. >> >> Good catch! I totally missed that when reviewing. >> >> > Yes, good catch! The indenting on the bug report must have confused me. > > Fixed version: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot > > HotSpot webrev is unchanged. Looks good. From omajid at redhat.com Mon Jul 11 21:32:35 2016 From: omajid at redhat.com (Omair Majid) Date: Mon, 11 Jul 2016 17:32:35 -0400 Subject: RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6 In-Reply-To: <20D15A8D-1C0A-4D44-9E83-A99B38622A6C@oracle.com> References: <20160711184513.GA1485@redhat.com> <20D15A8D-1C0A-4D44-9E83-A99B38622A6C@oracle.com> Message-ID: <20160711213233.GC4079@redhat.com> Hi Kim, Thanks for the review! * Kim Barrett [2016-07-11 17:28]: > > On Jul 11, 2016, at 2:45 PM, Omair Majid wrote: > > > > Hi, > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161145 > > Webrev: http://cr.openjdk.java.net/~omajid/webrevs/8161145-gcc6-min-max-macros/00/ > > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide > All .cpp files include precompiled.hpp as the first include line. Thanks for the pointer. I was not aware of this. > I think a different approach is needed. Perhaps don't provided the > poisoned definitions at all. That sounds like the best solution in the long term. But I am afraid to remove it because it was probably added for a reason and I am not familiar with the code. > Or maybe we can use blue paint, e.g. > > #define min min > #define max max Should I implement this approach? Or should I look into removing the poisoned definitions? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From kim.barrett at oracle.com Mon Jul 11 21:44:29 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 11 Jul 2016 17:44:29 -0400 Subject: RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6 In-Reply-To: <20160711213233.GC4079@redhat.com> References: <20160711184513.GA1485@redhat.com> <20D15A8D-1C0A-4D44-9E83-A99B38622A6C@oracle.com> <20160711213233.GC4079@redhat.com> Message-ID: > On Jul 11, 2016, at 5:32 PM, Omair Majid wrote: > > Hi Kim, > > Thanks for the review! > > * Kim Barrett [2016-07-11 17:28]: >>> On Jul 11, 2016, at 2:45 PM, Omair Majid wrote: >>> >>> Hi, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161145 >>> Webrev: http://cr.openjdk.java.net/~omajid/webrevs/8161145-gcc6-min-max-macros/00/ >> >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >> All .cpp files include precompiled.hpp as the first include line. > > Thanks for the pointer. I was not aware of this. > >> I think a different approach is needed. Perhaps don't provided the >> poisoned definitions at all. > > That sounds like the best solution in the long term. But I am afraid to > remove it because it was probably added for a reason and I am not > familiar with the code. > >> Or maybe we can use blue paint, e.g. >> >> #define min min >> #define max max > > Should I implement this approach? Or should I look into removing the > poisoned definitions? I suspect the poisoning exists because these names are defined as macros by a frequently used Windows system header (windefs.h?), and we want to ensure Hotspot code doesn't accidentally use them. I think the blue paint approach would produce a similar result, but I haven't tested it (and I'm not well versed in the foibles of Visual Studio's preprocessor, though have seen many complaints about its non-compliance). From david.holmes at oracle.com Tue Jul 12 01:25:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 11:25:17 +1000 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> Message-ID: Catching up ... On 11/07/2016 7:05 AM, Andrew Hughes wrote: > > > ----- Original Message ----- >>> On Jul 8, 2016, at 2:38 AM, Erik Joelsson wrote: >>> >>> Hello, >>> >>> This looks good except for the change in toolchain.m4, which looks like it >>> might actually break cross compilation by overriding the value for >>> compiler version for the build compiler using the target compiler. With >>> this change we basically have: >>> >>> if cross compilation >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) >>> else >>> ... >>> fi >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) >>> >>> The problem you are trying to solve is that in the case of not cross >>> compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't >>> called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in >>> the else clause. >> >> Good catch! I totally missed that when reviewing. >> >> > Yes, good catch! The indenting on the bug report must have confused me. > > Fixed version: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot I was glad to see you realized that parts of the hotspot build (libjsig, libdtrace) only deal with C programs not C++ and so don't want and should not have a C++ setting passed. But that then begs the question in the main build in flags.m4 why we have: $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" which again adds a C++ related flags to what should be the C compilation flags ?? Thanks, David ----- > HotSpot webrev is unchanged. > > Thanks, > From david.holmes at oracle.com Tue Jul 12 01:51:37 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 11:51:37 +1000 Subject: Exceptions on using Java on ARM In-Reply-To: <6AE91074EA3C3E49BD0F843608814648BB35932C@oro-mbox-02.luxoft.com> References: <6AE91074EA3C3E49BD0F843608814648BB35932C@oro-mbox-02.luxoft.com> Message-ID: <095198fd-9875-786b-3276-d90550357b45@oracle.com> As I said in reply to your original email: This is an issue with the Oracle SE Embedded JRE for ARM , which is not part of OpenJDK and so can not be discussed on these mailing lists. --- Please do not send emails about this. Bug reports need to come in via the approved channels as informed when you downloaded this product. Thanks, David On 5/07/2016 1:10 AM, Lebeda, Borys wrote: > Hello everyone, > > I get following errors when run tomcat 6 on server with Java 8 on ARM device: > > I have once already reported the problem with the same environment which not reproduced with -Xint, however this time there was no -Xint option: > root at phyFLEX-i:~ uname -a > Linux phyFLEX-i.MX6 3.0.43-tpcom_run2-PD13.2.4 #1 SMP PREEMPT Fri Jun 10 11:55:37 CEST 2016 armv7l GNU/Linux > > root at phyFLEX-i:/usr/tomcat/lib /usr/java/ejre1.8.0_65/bin/java -cp catalina.jar org.apache.catalina.util.ServerInfo > Server version: Apache Tomcat/6.0.36 > Server built: Oct 16 2012 09:59:09 > Server number: 6.0.36.0 > OS Name: Linux > OS Version: 3.0.43-tpcom_run2-PD13.2.4 > Architecture: arm > JVM Version: 1.8.0_65-b17 > JVM Vendor: Oracle Corporation > > root at phyFLEX-i:~ /usr/java/ejre1.8.0_65/bin/java -version > java version "1.8.0_65" > Java(TM) SE Embedded Runtime Environment (build 1.8.0_65-b17, headless) > Java HotSpot(TM) Embedded Client VM (build 25.65-b01, mixed mode) > > My assumption that these two crashes somehow connected, but I might be wrong: the connection is that test case and environment is the same > > > Kind regards, > Borys Lebeda > > ________________________________ > > This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. > From david.holmes at oracle.com Tue Jul 12 02:21:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 12:21:08 +1000 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> Message-ID: Hi John, On 7/07/2016 9:29 PM, John Crowley wrote: > All: > > Would like to make a suggestion re the JVM and non-atomic load/store for long and double values since both are 64-bit. (Sec 17.7 of the JLS version 8 - have not been able to find a JLS V9 yet). Did some searching through JSRs and mailing lists, but did not see this addressed - please send me a link if it has been and I just missed it. This is not a hotspot issue but a Java programming language issue. Hotspot would never provide a flag that changes the Java programming language semantics. The performance impact of all-accesses-are-atomic on 32-bit systems is considerable so as long as we support 32-bit I don't see this happening (regardless of what may be discussed on jmm-dev). It would be unconscionable to have different semantics on 32-bit and 64-bit so that is not an option either. I also think this is somewhat of a red-herring. If lack of atomic accesses is causing your code a problem then your code is not performing atomic updates of variables - ie modifications to longs/doubles are not being done in a thread-safe way. Making simple reads/writes atomic will not change that - your code will still be broken. > Right now, in a multi-threaded environment the developer must make these volatile to ensure correct operation - which I would suspect that 95% of Java developers do not realize. (I certainly didn?t for over 20 years!) Any introductory Java text worth its salt, and certainly any text on concurrent programming in Java, covers this part of the programming model. > Worse, in most cases these will in fact be atomic on any 64-bit server, and non-atomic on a 32-bit architecture - so you may suddenly get very strange differences running the same codebase. [Are there any 64-bit JVMs in which these load/store operations are done in 32-bit chunks?] Unaligned accesses to 64-bit variables may not be atomic on some architectures. Cheers, David ----- > I would propose pushing this decision down into the JVM - along roughly this plan: > > Define a new JVM option: -DatomicLong=[true|false] > For any JVM with a 64-bit architecture this would be ignored (or issue a warning if explicitly set to false) > For a 32-bit JVM, the default would be false (see below) > If true for a 32-bit JVM, then the JVM itself would execute a memory barrier as required to perform atomic load/store of a long or double from/to application memory. > > A JVM option is suggested because there are probably still many applications running on 32-bit servers, and using a lot of long/double variables, that would suffer a major performance hit if the 32-bit JVM suddenly started implementing atomic load/store operations. Examples: financial models, simulations, weather forecasting. Also many applications may not be multi-threaded and would prefer to eliminate the overhead. > > Having a default of false preserves the current semantics of a 32-bit JVM. > > You could also drop the JVM option and have 32-bit JVMs compiled with two flavors: JVM (old semantics) and JVMAtomic (new semantics). This would eliminate any possible runtime overhead and allow the user to invoke the desired version at runtime. > > Best, > > > John Crowley > Westport, CT > 203-856-2396 > > > > From david.holmes at oracle.com Tue Jul 12 03:22:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 13:22:09 +1000 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <577BAC42.80708@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <577A7DDA.4000304@redhat.com> <577B7942.5090801@redhat.com> <577BAC42.80708@redhat.com> Message-ID: On 5/07/2016 10:46 PM, Andrew Haley wrote: > On 05/07/16 13:17, David Holmes wrote: >> On 5/07/2016 7:09 PM, Andrew Haley wrote: >>> On 04/07/16 22:09, David Holmes wrote: >>>> Surely cmpxchg already ensures the store (if it happens) is visible in >>>> other threads - else the cmpxchg would not even operate correctly. >>> >>> No, it doesn't. Semantically, the cmpxchg is no more than an atomic >>> operation on a single word: it has no other memory ordering effects. >>> If you want the store to be observed before some other memory access >>> you have to do something to make that happen. >> >> You seem to be confusing ordering with visibility. > > I hope not. > >> The cmpxchg must be visible to other threads else cmpxchg can't >> function. But that doesn't imply any ordering constraints with >> anything before/after the cmpxchg. > > Indeed not, but a volatile store -- the case I'm talking about -- is > supposed to be part of the total order. So, the store must be > sequenced before any following volatile loads. It makes no difference > whether the operation is a simple store or is a cmpxchg: we need the > trailing StoreLoad barrier. Right - ordering, not visibility. David > Andrew. > From gnu.andrew at redhat.com Tue Jul 12 03:40:01 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 Jul 2016 23:40:01 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> Message-ID: <1630509666.3999193.1468294801972.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Catching up ... > > On 11/07/2016 7:05 AM, Andrew Hughes wrote: > > > > > > ----- Original Message ----- > >>> On Jul 8, 2016, at 2:38 AM, Erik Joelsson > >>> wrote: > >>> > >>> Hello, > >>> > >>> This looks good except for the change in toolchain.m4, which looks like > >>> it > >>> might actually break cross compilation by overriding the value for > >>> compiler version for the build compiler using the target compiler. With > >>> this change we basically have: > >>> > >>> if cross compilation > >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) > >>> else > >>> ... > >>> fi > >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) > >>> > >>> The problem you are trying to solve is that in the case of not cross > >>> compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't > >>> called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call > >>> in > >>> the else clause. > >> > >> Good catch! I totally missed that when reviewing. > >> > >> > > Yes, good catch! The indenting on the bug report must have confused me. > > > > Fixed version: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ > > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot > > I was glad to see you realized that parts of the hotspot build (libjsig, > libdtrace) only deal with C programs not C++ and so don't want and > should not have a C++ setting passed. But that then begs the question in > the main build in flags.m4 why we have: > > $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" > > which again adds a C++ related flags to what should be the C compilation > flags ?? > You'd think so, but for some reason, the HotSpot build has always called the C++ compiler flags 'CFLAGS'. There is no JVM_CXXFLAGS. The same behaviour was true with the old build; we had to pass these options down to HotSpot in EXTRA_CFLAGS. JVM_CFLAGS is the main variable used in the HotSpot build (see make/lib/CompileJvm.gmk). The only C files in the HotSpot tree are for libsaproc, jsig and DTrace, all of which are handled by separate makefiles. The only one to use JVM_CFLAGS is make/lib/CompileDtracePostJvm.gmk, where it is used for a single C++ file, generateJvmOffsets.cpp: generateJvmOffsets.cpp_CXXFLAGS := $(JVM_CFLAGS) -mt -xnolib -norunpath, \ generateJvmOffsetsMain.c_CFLAGS := -library=%none -mt -m64 -norunpath -z nodefs, \ Thus, it seems JVM_CFLAGS is JVM_CXXFLAGS in all but name. If -std=gnu++98 does get passed to the C compiler, it produces a warning: cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C I don't see this at all for this patch on OpenJDK 9. It does appear in the backport to 8u [0], because the aforementioned C code in the old HotSpot build does use the same CFLAGS there. > Thanks, > David > ----- > > > HotSpot webrev is unchanged. > > > > Thanks, > > > [0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-July/005690.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From david.holmes at oracle.com Tue Jul 12 04:01:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 14:01:48 +1000 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> Message-ID: <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> Hi Ivan, On 7/07/2016 2:55 AM, Ivan Gerasimov wrote: > Hello! > > When fixing JDK-8069048 a potential race was overlooked: > 1) Thread A wants to call _endthreadex() and registers itself, > 2) Thread B wants to call exit(), takes its turn and raises the flag > `process_exiting`, > 3) Thread A continues, and gets captured in the loop at 4020, in > SuspendThread(GetCurrentThread()), > 4) Now, the thread B will have to wait for all the registered threads, > including the thread A, which will never wake up. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 > WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ Nit: can we change 'registered_itself" to just "registered" please. Can you explain under what conditions a thread will now reach the self-suspension code. Is that only if an error occurred such that we were unable to register our handle for the process-exiting thread to wait on? If so some commentary on that block seems appropriate - perhaps more appropriate there than back up at the place where it failed to get the handle (as Dan requested). Given we keep missing conditions I'm only cautiously optimistic about this. And I'd like to understand how we still sometimes end up exiting with an "error code" that seems to be the value of an exception! :( Thanks, David > With kind regards, > Ivan > From david.holmes at oracle.com Tue Jul 12 04:20:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 14:20:03 +1000 Subject: RFR(XS): 8161032: GPL header incorrect - address wrong - not swapped In-Reply-To: <552ED192-DB7A-46D0-807F-64C23FC053D2@oracle.com> References: <9B3A2719-0473-4F0C-A60A-61226896D793@oracle.com> <552ED192-DB7A-46D0-807F-64C23FC053D2@oracle.com> Message-ID: Looks good. Thanks, David On 12/07/2016 12:31 AM, Michael Haupt wrote: > ... corrected link for webrev: http://cr.openjdk.java.net/~mhaupt/8161032/webrev.00/ > > Best, > > Michael > >> Am 11.07.2016 um 16:11 schrieb Michael Haupt : >> >> Dear all, >> >> Please review this fix. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161032 >> Webrev: http://javaweb.us.oracle.com/~mhaupt/8161032/webrev/ >> >> As it's a doc-only fix, I have not run any tests. >> >> Thanks, >> >> Michael > From david.holmes at oracle.com Tue Jul 12 04:41:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 14:41:47 +1000 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1630509666.3999193.1468294801972.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> <1630509666.3999193.1468294801972.JavaMail.zimbra@redhat.com> Message-ID: On 12/07/2016 1:40 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Catching up ... >> >> On 11/07/2016 7:05 AM, Andrew Hughes wrote: >>> >>> >>> ----- Original Message ----- >>>>> On Jul 8, 2016, at 2:38 AM, Erik Joelsson >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> This looks good except for the change in toolchain.m4, which looks like >>>>> it >>>>> might actually break cross compilation by overriding the value for >>>>> compiler version for the build compiler using the target compiler. With >>>>> this change we basically have: >>>>> >>>>> if cross compilation >>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) >>>>> else >>>>> ... >>>>> fi >>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) >>>>> >>>>> The problem you are trying to solve is that in the case of not cross >>>>> compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't >>>>> called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call >>>>> in >>>>> the else clause. >>>> >>>> Good catch! I totally missed that when reviewing. >>>> >>>> >>> Yes, good catch! The indenting on the bug report must have confused me. >>> >>> Fixed version: >>> >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot >> >> I was glad to see you realized that parts of the hotspot build (libjsig, >> libdtrace) only deal with C programs not C++ and so don't want and >> should not have a C++ setting passed. But that then begs the question in >> the main build in flags.m4 why we have: >> >> $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" >> >> which again adds a C++ related flags to what should be the C compilation >> flags ?? >> > > You'd think so, but for some reason, the HotSpot build has always called the > C++ compiler flags 'CFLAGS'. There is no JVM_CXXFLAGS. Ah now I recall - this is the CPP -> CXX mess. CFLAGS meant compiler-flags; CPPFLAGS meant pre-processor-flags. People thought CPP meant C++ and changed to CXX. > The same behaviour was true with the old build; we had to pass these options > down to HotSpot in EXTRA_CFLAGS. > > JVM_CFLAGS is the main variable used in the HotSpot build (see make/lib/CompileJvm.gmk). > The only C files in the HotSpot tree are for libsaproc, jsig and DTrace, > all of which are handled by separate makefiles. The only one to use JVM_CFLAGS is > make/lib/CompileDtracePostJvm.gmk, where it is used for a single C++ file, generateJvmOffsets.cpp: > > generateJvmOffsets.cpp_CXXFLAGS := $(JVM_CFLAGS) -mt -xnolib -norunpath, \ > generateJvmOffsetsMain.c_CFLAGS := -library=%none -mt -m64 -norunpath -z nodefs, \ > > Thus, it seems JVM_CFLAGS is JVM_CXXFLAGS in all but name. Thanks for stepping through that. David > If -std=gnu++98 does get passed to the C compiler, it produces a warning: > > cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C > > I don't see this at all for this patch on OpenJDK 9. It does appear in the backport > to 8u [0], because the aforementioned C code in the old HotSpot build does use the > same CFLAGS there. > >> Thanks, >> David >> ----- >> >>> HotSpot webrev is unchanged. >>> >>> Thanks, >>> >> > > [0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-July/005690.html > From michael.haupt at oracle.com Tue Jul 12 08:20:50 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 12 Jul 2016 10:20:50 +0200 Subject: RFR(XS): 8161032: GPL header incorrect - address wrong - not swapped In-Reply-To: References: <9B3A2719-0473-4F0C-A60A-61226896D793@oracle.com> <552ED192-DB7A-46D0-807F-64C23FC053D2@oracle.com> Message-ID: <2E238DA3-8B54-4FD7-A4DA-B0F58DCE3A3A@oracle.com> ... thanks, David and Vladimir! Best, Michael > Am 12.07.2016 um 06:20 schrieb David Holmes : > > Looks good. > > Thanks, > David > > On 12/07/2016 12:31 AM, Michael Haupt wrote: >> ... corrected link for webrev: http://cr.openjdk.java.net/~mhaupt/8161032/webrev.00/ >> >> Best, >> >> Michael >> >>> Am 11.07.2016 um 16:11 schrieb Michael Haupt : >>> >>> Dear all, >>> >>> Please review this fix. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161032 >>> Webrev: http://javaweb.us.oracle.com/~mhaupt/8161032/webrev/ >>> >>> As it's a doc-only fix, I have not run any tests. >>> >>> Thanks, >>> >>> Michael >> -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Tue Jul 12 10:12:25 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Jul 2016 11:12:25 +0100 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> Message-ID: <5784C289.6030002@redhat.com> On 12/07/16 03:21, David Holmes wrote: > This is not a hotspot issue but a Java programming language issue. > Hotspot would never provide a flag that changes the Java programming > language semantics. The performance impact of all-accesses-are- > atomic on 32-bit systems is considerable Not necessarily. There are significant performance implications on some 32-bit systems, but by no means all. And such 32-bit systems are getting rarer -- IMVHO. > so as long as we support 32-bit I don't see this happening > (regardless of what may be discussed on jmm-dev). It would be > unconscionable to have different semantics on 32-bit and 64-bit so > that is not an option either. I wonder if a better solution to this might be to make VarHandle.{get,set}Opaque atomic on all primitive types. This gives us a way to get atomic operations on 32-bit machines without the overhead of volatile accesses. Being able to read a 64-bit counter atomically is very useful. C++ says: [ Note: Atomic operations specifying memory_order_relaxed are relaxed with respect to memory ordering. Implementations must still guarantee that any given atomic access to a particular atomic object be indivisible with respect to all other atomic accesses to that object. ? end note ] But Java says: Unless stated otherwise in the documentation of a factory method, the access modes get and set (if supported) provide atomic access for reference types and all primitives types, with the exception of long and double on 32-bit platforms. I wonder if this divergence between Java and C++ is deliberate. It seems wrong to me. Andrew. From jdcrowley at gmail.com Tue Jul 12 11:50:53 2016 From: jdcrowley at gmail.com (John Crowley) Date: Tue, 12 Jul 2016 07:50:53 -0400 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> Message-ID: John Crowley Westport, CT 203-856-2396 > On Jul 11, 2016, at 10:21 PM, David Holmes wrote: > > Hi John, > > On 7/07/2016 9:29 PM, John Crowley wrote: >> All: >> >> Would like to make a suggestion re the JVM and non-atomic load/store for long and double values since both are 64-bit. (Sec 17.7 of the JLS version 8 - have not been able to find a JLS V9 yet). Did some searching through JSRs and mailing lists, but did not see this addressed - please send me a link if it has been and I just missed it. > > This is not a hotspot issue but a Java programming language issue. Hotspot would never provide a flag that changes the Java programming language semantics. The performance impact of all-accesses-are-atomic on 32-bit systems is considerable so as long as we support 32-bit I don't see this happening (regardless of what may be discussed on jmm-dev). It would be unconscionable to have different semantics on 32-bit and 64-bit so that is not an option either. Certainly not suggesting that Hotspot unilaterally make this change. Would expect it to be discussed, considered through the JSR (or other) process, and coordinated with some future releases of Java and the JVM. Would also need to be discussed and published to the multiple other languages which compile to the JVM. The suggested implementations are intended so that the defaults do not change the current semantics, and the user must choose if the atomic load/store semantics are activated. Agree that the performance hit on 32-bit systems would be dramatic, hence options to operate either way as a developer decision. Expect that the vast majority of Java code is already executing on 64-bit machines, and the current situation requires use of volatile so we are imposing an extra memory barrier (and possibly disallowing some optimizations) where it is not required. Also agree that 32-bit support will be required in the future, especially if the JVM is used in embedded applications or other environments where 64-bit architectures will never be present, so these can choose the non-atomic semantics. Understand, I don?t really like having to make this choice at the JVM level, but feel that it eliminates a "gotcha" in the language and provides the most efficient processing for the vast majority of standard Java executions. IMHO the current situation already has different semantics on 32-bit vs 64-bit architectures. Most 64-bit architectures have atomic load/store of long and double primitives, where 32-bit architectures have split operations - this suggestion is trying to eliminate this difference. > > I also think this is somewhat of a red-herring. If lack of atomic accesses is causing your code a problem then your code is not performing atomic updates of variables - ie modifications to longs/doubles are not being done in a thread-safe way. Making simple reads/writes atomic will not change that - your code will still be broken. Was primarily thinking of situations where only 1 thread writes to the variable, but there are multiple readers. Example, posting currentTimeInMillis when some worker thread completes a stage of a computation (e.g. message sent or received). > >> Right now, in a multi-threaded environment the developer must make these volatile to ensure correct operation - which I would suspect that 95% of Java developers do not realize. (I certainly didn?t for over 20 years!) > > Any introductory Java text worth its salt, and certainly any text on concurrent programming in Java, covers this part of the programming model. Read my last introductory Java text in 1996 (I believe), and was trying to get "Hello, world!" to run - certainly not considering at all the subtle details of multi-threaded programming. Suspect that a large number of Java developers working on standard business applications, who started when all programs were single-threaded anyway, may not realize this point. > >> Worse, in most cases these will in fact be atomic on any 64-bit server, and non-atomic on a 32-bit architecture - so you may suddenly get very strange differences running the same codebase. [Are there any 64-bit JVMs in which these load/store operations are done in 32-bit chunks?] > > Unaligned accesses to 64-bit variables may not be atomic on some architectures. Good point. > > Cheers, > David > ----- > >> I would propose pushing this decision down into the JVM - along roughly this plan: >> >> Define a new JVM option: -DatomicLong=[true|false] >> For any JVM with a 64-bit architecture this would be ignored (or issue a warning if explicitly set to false) >> For a 32-bit JVM, the default would be false (see below) >> If true for a 32-bit JVM, then the JVM itself would execute a memory barrier as required to perform atomic load/store of a long or double from/to application memory. >> >> A JVM option is suggested because there are probably still many applications running on 32-bit servers, and using a lot of long/double variables, that would suffer a major performance hit if the 32-bit JVM suddenly started implementing atomic load/store operations. Examples: financial models, simulations, weather forecasting. Also many applications may not be multi-threaded and would prefer to eliminate the overhead. >> >> Having a default of false preserves the current semantics of a 32-bit JVM. >> >> You could also drop the JVM option and have 32-bit JVMs compiled with two flavors: JVM (old semantics) and JVMAtomic (new semantics). This would eliminate any possible runtime overhead and allow the user to invoke the desired version at runtime. >> >> Best, >> >> >> John Crowley >> Westport, CT >> 203-856-2396 >> >> >> >> From aleksey.shipilev at oracle.com Tue Jul 12 12:21:36 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 12 Jul 2016 15:21:36 +0300 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> Message-ID: <5784E0D0.70009@oracle.com> On 07/12/2016 02:50 PM, John Crowley wrote: >> On Jul 11, 2016, at 10:21 PM, David Holmes >> wrote: >> On 7/07/2016 9:29 PM, John Crowley wrote: >>> Would like to make a suggestion re the JVM and non-atomic >>> load/store for long and double values since both are 64-bit. >>> (Sec 17.7 of the JLS version 8 - have not been able to find a JLS >>> V9 yet). Did some searching through JSRs and mailing lists, but >>> did not see this addressed - please send me a link if it has been >>> and I just missed it. In Hotspot, there is an experimental -XX:+AlwaysAtomicAccesses flag that turns long/double accesses to be single-copy atomic. Not sure it works properly in interpreter though. You may build on that. The sound counter-argument that I heard against enabling long/double atomic accesses is the interaction with value types. If we make all present types access-atomic, and have to retract that back when larger-than-machine-word value types come in, that would be bad. Since this long/double spec change is at best Java 10, we better off seeing how it plays out with value types. Thanks, -Aleksey From dl at cs.oswego.edu Tue Jul 12 12:29:52 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 12 Jul 2016 08:29:52 -0400 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: <5784E0D0.70009@oracle.com> References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> <5784E0D0.70009@oracle.com> Message-ID: <5784E2C0.1070408@cs.oswego.edu> On 07/12/2016 08:21 AM, Aleksey Shipilev wrote: > On 07/12/2016 02:50 PM, John Crowley wrote: >>> On Jul 11, 2016, at 10:21 PM, David Holmes >>> wrote: >>> On 7/07/2016 9:29 PM, John Crowley wrote: >>>> Would like to make a suggestion re the JVM and non-atomic >>>> load/store for long and double values since both are 64-bit. >>>> (Sec 17.7 of the JLS version 8 - have not been able to find a JLS >>>> V9 yet). Did some searching through JSRs and mailing lists, but >>>> did not see this addressed - please send me a link if it has been >>>> and I just missed it. > > In Hotspot, there is an experimental -XX:+AlwaysAtomicAccesses flag that > turns long/double accesses to be single-copy atomic. Not sure it works > properly in interpreter though. You may build on that. > > The sound counter-argument that I heard against enabling long/double > atomic accesses is the interaction with value types. If we make all > present types access-atomic, and have to retract that back when > larger-than-machine-word value types come in, that would be bad. Since > this long/double spec change is at best Java 10, we better off seeing > how it plays out with value types. > Yes, thanks. That's an accurate synopsis of discussions on the jmm-dev list in 2014. (http://mail.openjdk.java.net/pipermail/jmm-dev/) In the mean time, we do need to make a clean-up pass on VarHandle javadocs/specs, that now include some remnants of previous designs and are missing a few clarifications. -Doug From aph at redhat.com Tue Jul 12 12:35:56 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Jul 2016 13:35:56 +0100 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> Message-ID: <5784E42C.60007@redhat.com> On 07/07/16 12:29, John Crowley wrote: > Would like to make a suggestion re the JVM and non-atomic load/store > for long and double values since both are 64-bit. (Sec 17.7 of the > JLS version 8 - have not been able to find a JLS V9 yet). Did some > searching through JSRs and mailing lists, but did not see this > addressed - please send me a link if it has been and I just missed > it. > > Right now, in a multi-threaded environment the developer must make > these volatile to ensure correct operation - which I would suspect > that 95% of Java developers do not realize. (I certainly didn?t for > over 20 years!) After more discussion on jmm-dev, it's clear that VarHandle.{get,set}Opaque() will do exactly what you want: guarantee atomic accesses to longs and doubles without the overhead of volatile accesses. I think that's enough for practical usage in Java. Andrew. From paul.sandoz at oracle.com Tue Jul 12 13:43:07 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Jul 2016 15:43:07 +0200 Subject: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors Re: ByteBuffer views, alignment, word tearing In-Reply-To: <5783CA94.7010000@redhat.com> References: <5783B65F.7040007@redhat.com> <5783CA94.7010000@redhat.com> Message-ID: <5DB0B7AA-2CFF-4481-9214-0FE633733E6B@oracle.com> Hi Andrew, Would you mind formally reviewing the patches? Including hotspot-dev as i have updated a hotspot test so should probably push to hs. I rebased to hs and fixed a silly bug in generated heap view buffers that were incorrectly calculating the unsafe byte offset: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access-hotspot/webrev/ JPRT runs for core and hotspot pass. > On 11 Jul 2016, at 18:34, Andrew Haley wrote: > > On 11/07/16 17:04, Paul Sandoz wrote: > >> I opted to directly use Unsafe rather than defer. I am not sure it?s >> always possible to defer to the underlying buffer since its >> positional and order state is mutable. > > Eww. The view has its own position, and the byte ordering is fixed > when the view is created. The wrapped byte buffer is in a protected > field, and the view is a package-private class so it can't be > subclassed by the user. So I would have thought that could be made to > work, but but never mind, I can see you've gone a long way down this > road already. Yes, and i laid some ground work in a previous fix to enable support for Unsafe double addressing mode on heap and direct buffers, with a grander plan to try and unify some of the implementations (careful performance analysis is required for direct buffers that access the base field whose value is null). > > The SPARC regression is very odd: I would have thought that if it's > broken here it would also be broken in HeapByteBuffer.getLong(). > I did not get a chance to look at the generated code, so there could be a number of factors involved. My feeling is the three alignment checks are causing more issues on SPARC (perhaps combined less efficient addressing calculations [*], with loop unrolling), which led to the suggestion of a modifying the unaligned Unsafe methods to take an extra arg that is the constant offset to check alignment, thus could be hoisted out of a loop making constant strides. Paul. [*] some work on x86 was recently done by Roland to improve this area From aph at redhat.com Tue Jul 12 17:33:28 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Jul 2016 18:33:28 +0100 Subject: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors Re: ByteBuffer views, alignment, word tearing In-Reply-To: <5DB0B7AA-2CFF-4481-9214-0FE633733E6B@oracle.com> References: <5783B65F.7040007@redhat.com> <5783CA94.7010000@redhat.com> <5DB0B7AA-2CFF-4481-9214-0FE633733E6B@oracle.com> Message-ID: <578529E8.5070900@redhat.com> Hi, On 12/07/16 14:43, Paul Sandoz wrote: > Would you mind formally reviewing the patches? > > Including hotspot-dev as i have updated a hotspot test so should > probably push to hs. > > I rebased to hs and fixed a silly bug in generated heap view buffers > that were incorrectly calculating the unsafe byte offset: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/ > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access-hotspot/webrev/ > > JPRT runs for core and hotspot pass. These are fine. I checked that the word-tearing problems were fixed too, and the generated code looks good. Thanks, Andrew. From gnu.andrew at redhat.com Tue Jul 12 18:21:12 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 12 Jul 2016 14:21:12 -0400 (EDT) Subject: RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6 In-Reply-To: <20D15A8D-1C0A-4D44-9E83-A99B38622A6C@oracle.com> References: <20160711184513.GA1485@redhat.com> <20D15A8D-1C0A-4D44-9E83-A99B38622A6C@oracle.com> Message-ID: <1655965499.4239256.1468347672234.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 11, 2016, at 2:45 PM, Omair Majid wrote: > > > > Hi, > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161145 > > Webrev: > > http://cr.openjdk.java.net/~omajid/webrevs/8161145-gcc6-min-max-macros/00/ > > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide > All .cpp files include precompiled.hpp as the first include line. > > Also, fixing include order problems by tweaking the order of the > includes rarely leads to a happy ending. I wonder whether > runtime/test_arguments.cpp is already suffering from such tweaking, as > it presently #includes unittest.hpp before > utilities/globalDefinitions.hpp, which seems odd. This was my worry as well when I saw Omair's patch. It fixes the issue for now, but it seems a very fragile solution. > > I think a different approach is needed. Perhaps don't provided the > poisoned definitions at all. Or maybe we can use blue paint, e.g. > > #define min min > #define max max > The workaround that currently works for me is: diff -r b515beb3b4ad src/share/vm/utilities/globalDefinitions.hpp --- a/src/share/vm/utilities/globalDefinitions.hpp Thu Jul 07 18:40:53 2016 +0100 +++ b/src/share/vm/utilities/globalDefinitions.hpp Tue Jul 12 19:13:51 2016 +0100 @@ -1163,8 +1163,10 @@ #undef min #endif +#ifndef _GLIBCXX_STDLIB_H #define max(a,b) Do_not_use_max_use_MAX2_instead #define min(a,b) Do_not_use_min_use_MIN2_instead +#endif // It is necessary to use templates here. Having normal overloaded // functions does not work because it is necessary to provide both 32- _GLIBCXX_STDLIB_H only exists in GCC 6. Earlier versions use stdlib.h from the C library. Thus this seems to provide the solution of only disabling those macros only on GCC >= 6 where they conflict with the functions max and min defined by this C++ stdlib.h wrapper (see stdlib.h changes in [0]) $ find /usr/lib/gcc/x86_64-pc-linux-gnu -name 'stdlib.h' /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/tr1/stdlib.h /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/tr1/stdlib.h /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/tr1/stdlib.h $ grep -r '_GLIBCXX_STDLIB_H' /usr/lib/gcc/x86_64-pc-linux-gnu/ /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h:#ifndef _GLIBCXX_STDLIB_H /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h:#define _GLIBCXX_STDLIB_H 1 /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h:#endif // _GLIBCXX_STDLIB_H [0] https://gcc.gnu.org/gcc-6/porting_to.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From kim.barrett at oracle.com Tue Jul 12 21:23:39 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 12 Jul 2016 17:23:39 -0400 Subject: RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6 In-Reply-To: <1655965499.4239256.1468347672234.JavaMail.zimbra@redhat.com> References: <20160711184513.GA1485@redhat.com> <20D15A8D-1C0A-4D44-9E83-A99B38622A6C@oracle.com> <1655965499.4239256.1468347672234.JavaMail.zimbra@redhat.com> Message-ID: <27891E85-5736-4D44-8D79-1C44B01499EE@oracle.com> > On Jul 12, 2016, at 2:21 PM, Andrew Hughes wrote: > The workaround that currently works for me is: > > diff -r b515beb3b4ad src/share/vm/utilities/globalDefinitions.hpp > --- a/src/share/vm/utilities/globalDefinitions.hpp Thu Jul 07 18:40:53 2016 +0100 > +++ b/src/share/vm/utilities/globalDefinitions.hpp Tue Jul 12 19:13:51 2016 +0100 > @@ -1163,8 +1163,10 @@ > #undef min > #endif > > +#ifndef _GLIBCXX_STDLIB_H > #define max(a,b) Do_not_use_max_use_MAX2_instead > #define min(a,b) Do_not_use_min_use_MIN2_instead > +#endif > > // It is necessary to use templates here. Having normal overloaded > // functions does not work because it is necessary to provide both 32- > > > _GLIBCXX_STDLIB_H only exists in GCC 6. Earlier versions use stdlib.h from the > C library. Thus this seems to provide the solution of only disabling > those macros only on GCC >= 6 where they conflict with the functions > max and min defined by this C++ stdlib.h wrapper (see stdlib.h changes > in [0]) Since when does define / declare min or max? To me, that seems like a bug in this wrapper. > $ find /usr/lib/gcc/x86_64-pc-linux-gnu -name 'stdlib.h' > /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/tr1/stdlib.h > /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/tr1/stdlib.h > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/tr1/stdlib.h > > $ grep -r '_GLIBCXX_STDLIB_H' /usr/lib/gcc/x86_64-pc-linux-gnu/ > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h:#ifndef _GLIBCXX_STDLIB_H > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h:#define _GLIBCXX_STDLIB_H 1 > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h:#endif // _GLIBCXX_STDLIB_H > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From goetz.lindenmaier at sap.com Tue Jul 12 21:58:24 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Jul 2016 21:58:24 +0000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> Message-ID: <65a0127fd1b94e879d648547df6c621a@DEWDFE13DE09.global.corp.sap> Hi, I implemented a prototype of the include model proposed by Volker. I tested this so far on linux_x86_64, aix_ppc64 and linux_ppc64. I'll test it on the other OSes/CPUs I have available tomorrow. The direcitves -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_MODEL_x86_64 -DTARGET_ARCH_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_OS_ARCH_linux_x86 are replaced by -DTARGET_OS=linux -DTARGET_CPU=x86. (OS and CPU are used for vm_version.cpp) The macros proposed by Volker are in utilities/macros.hpp. There are some places where above TARGET_... macros are used for other purposes than guarding the includes, I replaced them to use the other platform dependent macros already defined. I also removed all headers carying _64 or _32 in their name. There were three on ppc. As I learned there is no PPC32 port any more, so changing this should be fine. I found one on x86 (stubRoutines...hpp). I merged it and use LP64 guards for the differences. I think this is acceptable as the files are rather small and it's the only case. The adlc generated files all had suffix _64/_32 which I removed. These are not significant, either. All this normalizing edits can be found in this webrev. It would be useful to apply them anyways: http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-cleanups/ The real change is here: http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-newIncludes/ I had to do a tweak for the #define linux=1 in macros.hpp. Please have a look at these changes. Also, check whether this works fine with the IDE of your choice :) If this finds appreciation, I'll open an Enhancement and make a real webrev/RFR. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of dean.long at oracle.com > Sent: Wednesday, July 06, 2016 7:49 AM > To: hotspot-dev at openjdk.java.net > Subject: Re: s390x port progress: patch queue for hotspot assembled. > > On 7/5/16 10:42 PM, dean.long at oracle.com wrote: > > > On 7/4/16 2:59 PM, David Holmes wrote: > > > >> On 5/07/2016 7:44 AM, Stefan Karlsson wrote: > >>> On 2016-07-04 23:03, David Holmes wrote: > >>>> On 5/07/2016 12:07 AM, Volker Simonis wrote: > >>>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley > wrote: > >>>>>> On 04/07/16 12:22, David Holmes wrote: > >>>>>> > >>>>>>> Unless the files are included into more than one other file then > >>>>>>> adding > >>>>>>> a level of indirection doesn't really help anything. > >>>>>> > >>>>>> I'm not sure what this means. > >>>>>> > >>>>>>> But I don't see why the platform part of the name needs to be kept > >>>>>>> when > >>>>>>> it is already part of the path? > >>>>>> > >>>>>> When switching between files in an editor, one doesn't usually > >>>>>> type in the full path, but the filename. I'd be very sad to lose > >>>>>> that, and I think that unique filenames are a nice thing to have. > >>>>>> > >>>>> > >>>>> In Emacs you can try the uniquify [1] extension which would solve the > >>>>> problem. I already use it for editing various hotspot version (i.e. > >>>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is probably > >>>>> not a practical solution for everybody :) > >>>>> > >>>>> [1] > >>>>> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify. > html > >>>>> > >>>>> > >>>>>> Andrew. > >>>>>> > >>>>> > >>>>> We could try something like this (adapted from [2]) although I'm not > >>>>> sure if that's really a good solution (i.e. if it is treated right by > >>>>> various IDEs): > >>>>> > >>>>> include_test.cpp > >>>>> ============ > >>>>> > >>>>> #define xstr(x) #x > >>>>> #define str(x) xstr(x) > >>>>> #define sub(x) x > >>>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) > >>>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) > >>>>> #define os_cpu_header(x) str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) > >>>>> > >>>>> #include cpu_header(assembler) > >>>>> #include os_header(assembler) > >>>>> #include os_cpu_header(assembler) > >>>> > >>>> This is the parameterization I thought was not possible. For some > >>>> reason I thought #define'd values could not be used within #include > >>>> directives. > >>> > >>> FWIW, we tried a similar approach when includeDB was removed, but > >>> abandoned it because of the problem described below with the 'linux' > >>> define. > >> > >> Give we have in the build (eg for linux x86) presently: > >> > >> -DTARGET_OS_FAMILY_linux > >> -DTARGET_ARCH_MODEL_x86_32 > >> -DTARGET_ARCH_x86 > >> -DTARGET_OS_ARCH_MODEL_linux_x86_32 > >> -DTARGET_OS_ARCH_linux_x86 > >> > >> I wonder if we can simply replace the above with: > >> > >> -DTARGET_OS_FAMILY=linux > >> -DTARGET_ARCH_MODEL=x86_32 > >> -DTARGET_ARCH=x86 > >> -DTARGET_OS_ARCH_MODEL=linux_x86_32 > >> -DTARGET_OS_ARCH=linux_x86 > >> > >> and use those variables for the include directives? > >> > > > > I remember experimenting with that idea, but gave up because I > > couldn't get it work. > > What I ended up doing was something like this: > > > > #*include* C1_LIRGENERATOR_MD_HPP > > > > Oops, let's try that again: > > #include C1_LIRGENERATOR_MD_HPP > > where, using x86 as an example, macros like C1_LIRGENERATOR_MD_HPP > are > defined in globalDefinitions_x86.hpp: > > #define C1_LIRGENERATOR_MD_HPP "c1_LIRGenerator_x86.hpp" > > dl > > > I don't know if this confuses IDEs or not. > > > > dl > > > >> David > >> > >>> StefanK > >>> > >>>> > >>>> This looks very workable to me. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> assembler_s390x.hpp > >>>>> ================ > >>>>> #pragma message ("including \"assembler_s390x.h\"") > >>>>> > >>>>> assembler_linux.hpp > >>>>> =============== > >>>>> #pragma message ("including \"assembler_linux.h\"") > >>>>> > >>>>> assembler_linux_s390x.hpp > >>>>> ==================== > >>>>> #pragma message ("including \"assembler_linux_s390x.h\"") > >>>>> > >>>>> > >>>>> It works on all the platforms I have tested so far (see below) except > >>>>> Linux where it needs some tweaks (see comments below): > >>>>> > >>>>> > >>>>> Solaris: > >>>>> ====== > >>>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E > include_test.cpp > >>>>> #1 "include_test.cpp" > >>>>> #1 "assembler_s390x.hpp" > >>>>> #pragma message ( "including \"assembler_s390x.h\"" ) > >>>>> #1 "assembler_linux.hpp" > >>>>> #pragma message ( "including \"assembler_linux.h\"" ) > >>>>> #1 "assembler_linux_s390x.hpp" > >>>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) > >>>>> > >>>>> AIX: > >>>>> === > >>>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c > >>>>> include_test.cpp > >>>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown "pragma > >>>>> message" is specified. > >>>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma > >>>>> message" is specified. > >>>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown > >>>>> "pragma message" is specified. > >>>>> > >>>>> MacOS X > >>>>> ======= > >>>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>> In file included from include_test.cpp:8: > >>>>> ./assembler_s390x.hpp:1:9: warning: including "assembler_s390x.h" > >>>>> [-W#pragma-messages] > >>>>> #pragma message ("including \"assembler_s390x.h\"") > >>>>> ^ > >>>>> In file included from include_test.cpp:9: > >>>>> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" > >>>>> [-W#pragma-messages] > >>>>> #pragma message ("including \"assembler_linux.h\"") > >>>>> ^ > >>>>> In file included from include_test.cpp:10: > >>>>> ./assembler_linux_s390x.hpp:1:9: warning: including > >>>>> "assembler_linux_s390x.h" [-W#pragma-messages] > >>>>> #pragma message ("including \"assembler_linux_s390x.h\"") > >>>>> ^ > >>>>> 3 warnings generated. > >>>>> > >>>>> Windows: > >>>>> ======= > >>>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x > >>>>> -DOS=linux -c include_test. > >>>>> cpp > >>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for > >>>>> x64 > >>>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>>> > >>>>> include_test.cpp > >>>>> including "assembler_s390x.h" > >>>>> including "assembler_linux.h" > >>>>> including "assembler_linux_s390x.h" > >>>>> > >>>>> HPUX: > >>>>> ===== > >>>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>> Info #4087-D: "including \"assembler_s390x.h\"" > >>>>> > >>>>> Info #4087-D: "including \"assembler_linux.h\"" > >>>>> > >>>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" > >>>>> > >>>>> Linux: > >>>>> ===== > >>>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or > >>>>> directory > >>>>> compilation terminated. > >>>>> > >>>>> The problem on Linux is that 'linux' is already predefined to '1' but > >>>>> that could be easily fixed for example by slightly changing the name > >>>>> or by adding the underscore to the definiton of the OS macro (i.e. > >>>>> -DOS=_linux). > >>>>> > >>>>> As I said, I'm still not sure if this looks nice? I just wanted to > >>>>> post my findings for discussion :) > >>>>> > >>>>> Regards, > >>>>> Volker > >>>>> > >>>>> [2] > >>>>> http://stackoverflow.com/questions/1852652/how-can-i-include-a- > file-whose-name-is-built-up-from-a-macro > >>>>> > >>>>> > >>>>> > >>> > > From jdcrowley at gmail.com Tue Jul 12 22:42:14 2016 From: jdcrowley at gmail.com (John Crowley) Date: Tue, 12 Jul 2016 18:42:14 -0400 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: <5784E42C.60007@redhat.com> References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> <5784E42C.60007@redhat.com> Message-ID: John Crowley Westport, CT 203-856-2396 > On Jul 12, 2016, at 8:35 AM, Andrew Haley wrote: > > On 07/07/16 12:29, John Crowley wrote: > >> Would like to make a suggestion re the JVM and non-atomic load/store >> for long and double values since both are 64-bit. (Sec 17.7 of the >> JLS version 8 - have not been able to find a JLS V9 yet). Did some >> searching through JSRs and mailing lists, but did not see this >> addressed - please send me a link if it has been and I just missed >> it. >> >> Right now, in a multi-threaded environment the developer must make >> these volatile to ensure correct operation - which I would suspect >> that 95% of Java developers do not realize. (I certainly didn?t for >> over 20 years!) > > After more discussion on jmm-dev, it's clear that > VarHandle.{get,set}Opaque() will do exactly what you want: guarantee > atomic accesses to longs and doubles without the overhead of volatile > accesses. I think that's enough for practical usage in Java. > Hi Andrew, Thanks for the info, but this just seems like we?re going in the wrong direction. Yes, it will technically work, and be slightly more efficient, but we?ve managed to turn a simple get/put of a primitive into a function call that will litter the code forever. IMHO if not already, then certainly within the next 10 years, 99% of Java code will execute on 64-bit platforms. It would seem better to migrate the language specification and JVM towards the cleanest possible code in that environment rather than add code everywhere in case of the 1% situation. Yes, the 1% case must be supported, but it can be with existing language constructs (volatile, {get,set}Opaque, AtomicLong/Double), or the JVM option as suggested [which keeps the source code clean]. Someone in the chain mentioned an experimental -XX:+AlwaysAtomicAccesses flag, which sounds like it would do exactly what is needed without requiring anything in the source. Would really rather move towards making long and double operate the same as object references and all other primitives instead of be special cases. John > Andrew. From david.holmes at oracle.com Wed Jul 13 03:43:02 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Jul 2016 13:43:02 +1000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <65a0127fd1b94e879d648547df6c621a@DEWDFE13DE09.global.corp.sap> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> <65a0127fd1b94e879d648547df6c621a@DEWDFE13DE09.global.corp.sap> Message-ID: Hi Goetz, Thanks for doing this! I think it looks good. Only nit ... On 13/07/2016 7:58 AM, Lindenmaier, Goetz wrote: > Hi, > > I implemented a prototype of the include model proposed by Volker. > I tested this so far on linux_x86_64, aix_ppc64 and linux_ppc64. > I'll test it on the other OSes/CPUs I have available tomorrow. > > The direcitves > -DTARGET_OS_FAMILY_linux > -DTARGET_ARCH_MODEL_x86_64 > -DTARGET_ARCH_x86 > -DTARGET_OS_ARCH_MODEL_linux_x86_64 > -DTARGET_OS_ARCH_linux_x86 > are replaced by -DTARGET_OS=linux -DTARGET_CPU=x86. > (OS and CPU are used for vm_version.cpp) Is there a reason you didn't do what I had suggested with the above and change the last _ to = ? I thought my suggestion would avoid the issue with the LINUX=1 problem. ?? I was going to test this out with our other platforms but unfortunately the patch didn't apply on latest jdk9/hs. Thanks, David > The macros proposed by Volker are in utilities/macros.hpp. > > There are some places where above TARGET_... macros are used for other > purposes than guarding the includes, I replaced them to use the other > platform dependent macros already defined. > > I also removed all headers carying _64 or _32 in their name. > There were three on ppc. As I learned there is no PPC32 port > any more, so changing this should be fine. I found one on x86 (stubRoutines...hpp). > I merged it and use LP64 guards for the differences. I think this is > acceptable as the files are rather small and it's the only case. > > The adlc generated files all had suffix _64/_32 which I removed. > These are not significant, either. > > All this normalizing edits can be found in this webrev. It would be > useful to apply them anyways: > http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-cleanups/ > The real change is here: > http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-newIncludes/ > I had to do a tweak for the #define linux=1 in macros.hpp. > > Please have a look at these changes. Also, check whether this > works fine with the IDE of your choice :) > > If this finds appreciation, I'll open an Enhancement and make a > real webrev/RFR. > > Best regards, > Goetz. > > > > > > > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of dean.long at oracle.com >> Sent: Wednesday, July 06, 2016 7:49 AM >> To: hotspot-dev at openjdk.java.net >> Subject: Re: s390x port progress: patch queue for hotspot assembled. >> >> On 7/5/16 10:42 PM, dean.long at oracle.com wrote: >> >>> On 7/4/16 2:59 PM, David Holmes wrote: >>> >>>> On 5/07/2016 7:44 AM, Stefan Karlsson wrote: >>>>> On 2016-07-04 23:03, David Holmes wrote: >>>>>> On 5/07/2016 12:07 AM, Volker Simonis wrote: >>>>>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley >> wrote: >>>>>>>> On 04/07/16 12:22, David Holmes wrote: >>>>>>>> >>>>>>>>> Unless the files are included into more than one other file then >>>>>>>>> adding >>>>>>>>> a level of indirection doesn't really help anything. >>>>>>>> >>>>>>>> I'm not sure what this means. >>>>>>>> >>>>>>>>> But I don't see why the platform part of the name needs to be kept >>>>>>>>> when >>>>>>>>> it is already part of the path? >>>>>>>> >>>>>>>> When switching between files in an editor, one doesn't usually >>>>>>>> type in the full path, but the filename. I'd be very sad to lose >>>>>>>> that, and I think that unique filenames are a nice thing to have. >>>>>>>> >>>>>>> >>>>>>> In Emacs you can try the uniquify [1] extension which would solve the >>>>>>> problem. I already use it for editing various hotspot version (i.e. >>>>>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is probably >>>>>>> not a practical solution for everybody :) >>>>>>> >>>>>>> [1] >>>>>>> >> https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify. >> html >>>>>>> >>>>>>> >>>>>>>> Andrew. >>>>>>>> >>>>>>> >>>>>>> We could try something like this (adapted from [2]) although I'm not >>>>>>> sure if that's really a good solution (i.e. if it is treated right by >>>>>>> various IDEs): >>>>>>> >>>>>>> include_test.cpp >>>>>>> ============ >>>>>>> >>>>>>> #define xstr(x) #x >>>>>>> #define str(x) xstr(x) >>>>>>> #define sub(x) x >>>>>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) >>>>>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) >>>>>>> #define os_cpu_header(x) str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) >>>>>>> >>>>>>> #include cpu_header(assembler) >>>>>>> #include os_header(assembler) >>>>>>> #include os_cpu_header(assembler) >>>>>> >>>>>> This is the parameterization I thought was not possible. For some >>>>>> reason I thought #define'd values could not be used within #include >>>>>> directives. >>>>> >>>>> FWIW, we tried a similar approach when includeDB was removed, but >>>>> abandoned it because of the problem described below with the 'linux' >>>>> define. >>>> >>>> Give we have in the build (eg for linux x86) presently: >>>> >>>> -DTARGET_OS_FAMILY_linux >>>> -DTARGET_ARCH_MODEL_x86_32 >>>> -DTARGET_ARCH_x86 >>>> -DTARGET_OS_ARCH_MODEL_linux_x86_32 >>>> -DTARGET_OS_ARCH_linux_x86 >>>> >>>> I wonder if we can simply replace the above with: >>>> >>>> -DTARGET_OS_FAMILY=linux >>>> -DTARGET_ARCH_MODEL=x86_32 >>>> -DTARGET_ARCH=x86 >>>> -DTARGET_OS_ARCH_MODEL=linux_x86_32 >>>> -DTARGET_OS_ARCH=linux_x86 >>>> >>>> and use those variables for the include directives? >>>> >>> >>> I remember experimenting with that idea, but gave up because I >>> couldn't get it work. >>> What I ended up doing was something like this: >>> >>> #*include* C1_LIRGENERATOR_MD_HPP >>> >> >> Oops, let's try that again: >> >> #include C1_LIRGENERATOR_MD_HPP >> >> where, using x86 as an example, macros like C1_LIRGENERATOR_MD_HPP >> are >> defined in globalDefinitions_x86.hpp: >> >> #define C1_LIRGENERATOR_MD_HPP "c1_LIRGenerator_x86.hpp" >> >> dl >> >>> I don't know if this confuses IDEs or not. >>> >>> dl >>> >>>> David >>>> >>>>> StefanK >>>>> >>>>>> >>>>>> This looks very workable to me. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> assembler_s390x.hpp >>>>>>> ================ >>>>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>>>> >>>>>>> assembler_linux.hpp >>>>>>> =============== >>>>>>> #pragma message ("including \"assembler_linux.h\"") >>>>>>> >>>>>>> assembler_linux_s390x.hpp >>>>>>> ==================== >>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>>>> >>>>>>> >>>>>>> It works on all the platforms I have tested so far (see below) except >>>>>>> Linux where it needs some tweaks (see comments below): >>>>>>> >>>>>>> >>>>>>> Solaris: >>>>>>> ====== >>>>>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E >> include_test.cpp >>>>>>> #1 "include_test.cpp" >>>>>>> #1 "assembler_s390x.hpp" >>>>>>> #pragma message ( "including \"assembler_s390x.h\"" ) >>>>>>> #1 "assembler_linux.hpp" >>>>>>> #pragma message ( "including \"assembler_linux.h\"" ) >>>>>>> #1 "assembler_linux_s390x.hpp" >>>>>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) >>>>>>> >>>>>>> AIX: >>>>>>> === >>>>>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c >>>>>>> include_test.cpp >>>>>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>>>>>> message" is specified. >>>>>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>>>>>> message" is specified. >>>>>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >>>>>>> "pragma message" is specified. >>>>>>> >>>>>>> MacOS X >>>>>>> ======= >>>>>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>> In file included from include_test.cpp:8: >>>>>>> ./assembler_s390x.hpp:1:9: warning: including "assembler_s390x.h" >>>>>>> [-W#pragma-messages] >>>>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>>>> ^ >>>>>>> In file included from include_test.cpp:9: >>>>>>> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" >>>>>>> [-W#pragma-messages] >>>>>>> #pragma message ("including \"assembler_linux.h\"") >>>>>>> ^ >>>>>>> In file included from include_test.cpp:10: >>>>>>> ./assembler_linux_s390x.hpp:1:9: warning: including >>>>>>> "assembler_linux_s390x.h" [-W#pragma-messages] >>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>>>> ^ >>>>>>> 3 warnings generated. >>>>>>> >>>>>>> Windows: >>>>>>> ======= >>>>>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x >>>>>>> -DOS=linux -c include_test. >>>>>>> cpp >>>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for >>>>>>> x64 >>>>>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>>>>> >>>>>>> include_test.cpp >>>>>>> including "assembler_s390x.h" >>>>>>> including "assembler_linux.h" >>>>>>> including "assembler_linux_s390x.h" >>>>>>> >>>>>>> HPUX: >>>>>>> ===== >>>>>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>> Info #4087-D: "including \"assembler_s390x.h\"" >>>>>>> >>>>>>> Info #4087-D: "including \"assembler_linux.h\"" >>>>>>> >>>>>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" >>>>>>> >>>>>>> Linux: >>>>>>> ===== >>>>>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or >>>>>>> directory >>>>>>> compilation terminated. >>>>>>> >>>>>>> The problem on Linux is that 'linux' is already predefined to '1' but >>>>>>> that could be easily fixed for example by slightly changing the name >>>>>>> or by adding the underscore to the definiton of the OS macro (i.e. >>>>>>> -DOS=_linux). >>>>>>> >>>>>>> As I said, I'm still not sure if this looks nice? I just wanted to >>>>>>> post my findings for discussion :) >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> [2] >>>>>>> http://stackoverflow.com/questions/1852652/how-can-i-include-a- >> file-whose-name-is-built-up-from-a-macro >>>>>>> >>>>>>> >>>>>>> >>>>> >>> > From david.holmes at oracle.com Wed Jul 13 03:53:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Jul 2016 13:53:57 +1000 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> <5784E42C.60007@redhat.com> Message-ID: <7e2ee2b8-0e97-4dd0-e252-d551c21b40f5@oracle.com> John, I think the point is that the Java language specification for this is not likely to change any time soon (certainly not 9, probably not even 10), and when it does change it will be to accommodate future constructs like value types - which raise the question of whether uniform atomic access should extend to types larger than 64-bit. Meanwhile if you want to experiment there is the VM flag. Additionally the VarHandle API provides an extra-linguistic mechanism for defining and applying access modes beyond those provided in the Java programming language. They are verbose to write but will be (JIT) compiled into direct access code. Cheers, David On 13/07/2016 8:42 AM, John Crowley wrote: > > > John Crowley > Westport, CT > 203-856-2396 > > > > >> On Jul 12, 2016, at 8:35 AM, Andrew Haley wrote: >> >> On 07/07/16 12:29, John Crowley wrote: >> >>> Would like to make a suggestion re the JVM and non-atomic load/store >>> for long and double values since both are 64-bit. (Sec 17.7 of the >>> JLS version 8 - have not been able to find a JLS V9 yet). Did some >>> searching through JSRs and mailing lists, but did not see this >>> addressed - please send me a link if it has been and I just missed >>> it. >>> >>> Right now, in a multi-threaded environment the developer must make >>> these volatile to ensure correct operation - which I would suspect >>> that 95% of Java developers do not realize. (I certainly didn?t for >>> over 20 years!) >> >> After more discussion on jmm-dev, it's clear that >> VarHandle.{get,set}Opaque() will do exactly what you want: guarantee >> atomic accesses to longs and doubles without the overhead of volatile >> accesses. I think that's enough for practical usage in Java. >> > Hi Andrew, > > Thanks for the info, but this just seems like we?re going in the wrong direction. > > Yes, it will technically work, and be slightly more efficient, but we?ve managed to turn a simple get/put of a primitive into a function call that will litter the code forever. > > IMHO if not already, then certainly within the next 10 years, 99% of Java code will execute on 64-bit platforms. It would seem better to migrate the language specification and JVM towards the cleanest possible code in that environment rather than add code everywhere in case of the 1% situation. Yes, the 1% case must be supported, but it can be with existing language constructs (volatile, {get,set}Opaque, AtomicLong/Double), or the JVM option as suggested [which keeps the source code clean]. > > Someone in the chain mentioned an experimental -XX:+AlwaysAtomicAccesses flag, which sounds like it would do exactly what is needed without requiring anything in the source. > > Would really rather move towards making long and double operate the same as object references and all other primitives instead of be special cases. > > John > >> Andrew. > From goetz.lindenmaier at sap.com Wed Jul 13 07:00:52 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 13 Jul 2016 07:00:52 +0000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> <65a0127fd1b94e879d648547df6c621a@DEWDFE13DE09.global.corp.sap> Message-ID: <0d6753a9474f4181a15bd6a4637686a0@DEWDFE13DE09.global.corp.sap> Hi David, > Is there a reason you didn't do what I had suggested with the above and > change the last _ to = ? * I think the names should match what is in the path, therefore I think CPU is better than ARCH (we have src/cpu/x86). * I left out "FAMILY". I don't see any gain in this part of the name. * Three of them are superfluous anyways. I thought about calling them INCLUDE_OS and INCLUDE_CPU, that better indicates what they are meant for. I also thought about only defining them in the macros.hpp file. We have -DLINUX -DAMD64 / -DAIX -DPPC64 etc. on the command line to identify which port to compile. > I thought my suggestion would avoid the issue > with the LINUX=1 problem. ? Do you want me to do -DTARGET_OS_FAMILY=_linux ? with '_'? The problem is that there is lower case #define linux=1. I don't think we should define things with leading '_', they are often used by the system headers / compilers. I rebased my changes, that did not cause any conflicts. I also downloaded the changesets and patched them into my repo, that works too. You first need to apply the cleanups, then the new includes. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 13. Juli 2016 05:43 > To: Lindenmaier, Goetz ; > 'dean.long at oracle.com' ; hotspot- > dev at openjdk.java.net > Subject: Re: s390x port progress: patch queue for hotspot assembled. > > Hi Goetz, > > Thanks for doing this! I think it looks good. Only nit ... > > On 13/07/2016 7:58 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > I implemented a prototype of the include model proposed by Volker. > > I tested this so far on linux_x86_64, aix_ppc64 and linux_ppc64. > > I'll test it on the other OSes/CPUs I have available tomorrow. > > > > The direcitves > > -DTARGET_OS_FAMILY_linux > > -DTARGET_ARCH_MODEL_x86_64 > > -DTARGET_ARCH_x86 > > -DTARGET_OS_ARCH_MODEL_linux_x86_64 > > -DTARGET_OS_ARCH_linux_x86 > > are replaced by -DTARGET_OS=linux -DTARGET_CPU=x86. > > (OS and CPU are used for vm_version.cpp) > > Is there a reason you didn't do what I had suggested with the above and > change the last _ to = ? I thought my suggestion would avoid the issue > with the LINUX=1 problem. ?? > > I was going to test this out with our other platforms but unfortunately > the patch didn't apply on latest jdk9/hs. > > Thanks, > David > > > The macros proposed by Volker are in utilities/macros.hpp. > > > > There are some places where above TARGET_... macros are used for other > > purposes than guarding the includes, I replaced them to use the other > > platform dependent macros already defined. > > > > I also removed all headers carying _64 or _32 in their name. > > There were three on ppc. As I learned there is no PPC32 port > > any more, so changing this should be fine. I found one on x86 > (stubRoutines...hpp). > > I merged it and use LP64 guards for the differences. I think this is > > acceptable as the files are rather small and it's the only case. > > > > The adlc generated files all had suffix _64/_32 which I removed. > > These are not significant, either. > > > > All this normalizing edits can be found in this webrev. It would be > > useful to apply them anyways: > > http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-cleanups/ > > The real change is here: > > http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev- > newIncludes/ > > I had to do a tweak for the #define linux=1 in macros.hpp. > > > > Please have a look at these changes. Also, check whether this > > works fine with the IDE of your choice :) > > > > If this finds appreciation, I'll open an Enhancement and make a > > real webrev/RFR. > > > > Best regards, > > Goetz. > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >> Behalf Of dean.long at oracle.com > >> Sent: Wednesday, July 06, 2016 7:49 AM > >> To: hotspot-dev at openjdk.java.net > >> Subject: Re: s390x port progress: patch queue for hotspot assembled. > >> > >> On 7/5/16 10:42 PM, dean.long at oracle.com wrote: > >> > >>> On 7/4/16 2:59 PM, David Holmes wrote: > >>> > >>>> On 5/07/2016 7:44 AM, Stefan Karlsson wrote: > >>>>> On 2016-07-04 23:03, David Holmes wrote: > >>>>>> On 5/07/2016 12:07 AM, Volker Simonis wrote: > >>>>>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley > >> wrote: > >>>>>>>> On 04/07/16 12:22, David Holmes wrote: > >>>>>>>> > >>>>>>>>> Unless the files are included into more than one other file then > >>>>>>>>> adding > >>>>>>>>> a level of indirection doesn't really help anything. > >>>>>>>> > >>>>>>>> I'm not sure what this means. > >>>>>>>> > >>>>>>>>> But I don't see why the platform part of the name needs to be > kept > >>>>>>>>> when > >>>>>>>>> it is already part of the path? > >>>>>>>> > >>>>>>>> When switching between files in an editor, one doesn't usually > >>>>>>>> type in the full path, but the filename. I'd be very sad to lose > >>>>>>>> that, and I think that unique filenames are a nice thing to have. > >>>>>>>> > >>>>>>> > >>>>>>> In Emacs you can try the uniquify [1] extension which would solve > the > >>>>>>> problem. I already use it for editing various hotspot version (i.e. > >>>>>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is > probably > >>>>>>> not a practical solution for everybody :) > >>>>>>> > >>>>>>> [1] > >>>>>>> > >> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify. > >> html > >>>>>>> > >>>>>>> > >>>>>>>> Andrew. > >>>>>>>> > >>>>>>> > >>>>>>> We could try something like this (adapted from [2]) although I'm > not > >>>>>>> sure if that's really a good solution (i.e. if it is treated right by > >>>>>>> various IDEs): > >>>>>>> > >>>>>>> include_test.cpp > >>>>>>> ============ > >>>>>>> > >>>>>>> #define xstr(x) #x > >>>>>>> #define str(x) xstr(x) > >>>>>>> #define sub(x) x > >>>>>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) > >>>>>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) > >>>>>>> #define os_cpu_header(x) > str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) > >>>>>>> > >>>>>>> #include cpu_header(assembler) > >>>>>>> #include os_header(assembler) > >>>>>>> #include os_cpu_header(assembler) > >>>>>> > >>>>>> This is the parameterization I thought was not possible. For some > >>>>>> reason I thought #define'd values could not be used within #include > >>>>>> directives. > >>>>> > >>>>> FWIW, we tried a similar approach when includeDB was removed, but > >>>>> abandoned it because of the problem described below with the 'linux' > >>>>> define. > >>>> > >>>> Give we have in the build (eg for linux x86) presently: > >>>> > >>>> -DTARGET_OS_FAMILY_linux > >>>> -DTARGET_ARCH_MODEL_x86_32 > >>>> -DTARGET_ARCH_x86 > >>>> -DTARGET_OS_ARCH_MODEL_linux_x86_32 > >>>> -DTARGET_OS_ARCH_linux_x86 > >>>> > >>>> I wonder if we can simply replace the above with: > >>>> > >>>> -DTARGET_OS_FAMILY=linux > >>>> -DTARGET_ARCH_MODEL=x86_32 > >>>> -DTARGET_ARCH=x86 > >>>> -DTARGET_OS_ARCH_MODEL=linux_x86_32 > >>>> -DTARGET_OS_ARCH=linux_x86 > >>>> > >>>> and use those variables for the include directives? > >>>> > >>> > >>> I remember experimenting with that idea, but gave up because I > >>> couldn't get it work. > >>> What I ended up doing was something like this: > >>> > >>> #*include* C1_LIRGENERATOR_MD_HPP > >>> > >> > >> Oops, let's try that again: > >> > >> #include C1_LIRGENERATOR_MD_HPP > >> > >> where, using x86 as an example, macros like C1_LIRGENERATOR_MD_HPP > >> are > >> defined in globalDefinitions_x86.hpp: > >> > >> #define C1_LIRGENERATOR_MD_HPP "c1_LIRGenerator_x86.hpp" > >> > >> dl > >> > >>> I don't know if this confuses IDEs or not. > >>> > >>> dl > >>> > >>>> David > >>>> > >>>>> StefanK > >>>>> > >>>>>> > >>>>>> This looks very workable to me. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>>> assembler_s390x.hpp > >>>>>>> ================ > >>>>>>> #pragma message ("including \"assembler_s390x.h\"") > >>>>>>> > >>>>>>> assembler_linux.hpp > >>>>>>> =============== > >>>>>>> #pragma message ("including \"assembler_linux.h\"") > >>>>>>> > >>>>>>> assembler_linux_s390x.hpp > >>>>>>> ==================== > >>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") > >>>>>>> > >>>>>>> > >>>>>>> It works on all the platforms I have tested so far (see below) except > >>>>>>> Linux where it needs some tweaks (see comments below): > >>>>>>> > >>>>>>> > >>>>>>> Solaris: > >>>>>>> ====== > >>>>>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E > >> include_test.cpp > >>>>>>> #1 "include_test.cpp" > >>>>>>> #1 "assembler_s390x.hpp" > >>>>>>> #pragma message ( "including \"assembler_s390x.h\"" ) > >>>>>>> #1 "assembler_linux.hpp" > >>>>>>> #pragma message ( "including \"assembler_linux.h\"" ) > >>>>>>> #1 "assembler_linux_s390x.hpp" > >>>>>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) > >>>>>>> > >>>>>>> AIX: > >>>>>>> === > >>>>>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c > >>>>>>> include_test.cpp > >>>>>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown > "pragma > >>>>>>> message" is specified. > >>>>>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma > >>>>>>> message" is specified. > >>>>>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown > >>>>>>> "pragma message" is specified. > >>>>>>> > >>>>>>> MacOS X > >>>>>>> ======= > >>>>>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>>>> In file included from include_test.cpp:8: > >>>>>>> ./assembler_s390x.hpp:1:9: warning: including > "assembler_s390x.h" > >>>>>>> [-W#pragma-messages] > >>>>>>> #pragma message ("including \"assembler_s390x.h\"") > >>>>>>> ^ > >>>>>>> In file included from include_test.cpp:9: > >>>>>>> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" > >>>>>>> [-W#pragma-messages] > >>>>>>> #pragma message ("including \"assembler_linux.h\"") > >>>>>>> ^ > >>>>>>> In file included from include_test.cpp:10: > >>>>>>> ./assembler_linux_s390x.hpp:1:9: warning: including > >>>>>>> "assembler_linux_s390x.h" [-W#pragma-messages] > >>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") > >>>>>>> ^ > >>>>>>> 3 warnings generated. > >>>>>>> > >>>>>>> Windows: > >>>>>>> ======= > >>>>>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x > >>>>>>> -DOS=linux -c include_test. > >>>>>>> cpp > >>>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for > >>>>>>> x64 > >>>>>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>>>>> > >>>>>>> include_test.cpp > >>>>>>> including "assembler_s390x.h" > >>>>>>> including "assembler_linux.h" > >>>>>>> including "assembler_linux_s390x.h" > >>>>>>> > >>>>>>> HPUX: > >>>>>>> ===== > >>>>>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>>>> Info #4087-D: "including \"assembler_s390x.h\"" > >>>>>>> > >>>>>>> Info #4087-D: "including \"assembler_linux.h\"" > >>>>>>> > >>>>>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" > >>>>>>> > >>>>>>> Linux: > >>>>>>> ===== > >>>>>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or > >>>>>>> directory > >>>>>>> compilation terminated. > >>>>>>> > >>>>>>> The problem on Linux is that 'linux' is already predefined to '1' but > >>>>>>> that could be easily fixed for example by slightly changing the name > >>>>>>> or by adding the underscore to the definiton of the OS macro (i.e. > >>>>>>> -DOS=_linux). > >>>>>>> > >>>>>>> As I said, I'm still not sure if this looks nice? I just wanted to > >>>>>>> post my findings for discussion :) > >>>>>>> > >>>>>>> Regards, > >>>>>>> Volker > >>>>>>> > >>>>>>> [2] > >>>>>>> http://stackoverflow.com/questions/1852652/how-can-i-include- > a- > >> file-whose-name-is-built-up-from-a-macro > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>> > > From aph at redhat.com Wed Jul 13 08:20:18 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jul 2016 09:20:18 +0100 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> <5784E42C.60007@redhat.com> Message-ID: <5785F9C2.6000005@redhat.com> On 12/07/16 23:42, John Crowley wrote: >> On Jul 12, 2016, at 8:35 AM, Andrew Haley wrote: >> >> On 07/07/16 12:29, John Crowley wrote: >>> >>> Right now, in a multi-threaded environment the developer must make >>> these volatile to ensure correct operation - which I would suspect >>> that 95% of Java developers do not realize. (I certainly didn?t for >>> over 20 years!) >> >> After more discussion on jmm-dev, it's clear that >> VarHandle.{get,set}Opaque() will do exactly what you want: guarantee >> atomic accesses to longs and doubles without the overhead of volatile >> accesses. I think that's enough for practical usage in Java. > > Thanks for the info, but this just seems like we?re going in the > wrong direction. > > Yes, it will technically work, and be slightly more efficient, but > we?ve managed to turn a simple get/put of a primitive into a > function call that will litter the code forever. But is it that simple? It's a racy access to a variable. IMO it's not a terrible idea to give a reader warning that something odd is happening. I wouldn't have thought that such accesses were very common in any code base. > Someone in the chain mentioned an experimental > -XX:+AlwaysAtomicAccesses flag, which sounds like it would do > exactly what is needed without requiring anything in the source. > > Would really rather move towards making long and double operate the > same as object references and all other primitives instead of be > special cases. Sure. You're not the only one to have made this observation, and that opinion might eventually prevail. However, there are 32-bit platforms, particularly in the embedded space, where long and double accesses would be significantly penalized. If the worst problem is a little bit of clutter in the source code around racy accesses I reckon we're not doing that badly. Andrew. From paul.sandoz at oracle.com Wed Jul 13 08:57:49 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 13 Jul 2016 10:57:49 +0200 Subject: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors Re: ByteBuffer views, alignment, word tearing In-Reply-To: <578529E8.5070900@redhat.com> References: <5783B65F.7040007@redhat.com> <5783CA94.7010000@redhat.com> <5DB0B7AA-2CFF-4481-9214-0FE633733E6B@oracle.com> <578529E8.5070900@redhat.com> Message-ID: <177D9EE1-4B3A-47FA-94A9-557313659C52@oracle.com> > On 12 Jul 2016, at 19:33, Andrew Haley wrote: > > Hi, > > On 12/07/16 14:43, Paul Sandoz wrote: > >> Would you mind formally reviewing the patches? >> >> Including hotspot-dev as i have updated a hotspot test so should >> probably push to hs. >> >> I rebased to hs and fixed a silly bug in generated heap view buffers >> that were incorrectly calculating the unsafe byte offset: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/ >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access-hotspot/webrev/ >> >> JPRT runs for core and hotspot pass. > > These are fine. I checked that the word-tearing problems were fixed > too, and the generated code looks good. > Thanks for reviewing and checking. It occurred to me that we don?t actually mention the atomicity properties of the ByteBuffer implementations when accessing binary data directly or via the views. We probably should using @implNote, but as another issue. Paul. From jdcrowley at gmail.com Wed Jul 13 12:57:22 2016 From: jdcrowley at gmail.com (John Crowley) Date: Wed, 13 Jul 2016 08:57:22 -0400 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: <7e2ee2b8-0e97-4dd0-e252-d551c21b40f5@oracle.com> References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> <5784E42C.60007@redhat.com> <7e2ee2b8-0e97-4dd0-e252-d551c21b40f5@oracle.com> Message-ID: <86B0EEBD-346D-4CC2-94EA-B7F23E8F7987@computer.org> John Crowley Westport, CT 203-856-2396 David, > On Jul 12, 2016, at 11:53 PM, David Holmes wrote: > > John, > > I think the point is that the Java language specification for this is not likely to change any time soon (certainly not 9, probably not even 10), and when it does change it will be to accommodate future constructs like value types - which raise the question of whether uniform atomic access should extend to types larger than 64-bit. > Agree that nothing will change for several Java releases. Just feel that this is an historical inconsistency, the future world will be almost entirely 64-bit architectures, and every app will be multi-threaded, so that handling the increasingly rare 32-bit environment at the JVM level is a cleaner approach. Understand that value types may add some additional feedback to this discussion, so some experience there will be good. > Meanwhile if you want to experiment there is the VM flag. Yes, this does look good. > > Additionally the VarHandle API provides an extra-linguistic mechanism for defining and applying access modes beyond those provided in the Java programming language. They are verbose to write but will be (JIT) compiled into direct access code. Got it - just hate to clutter up the source code. > > Cheers, > David Thanks for the insights, John > > On 13/07/2016 8:42 AM, John Crowley wrote: >> >> >> John Crowley >> Westport, CT >> 203-856-2396 >> >> >> >> >>> On Jul 12, 2016, at 8:35 AM, Andrew Haley wrote: >>> >>> On 07/07/16 12:29, John Crowley wrote: >>> >>>> Would like to make a suggestion re the JVM and non-atomic load/store >>>> for long and double values since both are 64-bit. (Sec 17.7 of the >>>> JLS version 8 - have not been able to find a JLS V9 yet). Did some >>>> searching through JSRs and mailing lists, but did not see this >>>> addressed - please send me a link if it has been and I just missed >>>> it. >>>> >>>> Right now, in a multi-threaded environment the developer must make >>>> these volatile to ensure correct operation - which I would suspect >>>> that 95% of Java developers do not realize. (I certainly didn?t for >>>> over 20 years!) >>> >>> After more discussion on jmm-dev, it's clear that >>> VarHandle.{get,set}Opaque() will do exactly what you want: guarantee >>> atomic accesses to longs and doubles without the overhead of volatile >>> accesses. I think that's enough for practical usage in Java. >>> >> Hi Andrew, >> >> Thanks for the info, but this just seems like we?re going in the wrong direction. >> >> Yes, it will technically work, and be slightly more efficient, but we?ve managed to turn a simple get/put of a primitive into a function call that will litter the code forever. >> >> IMHO if not already, then certainly within the next 10 years, 99% of Java code will execute on 64-bit platforms. It would seem better to migrate the language specification and JVM towards the cleanest possible code in that environment rather than add code everywhere in case of the 1% situation. Yes, the 1% case must be supported, but it can be with existing language constructs (volatile, {get,set}Opaque, AtomicLong/Double), or the JVM option as suggested [which keeps the source code clean]. >> >> Someone in the chain mentioned an experimental -XX:+AlwaysAtomicAccesses flag, which sounds like it would do exactly what is needed without requiring anything in the source. >> >> Would really rather move towards making long and double operate the same as object references and all other primitives instead of be special cases. >> >> John >> >>> Andrew. >> From jdcrowley at gmail.com Wed Jul 13 13:23:28 2016 From: jdcrowley at gmail.com (John Crowley) Date: Wed, 13 Jul 2016 09:23:28 -0400 Subject: Make load/store of 64-bit long and double atomic In-Reply-To: <5785F9C2.6000005@redhat.com> References: <4E29117D-735B-445E-8C57-F047E5B00712@computer.org> <5784E42C.60007@redhat.com> <5785F9C2.6000005@redhat.com> Message-ID: <661159AD-EB95-4E69-8128-8683EF2131B1@computer.org> All: Some comments below, but I feel that at this time all of the points are on the table (and I?ve learned a few things!) I?m glad to continue the discussion, but don?t want to waste anyone?s time so also OK to consider this thread closed - your choice. Best to all, John Crowley Westport, CT 203-856-2396 > On Jul 13, 2016, at 4:20 AM, Andrew Haley wrote: > > On 12/07/16 23:42, John Crowley wrote: >>> On Jul 12, 2016, at 8:35 AM, Andrew Haley wrote: >>> >>> On 07/07/16 12:29, John Crowley wrote: >>>> >>>> Right now, in a multi-threaded environment the developer must make >>>> these volatile to ensure correct operation - which I would suspect >>>> that 95% of Java developers do not realize. (I certainly didn?t for >>>> over 20 years!) >>> >>> After more discussion on jmm-dev, it's clear that >>> VarHandle.{get,set}Opaque() will do exactly what you want: guarantee >>> atomic accesses to longs and doubles without the overhead of volatile >>> accesses. I think that's enough for practical usage in Java. >> >> Thanks for the info, but this just seems like we?re going in the >> wrong direction. >> >> Yes, it will technically work, and be slightly more efficient, but >> we?ve managed to turn a simple get/put of a primitive into a >> function call that will litter the code forever. > > But is it that simple? It's a racy access to a variable. IMO it's > not a terrible idea to give a reader warning that something odd is > happening. I wouldn't have thought that such accesses were very > common in any code base. You are correct in that observation. I?m mainly concerned that this is an inconsistency in the handling of primitives, and not needed in the world of 64-bit machines. > >> Someone in the chain mentioned an experimental >> -XX:+AlwaysAtomicAccesses flag, which sounds like it would do >> exactly what is needed without requiring anything in the source. >> >> Would really rather move towards making long and double operate the >> same as object references and all other primitives instead of be >> special cases. > > Sure. You're not the only one to have made this observation, and that > opinion might eventually prevail. However, there are 32-bit > platforms, particularly in the embedded space, where long and double > accesses would be significantly penalized. If the worst problem is a > little bit of clutter in the source code around racy accesses I reckon > we're not doing that badly. Understand, but think it is cleaner to say that the standard is atomic access but that a JVM flag exists to support the deprecated non-atomic access if required. Again, over multiple releases of Java and JVM. > > Andrew. Thanks for your insights, John From aph at redhat.com Wed Jul 13 14:24:28 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jul 2016 15:24:28 +0100 Subject: RFR: 8159467: AArch64: Enable compact strings Message-ID: <57864F1C.7050508@redhat.com> Compact strings are now complete enough to be enabled by default. The patch also includes the deletion of a couple of incorrect lines code which supposedly disabled biased locking. This code never worked, never did anything, and biased locking has always been on by default. http://cr.openjdk.java.net/~aph/8159467 Andrew. From aleksey.shipilev at oracle.com Wed Jul 13 14:47:22 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 13 Jul 2016 17:47:22 +0300 Subject: RFR: 8159467: AArch64: Enable compact strings In-Reply-To: <57864F1C.7050508@redhat.com> References: <57864F1C.7050508@redhat.com> Message-ID: <5786547A.8010905@oracle.com> On 07/13/2016 05:24 PM, Andrew Haley wrote: > Compact strings are now complete enough to be enabled by default. > > The patch also includes the deletion of a couple of incorrect lines > code which supposedly disabled biased locking. This code never worked, > never did anything, and biased locking has always been on by default. Come again? Are you saying that 77 define_pd_global(bool, UseBiasedLocking, false); ...did not disable BiasedLocking on AArch64? > http://cr.openjdk.java.net/~aph/8159467 +1 Thanks, -Aleksey From aph at redhat.com Wed Jul 13 14:51:55 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jul 2016 15:51:55 +0100 Subject: RFR: 8159467: AArch64: Enable compact strings In-Reply-To: <5786547A.8010905@oracle.com> References: <57864F1C.7050508@redhat.com> <5786547A.8010905@oracle.com> Message-ID: <5786558B.1050302@redhat.com> On 13/07/16 15:47, Aleksey Shipilev wrote: > On 07/13/2016 05:24 PM, Andrew Haley wrote: >> Compact strings are now complete enough to be enabled by default. >> >> The patch also includes the deletion of a couple of incorrect lines >> code which supposedly disabled biased locking. This code never worked, >> never did anything, and biased locking has always been on by default. > > Come again? Are you saying that > > 77 define_pd_global(bool, UseBiasedLocking, false); > > ...did not disable BiasedLocking on AArch64? Yeah. Really not. BiasedLocking is a product flag, not a product_pd flag, so it didn't do anything. >> http://cr.openjdk.java.net/~aph/8159467 > > +1 Thanks, Andrew. From coleen.phillimore at oracle.com Wed Jul 13 15:30:25 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Jul 2016 11:30:25 -0400 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <0d6753a9474f4181a15bd6a4637686a0@DEWDFE13DE09.global.corp.sap> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> <65a0127fd1b94e879d648547df6c621a@DEWDFE13DE09.global.corp.sap> <0d6753a9474f4181a15bd6a4637686a0@DEWDFE13DE09.global.corp.sap> Message-ID: <122c1ef9-8448-e7ea-588d-6151c9688dd8@oracle.com> Goetz, I like the cleanups in your patch but when I grep for TARGET_OS_FAMILY, I see this in jvm.cpp (which you changed) but also mutex.cpp and vmStructs.cpp which you didn't change. In mutex.cpp, this includes files that are all empty! #ifdef TARGET_OS_FAMILY_linux # include "mutex_linux.inline.hpp" #endif #ifdef TARGET_OS_FAMILY_solaris # include "mutex_solaris.inline.hpp" #endif #ifdef TARGET_OS_FAMILY_windows # include "mutex_windows.inline.hpp" #endif #ifdef TARGET_OS_FAMILY_bsd # include "mutex_bsd.inline.hpp" #endif Thanks, Coleen On 7/13/16 3:00 AM, Lindenmaier, Goetz wrote: > Hi David, > >> Is there a reason you didn't do what I had suggested with the above and >> change the last _ to = ? > * I think the names should match what is in the path, therefore I think > CPU is better than ARCH (we have src/cpu/x86). > * I left out "FAMILY". I don't see any gain in this part of the name. I agree. > * Three of them are superfluous anyways. > I thought about calling them INCLUDE_OS and INCLUDE_CPU, that > better indicates what they are meant for. > I also thought about only defining them in the macros.hpp file. We > have -DLINUX -DAMD64 / -DAIX -DPPC64 etc. on the command line > to identify which port to compile. > >> I thought my suggestion would avoid the issue >> with the LINUX=1 problem. ? > Do you want me to do -DTARGET_OS_FAMILY=_linux ? with '_'? > The problem is that there is lower case #define linux=1. > I don't think we should define things with leading '_', they are often > used by the system headers / compilers. > > I rebased my changes, that did not cause any conflicts. I also downloaded > the changesets and patched them into my repo, that works too. > You first need to apply the cleanups, then the new includes. > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 13. Juli 2016 05:43 >> To: Lindenmaier, Goetz ; >> 'dean.long at oracle.com' ; hotspot- >> dev at openjdk.java.net >> Subject: Re: s390x port progress: patch queue for hotspot assembled. >> >> Hi Goetz, >> >> Thanks for doing this! I think it looks good. Only nit ... >> >> On 13/07/2016 7:58 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I implemented a prototype of the include model proposed by Volker. >>> I tested this so far on linux_x86_64, aix_ppc64 and linux_ppc64. >>> I'll test it on the other OSes/CPUs I have available tomorrow. >>> >>> The direcitves >>> -DTARGET_OS_FAMILY_linux >>> -DTARGET_ARCH_MODEL_x86_64 >>> -DTARGET_ARCH_x86 >>> -DTARGET_OS_ARCH_MODEL_linux_x86_64 >>> -DTARGET_OS_ARCH_linux_x86 >>> are replaced by -DTARGET_OS=linux -DTARGET_CPU=x86. >>> (OS and CPU are used for vm_version.cpp) >> Is there a reason you didn't do what I had suggested with the above and >> change the last _ to = ? I thought my suggestion would avoid the issue >> with the LINUX=1 problem. ?? >> >> I was going to test this out with our other platforms but unfortunately >> the patch didn't apply on latest jdk9/hs. >> >> Thanks, >> David >> >>> The macros proposed by Volker are in utilities/macros.hpp. >>> >>> There are some places where above TARGET_... macros are used for other >>> purposes than guarding the includes, I replaced them to use the other >>> platform dependent macros already defined. >>> >>> I also removed all headers carying _64 or _32 in their name. >>> There were three on ppc. As I learned there is no PPC32 port >>> any more, so changing this should be fine. I found one on x86 >> (stubRoutines...hpp). >>> I merged it and use LP64 guards for the differences. I think this is >>> acceptable as the files are rather small and it's the only case. >>> >>> The adlc generated files all had suffix _64/_32 which I removed. >>> These are not significant, either. >>> >>> All this normalizing edits can be found in this webrev. It would be >>> useful to apply them anyways: >>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-cleanups/ >>> The real change is here: >>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev- >> newIncludes/ >>> I had to do a tweak for the #define linux=1 in macros.hpp. >>> >>> Please have a look at these changes. Also, check whether this >>> works fine with the IDE of your choice :) >>> >>> If this finds appreciation, I'll open an Enhancement and make a >>> real webrev/RFR. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of dean.long at oracle.com >>>> Sent: Wednesday, July 06, 2016 7:49 AM >>>> To: hotspot-dev at openjdk.java.net >>>> Subject: Re: s390x port progress: patch queue for hotspot assembled. >>>> >>>> On 7/5/16 10:42 PM, dean.long at oracle.com wrote: >>>> >>>>> On 7/4/16 2:59 PM, David Holmes wrote: >>>>> >>>>>> On 5/07/2016 7:44 AM, Stefan Karlsson wrote: >>>>>>> On 2016-07-04 23:03, David Holmes wrote: >>>>>>>> On 5/07/2016 12:07 AM, Volker Simonis wrote: >>>>>>>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley >>>> wrote: >>>>>>>>>> On 04/07/16 12:22, David Holmes wrote: >>>>>>>>>> >>>>>>>>>>> Unless the files are included into more than one other file then >>>>>>>>>>> adding >>>>>>>>>>> a level of indirection doesn't really help anything. >>>>>>>>>> I'm not sure what this means. >>>>>>>>>> >>>>>>>>>>> But I don't see why the platform part of the name needs to be >> kept >>>>>>>>>>> when >>>>>>>>>>> it is already part of the path? >>>>>>>>>> When switching between files in an editor, one doesn't usually >>>>>>>>>> type in the full path, but the filename. I'd be very sad to lose >>>>>>>>>> that, and I think that unique filenames are a nice thing to have. >>>>>>>>>> >>>>>>>>> In Emacs you can try the uniquify [1] extension which would solve >> the >>>>>>>>> problem. I already use it for editing various hotspot version (i.e. >>>>>>>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is >> probably >>>>>>>>> not a practical solution for everybody :) >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >> https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify. >>>> html >>>>>>>>> >>>>>>>>>> Andrew. >>>>>>>>>> >>>>>>>>> We could try something like this (adapted from [2]) although I'm >> not >>>>>>>>> sure if that's really a good solution (i.e. if it is treated right by >>>>>>>>> various IDEs): >>>>>>>>> >>>>>>>>> include_test.cpp >>>>>>>>> ============ >>>>>>>>> >>>>>>>>> #define xstr(x) #x >>>>>>>>> #define str(x) xstr(x) >>>>>>>>> #define sub(x) x >>>>>>>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) >>>>>>>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) >>>>>>>>> #define os_cpu_header(x) >> str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) >>>>>>>>> #include cpu_header(assembler) >>>>>>>>> #include os_header(assembler) >>>>>>>>> #include os_cpu_header(assembler) >>>>>>>> This is the parameterization I thought was not possible. For some >>>>>>>> reason I thought #define'd values could not be used within #include >>>>>>>> directives. >>>>>>> FWIW, we tried a similar approach when includeDB was removed, but >>>>>>> abandoned it because of the problem described below with the 'linux' >>>>>>> define. >>>>>> Give we have in the build (eg for linux x86) presently: >>>>>> >>>>>> -DTARGET_OS_FAMILY_linux >>>>>> -DTARGET_ARCH_MODEL_x86_32 >>>>>> -DTARGET_ARCH_x86 >>>>>> -DTARGET_OS_ARCH_MODEL_linux_x86_32 >>>>>> -DTARGET_OS_ARCH_linux_x86 >>>>>> >>>>>> I wonder if we can simply replace the above with: >>>>>> >>>>>> -DTARGET_OS_FAMILY=linux >>>>>> -DTARGET_ARCH_MODEL=x86_32 >>>>>> -DTARGET_ARCH=x86 >>>>>> -DTARGET_OS_ARCH_MODEL=linux_x86_32 >>>>>> -DTARGET_OS_ARCH=linux_x86 >>>>>> >>>>>> and use those variables for the include directives? >>>>>> >>>>> I remember experimenting with that idea, but gave up because I >>>>> couldn't get it work. >>>>> What I ended up doing was something like this: >>>>> >>>>> #*include* C1_LIRGENERATOR_MD_HPP >>>>> >>>> Oops, let's try that again: >>>> >>>> #include C1_LIRGENERATOR_MD_HPP >>>> >>>> where, using x86 as an example, macros like C1_LIRGENERATOR_MD_HPP >>>> are >>>> defined in globalDefinitions_x86.hpp: >>>> >>>> #define C1_LIRGENERATOR_MD_HPP "c1_LIRGenerator_x86.hpp" >>>> >>>> dl >>>> >>>>> I don't know if this confuses IDEs or not. >>>>> >>>>> dl >>>>> >>>>>> David >>>>>> >>>>>>> StefanK >>>>>>> >>>>>>>> This looks very workable to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> assembler_s390x.hpp >>>>>>>>> ================ >>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>>>>>> >>>>>>>>> assembler_linux.hpp >>>>>>>>> =============== >>>>>>>>> #pragma message ("including \"assembler_linux.h\"") >>>>>>>>> >>>>>>>>> assembler_linux_s390x.hpp >>>>>>>>> ==================== >>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>>>>>> >>>>>>>>> >>>>>>>>> It works on all the platforms I have tested so far (see below) except >>>>>>>>> Linux where it needs some tweaks (see comments below): >>>>>>>>> >>>>>>>>> >>>>>>>>> Solaris: >>>>>>>>> ====== >>>>>>>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E >>>> include_test.cpp >>>>>>>>> #1 "include_test.cpp" >>>>>>>>> #1 "assembler_s390x.hpp" >>>>>>>>> #pragma message ( "including \"assembler_s390x.h\"" ) >>>>>>>>> #1 "assembler_linux.hpp" >>>>>>>>> #pragma message ( "including \"assembler_linux.h\"" ) >>>>>>>>> #1 "assembler_linux_s390x.hpp" >>>>>>>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) >>>>>>>>> >>>>>>>>> AIX: >>>>>>>>> === >>>>>>>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c >>>>>>>>> include_test.cpp >>>>>>>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >> "pragma >>>>>>>>> message" is specified. >>>>>>>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>>>>>>>> message" is specified. >>>>>>>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >>>>>>>>> "pragma message" is specified. >>>>>>>>> >>>>>>>>> MacOS X >>>>>>>>> ======= >>>>>>>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>>>> In file included from include_test.cpp:8: >>>>>>>>> ./assembler_s390x.hpp:1:9: warning: including >> "assembler_s390x.h" >>>>>>>>> [-W#pragma-messages] >>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>>>>>> ^ >>>>>>>>> In file included from include_test.cpp:9: >>>>>>>>> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" >>>>>>>>> [-W#pragma-messages] >>>>>>>>> #pragma message ("including \"assembler_linux.h\"") >>>>>>>>> ^ >>>>>>>>> In file included from include_test.cpp:10: >>>>>>>>> ./assembler_linux_s390x.hpp:1:9: warning: including >>>>>>>>> "assembler_linux_s390x.h" [-W#pragma-messages] >>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>>>>>> ^ >>>>>>>>> 3 warnings generated. >>>>>>>>> >>>>>>>>> Windows: >>>>>>>>> ======= >>>>>>>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x >>>>>>>>> -DOS=linux -c include_test. >>>>>>>>> cpp >>>>>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for >>>>>>>>> x64 >>>>>>>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>>>>>>> >>>>>>>>> include_test.cpp >>>>>>>>> including "assembler_s390x.h" >>>>>>>>> including "assembler_linux.h" >>>>>>>>> including "assembler_linux_s390x.h" >>>>>>>>> >>>>>>>>> HPUX: >>>>>>>>> ===== >>>>>>>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>>>> Info #4087-D: "including \"assembler_s390x.h\"" >>>>>>>>> >>>>>>>>> Info #4087-D: "including \"assembler_linux.h\"" >>>>>>>>> >>>>>>>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" >>>>>>>>> >>>>>>>>> Linux: >>>>>>>>> ===== >>>>>>>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or >>>>>>>>> directory >>>>>>>>> compilation terminated. >>>>>>>>> >>>>>>>>> The problem on Linux is that 'linux' is already predefined to '1' but >>>>>>>>> that could be easily fixed for example by slightly changing the name >>>>>>>>> or by adding the underscore to the definiton of the OS macro (i.e. >>>>>>>>> -DOS=_linux). >>>>>>>>> >>>>>>>>> As I said, I'm still not sure if this looks nice? I just wanted to >>>>>>>>> post my findings for discussion :) >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> [2] >>>>>>>>> http://stackoverflow.com/questions/1852652/how-can-i-include- >> a- >>>> file-whose-name-is-built-up-from-a-macro >>>>>>>>> >>>>>>>>> From gnu.andrew at redhat.com Wed Jul 13 19:12:33 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Jul 2016 15:12:33 -0400 (EDT) Subject: RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6 In-Reply-To: <27891E85-5736-4D44-8D79-1C44B01499EE@oracle.com> References: <20160711184513.GA1485@redhat.com> <20D15A8D-1C0A-4D44-9E83-A99B38622A6C@oracle.com> <1655965499.4239256.1468347672234.JavaMail.zimbra@redhat.com> <27891E85-5736-4D44-8D79-1C44B01499EE@oracle.com> Message-ID: <1461764727.4609223.1468437153322.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 12, 2016, at 2:21 PM, Andrew Hughes wrote: > > The workaround that currently works for me is: > > > > diff -r b515beb3b4ad src/share/vm/utilities/globalDefinitions.hpp > > --- a/src/share/vm/utilities/globalDefinitions.hpp Thu Jul 07 18:40:53 2016 > > +0100 > > +++ b/src/share/vm/utilities/globalDefinitions.hpp Tue Jul 12 19:13:51 2016 > > +0100 > > @@ -1163,8 +1163,10 @@ > > #undef min > > #endif > > > > +#ifndef _GLIBCXX_STDLIB_H > > #define max(a,b) Do_not_use_max_use_MAX2_instead > > #define min(a,b) Do_not_use_min_use_MIN2_instead > > +#endif > > > > // It is necessary to use templates here. Having normal overloaded > > // functions does not work because it is necessary to provide both 32- > > > > > > _GLIBCXX_STDLIB_H only exists in GCC 6. Earlier versions use stdlib.h from > > the > > C library. Thus this seems to provide the solution of only disabling > > those macros only on GCC >= 6 where they conflict with the functions > > max and min defined by this C++ stdlib.h wrapper (see stdlib.h changes > > in [0]) > > Since when does define / declare min or max? To me, that seems > like a bug in this wrapper. It doesn't; it's defined in . The stdlib.h C++ wrapper is new to GCC 6, and thus so is the define, so we can use it to just disable these macros on that version. It also wouldn't surprise me that the error is down to one of these new wrapper headers bringing in other C++ headers, including limits. I can't find the exact path for such an inclusion, but this issue only shows up on GCC 6, where the wrapper headers are present. Including on earlier versions just uses the C header, not . > > > $ find /usr/lib/gcc/x86_64-pc-linux-gnu -name 'stdlib.h' > > /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/tr1/stdlib.h > > /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/tr1/stdlib.h > > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h > > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/tr1/stdlib.h > > > > $ grep -r '_GLIBCXX_STDLIB_H' /usr/lib/gcc/x86_64-pc-linux-gnu/ > > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h:#ifndef > > _GLIBCXX_STDLIB_H > > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h:#define > > _GLIBCXX_STDLIB_H 1 > > /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20160306/include/g++-v6/stdlib.h:#endif > > // _GLIBCXX_STDLIB_H > > > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From david.holmes at oracle.com Thu Jul 14 00:14:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jul 2016 10:14:56 +1000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <0d6753a9474f4181a15bd6a4637686a0@DEWDFE13DE09.global.corp.sap> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> <65a0127fd1b94e879d648547df6c621a@DEWDFE13DE09.global.corp.sap> <0d6753a9474f4181a15bd6a4637686a0@DEWDFE13DE09.global.corp.sap> Message-ID: <77e129a3-1a9f-5265-70c5-3a712b4a7536@oracle.com> On 13/07/2016 5:00 PM, Lindenmaier, Goetz wrote: > Hi David, > >> Is there a reason you didn't do what I had suggested with the above and >> change the last _ to = ? > * I think the names should match what is in the path, therefore I think > CPU is better than ARCH (we have src/cpu/x86). > * I left out "FAMILY". I don't see any gain in this part of the name. > * Three of them are superfluous anyways. My view is that we should not change the names as they exist and thus avoid the inevitable debates over arch versus cpu verus whatever. It is messy enough that simply changing things again does not add any value in my opinion. > I thought about calling them INCLUDE_OS and INCLUDE_CPU, that > better indicates what they are meant for. > I also thought about only defining them in the macros.hpp file. We > have -DLINUX -DAMD64 / -DAIX -DPPC64 etc. on the command line > to identify which port to compile. Not quite sure what you mean. These things should be being set by the build system for use in macros.hpp >> I thought my suggestion would avoid the issue >> with the LINUX=1 problem. ? > Do you want me to do -DTARGET_OS_FAMILY=_linux ? with '_'? > The problem is that there is lower case #define linux=1. > I don't think we should define things with leading '_', they are often > used by the system headers / compilers. No I wasn't suggesting adding '_' - I thought we would avoid the issue. :( Often wondered why C lacks a means to say "don't macro-expand this" > I rebased my changes, that did not cause any conflicts. I also downloaded > the changesets and patched them into my repo, that works too. > You first need to apply the cleanups, then the new includes. Ah I see. Thanks, David > Best regards, > Goetz. > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 13. Juli 2016 05:43 >> To: Lindenmaier, Goetz ; >> 'dean.long at oracle.com' ; hotspot- >> dev at openjdk.java.net >> Subject: Re: s390x port progress: patch queue for hotspot assembled. >> >> Hi Goetz, >> >> Thanks for doing this! I think it looks good. Only nit ... >> >> On 13/07/2016 7:58 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I implemented a prototype of the include model proposed by Volker. >>> I tested this so far on linux_x86_64, aix_ppc64 and linux_ppc64. >>> I'll test it on the other OSes/CPUs I have available tomorrow. >>> >>> The direcitves >>> -DTARGET_OS_FAMILY_linux >>> -DTARGET_ARCH_MODEL_x86_64 >>> -DTARGET_ARCH_x86 >>> -DTARGET_OS_ARCH_MODEL_linux_x86_64 >>> -DTARGET_OS_ARCH_linux_x86 >>> are replaced by -DTARGET_OS=linux -DTARGET_CPU=x86. >>> (OS and CPU are used for vm_version.cpp) >> >> Is there a reason you didn't do what I had suggested with the above and >> change the last _ to = ? I thought my suggestion would avoid the issue >> with the LINUX=1 problem. ?? >> >> I was going to test this out with our other platforms but unfortunately >> the patch didn't apply on latest jdk9/hs. >> >> Thanks, >> David >> >>> The macros proposed by Volker are in utilities/macros.hpp. >>> >>> There are some places where above TARGET_... macros are used for other >>> purposes than guarding the includes, I replaced them to use the other >>> platform dependent macros already defined. >>> >>> I also removed all headers carying _64 or _32 in their name. >>> There were three on ppc. As I learned there is no PPC32 port >>> any more, so changing this should be fine. I found one on x86 >> (stubRoutines...hpp). >>> I merged it and use LP64 guards for the differences. I think this is >>> acceptable as the files are rather small and it's the only case. >>> >>> The adlc generated files all had suffix _64/_32 which I removed. >>> These are not significant, either. >>> >>> All this normalizing edits can be found in this webrev. It would be >>> useful to apply them anyways: >>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-cleanups/ >>> The real change is here: >>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev- >> newIncludes/ >>> I had to do a tweak for the #define linux=1 in macros.hpp. >>> >>> Please have a look at these changes. Also, check whether this >>> works fine with the IDE of your choice :) >>> >>> If this finds appreciation, I'll open an Enhancement and make a >>> real webrev/RFR. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of dean.long at oracle.com >>>> Sent: Wednesday, July 06, 2016 7:49 AM >>>> To: hotspot-dev at openjdk.java.net >>>> Subject: Re: s390x port progress: patch queue for hotspot assembled. >>>> >>>> On 7/5/16 10:42 PM, dean.long at oracle.com wrote: >>>> >>>>> On 7/4/16 2:59 PM, David Holmes wrote: >>>>> >>>>>> On 5/07/2016 7:44 AM, Stefan Karlsson wrote: >>>>>>> On 2016-07-04 23:03, David Holmes wrote: >>>>>>>> On 5/07/2016 12:07 AM, Volker Simonis wrote: >>>>>>>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley >>>> wrote: >>>>>>>>>> On 04/07/16 12:22, David Holmes wrote: >>>>>>>>>> >>>>>>>>>>> Unless the files are included into more than one other file then >>>>>>>>>>> adding >>>>>>>>>>> a level of indirection doesn't really help anything. >>>>>>>>>> >>>>>>>>>> I'm not sure what this means. >>>>>>>>>> >>>>>>>>>>> But I don't see why the platform part of the name needs to be >> kept >>>>>>>>>>> when >>>>>>>>>>> it is already part of the path? >>>>>>>>>> >>>>>>>>>> When switching between files in an editor, one doesn't usually >>>>>>>>>> type in the full path, but the filename. I'd be very sad to lose >>>>>>>>>> that, and I think that unique filenames are a nice thing to have. >>>>>>>>>> >>>>>>>>> >>>>>>>>> In Emacs you can try the uniquify [1] extension which would solve >> the >>>>>>>>> problem. I already use it for editing various hotspot version (i.e. >>>>>>>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is >> probably >>>>>>>>> not a practical solution for everybody :) >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>> >> https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify. >>>> html >>>>>>>>> >>>>>>>>> >>>>>>>>>> Andrew. >>>>>>>>>> >>>>>>>>> >>>>>>>>> We could try something like this (adapted from [2]) although I'm >> not >>>>>>>>> sure if that's really a good solution (i.e. if it is treated right by >>>>>>>>> various IDEs): >>>>>>>>> >>>>>>>>> include_test.cpp >>>>>>>>> ============ >>>>>>>>> >>>>>>>>> #define xstr(x) #x >>>>>>>>> #define str(x) xstr(x) >>>>>>>>> #define sub(x) x >>>>>>>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) >>>>>>>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) >>>>>>>>> #define os_cpu_header(x) >> str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) >>>>>>>>> >>>>>>>>> #include cpu_header(assembler) >>>>>>>>> #include os_header(assembler) >>>>>>>>> #include os_cpu_header(assembler) >>>>>>>> >>>>>>>> This is the parameterization I thought was not possible. For some >>>>>>>> reason I thought #define'd values could not be used within #include >>>>>>>> directives. >>>>>>> >>>>>>> FWIW, we tried a similar approach when includeDB was removed, but >>>>>>> abandoned it because of the problem described below with the 'linux' >>>>>>> define. >>>>>> >>>>>> Give we have in the build (eg for linux x86) presently: >>>>>> >>>>>> -DTARGET_OS_FAMILY_linux >>>>>> -DTARGET_ARCH_MODEL_x86_32 >>>>>> -DTARGET_ARCH_x86 >>>>>> -DTARGET_OS_ARCH_MODEL_linux_x86_32 >>>>>> -DTARGET_OS_ARCH_linux_x86 >>>>>> >>>>>> I wonder if we can simply replace the above with: >>>>>> >>>>>> -DTARGET_OS_FAMILY=linux >>>>>> -DTARGET_ARCH_MODEL=x86_32 >>>>>> -DTARGET_ARCH=x86 >>>>>> -DTARGET_OS_ARCH_MODEL=linux_x86_32 >>>>>> -DTARGET_OS_ARCH=linux_x86 >>>>>> >>>>>> and use those variables for the include directives? >>>>>> >>>>> >>>>> I remember experimenting with that idea, but gave up because I >>>>> couldn't get it work. >>>>> What I ended up doing was something like this: >>>>> >>>>> #*include* C1_LIRGENERATOR_MD_HPP >>>>> >>>> >>>> Oops, let's try that again: >>>> >>>> #include C1_LIRGENERATOR_MD_HPP >>>> >>>> where, using x86 as an example, macros like C1_LIRGENERATOR_MD_HPP >>>> are >>>> defined in globalDefinitions_x86.hpp: >>>> >>>> #define C1_LIRGENERATOR_MD_HPP "c1_LIRGenerator_x86.hpp" >>>> >>>> dl >>>> >>>>> I don't know if this confuses IDEs or not. >>>>> >>>>> dl >>>>> >>>>>> David >>>>>> >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> This looks very workable to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> assembler_s390x.hpp >>>>>>>>> ================ >>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>>>>>> >>>>>>>>> assembler_linux.hpp >>>>>>>>> =============== >>>>>>>>> #pragma message ("including \"assembler_linux.h\"") >>>>>>>>> >>>>>>>>> assembler_linux_s390x.hpp >>>>>>>>> ==================== >>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>>>>>> >>>>>>>>> >>>>>>>>> It works on all the platforms I have tested so far (see below) except >>>>>>>>> Linux where it needs some tweaks (see comments below): >>>>>>>>> >>>>>>>>> >>>>>>>>> Solaris: >>>>>>>>> ====== >>>>>>>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E >>>> include_test.cpp >>>>>>>>> #1 "include_test.cpp" >>>>>>>>> #1 "assembler_s390x.hpp" >>>>>>>>> #pragma message ( "including \"assembler_s390x.h\"" ) >>>>>>>>> #1 "assembler_linux.hpp" >>>>>>>>> #pragma message ( "including \"assembler_linux.h\"" ) >>>>>>>>> #1 "assembler_linux_s390x.hpp" >>>>>>>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) >>>>>>>>> >>>>>>>>> AIX: >>>>>>>>> === >>>>>>>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c >>>>>>>>> include_test.cpp >>>>>>>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >> "pragma >>>>>>>>> message" is specified. >>>>>>>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>>>>>>>> message" is specified. >>>>>>>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >>>>>>>>> "pragma message" is specified. >>>>>>>>> >>>>>>>>> MacOS X >>>>>>>>> ======= >>>>>>>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>>>> In file included from include_test.cpp:8: >>>>>>>>> ./assembler_s390x.hpp:1:9: warning: including >> "assembler_s390x.h" >>>>>>>>> [-W#pragma-messages] >>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>>>>>> ^ >>>>>>>>> In file included from include_test.cpp:9: >>>>>>>>> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" >>>>>>>>> [-W#pragma-messages] >>>>>>>>> #pragma message ("including \"assembler_linux.h\"") >>>>>>>>> ^ >>>>>>>>> In file included from include_test.cpp:10: >>>>>>>>> ./assembler_linux_s390x.hpp:1:9: warning: including >>>>>>>>> "assembler_linux_s390x.h" [-W#pragma-messages] >>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>>>>>> ^ >>>>>>>>> 3 warnings generated. >>>>>>>>> >>>>>>>>> Windows: >>>>>>>>> ======= >>>>>>>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x >>>>>>>>> -DOS=linux -c include_test. >>>>>>>>> cpp >>>>>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for >>>>>>>>> x64 >>>>>>>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>>>>>>> >>>>>>>>> include_test.cpp >>>>>>>>> including "assembler_s390x.h" >>>>>>>>> including "assembler_linux.h" >>>>>>>>> including "assembler_linux_s390x.h" >>>>>>>>> >>>>>>>>> HPUX: >>>>>>>>> ===== >>>>>>>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>>>> Info #4087-D: "including \"assembler_s390x.h\"" >>>>>>>>> >>>>>>>>> Info #4087-D: "including \"assembler_linux.h\"" >>>>>>>>> >>>>>>>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" >>>>>>>>> >>>>>>>>> Linux: >>>>>>>>> ===== >>>>>>>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file or >>>>>>>>> directory >>>>>>>>> compilation terminated. >>>>>>>>> >>>>>>>>> The problem on Linux is that 'linux' is already predefined to '1' but >>>>>>>>> that could be easily fixed for example by slightly changing the name >>>>>>>>> or by adding the underscore to the definiton of the OS macro (i.e. >>>>>>>>> -DOS=_linux). >>>>>>>>> >>>>>>>>> As I said, I'm still not sure if this looks nice? I just wanted to >>>>>>>>> post my findings for discussion :) >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> [2] >>>>>>>>> http://stackoverflow.com/questions/1852652/how-can-i-include- >> a- >>>> file-whose-name-is-built-up-from-a-macro >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> From david.holmes at oracle.com Thu Jul 14 00:18:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jul 2016 10:18:22 +1000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <122c1ef9-8448-e7ea-588d-6151c9688dd8@oracle.com> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> <65a0127fd1b94e879d648547df6c621a@DEWDFE13DE09.global.corp.sap> <0d6753a9474f4181a15bd6a4637686a0@DEWDFE13DE09.global.corp.sap> <122c1ef9-8448-e7ea-588d-6151c9688dd8@oracle.com> Message-ID: <46c4b02b-a2e3-cfac-6a3e-582c2e8bfb1c@oracle.com> On 14/07/2016 1:30 AM, Coleen Phillimore wrote: > > > Goetz, > > I like the cleanups in your patch but when I grep for TARGET_OS_FAMILY, > I see this in jvm.cpp (which you changed) but also mutex.cpp and > vmStructs.cpp which you didn't change. > > In mutex.cpp, this includes files that are all empty! Time implement this cleanup: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-February/021617.html :) David > #ifdef TARGET_OS_FAMILY_linux > # include "mutex_linux.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_solaris > # include "mutex_solaris.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_windows > # include "mutex_windows.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_bsd > # include "mutex_bsd.inline.hpp" > #endif > > > Thanks, > Coleen > > On 7/13/16 3:00 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >>> Is there a reason you didn't do what I had suggested with the above and >>> change the last _ to = ? >> * I think the names should match what is in the path, therefore I think >> CPU is better than ARCH (we have src/cpu/x86). >> * I left out "FAMILY". I don't see any gain in this part of the name. > > I agree. >> * Three of them are superfluous anyways. >> I thought about calling them INCLUDE_OS and INCLUDE_CPU, that >> better indicates what they are meant for. >> I also thought about only defining them in the macros.hpp file. We >> have -DLINUX -DAMD64 / -DAIX -DPPC64 etc. on the command line >> to identify which port to compile. >> >>> I thought my suggestion would avoid the issue >>> with the LINUX=1 problem. ? >> Do you want me to do -DTARGET_OS_FAMILY=_linux ? with '_'? >> The problem is that there is lower case #define linux=1. >> I don't think we should define things with leading '_', they are often >> used by the system headers / compilers. >> >> I rebased my changes, that did not cause any conflicts. I also downloaded >> the changesets and patched them into my repo, that works too. >> You first need to apply the cleanups, then the new includes. >> >> Best regards, >> Goetz. >> >> >> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Mittwoch, 13. Juli 2016 05:43 >>> To: Lindenmaier, Goetz ; >>> 'dean.long at oracle.com' ; hotspot- >>> dev at openjdk.java.net >>> Subject: Re: s390x port progress: patch queue for hotspot assembled. >>> >>> Hi Goetz, >>> >>> Thanks for doing this! I think it looks good. Only nit ... >>> >>> On 13/07/2016 7:58 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I implemented a prototype of the include model proposed by Volker. >>>> I tested this so far on linux_x86_64, aix_ppc64 and linux_ppc64. >>>> I'll test it on the other OSes/CPUs I have available tomorrow. >>>> >>>> The direcitves >>>> -DTARGET_OS_FAMILY_linux >>>> -DTARGET_ARCH_MODEL_x86_64 >>>> -DTARGET_ARCH_x86 >>>> -DTARGET_OS_ARCH_MODEL_linux_x86_64 >>>> -DTARGET_OS_ARCH_linux_x86 >>>> are replaced by -DTARGET_OS=linux -DTARGET_CPU=x86. >>>> (OS and CPU are used for vm_version.cpp) >>> Is there a reason you didn't do what I had suggested with the above and >>> change the last _ to = ? I thought my suggestion would avoid the issue >>> with the LINUX=1 problem. ?? >>> >>> I was going to test this out with our other platforms but unfortunately >>> the patch didn't apply on latest jdk9/hs. >>> >>> Thanks, >>> David >>> >>>> The macros proposed by Volker are in utilities/macros.hpp. >>>> >>>> There are some places where above TARGET_... macros are used for other >>>> purposes than guarding the includes, I replaced them to use the other >>>> platform dependent macros already defined. >>>> >>>> I also removed all headers carying _64 or _32 in their name. >>>> There were three on ppc. As I learned there is no PPC32 port >>>> any more, so changing this should be fine. I found one on x86 >>> (stubRoutines...hpp). >>>> I merged it and use LP64 guards for the differences. I think this is >>>> acceptable as the files are rather small and it's the only case. >>>> >>>> The adlc generated files all had suffix _64/_32 which I removed. >>>> These are not significant, either. >>>> >>>> All this normalizing edits can be found in this webrev. It would be >>>> useful to apply them anyways: >>>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-cleanups/ >>>> The real change is here: >>>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev- >>> newIncludes/ >>>> I had to do a tweak for the #define linux=1 in macros.hpp. >>>> >>>> Please have a look at these changes. Also, check whether this >>>> works fine with the IDE of your choice :) >>>> >>>> If this finds appreciation, I'll open an Enhancement and make a >>>> real webrev/RFR. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>> Behalf Of dean.long at oracle.com >>>>> Sent: Wednesday, July 06, 2016 7:49 AM >>>>> To: hotspot-dev at openjdk.java.net >>>>> Subject: Re: s390x port progress: patch queue for hotspot assembled. >>>>> >>>>> On 7/5/16 10:42 PM, dean.long at oracle.com wrote: >>>>> >>>>>> On 7/4/16 2:59 PM, David Holmes wrote: >>>>>> >>>>>>> On 5/07/2016 7:44 AM, Stefan Karlsson wrote: >>>>>>>> On 2016-07-04 23:03, David Holmes wrote: >>>>>>>>> On 5/07/2016 12:07 AM, Volker Simonis wrote: >>>>>>>>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley >>>>> wrote: >>>>>>>>>>> On 04/07/16 12:22, David Holmes wrote: >>>>>>>>>>> >>>>>>>>>>>> Unless the files are included into more than one other file >>>>>>>>>>>> then >>>>>>>>>>>> adding >>>>>>>>>>>> a level of indirection doesn't really help anything. >>>>>>>>>>> I'm not sure what this means. >>>>>>>>>>> >>>>>>>>>>>> But I don't see why the platform part of the name needs to be >>> kept >>>>>>>>>>>> when >>>>>>>>>>>> it is already part of the path? >>>>>>>>>>> When switching between files in an editor, one doesn't usually >>>>>>>>>>> type in the full path, but the filename. I'd be very sad to >>>>>>>>>>> lose >>>>>>>>>>> that, and I think that unique filenames are a nice thing to >>>>>>>>>>> have. >>>>>>>>>>> >>>>>>>>>> In Emacs you can try the uniquify [1] extension which would solve >>> the >>>>>>>>>> problem. I already use it for editing various hotspot version >>>>>>>>>> (i.e. >>>>>>>>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is >>> probably >>>>>>>>>> not a practical solution for everybody :) >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> >>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify. >>>>> html >>>>>>>>>> >>>>>>>>>>> Andrew. >>>>>>>>>>> >>>>>>>>>> We could try something like this (adapted from [2]) although I'm >>> not >>>>>>>>>> sure if that's really a good solution (i.e. if it is treated >>>>>>>>>> right by >>>>>>>>>> various IDEs): >>>>>>>>>> >>>>>>>>>> include_test.cpp >>>>>>>>>> ============ >>>>>>>>>> >>>>>>>>>> #define xstr(x) #x >>>>>>>>>> #define str(x) xstr(x) >>>>>>>>>> #define sub(x) x >>>>>>>>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) >>>>>>>>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) >>>>>>>>>> #define os_cpu_header(x) >>> str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) >>>>>>>>>> #include cpu_header(assembler) >>>>>>>>>> #include os_header(assembler) >>>>>>>>>> #include os_cpu_header(assembler) >>>>>>>>> This is the parameterization I thought was not possible. For some >>>>>>>>> reason I thought #define'd values could not be used within >>>>>>>>> #include >>>>>>>>> directives. >>>>>>>> FWIW, we tried a similar approach when includeDB was removed, but >>>>>>>> abandoned it because of the problem described below with the >>>>>>>> 'linux' >>>>>>>> define. >>>>>>> Give we have in the build (eg for linux x86) presently: >>>>>>> >>>>>>> -DTARGET_OS_FAMILY_linux >>>>>>> -DTARGET_ARCH_MODEL_x86_32 >>>>>>> -DTARGET_ARCH_x86 >>>>>>> -DTARGET_OS_ARCH_MODEL_linux_x86_32 >>>>>>> -DTARGET_OS_ARCH_linux_x86 >>>>>>> >>>>>>> I wonder if we can simply replace the above with: >>>>>>> >>>>>>> -DTARGET_OS_FAMILY=linux >>>>>>> -DTARGET_ARCH_MODEL=x86_32 >>>>>>> -DTARGET_ARCH=x86 >>>>>>> -DTARGET_OS_ARCH_MODEL=linux_x86_32 >>>>>>> -DTARGET_OS_ARCH=linux_x86 >>>>>>> >>>>>>> and use those variables for the include directives? >>>>>>> >>>>>> I remember experimenting with that idea, but gave up because I >>>>>> couldn't get it work. >>>>>> What I ended up doing was something like this: >>>>>> >>>>>> #*include* C1_LIRGENERATOR_MD_HPP >>>>>> >>>>> Oops, let's try that again: >>>>> >>>>> #include C1_LIRGENERATOR_MD_HPP >>>>> >>>>> where, using x86 as an example, macros like C1_LIRGENERATOR_MD_HPP >>>>> are >>>>> defined in globalDefinitions_x86.hpp: >>>>> >>>>> #define C1_LIRGENERATOR_MD_HPP "c1_LIRGenerator_x86.hpp" >>>>> >>>>> dl >>>>> >>>>>> I don't know if this confuses IDEs or not. >>>>>> >>>>>> dl >>>>>> >>>>>>> David >>>>>>> >>>>>>>> StefanK >>>>>>>> >>>>>>>>> This looks very workable to me. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> assembler_s390x.hpp >>>>>>>>>> ================ >>>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>>>>>>> >>>>>>>>>> assembler_linux.hpp >>>>>>>>>> =============== >>>>>>>>>> #pragma message ("including \"assembler_linux.h\"") >>>>>>>>>> >>>>>>>>>> assembler_linux_s390x.hpp >>>>>>>>>> ==================== >>>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It works on all the platforms I have tested so far (see below) >>>>>>>>>> except >>>>>>>>>> Linux where it needs some tweaks (see comments below): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Solaris: >>>>>>>>>> ====== >>>>>>>>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E >>>>> include_test.cpp >>>>>>>>>> #1 "include_test.cpp" >>>>>>>>>> #1 "assembler_s390x.hpp" >>>>>>>>>> #pragma message ( "including \"assembler_s390x.h\"" ) >>>>>>>>>> #1 "assembler_linux.hpp" >>>>>>>>>> #pragma message ( "including \"assembler_linux.h\"" ) >>>>>>>>>> #1 "assembler_linux_s390x.hpp" >>>>>>>>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) >>>>>>>>>> >>>>>>>>>> AIX: >>>>>>>>>> === >>>>>>>>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux -c >>>>>>>>>> include_test.cpp >>>>>>>>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >>> "pragma >>>>>>>>>> message" is specified. >>>>>>>>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown "pragma >>>>>>>>>> message" is specified. >>>>>>>>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An unknown >>>>>>>>>> "pragma message" is specified. >>>>>>>>>> >>>>>>>>>> MacOS X >>>>>>>>>> ======= >>>>>>>>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>>>>> In file included from include_test.cpp:8: >>>>>>>>>> ./assembler_s390x.hpp:1:9: warning: including >>> "assembler_s390x.h" >>>>>>>>>> [-W#pragma-messages] >>>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") >>>>>>>>>> ^ >>>>>>>>>> In file included from include_test.cpp:9: >>>>>>>>>> ./assembler_linux.hpp:1:9: warning: including "assembler_linux.h" >>>>>>>>>> [-W#pragma-messages] >>>>>>>>>> #pragma message ("including \"assembler_linux.h\"") >>>>>>>>>> ^ >>>>>>>>>> In file included from include_test.cpp:10: >>>>>>>>>> ./assembler_linux_s390x.hpp:1:9: warning: including >>>>>>>>>> "assembler_linux_s390x.h" [-W#pragma-messages] >>>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") >>>>>>>>>> ^ >>>>>>>>>> 3 warnings generated. >>>>>>>>>> >>>>>>>>>> Windows: >>>>>>>>>> ======= >>>>>>>>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -DCPU=s390x >>>>>>>>>> -DOS=linux -c include_test. >>>>>>>>>> cpp >>>>>>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 >>>>>>>>>> for >>>>>>>>>> x64 >>>>>>>>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>>>>>>>> >>>>>>>>>> include_test.cpp >>>>>>>>>> including "assembler_s390x.h" >>>>>>>>>> including "assembler_linux.h" >>>>>>>>>> including "assembler_linux_s390x.h" >>>>>>>>>> >>>>>>>>>> HPUX: >>>>>>>>>> ===== >>>>>>>>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>>>>> Info #4087-D: "including \"assembler_s390x.h\"" >>>>>>>>>> >>>>>>>>>> Info #4087-D: "including \"assembler_linux.h\"" >>>>>>>>>> >>>>>>>>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" >>>>>>>>>> >>>>>>>>>> Linux: >>>>>>>>>> ===== >>>>>>>>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp >>>>>>>>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such >>>>>>>>>> file or >>>>>>>>>> directory >>>>>>>>>> compilation terminated. >>>>>>>>>> >>>>>>>>>> The problem on Linux is that 'linux' is already predefined to >>>>>>>>>> '1' but >>>>>>>>>> that could be easily fixed for example by slightly changing >>>>>>>>>> the name >>>>>>>>>> or by adding the underscore to the definiton of the OS macro >>>>>>>>>> (i.e. >>>>>>>>>> -DOS=_linux). >>>>>>>>>> >>>>>>>>>> As I said, I'm still not sure if this looks nice? I just >>>>>>>>>> wanted to >>>>>>>>>> post my findings for discussion :) >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>>> [2] >>>>>>>>>> http://stackoverflow.com/questions/1852652/how-can-i-include- >>> a- >>>>> file-whose-name-is-built-up-from-a-macro >>>>>>>>>> >>>>>>>>>> > From goetz.lindenmaier at sap.com Thu Jul 14 08:21:58 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 08:21:58 +0000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <122c1ef9-8448-e7ea-588d-6151c9688dd8@oracle.com> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> <65a0127fd1b94e879d648547df6c621a@DEWDFE13DE09.global.corp.sap> <0d6753a9474f4181a15bd6a4637686a0@DEWDFE13DE09.global.corp.sap> <122c1ef9-8448-e7ea-588d-6151c9688dd8@oracle.com> Message-ID: Hi Coleen, I'm about to send a proper RFR, I fixed these issues in the webrev there. I removed all the empty mutex files. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Coleen Phillimore > Sent: Mittwoch, 13. Juli 2016 17:30 > To: hotspot-dev at openjdk.java.net > Subject: Re: s390x port progress: patch queue for hotspot assembled. > > > > Goetz, > > I like the cleanups in your patch but when I grep for TARGET_OS_FAMILY, > I see this in jvm.cpp (which you changed) but also mutex.cpp and > vmStructs.cpp which you didn't change. > > In mutex.cpp, this includes files that are all empty! > > #ifdef TARGET_OS_FAMILY_linux > # include "mutex_linux.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_solaris > # include "mutex_solaris.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_windows > # include "mutex_windows.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_bsd > # include "mutex_bsd.inline.hpp" > #endif > > > Thanks, > Coleen > > On 7/13/16 3:00 AM, Lindenmaier, Goetz wrote: > > Hi David, > > > >> Is there a reason you didn't do what I had suggested with the above and > >> change the last _ to = ? > > * I think the names should match what is in the path, therefore I think > > CPU is better than ARCH (we have src/cpu/x86). > > * I left out "FAMILY". I don't see any gain in this part of the name. > > I agree. > > * Three of them are superfluous anyways. > > I thought about calling them INCLUDE_OS and INCLUDE_CPU, that > > better indicates what they are meant for. > > I also thought about only defining them in the macros.hpp file. We > > have -DLINUX -DAMD64 / -DAIX -DPPC64 etc. on the command line > > to identify which port to compile. > > > >> I thought my suggestion would avoid the issue > >> with the LINUX=1 problem. ? > > Do you want me to do -DTARGET_OS_FAMILY=_linux ? with '_'? > > The problem is that there is lower case #define linux=1. > > I don't think we should define things with leading '_', they are often > > used by the system headers / compilers. > > > > I rebased my changes, that did not cause any conflicts. I also downloaded > > the changesets and patched them into my repo, that works too. > > You first need to apply the cleanups, then the new includes. > > > > Best regards, > > Goetz. > > > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 13. Juli 2016 05:43 > >> To: Lindenmaier, Goetz ; > >> 'dean.long at oracle.com' ; hotspot- > >> dev at openjdk.java.net > >> Subject: Re: s390x port progress: patch queue for hotspot assembled. > >> > >> Hi Goetz, > >> > >> Thanks for doing this! I think it looks good. Only nit ... > >> > >> On 13/07/2016 7:58 AM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I implemented a prototype of the include model proposed by Volker. > >>> I tested this so far on linux_x86_64, aix_ppc64 and linux_ppc64. > >>> I'll test it on the other OSes/CPUs I have available tomorrow. > >>> > >>> The direcitves > >>> -DTARGET_OS_FAMILY_linux > >>> -DTARGET_ARCH_MODEL_x86_64 > >>> -DTARGET_ARCH_x86 > >>> -DTARGET_OS_ARCH_MODEL_linux_x86_64 > >>> -DTARGET_OS_ARCH_linux_x86 > >>> are replaced by -DTARGET_OS=linux -DTARGET_CPU=x86. > >>> (OS and CPU are used for vm_version.cpp) > >> Is there a reason you didn't do what I had suggested with the above and > >> change the last _ to = ? I thought my suggestion would avoid the issue > >> with the LINUX=1 problem. ?? > >> > >> I was going to test this out with our other platforms but unfortunately > >> the patch didn't apply on latest jdk9/hs. > >> > >> Thanks, > >> David > >> > >>> The macros proposed by Volker are in utilities/macros.hpp. > >>> > >>> There are some places where above TARGET_... macros are used for > other > >>> purposes than guarding the includes, I replaced them to use the other > >>> platform dependent macros already defined. > >>> > >>> I also removed all headers carying _64 or _32 in their name. > >>> There were three on ppc. As I learned there is no PPC32 port > >>> any more, so changing this should be fine. I found one on x86 > >> (stubRoutines...hpp). > >>> I merged it and use LP64 guards for the differences. I think this is > >>> acceptable as the files are rather small and it's the only case. > >>> > >>> The adlc generated files all had suffix _64/_32 which I removed. > >>> These are not significant, either. > >>> > >>> All this normalizing edits can be found in this webrev. It would be > >>> useful to apply them anyways: > >>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-cleanups/ > >>> The real change is here: > >>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev- > >> newIncludes/ > >>> I had to do a tweak for the #define linux=1 in macros.hpp. > >>> > >>> Please have a look at these changes. Also, check whether this > >>> works fine with the IDE of your choice :) > >>> > >>> If this finds appreciation, I'll open an Enhancement and make a > >>> real webrev/RFR. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] > On > >>>> Behalf Of dean.long at oracle.com > >>>> Sent: Wednesday, July 06, 2016 7:49 AM > >>>> To: hotspot-dev at openjdk.java.net > >>>> Subject: Re: s390x port progress: patch queue for hotspot assembled. > >>>> > >>>> On 7/5/16 10:42 PM, dean.long at oracle.com wrote: > >>>> > >>>>> On 7/4/16 2:59 PM, David Holmes wrote: > >>>>> > >>>>>> On 5/07/2016 7:44 AM, Stefan Karlsson wrote: > >>>>>>> On 2016-07-04 23:03, David Holmes wrote: > >>>>>>>> On 5/07/2016 12:07 AM, Volker Simonis wrote: > >>>>>>>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley > > >>>> wrote: > >>>>>>>>>> On 04/07/16 12:22, David Holmes wrote: > >>>>>>>>>> > >>>>>>>>>>> Unless the files are included into more than one other file > then > >>>>>>>>>>> adding > >>>>>>>>>>> a level of indirection doesn't really help anything. > >>>>>>>>>> I'm not sure what this means. > >>>>>>>>>> > >>>>>>>>>>> But I don't see why the platform part of the name needs to be > >> kept > >>>>>>>>>>> when > >>>>>>>>>>> it is already part of the path? > >>>>>>>>>> When switching between files in an editor, one doesn't usually > >>>>>>>>>> type in the full path, but the filename. I'd be very sad to lose > >>>>>>>>>> that, and I think that unique filenames are a nice thing to have. > >>>>>>>>>> > >>>>>>>>> In Emacs you can try the uniquify [1] extension which would > solve > >> the > >>>>>>>>> problem. I already use it for editing various hotspot version (i.e. > >>>>>>>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is > >> probably > >>>>>>>>> not a practical solution for everybody :) > >>>>>>>>> > >>>>>>>>> [1] > >>>>>>>>> > >> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify. > >>>> html > >>>>>>>>> > >>>>>>>>>> Andrew. > >>>>>>>>>> > >>>>>>>>> We could try something like this (adapted from [2]) although I'm > >> not > >>>>>>>>> sure if that's really a good solution (i.e. if it is treated right by > >>>>>>>>> various IDEs): > >>>>>>>>> > >>>>>>>>> include_test.cpp > >>>>>>>>> ============ > >>>>>>>>> > >>>>>>>>> #define xstr(x) #x > >>>>>>>>> #define str(x) xstr(x) > >>>>>>>>> #define sub(x) x > >>>>>>>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) > >>>>>>>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) > >>>>>>>>> #define os_cpu_header(x) > >> str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) > >>>>>>>>> #include cpu_header(assembler) > >>>>>>>>> #include os_header(assembler) > >>>>>>>>> #include os_cpu_header(assembler) > >>>>>>>> This is the parameterization I thought was not possible. For some > >>>>>>>> reason I thought #define'd values could not be used within > #include > >>>>>>>> directives. > >>>>>>> FWIW, we tried a similar approach when includeDB was removed, > but > >>>>>>> abandoned it because of the problem described below with the > 'linux' > >>>>>>> define. > >>>>>> Give we have in the build (eg for linux x86) presently: > >>>>>> > >>>>>> -DTARGET_OS_FAMILY_linux > >>>>>> -DTARGET_ARCH_MODEL_x86_32 > >>>>>> -DTARGET_ARCH_x86 > >>>>>> -DTARGET_OS_ARCH_MODEL_linux_x86_32 > >>>>>> -DTARGET_OS_ARCH_linux_x86 > >>>>>> > >>>>>> I wonder if we can simply replace the above with: > >>>>>> > >>>>>> -DTARGET_OS_FAMILY=linux > >>>>>> -DTARGET_ARCH_MODEL=x86_32 > >>>>>> -DTARGET_ARCH=x86 > >>>>>> -DTARGET_OS_ARCH_MODEL=linux_x86_32 > >>>>>> -DTARGET_OS_ARCH=linux_x86 > >>>>>> > >>>>>> and use those variables for the include directives? > >>>>>> > >>>>> I remember experimenting with that idea, but gave up because I > >>>>> couldn't get it work. > >>>>> What I ended up doing was something like this: > >>>>> > >>>>> #*include* C1_LIRGENERATOR_MD_HPP > >>>>> > >>>> Oops, let's try that again: > >>>> > >>>> #include C1_LIRGENERATOR_MD_HPP > >>>> > >>>> where, using x86 as an example, macros like > C1_LIRGENERATOR_MD_HPP > >>>> are > >>>> defined in globalDefinitions_x86.hpp: > >>>> > >>>> #define C1_LIRGENERATOR_MD_HPP "c1_LIRGenerator_x86.hpp" > >>>> > >>>> dl > >>>> > >>>>> I don't know if this confuses IDEs or not. > >>>>> > >>>>> dl > >>>>> > >>>>>> David > >>>>>> > >>>>>>> StefanK > >>>>>>> > >>>>>>>> This looks very workable to me. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> > >>>>>>>>> assembler_s390x.hpp > >>>>>>>>> ================ > >>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") > >>>>>>>>> > >>>>>>>>> assembler_linux.hpp > >>>>>>>>> =============== > >>>>>>>>> #pragma message ("including \"assembler_linux.h\"") > >>>>>>>>> > >>>>>>>>> assembler_linux_s390x.hpp > >>>>>>>>> ==================== > >>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> It works on all the platforms I have tested so far (see below) > except > >>>>>>>>> Linux where it needs some tweaks (see comments below): > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Solaris: > >>>>>>>>> ====== > >>>>>>>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E > >>>> include_test.cpp > >>>>>>>>> #1 "include_test.cpp" > >>>>>>>>> #1 "assembler_s390x.hpp" > >>>>>>>>> #pragma message ( "including \"assembler_s390x.h\"" ) > >>>>>>>>> #1 "assembler_linux.hpp" > >>>>>>>>> #pragma message ( "including \"assembler_linux.h\"" ) > >>>>>>>>> #1 "assembler_linux_s390x.hpp" > >>>>>>>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) > >>>>>>>>> > >>>>>>>>> AIX: > >>>>>>>>> === > >>>>>>>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux - > c > >>>>>>>>> include_test.cpp > >>>>>>>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown > >> "pragma > >>>>>>>>> message" is specified. > >>>>>>>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown > "pragma > >>>>>>>>> message" is specified. > >>>>>>>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An > unknown > >>>>>>>>> "pragma message" is specified. > >>>>>>>>> > >>>>>>>>> MacOS X > >>>>>>>>> ======= > >>>>>>>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>>>>>> In file included from include_test.cpp:8: > >>>>>>>>> ./assembler_s390x.hpp:1:9: warning: including > >> "assembler_s390x.h" > >>>>>>>>> [-W#pragma-messages] > >>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") > >>>>>>>>> ^ > >>>>>>>>> In file included from include_test.cpp:9: > >>>>>>>>> ./assembler_linux.hpp:1:9: warning: including > "assembler_linux.h" > >>>>>>>>> [-W#pragma-messages] > >>>>>>>>> #pragma message ("including \"assembler_linux.h\"") > >>>>>>>>> ^ > >>>>>>>>> In file included from include_test.cpp:10: > >>>>>>>>> ./assembler_linux_s390x.hpp:1:9: warning: including > >>>>>>>>> "assembler_linux_s390x.h" [-W#pragma-messages] > >>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") > >>>>>>>>> ^ > >>>>>>>>> 3 warnings generated. > >>>>>>>>> > >>>>>>>>> Windows: > >>>>>>>>> ======= > >>>>>>>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl - > DCPU=s390x > >>>>>>>>> -DOS=linux -c include_test. > >>>>>>>>> cpp > >>>>>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 > for > >>>>>>>>> x64 > >>>>>>>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>>>>>>> > >>>>>>>>> include_test.cpp > >>>>>>>>> including "assembler_s390x.h" > >>>>>>>>> including "assembler_linux.h" > >>>>>>>>> including "assembler_linux_s390x.h" > >>>>>>>>> > >>>>>>>>> HPUX: > >>>>>>>>> ===== > >>>>>>>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>>>>>> Info #4087-D: "including \"assembler_s390x.h\"" > >>>>>>>>> > >>>>>>>>> Info #4087-D: "including \"assembler_linux.h\"" > >>>>>>>>> > >>>>>>>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" > >>>>>>>>> > >>>>>>>>> Linux: > >>>>>>>>> ===== > >>>>>>>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>>>>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file > or > >>>>>>>>> directory > >>>>>>>>> compilation terminated. > >>>>>>>>> > >>>>>>>>> The problem on Linux is that 'linux' is already predefined to '1' > but > >>>>>>>>> that could be easily fixed for example by slightly changing the > name > >>>>>>>>> or by adding the underscore to the definiton of the OS macro > (i.e. > >>>>>>>>> -DOS=_linux). > >>>>>>>>> > >>>>>>>>> As I said, I'm still not sure if this looks nice? I just wanted to > >>>>>>>>> post my findings for discussion :) > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Volker > >>>>>>>>> > >>>>>>>>> [2] > >>>>>>>>> http://stackoverflow.com/questions/1852652/how-can-i- > include- > >> a- > >>>> file-whose-name-is-built-up-from-a-macro > >>>>>>>>> > >>>>>>>>> From goetz.lindenmaier at sap.com Thu Jul 14 08:31:31 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 08:31:31 +0000 Subject: s390x port progress: patch queue for hotspot assembled. In-Reply-To: <77e129a3-1a9f-5265-70c5-3a712b4a7536@oracle.com> References: <577A14CD.8020704@redhat.com> <577A61E1.3010803@redhat.com> <18854977-0002-e7bc-38b2-9d6715e7db5b@oracle.com> <0bd898c2-befb-1285-e662-2dbed4f445b4@oracle.com> <90d121ce-b0d2-e5eb-f951-33199ef9f3f3@oracle.com> <65a0127fd1b94e879d648547df6c621a@DEWDFE13DE09.global.corp.sap> <0d6753a9474f4181a15bd6a4637686a0@DEWDFE13DE09.global.corp.sap> <77e129a3-1a9f-5265-70c5-3a712b4a7536@oracle.com> Message-ID: <760e9f0b5bed43ecb1309e287ac16e40@DEWDFE13DE09.global.corp.sap> Hi David, > >> Is there a reason you didn't do what I had suggested with the above and > >> change the last _ to = ? > > * I think the names should match what is in the path, therefore I think > > CPU is better than ARCH (we have src/cpu/x86). > > * I left out "FAMILY". I don't see any gain in this part of the name. > > * Three of them are superfluous anyways. > > My view is that we should not change the names as they exist and thus > avoid the inevitable debates over arch versus cpu verus whatever. It is > messy enough that simply changing things again does not add any value in > my opinion. I think the matter of confusion is gone with my change. There are no more includes that require the _64 ending, so there is no need to distinguish two categories of cpu or arch macros or whatever expressed which processor the vm is compiled for. Before there was -DTARGET_ARCH_MODEL_$(HOTSPOT_TARGET_CPU) and -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) But now only one is left. Anyways, the old macros have been used strangely in a lot of places, so the name was misleading anyways. (See the cleanups I have posted.) I'll send a RFR soon. I use -DINCLUDE_SUFFIX_CPU=$(HOTSPOT_TARGET_CPU_ARCH) in the webrev. I wanted to reply directly on your mail, but maybe it's a good idea to continue the discussion in the RFR thread. Best regards, Goetz. > > > I thought about calling them INCLUDE_OS and INCLUDE_CPU, that > > better indicates what they are meant for. > > I also thought about only defining them in the macros.hpp file. We > > have -DLINUX -DAMD64 / -DAIX -DPPC64 etc. on the command line > > to identify which port to compile. > > Not quite sure what you mean. These things should be being set by the > build system for use in macros.hpp > > >> I thought my suggestion would avoid the issue > >> with the LINUX=1 problem. ? > > Do you want me to do -DTARGET_OS_FAMILY=_linux ? with '_'? > > The problem is that there is lower case #define linux=1. > > I don't think we should define things with leading '_', they are often > > used by the system headers / compilers. > > No I wasn't suggesting adding '_' - I thought we would avoid the issue. > :( Often wondered why C lacks a means to say "don't macro-expand this" > > > > I rebased my changes, that did not cause any conflicts. I also downloaded > > the changesets and patched them into my repo, that works too. > > You first need to apply the cleanups, then the new includes. > > Ah I see. > > Thanks, > David > > > Best regards, > > Goetz. > > > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 13. Juli 2016 05:43 > >> To: Lindenmaier, Goetz ; > >> 'dean.long at oracle.com' ; hotspot- > >> dev at openjdk.java.net > >> Subject: Re: s390x port progress: patch queue for hotspot assembled. > >> > >> Hi Goetz, > >> > >> Thanks for doing this! I think it looks good. Only nit ... > >> > >> On 13/07/2016 7:58 AM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I implemented a prototype of the include model proposed by Volker. > >>> I tested this so far on linux_x86_64, aix_ppc64 and linux_ppc64. > >>> I'll test it on the other OSes/CPUs I have available tomorrow. > >>> > >>> The direcitves > >>> -DTARGET_OS_FAMILY_linux > >>> -DTARGET_ARCH_MODEL_x86_64 > >>> -DTARGET_ARCH_x86 > >>> -DTARGET_OS_ARCH_MODEL_linux_x86_64 > >>> -DTARGET_OS_ARCH_linux_x86 > >>> are replaced by -DTARGET_OS=linux -DTARGET_CPU=x86. > >>> (OS and CPU are used for vm_version.cpp) > >> > >> Is there a reason you didn't do what I had suggested with the above and > >> change the last _ to = ? I thought my suggestion would avoid the issue > >> with the LINUX=1 problem. ?? > >> > >> I was going to test this out with our other platforms but unfortunately > >> the patch didn't apply on latest jdk9/hs. > >> > >> Thanks, > >> David > >> > >>> The macros proposed by Volker are in utilities/macros.hpp. > >>> > >>> There are some places where above TARGET_... macros are used for > other > >>> purposes than guarding the includes, I replaced them to use the other > >>> platform dependent macros already defined. > >>> > >>> I also removed all headers carying _64 or _32 in their name. > >>> There were three on ppc. As I learned there is no PPC32 port > >>> any more, so changing this should be fine. I found one on x86 > >> (stubRoutines...hpp). > >>> I merged it and use LP64 guards for the differences. I think this is > >>> acceptable as the files are rather small and it's the only case. > >>> > >>> The adlc generated files all had suffix _64/_32 which I removed. > >>> These are not significant, either. > >>> > >>> All this normalizing edits can be found in this webrev. It would be > >>> useful to apply them anyways: > >>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev-cleanups/ > >>> The real change is here: > >>> http://cr.openjdk.java.net/~goetz/wr16/newPfmIncl/webrev- > >> newIncludes/ > >>> I had to do a tweak for the #define linux=1 in macros.hpp. > >>> > >>> Please have a look at these changes. Also, check whether this > >>> works fine with the IDE of your choice :) > >>> > >>> If this finds appreciation, I'll open an Enhancement and make a > >>> real webrev/RFR. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] > On > >>>> Behalf Of dean.long at oracle.com > >>>> Sent: Wednesday, July 06, 2016 7:49 AM > >>>> To: hotspot-dev at openjdk.java.net > >>>> Subject: Re: s390x port progress: patch queue for hotspot assembled. > >>>> > >>>> On 7/5/16 10:42 PM, dean.long at oracle.com wrote: > >>>> > >>>>> On 7/4/16 2:59 PM, David Holmes wrote: > >>>>> > >>>>>> On 5/07/2016 7:44 AM, Stefan Karlsson wrote: > >>>>>>> On 2016-07-04 23:03, David Holmes wrote: > >>>>>>>> On 5/07/2016 12:07 AM, Volker Simonis wrote: > >>>>>>>>> On Mon, Jul 4, 2016 at 3:17 PM, Andrew Haley > > >>>> wrote: > >>>>>>>>>> On 04/07/16 12:22, David Holmes wrote: > >>>>>>>>>> > >>>>>>>>>>> Unless the files are included into more than one other file > then > >>>>>>>>>>> adding > >>>>>>>>>>> a level of indirection doesn't really help anything. > >>>>>>>>>> > >>>>>>>>>> I'm not sure what this means. > >>>>>>>>>> > >>>>>>>>>>> But I don't see why the platform part of the name needs to be > >> kept > >>>>>>>>>>> when > >>>>>>>>>>> it is already part of the path? > >>>>>>>>>> > >>>>>>>>>> When switching between files in an editor, one doesn't usually > >>>>>>>>>> type in the full path, but the filename. I'd be very sad to lose > >>>>>>>>>> that, and I think that unique filenames are a nice thing to have. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> In Emacs you can try the uniquify [1] extension which would > solve > >> the > >>>>>>>>> problem. I already use it for editing various hotspot version (i.e. > >>>>>>>>> hs-comp, jdk9-dev) in one Emacs. But I agree that Emacs is > >> probably > >>>>>>>>> not a practical solution for everybody :) > >>>>>>>>> > >>>>>>>>> [1] > >>>>>>>>> > >>>> > >> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Uniquify. > >>>> html > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Andrew. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> We could try something like this (adapted from [2]) although I'm > >> not > >>>>>>>>> sure if that's really a good solution (i.e. if it is treated right by > >>>>>>>>> various IDEs): > >>>>>>>>> > >>>>>>>>> include_test.cpp > >>>>>>>>> ============ > >>>>>>>>> > >>>>>>>>> #define xstr(x) #x > >>>>>>>>> #define str(x) xstr(x) > >>>>>>>>> #define sub(x) x > >>>>>>>>> #define cpu_header(x) str(sub(x)sub(_)CPU.hpp) > >>>>>>>>> #define os_header(x) str(sub(x)sub(_)OS.hpp) > >>>>>>>>> #define os_cpu_header(x) > >> str(sub(x)sub(_)sub(OS)sub(_)CPU.hpp) > >>>>>>>>> > >>>>>>>>> #include cpu_header(assembler) > >>>>>>>>> #include os_header(assembler) > >>>>>>>>> #include os_cpu_header(assembler) > >>>>>>>> > >>>>>>>> This is the parameterization I thought was not possible. For some > >>>>>>>> reason I thought #define'd values could not be used within > #include > >>>>>>>> directives. > >>>>>>> > >>>>>>> FWIW, we tried a similar approach when includeDB was removed, > but > >>>>>>> abandoned it because of the problem described below with the > 'linux' > >>>>>>> define. > >>>>>> > >>>>>> Give we have in the build (eg for linux x86) presently: > >>>>>> > >>>>>> -DTARGET_OS_FAMILY_linux > >>>>>> -DTARGET_ARCH_MODEL_x86_32 > >>>>>> -DTARGET_ARCH_x86 > >>>>>> -DTARGET_OS_ARCH_MODEL_linux_x86_32 > >>>>>> -DTARGET_OS_ARCH_linux_x86 > >>>>>> > >>>>>> I wonder if we can simply replace the above with: > >>>>>> > >>>>>> -DTARGET_OS_FAMILY=linux > >>>>>> -DTARGET_ARCH_MODEL=x86_32 > >>>>>> -DTARGET_ARCH=x86 > >>>>>> -DTARGET_OS_ARCH_MODEL=linux_x86_32 > >>>>>> -DTARGET_OS_ARCH=linux_x86 > >>>>>> > >>>>>> and use those variables for the include directives? > >>>>>> > >>>>> > >>>>> I remember experimenting with that idea, but gave up because I > >>>>> couldn't get it work. > >>>>> What I ended up doing was something like this: > >>>>> > >>>>> #*include* C1_LIRGENERATOR_MD_HPP > >>>>> > >>>> > >>>> Oops, let's try that again: > >>>> > >>>> #include C1_LIRGENERATOR_MD_HPP > >>>> > >>>> where, using x86 as an example, macros like > C1_LIRGENERATOR_MD_HPP > >>>> are > >>>> defined in globalDefinitions_x86.hpp: > >>>> > >>>> #define C1_LIRGENERATOR_MD_HPP "c1_LIRGenerator_x86.hpp" > >>>> > >>>> dl > >>>> > >>>>> I don't know if this confuses IDEs or not. > >>>>> > >>>>> dl > >>>>> > >>>>>> David > >>>>>> > >>>>>>> StefanK > >>>>>>> > >>>>>>>> > >>>>>>>> This looks very workable to me. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> > >>>>>>>>> assembler_s390x.hpp > >>>>>>>>> ================ > >>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") > >>>>>>>>> > >>>>>>>>> assembler_linux.hpp > >>>>>>>>> =============== > >>>>>>>>> #pragma message ("including \"assembler_linux.h\"") > >>>>>>>>> > >>>>>>>>> assembler_linux_s390x.hpp > >>>>>>>>> ==================== > >>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> It works on all the platforms I have tested so far (see below) > except > >>>>>>>>> Linux where it needs some tweaks (see comments below): > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Solaris: > >>>>>>>>> ====== > >>>>>>>>> /SS12u4/SUNWspro/bin/CC -DCPU=s390x -DOS="linux" -E > >>>> include_test.cpp > >>>>>>>>> #1 "include_test.cpp" > >>>>>>>>> #1 "assembler_s390x.hpp" > >>>>>>>>> #pragma message ( "including \"assembler_s390x.h\"" ) > >>>>>>>>> #1 "assembler_linux.hpp" > >>>>>>>>> #pragma message ( "including \"assembler_linux.h\"" ) > >>>>>>>>> #1 "assembler_linux_s390x.hpp" > >>>>>>>>> #pragma message ( "including \"assembler_linux_s390x.h\"" ) > >>>>>>>>> > >>>>>>>>> AIX: > >>>>>>>>> === > >>>>>>>>> /usr/vacpp_V12/usr/vacpp/bin/xlC_r -DCPU=s390x -DOS=linux - > c > >>>>>>>>> include_test.cpp > >>>>>>>>> "assembler_s390x.hpp", line 1.9: 1540-1401 (I) An unknown > >> "pragma > >>>>>>>>> message" is specified. > >>>>>>>>> "assembler_linux.hpp", line 1.9: 1540-1401 (I) An unknown > "pragma > >>>>>>>>> message" is specified. > >>>>>>>>> "assembler_linux_s390x.hpp", line 1.9: 1540-1401 (I) An > unknown > >>>>>>>>> "pragma message" is specified. > >>>>>>>>> > >>>>>>>>> MacOS X > >>>>>>>>> ======= > >>>>>>>>> /usr/bin/clang++ -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>>>>>> In file included from include_test.cpp:8: > >>>>>>>>> ./assembler_s390x.hpp:1:9: warning: including > >> "assembler_s390x.h" > >>>>>>>>> [-W#pragma-messages] > >>>>>>>>> #pragma message ("including \"assembler_s390x.h\"") > >>>>>>>>> ^ > >>>>>>>>> In file included from include_test.cpp:9: > >>>>>>>>> ./assembler_linux.hpp:1:9: warning: including > "assembler_linux.h" > >>>>>>>>> [-W#pragma-messages] > >>>>>>>>> #pragma message ("including \"assembler_linux.h\"") > >>>>>>>>> ^ > >>>>>>>>> In file included from include_test.cpp:10: > >>>>>>>>> ./assembler_linux_s390x.hpp:1:9: warning: including > >>>>>>>>> "assembler_linux_s390x.h" [-W#pragma-messages] > >>>>>>>>> #pragma message ("including \"assembler_linux_s390x.h\"") > >>>>>>>>> ^ > >>>>>>>>> 3 warnings generated. > >>>>>>>>> > >>>>>>>>> Windows: > >>>>>>>>> ======= > >>>>>>>>> $ /cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl - > DCPU=s390x > >>>>>>>>> -DOS=linux -c include_test. > >>>>>>>>> cpp > >>>>>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 > for > >>>>>>>>> x64 > >>>>>>>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>>>>>>> > >>>>>>>>> include_test.cpp > >>>>>>>>> including "assembler_s390x.h" > >>>>>>>>> including "assembler_linux.h" > >>>>>>>>> including "assembler_linux_s390x.h" > >>>>>>>>> > >>>>>>>>> HPUX: > >>>>>>>>> ===== > >>>>>>>>> $ /opt/aCC/bin/aCC -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>>>>>> Info #4087-D: "including \"assembler_s390x.h\"" > >>>>>>>>> > >>>>>>>>> Info #4087-D: "including \"assembler_linux.h\"" > >>>>>>>>> > >>>>>>>>> Info #4087-D: "including \"assembler_linux_s390x.h\"" > >>>>>>>>> > >>>>>>>>> Linux: > >>>>>>>>> ===== > >>>>>>>>> g++ -DCPU=s390x -DOS=linux -c include_test.cpp > >>>>>>>>> include_test.cpp:9:30: fatal error: assembler_1.hpp: No such file > or > >>>>>>>>> directory > >>>>>>>>> compilation terminated. > >>>>>>>>> > >>>>>>>>> The problem on Linux is that 'linux' is already predefined to '1' > but > >>>>>>>>> that could be easily fixed for example by slightly changing the > name > >>>>>>>>> or by adding the underscore to the definiton of the OS macro > (i.e. > >>>>>>>>> -DOS=_linux). > >>>>>>>>> > >>>>>>>>> As I said, I'm still not sure if this looks nice? I just wanted to > >>>>>>>>> post my findings for discussion :) > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Volker > >>>>>>>>> > >>>>>>>>> [2] > >>>>>>>>> http://stackoverflow.com/questions/1852652/how-can-i- > include- > >> a- > >>>> file-whose-name-is-built-up-from-a-macro > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >>> From michail.chernov at oracle.com Thu Jul 14 16:21:58 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 14 Jul 2016 19:21:58 +0300 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM Message-ID: <5787BC26.2000602@oracle.com> Hi, Could I have a reviews for this change, please? https://bugs.openjdk.java.net/browse/JDK-8161208 http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ This issue is started since this fix: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html This change fixes two issues: 1. Avoiding of java.management usage with minimal VM (JTreg was started with '-vmoptions:"-minimal"' and worked as expected). 2. Adding appropriate modules for proper VMProps execution on non-full JDK images (JTreg was tested with '-vmoptions:"-limitmods java.base"', java.compact1, java.compact2 and so on - JTreg is started and works as expected). Tested locally and via RBT/JPRT. Thanks Michail From dmitry.fazunenko at oracle.com Thu Jul 14 16:28:03 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 14 Jul 2016 19:28:03 +0300 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM In-Reply-To: <5787BC26.2000602@oracle.com> References: <5787BC26.2000602@oracle.com> Message-ID: Michail, the fix looks good to me. Before push, please fix: 135 if ( "minimal".equals(flavor)) 136 return "false"; --> 135 if ("minimal".equals(flavor)) { 136 return "false"; 137 } To meet the Java Coding Style. Thanks, Dima On 14.07.2016 19:21, Michail Chernov wrote: > Hi, > > Could I have a reviews for this change, please? > > https://bugs.openjdk.java.net/browse/JDK-8161208 > http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ > http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ > > This issue is started since this fix: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html > > > This change fixes two issues: > 1. Avoiding of java.management usage with minimal VM (JTreg was > started with '-vmoptions:"-minimal"' and worked as expected). > 2. Adding appropriate modules for proper VMProps execution on non-full > JDK images (JTreg was tested with '-vmoptions:"-limitmods java.base"', > java.compact1, java.compact2 and so on - JTreg is started and works as > expected). > > Tested locally and via RBT/JPRT. > > Thanks > Michail From michail.chernov at oracle.com Thu Jul 14 16:32:34 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 14 Jul 2016 19:32:34 +0300 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM In-Reply-To: References: <5787BC26.2000602@oracle.com> Message-ID: <5787BEA2.1000605@oracle.com> Hi Dima, Thank you for reviewing this, I will make the changes you mentioned. Michail On 07/14/2016 07:28 PM, Dmitry Fazunenko wrote: > Michail, > > the fix looks good to me. > Before push, please fix: > > 135 if ( "minimal".equals(flavor)) > 136 return "false"; --> 135 if ("minimal".equals(flavor)) { > 136 return "false"; 137 } > To meet the Java Coding Style. > > Thanks, > Dima > > On 14.07.2016 19:21, Michail Chernov wrote: >> Hi, >> >> Could I have a reviews for this change, please? >> >> https://bugs.openjdk.java.net/browse/JDK-8161208 >> http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ >> http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ >> >> This issue is started since this fix: >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html >> >> >> This change fixes two issues: >> 1. Avoiding of java.management usage with minimal VM (JTreg was >> started with '-vmoptions:"-minimal"' and worked as expected). >> 2. Adding appropriate modules for proper VMProps execution on >> non-full JDK images (JTreg was tested with '-vmoptions:"-limitmods >> java.base"', java.compact1, java.compact2 and so on - JTreg is >> started and works as expected). >> >> Tested locally and via RBT/JPRT. >> >> Thanks >> Michail > From david.holmes at oracle.com Fri Jul 15 05:31:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jul 2016 15:31:10 +1000 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM In-Reply-To: <5787BC26.2000602@oracle.com> References: <5787BC26.2000602@oracle.com> Message-ID: Hi Michail, On 15/07/2016 2:21 AM, Michail Chernov wrote: > Hi, > > Could I have a reviews for this change, please? > > https://bugs.openjdk.java.net/browse/JDK-8161208 > http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ > http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ > > This issue is started since this fix: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html I think I would have objected to the form of that fix - VMProps was only looking at information available via system properties. > This change fixes two issues: > 1. Avoiding of java.management usage with minimal VM (JTreg was started > with '-vmoptions:"-minimal"' and worked as expected). Okay. > 2. Adding appropriate modules for proper VMProps execution on non-full > JDK images (JTreg was tested with '-vmoptions:"-limitmods java.base"', > java.compact1, java.compact2 and so on - JTreg is started and works as > expected). Was that testing done with a full VM or the Minimal VM? On a full VM limited to compact1, compact2 or java.base, java.lang.management will not be present, but we will execute the query code in VMProps as it isn't the minimal VM. Thanks, David > Tested locally and via RBT/JPRT. > > Thanks > Michail From gnu.andrew at redhat.com Fri Jul 15 15:22:10 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 Jul 2016 11:22:10 -0400 (EDT) Subject: PING: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> <577F4C58.6060101@oracle.com> <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> Message-ID: <788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com> Ping? ----- Original Message ----- > ----- Original Message ----- > > Hello, > > > > It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always returning > > yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and > > C++ checks. > > > > Ugh, merged a block in the wrong place by the looks of it. > > Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/ > > configure:29739: checking if the C++ compiler supports "-std=gnu++98 " > configure:29755: /usr/bin/g++ -c -std=gnu++98 conftest.cpp >&5 > configure:29755: $? = 0 > configure:29769: result: yes > configure:29815: checking if the C compiler supports > "-fno-delete-null-pointer-checks -Werror" > configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks -Werror > conftest.c >&5 > configure:29832: $? = 0 > configure:29846: result: yes > configure:29855: checking if the C++ compiler supports > "-fno-delete-null-pointer-checks -Werror" > configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks -Werror > conftest.cpp >&5 > configure:29871: $? = 0 > configure:29885: result: yes > configure:29894: checking if both compilers support > "-fno-delete-null-pointer-checks -Werror" > configure:29899: result: yes > configure:29911: checking if the C compiler supports "-fno-lifetime-dse > -Werror" > configure:29927: /usr/bin/gcc -c -fno-lifetime-dse -Werror conftest.c >&5 > configure:29927: $? = 0 > configure:29941: result: yes > configure:29950: checking if the C++ compiler supports "-fno-lifetime-dse > -Werror" > configure:29966: /usr/bin/g++ -c -fno-lifetime-dse -Werror conftest.cpp >&5 > configure:29966: $? = 0 > configure:29980: result: yes > configure:29989: checking if both compilers support "-fno-lifetime-dse > -Werror" > configure:29994: result: yes > > > > /Erik > > > > On 2016-07-07 22:21, Andrew Hughes wrote: > > > Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 > > > > > > This is a backport of the original fix to support building OpenJDK > > > with GCC 6. It was necessary to cherry-pick parts of a number of > > > earlier fixes to make this work with the build system in 8: > > > > > > 8149647: Incremental enhancements from build-infra > > > 8032045: Enable compiler and linker safety switches for debug builds > > > > > > and so I'm requesting a review of the 8 version of the patch here as well > > > as approval for 8u. > > > > > > In brief, the patch makes OpenJDK build with GCC 6 by explicitly > > > specifying > > > the C++ standard to use (-std=gnu++98) and disabling two optimisations > > > with > > > -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further > > > information > > > on the changes is available in the GCC 6 release notes [0]. GCC 6 uses > > > a newer C++ standard, C++14, with which the OpenJDK codebase is not yet > > > compliant. The simplest way to fix this, especially for existing > > > releases, > > > is to explicitly request the previous default, gnu++98. The deletion > > > of null pointer checks and more aggressive lifetime dead store > > > elimination > > > in 6 lead to a crashing virtual machine being built, so we disable them > > > if GCC >= 6 is used. > > > > > > To make the original patch work with 8u, a number of changes from other > > > fixes had to also be brought over: > > > > > > * We need to check we are using GCC 6 or above, so we need to bring > > > over the TOOLCHAIN_CHECK_COMPILER_VERSION and > > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. > > > TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional > > > numbered rather than named argument macro so we don't need to backport > > > BASIC_DEFUN_NAMED. > > > * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 > > > as we need to apply the -std option only to the C++ compiler, not the > > > C compiler. If passed to the C compiler, it will produce a warning, > > > and this is converted to an error at one point in the build > > > (a -Werror in libsctp). > > > > > > Generally, we've kept things in toolchain.m4 (8034788 introduced > > > flags.m4, > > > separating out some code, and so many of these changes are in that file > > > in 9) and avoid named argument macros. Otherwise, it's largely the > > > same as the 9 version. We have adopted the longer name for > > > the -fno-delete-null-pointer-checks flag variable as suggested in the > > > review of the update to this patch for the new HotSpot build [1]. > > > > > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > > > [1] > > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html > > > > > > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From kim.barrett at oracle.com Fri Jul 15 18:35:08 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Jul 2016 14:35:08 -0400 Subject: RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6 In-Reply-To: <1461764727.4609223.1468437153322.JavaMail.zimbra@redhat.com> References: <20160711184513.GA1485@redhat.com> <20D15A8D-1C0A-4D44-9E83-A99B38622A6C@oracle.com> <1655965499.4239256.1468347672234.JavaMail.zimbra@redhat.com> <27891E85-5736-4D44-8D79-1C44B01499EE@oracle.com> <1461764727.4609223.1468437153322.JavaMail.zimbra@redhat.com> Message-ID: > On Jul 13, 2016, at 3:12 PM, Andrew Hughes wrote: > > > > ----- Original Message ----- >>> On Jul 12, 2016, at 2:21 PM, Andrew Hughes wrote: >>> The workaround that currently works for me is: >>> >>> diff -r b515beb3b4ad src/share/vm/utilities/globalDefinitions.hpp >>> --- a/src/share/vm/utilities/globalDefinitions.hpp Thu Jul 07 18:40:53 2016 >>> +0100 >>> +++ b/src/share/vm/utilities/globalDefinitions.hpp Tue Jul 12 19:13:51 2016 >>> +0100 >>> @@ -1163,8 +1163,10 @@ >>> #undef min >>> #endif >>> >>> +#ifndef _GLIBCXX_STDLIB_H >>> #define max(a,b) Do_not_use_max_use_MAX2_instead >>> #define min(a,b) Do_not_use_min_use_MIN2_instead >>> +#endif >>> >>> // It is necessary to use templates here. Having normal overloaded >>> // functions does not work because it is necessary to provide both 32- >>> >>> >>> _GLIBCXX_STDLIB_H only exists in GCC 6. Earlier versions use stdlib.h from >>> the >>> C library. Thus this seems to provide the solution of only disabling >>> those macros only on GCC >= 6 where they conflict with the functions >>> max and min defined by this C++ stdlib.h wrapper (see stdlib.h changes >>> in [0]) >> >> Since when does define / declare min or max? To me, that seems >> like a bug in this wrapper. > > It doesn't; it's defined in . > > The stdlib.h C++ wrapper is new to GCC 6, and thus so is the define, so we > can use it to just disable these macros on that version. > > It also wouldn't surprise me that the error is down to one of these new > wrapper headers bringing in other C++ headers, including limits. I > can't find the exact path for such an inclusion, but this issue > only shows up on GCC 6, where the wrapper headers are present. > Including on earlier versions just uses the C > header, not . That seems a likely explanation. If my conjecture about these being intended to poison the windefs.h definitions is correct, then we could just move these definitions to globalDefinitions_visCPP.hpp. But I don't know if anyone could answer that definitively. We try pretty hard to avoid platform-specific #ifdefs and the like in otherwise generic code. I think that's a good thing, hence my reluctance to conditionalize on _GLIBCXX_STDLIB_H. After some experiments, my preferred solution would be the blue paint approach I suggested as a possibility earlier, e.g. #define max max #define min min A later attempt to (re)define without #undef would make the program ill-formed, and all the compilers Oracle supports report such. In the absence of any attempt to redefine, the macros expand to similarly named identifiers, e.g. it's as if the macro definitions didn't exist, except for defined(max) &etc being true. From mikael.gerdin at oracle.com Mon Jul 18 11:27:07 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 18 Jul 2016 13:27:07 +0200 Subject: RFR(silly) 8161027: GPL header missing comma after year Message-ID: <578CBD0B.4010402@oracle.com> Hi all, It seems that sometime last year I forgot some commas in two GPL headers. Please review the attached patch to fix this. Unfortunately the JBS entry is confidential but it provides no further information about the issue. diff --git a/src/share/vm/utilities/resourceHash.cpp b/src/share/vm/utilities/resourceHash.cpp --- a/src/share/vm/utilities/resourceHash.cpp +++ b/src/share/vm/utilities/resourceHash.cpp @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 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 diff --git a/src/share/vm/utilities/resourceHash.hpp b/src/share/vm/utilities/resourceHash.hpp --- a/src/share/vm/utilities/resourceHash.hpp +++ b/src/share/vm/utilities/resourceHash.hpp @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 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 After review I intend to push this straight away since the fix is simple and only affects comments. /Mikael From claes.redestad at oracle.com Mon Jul 18 11:42:30 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 Jul 2016 13:42:30 +0200 Subject: RFR(silly) 8161027: GPL header missing comma after year In-Reply-To: <578CBD0B.4010402@oracle.com> References: <578CBD0B.4010402@oracle.com> Message-ID: <578CC0A6.60107@oracle.com> Ship it! On 2016-07-18 13:27, Mikael Gerdin wrote: > Hi all, > > It seems that sometime last year I forgot some commas in two GPL headers. > Please review the attached patch to fix this. > > Unfortunately the JBS entry is confidential but it provides no further > information about the issue. > > diff --git a/src/share/vm/utilities/resourceHash.cpp > b/src/share/vm/utilities/resourceHash.cpp > --- a/src/share/vm/utilities/resourceHash.cpp > +++ b/src/share/vm/utilities/resourceHash.cpp > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 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 > diff --git a/src/share/vm/utilities/resourceHash.hpp > b/src/share/vm/utilities/resourceHash.hpp > --- a/src/share/vm/utilities/resourceHash.hpp > +++ b/src/share/vm/utilities/resourceHash.hpp > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2012, 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 > > After review I intend to push this straight away since the fix is > simple and only affects comments. > > > /Mikael From david.holmes at oracle.com Mon Jul 18 12:24:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jul 2016 22:24:39 +1000 Subject: RFR(silly) 8161027: GPL header missing comma after year In-Reply-To: <578CC0A6.60107@oracle.com> References: <578CBD0B.4010402@oracle.com> <578CC0A6.60107@oracle.com> Message-ID: <6d3229b5-9bef-9241-93df-e96ebcc54335@oracle.com> +1 David On 18/07/2016 9:42 PM, Claes Redestad wrote: > Ship it! > > On 2016-07-18 13:27, Mikael Gerdin wrote: >> Hi all, >> >> It seems that sometime last year I forgot some commas in two GPL headers. >> Please review the attached patch to fix this. >> >> Unfortunately the JBS entry is confidential but it provides no further >> information about the issue. >> >> diff --git a/src/share/vm/utilities/resourceHash.cpp >> b/src/share/vm/utilities/resourceHash.cpp >> --- a/src/share/vm/utilities/resourceHash.cpp >> +++ b/src/share/vm/utilities/resourceHash.cpp >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 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 >> diff --git a/src/share/vm/utilities/resourceHash.hpp >> b/src/share/vm/utilities/resourceHash.hpp >> --- a/src/share/vm/utilities/resourceHash.hpp >> +++ b/src/share/vm/utilities/resourceHash.hpp >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2012, 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 >> >> After review I intend to push this straight away since the fix is >> simple and only affects comments. >> >> >> /Mikael > From mikael.gerdin at oracle.com Mon Jul 18 12:48:49 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 18 Jul 2016 14:48:49 +0200 Subject: RFR(silly) 8161027: GPL header missing comma after year In-Reply-To: <6d3229b5-9bef-9241-93df-e96ebcc54335@oracle.com> References: <578CBD0B.4010402@oracle.com> <578CC0A6.60107@oracle.com> <6d3229b5-9bef-9241-93df-e96ebcc54335@oracle.com> Message-ID: <578CD031.3020102@oracle.com> Thanks David and Claes for the prompt responses. /Mikael On 2016-07-18 14:24, David Holmes wrote: > +1 > > David > > On 18/07/2016 9:42 PM, Claes Redestad wrote: >> Ship it! >> >> On 2016-07-18 13:27, Mikael Gerdin wrote: >>> Hi all, >>> >>> It seems that sometime last year I forgot some commas in two GPL >>> headers. >>> Please review the attached patch to fix this. >>> >>> Unfortunately the JBS entry is confidential but it provides no further >>> information about the issue. >>> >>> diff --git a/src/share/vm/utilities/resourceHash.cpp >>> b/src/share/vm/utilities/resourceHash.cpp >>> --- a/src/share/vm/utilities/resourceHash.cpp >>> +++ b/src/share/vm/utilities/resourceHash.cpp >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2015 Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 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 >>> diff --git a/src/share/vm/utilities/resourceHash.hpp >>> b/src/share/vm/utilities/resourceHash.hpp >>> --- a/src/share/vm/utilities/resourceHash.hpp >>> +++ b/src/share/vm/utilities/resourceHash.hpp >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2012, 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 >>> >>> After review I intend to push this straight away since the fix is >>> simple and only affects comments. >>> >>> >>> /Mikael >> From max.ockner at oracle.com Mon Jul 18 19:19:50 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 18 Jul 2016 15:19:50 -0400 Subject: RFR: 8038332: Added trace event vm/class/define Message-ID: <578D2BD6.1000807@oracle.com> Hello, After some extended brainstorming with Karen, Marcus Hirt, and Eric Gahlin, we have decided to pursue a cleaner solution for this bug. The original issue suggests that the vm/class/load event should fire during JVM_DefineClass*, but it was difficult to think of a solution with no duplicates or omitted events. We settled on adding a new vm/class/define event which is fired on updates to SystemDictionary. Webrev: http://cr.openjdk.java.net/~mockner/8038332.04/ Thanks, Max From erik.gahlin at oracle.com Mon Jul 18 20:01:07 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 18 Jul 2016 22:01:07 +0200 Subject: RFR: 8038332: Added trace event vm/class/define In-Reply-To: <578D2BD6.1000807@oracle.com> References: <578D2BD6.1000807@oracle.com> Message-ID: <578D3583.9050302@oracle.com> Looks good! Erik On 2016-07-18 21:19, Max Ockner wrote: > Hello, > > After some extended brainstorming with Karen, Marcus Hirt, and Eric > Gahlin, we have decided to pursue a cleaner solution for this bug. The > original issue suggests that the vm/class/load event should fire > during JVM_DefineClass*, but it was difficult to think of a solution > with no duplicates or omitted events. We settled on adding a new > vm/class/define event which is fired on updates to SystemDictionary. > > Webrev: http://cr.openjdk.java.net/~mockner/8038332.04/ > > Thanks, > Max From karen.kinnear at oracle.com Mon Jul 18 20:12:00 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 18 Jul 2016 16:12:00 -0400 Subject: RFR: 8038332: Added trace event vm/class/define In-Reply-To: <578D3583.9050302@oracle.com> References: <578D2BD6.1000807@oracle.com> <578D3583.9050302@oracle.com> Message-ID: <5DF2F328-24A1-416C-BE19-870A8E442640@oracle.com> Max, Looks good. Many thanks for reworking this. thanks, Karen > On Jul 18, 2016, at 4:01 PM, Erik Gahlin wrote: > > Looks good! > > Erik > > On 2016-07-18 21:19, Max Ockner wrote: >> Hello, >> >> After some extended brainstorming with Karen, Marcus Hirt, and Eric Gahlin, we have decided to pursue a cleaner solution for this bug. The original issue suggests that the vm/class/load event should fire during JVM_DefineClass*, but it was difficult to think of a solution with no duplicates or omitted events. We settled on adding a new vm/class/define event which is fired on updates to SystemDictionary. >> >> Webrev: http://cr.openjdk.java.net/~mockner/8038332.04/ >> >> Thanks, >> Max > From vladimir.kozlov at oracle.com Mon Jul 18 22:32:23 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Jul 2016 15:32:23 -0700 Subject: RFR: 8159052: aarch64: optimise unaligned copies in pd_disjoint_words and pd_conjoint_words In-Reply-To: <57581E4A.6070503@redhat.com> References: <1465392530.28716.52.camel@mylittlepony.linaroharston> <57581E4A.6070503@redhat.com> Message-ID: <45110897-ff71-c064-f4a7-88c3d11f415e@oracle.com> Yes, aarch64 specific changes are easy to approve. Add FC Extension Request and "jdk9-fc-request" label to RFEs targeted JDK 9. Thanks, Vladimir On 6/8/16 6:31 AM, Andrew Haley wrote: > On 08/06/16 14:28, Edward Nevill wrote: >> I understand that this cannot be pushed to jdk 9 at the moment because >> jdk 9 is FC, however I would like to push this to the aarch64 port jdk8u >> repo so it has a save home to be migrated to jdk 9/jdk 9u/jdk 10 in the >> future. >> >> OK to push to jdk8u? > > OK. This is also OK for jdk9 once we figure out how to get approval. > > Andrew. > From zoltan.majo at oracle.com Tue Jul 19 07:58:38 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 19 Jul 2016 09:58:38 +0200 Subject: [9] RFR (XS): 8161660: Quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java Message-ID: <578DDDAE.4010504@oracle.com> Hi, please review the patch for quarantining Quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java [1]. The tests recently started failing in the jdk9/dev repository [2]; the problem currently prohibits us from pushing into the repository using JPRT. Once reviewed, I plan to push the fix directly into jdk9/dev. Here is the webrev: http://cr.openjdk.java.net/~zmajo/8161660/webrev.00/ Thank you! Best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8161660 [2] https://bugs.openjdk.java.net/browse/JDK-8161552 From tobias.hartmann at oracle.com Tue Jul 19 08:15:10 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 19 Jul 2016 10:15:10 +0200 Subject: [9] RFR (XS): 8161660: Quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java In-Reply-To: <578DDDAE.4010504@oracle.com> References: <578DDDAE.4010504@oracle.com> Message-ID: <578DE18E.4040602@oracle.com> Hi Zoltan, looks good! Best regards, Tobias On 19.07.2016 09:58, Zolt?n Maj? wrote: > Hi, > > > please review the patch for quarantining Quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java [1]. The tests recently started failing in the jdk9/dev repository [2]; the problem currently prohibits us from pushing into the repository using JPRT. > > Once reviewed, I plan to push the fix directly into jdk9/dev. > > Here is the webrev: > > http://cr.openjdk.java.net/~zmajo/8161660/webrev.00/ > > Thank you! > > Best regards, > > > Zoltan > > [1] https://bugs.openjdk.java.net/browse/JDK-8161660 > [2] https://bugs.openjdk.java.net/browse/JDK-8161552 > From david.holmes at oracle.com Tue Jul 19 08:32:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Jul 2016 18:32:40 +1000 Subject: [9] RFR (XS): 8161660: Quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java In-Reply-To: <578DDDAE.4010504@oracle.com> References: <578DDDAE.4010504@oracle.com> Message-ID: Looks good. Thanks, David On 19/07/2016 5:58 PM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for quarantining Quarantine > TestParallelHeapSizeFlags.java and TestSmallHeap.java [1]. The tests > recently started failing in the jdk9/dev repository [2]; the problem > currently prohibits us from pushing into the repository using JPRT. > > Once reviewed, I plan to push the fix directly into jdk9/dev. > > Here is the webrev: > > http://cr.openjdk.java.net/~zmajo/8161660/webrev.00/ > > Thank you! > > Best regards, > > > Zoltan > > [1] https://bugs.openjdk.java.net/browse/JDK-8161660 > [2] https://bugs.openjdk.java.net/browse/JDK-8161552 > From zoltan.majo at oracle.com Tue Jul 19 08:33:54 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 19 Jul 2016 10:33:54 +0200 Subject: [9] RFR (XS): 8161660: Quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java In-Reply-To: References: <578DDDAE.4010504@oracle.com> Message-ID: <578DE5F2.1010501@oracle.com> Thank you, David and Tobias, for the review! Best regards, Zoltan On 07/19/2016 10:32 AM, David Holmes wrote: > Looks good. > > Thanks, > David > > On 19/07/2016 5:58 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for quarantining Quarantine >> TestParallelHeapSizeFlags.java and TestSmallHeap.java [1]. The tests >> recently started failing in the jdk9/dev repository [2]; the problem >> currently prohibits us from pushing into the repository using JPRT. >> >> Once reviewed, I plan to push the fix directly into jdk9/dev. >> >> Here is the webrev: >> >> http://cr.openjdk.java.net/~zmajo/8161660/webrev.00/ >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8161660 >> [2] https://bugs.openjdk.java.net/browse/JDK-8161552 >> From michail.chernov at oracle.com Tue Jul 19 13:35:35 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Tue, 19 Jul 2016 16:35:35 +0300 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM In-Reply-To: References: <5787BC26.2000602@oracle.com> Message-ID: <578E2CA7.7010400@oracle.com> Hi David, Thanks for your answer. I revised code that checks FlightRecorder status. At my point of view better way is to use WhiteBox to get VM flag value. This allows not to use additional dependencies for VMProps. Updated webrev: http://cr.openjdk.java.net/~mchernov/8161208/webrev.01/ Tested locally on Open JDK build, and Oracle JDK (Linux x64 , Linux x86 - server and minimal VM). Thanks, Michail On 15.07.2016 08:31, David Holmes wrote: > Hi Michail, > > On 15/07/2016 2:21 AM, Michail Chernov wrote: >> Hi, >> >> Could I have a reviews for this change, please? >> >> https://bugs.openjdk.java.net/browse/JDK-8161208 >> http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ >> http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ >> >> This issue is started since this fix: >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html >> > > I think I would have objected to the form of that fix - VMProps was > only looking at information available via system properties. > >> This change fixes two issues: >> 1. Avoiding of java.management usage with minimal VM (JTreg was started >> with '-vmoptions:"-minimal"' and worked as expected). > > Okay. > >> 2. Adding appropriate modules for proper VMProps execution on non-full >> JDK images (JTreg was tested with '-vmoptions:"-limitmods java.base"', >> java.compact1, java.compact2 and so on - JTreg is started and works as >> expected). > > Was that testing done with a full VM or the Minimal VM? On a full VM > limited to compact1, compact2 or java.base, java.lang.management will > not be present, but we will execute the query code in VMProps as it > isn't the minimal VM. > > Thanks, > David > >> Tested locally and via RBT/JPRT. >> >> Thanks >> Michail From jon.masamitsu at oracle.com Tue Jul 19 18:16:58 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 19 Jul 2016 11:16:58 -0700 Subject: [9] RFR (XS): 8161660: Quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java In-Reply-To: <578DDDAE.4010504@oracle.com> References: <578DDDAE.4010504@oracle.com> Message-ID: <8f9a1c66-fece-9648-a7ab-ab5367b4ad22@oracle.com> Looks good. Jon On 7/19/2016 12:58 AM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for quarantining Quarantine > TestParallelHeapSizeFlags.java and TestSmallHeap.java [1]. The tests > recently started failing in the jdk9/dev repository [2]; the problem > currently prohibits us from pushing into the repository using JPRT. > > Once reviewed, I plan to push the fix directly into jdk9/dev. > > Here is the webrev: > > http://cr.openjdk.java.net/~zmajo/8161660/webrev.00/ > > Thank you! > > Best regards, > > > Zoltan > > [1] https://bugs.openjdk.java.net/browse/JDK-8161660 > [2] https://bugs.openjdk.java.net/browse/JDK-8161552 > From david.holmes at oracle.com Wed Jul 20 02:08:32 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jul 2016 12:08:32 +1000 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM In-Reply-To: <578E2CA7.7010400@oracle.com> References: <5787BC26.2000602@oracle.com> <578E2CA7.7010400@oracle.com> Message-ID: <692843f6-bd30-b1e7-91a9-b0046c3f7ca7@oracle.com> On 19/07/2016 11:35 PM, Michail Chernov wrote: > Hi David, > Thanks for your answer. I revised code that checks FlightRecorder > status. At my point of view better way is to use WhiteBox to get VM flag > value. This allows not to use additional dependencies for VMProps. > > Updated webrev: > http://cr.openjdk.java.net/~mchernov/8161208/webrev.01/ That looks better to me. Only nit, our Java style uses "a == null" rather than "null == a". You might also add a comment in VMProps.java: /** * The Class to be invoked by jtreg prior Test Suite execution to * collect information about VM. + * Do not use any API's that may not be available in all target VMs. * Properties set by this Class will be available in the @requires expressions. */ to help avoid this in the future. Thanks, David > Tested locally on Open JDK build, and Oracle JDK (Linux x64 , Linux x86 > - server and minimal VM). > > Thanks, > Michail > > On 15.07.2016 08:31, David Holmes wrote: >> Hi Michail, >> >> On 15/07/2016 2:21 AM, Michail Chernov wrote: >>> Hi, >>> >>> Could I have a reviews for this change, please? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8161208 >>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ >>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ >>> >>> This issue is started since this fix: >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html >>> >> >> I think I would have objected to the form of that fix - VMProps was >> only looking at information available via system properties. >> >>> This change fixes two issues: >>> 1. Avoiding of java.management usage with minimal VM (JTreg was started >>> with '-vmoptions:"-minimal"' and worked as expected). >> >> Okay. >> >>> 2. Adding appropriate modules for proper VMProps execution on non-full >>> JDK images (JTreg was tested with '-vmoptions:"-limitmods java.base"', >>> java.compact1, java.compact2 and so on - JTreg is started and works as >>> expected). >> >> Was that testing done with a full VM or the Minimal VM? On a full VM >> limited to compact1, compact2 or java.base, java.lang.management will >> not be present, but we will execute the query code in VMProps as it >> isn't the minimal VM. >> >> Thanks, >> David >> >>> Tested locally and via RBT/JPRT. >>> >>> Thanks >>> Michail > From weijun.wang at oracle.com Wed Jul 20 03:03:34 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 20 Jul 2016 11:03:34 +0800 Subject: javac crashes VM on Mac (jdk9/dev) Message-ID: <21AF92C7-0F7F-4B65-8CAC-3715110A8EE2@oracle.com> I just synced all my repos and did a exploded build, and it crashes if I want to compile a simple program with javac directly. If the program has an error, javac will happily point it out and exit nicely. # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/library_call.cpp:2803 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/space/repos/jdk9/dev/hotspot/src/share/vm/opto/library_call.cpp:2803), pid=52376, tid=27395 # assert(alias_type->adr_type() == TypeRawPtr::BOTTOM || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->basic_type() != T_ILLEGAL) failed: field, array element or unknown # # JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-07-19-162420.ww155710.dev) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-07-19-162420.ww155710.dev, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64) # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /private/tmp/hs_err_pid52376.log # # Compiler replay data is saved as: # /private/tmp/replay_pid52376.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 27395 Dumping core ... Abort trap: 6 If you want to read more, I put the logs at https://gist.github.com/wangweij/06476f39fcee5b36012786135ebe208d https://gist.github.com/wangweij/cdcdc11df81435cfbfe0bcf024ae91d3 Thanks Max From vladimir.kozlov at oracle.com Wed Jul 20 03:17:11 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Jul 2016 20:17:11 -0700 Subject: javac crashes VM on Mac (jdk9/dev) In-Reply-To: <21AF92C7-0F7F-4B65-8CAC-3715110A8EE2@oracle.com> References: <21AF92C7-0F7F-4B65-8CAC-3715110A8EE2@oracle.com> Message-ID: https://bugs.openjdk.java.net/browse/JDK-8155781 On 7/19/16 8:03 PM, Wang Weijun wrote: > I just synced all my repos and did a exploded build, and it crashes if I want to compile a simple program with javac directly. If the program has an error, javac will happily point it out and exit nicely. > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/library_call.cpp:2803 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/space/repos/jdk9/dev/hotspot/src/share/vm/opto/library_call.cpp:2803), pid=52376, tid=27395 > # assert(alias_type->adr_type() == TypeRawPtr::BOTTOM || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->basic_type() != T_ILLEGAL) failed: field, array element or unknown > # > # JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-07-19-162420.ww155710.dev) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-07-19-162420.ww155710.dev, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64) > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /private/tmp/hs_err_pid52376.log > # > # Compiler replay data is saved as: > # /private/tmp/replay_pid52376.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > Current thread is 27395 > Dumping core ... > Abort trap: 6 > > If you want to read more, I put the logs at > > https://gist.github.com/wangweij/06476f39fcee5b36012786135ebe208d > https://gist.github.com/wangweij/cdcdc11df81435cfbfe0bcf024ae91d3 > > Thanks > Max > From dmitry.fazunenko at oracle.com Wed Jul 20 08:12:43 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 20 Jul 2016 11:12:43 +0300 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM In-Reply-To: <578E2CA7.7010400@oracle.com> References: <5787BC26.2000602@oracle.com> <578E2CA7.7010400@oracle.com> Message-ID: <152e845b-ed85-ba03-0edd-10a275c9c93c@oracle.com> Michail, The new version looks much better, thanks for finding existing WB API to access VM flags. So, the fix looks good, but some rather cosmetic comments: 1) 45 private WhiteBox whiteBox = WhiteBox.getWhiteBox(); --> 45 private *static final* WhiteBox WB = WhiteBox.getWhiteBox(); 2) startFR is not boolean: 137 String isStartFR = --> 137 String startFR = 3) For the sake of code simplicity you can skip check for UnlockedCommercialFatures But it's up to you. 4) another way to turn JFR on: |-XX:FlightRecorderOptions| (https://docs.oracle.com/javacomponents/jmc-5-5/jfr-runtime-guide/comline.htm#JFRRT184) I'm not sure if this option has an effect standalone, but it's better to check for its setting as well. Thanks, Dima On 19.07.2016 16:35, Michail Chernov wrote: > Hi David, > Thanks for your answer. I revised code that checks FlightRecorder > status. At my point of view better way is to use WhiteBox to get VM > flag value. This allows not to use additional dependencies for VMProps. > > Updated webrev: > http://cr.openjdk.java.net/~mchernov/8161208/webrev.01/ > > Tested locally on Open JDK build, and Oracle JDK (Linux x64 , Linux > x86 - server and minimal VM). > > Thanks, > Michail > > On 15.07.2016 08:31, David Holmes wrote: >> Hi Michail, >> >> On 15/07/2016 2:21 AM, Michail Chernov wrote: >>> Hi, >>> >>> Could I have a reviews for this change, please? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8161208 >>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ >>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ >>> >>> This issue is started since this fix: >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html >>> >> >> I think I would have objected to the form of that fix - VMProps was >> only looking at information available via system properties. >> >>> This change fixes two issues: >>> 1. Avoiding of java.management usage with minimal VM (JTreg was started >>> with '-vmoptions:"-minimal"' and worked as expected). >> >> Okay. >> >>> 2. Adding appropriate modules for proper VMProps execution on non-full >>> JDK images (JTreg was tested with '-vmoptions:"-limitmods java.base"', >>> java.compact1, java.compact2 and so on - JTreg is started and works as >>> expected). >> >> Was that testing done with a full VM or the Minimal VM? On a full VM >> limited to compact1, compact2 or java.base, java.lang.management will >> not be present, but we will execute the query code in VMProps as it >> isn't the minimal VM. >> >> Thanks, >> David >> >>> Tested locally and via RBT/JPRT. >>> >>> Thanks >>> Michail > From michail.chernov at oracle.com Wed Jul 20 08:21:12 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 20 Jul 2016 11:21:12 +0300 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM In-Reply-To: <692843f6-bd30-b1e7-91a9-b0046c3f7ca7@oracle.com> References: <5787BC26.2000602@oracle.com> <578E2CA7.7010400@oracle.com> <692843f6-bd30-b1e7-91a9-b0046c3f7ca7@oracle.com> Message-ID: <578F3478.1060703@oracle.com> Hi David, This is updated review with fixed style issues. Added your comment to VMProps.java. http://cr.openjdk.java.net/~mchernov/8161208/webrev.02/ Thanks, Michail On 20.07.2016 05:08, David Holmes wrote: > On 19/07/2016 11:35 PM, Michail Chernov wrote: >> Hi David, >> Thanks for your answer. I revised code that checks FlightRecorder >> status. At my point of view better way is to use WhiteBox to get VM flag >> value. This allows not to use additional dependencies for VMProps. >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchernov/8161208/webrev.01/ > > That looks better to me. Only nit, our Java style uses "a == null" > rather than "null == a". > > You might also add a comment in VMProps.java: > > /** > * The Class to be invoked by jtreg prior Test Suite execution to > * collect information about VM. > + * Do not use any API's that may not be available in all target VMs. > * Properties set by this Class will be available in the @requires > expressions. > */ > > to help avoid this in the future. > > Thanks, > David > >> Tested locally on Open JDK build, and Oracle JDK (Linux x64 , Linux x86 >> - server and minimal VM). >> >> Thanks, >> Michail >> >> On 15.07.2016 08:31, David Holmes wrote: >>> Hi Michail, >>> >>> On 15/07/2016 2:21 AM, Michail Chernov wrote: >>>> Hi, >>>> >>>> Could I have a reviews for this change, please? >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8161208 >>>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ >>>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ >>>> >>>> This issue is started since this fix: >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html >>>> >>>> >>> >>> I think I would have objected to the form of that fix - VMProps was >>> only looking at information available via system properties. >>> >>>> This change fixes two issues: >>>> 1. Avoiding of java.management usage with minimal VM (JTreg was >>>> started >>>> with '-vmoptions:"-minimal"' and worked as expected). >>> >>> Okay. >>> >>>> 2. Adding appropriate modules for proper VMProps execution on non-full >>>> JDK images (JTreg was tested with '-vmoptions:"-limitmods java.base"', >>>> java.compact1, java.compact2 and so on - JTreg is started and works as >>>> expected). >>> >>> Was that testing done with a full VM or the Minimal VM? On a full VM >>> limited to compact1, compact2 or java.base, java.lang.management will >>> not be present, but we will execute the query code in VMProps as it >>> isn't the minimal VM. >>> >>> Thanks, >>> David >>> >>>> Tested locally and via RBT/JPRT. >>>> >>>> Thanks >>>> Michail >> From michail.chernov at oracle.com Wed Jul 20 12:10:57 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 20 Jul 2016 15:10:57 +0300 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM In-Reply-To: <152e845b-ed85-ba03-0edd-10a275c9c93c@oracle.com> References: <5787BC26.2000602@oracle.com> <578E2CA7.7010400@oracle.com> <152e845b-ed85-ba03-0edd-10a275c9c93c@oracle.com> Message-ID: <4b441dd0-1100-93e1-8c82-cec9550c6453@oracle.com> Hi Dima, I took into account your comments. http://cr.openjdk.java.net/~mchernov/8161208/webrev.03/ JFR is enabled only with FlightRecorder or StartFlightRecording options. Please look at closed src (jfrActivator.cpp - JfrActivator::initialize()). I would keep checking of UnlockCommercialFeatures because it makes this checking more clear and this is similar to code from closed part. Thanks, Michail On 07/20/2016 11:12 AM, Dmitry Fazunenko wrote: > Michail, > > The new version looks much better, thanks for finding existing WB API > to access VM flags. > So, the fix looks good, but some rather cosmetic comments: > > 1) 45 private WhiteBox whiteBox = WhiteBox.getWhiteBox(); --> 45 > private *static final* WhiteBox WB = WhiteBox.getWhiteBox(); > > 2) startFR is not boolean: 137 String isStartFR = --> 137 String startFR = > > 3) For the sake of code simplicity you can skip check for > UnlockedCommercialFatures But it's up to you. 4) another way to turn > JFR on: |-XX:FlightRecorderOptions| (https://docs.oracle.com/javacomponents/jmc-5-5/jfr-runtime-guide/comline.htm#JFRRT184) > I'm not sure if this option has an effect standalone, but it's better to check > for its setting as well. > > Thanks, > Dima > > > On 19.07.2016 16:35, Michail Chernov wrote: >> Hi David, >> Thanks for your answer. I revised code that checks FlightRecorder >> status. At my point of view better way is to use WhiteBox to get VM >> flag value. This allows not to use additional dependencies for VMProps. >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchernov/8161208/webrev.01/ >> >> Tested locally on Open JDK build, and Oracle JDK (Linux x64 , Linux >> x86 - server and minimal VM). >> >> Thanks, >> Michail >> >> On 15.07.2016 08:31, David Holmes wrote: >>> Hi Michail, >>> >>> On 15/07/2016 2:21 AM, Michail Chernov wrote: >>>> Hi, >>>> >>>> Could I have a reviews for this change, please? >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8161208 >>>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ >>>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ >>>> >>>> This issue is started since this fix: >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html >>>> >>> >>> I think I would have objected to the form of that fix - VMProps was >>> only looking at information available via system properties. >>> >>>> This change fixes two issues: >>>> 1. Avoiding of java.management usage with minimal VM (JTreg was >>>> started >>>> with '-vmoptions:"-minimal"' and worked as expected). >>> >>> Okay. >>> >>>> 2. Adding appropriate modules for proper VMProps execution on non-full >>>> JDK images (JTreg was tested with '-vmoptions:"-limitmods java.base"', >>>> java.compact1, java.compact2 and so on - JTreg is started and works as >>>> expected). >>> >>> Was that testing done with a full VM or the Minimal VM? On a full VM >>> limited to compact1, compact2 or java.base, java.lang.management >>> will not be present, but we will execute the query code in VMProps >>> as it isn't the minimal VM. >>> >>> Thanks, >>> David >>> >>>> Tested locally and via RBT/JPRT. >>>> >>>> Thanks >>>> Michail >> > From zoltan.majo at oracle.com Wed Jul 20 12:16:22 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 20 Jul 2016 14:16:22 +0200 Subject: [9] RFR (XS): 8161660: Quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java In-Reply-To: <8f9a1c66-fece-9648-a7ab-ab5367b4ad22@oracle.com> References: <578DDDAE.4010504@oracle.com> <8f9a1c66-fece-9648-a7ab-ab5367b4ad22@oracle.com> Message-ID: Hi Jon, thank you for the review! Unfortunately, I've already pushed the fix by the time your review has arrived, so I was not able to mention you as a reviewer. Sorry for that. Thank you and best regards, Zoltan On 07/19/2016 08:16 PM, Jon Masamitsu wrote: > Looks good. > > Jon > > On 7/19/2016 12:58 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for quarantining Quarantine >> TestParallelHeapSizeFlags.java and TestSmallHeap.java [1]. The tests >> recently started failing in the jdk9/dev repository [2]; the problem >> currently prohibits us from pushing into the repository using JPRT. >> >> Once reviewed, I plan to push the fix directly into jdk9/dev. >> >> Here is the webrev: >> >> http://cr.openjdk.java.net/~zmajo/8161660/webrev.00/ >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8161660 >> [2] https://bugs.openjdk.java.net/browse/JDK-8161552 >> > From dmitry.fazunenko at oracle.com Wed Jul 20 13:23:06 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 20 Jul 2016 16:23:06 +0300 Subject: RFR: 8161208: Unable to run jtreg tests with MinimalVM In-Reply-To: <4b441dd0-1100-93e1-8c82-cec9550c6453@oracle.com> References: <5787BC26.2000602@oracle.com> <578E2CA7.7010400@oracle.com> <152e845b-ed85-ba03-0edd-10a275c9c93c@oracle.com> <4b441dd0-1100-93e1-8c82-cec9550c6453@oracle.com> Message-ID: <6e032679-7e93-33a3-34b0-18ce9317403f@oracle.com> Michail, the change looks good to me. Thank you for taking my notes. -- Dima On 20.07.2016 15:10, Michail Chernov wrote: > > Hi Dima, > > I took into account your comments. > > http://cr.openjdk.java.net/~mchernov/8161208/webrev.03/ > > JFR is enabled only with FlightRecorder or StartFlightRecording > options. Please look at closed src (jfrActivator.cpp - > JfrActivator::initialize()). > > I would keep checking of UnlockCommercialFeatures because it makes > this checking more clear and this is similar to code from closed part. > > > Thanks, > Michail > > On 07/20/2016 11:12 AM, Dmitry Fazunenko wrote: >> Michail, >> >> The new version looks much better, thanks for finding existing WB API >> to access VM flags. >> So, the fix looks good, but some rather cosmetic comments: >> >> 1) 45 private WhiteBox whiteBox = WhiteBox.getWhiteBox(); --> 45 >> private *static final* WhiteBox WB = WhiteBox.getWhiteBox(); >> >> 2) startFR is not boolean: 137 String isStartFR = --> 137 String >> startFR = >> >> 3) For the sake of code simplicity you can skip check for >> UnlockedCommercialFatures But it's up to you. 4) another way to turn >> JFR on: |-XX:FlightRecorderOptions| (https://docs.oracle.com/javacomponents/jmc-5-5/jfr-runtime-guide/comline.htm#JFRRT184) >> I'm not sure if this option has an effect standalone, but it's better to check >> for its setting as well. >> >> Thanks, >> Dima >> >> >> On 19.07.2016 16:35, Michail Chernov wrote: >>> Hi David, >>> Thanks for your answer. I revised code that checks FlightRecorder >>> status. At my point of view better way is to use WhiteBox to get VM >>> flag value. This allows not to use additional dependencies for VMProps. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.01/ >>> >>> Tested locally on Open JDK build, and Oracle JDK (Linux x64 , Linux >>> x86 - server and minimal VM). >>> >>> Thanks, >>> Michail >>> >>> On 15.07.2016 08:31, David Holmes wrote: >>>> Hi Michail, >>>> >>>> On 15/07/2016 2:21 AM, Michail Chernov wrote: >>>>> Hi, >>>>> >>>>> Could I have a reviews for this change, please? >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8161208 >>>>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.00/ >>>>> http://cr.openjdk.java.net/~mchernov/8161208/webrev.hotspot.00/ >>>>> >>>>> This issue is started since this fix: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018319.html >>>>> >>>> >>>> I think I would have objected to the form of that fix - VMProps was >>>> only looking at information available via system properties. >>>> >>>>> This change fixes two issues: >>>>> 1. Avoiding of java.management usage with minimal VM (JTreg was >>>>> started >>>>> with '-vmoptions:"-minimal"' and worked as expected). >>>> >>>> Okay. >>>> >>>>> 2. Adding appropriate modules for proper VMProps execution on >>>>> non-full >>>>> JDK images (JTreg was tested with '-vmoptions:"-limitmods >>>>> java.base"', >>>>> java.compact1, java.compact2 and so on - JTreg is started and >>>>> works as >>>>> expected). >>>> >>>> Was that testing done with a full VM or the Minimal VM? On a full >>>> VM limited to compact1, compact2 or java.base, java.lang.management >>>> will not be present, but we will execute the query code in VMProps >>>> as it isn't the minimal VM. >>>> >>>> Thanks, >>>> David >>>> >>>>> Tested locally and via RBT/JPRT. >>>>> >>>>> Thanks >>>>> Michail >>> >> > From mikael.gerdin at oracle.com Wed Jul 20 13:54:44 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Jul 2016 15:54:44 +0200 Subject: RFR(XS) 8161915: Linking gtestLauncher may end up linking with non-gtest libjvm Message-ID: Hi all, Please review this small fix to work around a problem where incremental builds of hotspot would fail due to the symbol runUnitTests missing. The cause for the problem is that the unit tests launcher linker command line contains a -L path containing the standard libjvm.so [10] LDFLAGS := -Wl,-z,defs -Wl,-z,now -Wl,-z,relro -Wl,--allow-shlib-undefined -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64 -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64/server [11] LDFLAGS_unix := -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/hotspot/variant-server/libjvm/gtest -Wl,-z,origin -Wl,-rpath,\$$ORIGIN [13] LIBS_unix := -ljvm This is caused by BUILD_GTEST_LAUNCHER picking up LDFLAGS_TESTEXE which was recently modified to include -L path to the standard libjvm.so My suggested fix is to instead use LDFLAGS_JDKEXE for the gtest launcher since the only difference between them is that TESTEXE appends JAVA_BASE_LDFLAGS: flags.m4, 687: LDFLAGS_TESTEXE="$LDFLAGS_JDKEXE $JAVA_BASE_LDFLAGS" Since the fix is only one line, I'll paste it inline here: diff --git a/make/lib/CompileGtest.gmk b/make/lib/CompileGtest.gmk --- a/make/lib/CompileGtest.gmk +++ b/make/lib/CompileGtest.gmk @@ -104,7 +104,7 @@ -I$(GTEST_FRAMEWORK_SRC)/include, \ CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ - LDFLAGS := $(LDFLAGS_TESTEXE), \ + LDFLAGS := $(LDFLAGS_JDKEXE), \ LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_solaris := -library=stlport4, \ LIBS_unix := -ljvm, \ Testing: JPRT -testset hotspot Bug link: https://bugs.openjdk.java.net/browse/JDK-8161915 Please let me know if there is any further testing I should do before pushing this. Thanks /Mikael From brent.christian at oracle.com Wed Jul 20 18:19:09 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 20 Jul 2016 11:19:09 -0700 Subject: RFR 8161028 : GPL header missing comma after year Message-ID: Hi, Looks like I didn't do the copyright on the stackwalk native files quite right - needs a comma after the 2nd year. (You gotta have more commas!) Proposed diff below. (Note that I am not subscribed to this alias) --- a/src/share/vm/prims/stackwalk.cpp Wed Jul 20 14:47:53 2016 +0300 +++ b/src/share/vm/prims/stackwalk.cpp Wed Jul 20 10:49:53 2016 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, 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 diff -r 9f5a448947a4 src/share/vm/prims/stackwalk.hpp --- a/src/share/vm/prims/stackwalk.hpp Wed Jul 20 14:47:53 2016 +0300 +++ b/src/share/vm/prims/stackwalk.hpp Wed Jul 20 10:49:53 2016 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, 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 Thanks, -Brent From david.holmes at oracle.com Thu Jul 21 05:42:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jul 2016 15:42:17 +1000 Subject: RFR(XS) 8161915: Linking gtestLauncher may end up linking with non-gtest libjvm In-Reply-To: References: Message-ID: <8c400eda-1fd7-98bc-ee8c-a3ca620b6ddc@oracle.com> Hi Mikael, On 20/07/2016 11:54 PM, Mikael Gerdin wrote: > Hi all, > > Please review this small fix to work around a problem where incremental > builds of hotspot would fail due to the symbol runUnitTests missing. > > The cause for the problem is that the unit tests launcher linker command > line contains a -L path containing the standard libjvm.so > [10] LDFLAGS := -Wl,-z,defs -Wl,-z,now -Wl,-z,relro > -Wl,--allow-shlib-undefined > -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64 > -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64/server > > [11] LDFLAGS_unix := > -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/hotspot/variant-server/libjvm/gtest > -Wl,-z,origin -Wl,-rpath,\$$ORIGIN > [13] LIBS_unix := -ljvm > > This is caused by BUILD_GTEST_LAUNCHER picking up LDFLAGS_TESTEXE which > was recently modified to include -L path to the standard libjvm.so > > My suggested fix is to instead use LDFLAGS_JDKEXE for the gtest launcher > since the only difference between them is that TESTEXE appends > JAVA_BASE_LDFLAGS: > flags.m4, 687: LDFLAGS_TESTEXE="$LDFLAGS_JDKEXE $JAVA_BASE_LDFLAGS" > > Since the fix is only one line, I'll paste it inline here: > diff --git a/make/lib/CompileGtest.gmk b/make/lib/CompileGtest.gmk > --- a/make/lib/CompileGtest.gmk > +++ b/make/lib/CompileGtest.gmk > @@ -104,7 +104,7 @@ > -I$(GTEST_FRAMEWORK_SRC)/include, \ > CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > - LDFLAGS := $(LDFLAGS_TESTEXE), \ > + LDFLAGS := $(LDFLAGS_JDKEXE), \ > LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call > SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_solaris := -library=stlport4, \ > LIBS_unix := -ljvm, \ This seems like a reasonable solution at least in the short-term. It may be that gtest launcher needs it own compiler/linker options independent of other "executables" in the build. Thanks, David > > Testing: JPRT -testset hotspot > Bug link: https://bugs.openjdk.java.net/browse/JDK-8161915 > > Please let me know if there is any further testing I should do before > pushing this. > > Thanks > /Mikael From erik.helin at oracle.com Thu Jul 21 10:01:43 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 21 Jul 2016 12:01:43 +0200 Subject: RFR(XS) 8161915: Linking gtestLauncher may end up linking with non-gtest libjvm In-Reply-To: References: Message-ID: <20160721100143.GA31575@ehelin.jrpg.bea.com> On 2016-07-20, Mikael Gerdin wrote: > Hi all, > > Please review this small fix to work around a problem where incremental > builds of hotspot would fail due to the symbol runUnitTests missing. > > The cause for the problem is that the unit tests launcher linker command > line contains a -L path containing the standard libjvm.so > [10] LDFLAGS := -Wl,-z,defs -Wl,-z,now -Wl,-z,relro > -Wl,--allow-shlib-undefined -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64 -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64/server > > [11] LDFLAGS_unix := -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/hotspot/variant-server/libjvm/gtest > -Wl,-z,origin -Wl,-rpath,\$$ORIGIN > [13] LIBS_unix := -ljvm > > This is caused by BUILD_GTEST_LAUNCHER picking up LDFLAGS_TESTEXE which was > recently modified to include -L path to the standard libjvm.so > > My suggested fix is to instead use LDFLAGS_JDKEXE for the gtest launcher > since the only difference between them is that TESTEXE appends > JAVA_BASE_LDFLAGS: > flags.m4, 687: LDFLAGS_TESTEXE="$LDFLAGS_JDKEXE $JAVA_BASE_LDFLAGS" > > Since the fix is only one line, I'll paste it inline here: > diff --git a/make/lib/CompileGtest.gmk b/make/lib/CompileGtest.gmk > --- a/make/lib/CompileGtest.gmk > +++ b/make/lib/CompileGtest.gmk > @@ -104,7 +104,7 @@ > -I$(GTEST_FRAMEWORK_SRC)/include, \ > CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > - LDFLAGS := $(LDFLAGS_TESTEXE), \ > + LDFLAGS := $(LDFLAGS_JDKEXE), \ > LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call > SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_solaris := -library=stlport4, \ > LIBS_unix := -ljvm, \ Looks good, Reviewed. Thanks, Erik > Testing: JPRT -testset hotspot > Bug link: https://bugs.openjdk.java.net/browse/JDK-8161915 > > Please let me know if there is any further testing I should do before > pushing this. > > Thanks > /Mikael From paul.sandoz at oracle.com Thu Jul 21 11:40:02 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 21 Jul 2016 13:40:02 +0200 Subject: RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev Message-ID: <18FEA9FE-FE28-4B01-B5C3-C05810B32A61@oracle.com> Hi, The fix for: https://bugs.openjdk.java.net/browse/JDK-8161129 8161129 Unsafe::getUnsafe should allow the platform class loader to access it broke a test in the Hotspot repo test area that i did not realize existed. That test can be deleted. There is an existing test in the JDK repo test area that tests the same functionality in sun.misc.Unsafe, which is arguably the right location, i have renamed that test. Paul. Hotspot test changes ? diff -r 9f5a448947a4 test/runtime/Unsafe/GetUnsafe.java --- a/test/runtime/Unsafe/GetUnsafe.java Wed Jul 20 14:47:53 2016 +0300 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,45 +0,0 @@ -/* - * Copyright (c) 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 - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - */ - -/* - * @test - * @summary Verifies that getUnsafe() actually throws SecurityException when unsafeAccess is prohibited. - * @library /testlibrary - * @modules java.base/jdk.internal.misc - * @run main GetUnsafe - */ - -import jdk.internal.misc.Unsafe; -import static jdk.test.lib.Asserts.*; - -public class GetUnsafe { - public static void main(String args[]) throws Exception { - try { - Unsafe unsafe = Unsafe.getUnsafe(); - } catch (SecurityException e) { - // Expected - return; - } - throw new RuntimeException("Did not get expected SecurityException"); - } -} JDK test changes ? diff --git a/test/sun/misc/Safe.java b/test/sun/misc/GetSunMiscUnsafe.java rename from test/sun/misc/Safe.java rename to test/sun/misc/GetSunMiscUnsafe.java --- a/test/sun/misc/Safe.java +++ b/test/sun/misc/GetSunMiscUnsafe.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2016 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 @@ -29,7 +29,7 @@ */ -public class Safe { +public class GetSunMiscUnsafe { public static void main(String[] args) throws Exception { try { From Alan.Bateman at oracle.com Thu Jul 21 12:04:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Jul 2016 13:04:35 +0100 Subject: RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev In-Reply-To: <18FEA9FE-FE28-4B01-B5C3-C05810B32A61@oracle.com> References: <18FEA9FE-FE28-4B01-B5C3-C05810B32A61@oracle.com> Message-ID: <33d44485-4b3c-976e-ac82-b0e1562df564@oracle.com> On 21/07/2016 12:40, Paul Sandoz wrote: > Hi, > > The fix for: > > https://bugs.openjdk.java.net/browse/JDK-8161129 > 8161129 Unsafe::getUnsafe should allow the platform class loader to access it > > broke a test in the Hotspot repo test area that i did not realize existed. That test can be deleted. There is an existing test in the JDK repo test area that tests the same functionality in sun.misc.Unsafe, which is arguably the right location, i have renamed that test. Make sense. For the test in the jdk repo then maybe it should be changed to catch SecurityException rather than Exception. -Alan From david.holmes at oracle.com Thu Jul 21 12:37:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jul 2016 22:37:21 +1000 Subject: RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev In-Reply-To: <18FEA9FE-FE28-4B01-B5C3-C05810B32A61@oracle.com> References: <18FEA9FE-FE28-4B01-B5C3-C05810B32A61@oracle.com> Message-ID: Hi Paul, On 21/07/2016 9:40 PM, Paul Sandoz wrote: > Hi, > > The fix for: > > https://bugs.openjdk.java.net/browse/JDK-8161129 > 8161129 Unsafe::getUnsafe should allow the platform class loader to access it > > broke a test in the Hotspot repo test area that i did not realize existed. That test can be deleted. There is an existing test in the JDK repo test area that tests the same functionality in sun.misc.Unsafe, which is arguably the right location, i have renamed that test. > > Paul. > > Hotspot test changes > ? > > diff -r 9f5a448947a4 test/runtime/Unsafe/GetUnsafe.java > --- a/test/runtime/Unsafe/GetUnsafe.java Wed Jul 20 14:47:53 2016 +0300 > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > @@ -1,45 +0,0 @@ > -/* > - * Copyright (c) 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 > - * under the terms of the GNU General Public License version 2 only, as > - * published by the Free Software Foundation. > - * > - * This code is distributed in the hope that it will be useful, but WITHOUT > - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > - * version 2 for more details (a copy is included in the LICENSE file that > - * accompanied this code). > - * > - * You should have received a copy of the GNU General Public License version > - * 2 along with this work; if not, write to the Free Software Foundation, > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > - * > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > - * or visit www.oracle.com if you need additional information or have any > - * questions. > - */ > - > -/* > - * @test > - * @summary Verifies that getUnsafe() actually throws SecurityException when unsafeAccess is prohibited. > - * @library /testlibrary > - * @modules java.base/jdk.internal.misc > - * @run main GetUnsafe > - */ > - > -import jdk.internal.misc.Unsafe; > -import static jdk.test.lib.Asserts.*; > - > -public class GetUnsafe { > - public static void main(String args[]) throws Exception { > - try { > - Unsafe unsafe = Unsafe.getUnsafe(); > - } catch (SecurityException e) { > - // Expected > - return; > - } > - throw new RuntimeException("Did not get expected SecurityException"); > - } > -} Removal looks fine. > > JDK test changes > ? > > diff --git a/test/sun/misc/Safe.java b/test/sun/misc/GetSunMiscUnsafe.java > rename from test/sun/misc/Safe.java > rename to test/sun/misc/GetSunMiscUnsafe.java > --- a/test/sun/misc/Safe.java > +++ b/test/sun/misc/GetSunMiscUnsafe.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2016 Oracle and/or its affiliates. All rights reserved. Comma needed after 2016 I'll leave the body of the test to core-libs folk. Thanks, David ----- > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -29,7 +29,7 @@ > */ > > > -public class Safe { > +public class GetSunMiscUnsafe { > > public static void main(String[] args) throws Exception { > try { > > From paul.sandoz at oracle.com Thu Jul 21 13:30:14 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 21 Jul 2016 15:30:14 +0200 Subject: RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev In-Reply-To: <33d44485-4b3c-976e-ac82-b0e1562df564@oracle.com> References: <18FEA9FE-FE28-4B01-B5C3-C05810B32A61@oracle.com> <33d44485-4b3c-976e-ac82-b0e1562df564@oracle.com> Message-ID: <06B219E4-058C-46EF-9009-AB03CFC66605@oracle.com> > On 21 Jul 2016, at 14:04, Alan Bateman wrote: > > On 21/07/2016 12:40, Paul Sandoz wrote: > >> Hi, >> >> The fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8161129 >> 8161129 Unsafe::getUnsafe should allow the platform class loader to access it >> >> broke a test in the Hotspot repo test area that i did not realize existed. That test can be deleted. There is an existing test in the JDK repo test area that tests the same functionality in sun.misc.Unsafe, which is arguably the right location, i have renamed that test. > Make sense. For the test in the jdk repo then maybe it should be changed to catch SecurityException rather than Exception. > Updated, thanks, Paul. From paul.sandoz at oracle.com Thu Jul 21 13:30:42 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 21 Jul 2016 15:30:42 +0200 Subject: RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev In-Reply-To: References: <18FEA9FE-FE28-4B01-B5C3-C05810B32A61@oracle.com> Message-ID: <9351D1EC-CE67-4DFA-AB91-CCAD40D88B83@oracle.com> > On 21 Jul 2016, at 14:37, David Holmes wrote: > >> >> JDK test changes >> ? >> >> diff --git a/test/sun/misc/Safe.java b/test/sun/misc/GetSunMiscUnsafe.java >> rename from test/sun/misc/Safe.java >> rename to test/sun/misc/GetSunMiscUnsafe.java >> --- a/test/sun/misc/Safe.java >> +++ b/test/sun/misc/GetSunMiscUnsafe.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2001, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2001, 2016 Oracle and/or its affiliates. All rights reserved. > > Comma needed after 2016 > Updated, thanks, Paul. From aph at redhat.com Thu Jul 21 17:19:29 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Jul 2016 18:19:29 +0100 Subject: RFR: 8162338: AArch64: Intrinsify fused mac operations Message-ID: <57910421.7090300@redhat.com> This is the AArch64 port of 8154122. http://cr.openjdk.java.net/~aph/8162338/ Andrew. From gromero at linux.vnet.ibm.com Thu Jul 21 18:30:04 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 21 Jul 2016 15:30:04 -0300 Subject: PPC64 JVM crashes when RTM is enabled Message-ID: <579114AC.6090700@linux.vnet.ibm.com> Hi As of now (jdk9/hs-comp, f3c27d6d4ad1 tip), JVM crashes due to the delivery of a signal in the middle of an HTM transaction on PPC64 (on x64 this feature is called RTM but on POWER it's called HTM, standing for Hardware Transactional Memory). When a SIGTRAP or a SIGILL is generated by the execution of a `trap` instruction or an illegal instruction at the beginning of a not entrant or zombie method and it happens in the middle of an HTM transaction, it fails the HTM transaction. As a consequence two different ucontext_t structs are set by the Linux kernel. One context is related to the HTM block that failed while the other context is related to where the offending instruction was executed, i.e. the method con- taining the `trap` or illegal instruction. Currently the JVM signal handler for Linux/PPC64 just inspects the context related to the failed HTM block and when it verifies the value of nip, i.e. the Next Instruction Pointer set at uc->uc_mcontext.regs->nip, by calling os::Linux::ucontext_get_pc(uc), the signal handler does not find the offending instruction but instead the instruction located at tbegin+4, that consists in a branch to the HTM failure handler, as explained here [1]. A simple test case is: java -XX:+UnlockExperimentalVMOptions -XX:+UseRTMForStackLocks -XX:+UseRTMLocking The issue first appeared in the compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java jtreg test: http://hastebin.com/raw/ufodiduqeh Please, refer to the following hs_err log: http://hastebin.com/raw/zucifaxoce In this log, si_addr=0x00003fff60460c10 (where the trap instruction is) but pc=0x00003fff60455ec4 (which points to tbegin+4, i.e. a beq instruction to the HTM failure handler, and not to a trap instruction). 0x00003fff60455ec0: .long 0x7c00051d (tbegin.) 0x00003fff60455ec4: beq- 0x00003fff60455ee0 <======= pc = HTM failure handler 0x00003fff60455ec8: ld r14,0(r3) and not trap (or illegal) instr. 0x00003fff60455ecc: clrldi r0,r14,61 0x00003fff60455ed0: cmpwi cr5,r0,1 0x00003fff60455ed4: beq- cr5,0x00003fff60455ff4 0x00003fff60455ed8: .long 0x7c00055d (tend.) Once in the signal handler, the pc is normally equal to si_addr, thus pc must point to the trap instruction located in the marked not entrant (or zombie) method. But when the JVM handler inspects pc it can't find a trap instruction (or otherwise an illegal instruction if -XX:-UseSIGTRAP flag is used). So it's an invalid condition for the JVM signal handler and the handler hits the report_and_die. Here are two examples of it, one using a trap instruction to mark a not entrant method and another using a illegal instruction for the same purpose: http://hastebin.com/raw/avahoyadik It's important to mention that the crash is indeed intermittent, so a few times a run will just not crash the JVM (it seems that the issue gets worse if the number of threads increase). The solution I found consists in restoring the right context that points to the not entrant method, which is stored by the kernel in a second ucontext_t struct in case a signal is caught in the middle of an HTM transaction, as explained in here [2]. The following patch is proposed to solve the issue, i.e. now compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java always passes: diff -r adc8c84b7cf8 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Fri Jul 01 11:29:55 2016 +0200 +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Wed Jul 20 21:52:08 2016 -0400 @@ -219,6 +219,28 @@ int abort_if_unrecognized) { ucontext_t* uc = (ucontext_t*) ucVoid; + // A second thread context exists if the signal is delivered during a + // transaction. Please see kernel doc transactional_memory.txt, L99-101: + // https://goo.gl/E1xbxZ + ucontext_t* transaction_uc = uc->uc_link; + + // If uc->uc_link != NULL, then the signal happened during a transaction, as + // pointed out in L106-107 (ibidem). MSR.TS bit must be checked for future + // compatibility, but for now just checking uc->uc_link is ok. + // + // The JVM signal handler expects the context where a `trap` or + // an illegal instruction occurs (i.e. at the beginning of a method marked as + // not entrant or zombie), but if the first context `uc` is used it contains + // the context of the HTM block, thus uc->uc_mcontext.regs->nip points to + // tbegin+4, as explained in L103-104 (ibidem). Hence it's necessary to + // restore the context where the `trap` or the illegal instruction are, which + // is the second context in uc->uc_link. + if (transaction_uc) { + uc = transaction_uc; + uc->uc_link = NULL; + ucVoid = (void*) uc; + } + Thread* t = Thread::current_or_null_safe(); SignalHandlerMark shm(t); Is it possible to open a bug for this issue? Thank you and best regards, Gustavo [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/transactional_memory.txt#L96-L105 [2] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/transactional_memory.txt#L106-L107 From goetz.lindenmaier at sap.com Fri Jul 22 06:44:13 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Jul 2016 06:44:13 +0000 Subject: PPC64 JVM crashes when RTM is enabled In-Reply-To: <579114AC.6090700@linux.vnet.ibm.com> References: <579114AC.6090700@linux.vnet.ibm.com> Message-ID: <777bc8ce70174a62baab35ea72dc2838@DEWDFE13DE09.global.corp.sap> Hi Gustavo, very neat analysis! I opened https://bugs.openjdk.java.net/browse/JDK-8162369 Does AIX require a similar fix? Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Romero > Sent: Donnerstag, 21. Juli 2016 20:30 > To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Cc: Breno Leitao > Subject: PPC64 JVM crashes when RTM is enabled > Importance: High > > Hi > > As of now (jdk9/hs-comp, f3c27d6d4ad1 tip), JVM crashes due to the > delivery of > a signal in the middle of an HTM transaction on PPC64 (on x64 this feature is > called RTM but on POWER it's called HTM, standing for Hardware > Transactional > Memory). > > When a SIGTRAP or a SIGILL is generated by the execution of a `trap` > instruction > or an illegal instruction at the beginning of a not entrant or zombie method > and > it happens in the middle of an HTM transaction, it fails the HTM transaction. > > As a consequence two different ucontext_t structs are set by the Linux > kernel. > One context is related to the HTM block that failed while the other context is > related to where the offending instruction was executed, i.e. the method > con- > taining the `trap` or illegal instruction. Currently the JVM signal handler for > Linux/PPC64 just inspects the context related to the failed HTM block and > when > it verifies the value of nip, i.e. the Next Instruction Pointer set at > uc->uc_mcontext.regs->nip, by calling os::Linux::ucontext_get_pc(uc), the > signal > handler does not find the offending instruction but instead the instruction > located at tbegin+4, that consists in a branch to the HTM failure handler, as > explained here [1]. > > A simple test case is: > java -XX:+UnlockExperimentalVMOptions -XX:+UseRTMForStackLocks - > XX:+UseRTMLocking > > The issue first appeared in the > compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > jtreg test: > http://hastebin.com/raw/ufodiduqeh > > Please, refer to the following hs_err log: > http://hastebin.com/raw/zucifaxoce > > In this log, si_addr=0x00003fff60460c10 (where the trap instruction is) but > pc=0x00003fff60455ec4 (which points to tbegin+4, i.e. a beq instruction to > the > HTM failure handler, and not to a trap instruction). > > 0x00003fff60455ec0: .long 0x7c00051d (tbegin.) > 0x00003fff60455ec4: beq- 0x00003fff60455ee0 <======= pc = HTM failure > handler > 0x00003fff60455ec8: ld r14,0(r3) and not trap (or illegal) instr. > 0x00003fff60455ecc: clrldi r0,r14,61 > 0x00003fff60455ed0: cmpwi cr5,r0,1 > 0x00003fff60455ed4: beq- cr5,0x00003fff60455ff4 > 0x00003fff60455ed8: .long 0x7c00055d (tend.) > > Once in the signal handler, the pc is normally equal to si_addr, thus pc must > point to the trap instruction located in the marked not entrant (or zombie) > method. But when the JVM handler inspects pc it can't find a trap instruction > (or otherwise an illegal instruction if -XX:-UseSIGTRAP flag is used). So it's > an invalid condition for the JVM signal handler and the handler hits the > report_and_die. > > Here are two examples of it, one using a trap instruction to mark a not > entrant > method and another using a illegal instruction for the same purpose: > http://hastebin.com/raw/avahoyadik It's important to mention that the > crash is > indeed intermittent, so a few times a run will just not crash the JVM (it > seems > that the issue gets worse if the number of threads increase). > > The solution I found consists in restoring the right context that points to the > not entrant method, which is stored by the kernel in a second ucontext_t > struct > in case a signal is caught in the middle of an HTM transaction, as explained in > here [2]. > > The following patch is proposed to solve the issue, i.e. now > compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > always > passes: > > > diff -r adc8c84b7cf8 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Fri Jul 01 11:29:55 2016 > +0200 > +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Wed Jul 20 21:52:08 > 2016 -0400 > @@ -219,6 +219,28 @@ > int abort_if_unrecognized) { > ucontext_t* uc = (ucontext_t*) ucVoid; > > + // A second thread context exists if the signal is delivered during a > + // transaction. Please see kernel doc transactional_memory.txt, L99-101: > + // https://goo.gl/E1xbxZ > + ucontext_t* transaction_uc = uc->uc_link; > + > + // If uc->uc_link != NULL, then the signal happened during a transaction, as > + // pointed out in L106-107 (ibidem). MSR.TS bit must be checked for future > + // compatibility, but for now just checking uc->uc_link is ok. > + // > + // The JVM signal handler expects the context where a `trap` or > + // an illegal instruction occurs (i.e. at the beginning of a method marked as > + // not entrant or zombie), but if the first context `uc` is used it contains > + // the context of the HTM block, thus uc->uc_mcontext.regs->nip points > to > + // tbegin+4, as explained in L103-104 (ibidem). Hence it's necessary to > + // restore the context where the `trap` or the illegal instruction are, which > + // is the second context in uc->uc_link. > + if (transaction_uc) { > + uc = transaction_uc; > + uc->uc_link = NULL; > + ucVoid = (void*) uc; > + } > + > Thread* t = Thread::current_or_null_safe(); > > SignalHandlerMark shm(t); > > Is it possible to open a bug for this issue? > > Thank you and best regards, > Gustavo > > [1] > https://github.com/torvalds/linux/blob/master/Documentation/powerpc/tr > ansactional_memory.txt#L96-L105 > [2] > https://github.com/torvalds/linux/blob/master/Documentation/powerpc/tr > ansactional_memory.txt#L106-L107 From thomas.stuefe at gmail.com Fri Jul 22 08:30:50 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 22 Jul 2016 10:30:50 +0200 Subject: PPC64 JVM crashes when RTM is enabled In-Reply-To: <777bc8ce70174a62baab35ea72dc2838@DEWDFE13DE09.global.corp.sap> References: <579114AC.6090700@linux.vnet.ibm.com> <777bc8ce70174a62baab35ea72dc2838@DEWDFE13DE09.global.corp.sap> Message-ID: I agree, this is a very good analysis! Short question though, does this mean the original context is of no value at all? So, for the purpose of error reporting, which register set should we print, the original one or the one from uc_link? Kind Regards, Thomas On Fri, Jul 22, 2016 at 8:44 AM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Gustavo, > > very neat analysis! I opened > https://bugs.openjdk.java.net/browse/JDK-8162369 > > Does AIX require a similar fix? > > Best regards, > Goetz. > > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Romero > > Sent: Donnerstag, 21. Juli 2016 20:30 > > To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > > Cc: Breno Leitao > > Subject: PPC64 JVM crashes when RTM is enabled > > Importance: High > > > > Hi > > > > As of now (jdk9/hs-comp, f3c27d6d4ad1 tip), JVM crashes due to the > > delivery of > > a signal in the middle of an HTM transaction on PPC64 (on x64 this > feature is > > called RTM but on POWER it's called HTM, standing for Hardware > > Transactional > > Memory). > > > > When a SIGTRAP or a SIGILL is generated by the execution of a `trap` > > instruction > > or an illegal instruction at the beginning of a not entrant or zombie > method > > and > > it happens in the middle of an HTM transaction, it fails the HTM > transaction. > > > > As a consequence two different ucontext_t structs are set by the Linux > > kernel. > > One context is related to the HTM block that failed while the other > context is > > related to where the offending instruction was executed, i.e. the method > > con- > > taining the `trap` or illegal instruction. Currently the JVM signal > handler for > > Linux/PPC64 just inspects the context related to the failed HTM block and > > when > > it verifies the value of nip, i.e. the Next Instruction Pointer set at > > uc->uc_mcontext.regs->nip, by calling os::Linux::ucontext_get_pc(uc), the > > signal > > handler does not find the offending instruction but instead the > instruction > > located at tbegin+4, that consists in a branch to the HTM failure > handler, as > > explained here [1]. > > > > A simple test case is: > > java -XX:+UnlockExperimentalVMOptions -XX:+UseRTMForStackLocks - > > XX:+UseRTMLocking > > > > The issue first appeared in the > > compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > > jtreg test: > > http://hastebin.com/raw/ufodiduqeh > > > > Please, refer to the following hs_err log: > > http://hastebin.com/raw/zucifaxoce > > > > In this log, si_addr=0x00003fff60460c10 (where the trap instruction is) > but > > pc=0x00003fff60455ec4 (which points to tbegin+4, i.e. a beq instruction > to > > the > > HTM failure handler, and not to a trap instruction). > > > > 0x00003fff60455ec0: .long 0x7c00051d (tbegin.) > > 0x00003fff60455ec4: beq- 0x00003fff60455ee0 <======= pc = HTM failure > > handler > > 0x00003fff60455ec8: ld r14,0(r3) and not trap (or > illegal) instr. > > 0x00003fff60455ecc: clrldi r0,r14,61 > > 0x00003fff60455ed0: cmpwi cr5,r0,1 > > 0x00003fff60455ed4: beq- cr5,0x00003fff60455ff4 > > 0x00003fff60455ed8: .long 0x7c00055d (tend.) > > > > Once in the signal handler, the pc is normally equal to si_addr, thus pc > must > > point to the trap instruction located in the marked not entrant (or > zombie) > > method. But when the JVM handler inspects pc it can't find a trap > instruction > > (or otherwise an illegal instruction if -XX:-UseSIGTRAP flag is used). > So it's > > an invalid condition for the JVM signal handler and the handler hits the > > report_and_die. > > > > Here are two examples of it, one using a trap instruction to mark a not > > entrant > > method and another using a illegal instruction for the same purpose: > > http://hastebin.com/raw/avahoyadik It's important to mention that the > > crash is > > indeed intermittent, so a few times a run will just not crash the JVM (it > > seems > > that the issue gets worse if the number of threads increase). > > > > The solution I found consists in restoring the right context that points > to the > > not entrant method, which is stored by the kernel in a second ucontext_t > > struct > > in case a signal is caught in the middle of an HTM transaction, as > explained in > > here [2]. > > > > The following patch is proposed to solve the issue, i.e. now > > compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > > always > > passes: > > > > > > diff -r adc8c84b7cf8 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > > --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Fri Jul 01 > 11:29:55 2016 > > +0200 > > +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Wed Jul 20 21:52:08 > > 2016 -0400 > > @@ -219,6 +219,28 @@ > > int abort_if_unrecognized) { > > ucontext_t* uc = (ucontext_t*) ucVoid; > > > > + // A second thread context exists if the signal is delivered during a > > + // transaction. Please see kernel doc transactional_memory.txt, > L99-101: > > + // https://goo.gl/E1xbxZ > > + ucontext_t* transaction_uc = uc->uc_link; > > + > > + // If uc->uc_link != NULL, then the signal happened during a > transaction, as > > + // pointed out in L106-107 (ibidem). MSR.TS bit must be checked for > future > > + // compatibility, but for now just checking uc->uc_link is ok. > > + // > > + // The JVM signal handler expects the context where a `trap` or > > + // an illegal instruction occurs (i.e. at the beginning of a method > marked as > > + // not entrant or zombie), but if the first context `uc` is used it > contains > > + // the context of the HTM block, thus uc->uc_mcontext.regs->nip points > > to > > + // tbegin+4, as explained in L103-104 (ibidem). Hence it's necessary > to > > + // restore the context where the `trap` or the illegal instruction > are, which > > + // is the second context in uc->uc_link. > > + if (transaction_uc) { > > + uc = transaction_uc; > > + uc->uc_link = NULL; > > + ucVoid = (void*) uc; > > + } > > + > > Thread* t = Thread::current_or_null_safe(); > > > > SignalHandlerMark shm(t); > > > > Is it possible to open a bug for this issue? > > > > Thank you and best regards, > > Gustavo > > > > [1] > > https://github.com/torvalds/linux/blob/master/Documentation/powerpc/tr > > ansactional_memory.txt#L96-L105 > > [2] > > https://github.com/torvalds/linux/blob/master/Documentation/powerpc/tr > > ansactional_memory.txt#L106-L107 > > From volker.simonis at gmail.com Fri Jul 22 09:08:31 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Jul 2016 11:08:31 +0200 Subject: [8u] request for approval: "8152172: PPC64: Support AES intrinsics" Message-ID: Hi, could you please approve the backport of the following, mostly ppc64 change to jdk8u-dev: 8152172: PPC64: Support AES intrinsics Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/ Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/ Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032 URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f As you can see, the change consists of two parts - the main one in the hotpsot repo and a small part in the jdk repo. The jdk part applied cleanly to jdk8u (with the usual directory shuffling). The hotspot part required a small tweak, but only in the ppc-only part. This is because the feature detection for the AES instructions was already active in jdk9 when the original change was made but is not available in jdk8u until now. You can find the additional changes at the end of this mail for your convenience. The required shared changes cleanly apply to jdk8u. As Vladimir pointed out in a previous thread, shared Hotspot changes have to go through JPRT even in jdk8u-dev. So I need a sponsor to do that and synchronously push both parts. @Hiroshii: could you please verify that you are fine with the change? I've done some tests on Power8LE but just want to be sure this downport satisfies your needs as well. Thank you and best regards, Volker ===================== diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700 +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200 @@ -452,6 +476,7 @@ a->popcntw(R7, R5); // code[7] -> popcntw a->fcfids(F3, F4); // code[8] -> fcfids a->vand(VR0, VR0, VR0); // code[9] -> vand + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher a->blr(); // Emit function to set one cache line to zero. Emit function descriptor and get pointer to it. @@ -495,6 +520,7 @@ if (code[feature_cntr++]) features |= popcntw_m; if (code[feature_cntr++]) features |= fcfids_m; if (code[feature_cntr++]) features |= vand_m; + if (code[feature_cntr++]) features |= vcipher_m; // Print the detection code. if (PrintAssembly) { diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700 +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200 @@ -42,6 +42,7 @@ fcfids, vand, dcba, + vcipher, num_features // last entry to count features }; enum Feature_Flag_Set { @@ -56,6 +57,7 @@ fcfids_m = (1 << fcfids ), vand_m = (1 << vand ), dcba_m = (1 << dcba ), + vcipher_m = (1 << vcipher), all_features_m = -1 }; static int _features; @@ -83,6 +85,7 @@ static bool has_fcfids() { return (_features & fcfids_m) != 0; } static bool has_vand() { return (_features & vand_m) != 0; } static bool has_dcba() { return (_features & dcba_m) != 0; } + static bool has_vcipher() { return (_features & vcipher_m) != 0; } static const char* cpu_features() { return _features_str; } From rwestrel at redhat.com Fri Jul 22 10:00:07 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 22 Jul 2016 12:00:07 +0200 Subject: RFR: 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: <57910421.7090300@redhat.com> References: <57910421.7090300@redhat.com> Message-ID: > http://cr.openjdk.java.net/~aph/8162338/ That looks good to me. Roland. From brent.christian at oracle.com Fri Jul 22 16:59:54 2016 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 22 Jul 2016 09:59:54 -0700 Subject: RFR 8161028 : GPL header missing comma after year In-Reply-To: References: Message-ID: Super boring, I know, but can somebody review this small diff? It's really small. :) Thank you, -Brent On 7/20/16 11:19 AM, Brent Christian wrote: > Hi, > > Looks like I didn't do the copyright on the stackwalk native files quite > right - needs a comma after the 2nd year. (You gotta have more commas!) > > Proposed diff below. > (Note that I am not subscribed to this alias) > > --- a/src/share/vm/prims/stackwalk.cpp Wed Jul 20 14:47:53 2016 +0300 > +++ b/src/share/vm/prims/stackwalk.cpp Wed Jul 20 10:49:53 2016 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2015, 2016, 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 > diff -r 9f5a448947a4 src/share/vm/prims/stackwalk.hpp > --- a/src/share/vm/prims/stackwalk.hpp Wed Jul 20 14:47:53 2016 +0300 > +++ b/src/share/vm/prims/stackwalk.hpp Wed Jul 20 10:49:53 2016 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2015, 2016, 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 > > Thanks, > -Brent > From daniel.daugherty at oracle.com Fri Jul 22 17:03:09 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 22 Jul 2016 11:03:09 -0600 Subject: RFR 8161028 : GPL header missing comma after year In-Reply-To: References: Message-ID: Thumbs up! Dan On 7/22/16 10:59 AM, Brent Christian wrote: > Super boring, I know, but can somebody review this small diff? It's > really small. :) > > Thank you, > -Brent > > On 7/20/16 11:19 AM, Brent Christian wrote: >> Hi, >> >> Looks like I didn't do the copyright on the stackwalk native files quite >> right - needs a comma after the 2nd year. (You gotta have more commas!) >> >> Proposed diff below. >> (Note that I am not subscribed to this alias) >> >> --- a/src/share/vm/prims/stackwalk.cpp Wed Jul 20 14:47:53 2016 +0300 >> +++ b/src/share/vm/prims/stackwalk.cpp Wed Jul 20 10:49:53 2016 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2016, 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 >> diff -r 9f5a448947a4 src/share/vm/prims/stackwalk.hpp >> --- a/src/share/vm/prims/stackwalk.hpp Wed Jul 20 14:47:53 2016 +0300 >> +++ b/src/share/vm/prims/stackwalk.hpp Wed Jul 20 10:49:53 2016 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2016, 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 >> >> Thanks, >> -Brent >> From harold.seigel at oracle.com Fri Jul 22 17:00:45 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 22 Jul 2016 13:00:45 -0400 Subject: RFR 8161028 : GPL header missing comma after year In-Reply-To: References: Message-ID: <1750fa89-18ad-fc82-c9db-1986e2a5c009@oracle.com> Looks good! Harold On 7/22/2016 12:59 PM, Brent Christian wrote: > Super boring, I know, but can somebody review this small diff? It's > really small. :) > > Thank you, > -Brent > > On 7/20/16 11:19 AM, Brent Christian wrote: >> Hi, >> >> Looks like I didn't do the copyright on the stackwalk native files quite >> right - needs a comma after the 2nd year. (You gotta have more commas!) >> >> Proposed diff below. >> (Note that I am not subscribed to this alias) >> >> --- a/src/share/vm/prims/stackwalk.cpp Wed Jul 20 14:47:53 2016 +0300 >> +++ b/src/share/vm/prims/stackwalk.cpp Wed Jul 20 10:49:53 2016 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2016, 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 >> diff -r 9f5a448947a4 src/share/vm/prims/stackwalk.hpp >> --- a/src/share/vm/prims/stackwalk.hpp Wed Jul 20 14:47:53 2016 +0300 >> +++ b/src/share/vm/prims/stackwalk.hpp Wed Jul 20 10:49:53 2016 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2016, 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 >> >> Thanks, >> -Brent >> From brent.christian at oracle.com Fri Jul 22 17:01:47 2016 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 22 Jul 2016 10:01:47 -0700 Subject: RFR 8161028 : GPL header missing comma after year In-Reply-To: References: Message-ID: <24be8f9e-254b-9d17-20f3-c85c868c0391@oracle.com> Thank you! :) -B On 7/22/16 10:03 AM, Daniel D. Daugherty wrote: > Thumbs up! > > Dan > > > On 7/22/16 10:59 AM, Brent Christian wrote: >> Super boring, I know, but can somebody review this small diff? It's >> really small. :) >> >> Thank you, >> -Brent >> >> On 7/20/16 11:19 AM, Brent Christian wrote: >>> Hi, >>> >>> Looks like I didn't do the copyright on the stackwalk native files quite >>> right - needs a comma after the 2nd year. (You gotta have more commas!) >>> >>> Proposed diff below. >>> (Note that I am not subscribed to this alias) >>> >>> --- a/src/share/vm/prims/stackwalk.cpp Wed Jul 20 14:47:53 2016 +0300 >>> +++ b/src/share/vm/prims/stackwalk.cpp Wed Jul 20 10:49:53 2016 -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2015, 2016, 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 >>> diff -r 9f5a448947a4 src/share/vm/prims/stackwalk.hpp >>> --- a/src/share/vm/prims/stackwalk.hpp Wed Jul 20 14:47:53 2016 +0300 >>> +++ b/src/share/vm/prims/stackwalk.hpp Wed Jul 20 10:49:53 2016 -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2015, 2016, 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 >>> >>> Thanks, >>> -Brent >>> > From joseph.provino at oracle.com Fri Jul 22 17:15:37 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Fri, 22 Jul 2016 13:15:37 -0400 Subject: RFR 8161028 : GPL header missing comma after year In-Reply-To: References: Message-ID: <53d4992f-0cfa-26ee-54d3-6e03ac4f383f@oracle.com> looks good! joe On 7/22/2016 1:03 PM, Daniel D. Daugherty wrote: > Thumbs up! > > Dan > > > On 7/22/16 10:59 AM, Brent Christian wrote: >> Super boring, I know, but can somebody review this small diff? It's >> really small. :) >> >> Thank you, >> -Brent >> >> On 7/20/16 11:19 AM, Brent Christian wrote: >>> Hi, >>> >>> Looks like I didn't do the copyright on the stackwalk native files >>> quite >>> right - needs a comma after the 2nd year. (You gotta have more >>> commas!) >>> >>> Proposed diff below. >>> (Note that I am not subscribed to this alias) >>> >>> --- a/src/share/vm/prims/stackwalk.cpp Wed Jul 20 14:47:53 2016 >>> +0300 >>> +++ b/src/share/vm/prims/stackwalk.cpp Wed Jul 20 10:49:53 2016 >>> -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2015, 2016, 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 >>> diff -r 9f5a448947a4 src/share/vm/prims/stackwalk.hpp >>> --- a/src/share/vm/prims/stackwalk.hpp Wed Jul 20 14:47:53 2016 >>> +0300 >>> +++ b/src/share/vm/prims/stackwalk.hpp Wed Jul 20 10:49:53 2016 >>> -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2015, 2016, 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 >>> >>> Thanks, >>> -Brent >>> > From george.triantafillou at oracle.com Fri Jul 22 17:33:14 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 22 Jul 2016 13:33:14 -0400 Subject: RFR 8161028 : GPL header missing comma after year In-Reply-To: <1750fa89-18ad-fc82-c9db-1986e2a5c009@oracle.com> References: <1750fa89-18ad-fc82-c9db-1986e2a5c009@oracle.com> Message-ID: <05f8d016-d68e-ce0a-b458-32406c735a6a@oracle.com> +1 -George On 7/22/2016 1:00 PM, harold seigel wrote: > Looks good! > > Harold > > > On 7/22/2016 12:59 PM, Brent Christian wrote: >> Super boring, I know, but can somebody review this small diff? It's >> really small. :) >> >> Thank you, >> -Brent >> >> On 7/20/16 11:19 AM, Brent Christian wrote: >>> Hi, >>> >>> Looks like I didn't do the copyright on the stackwalk native files >>> quite >>> right - needs a comma after the 2nd year. (You gotta have more >>> commas!) >>> >>> Proposed diff below. >>> (Note that I am not subscribed to this alias) >>> >>> --- a/src/share/vm/prims/stackwalk.cpp Wed Jul 20 14:47:53 2016 >>> +0300 >>> +++ b/src/share/vm/prims/stackwalk.cpp Wed Jul 20 10:49:53 2016 >>> -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2015, 2016, 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 >>> diff -r 9f5a448947a4 src/share/vm/prims/stackwalk.hpp >>> --- a/src/share/vm/prims/stackwalk.hpp Wed Jul 20 14:47:53 2016 >>> +0300 >>> +++ b/src/share/vm/prims/stackwalk.hpp Wed Jul 20 10:49:53 2016 >>> -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2015, 2016, 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 >>> >>> Thanks, >>> -Brent >>> > From aph at redhat.com Fri Jul 22 17:46:15 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Jul 2016 18:46:15 +0100 Subject: PING^3: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <576DF4CD.502@oracle.com> References: <576AD768.3070005@redhat.com> <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> <576C0BD6.4000106@redhat.com> <576DB611.4030408@oracle.com> <576DF4CD.502@oracle.com> Message-ID: <57925BE7.1030000@redhat.com> [re-sending] http://cr.openjdk.java.net/~aph/8157306.1/ Hi Vladimir, The current status: This patch fixes a serious bug in AArch64 and perhaps other targets. It's blocked because you discovered that an assertion (added by this patch) was triggered by some tests. I do not believe that anything this patch does could cause whatever problem the assertion reveals. I have not been able to reproduce the problem that you saw. Therefore there is nothing that I can do to fix it. May I simply take the assertion out and resubmit the patch? This bug in C2 is real, and serious. This patch is a blocker for AArch64. Thanks, Andrew. From gnu.andrew at redhat.com Mon Jul 25 17:33:21 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Jul 2016 13:33:21 -0400 (EDT) Subject: [8u communication] Approaching JDK 8 Updates milestone: 8u112 RDP In-Reply-To: <20160722131942.GD3768@vimes> References: <20160722131942.GD3768@vimes> Message-ID: <1879590918.8456697.1469468001189.JavaMail.zimbra@redhat.com> ----- Original Message ----- > As per the preliminary 8u112 timeline [1], the 8u112 Rampdown 2 milestone is > approaching. Please aim to have all 8u112 planned fixes addressed by the end > of July 25th. The 8u112 RDP2 build is planned for July 26th and fixes need > to be in the jdk8u-dev forest slightly beforehand for PIT testing. > > -Rob > > [1] http://openjdk.java.net/projects/jdk8u/releases/8u112.html > It would be good to get 8u112 working with GCC 6. My latest 8u webrev for this has been waiting for review for two weeks now: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-July/005696.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From vladimir.kozlov at oracle.com Mon Jul 25 21:20:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jul 2016 14:20:35 -0700 Subject: PING^3: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <57925BE7.1030000@redhat.com> References: <576AD768.3070005@redhat.com> <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> <576C0BD6.4000106@redhat.com> <576DB611.4030408@oracle.com> <576DF4CD.502@oracle.com> <57925BE7.1030000@redhat.com> Message-ID: <579682A3.1080509@oracle.com> Hi Andrew, I finally got time to verify that changes in lcm without the assert do not introduce regression - tests failed without lcm changes. I am pushing only lcm.cpp change as you suggested. And I filed a separate bug for failing cases with the assert. https://bugs.openjdk.java.net/browse/JDK-8162496 Regards, Vladimir On 7/22/16 10:46 AM, Andrew Haley wrote: > [re-sending] > > http://cr.openjdk.java.net/~aph/8157306.1/ > > Hi Vladimir, > > The current status: > > This patch fixes a serious bug in AArch64 and perhaps other > targets. It's blocked because you discovered that an assertion > (added by this patch) was triggered by some tests. I do not believe > that anything this patch does could cause whatever problem the > assertion reveals. > > I have not been able to reproduce the problem that you saw. Therefore > there is nothing that I can do to fix it. May I simply take the > assertion out and resubmit the patch? > > This bug in C2 is real, and serious. This patch is a blocker for > AArch64. > > Thanks, > > Andrew. > From aph at redhat.com Tue Jul 26 07:50:22 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jul 2016 08:50:22 +0100 Subject: PING^3: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <579682A3.1080509@oracle.com> References: <576AD768.3070005@redhat.com> <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> <576C0BD6.4000106@redhat.com> <576DB611.4030408@oracle.com> <576DF4CD.502@oracle.com> <57925BE7.1030000@redhat.com> <579682A3.1080509@oracle.com> Message-ID: <5797163E.4070203@redhat.com> On 25/07/16 22:20, Vladimir Kozlov wrote: > I finally got time to verify that changes in lcm without the assert > do not introduce regression - tests failed without lcm changes. I am > pushing only lcm.cpp change as you suggested. And I filed a separate > bug for failing cases with the assert. > > https://bugs.openjdk.java.net/browse/JDK-8162496 Thank you! I'd like to have a stab at that bug for the failing cases if I could only reproduce it. Oh well. Andrew. From martin.doerr at sap.com Tue Jul 26 14:24:20 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 26 Jul 2016 14:24:20 +0000 Subject: PPC64 JVM crashes when RTM is enabled In-Reply-To: <777bc8ce70174a62baab35ea72dc2838@DEWDFE13DE09.global.corp.sap> References: <579114AC.6090700@linux.vnet.ibm.com> <777bc8ce70174a62baab35ea72dc2838@DEWDFE13DE09.global.corp.sap> Message-ID: <5a7de0e5b7c94c99903e78f785db031a@DEWDFE13DE14.global.corp.sap> Hi Gustavo and all, thanks for investigating. We have only tested RTM on AIX which seems to work fine. We have inserted the following code into JVM_handle_aix_signal: #if INCLUDE_RTM_OPT { int *inst_ptr = (int*)(pc - BytesPerInstWord); if (CodeCache::contains((address)inst_ptr) && MacroAssembler::is_tbegin(*inst_ptr)) { // Ignore transaction abort due to signal. Will jump to abort handler. if (TraceTraps) { tty->print_cr("Caught signal %d in transaction. Ignoring to jump to abort handler.", sig); } return true; } } #endif The transaction always got aborted and we never ran into this code. I had made the same experiment on linux in JVM_handle_linux_signal where we ran into it. But RTM didn't work as expected because I was using an old linux version which doesn't treat system calls as required. Maybe you would like to use this detection and figure out the context of the signaling instruction. Please keep in mind that the C/C++ code must be compilable on old linux versions (at least for big endian). But I guess this shouldn't be an issue as the uc_link isn't new. Can you provide a webrev? I can sponsor the fix. Best regards, Martin -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Freitag, 22. Juli 2016 08:44 To: Gustavo Romero ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Cc: Breno Leitao Subject: RE: PPC64 JVM crashes when RTM is enabled Hi Gustavo, very neat analysis! I opened https://bugs.openjdk.java.net/browse/JDK-8162369 Does AIX require a similar fix? Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Romero > Sent: Donnerstag, 21. Juli 2016 20:30 > To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Cc: Breno Leitao > Subject: PPC64 JVM crashes when RTM is enabled > Importance: High > > Hi > > As of now (jdk9/hs-comp, f3c27d6d4ad1 tip), JVM crashes due to the > delivery of > a signal in the middle of an HTM transaction on PPC64 (on x64 this feature is > called RTM but on POWER it's called HTM, standing for Hardware > Transactional > Memory). > > When a SIGTRAP or a SIGILL is generated by the execution of a `trap` > instruction > or an illegal instruction at the beginning of a not entrant or zombie method > and > it happens in the middle of an HTM transaction, it fails the HTM transaction. > > As a consequence two different ucontext_t structs are set by the Linux > kernel. > One context is related to the HTM block that failed while the other context is > related to where the offending instruction was executed, i.e. the method > con- > taining the `trap` or illegal instruction. Currently the JVM signal handler for > Linux/PPC64 just inspects the context related to the failed HTM block and > when > it verifies the value of nip, i.e. the Next Instruction Pointer set at > uc->uc_mcontext.regs->nip, by calling os::Linux::ucontext_get_pc(uc), the > signal > handler does not find the offending instruction but instead the instruction > located at tbegin+4, that consists in a branch to the HTM failure handler, as > explained here [1]. > > A simple test case is: > java -XX:+UnlockExperimentalVMOptions -XX:+UseRTMForStackLocks - > XX:+UseRTMLocking > > The issue first appeared in the > compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > jtreg test: > http://hastebin.com/raw/ufodiduqeh > > Please, refer to the following hs_err log: > http://hastebin.com/raw/zucifaxoce > > In this log, si_addr=0x00003fff60460c10 (where the trap instruction is) but > pc=0x00003fff60455ec4 (which points to tbegin+4, i.e. a beq instruction to > the > HTM failure handler, and not to a trap instruction). > > 0x00003fff60455ec0: .long 0x7c00051d (tbegin.) > 0x00003fff60455ec4: beq- 0x00003fff60455ee0 <======= pc = HTM failure > handler > 0x00003fff60455ec8: ld r14,0(r3) and not trap (or illegal) instr. > 0x00003fff60455ecc: clrldi r0,r14,61 > 0x00003fff60455ed0: cmpwi cr5,r0,1 > 0x00003fff60455ed4: beq- cr5,0x00003fff60455ff4 > 0x00003fff60455ed8: .long 0x7c00055d (tend.) > > Once in the signal handler, the pc is normally equal to si_addr, thus pc must > point to the trap instruction located in the marked not entrant (or zombie) > method. But when the JVM handler inspects pc it can't find a trap instruction > (or otherwise an illegal instruction if -XX:-UseSIGTRAP flag is used). So it's > an invalid condition for the JVM signal handler and the handler hits the > report_and_die. > > Here are two examples of it, one using a trap instruction to mark a not > entrant > method and another using a illegal instruction for the same purpose: > http://hastebin.com/raw/avahoyadik It's important to mention that the > crash is > indeed intermittent, so a few times a run will just not crash the JVM (it > seems > that the issue gets worse if the number of threads increase). > > The solution I found consists in restoring the right context that points to the > not entrant method, which is stored by the kernel in a second ucontext_t > struct > in case a signal is caught in the middle of an HTM transaction, as explained in > here [2]. > > The following patch is proposed to solve the issue, i.e. now > compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > always > passes: > > > diff -r adc8c84b7cf8 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Fri Jul 01 11:29:55 2016 > +0200 > +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Wed Jul 20 21:52:08 > 2016 -0400 > @@ -219,6 +219,28 @@ > int abort_if_unrecognized) { > ucontext_t* uc = (ucontext_t*) ucVoid; > > + // A second thread context exists if the signal is delivered during a > + // transaction. Please see kernel doc transactional_memory.txt, L99-101: > + // https://goo.gl/E1xbxZ > + ucontext_t* transaction_uc = uc->uc_link; > + > + // If uc->uc_link != NULL, then the signal happened during a transaction, as > + // pointed out in L106-107 (ibidem). MSR.TS bit must be checked for future > + // compatibility, but for now just checking uc->uc_link is ok. > + // > + // The JVM signal handler expects the context where a `trap` or > + // an illegal instruction occurs (i.e. at the beginning of a method marked as > + // not entrant or zombie), but if the first context `uc` is used it contains > + // the context of the HTM block, thus uc->uc_mcontext.regs->nip points > to > + // tbegin+4, as explained in L103-104 (ibidem). Hence it's necessary to > + // restore the context where the `trap` or the illegal instruction are, which > + // is the second context in uc->uc_link. > + if (transaction_uc) { > + uc = transaction_uc; > + uc->uc_link = NULL; > + ucVoid = (void*) uc; > + } > + > Thread* t = Thread::current_or_null_safe(); > > SignalHandlerMark shm(t); > > Is it possible to open a bug for this issue? > > Thank you and best regards, > Gustavo > > [1] > https://github.com/torvalds/linux/blob/master/Documentation/powerpc/tr > ansactional_memory.txt#L96-L105 > [2] > https://github.com/torvalds/linux/blob/master/Documentation/powerpc/tr > ansactional_memory.txt#L106-L107 From gromero at linux.vnet.ibm.com Wed Jul 27 00:48:06 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 26 Jul 2016 21:48:06 -0300 Subject: PPC64 JVM crashes when RTM is enabled In-Reply-To: <5a7de0e5b7c94c99903e78f785db031a@DEWDFE13DE14.global.corp.sap> References: <579114AC.6090700@linux.vnet.ibm.com> <777bc8ce70174a62baab35ea72dc2838@DEWDFE13DE09.global.corp.sap> <5a7de0e5b7c94c99903e78f785db031a@DEWDFE13DE14.global.corp.sap> Message-ID: <579804C6.20006@linux.vnet.ibm.com> Hi Goetz, Thomas, Martin Goetz, my knowledge on AIX kernel is close to zero, so I could not say for sure if the fix was required also on AIX before testing. Unfortunately I was unable to set up an AIX env so far in order to perform additional tests regarding the HTM behavior on AIX. That said, by looking at the AIX docs [1], it seems the AIX has a quite similar mechanism when dealing with an HTM abortion due to a signal, i.e. it will set accordingly a second context (or extended context). The only difference I see is on the member names, like __extcxt instead of uc_link and also the way to check if such a extended context exists, since on AIX there will be a member called __extctx_magic that must be check if being equal to __EXTCTX_MAGIC and if so that indicates we got a signal in the middle of an HTM transaction. unsigned long long __extctx; /* address of extended context */ int __extctx_magic; /* if set to __EXTCTX_MAGIC, then */ /* extended context is present */ Nonetheless, Martin proposes a different solution, which consists in not switching the context where the trap/illegal instruction occurs but instead to use the current one and let it fall into the HTM failure handler, so not using the second (extended) context. Martin, I've tested on Linux the solution as you've tried on AIX and it works. But I've got a question: checking if the signal happened in the middle of an HTM transaction by just checking the presence of tbegin. at pc-4, aren't we missing a crash in case an illegal instruction is generated (and executed) /not/ intentionally in the middle of an HTM transaction, due to, let's say, a bug in the JIT compiler? Anyway, I think that managing to fall into the HTM failure handler is the correct thing to do, instead of switching to the second context (my first approach to the problem). For instance, in a nested HTM: tbegin. beq failure_handler tbegin. beq failure_handler ... ... tend. tend. it seems wrong to return control to the second context (inner trap/illegal instruction) and not the most outer failure_handler (just as curiosity, no matter the number of levels of nested HTM blocks if any of them fails pc will set at the most outer HTM failure handler). Thomas, in any case both contexts contain be valid and we can choose any (or both) to include in the report. Also there are other registers, like TEXASR, that can indicate precisely why the HTM transactoin failed. But I'm not sure if we should include them in the crash report. Should we address the case when an unintentional instruction is caught in the middle of an HTM by including additional checks? Should we add any additional information in the report to indicate it happened in the middle of a HTM transaction? Goetz, thanks for opening the bug. Thank you and kind regards, Gustavo [1] https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.genprogc/transactional_memory.htm On 26-07-2016 11:24, Doerr, Martin wrote: > Hi Gustavo and all, > > thanks for investigating. We have only tested RTM on AIX which seems to work fine. > We have inserted the following code into JVM_handle_aix_signal: > > #if INCLUDE_RTM_OPT > { > int *inst_ptr = (int*)(pc - BytesPerInstWord); > if (CodeCache::contains((address)inst_ptr) && MacroAssembler::is_tbegin(*inst_ptr)) { > // Ignore transaction abort due to signal. Will jump to abort handler. > if (TraceTraps) { > tty->print_cr("Caught signal %d in transaction. Ignoring to jump to abort handler.", sig); > } > return true; > } > } > #endif > > The transaction always got aborted and we never ran into this code. > > I had made the same experiment on linux in JVM_handle_linux_signal where we ran into it. But RTM didn't work as expected because I was using an old linux version which doesn't treat system calls as required. > > Maybe you would like to use this detection and figure out the context of the signaling instruction. > > Please keep in mind that the C/C++ code must be compilable on old linux versions (at least for big endian). But I guess this shouldn't be an issue as the uc_link isn't new. > > Can you provide a webrev? I can sponsor the fix. > > Best regards, > Martin > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > Sent: Freitag, 22. Juli 2016 08:44 > To: Gustavo Romero ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Cc: Breno Leitao > Subject: RE: PPC64 JVM crashes when RTM is enabled > > Hi Gustavo, > > very neat analysis! I opened > https://bugs.openjdk.java.net/browse/JDK-8162369 > > Does AIX require a similar fix? > > Best regards, > Goetz. > > >> -----Original Message----- >> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >> bounces at openjdk.java.net] On Behalf Of Gustavo Romero >> Sent: Donnerstag, 21. Juli 2016 20:30 >> To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Cc: Breno Leitao >> Subject: PPC64 JVM crashes when RTM is enabled >> Importance: High >> >> Hi >> >> As of now (jdk9/hs-comp, f3c27d6d4ad1 tip), JVM crashes due to the >> delivery of >> a signal in the middle of an HTM transaction on PPC64 (on x64 this feature is >> called RTM but on POWER it's called HTM, standing for Hardware >> Transactional >> Memory). >> >> When a SIGTRAP or a SIGILL is generated by the execution of a `trap` >> instruction >> or an illegal instruction at the beginning of a not entrant or zombie method >> and >> it happens in the middle of an HTM transaction, it fails the HTM transaction. >> >> As a consequence two different ucontext_t structs are set by the Linux >> kernel. >> One context is related to the HTM block that failed while the other context is >> related to where the offending instruction was executed, i.e. the method >> con- >> taining the `trap` or illegal instruction. Currently the JVM signal handler for >> Linux/PPC64 just inspects the context related to the failed HTM block and >> when >> it verifies the value of nip, i.e. the Next Instruction Pointer set at >> uc->uc_mcontext.regs->nip, by calling os::Linux::ucontext_get_pc(uc), the >> signal >> handler does not find the offending instruction but instead the instruction >> located at tbegin+4, that consists in a branch to the HTM failure handler, as >> explained here [1]. >> >> A simple test case is: >> java -XX:+UnlockExperimentalVMOptions -XX:+UseRTMForStackLocks - >> XX:+UseRTMLocking >> >> The issue first appeared in the >> compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java >> jtreg test: >> http://hastebin.com/raw/ufodiduqeh >> >> Please, refer to the following hs_err log: >> http://hastebin.com/raw/zucifaxoce >> >> In this log, si_addr=0x00003fff60460c10 (where the trap instruction is) but >> pc=0x00003fff60455ec4 (which points to tbegin+4, i.e. a beq instruction to >> the >> HTM failure handler, and not to a trap instruction). >> >> 0x00003fff60455ec0: .long 0x7c00051d (tbegin.) >> 0x00003fff60455ec4: beq- 0x00003fff60455ee0 <======= pc = HTM failure >> handler >> 0x00003fff60455ec8: ld r14,0(r3) and not trap (or illegal) instr. >> 0x00003fff60455ecc: clrldi r0,r14,61 >> 0x00003fff60455ed0: cmpwi cr5,r0,1 >> 0x00003fff60455ed4: beq- cr5,0x00003fff60455ff4 >> 0x00003fff60455ed8: .long 0x7c00055d (tend.) >> >> Once in the signal handler, the pc is normally equal to si_addr, thus pc must >> point to the trap instruction located in the marked not entrant (or zombie) >> method. But when the JVM handler inspects pc it can't find a trap instruction >> (or otherwise an illegal instruction if -XX:-UseSIGTRAP flag is used). So it's >> an invalid condition for the JVM signal handler and the handler hits the >> report_and_die. >> >> Here are two examples of it, one using a trap instruction to mark a not >> entrant >> method and another using a illegal instruction for the same purpose: >> http://hastebin.com/raw/avahoyadik It's important to mention that the >> crash is >> indeed intermittent, so a few times a run will just not crash the JVM (it >> seems >> that the issue gets worse if the number of threads increase). >> >> The solution I found consists in restoring the right context that points to the >> not entrant method, which is stored by the kernel in a second ucontext_t >> struct >> in case a signal is caught in the middle of an HTM transaction, as explained in >> here [2]. >> >> The following patch is proposed to solve the issue, i.e. now >> compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java >> always >> passes: >> >> >> diff -r adc8c84b7cf8 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp >> --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Fri Jul 01 11:29:55 2016 >> +0200 >> +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Wed Jul 20 21:52:08 >> 2016 -0400 >> @@ -219,6 +219,28 @@ >> int abort_if_unrecognized) { >> ucontext_t* uc = (ucontext_t*) ucVoid; >> >> + // A second thread context exists if the signal is delivered during a >> + // transaction. Please see kernel doc transactional_memory.txt, L99-101: >> + // https://goo.gl/E1xbxZ >> + ucontext_t* transaction_uc = uc->uc_link; >> + >> + // If uc->uc_link != NULL, then the signal happened during a transaction, as >> + // pointed out in L106-107 (ibidem). MSR.TS bit must be checked for future >> + // compatibility, but for now just checking uc->uc_link is ok. >> + // >> + // The JVM signal handler expects the context where a `trap` or >> + // an illegal instruction occurs (i.e. at the beginning of a method marked as >> + // not entrant or zombie), but if the first context `uc` is used it contains >> + // the context of the HTM block, thus uc->uc_mcontext.regs->nip points >> to >> + // tbegin+4, as explained in L103-104 (ibidem). Hence it's necessary to >> + // restore the context where the `trap` or the illegal instruction are, which >> + // is the second context in uc->uc_link. >> + if (transaction_uc) { >> + uc = transaction_uc; >> + uc->uc_link = NULL; >> + ucVoid = (void*) uc; >> + } >> + >> Thread* t = Thread::current_or_null_safe(); >> >> SignalHandlerMark shm(t); >> >> Is it possible to open a bug for this issue? >> >> Thank you and best regards, >> Gustavo >> >> [1] >> https://github.com/torvalds/linux/blob/master/Documentation/powerpc/tr >> ansactional_memory.txt#L96-L105 >> [2] >> https://github.com/torvalds/linux/blob/master/Documentation/powerpc/tr >> ansactional_memory.txt#L106-L107 > From paul.sandoz at oracle.com Wed Jul 27 11:47:12 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jul 2016 13:47:12 +0200 Subject: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access Message-ID: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> Hi, I made an embarrassing mistake in the fix for https://bugs.openjdk.java.net/browse/JDK-8151163 All Buffer implementations should leverage Unsafe unaligned accessors The offset calculation for Unsafe access was incorrect, it?s easy to get confused because for heap buffers the offset is relative to the array, and for direct buffers the address (which can update for slices/duplicates). Disturbingly all existing tests were passing both for core and hotspot when i pushed to hs. As a penance i wrote a combinatorial test for buffer views to navigate the twisty maze of heap/direct, aligned/unaligned, little/big endian for accessing binary data and views from the source buffer. Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162458-byte-buffer-view-offset-access-incorrect/webrev/ (This may be a duplicate of [1]). Test has been verified to fail with the existing code. Focused JPRT runs pass, but i will kick off core/hotspot runs later on today. I will push to hs since that is where JDK-8151163 and it has not been integrated into jdk9/dev. Paul. [1] https://bugs.openjdk.java.net/browse/JDK-8159257 unsafe.cpp: assert(byte_offset < p_size) failed: Unsafe access: offset 32767 > object's size 16 For the test runtime/Unsafe/RangeCheck.java I can reproduce a crash in jdk9/dev which does not have JDK-8151163, and i can reproduce on jdk9/hs with this fix for JDK-8162458. From aph at redhat.com Wed Jul 27 12:49:16 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jul 2016 13:49:16 +0100 Subject: RFD: C2: Poor code quality for Unsafe Message-ID: <5798ADCC.9000409@redhat.com> Summary: The code we generate for heap-based X-Buffers is good, but for off-heap X-Buffers it can be bad. Quite startlingly so. [This is AArch64 code, but Intel is very similar. I've been working on AArch64 so much that Intel assembler looks like line noise to me. I will produce x86 examples if anyone wants them.] Consider something like void floss(IntBuffer b, int n) { for (int i = 0; i < b.capacity(); i++) { b.put(i, n); } } If the byte buffer is allocated like this: ByteBuffer buf = ByteBuffer.allocate(SIZE * 4); IntBuffer ibuf; buf.order(ByteOrder.LITTLE_ENDIAN); ibuf = buf.asIntBuffer(); we get nice code, sweetly unrolled: 0x0000007fa127cd30: str w3, [x21,w1,sxtw #2] 0x0000007fa127cd34: str w3, [x13,w1,sxtw #2] 0x0000007fa127cd38: str w3, [x14,w1,sxtw #2] 0x0000007fa127cd3c: str w3, [x15,w1,sxtw #2] 0x0000007fa127cd40: str w3, [x16,w1,sxtw #2] 0x0000007fa127cd44: str w3, [x17,w1,sxtw #2] ... But if we allocate it as a direct buffer, like this: ByteBuffer buf = ByteBuffer.allocateDirect(SIZE * 4); bad things happen: 0x0000007fa526f060: add w12, w11, #0xf 0x0000007fa526f064: add w15, w11, #0xe 0x0000007fa526f068: sbfiz x12, x12, #2, #32 0x0000007fa526f06c: add x12, x12, x16 0x0000007fa526f070: sbfiz x14, x15, #2, #32 0x0000007fa526f074: add x14, x14, x16 0x0000007fa526f078: mov x18, x12 0x0000007fa526f07c: mov x0, x14 0x0000007fa526f080: sbfiz x12, x11, #2, #32 0x0000007fa526f084: add x12, x12, x16 0x0000007fa526f088: add w14, w11, #0x1 0x0000007fa526f08c: str w3, [x12] 0x0000007fa526f090: sbfiz x12, x14, #2, #32 0x0000007fa526f094: add x12, x12, x16 0x0000007fa526f098: add w15, w11, #0x2 0x0000007fa526f09c: str w3, [x12] ... As you can see, all of the address calculation is performed as arithmetic, and the loop contains more than three times as many instructions. [ Note: if we inline floss() in a caller method which knows a bit more about the types of the arguments and the fact that we keep using the same array we get much better code than this, back to something which is nearly optimal. But I'd argue that this is rather like rolling the dice and hoping for the best. ] So what's going on here? In a Direct-X-Buffer the address calculation is done as a long: private long ix(int i) { return address + ((long)i << $LG_BYTES_PER_VALUE$); } but in a ByteBufferAs-X-Buffer it's an int: protected int ix(int i) { return (i << $LG_BYTES_PER_VALUE$) + offset; } The reason for this optimization being missed is that in CastX2PNode::Ideal we convert CastX2P(AddX(x, y)) to AddP(CastX2P(x), y) if y fits in an int. The logic looks like this: if (fits_in_int(phase->type(y))) { return addP_of_X2P(phase, x, y); } if (fits_in_int(phase->type(x))) { return addP_of_X2P(phase, y, x); } I guess the idea here is that when we're indexing a pointer (encoded as a long) and an int, we always arrange things so that the pointer is on the left and we get a+n. But in the case where neither x nor y fits in an int we're not going to rearrange CastX2P(AddX(x, y)). Nothing in C2 recognizes any of this stuff, and we're going to keep the CastX2P nodes in the IR all the way to the back end. This seems to be easy enough to fix, at least for Direct-X-Buffers, like this, by commenting out a fits_in_int() test: if (fits_in_int(phase->type(y))) { return addP_of_X2P(phase, x, y); } // if (fits_in_int(phase->type(x))) { return addP_of_X2P(phase, y, x); } we then generate: 0x0000007f8527c260: str w3, [x15,w16,sxtw #2] 0x0000007f8527c264: add w12, w16, #0x1 0x0000007f8527c268: str w3, [x15,w12,sxtw #2] 0x0000007f8527c26c: add w13, w16, #0x2 0x0000007f8527c270: str w3, [x15,w13,sxtw #2] 0x0000007f8527c274: add w12, w16, #0x3 0x0000007f8527c278: str w3, [x15,w12,sxtw #2] 0x0000007f8527c27c: add w13, w16, #0x4 0x0000007f8527c280: str w3, [x15,w13,sxtw #2] 0x0000007f8527c284: add w12, w16, #0x5 ... This code isn't perfect but it's a heckuva lot better than we generate today. It's arbitrary to pick either x or y, but picking either is an improvement. Maybe we could do something smarter: if one of the arguments to the add is a shift, the other must be a base pointer. Thoughts? Does anyone here know the real reason why CastX2PNode::Ideal() only canonicalizes itself if one of its arguments fits in an int? Andrew. // Run with option dontinline ByteBufferTest::floss import java.nio.*; public class ByteBufferTest { int SIZE = 1024; ByteBuffer buf = ByteBuffer.allocateDirect(SIZE * 4); IntBuffer ibuf; ByteBufferTest() { buf.order(ByteOrder.LITTLE_ENDIAN); ibuf = buf.asIntBuffer(); } static private final ByteBufferTest test = new ByteBufferTest(); void floss(IntBuffer b, int n) { for (int i = 0; i < b.capacity(); i++) { b.put(i, n); } } public static void main(String[] args) { for (int i = 0; i < 100000; i++) test.floss(test.ibuf, i); } } From paul.sandoz at oracle.com Wed Jul 27 12:57:18 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jul 2016 14:57:18 +0200 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: <5798ADCC.9000409@redhat.com> References: <5798ADCC.9000409@redhat.com> Message-ID: Hi Andrew, What JDK build are you using? dev, hs, or hs-comp? Would it be possible to reevaluate with a fix for a bug i introduced switching ByteBufferAs-X-Buffer to use Unsafe? http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/024007.html Thanks, Paul. > On 27 Jul 2016, at 14:49, Andrew Haley wrote: > > Summary: The code we generate for heap-based X-Buffers is good, but > for off-heap X-Buffers it can be bad. Quite startlingly so. > > [This is AArch64 code, but Intel is very similar. I've been working > on AArch64 so much that Intel assembler looks like line noise to me. > I will produce x86 examples if anyone wants them.] > > Consider something like > > void floss(IntBuffer b, int n) { > for (int i = 0; i < b.capacity(); i++) { > b.put(i, n); > } > } > > If the byte buffer is allocated like this: > > ByteBuffer buf = ByteBuffer.allocate(SIZE * 4); > IntBuffer ibuf; > buf.order(ByteOrder.LITTLE_ENDIAN); > ibuf = buf.asIntBuffer(); > > we get nice code, sweetly unrolled: > > 0x0000007fa127cd30: str w3, [x21,w1,sxtw #2] > 0x0000007fa127cd34: str w3, [x13,w1,sxtw #2] > 0x0000007fa127cd38: str w3, [x14,w1,sxtw #2] > 0x0000007fa127cd3c: str w3, [x15,w1,sxtw #2] > 0x0000007fa127cd40: str w3, [x16,w1,sxtw #2] > 0x0000007fa127cd44: str w3, [x17,w1,sxtw #2] > ... > > But if we allocate it as a direct buffer, like this: > > ByteBuffer buf = ByteBuffer.allocateDirect(SIZE * 4); > > bad things happen: > > 0x0000007fa526f060: add w12, w11, #0xf > 0x0000007fa526f064: add w15, w11, #0xe > 0x0000007fa526f068: sbfiz x12, x12, #2, #32 > 0x0000007fa526f06c: add x12, x12, x16 > 0x0000007fa526f070: sbfiz x14, x15, #2, #32 > 0x0000007fa526f074: add x14, x14, x16 > 0x0000007fa526f078: mov x18, x12 > 0x0000007fa526f07c: mov x0, x14 > 0x0000007fa526f080: sbfiz x12, x11, #2, #32 > 0x0000007fa526f084: add x12, x12, x16 > 0x0000007fa526f088: add w14, w11, #0x1 > 0x0000007fa526f08c: str w3, [x12] > 0x0000007fa526f090: sbfiz x12, x14, #2, #32 > 0x0000007fa526f094: add x12, x12, x16 > 0x0000007fa526f098: add w15, w11, #0x2 > 0x0000007fa526f09c: str w3, [x12] > ... > > As you can see, all of the address calculation is performed as > arithmetic, and the loop contains more than three times as many > instructions. > > [ Note: if we inline floss() in a caller method which knows a bit more > about the types of the arguments and the fact that we keep using the > same array we get much better code than this, back to something which > is nearly optimal. But I'd argue that this is rather like rolling the > dice and hoping for the best. ] > > So what's going on here? > > In a Direct-X-Buffer the address calculation is done as a long: > > private long ix(int i) { > return address + ((long)i << $LG_BYTES_PER_VALUE$); > } > > but in a ByteBufferAs-X-Buffer it's an int: > > protected int ix(int i) { > return (i << $LG_BYTES_PER_VALUE$) + offset; > } > > The reason for this optimization being missed is that in > CastX2PNode::Ideal we convert CastX2P(AddX(x, y)) to AddP(CastX2P(x), > y) if y fits in an int. The logic looks like this: > > if (fits_in_int(phase->type(y))) > { > return addP_of_X2P(phase, x, y); > } > if (fits_in_int(phase->type(x))) > { > return addP_of_X2P(phase, y, x); > } > > I guess the idea here is that when we're indexing a pointer (encoded > as a long) and an int, we always arrange things so that the pointer is > on the left and we get a+n. But in the case where neither x nor y > fits in an int we're not going to rearrange CastX2P(AddX(x, y)). > > Nothing in C2 recognizes any of this stuff, and we're going to keep > the CastX2P nodes in the IR all the way to the back end. > > This seems to be easy enough to fix, at least for Direct-X-Buffers, > like this, by commenting out a fits_in_int() test: > > if (fits_in_int(phase->type(y))) > { > return addP_of_X2P(phase, x, y); > } > // if (fits_in_int(phase->type(x))) > { > return addP_of_X2P(phase, y, x); > } > > we then generate: > > 0x0000007f8527c260: str w3, [x15,w16,sxtw #2] > 0x0000007f8527c264: add w12, w16, #0x1 > 0x0000007f8527c268: str w3, [x15,w12,sxtw #2] > 0x0000007f8527c26c: add w13, w16, #0x2 > 0x0000007f8527c270: str w3, [x15,w13,sxtw #2] > 0x0000007f8527c274: add w12, w16, #0x3 > 0x0000007f8527c278: str w3, [x15,w12,sxtw #2] > 0x0000007f8527c27c: add w13, w16, #0x4 > 0x0000007f8527c280: str w3, [x15,w13,sxtw #2] > 0x0000007f8527c284: add w12, w16, #0x5 > ... > > This code isn't perfect but it's a heckuva lot better than we generate > today. It's arbitrary to pick either x or y, but picking either is an > improvement. Maybe we could do something smarter: if one of the > arguments to the add is a shift, the other must be a base pointer. > > Thoughts? Does anyone here know the real reason why > CastX2PNode::Ideal() only canonicalizes itself if one of its arguments > fits in an int? > > Andrew. > > > // Run with option dontinline ByteBufferTest::floss > > import java.nio.*; > > public class ByteBufferTest { > > int SIZE = 1024; > > ByteBuffer buf = ByteBuffer.allocateDirect(SIZE * 4); > IntBuffer ibuf; > > ByteBufferTest() { > buf.order(ByteOrder.LITTLE_ENDIAN); > ibuf = buf.asIntBuffer(); > } > > static private final ByteBufferTest test = new ByteBufferTest(); > > void floss(IntBuffer b, int n) { > for (int i = 0; i < b.capacity(); i++) { > b.put(i, n); > } > } > > public static void main(String[] args) { > for (int i = 0; i < 100000; i++) > test.floss(test.ibuf, i); > } > } > From aph at redhat.com Wed Jul 27 13:36:56 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jul 2016 14:36:56 +0100 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: References: <5798ADCC.9000409@redhat.com> Message-ID: <5798B8F8.8070902@redhat.com> On 27/07/16 13:57, Paul Sandoz wrote: > What JDK build are you using? dev, hs, or hs-comp? hs-comp. > Would it be possible to reevaluate with a fix for a bug i introduced switching ByteBufferAs-X-Buffer to use Unsafe? > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/024007.html Sure. It doesn't seem to make any difference to the exact issue I'm addressing. I'm kinda amazed that the ByteBufferTest didn't detect any of that. Oh well, I thought that it was so thorough. :-) Andrew. From paul.sandoz at oracle.com Wed Jul 27 13:45:59 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jul 2016 15:45:59 +0200 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: <5798B8F8.8070902@redhat.com> References: <5798ADCC.9000409@redhat.com> <5798B8F8.8070902@redhat.com> Message-ID: <8AE999A3-3952-4D56-9544-ECC8F94CC705@oracle.com> > On 27 Jul 2016, at 15:36, Andrew Haley wrote: > > On 27/07/16 13:57, Paul Sandoz wrote: >> What JDK build are you using? dev, hs, or hs-comp? > > hs-comp. > Only hs has the buggy fix for ByteBufferAs-X-Buffer to use Unsafe to read/write as wider primitives, so hs-comp will resort to reading/writing as bytes and composing/decomposing as view types via Bits.java. >> Would it be possible to reevaluate with a fix for a bug i introduced switching ByteBufferAs-X-Buffer to use Unsafe? >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/024007.html > > Sure. It doesn't seem to make any difference to the exact issue I'm > addressing. > Thanks. Perhaps it will if Unsafe is used to read wider primitives? > I'm kinda amazed that the ByteBufferTest didn't detect any of that. Oh > well, I thought that it was so thorough. :-) > Same here, and i added views to the test. I found out that slicing/duplicating when the position is > 0 complicates how offsets are progpagated and there are subtle differences between heap and direct buffers in that regard. Paul. From aph at redhat.com Wed Jul 27 13:54:49 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jul 2016 14:54:49 +0100 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: <8AE999A3-3952-4D56-9544-ECC8F94CC705@oracle.com> References: <5798ADCC.9000409@redhat.com> <5798B8F8.8070902@redhat.com> <8AE999A3-3952-4D56-9544-ECC8F94CC705@oracle.com> Message-ID: <5798BD29.5080604@redhat.com> On 27/07/16 14:45, Paul Sandoz wrote: > >> On 27 Jul 2016, at 15:36, Andrew Haley wrote: >> >> On 27/07/16 13:57, Paul Sandoz wrote: >>> What JDK build are you using? dev, hs, or hs-comp? >> >> hs-comp. > > Only hs has the buggy fix for ByteBufferAs-X-Buffer to use Unsafe to > read/write as wider primitives, so hs-comp will resort to > reading/writing as bytes and composing/decomposing as view types via > Bits.java. Yabbut: remember, I reviewed that patch, so my copy does. This code quality issue came up during that review. I determined that it was a HotSpot issue. >> Sure. It doesn't seem to make any difference to the exact issue I'm >> addressing. > > Thanks. Perhaps it will if Unsafe is used to read wider primitives? No. I now have everything that you have, I think. :-) Andrew. From paul.sandoz at oracle.com Wed Jul 27 14:08:57 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jul 2016 16:08:57 +0200 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: <5798BD29.5080604@redhat.com> References: <5798ADCC.9000409@redhat.com> <5798B8F8.8070902@redhat.com> <8AE999A3-3952-4D56-9544-ECC8F94CC705@oracle.com> <5798BD29.5080604@redhat.com> Message-ID: <3AA8093A-16C9-4235-B857-C17428505CDC@oracle.com> > On 27 Jul 2016, at 15:54, Andrew Haley wrote: > > On 27/07/16 14:45, Paul Sandoz wrote: >> >>> On 27 Jul 2016, at 15:36, Andrew Haley wrote: >>> >>> On 27/07/16 13:57, Paul Sandoz wrote: >>>> What JDK build are you using? dev, hs, or hs-comp? >>> >>> hs-comp. >> >> Only hs has the buggy fix for ByteBufferAs-X-Buffer to use Unsafe to >> read/write as wider primitives, so hs-comp will resort to >> reading/writing as bytes and composing/decomposing as view types via >> Bits.java. > > Yabbut: remember, I reviewed that patch, so my copy does. Ah, ok, i did not realize you had that patch applied as well, i was thrown off base because you mentioned the following method: protected int ix(int i) { return (i << $LG_BYTES_PER_VALUE$) + offset; } which is not used for access [*] in the patch(s). Paul. [*] Bad patch: 111 protected int ix(int i) { 112 return (i << $LG_BYTES_PER_VALUE$) + offset; 113 } 114 115 private long byteOffset(long i) { 116 return (i << $LG_BYTES_PER_VALUE$) + bb.address + offset; 117 } 118 119 public $type$ get() { 120 $memtype$ x = unsafe.get$Memtype$Unaligned(bb.hb, byteOffset(nextGetIndex()), 121 {#if[boB]?true:false}); 122 return $fromBits$(x); 123 } Good (hopefully!) patch: 110 private int ix(int i) { 111 int off = (int) (address - bb.address); 112 return (i << $LG_BYTES_PER_VALUE$) + off; 113 } 114 115 protected long byteOffset(long i) { 116 return (i << $LG_BYTES_PER_VALUE$) + address; 117 } 118 119 public $type$ get() { 120 $memtype$ x = unsafe.get$Memtype$Unaligned(bb.hb, byteOffset(nextGetIndex()), 121 {#if[boB]?true:false}); 122 return $fromBits$(x); 123 } > This code > quality issue came up during that review. I determined that it was a > HotSpot issue. > >>> Sure. It doesn't seem to make any difference to the exact issue I'm >>> addressing. >> >> Thanks. Perhaps it will if Unsafe is used to read wider primitives? > > No. I now have everything that you have, I think. :-) > > Andrew. From aph at redhat.com Wed Jul 27 14:13:26 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jul 2016 15:13:26 +0100 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: <3AA8093A-16C9-4235-B857-C17428505CDC@oracle.com> References: <5798ADCC.9000409@redhat.com> <5798B8F8.8070902@redhat.com> <8AE999A3-3952-4D56-9544-ECC8F94CC705@oracle.com> <5798BD29.5080604@redhat.com> <3AA8093A-16C9-4235-B857-C17428505CDC@oracle.com> Message-ID: <5798C186.6070008@redhat.com> On 27/07/16 15:08, Paul Sandoz wrote: > Ah, ok, i did not realize you had that patch applied as well, i was thrown off base because you mentioned the following method: I'll retest with hs just in case. Andrew. From aph at redhat.com Wed Jul 27 14:55:37 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jul 2016 15:55:37 +0100 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: <3AA8093A-16C9-4235-B857-C17428505CDC@oracle.com> References: <5798ADCC.9000409@redhat.com> <5798B8F8.8070902@redhat.com> <8AE999A3-3952-4D56-9544-ECC8F94CC705@oracle.com> <5798BD29.5080604@redhat.com> <3AA8093A-16C9-4235-B857-C17428505CDC@oracle.com> Message-ID: <5798CB69.60602@redhat.com> On 27/07/16 15:08, Paul Sandoz wrote: > Ah, ok, i did not realize you had that patch applied as well, i was thrown off base because you mentioned the following method: > > protected int ix(int i) { > return (i << $LG_BYTES_PER_VALUE$) + offset; > } > > which is not used for access [*] in the patch(s). It *is* used in Direct-X-Buffer, which is what gets inlined. The inlining looks like this: @ 18 ByteBufferTest::floss (24 bytes) inline (hot) @ 4 java.nio.Buffer::capacity (5 bytes) accessor @ 13 java.nio.DirectIntBufferU::put (18 bytes) inline (hot) @ 6 java.nio.Buffer::checkIndex (22 bytes) inline (hot) @ 9 java.nio.DirectIntBufferU::ix (10 bytes) inline (hot) @ 13 jdk.internal.misc.Unsafe::putInt (8 bytes) force inline by annotation @ 4 jdk.internal.misc.Unsafe::putInt (0 bytes) (intrinsic) @ 4 java.nio.Buffer::capacity (5 bytes) accessor I can confirm that your corrected patch makes no difference to any of this. Andrew. From aph at redhat.com Wed Jul 27 16:19:29 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jul 2016 17:19:29 +0100 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: <5798ADCC.9000409@redhat.com> References: <5798ADCC.9000409@redhat.com> Message-ID: <5798DF11.3080002@redhat.com> On 27/07/16 13:49, Andrew Haley wrote: > Summary: The code we generate for heap-based X-Buffers is good, but > for off-heap X-Buffers it can be bad. Quite startlingly so. I've been trying this, and it seems to work well: diff --git a/src/share/vm/opto/castnode.cpp b/src/share/vm/opto/castnode.cpp --- a/src/share/vm/opto/castnode.cpp +++ b/src/share/vm/opto/castnode.cpp @@ -456,6 +456,14 @@ if (fits_in_int(phase->type(x))) { return addP_of_X2P(phase, y, x); } + // convert CastX2P(AddX(x, y)) to AddP(CastX2P(x), y) if y is a + // pointer-size shift. + if (y->Opcode() == Op_LShiftX) { + return addP_of_X2P(phase, x, y); + } + if (x->Opcode() == Op_LShiftX) { + return addP_of_X2P(phase, y, x); + } break; } return NULL; Andrew. From paul.sandoz at oracle.com Thu Jul 28 10:10:17 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 28 Jul 2016 12:10:17 +0200 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: <5798CB69.60602@redhat.com> References: <5798ADCC.9000409@redhat.com> <5798B8F8.8070902@redhat.com> <8AE999A3-3952-4D56-9544-ECC8F94CC705@oracle.com> <5798BD29.5080604@redhat.com> <3AA8093A-16C9-4235-B857-C17428505CDC@oracle.com> <5798CB69.60602@redhat.com> Message-ID: Hi Andrew, Sorry, i went back and re-read your email, i got mixed up with direct and heap buffers. I observe similar behaviour as you do on x86 for direct int buffer views. For a direct int buffer view the compiled floss method has poorly generated code. However, when that floss method gets inlined into the on-stack-replaced main i observe good generated code. Seems fragile. I also verified my patch does not regress for heap int buffer views, and that patch uses a similar express for calculating the Unsafe address as for direct buffer views. Perhaps the code generation issue is also associated with single addressing mode? We recently switched the single addressing accessors to use the double address accessors passing null as the base value. It would be good to talk with Roland about this, as he implemented some improvements to the addressing calculations for Unsafe access for arrays and heap buffers. Paul. > On 27 Jul 2016, at 16:55, Andrew Haley wrote: > > On 27/07/16 15:08, Paul Sandoz wrote: >> Ah, ok, i did not realize you had that patch applied as well, i was thrown off base because you mentioned the following method: >> >> protected int ix(int i) { >> return (i << $LG_BYTES_PER_VALUE$) + offset; >> } >> >> which is not used for access [*] in the patch(s). > > It *is* used in Direct-X-Buffer, which is what gets inlined. The > inlining looks like this: > > @ 18 ByteBufferTest::floss (24 bytes) inline (hot) > @ 4 java.nio.Buffer::capacity (5 bytes) accessor > @ 13 java.nio.DirectIntBufferU::put (18 bytes) inline (hot) > @ 6 java.nio.Buffer::checkIndex (22 bytes) inline (hot) > @ 9 java.nio.DirectIntBufferU::ix (10 bytes) inline (hot) > @ 13 jdk.internal.misc.Unsafe::putInt (8 bytes) force inline by annotation > @ 4 jdk.internal.misc.Unsafe::putInt (0 bytes) (intrinsic) > @ 4 java.nio.Buffer::capacity (5 bytes) accessor > > I can confirm that your corrected patch makes no difference to any of > this. > > Andrew. > From paul.sandoz at oracle.com Thu Jul 28 10:33:19 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 28 Jul 2016 12:33:19 +0200 Subject: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access In-Reply-To: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> References: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> Message-ID: <90A0B797-2324-42B5-BAF9-E28AAB48B3E5@oracle.com> Hooking in nio dev. I think this issue is important to review/push soon (i.e. this week) so as it does not leak out beyond the hs repo. ? Incidentally this patch also fixes what might have been a long standing bug in the compact method of buffer views. Here is ByteBufferAsIntBufferB?s compact method: public IntBuffer compact() { int pos = position(); int lim = limit(); assert (pos <= lim); int rem = (pos <= lim ? lim - pos : 0); ByteBuffer db = bb.duplicate(); db.limit(ix(lim)); db.position(ix(0)); ByteBuffer sb = db.slice(); sb.position(pos << 2); sb.compact(); position(rem); limit(capacity()); discardMark(); return this; } For view heap buffers the ix method used to return an offset relative to the underlying byte array, not relative to the buffer. this this can result values that are beyond the capacity of the buffer. The following code: ByteBuffer bb0 = ByteBuffer.allocate(16); ByteBuffer bb4 = bb0.position(4).slice(); ByteBuffer bb8 = bb4.position(4).slice(); IntBuffer ib = bb8.asIntBuffer().compact(); results in: Exception in thread "main" java.lang.IllegalArgumentException: newLimit > capacity: (16 > 8) Paul. > On 27 Jul 2016, at 13:47, Paul Sandoz wrote: > > Hi, > > I made an embarrassing mistake in the fix for > > https://bugs.openjdk.java.net/browse/JDK-8151163 > All Buffer implementations should leverage Unsafe unaligned accessors > > The offset calculation for Unsafe access was incorrect, it?s easy to get confused because for heap buffers the offset is relative to the array, and for direct buffers the address (which can update for slices/duplicates). Disturbingly all existing tests were passing both for core and hotspot when i pushed to hs. > > As a penance i wrote a combinatorial test for buffer views to navigate the twisty maze of heap/direct, aligned/unaligned, little/big endian for accessing binary data and views from the source buffer. > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162458-byte-buffer-view-offset-access-incorrect/webrev/ > > (This may be a duplicate of [1]). > > Test has been verified to fail with the existing code. Focused JPRT runs pass, but i will kick off core/hotspot runs later on today. > > I will push to hs since that is where JDK-8151163 and it has not been integrated into jdk9/dev. > > Paul. > > [1] https://bugs.openjdk.java.net/browse/JDK-8159257 > unsafe.cpp: assert(byte_offset < p_size) failed: Unsafe access: offset 32767 > object's size 16 > > For the test runtime/Unsafe/RangeCheck.java I can reproduce a crash in jdk9/dev which does not have JDK-8151163, and i can reproduce on jdk9/hs with this fix for JDK-8162458. From aph at redhat.com Thu Jul 28 12:39:59 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Jul 2016 13:39:59 +0100 Subject: RFD: C2: Poor code quality for Unsafe In-Reply-To: References: <5798ADCC.9000409@redhat.com> <5798B8F8.8070902@redhat.com> <8AE999A3-3952-4D56-9544-ECC8F94CC705@oracle.com> <5798BD29.5080604@redhat.com> <3AA8093A-16C9-4235-B857-C17428505CDC@oracle.com> <5798CB69.60602@redhat.com> Message-ID: <5799FD1F.2030204@redhat.com> On 28/07/16 11:10, Paul Sandoz wrote: > It would be good to talk with Roland about this, as he implemented > some improvements to the addressing calculations for Unsafe access > for arrays and heap buffers. I already did, when I started this. It's pretty clear that the long arithmetic means that the X2P doesn't get canonicalized; the only issue in my mind is how best to fix it. Andrew. From daniel.daugherty at oracle.com Thu Jul 28 14:29:47 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Jul 2016 08:29:47 -0600 Subject: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access In-Reply-To: <90A0B797-2324-42B5-BAF9-E28AAB48B3E5@oracle.com> References: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> <90A0B797-2324-42B5-BAF9-E28AAB48B3E5@oracle.com> Message-ID: <130ce829-b790-54b3-21ad-20da02623377@oracle.com> Paul, I have marked this bug (JDK-8162458) as an 'integration_blocker' in order to keep JDK-8151163 from leaving JDK9-hs in its current state. Dan On 7/28/16 4:33 AM, Paul Sandoz wrote: > Hooking in nio dev. > > I think this issue is important to review/push soon (i.e. this week) so as it does not leak out beyond the hs repo. > > ? > > Incidentally this patch also fixes what might have been a long standing bug in the compact method of buffer views. > > Here is ByteBufferAsIntBufferB?s compact method: > > public IntBuffer compact() { > > int pos = position(); > int lim = limit(); > assert (pos <= lim); > int rem = (pos <= lim ? lim - pos : 0); > > ByteBuffer db = bb.duplicate(); > db.limit(ix(lim)); > db.position(ix(0)); > ByteBuffer sb = db.slice(); > sb.position(pos << 2); > sb.compact(); > position(rem); > limit(capacity()); > discardMark(); > return this; > } > > > For view heap buffers the ix method used to return an offset relative to the underlying byte array, not relative to the buffer. this this can result values that are beyond the capacity of the buffer. > > The following code: > > ByteBuffer bb0 = ByteBuffer.allocate(16); > ByteBuffer bb4 = bb0.position(4).slice(); > ByteBuffer bb8 = bb4.position(4).slice(); > IntBuffer ib = bb8.asIntBuffer().compact(); > > results in: > > Exception in thread "main" java.lang.IllegalArgumentException: newLimit > capacity: (16 > 8) > > Paul. > > >> On 27 Jul 2016, at 13:47, Paul Sandoz wrote: >> >> Hi, >> >> I made an embarrassing mistake in the fix for >> >> https://bugs.openjdk.java.net/browse/JDK-8151163 >> All Buffer implementations should leverage Unsafe unaligned accessors >> >> The offset calculation for Unsafe access was incorrect, it?s easy to get confused because for heap buffers the offset is relative to the array, and for direct buffers the address (which can update for slices/duplicates). Disturbingly all existing tests were passing both for core and hotspot when i pushed to hs. >> >> As a penance i wrote a combinatorial test for buffer views to navigate the twisty maze of heap/direct, aligned/unaligned, little/big endian for accessing binary data and views from the source buffer. >> >> Please review: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162458-byte-buffer-view-offset-access-incorrect/webrev/ >> >> (This may be a duplicate of [1]). >> >> Test has been verified to fail with the existing code. Focused JPRT runs pass, but i will kick off core/hotspot runs later on today. >> >> I will push to hs since that is where JDK-8151163 and it has not been integrated into jdk9/dev. >> >> Paul. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8159257 >> unsafe.cpp: assert(byte_offset < p_size) failed: Unsafe access: offset 32767 > object's size 16 >> >> For the test runtime/Unsafe/RangeCheck.java I can reproduce a crash in jdk9/dev which does not have JDK-8151163, and i can reproduce on jdk9/hs with this fix for JDK-8162458. > From vladimir.kozlov at oracle.com Fri Jul 29 01:29:38 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Jul 2016 18:29:38 -0700 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <579A3EB9.7060704@oracle.com> References: <579A3EB9.7060704@oracle.com> Message-ID: <579AB182.8040502@oracle.com> It affects all groups. Should be reviewed on hotspot-dev. Thanks, Vladimir On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: > Hi, > > please review small patch for 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests > > A problem is that tests under jdk repo can't use additional jtreg requires properties(like vm.flavor to filter out client or server vm). The same functionality was introduced for hotspot repo as part > of JDK-8154956. So, in order to filter tests using these additional properties a small fix is created. > > webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8162727 > > Thanks, > Dmitrij From leelamohan.venati at gmail.com Fri Jul 29 02:59:06 2016 From: leelamohan.venati at gmail.com (Leela Mohan) Date: Thu, 28 Jul 2016 19:59:06 -0700 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <540E605C.8020707@oracle.com> References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> Message-ID: I think, change in the file unsafe.cpp is incorrect. ( http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) Below function is accessing naked oops when thread has transitioned to "native": *+ static jobject get_class_loader(JNIEnv* env, jclass cls) {**+ if (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) {**+ return NULL;**+ }**+ Klass* k = java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ oop loader = k->class_loader();**+ return JNIHandles::make_local(env, loader);**+ }* - Leela On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > Thanks, Mandy! > > Coleen > > > On 9/8/14, 6:59 PM, Mandy Chung wrote: > >> Thumbs up. >> >> Mandy >> >> On 9/5/2014 12:55 PM, Coleen Phillimore wrote: >> >>> Summary: Add classLoader to java/lang/Class instance for fast access >>> >>> This is a backport request for 8u40. This change has been in the jdk9 >>> code for 3 months without any problems. >>> >>> The JDK changes hg imported cleanly. The Hotspot change needed a hand >>> merge for create_mirror call in klass.cpp. >>> >>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ >>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ >>> >>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>> >>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also ran >>> jck java_lang tests with only the hotspot change. The hotspot change can >>> be tested separately from the jdk change (but not the other way around). >>> >>> Thanks, >>> Coleen >>> >> >> > From david.holmes at oracle.com Fri Jul 29 05:51:59 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Jul 2016 15:51:59 +1000 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> Message-ID: Hi Leela, On 29/07/2016 12:59 PM, Leela Mohan wrote: > I think, change in the file unsafe.cpp is incorrect. ( > http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) > > Below function is accessing naked oops when thread has transitioned to > "native": > > *+ static jobject get_class_loader(JNIEnv* env, jclass cls) {**+ if > (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) > {**+ return NULL;**+ }**+ Klass* k = > java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ oop > loader = k->class_loader();**+ return JNIHandles::make_local(env, > loader);**+ }* klass types are no longer oops in the Java heap, but metaspace objects that reside in a per-classloader allocation region. They never get compacted or relocated so raw pointers to them are safe. Cheers, David > > - Leela > > On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> >> Thanks, Mandy! >> >> Coleen >> >> >> On 9/8/14, 6:59 PM, Mandy Chung wrote: >> >>> Thumbs up. >>> >>> Mandy >>> >>> On 9/5/2014 12:55 PM, Coleen Phillimore wrote: >>> >>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>> >>>> This is a backport request for 8u40. This change has been in the jdk9 >>>> code for 3 months without any problems. >>>> >>>> The JDK changes hg imported cleanly. The Hotspot change needed a hand >>>> merge for create_mirror call in klass.cpp. >>>> >>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ >>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ >>>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>>> >>>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also ran >>>> jck java_lang tests with only the hotspot change. The hotspot change can >>>> be tested separately from the jdk change (but not the other way around). >>>> >>>> Thanks, >>>> Coleen >>>> >>> >>> >> From dmitry.fazunenko at oracle.com Fri Jul 29 07:35:47 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 29 Jul 2016 10:35:47 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <579AB182.8040502@oracle.com> References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> Message-ID: Hi Dmitrij, The change itself looks good. One note: this change adds a little overhead (a very little) for running tests in jdk repository, but it's required only for VM specific tests stored in jdk. As alternative of this change I can suggest moving VM specific tests from the 'jdk' to 'hotspot' repository. Perhaps, such massive update is too late for JDK9 time frame and could be done only in JDK10. So, if the changes depending on 8162727 are not so critical and could be deferred I would prefer to postpone this fix. Thanks, Dima On 29.07.2016 4:29, Vladimir Kozlov wrote: > It affects all groups. Should be reviewed on hotspot-dev. > > Thanks, > Vladimir > > On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >> Hi, >> >> please review small patch for 8162727 - Testbug: additional requires >> properties can't be used for filtering server vm in jdk jtreg tests >> >> A problem is that tests under jdk repo can't use additional jtreg >> requires properties(like vm.flavor to filter out client or server >> vm). The same functionality was introduced for hotspot repo as part >> of JDK-8154956. So, in order to filter tests using these additional >> properties a small fix is created. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >> >> Thanks, >> Dmitrij From leelamohan.venati at gmail.com Fri Jul 29 07:55:47 2016 From: leelamohan.venati at gmail.com (Leela Mohan) Date: Fri, 29 Jul 2016 00:55:47 -0700 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> Message-ID: Hi David, I understand, Klass types are no longer oops but JNIHandles::resolve_non_null() would expose naked oops. In other words, KlassOops are no longer oops but java.lang.Class objects are. Thanks, Leela On Thu, Jul 28, 2016 at 10:51 PM, David Holmes wrote: > Hi Leela, > > On 29/07/2016 12:59 PM, Leela Mohan wrote: > >> I think, change in the file unsafe.cpp is incorrect. ( >> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) >> >> Below function is accessing naked oops when thread has transitioned to >> "native": >> >> *+ static jobject get_class_loader(JNIEnv* env, jclass cls) {**+ if >> (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) >> {**+ return NULL;**+ }**+ Klass* k = >> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ oop >> loader = k->class_loader();**+ return JNIHandles::make_local(env, >> loader);**+ }* >> > > klass types are no longer oops in the Java heap, but metaspace objects > that reside in a per-classloader allocation region. They never get > compacted or relocated so raw pointers to them are safe. > > Cheers, > David > > > >> - Leela >> >> On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < >> coleen.phillimore at oracle.com> wrote: >> >> >>> Thanks, Mandy! >>> >>> Coleen >>> >>> >>> On 9/8/14, 6:59 PM, Mandy Chung wrote: >>> >>> Thumbs up. >>>> >>>> Mandy >>>> >>>> On 9/5/2014 12:55 PM, Coleen Phillimore wrote: >>>> >>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>> >>>>> This is a backport request for 8u40. This change has been in the jdk9 >>>>> code for 3 months without any problems. >>>>> >>>>> The JDK changes hg imported cleanly. The Hotspot change needed a hand >>>>> merge for create_mirror call in klass.cpp. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ >>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ >>>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>>>> >>>>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also ran >>>>> jck java_lang tests with only the hotspot change. The hotspot change >>>>> can >>>>> be tested separately from the jdk change (but not the other way >>>>> around). >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>>> >>> From mikael.gerdin at oracle.com Fri Jul 29 08:35:56 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 29 Jul 2016 10:35:56 +0200 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> Message-ID: <6025906e-eaa4-62c6-b016-2269333e9dc8@oracle.com> Hi, (dropping core-libs since this is a VM-specific issue) On 2016-07-29 09:55, Leela Mohan wrote: > Hi David, > > I understand, Klass types are no longer oops but > JNIHandles::resolve_non_null() > would expose naked oops. In other words, KlassOops are no longer oops but > java.lang.Class objects are. I agree. In this case it's not only the java.lang.Class but also the ClassLoader oop. In an unrelated change I've toyed with adding an assertion that the current thread is not _thread_in_native in JNIHandles::resolve.. to catch similar problems. The code in the webrev explicitly transitions to native and as such there can be a GC in progress when get_class_loader is being executed and while resolving the handles and creating new ones are probably not going to crash we could be creating an invalid handle at line 962. I'm unable to locate the corresponding code in JDK 9 but in 8u the potential problem persists. The 8u UnsafeDefineClass0 needs the native transition because the JVM_ entrypoints expect it but all of them just transition back to _in_vm so if the code could just stay in the VM and use internal VM APIs to get the caller class and protection domains this would of course not be an issue. /Mikael > > Thanks, > Leela > > On Thu, Jul 28, 2016 at 10:51 PM, David Holmes > wrote: > >> Hi Leela, >> >> On 29/07/2016 12:59 PM, Leela Mohan wrote: >> >>> I think, change in the file unsafe.cpp is incorrect. ( >>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) >>> >>> Below function is accessing naked oops when thread has transitioned to >>> "native": >>> >>> *+ static jobject get_class_loader(JNIEnv* env, jclass cls) {**+ if >>> (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) >>> {**+ return NULL;**+ }**+ Klass* k = >>> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ oop >>> loader = k->class_loader();**+ return JNIHandles::make_local(env, >>> loader);**+ }* >>> >> >> klass types are no longer oops in the Java heap, but metaspace objects >> that reside in a per-classloader allocation region. They never get >> compacted or relocated so raw pointers to them are safe. >> >> Cheers, >> David >> >> >> >>> - Leela >>> >>> On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < >>> coleen.phillimore at oracle.com> wrote: >>> >>> >>>> Thanks, Mandy! >>>> >>>> Coleen >>>> >>>> >>>> On 9/8/14, 6:59 PM, Mandy Chung wrote: >>>> >>>> Thumbs up. >>>>> >>>>> Mandy >>>>> >>>>> On 9/5/2014 12:55 PM, Coleen Phillimore wrote: >>>>> >>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>> >>>>>> This is a backport request for 8u40. This change has been in the jdk9 >>>>>> code for 3 months without any problems. >>>>>> >>>>>> The JDK changes hg imported cleanly. The Hotspot change needed a hand >>>>>> merge for create_mirror call in klass.cpp. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ >>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ >>>>>> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>>>>> >>>>>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also ran >>>>>> jck java_lang tests with only the hotspot change. The hotspot change >>>>>> can >>>>>> be tested separately from the jdk change (but not the other way >>>>>> around). >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>>> >>>> From mikael.gerdin at oracle.com Fri Jul 29 08:45:27 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 29 Jul 2016 10:45:27 +0200 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <6025906e-eaa4-62c6-b016-2269333e9dc8@oracle.com> References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> <6025906e-eaa4-62c6-b016-2269333e9dc8@oracle.com> Message-ID: Leela, Thanks for the report! I filed https://bugs.openjdk.java.net/browse/JDK-8162766 to track the issue. I must ask, how did you find this in that old 2014 webrev? /Mikael On 2016-07-29 10:35, Mikael Gerdin wrote: > Hi, > > (dropping core-libs since this is a VM-specific issue) > > On 2016-07-29 09:55, Leela Mohan wrote: >> Hi David, >> >> I understand, Klass types are no longer oops but >> JNIHandles::resolve_non_null() >> would expose naked oops. In other words, KlassOops are no longer oops but >> java.lang.Class objects are. > > I agree. > In this case it's not only the java.lang.Class but also the ClassLoader > oop. > In an unrelated change I've toyed with adding an assertion that the > current thread is not _thread_in_native in JNIHandles::resolve.. to > catch similar problems. > > The code in the webrev explicitly transitions to native and as such > there can be a GC in progress when get_class_loader is being executed > and while resolving the handles and creating new ones are probably not > going to crash we could be creating an invalid handle at line 962. > > I'm unable to locate the corresponding code in JDK 9 but in 8u the > potential problem persists. > > The 8u UnsafeDefineClass0 needs the native transition because the JVM_ > entrypoints expect it but all of them just transition back to _in_vm so > if the code could just stay in the VM and use internal VM APIs to get > the caller class and protection domains this would of course not be an > issue. > > > /Mikael > >> >> Thanks, >> Leela >> >> On Thu, Jul 28, 2016 at 10:51 PM, David Holmes >> wrote: >> >>> Hi Leela, >>> >>> On 29/07/2016 12:59 PM, Leela Mohan wrote: >>> >>>> I think, change in the file unsafe.cpp is incorrect. ( >>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) >>>> >>>> Below function is accessing naked oops when thread has transitioned to >>>> "native": >>>> >>>> *+ static jobject get_class_loader(JNIEnv* env, jclass cls) {**+ if >>>> (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) >>>> {**+ return NULL;**+ }**+ Klass* k = >>>> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ oop >>>> loader = k->class_loader();**+ return JNIHandles::make_local(env, >>>> loader);**+ }* >>>> >>> >>> klass types are no longer oops in the Java heap, but metaspace objects >>> that reside in a per-classloader allocation region. They never get >>> compacted or relocated so raw pointers to them are safe. >>> >>> Cheers, >>> David >>> >>> >>> >>>> - Leela >>>> >>>> On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < >>>> coleen.phillimore at oracle.com> wrote: >>>> >>>> >>>>> Thanks, Mandy! >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 9/8/14, 6:59 PM, Mandy Chung wrote: >>>>> >>>>> Thumbs up. >>>>>> >>>>>> Mandy >>>>>> >>>>>> On 9/5/2014 12:55 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>>> >>>>>>> This is a backport request for 8u40. This change has been in >>>>>>> the jdk9 >>>>>>> code for 3 months without any problems. >>>>>>> >>>>>>> The JDK changes hg imported cleanly. The Hotspot change needed a >>>>>>> hand >>>>>>> merge for create_mirror call in klass.cpp. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ >>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ >>>>>>> >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>>>>>> >>>>>>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. >>>>>>> Also ran >>>>>>> jck java_lang tests with only the hotspot change. The hotspot >>>>>>> change >>>>>>> can >>>>>>> be tested separately from the jdk change (but not the other way >>>>>>> around). >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> From coleen.phillimore at oracle.com Fri Jul 29 11:12:59 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 29 Jul 2016 07:12:59 -0400 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <6025906e-eaa4-62c6-b016-2269333e9dc8@oracle.com> References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> <6025906e-eaa4-62c6-b016-2269333e9dc8@oracle.com> Message-ID: <6ccdf5f5-3d78-e6a2-8b2d-641fe7abd391@oracle.com> On 7/29/16 4:35 AM, Mikael Gerdin wrote: > Hi, > > (dropping core-libs since this is a VM-specific issue) > > On 2016-07-29 09:55, Leela Mohan wrote: >> Hi David, >> >> I understand, Klass types are no longer oops but >> JNIHandles::resolve_non_null() >> would expose naked oops. In other words, KlassOops are no longer oops >> but >> java.lang.Class objects are. > > I agree. > In this case it's not only the java.lang.Class but also the > ClassLoader oop. > In an unrelated change I've toyed with adding an assertion that the > current thread is not _thread_in_native in JNIHandles::resolve.. to > catch similar problems. > > The code in the webrev explicitly transitions to native and as such > there can be a GC in progress when get_class_loader is being executed > and while resolving the handles and creating new ones are probably not > going to crash we could be creating an invalid handle at line 962. I see it now. Wow, that is subtle and a good find. Thanks for filing the bug. Coleen > > I'm unable to locate the corresponding code in JDK 9 but in 8u the > potential problem persists. > > The 8u UnsafeDefineClass0 needs the native transition because the JVM_ > entrypoints expect it but all of them just transition back to _in_vm > so if the code could just stay in the VM and use internal VM APIs to > get the caller class and protection domains this would of course not > be an issue. > > > /Mikael > >> >> Thanks, >> Leela >> >> On Thu, Jul 28, 2016 at 10:51 PM, David Holmes >> wrote: >> >>> Hi Leela, >>> >>> On 29/07/2016 12:59 PM, Leela Mohan wrote: >>> >>>> I think, change in the file unsafe.cpp is incorrect. ( >>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) >>>> >>>> Below function is accessing naked oops when thread has transitioned to >>>> "native": >>>> >>>> *+ static jobject get_class_loader(JNIEnv* env, jclass cls) {**+ if >>>> (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) >>>> {**+ return NULL;**+ }**+ Klass* k = >>>> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ oop >>>> loader = k->class_loader();**+ return JNIHandles::make_local(env, >>>> loader);**+ }* >>>> >>> >>> klass types are no longer oops in the Java heap, but metaspace objects >>> that reside in a per-classloader allocation region. They never get >>> compacted or relocated so raw pointers to them are safe. >>> >>> Cheers, >>> David >>> >>> >>> >>>> - Leela >>>> >>>> On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < >>>> coleen.phillimore at oracle.com> wrote: >>>> >>>> >>>>> Thanks, Mandy! >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 9/8/14, 6:59 PM, Mandy Chung wrote: >>>>> >>>>> Thumbs up. >>>>>> >>>>>> Mandy >>>>>> >>>>>> On 9/5/2014 12:55 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>>> >>>>>>> This is a backport request for 8u40. This change has been in >>>>>>> the jdk9 >>>>>>> code for 3 months without any problems. >>>>>>> >>>>>>> The JDK changes hg imported cleanly. The Hotspot change needed >>>>>>> a hand >>>>>>> merge for create_mirror call in klass.cpp. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ >>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ >>>>>>> >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>>>>>> >>>>>>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. >>>>>>> Also ran >>>>>>> jck java_lang tests with only the hotspot change. The hotspot >>>>>>> change >>>>>>> can >>>>>>> be tested separately from the jdk change (but not the other way >>>>>>> around). >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> From coleen.phillimore at oracle.com Fri Jul 29 12:11:16 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 29 Jul 2016 08:11:16 -0400 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> <6025906e-eaa4-62c6-b016-2269333e9dc8@oracle.com> Message-ID: <81154516-ac07-5551-8018-31eb4d154cde@oracle.com> Leela, Do you want to contribute the fix, since you found the problem? I will sponsor it for you. Thanks, Coleen On 7/29/16 4:45 AM, Mikael Gerdin wrote: > Leela, > Thanks for the report! > I filed https://bugs.openjdk.java.net/browse/JDK-8162766 to track the > issue. > > I must ask, how did you find this in that old 2014 webrev? > > /Mikael > > On 2016-07-29 10:35, Mikael Gerdin wrote: >> Hi, >> >> (dropping core-libs since this is a VM-specific issue) >> >> On 2016-07-29 09:55, Leela Mohan wrote: >>> Hi David, >>> >>> I understand, Klass types are no longer oops but >>> JNIHandles::resolve_non_null() >>> would expose naked oops. In other words, KlassOops are no longer >>> oops but >>> java.lang.Class objects are. >> >> I agree. >> In this case it's not only the java.lang.Class but also the ClassLoader >> oop. >> In an unrelated change I've toyed with adding an assertion that the >> current thread is not _thread_in_native in JNIHandles::resolve.. to >> catch similar problems. >> >> The code in the webrev explicitly transitions to native and as such >> there can be a GC in progress when get_class_loader is being executed >> and while resolving the handles and creating new ones are probably not >> going to crash we could be creating an invalid handle at line 962. >> >> I'm unable to locate the corresponding code in JDK 9 but in 8u the >> potential problem persists. >> >> The 8u UnsafeDefineClass0 needs the native transition because the JVM_ >> entrypoints expect it but all of them just transition back to _in_vm so >> if the code could just stay in the VM and use internal VM APIs to get >> the caller class and protection domains this would of course not be an >> issue. >> >> >> /Mikael >> >>> >>> Thanks, >>> Leela >>> >>> On Thu, Jul 28, 2016 at 10:51 PM, David Holmes >>> >>> wrote: >>> >>>> Hi Leela, >>>> >>>> On 29/07/2016 12:59 PM, Leela Mohan wrote: >>>> >>>>> I think, change in the file unsafe.cpp is incorrect. ( >>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) >>>>> >>>>> Below function is accessing naked oops when thread has >>>>> transitioned to >>>>> "native": >>>>> >>>>> *+ static jobject get_class_loader(JNIEnv* env, jclass cls) {**+ if >>>>> (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) >>>>> {**+ return NULL;**+ }**+ Klass* k = >>>>> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ >>>>> oop >>>>> loader = k->class_loader();**+ return JNIHandles::make_local(env, >>>>> loader);**+ }* >>>>> >>>> >>>> klass types are no longer oops in the Java heap, but metaspace objects >>>> that reside in a per-classloader allocation region. They never get >>>> compacted or relocated so raw pointers to them are safe. >>>> >>>> Cheers, >>>> David >>>> >>>> >>>> >>>>> - Leela >>>>> >>>>> On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < >>>>> coleen.phillimore at oracle.com> wrote: >>>>> >>>>> >>>>>> Thanks, Mandy! >>>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 9/8/14, 6:59 PM, Mandy Chung wrote: >>>>>> >>>>>> Thumbs up. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>> On 9/5/2014 12:55 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Summary: Add classLoader to java/lang/Class instance for fast >>>>>>> access >>>>>>>> >>>>>>>> This is a backport request for 8u40. This change has been in >>>>>>>> the jdk9 >>>>>>>> code for 3 months without any problems. >>>>>>>> >>>>>>>> The JDK changes hg imported cleanly. The Hotspot change needed a >>>>>>>> hand >>>>>>>> merge for create_mirror call in klass.cpp. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ >>>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ >>>>>>>> >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>>>>>>> >>>>>>>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. >>>>>>>> Also ran >>>>>>>> jck java_lang tests with only the hotspot change. The hotspot >>>>>>>> change >>>>>>>> can >>>>>>>> be tested separately from the jdk change (but not the other way >>>>>>>> around). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> From dmitry.fazunenko at oracle.com Fri Jul 29 14:07:59 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 29 Jul 2016 17:07:59 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <579B3B08.1010105@oracle.com> References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <579B3B08.1010105@oracle.com> Message-ID: <46cd3c29-c71a-8449-f2da-6b494362b579@oracle.com> Dmitrij, On 29.07.2016 14:16, Dmitrij Pochepko wrote: > > > Hi, > > first of all thank you for review. > > I have bugfixes which depends on that. A number of tests needs these > properties for correct execution process. Okay, I don't object against this change. Once we moved VM tests from 'jdk' to 'hotspot' we can undo the change. So, looks good. Thanks, Dima > > Thanks, > Dmitrij >> Hi Dmitrij, >> >> The change itself looks good. >> >> One note: this change adds a little overhead (a very little) for >> running tests in jdk repository, but it's required only for VM >> specific tests stored in jdk. As alternative of this change I can >> suggest moving VM specific tests from the 'jdk' to 'hotspot' >> repository. Perhaps, such massive update is too late for JDK9 time >> frame and could be done only in JDK10. >> So, if the changes depending on 8162727 are not so critical and could >> be deferred I would prefer to postpone this fix. >> >> Thanks, >> Dima >> >> >> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>> It affects all groups. Should be reviewed on hotspot-dev. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> please review small patch for 8162727 - Testbug: additional >>>> requires properties can't be used for filtering server vm in jdk >>>> jtreg tests >>>> >>>> A problem is that tests under jdk repo can't use additional jtreg >>>> requires properties(like vm.flavor to filter out client or server >>>> vm). The same functionality was introduced for hotspot repo as part >>>> of JDK-8154956. So, in order to filter tests using these additional >>>> properties a small fix is created. >>>> >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>> >>>> Thanks, >>>> Dmitrij >> > From trevor.d.watson at oracle.com Fri Jul 29 08:37:08 2016 From: trevor.d.watson at oracle.com (Trevor Watson) Date: Fri, 29 Jul 2016 09:37:08 +0100 Subject: RFR: JDK-8141634 Implement VarHandles/Unsafe intrinsics on SPARC Message-ID: <7ebde74d-dd50-bfa8-4f2f-502088348c0d@oracle.com> Summary: SPARC assembler implementations of the compareAndExchange* intrinsics and the addition of the WeakCompareAndSwap* matchers. Have successfully run the 'gmake test' target and the benchmarks mentioned in the bug report. Benchmarks for the compareAndExchange* intrinsic operations now show an approximate 9x-20x improvement: Before: Benchmark Mode Cnt Score Error Units caeAcquire.IntTest.varHandle avgt 15 351.933 ? 7.161 ns/op caeAcquire.LongTest.varHandle avgt 15 435.872 ? 3.129 ns/op caeAcquire.ObjectTest.varHandle avgt 15 975.728 ? 88.362 ns/op caeRelease.IntTest.varHandle avgt 15 346.391 ? 2.798 ns/op caeRelease.LongTest.varHandle avgt 15 439.734 ? 9.739 ns/op caeRelease.ObjectTest.varHandle avgt 15 934.279 ? 19.454 ns/op caeVolatile.IntTest.varHandle avgt 15 346.076 ? 1.771 ns/op caeVolatile.LongTest.varHandle avgt 15 436.788 ? 1.825 ns/op caeVolatile.ObjectTest.varHandle avgt 15 935.250 ? 59.526 ns/op With new intrinsic implementation: caeAcquire.IntTest.varHandle avgt 15 38.514 ? 0.974 ns/op caeAcquire.LongTest.varHandle avgt 15 38.411 ? 0.359 ns/op caeAcquire.ObjectTest.varHandle avgt 15 42.616 ? 0.916 ns/op caeRelease.IntTest.varHandle avgt 15 38.235 ? 0.185 ns/op caeRelease.LongTest.varHandle avgt 15 38.165 ? 0.145 ns/op caeRelease.ObjectTest.varHandle avgt 15 42.320 ? 0.156 ns/op caeVolatile.IntTest.varHandle avgt 15 38.321 ? 0.221 ns/op caeVolatile.LongTest.varHandle avgt 15 38.270 ? 0.198 ns/op caeVolatile.ObjectTest.varHandle avgt 15 42.541 ? 0.720 ns/op Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8141634/ Bug link: https://bugs.openjdk.java.net/browse/JDK-8141634 From dmitrij.pochepko at oracle.com Fri Jul 29 11:16:24 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 29 Jul 2016 14:16:24 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> Message-ID: <579B3B08.1010105@oracle.com> Hi, first of all thank you for review. I have bugfixes which depends on that. A number of tests needs these properties for correct execution process. Thanks, Dmitrij > Hi Dmitrij, > > The change itself looks good. > > One note: this change adds a little overhead (a very little) for > running tests in jdk repository, but it's required only for VM > specific tests stored in jdk. As alternative of this change I can > suggest moving VM specific tests from the 'jdk' to 'hotspot' > repository. Perhaps, such massive update is too late for JDK9 time > frame and could be done only in JDK10. > So, if the changes depending on 8162727 are not so critical and could > be deferred I would prefer to postpone this fix. > > Thanks, > Dima > > > On 29.07.2016 4:29, Vladimir Kozlov wrote: >> It affects all groups. Should be reviewed on hotspot-dev. >> >> Thanks, >> Vladimir >> >> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> please review small patch for 8162727 - Testbug: additional requires >>> properties can't be used for filtering server vm in jdk jtreg tests >>> >>> A problem is that tests under jdk repo can't use additional jtreg >>> requires properties(like vm.flavor to filter out client or server >>> vm). The same functionality was introduced for hotspot repo as part >>> of JDK-8154956. So, in order to filter tests using these additional >>> properties a small fix is created. >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>> >>> Thanks, >>> Dmitrij > From joe.darcy at oracle.com Fri Jul 29 17:16:14 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 29 Jul 2016 10:16:14 -0700 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> Message-ID: <9491a957-7368-b373-b676-1987ba814550@oracle.com> Hello, I also recommend sending this review request over to core-libs-dev since it affect the jdk repo. Thanks, -Joe On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: > Hi Dmitrij, > > The change itself looks good. > > One note: this change adds a little overhead (a very little) for > running tests in jdk repository, but it's required only for VM > specific tests stored in jdk. As alternative of this change I can > suggest moving VM specific tests from the 'jdk' to 'hotspot' > repository. Perhaps, such massive update is too late for JDK9 time > frame and could be done only in JDK10. > So, if the changes depending on 8162727 are not so critical and could > be deferred I would prefer to postpone this fix. > > Thanks, > Dima > > > On 29.07.2016 4:29, Vladimir Kozlov wrote: >> It affects all groups. Should be reviewed on hotspot-dev. >> >> Thanks, >> Vladimir >> >> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> please review small patch for 8162727 - Testbug: additional requires >>> properties can't be used for filtering server vm in jdk jtreg tests >>> >>> A problem is that tests under jdk repo can't use additional jtreg >>> requires properties(like vm.flavor to filter out client or server >>> vm). The same functionality was introduced for hotspot repo as part >>> of JDK-8154956. So, in order to filter tests using these additional >>> properties a small fix is created. >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>> >>> Thanks, >>> Dmitrij > From coleen.phillimore at oracle.com Fri Jul 29 17:52:05 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 29 Jul 2016 13:52:05 -0400 Subject: RFR 8161445: [BACKOUT] MemberNameTable doesn't purge stale entries Message-ID: Summary: Original change caused performance regression in microbenchmarks after GC Eric Caspole's additional performance measurements are in the bug report. Also, I don't think it was a good idea for the jvm to intern MemberName assuming they are immutable. The interning should be in Java code. I didn't see a huge advantage to interning these as there weren't a big proportion of duplicates that I could see in my logging. I added a REDO bug and contacted the submitter for the severity of this problem in real life, since what they sent was a microbenchmark as well. Tested with JPRT and original test case. The backout was clean and had no conflicts. open webrev at http://cr.openjdk.java.net/~coleenp/8161445/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8161445 Thanks, Coleen From volker.simonis at gmail.com Fri Jul 29 18:58:25 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Jul 2016 20:58:25 +0200 Subject: [8u] request for approval: "8152172: PPC64: Support AES intrinsics" In-Reply-To: References: Message-ID: Ping! Can I please have an approval for backporting this change to 8u-dev? Thanks, Volker On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis wrote: > Hi, > > could you please approve the backport of the following, mostly ppc64 > change to jdk8u-dev: > > 8152172: PPC64: Support AES intrinsics > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 > Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/ > Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032 > URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b > URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f > > As you can see, the change consists of two parts - the main one in the > hotpsot repo and a small part in the jdk repo. > > The jdk part applied cleanly to jdk8u (with the usual directory shuffling). > > The hotspot part required a small tweak, but only in the ppc-only > part. This is because the feature detection for the AES instructions > was already active in jdk9 when the original change was made but is > not available in jdk8u until now. You can find the additional changes > at the end of this mail for your convenience. > > The required shared changes cleanly apply to jdk8u. > > As Vladimir pointed out in a previous thread, shared Hotspot changes > have to go through JPRT even in jdk8u-dev. So I need a sponsor to do > that and synchronously push both parts. > > @Hiroshii: could you please verify that you are fine with the change? > I've done some tests on Power8LE but just want to be sure this > downport satisfies your needs as well. > > Thank you and best regards, > Volker > > ===================== > > diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp > --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700 > +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200 > @@ -452,6 +476,7 @@ > a->popcntw(R7, R5); // code[7] -> popcntw > a->fcfids(F3, F4); // code[8] -> fcfids > a->vand(VR0, VR0, VR0); // code[9] -> vand > + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher > a->blr(); > > // Emit function to set one cache line to zero. Emit function > descriptor and get pointer to it. > @@ -495,6 +520,7 @@ > if (code[feature_cntr++]) features |= popcntw_m; > if (code[feature_cntr++]) features |= fcfids_m; > if (code[feature_cntr++]) features |= vand_m; > + if (code[feature_cntr++]) features |= vcipher_m; > > // Print the detection code. > if (PrintAssembly) { > diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp > --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700 > +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200 > @@ -42,6 +42,7 @@ > fcfids, > vand, > dcba, > + vcipher, > num_features // last entry to count features > }; > enum Feature_Flag_Set { > @@ -56,6 +57,7 @@ > fcfids_m = (1 << fcfids ), > vand_m = (1 << vand ), > dcba_m = (1 << dcba ), > + vcipher_m = (1 << vcipher), > all_features_m = -1 > }; > static int _features; > @@ -83,6 +85,7 @@ > static bool has_fcfids() { return (_features & fcfids_m) != 0; } > static bool has_vand() { return (_features & vand_m) != 0; } > static bool has_dcba() { return (_features & dcba_m) != 0; } > + static bool has_vcipher() { return (_features & vcipher_m) != 0; } > > static const char* cpu_features() { return _features_str; } From david.holmes at oracle.com Sat Jul 30 00:56:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 30 Jul 2016 10:56:50 +1000 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> Message-ID: <859ac976-cfb9-2bdf-67cc-10b928b6f24d@oracle.com> On 29/07/2016 5:55 PM, Leela Mohan wrote: > Hi David, > > I understand, Klass types are no longer oops > but JNIHandles::resolve_non_null() would expose naked oops. In other > words, KlassOops are no longer oops but java.lang.Class objects are. Yes my mistake - focusing on the wrong aspect. Good catch. Thanks, David > Thanks, > Leela > > On Thu, Jul 28, 2016 at 10:51 PM, David Holmes > wrote: > > Hi Leela, > > On 29/07/2016 12:59 PM, Leela Mohan wrote: > > I think, change in the file unsafe.cpp is incorrect. ( > http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) > > Below function is accessing naked oops when thread has > transitioned to > "native": > > *+ static jobject get_class_loader(JNIEnv* env, jclass cls) > {**+ if > (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) > {**+ return NULL;**+ }**+ Klass* k = > java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ oop > loader = k->class_loader();**+ return JNIHandles::make_local(env, > loader);**+ }* > > > klass types are no longer oops in the Java heap, but metaspace > objects that reside in a per-classloader allocation region. They > never get compacted or relocated so raw pointers to them are safe. > > Cheers, > David > > > > - Leela > > On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < > coleen.phillimore at oracle.com > > wrote: > > > Thanks, Mandy! > > Coleen > > > On 9/8/14, 6:59 PM, Mandy Chung wrote: > > Thumbs up. > > Mandy > > On 9/5/2014 12:55 PM, Coleen Phillimore wrote: > > Summary: Add classLoader to java/lang/Class instance > for fast access > > This is a backport request for 8u40. This change > has been in the jdk9 > code for 3 months without any problems. > > The JDK changes hg imported cleanly. The Hotspot > change needed a hand > merge for create_mirror call in klass.cpp. > > http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ > http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ > > bug link > https://bugs.openjdk.java.net/browse/JDK-6642881 > > Ran jdk_core jtreg tests in jdk with both > jdk/hotspot changes. Also ran > jck java_lang tests with only the hotspot change. > The hotspot change can > be tested separately from the jdk change (but not > the other way around). > > Thanks, > Coleen > > > > > From leelamohan.venati at gmail.com Sat Jul 30 06:17:42 2016 From: leelamohan.venati at gmail.com (Leela Mohan) Date: Fri, 29 Jul 2016 23:17:42 -0700 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> <6025906e-eaa4-62c6-b016-2269333e9dc8@oracle.com> Message-ID: Mikael, Found it during our internal code inspection and tracked it to this webrev which got in the change. Thanks, Leela On Fri, Jul 29, 2016 at 1:45 AM, Mikael Gerdin wrote: > Leela, > Thanks for the report! > I filed https://bugs.openjdk.java.net/browse/JDK-8162766 to track the > issue. > > I must ask, how did you find this in that old 2014 webrev? > > /Mikael > > > On 2016-07-29 10:35, Mikael Gerdin wrote: > >> Hi, >> >> (dropping core-libs since this is a VM-specific issue) >> >> On 2016-07-29 09:55, Leela Mohan wrote: >> >>> Hi David, >>> >>> I understand, Klass types are no longer oops but >>> JNIHandles::resolve_non_null() >>> would expose naked oops. In other words, KlassOops are no longer oops but >>> java.lang.Class objects are. >>> >> >> I agree. >> In this case it's not only the java.lang.Class but also the ClassLoader >> oop. >> In an unrelated change I've toyed with adding an assertion that the >> current thread is not _thread_in_native in JNIHandles::resolve.. to >> catch similar problems. >> >> The code in the webrev explicitly transitions to native and as such >> there can be a GC in progress when get_class_loader is being executed >> and while resolving the handles and creating new ones are probably not >> going to crash we could be creating an invalid handle at line 962. >> >> I'm unable to locate the corresponding code in JDK 9 but in 8u the >> potential problem persists. >> >> The 8u UnsafeDefineClass0 needs the native transition because the JVM_ >> entrypoints expect it but all of them just transition back to _in_vm so >> if the code could just stay in the VM and use internal VM APIs to get >> the caller class and protection domains this would of course not be an >> issue. >> >> >> /Mikael >> >> >>> Thanks, >>> Leela >>> >>> On Thu, Jul 28, 2016 at 10:51 PM, David Holmes >>> wrote: >>> >>> Hi Leela, >>>> >>>> On 29/07/2016 12:59 PM, Leela Mohan wrote: >>>> >>>> I think, change in the file unsafe.cpp is incorrect. ( >>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) >>>>> >>>>> Below function is accessing naked oops when thread has transitioned to >>>>> "native": >>>>> >>>>> *+ static jobject get_class_loader(JNIEnv* env, jclass cls) {**+ if >>>>> (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) >>>>> {**+ return NULL;**+ }**+ Klass* k = >>>>> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ oop >>>>> loader = k->class_loader();**+ return JNIHandles::make_local(env, >>>>> loader);**+ }* >>>>> >>>>> >>>> klass types are no longer oops in the Java heap, but metaspace objects >>>> that reside in a per-classloader allocation region. They never get >>>> compacted or relocated so raw pointers to them are safe. >>>> >>>> Cheers, >>>> David >>>> >>>> >>>> >>>> - Leela >>>>> >>>>> On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < >>>>> coleen.phillimore at oracle.com> wrote: >>>>> >>>>> >>>>> Thanks, Mandy! >>>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 9/8/14, 6:59 PM, Mandy Chung wrote: >>>>>> >>>>>> Thumbs up. >>>>>> >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>> On 9/5/2014 12:55 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>>> >>>>>>>> >>>>>>>> This is a backport request for 8u40. This change has been in >>>>>>>> the jdk9 >>>>>>>> code for 3 months without any problems. >>>>>>>> >>>>>>>> The JDK changes hg imported cleanly. The Hotspot change needed a >>>>>>>> hand >>>>>>>> merge for create_mirror call in klass.cpp. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ >>>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ >>>>>>>> >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>>>>>>> >>>>>>>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. >>>>>>>> Also ran >>>>>>>> jck java_lang tests with only the hotspot change. The hotspot >>>>>>>> change >>>>>>>> can >>>>>>>> be tested separately from the jdk change (but not the other way >>>>>>>> around). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> From leelamohan.venati at gmail.com Sat Jul 30 06:22:48 2016 From: leelamohan.venati at gmail.com (Leela Mohan) Date: Fri, 29 Jul 2016 23:22:48 -0700 Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <81154516-ac07-5551-8018-31eb4d154cde@oracle.com> References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com> <540E605C.8020707@oracle.com> <6025906e-eaa4-62c6-b016-2269333e9dc8@oracle.com> <81154516-ac07-5551-8018-31eb4d154cde@oracle.com> Message-ID: Hi Coleen, I will be happy to contribute. I am planning to make the change in the lines of Mikael was mentioning. Let me make a patch and send it to the group soon. Thanks, Leela On Fri, Jul 29, 2016 at 5:11 AM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > Leela, > > Do you want to contribute the fix, since you found the problem? I will > sponsor it for you. > > Thanks, > Coleen > > > On 7/29/16 4:45 AM, Mikael Gerdin wrote: > >> Leela, >> Thanks for the report! >> I filed https://bugs.openjdk.java.net/browse/JDK-8162766 to track the >> issue. >> >> I must ask, how did you find this in that old 2014 webrev? >> >> /Mikael >> >> On 2016-07-29 10:35, Mikael Gerdin wrote: >> >>> Hi, >>> >>> (dropping core-libs since this is a VM-specific issue) >>> >>> On 2016-07-29 09:55, Leela Mohan wrote: >>> >>>> Hi David, >>>> >>>> I understand, Klass types are no longer oops but >>>> JNIHandles::resolve_non_null() >>>> would expose naked oops. In other words, KlassOops are no longer oops >>>> but >>>> java.lang.Class objects are. >>>> >>> >>> I agree. >>> In this case it's not only the java.lang.Class but also the ClassLoader >>> oop. >>> In an unrelated change I've toyed with adding an assertion that the >>> current thread is not _thread_in_native in JNIHandles::resolve.. to >>> catch similar problems. >>> >>> The code in the webrev explicitly transitions to native and as such >>> there can be a GC in progress when get_class_loader is being executed >>> and while resolving the handles and creating new ones are probably not >>> going to crash we could be creating an invalid handle at line 962. >>> >>> I'm unable to locate the corresponding code in JDK 9 but in 8u the >>> potential problem persists. >>> >>> The 8u UnsafeDefineClass0 needs the native transition because the JVM_ >>> entrypoints expect it but all of them just transition back to _in_vm so >>> if the code could just stay in the VM and use internal VM APIs to get >>> the caller class and protection domains this would of course not be an >>> issue. >>> >>> >>> /Mikael >>> >>> >>>> Thanks, >>>> Leela >>>> >>>> On Thu, Jul 28, 2016 at 10:51 PM, David Holmes >>> > >>>> wrote: >>>> >>>> Hi Leela, >>>>> >>>>> On 29/07/2016 12:59 PM, Leela Mohan wrote: >>>>> >>>>> I think, change in the file unsafe.cpp is incorrect. ( >>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) >>>>>> >>>>>> Below function is accessing naked oops when thread has transitioned to >>>>>> "native": >>>>>> >>>>>> *+ static jobject get_class_loader(JNIEnv* env, jclass cls) {**+ if >>>>>> (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) >>>>>> {**+ return NULL;**+ }**+ Klass* k = >>>>>> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));**+ oop >>>>>> loader = k->class_loader();**+ return JNIHandles::make_local(env, >>>>>> loader);**+ }* >>>>>> >>>>>> >>>>> klass types are no longer oops in the Java heap, but metaspace objects >>>>> that reside in a per-classloader allocation region. They never get >>>>> compacted or relocated so raw pointers to them are safe. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> >>>>> >>>>> - Leela >>>>>> >>>>>> On Mon, Sep 8, 2014 at 7:05 PM, Coleen Phillimore < >>>>>> coleen.phillimore at oracle.com> wrote: >>>>>> >>>>>> >>>>>> Thanks, Mandy! >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> On 9/8/14, 6:59 PM, Mandy Chung wrote: >>>>>>> >>>>>>> Thumbs up. >>>>>>> >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>> On 9/5/2014 12:55 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>>>> >>>>>>>>> >>>>>>>>> This is a backport request for 8u40. This change has been in >>>>>>>>> the jdk9 >>>>>>>>> code for 3 months without any problems. >>>>>>>>> >>>>>>>>> The JDK changes hg imported cleanly. The Hotspot change needed a >>>>>>>>> hand >>>>>>>>> merge for create_mirror call in klass.cpp. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ >>>>>>>>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ >>>>>>>>> >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>>>>>>>> >>>>>>>>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. >>>>>>>>> Also ran >>>>>>>>> jck java_lang tests with only the hotspot change. The hotspot >>>>>>>>> change >>>>>>>>> can >>>>>>>>> be tested separately from the jdk change (but not the other way >>>>>>>>> around). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> > From dmitrij.pochepko at oracle.com Fri Jul 29 18:42:14 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 29 Jul 2016 21:42:14 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <9491a957-7368-b373-b676-1987ba814550@oracle.com> References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> Message-ID: <579BA386.20608@oracle.com> Sure, now including core-libs-dev Thanks, Dmitrij On 29.07.2016 20:16, joe darcy wrote: > Hello, > > I also recommend sending this review request over to core-libs-dev > since it affect the jdk repo. > > Thanks, > > -Joe > > > On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >> Hi Dmitrij, >> >> The change itself looks good. >> >> One note: this change adds a little overhead (a very little) for >> running tests in jdk repository, but it's required only for VM >> specific tests stored in jdk. As alternative of this change I can >> suggest moving VM specific tests from the 'jdk' to 'hotspot' >> repository. Perhaps, such massive update is too late for JDK9 time >> frame and could be done only in JDK10. >> So, if the changes depending on 8162727 are not so critical and could >> be deferred I would prefer to postpone this fix. >> >> Thanks, >> Dima >> >> >> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>> It affects all groups. Should be reviewed on hotspot-dev. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> please review small patch for 8162727 - Testbug: additional >>>> requires properties can't be used for filtering server vm in jdk >>>> jtreg tests >>>> >>>> A problem is that tests under jdk repo can't use additional jtreg >>>> requires properties(like vm.flavor to filter out client or server >>>> vm). The same functionality was introduced for hotspot repo as part >>>> of JDK-8154956. So, in order to filter tests using these additional >>>> properties a small fix is created. >>>> >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>> >>>> Thanks, >>>> Dmitrij >> >