From coleen.phillimore at oracle.com Tue Apr 1 03:30:11 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 31 Mar 2014 23:30:11 -0400 Subject: RFR 8028497: SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool) In-Reply-To: <53345BD5.5020806@oracle.com> References: <5331EA20.6000001@oracle.com> <5332FF22.4010900@oracle.com> <5333438B.8090508@oracle.com> <53338653.6060500@oracle.com> <53341BF7.6060309@oracle.com> <53343DFC.9000904@oracle.com> <53345BD5.5020806@oracle.com> Message-ID: <533A32C3.3090002@oracle.com> Erik, You are right. The old code would use the Klass->mirror link to clear out the mirror->Klass link so that we didn't have a pointer to a deallocated Klass in a mirror that might still be live for CMS marking. The new code doesn't set the Klass->mirror link unless the mirror fields are completely allocated, so we could crash if we deallocated a Klass before the mirror because the mirror would still be pointing to the class. I've caught failed allocation in mirror fields so that the link is reset in this change. The only change is to the function create_mirror calls initialize_mirror_fields. open webrev at http://cr.openjdk.java.net/~coleenp/8028497_3/ Tested with vm.parallel_class_loading.testlist which do hit this case. Thanks! Coleen On 3/27/14 1:11 PM, Erik Helin wrote: > Hi Coleen, > > thanks for taking on this tricky bug! However, I think there is an > issue with your fix :( > > This case is for "normal" (non-CDS) class loading: > 1. We create the mirror > 2. We set up the link from the mirror to the Klass > 3. We fail somewhere before setting the link from the Klass to the > mirror, for example when allocating the Java object for the init > lock. > 4. The destructor for ClassFileParser is run and we add the Klass to the > deallocate list. > 5. A CMS concurrent cycle is started, it will treat all objects in eden > + the survivor area as roots (including the mirror). > 6. The above concurrent cycle enters the "final remark" phase and does > class unloading which will call free_deallocate_list() which will > return the memory for the Klass added to the deallocate list in step > 4 to Metaspace. > 7. The concurrent CMS cycle ends (the mirror is still in eden or young) > 8. A new concurrent CMS cycle is started, the mirror will once again be > treated as a root since it is still in eden or young (no YC has been > done). > 9. During the initial marking, CMS will now follow the pointer to the > Klass that the mirror is mirroring, but we returned this memory to > Metaspace in step 6. > 10. We now crash :( > > Unfortunately, I don't have any suggestion on how to solve the above > scenario at the moment. > > Thanks, > Erik > > On 2014-03-27 16:04, Coleen Phillimore wrote: >> >> On 3/27/14 8:39 AM, Stefan Karlsson wrote: >>> >>> On 2014-03-27 03:00, Coleen Phillimore wrote: >>>> >>>> I have a new version of this change based on code that Ioi noticed >>>> that I was missing for making restoring the method's adapters >>>> restartable if something fails during restore_unshareable_info, and >>>> the constant pool resolved references array. >>>> Please review this new code (only method.* and instanceKlass.cpp and >>>> constantPool.cpp have differences). Reran tests with CDS and CMS. >>>> >>>> http://cr.openjdk.java.net/~coleenp/8028497_2/ >>> >>> This seems good. I'd prefer if someone with more experience with CDS >>> also Reviews the change. >> >> Thanks, Ioi said he'd look at it. >> >>> >>> Small comment: >>> >>> http://cr.openjdk.java.net/~coleenp/8028497_2/src/share/vm/oops/instanceKlass.cpp.udiff.html >>> >>> >>> >>> - methodHandle m(THREAD, methods->at(index2)); >>> - m()->link_method(m, CHECK); >>> - // restore method's vtable by calling a virtual function >>> - m->restore_vtable(); >>> + Method *m = methods->at(index2); >>> + m->restore_unshareable_info(CHECK); >>> >>> >>> Do we really want to use a raw Method * here. I know that we wrap the >>> method in a handle inside m->restore_unshareable_info, but it's not >>> clear from the this context. I'm thinking about this issue: >>> https://bugs.openjdk.java.net/browse/JDK-8004815 >>> >>> On the other hand, I guess we can't redefine a class before it has >>> been defined. But maybe it would be good to not promote the usage of >>> Method* over calls that might hit a Safepoint. >>> >> >> I think you're right, we don't use 'm' after the potential safepoint and >> we can't really redefine this class yet anyway but I'll restore the code >> because we don't want to encourage uses of unhandled Methods unless >> proven to be harmless. >> >> Thanks! >> Coleen >>> thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 3/26/14 5:15 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi Jon, >>>>> Thank you for looking at the code changes. >>>>> >>>>> On 3/26/14 12:24 PM, Jon Masamitsu wrote: >>>>>> Coleen, >>>>>> >>>>>> Did you remove Class_obj_allocate() because it was only >>>>>> called in that one spot and use obj_allocate() did most >>>>>> of the work? >>>>> >>>>> I deleted it because GC doesn't need to know how these javaClasses >>>>> are set up and I spent way to long looking for this code and didn't >>>>> find it where it belongs, so I removed this. This Class_obj_allocate >>>>> is an artifact of the permgen code. >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/instanceMirrorKlass.cpp.frames.html >>>>>> >>>>>> >>>>>> >>>>>> 373 // the size in the mirror size itself. >>>>>> >>>>>> Drop the second "size". You know how we GC guys are >>>>>> getting with our comments :-). >>>>> >>>>> Yes, I noticed that. Thanks - fixed. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/klass.cpp.frames.html >>>>>> >>>>>> >>>>>> >>>>>> 498 void Klass::restore_unshareable_info(TRAPS) { >>>>>> 499 // If an exception happened during CDS restore, some of >>>>>> these fields may already be >>>>>> 500 // set. We leave the class on the CLD list, even if >>>>>> incomplete so that we don't >>>>>> 501 // modify the CLD list outside a safepoint. >>>>>> 502 if (class_loader_data() == NULL) { >>>>>> 503 ClassLoaderData* loader_data = >>>>>> ClassLoaderData::the_null_class_loader_data(); >>>>>> >>>>>> I can see that this works with the current CDS (sharing only >>>>>> classes loader >>>>>> with the NULL class loader). Will it work if the shared classes >>>>>> are loaded >>>>>> with an application class loader? >>>>> >>>>> I hope Ioi can answer that. I assume so because the classes don't >>>>> change class loaders if restoring shareable info fails. >>>>> >>>>> Ioi pointed out to me (not on open list) that I missed making >>>>> link_method() and creating the constant pool resolved references >>>>> array restartable, so I'm testing a fix for that also and I'll post >>>>> an update later. But you've seen most of it. >>>>> >>>>> Thanks!! >>>>> Coleen >>>>>> >>>>>> Rest looks good. >>>>>> >>>>>> Jon >>>>>> >>>>>> On 3/25/2014 1:42 PM, Coleen Phillimore wrote: >>>>>>> Summary: Keep class in CLD::_klasses list and mirror created for >>>>>>> CDS classes if OOM during restore_shareable_info(). This keeps >>>>>>> pointers consistent for CMS. >>>>>>> >>>>>>> This change makes restoring the mirror for shared classes >>>>>>> restartable if there is an OOM in the middle of >>>>>>> restore_unshareable_info. The mirror field in the classes and >>>>>>> CLD link is not cleaned up anymore. The class isn't marked loaded >>>>>>> though so must be loaded again. >>>>>>> >>>>>>> Tested with Stefan's test case with hard coded OOM in jvm, so >>>>>>> can't add the test. Also ran all the tests against -client and >>>>>>> server with -Xshare:auto and with -XX:+UseConcMarkSweepGC. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8028497/ >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8028497 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Tue Apr 1 06:02:41 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 01 Apr 2014 16:02:41 +1000 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap> Message-ID: <533A5681.20607@oracle.com> Hi Goetz, Not a review ... On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote: > Hi, > > could I please get reviews for this change? I please also need a sponsor. > I would like to get this into 8u20, as 8036330 was downported, too. > > I'd like to make the point of this change clear once more, independent > of which compiler does what. > > I think we agree that basically > - a file should include all headers that define symbols or include > method bodies used in that file Personally I don't see why a cpp file should have to be aware that a member function it uses just happens to have been defined in an inline.hpp file by its author. Seems to break encapsulation to me. :( > - a .hpp header should not include a .inline.hpp header I see 277 occurrences of this in the existing OpenJDK hotspot code, so I don't think we can take this as a general rule either. Note I'm not saying this fix isn't right or needed, just that the "rules" you are trying to embody don't seem to generally apply. David ----- > This is violated > > 1.) by defining > template void immediate_rs_update(HeapRegion* from, T* p, int tid) { > if (!from->is_survivor()) { > _g1_rem->par_write_ref(from, p, tid); > } > } > in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only defined in > g1RemSet.inline.hpp - which is not included and should not be included > in g1CollectedHeap.hpp. > 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp > > This change fixes these two points by moving functions into .inline.hpp files > and fixing the include. > > Best regards, > Goetz. > > > > > From: Lindenmaier, Goetz > Sent: Donnerstag, 27. M?rz 2014 17:46 > To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 > > Hi, > > Please review and test this change. I please need a sponsor: > http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ > > Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure > broke the dbg build on AIX. That's because do_oop_partial_array() is added in > a header, but requires inline function par_write_ref() through several inlined > calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined > as the corresponding inline header is not included. The aix debug VM does not start. > > This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp. > > Unfortunately this now causes a cyclic dependency that breaks the linux build. > A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file > can not see the class declaration. > This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp. > But .inline.hpp files never should be included in .hpp files. > > To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As consequence, > I had to move a row of functions to existing .inline.hpp files. > > I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, > sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. > > Best regards, > Goetz > From david.holmes at oracle.com Tue Apr 1 06:38:57 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 01 Apr 2014 16:38:57 +1000 Subject: RFR: 8033251: Use DWARF debug symbols for Linux 32-bit as default In-Reply-To: <53395F6E.4030505@oracle.com> References: <53359F78.6070503@oracle.com> <5335A38E.6040406@oracle.com> <5335A6F3.7010300@oracle.com> <5335BECD.9050808@oracle.com> <53364F7A.1020903@oracle.com> <53395F6E.4030505@oracle.com> Message-ID: <533A5F01.3060200@oracle.com> Hi Erik, On 31/03/2014 10:28 PM, Erik Helin wrote: > Hi David, > > thanks for having a look! Please see my reply inline. Thanks for the additional cleanup! Looks good. David > On 2014-03-29 05:43, David Holmes wrote: >> On 29/03/2014 4:26 AM, Coleen Phillimore wrote: >>> >>> On 3/28/14 12:44 PM, Erik Helin wrote: >>>> Hi Coleen, >>>> >>>> thanks for having a look at the patch! >>>> >>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>> >>>>> I thought you'd be able to remove the DEBUG_BINARIES logic with this >>>>> change. It appears there are no platforms left that use stabs with >>>>> gcc. >>>> >>>> Yeah, I also noticed that this change enables cleanups in the >>>> Makefiles. However, I think it is better to do these cleanups as a >>>> second change after this one, what do you think? >>> >>> A cleanup CR is fine. >> >> Unless the cleanup is coming "tomorrow" I disagree. What have now is >> comments that make no sense given the change that has been made. And as >> every defined platform seems to use -g we can get rid of all this >> per-platform logic and simply check for clang. All of which can be done >> without doing the DEBUG_BINARIES cleanup. Eg delete the per-platform >> flags and simply have, for example, >> >> # Override per-platform if the default -g doesn't suite >> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH)) >> ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) >> ifeq ($(USE_CLANG), true) >> # Clang doesn't understand -gstabs >> OPT_CFLAGS += -g >> else >> OPT_CFLAGS += -gstabs >> endif >> endif > > I wanted this change to only be about changing from STABS to DWARF, but > based on your feedback I cleaned up some code in the makefile as well: > > - Incremental webrev: > http://cr.openjdk.java.net/~ehelin/8033251/webrev.00-01/ > - New webrev: > http://cr.openjdk.java.net/~ehelin/8033251/webrev.01/ > > The default is now to use DWARF for all platforms, but this can be > changed by using CFLAGS, for example FASTDEBUG_CFLAGS/amd64=-gstabs will > give you STABS debug symbols for a fastdebug build on 64-bit Linux. > Having -g as default also enables us to get rid of all the $(USE_CLANG) > checks. > > The new patch also fixes a small bug where FASTDEBUG_CFLAGS was set to > $(DEBUG_CFLAGS/$(BUILDARCH)), it should be set to > $(FASTDEBUG_CFLAGS/$(BUILDARCH)). > > Testing of new patch: > - JPRT > - Building builds for different targets with different debug symbols > locally. > > Thanks, > Erik > >> In the future this flag should also potentially be coming in via >> spec.gmk. >> >> David >> >>>> >>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>> Does this change add -g for saproc, adlc and jsig compilations also? >>>> It seems like saproc uses SA_DEBUG_CFLAGS which only is being set if >>>> DEBUG_BINARIES=true. If DEBUG_BINARIES is not true, then it seems like >>>> we don't generate debug symbols (please correct me if I'm wrong). >>>> >>>> The above also seems to be the case for libjsig.so. >>>> >>> >>> These seem broken, but I don't know the makefiles well enough to >>> comment. >>> >>> I think this change is good. People have been asking for it for years >>> and now that the size problem with dwarf has been fixed, I'm glad you >>> are making this change. >>> >>> Thanks, >>> Coleen >>>> Looking in make/linux/makefiles/adlc.make it seems like adlc is using >>>> -g for GCC 3.3 or newer. >>>> >>>> Thanks, >>>> Erik >>>> >>>>> Coleen >>>>> >>>>> On 3/28/14 12:12 PM, Erik Helin wrote: >>>>>> Hi all, >>>>>> >>>>>> this patch changes the Linux Makefiles to use DWARF as the default >>>>>> debug symbol format for Linux 32-bit instead of STABS. The main >>>>>> arguments for using DWARF are: >>>>>> >>>>>> - DWARF provides a superior debugging experience compared to STABS. >>>>>> - STABS support in GCC/GDB is in maintenance mode [0]. >>>>>> - External tools (e.g. perf on Linux) often understands DWARF but >>>>>> not >>>>>> STABS. >>>>>> - Compilation on 32-bit Linux can make use of precompiled headers. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00/ >>>>>> >>>>>> Testing: >>>>>> - Compiling with GCC 4.3.4, GCC 4.7.3 and GCC 4.8.1 >>>>>> - JPRT >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>>>>> [0]: https://sourceware.org/ml/binutils/2013-01/msg00028.html >>>>> >>> From stefan.karlsson at oracle.com Tue Apr 1 06:40:04 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 01 Apr 2014 08:40:04 +0200 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <533A5681.20607@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap> <533A5681.20607@oracle.com> Message-ID: <533A5F44.2000308@oracle.com> On 2014-04-01 08:02, David Holmes wrote: > Hi Goetz, > > Not a review ... > > On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> could I please get reviews for this change? I please also need a >> sponsor. >> I would like to get this into 8u20, as 8036330 was downported, too. >> >> I'd like to make the point of this change clear once more, independent >> of which compiler does what. >> >> I think we agree that basically >> - a file should include all headers that define symbols or include >> method bodies used in that file > > Personally I don't see why a cpp file should have to be aware that a > member function it uses just happens to have been defined in an > inline.hpp file by its author. Seems to break encapsulation to me. :( Yes, it's unfortunate, but necessary to prevent problems like circular dependencies. If we don't follow it, we not only risk breaking the code with the offending patch, but future patches might be harder to create because of the transitive closure of include files that is introduced by including the .inline.hpp file. > >> - a .hpp header should not include a .inline.hpp header > > I see 277 occurrences of this in the existing OpenJDK hotspot code, so > I don't think we can take this as a general rule either. > > Note I'm not saying this fix isn't right or needed, just that the > "rules" you are trying to embody don't seem to generally apply. This is a rule I try hard to enforce when reviewing changes. If you don't follow it we'll end up with problems like this. I think it's worth adding to: https://wiki.openjdk.java.net/display/HotSpot/StyleGuide thanks, StefanK > > David > ----- > >> This is violated >> >> 1.) by defining >> template void immediate_rs_update(HeapRegion* from, T* p, >> int tid) { >> if (!from->is_survivor()) { >> _g1_rem->par_write_ref(from, p, tid); >> } >> } >> in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and >> only defined in >> g1RemSet.inline.hpp - which is not included and should not be >> included >> in g1CollectedHeap.hpp. >> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp >> >> This change fixes these two points by moving functions into >> .inline.hpp files >> and fixing the include. >> >> Best regards, >> Goetz. >> >> >> >> >> From: Lindenmaier, Goetz >> Sent: Donnerstag, 27. M?rz 2014 17:46 >> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 >> >> Hi, >> >> Please review and test this change. I please need a sponsor: >> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ >> >> Change 8035330: Remove G1ParScanPartialArrayClosure and >> G1ParScanHeapEvacClosure >> broke the dbg build on AIX. That's because do_oop_partial_array() is >> added in >> a header, but requires inline function par_write_ref() through >> several inlined >> calls. In some cpp files, like arguments.cpp, par_write_ref() is not >> defined >> as the corresponding inline header is not included. The aix debug VM >> does not start. >> >> This can be solved by including g1RemSet.inline.hpp in >> g1CollectedHeap.inline.hpp. >> >> Unfortunately this now causes a cyclic dependency that breaks the >> linux build. >> A inline.hpp file is included ahead of a .hpp file, so that the code >> in the inline.hpp file >> can not see the class declaration. >> This is caused because g1CollectedHeap.inline.hpp is included in >> sparsePRT.hpp. >> But .inline.hpp files never should be included in .hpp files. >> >> To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As >> consequence, >> I had to move a row of functions to existing .inline.hpp files. >> >> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, >> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. >> >> Best regards, >> Goetz >> From goetz.lindenmaier at sap.com Tue Apr 1 07:30:17 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Apr 2014 07:30:17 +0000 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <533A5681.20607@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap> <533A5681.20607@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap> Hi David, > Personally I don't see why a cpp file should have to be aware that a > member function it uses just happens to have been defined in an > inline.hpp file by its author. Seems to break encapsulation to me. :( Because the .cpp file will not compile if the .inline.hpp header with the implementation is not visible during compilation. > I see 277 occurrences of this in the existing OpenJDK hotspot code, so I There are a lot of .hpp files with include methods that don't have a corresponding .inline.hpp file. Like taskqueue.hpp, which includes the atomic headers. Would be nice if this was cleaned up. Also, oop.inline.hpp often makes problems, because methods defined there are used in .hpp files, which can not include oop.inline.hpp as it causes cycles. If you include that header in a cpp file, you also have to include oop.inline.hpp, which is really unintuitive. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 1. April 2014 08:03 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330 Hi Goetz, Not a review ... On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote: > Hi, > > could I please get reviews for this change? I please also need a sponsor. > I would like to get this into 8u20, as 8036330 was downported, too. > > I'd like to make the point of this change clear once more, independent > of which compiler does what. > > I think we agree that basically > - a file should include all headers that define symbols or include > method bodies used in that file Personally I don't see why a cpp file should have to be aware that a member function it uses just happens to have been defined in an inline.hpp file by its author. Seems to break encapsulation to me. :( > - a .hpp header should not include a .inline.hpp header I see 277 occurrences of this in the existing OpenJDK hotspot code, so I don't think we can take this as a general rule either. Note I'm not saying this fix isn't right or needed, just that the "rules" you are trying to embody don't seem to generally apply. David ----- > This is violated > > 1.) by defining > template void immediate_rs_update(HeapRegion* from, T* p, int tid) { > if (!from->is_survivor()) { > _g1_rem->par_write_ref(from, p, tid); > } > } > in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only defined in > g1RemSet.inline.hpp - which is not included and should not be included > in g1CollectedHeap.hpp. > 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp > > This change fixes these two points by moving functions into .inline.hpp files > and fixing the include. > > Best regards, > Goetz. > > > > > From: Lindenmaier, Goetz > Sent: Donnerstag, 27. M?rz 2014 17:46 > To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 > > Hi, > > Please review and test this change. I please need a sponsor: > http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ > > Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure > broke the dbg build on AIX. That's because do_oop_partial_array() is added in > a header, but requires inline function par_write_ref() through several inlined > calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined > as the corresponding inline header is not included. The aix debug VM does not start. > > This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp. > > Unfortunately this now causes a cyclic dependency that breaks the linux build. > A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file > can not see the class declaration. > This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp. > But .inline.hpp files never should be included in .hpp files. > > To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As consequence, > I had to move a row of functions to existing .inline.hpp files. > > I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, > sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. > > Best regards, > Goetz > From david.holmes at oracle.com Tue Apr 1 07:36:11 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 01 Apr 2014 17:36:11 +1000 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap> <533A5681.20607@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap> Message-ID: <533A6C6B.6090203@oracle.com> On 1/04/2014 5:30 PM, Lindenmaier, Goetz wrote: > Hi David, > >> Personally I don't see why a cpp file should have to be aware that a >> member function it uses just happens to have been defined in an >> inline.hpp file by its author. Seems to break encapsulation to me. :( > Because the .cpp file will not compile if the .inline.hpp header with > the implementation is not visible during compilation. Understood - but there is more than one way to make the implementation visible to the cpp file eg cpp include .hpp and .hpp includes .inline.hpp (I suppose that is a "bad" thing to do?) And that still doesn't change the fact it is breaking encapsulation :) >> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I > There are a lot of .hpp files with include methods that don't have > a corresponding .inline.hpp file. Like taskqueue.hpp, which includes > the atomic headers. Would be nice if this was cleaned up. > Also, oop.inline.hpp often makes problems, because methods defined > there are used in .hpp files, which can not include oop.inline.hpp > as it causes cycles. If you include that header in a cpp file, you also have > to include oop.inline.hpp, which is really unintuitive. I find the inline situation to be unintuitive in general. There's a flow on affect that an inline function can't use other inline functions unless they all get moved to .inline.hpp files. I hope it is okay for one .inline.hpp file to include another one? Otherwise you have to expose the internal implementation detail of one class to its clients so they know which set of .inline.hpp files have to be included! Cheers, David > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 1. April 2014 08:03 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330 > > Hi Goetz, > > Not a review ... > > On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> could I please get reviews for this change? I please also need a sponsor. >> I would like to get this into 8u20, as 8036330 was downported, too. >> >> I'd like to make the point of this change clear once more, independent >> of which compiler does what. >> >> I think we agree that basically >> - a file should include all headers that define symbols or include >> method bodies used in that file > > Personally I don't see why a cpp file should have to be aware that a > member function it uses just happens to have been defined in an > inline.hpp file by its author. Seems to break encapsulation to me. :( > >> - a .hpp header should not include a .inline.hpp header > > I see 277 occurrences of this in the existing OpenJDK hotspot code, so I > don't think we can take this as a general rule either. > > Note I'm not saying this fix isn't right or needed, just that the > "rules" you are trying to embody don't seem to generally apply. > > David > ----- > >> This is violated >> >> 1.) by defining >> template void immediate_rs_update(HeapRegion* from, T* p, int tid) { >> if (!from->is_survivor()) { >> _g1_rem->par_write_ref(from, p, tid); >> } >> } >> in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only defined in >> g1RemSet.inline.hpp - which is not included and should not be included >> in g1CollectedHeap.hpp. >> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp >> >> This change fixes these two points by moving functions into .inline.hpp files >> and fixing the include. >> >> Best regards, >> Goetz. >> >> >> >> >> From: Lindenmaier, Goetz >> Sent: Donnerstag, 27. M?rz 2014 17:46 >> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 >> >> Hi, >> >> Please review and test this change. I please need a sponsor: >> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ >> >> Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure >> broke the dbg build on AIX. That's because do_oop_partial_array() is added in >> a header, but requires inline function par_write_ref() through several inlined >> calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined >> as the corresponding inline header is not included. The aix debug VM does not start. >> >> This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp. >> >> Unfortunately this now causes a cyclic dependency that breaks the linux build. >> A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file >> can not see the class declaration. >> This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp. >> But .inline.hpp files never should be included in .hpp files. >> >> To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As consequence, >> I had to move a row of functions to existing .inline.hpp files. >> >> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, >> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. >> >> Best regards, >> Goetz >> From goetz.lindenmaier at sap.com Tue Apr 1 08:04:48 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Apr 2014 08:04:48 +0000 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <533A6C6B.6090203@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap> <533A5681.20607@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap> <533A6C6B.6090203@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEABFE1@DEWDFEMB12A.global.corp.sap> Hi David, Well, the only reason for .inline.hpp files is to break include cycles. If you include them in the corresponding .hpp files, you reintroduce the cycles. If you want encapsulation, don't use inline methods. > There's a flow > on affect that an inline function can't use other inline functions > unless they all get moved to .inline.hpp files. That's exactly the rule that should be enforced. Yes, .inline.hpp files may include .inline.hpp files. That will not cause cycles. This way .hpp files will all be placed in the beginning of a (preprocessed) cpp file, then the .include.hpp files and last the code of the .cpp file. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 1. April 2014 09:36 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330 On 1/04/2014 5:30 PM, Lindenmaier, Goetz wrote: > Hi David, > >> Personally I don't see why a cpp file should have to be aware that a >> member function it uses just happens to have been defined in an >> inline.hpp file by its author. Seems to break encapsulation to me. :( > Because the .cpp file will not compile if the .inline.hpp header with > the implementation is not visible during compilation. Understood - but there is more than one way to make the implementation visible to the cpp file eg cpp include .hpp and .hpp includes .inline.hpp (I suppose that is a "bad" thing to do?) And that still doesn't change the fact it is breaking encapsulation :) >> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I > There are a lot of .hpp files with include methods that don't have > a corresponding .inline.hpp file. Like taskqueue.hpp, which includes > the atomic headers. Would be nice if this was cleaned up. > Also, oop.inline.hpp often makes problems, because methods defined > there are used in .hpp files, which can not include oop.inline.hpp > as it causes cycles. If you include that header in a cpp file, you also have > to include oop.inline.hpp, which is really unintuitive. I find the inline situation to be unintuitive in general. There's a flow on affect that an inline function can't use other inline functions unless they all get moved to .inline.hpp files. I hope it is okay for one .inline.hpp file to include another one? Otherwise you have to expose the internal implementation detail of one class to its clients so they know which set of .inline.hpp files have to be included! Cheers, David > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 1. April 2014 08:03 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330 > > Hi Goetz, > > Not a review ... > > On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> could I please get reviews for this change? I please also need a sponsor. >> I would like to get this into 8u20, as 8036330 was downported, too. >> >> I'd like to make the point of this change clear once more, independent >> of which compiler does what. >> >> I think we agree that basically >> - a file should include all headers that define symbols or include >> method bodies used in that file > > Personally I don't see why a cpp file should have to be aware that a > member function it uses just happens to have been defined in an > inline.hpp file by its author. Seems to break encapsulation to me. :( > >> - a .hpp header should not include a .inline.hpp header > > I see 277 occurrences of this in the existing OpenJDK hotspot code, so I > don't think we can take this as a general rule either. > > Note I'm not saying this fix isn't right or needed, just that the > "rules" you are trying to embody don't seem to generally apply. > > David > ----- > >> This is violated >> >> 1.) by defining >> template void immediate_rs_update(HeapRegion* from, T* p, int tid) { >> if (!from->is_survivor()) { >> _g1_rem->par_write_ref(from, p, tid); >> } >> } >> in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only defined in >> g1RemSet.inline.hpp - which is not included and should not be included >> in g1CollectedHeap.hpp. >> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp >> >> This change fixes these two points by moving functions into .inline.hpp files >> and fixing the include. >> >> Best regards, >> Goetz. >> >> >> >> >> From: Lindenmaier, Goetz >> Sent: Donnerstag, 27. M?rz 2014 17:46 >> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 >> >> Hi, >> >> Please review and test this change. I please need a sponsor: >> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ >> >> Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure >> broke the dbg build on AIX. That's because do_oop_partial_array() is added in >> a header, but requires inline function par_write_ref() through several inlined >> calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined >> as the corresponding inline header is not included. The aix debug VM does not start. >> >> This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp. >> >> Unfortunately this now causes a cyclic dependency that breaks the linux build. >> A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file >> can not see the class declaration. >> This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp. >> But .inline.hpp files never should be included in .hpp files. >> >> To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As consequence, >> I had to move a row of functions to existing .inline.hpp files. >> >> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, >> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. >> >> Best regards, >> Goetz >> From erik.helin at oracle.com Tue Apr 1 08:17:52 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 01 Apr 2014 10:17:52 +0200 Subject: RFR: 8033251: Use DWARF debug symbols for Linux 32-bit as default In-Reply-To: <533A5F01.3060200@oracle.com> References: <53359F78.6070503@oracle.com> <5335A38E.6040406@oracle.com> <5335A6F3.7010300@oracle.com> <5335BECD.9050808@oracle.com> <53364F7A.1020903@oracle.com> <53395F6E.4030505@oracle.com> <533A5F01.3060200@oracle.com> Message-ID: <533A7630.4040600@oracle.com> On 2014-04-01 08:38, David Holmes wrote: > Hi Erik, > > On 31/03/2014 10:28 PM, Erik Helin wrote: >> Hi David, >> >> thanks for having a look! Please see my reply inline. > > Thanks for the additional cleanup! > > Looks good. Thanks! Erik > David > > >> On 2014-03-29 05:43, David Holmes wrote: >>> On 29/03/2014 4:26 AM, Coleen Phillimore wrote: >>>> >>>> On 3/28/14 12:44 PM, Erik Helin wrote: >>>>> Hi Coleen, >>>>> >>>>> thanks for having a look at the patch! >>>>> >>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>> >>>>>> I thought you'd be able to remove the DEBUG_BINARIES logic with this >>>>>> change. It appears there are no platforms left that use stabs with >>>>>> gcc. >>>>> >>>>> Yeah, I also noticed that this change enables cleanups in the >>>>> Makefiles. However, I think it is better to do these cleanups as a >>>>> second change after this one, what do you think? >>>> >>>> A cleanup CR is fine. >>> >>> Unless the cleanup is coming "tomorrow" I disagree. What have now is >>> comments that make no sense given the change that has been made. And as >>> every defined platform seems to use -g we can get rid of all this >>> per-platform logic and simply check for clang. All of which can be done >>> without doing the DEBUG_BINARIES cleanup. Eg delete the per-platform >>> flags and simply have, for example, >>> >>> # Override per-platform if the default -g doesn't suite >>> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH)) >>> ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) >>> ifeq ($(USE_CLANG), true) >>> # Clang doesn't understand -gstabs >>> OPT_CFLAGS += -g >>> else >>> OPT_CFLAGS += -gstabs >>> endif >>> endif >> >> I wanted this change to only be about changing from STABS to DWARF, but >> based on your feedback I cleaned up some code in the makefile as well: >> >> - Incremental webrev: >> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00-01/ >> - New webrev: >> http://cr.openjdk.java.net/~ehelin/8033251/webrev.01/ >> >> The default is now to use DWARF for all platforms, but this can be >> changed by using CFLAGS, for example FASTDEBUG_CFLAGS/amd64=-gstabs will >> give you STABS debug symbols for a fastdebug build on 64-bit Linux. >> Having -g as default also enables us to get rid of all the $(USE_CLANG) >> checks. >> >> The new patch also fixes a small bug where FASTDEBUG_CFLAGS was set to >> $(DEBUG_CFLAGS/$(BUILDARCH)), it should be set to >> $(FASTDEBUG_CFLAGS/$(BUILDARCH)). >> >> Testing of new patch: >> - JPRT >> - Building builds for different targets with different debug symbols >> locally. >> >> Thanks, >> Erik >> >>> In the future this flag should also potentially be coming in via >>> spec.gmk. >>> >>> David >>> >>>>> >>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>> Does this change add -g for saproc, adlc and jsig compilations also? >>>>> It seems like saproc uses SA_DEBUG_CFLAGS which only is being set if >>>>> DEBUG_BINARIES=true. If DEBUG_BINARIES is not true, then it seems like >>>>> we don't generate debug symbols (please correct me if I'm wrong). >>>>> >>>>> The above also seems to be the case for libjsig.so. >>>>> >>>> >>>> These seem broken, but I don't know the makefiles well enough to >>>> comment. >>>> >>>> I think this change is good. People have been asking for it for years >>>> and now that the size problem with dwarf has been fixed, I'm glad you >>>> are making this change. >>>> >>>> Thanks, >>>> Coleen >>>>> Looking in make/linux/makefiles/adlc.make it seems like adlc is using >>>>> -g for GCC 3.3 or newer. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>>> Coleen >>>>>> >>>>>> On 3/28/14 12:12 PM, Erik Helin wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> this patch changes the Linux Makefiles to use DWARF as the default >>>>>>> debug symbol format for Linux 32-bit instead of STABS. The main >>>>>>> arguments for using DWARF are: >>>>>>> >>>>>>> - DWARF provides a superior debugging experience compared to >>>>>>> STABS. >>>>>>> - STABS support in GCC/GDB is in maintenance mode [0]. >>>>>>> - External tools (e.g. perf on Linux) often understands DWARF but >>>>>>> not >>>>>>> STABS. >>>>>>> - Compilation on 32-bit Linux can make use of precompiled headers. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00/ >>>>>>> >>>>>>> Testing: >>>>>>> - Compiling with GCC 4.3.4, GCC 4.7.3 and GCC 4.8.1 >>>>>>> - JPRT >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>>>> >>>>>>> [0]: https://sourceware.org/ml/binutils/2013-01/msg00028.html >>>>>> >>>> From erik.helin at oracle.com Tue Apr 1 08:32:37 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 01 Apr 2014 10:32:37 +0200 Subject: RFR 8028497: SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool) In-Reply-To: <533A32C3.3090002@oracle.com> References: <5331EA20.6000001@oracle.com> <5332FF22.4010900@oracle.com> <5333438B.8090508@oracle.com> <53338653.6060500@oracle.com> <53341BF7.6060309@oracle.com> <53343DFC.9000904@oracle.com> <53345BD5.5020806@oracle.com> <533A32C3.3090002@oracle.com> Message-ID: <533A79A5.6050307@oracle.com> On 2014-04-01 05:30, Coleen Phillimore wrote: > > Erik, > > You are right. The old code would use the Klass->mirror link to clear > out the mirror->Klass link so that we didn't have a pointer to a > deallocated Klass in a mirror that might still be live for CMS marking. > The new code doesn't set the Klass->mirror link unless the mirror fields > are completely allocated, so we could crash if we deallocated a Klass > before the mirror because the mirror would still be pointing to the class. > > I've caught failed allocation in mirror fields so that the link is reset > in this change. The only change is to the function create_mirror calls > initialize_mirror_fields. > > open webrev at http://cr.openjdk.java.net/~coleenp/8028497_3/ In javaClasses.cpp: void java_lang_Class::create_mirror(KlassHandle k, Handle, TRAPS) { ... initialize_mirror_fields(k, mirror, protection_domain, THREAD); if (HAS_PENDING_EXCEPTION) { // If any of the fields throws an exception like OOM remove the // klass field from the mirror so GC doesn't follow it after the // klass has been deallocated. java_lang_Class::set_klass(mirror(), k()); return; ^ } | | +------------------------------------------+ | +-- Do you really want to use k() here? I thought the idea was to do: java_lang_Class::set_klass(mirror(), NULL); Setting the Klass that the mirror is mirroring will hit the following check in instanceMirrorKlass.cpp, oop_oop_iterate macro: int InstanceMirrorKlass::oop_oop_iterate##nv_suffix(...) { \ ... \ if_do_metadata_checked(closure, nv_suffix) { \ Klass* klass = java_lang_Class::as_Klass(obj); \ /* We'll get NULL for primitive mirrors. */ \ if (klass != NULL) { \ closure->do_klass##nv_suffix(klass); \ } \ } Setting the Klass that the mirror is mirroring to NULL will make the mirror look like a primitive mirror (this is the way we encode primitive mirrors). Will that be a problem? Thanks, Erik > Tested with vm.parallel_class_loading.testlist which do hit this case. > > Thanks! > Coleen > > > On 3/27/14 1:11 PM, Erik Helin wrote: >> Hi Coleen, >> >> thanks for taking on this tricky bug! However, I think there is an >> issue with your fix :( >> >> This case is for "normal" (non-CDS) class loading: >> 1. We create the mirror >> 2. We set up the link from the mirror to the Klass >> 3. We fail somewhere before setting the link from the Klass to the >> mirror, for example when allocating the Java object for the init >> lock. >> 4. The destructor for ClassFileParser is run and we add the Klass to the >> deallocate list. >> 5. A CMS concurrent cycle is started, it will treat all objects in eden >> + the survivor area as roots (including the mirror). >> 6. The above concurrent cycle enters the "final remark" phase and does >> class unloading which will call free_deallocate_list() which will >> return the memory for the Klass added to the deallocate list in step >> 4 to Metaspace. >> 7. The concurrent CMS cycle ends (the mirror is still in eden or young) >> 8. A new concurrent CMS cycle is started, the mirror will once again be >> treated as a root since it is still in eden or young (no YC has been >> done). >> 9. During the initial marking, CMS will now follow the pointer to the >> Klass that the mirror is mirroring, but we returned this memory to >> Metaspace in step 6. >> 10. We now crash :( >> >> Unfortunately, I don't have any suggestion on how to solve the above >> scenario at the moment. >> >> Thanks, >> Erik >> >> On 2014-03-27 16:04, Coleen Phillimore wrote: >>> >>> On 3/27/14 8:39 AM, Stefan Karlsson wrote: >>>> >>>> On 2014-03-27 03:00, Coleen Phillimore wrote: >>>>> >>>>> I have a new version of this change based on code that Ioi noticed >>>>> that I was missing for making restoring the method's adapters >>>>> restartable if something fails during restore_unshareable_info, and >>>>> the constant pool resolved references array. >>>>> Please review this new code (only method.* and instanceKlass.cpp and >>>>> constantPool.cpp have differences). Reran tests with CDS and CMS. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8028497_2/ >>>> >>>> This seems good. I'd prefer if someone with more experience with CDS >>>> also Reviews the change. >>> >>> Thanks, Ioi said he'd look at it. >>> >>>> >>>> Small comment: >>>> >>>> http://cr.openjdk.java.net/~coleenp/8028497_2/src/share/vm/oops/instanceKlass.cpp.udiff.html >>>> >>>> >>>> >>>> - methodHandle m(THREAD, methods->at(index2)); >>>> - m()->link_method(m, CHECK); >>>> - // restore method's vtable by calling a virtual function >>>> - m->restore_vtable(); >>>> + Method *m = methods->at(index2); >>>> + m->restore_unshareable_info(CHECK); >>>> >>>> >>>> Do we really want to use a raw Method * here. I know that we wrap the >>>> method in a handle inside m->restore_unshareable_info, but it's not >>>> clear from the this context. I'm thinking about this issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8004815 >>>> >>>> On the other hand, I guess we can't redefine a class before it has >>>> been defined. But maybe it would be good to not promote the usage of >>>> Method* over calls that might hit a Safepoint. >>>> >>> >>> I think you're right, we don't use 'm' after the potential safepoint and >>> we can't really redefine this class yet anyway but I'll restore the code >>> because we don't want to encourage uses of unhandled Methods unless >>> proven to be harmless. >>> >>> Thanks! >>> Coleen >>>> thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 3/26/14 5:15 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi Jon, >>>>>> Thank you for looking at the code changes. >>>>>> >>>>>> On 3/26/14 12:24 PM, Jon Masamitsu wrote: >>>>>>> Coleen, >>>>>>> >>>>>>> Did you remove Class_obj_allocate() because it was only >>>>>>> called in that one spot and use obj_allocate() did most >>>>>>> of the work? >>>>>> >>>>>> I deleted it because GC doesn't need to know how these javaClasses >>>>>> are set up and I spent way to long looking for this code and didn't >>>>>> find it where it belongs, so I removed this. This Class_obj_allocate >>>>>> is an artifact of the permgen code. >>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/instanceMirrorKlass.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> 373 // the size in the mirror size itself. >>>>>>> >>>>>>> Drop the second "size". You know how we GC guys are >>>>>>> getting with our comments :-). >>>>>> >>>>>> Yes, I noticed that. Thanks - fixed. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/klass.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> 498 void Klass::restore_unshareable_info(TRAPS) { >>>>>>> 499 // If an exception happened during CDS restore, some of >>>>>>> these fields may already be >>>>>>> 500 // set. We leave the class on the CLD list, even if >>>>>>> incomplete so that we don't >>>>>>> 501 // modify the CLD list outside a safepoint. >>>>>>> 502 if (class_loader_data() == NULL) { >>>>>>> 503 ClassLoaderData* loader_data = >>>>>>> ClassLoaderData::the_null_class_loader_data(); >>>>>>> >>>>>>> I can see that this works with the current CDS (sharing only >>>>>>> classes loader >>>>>>> with the NULL class loader). Will it work if the shared classes >>>>>>> are loaded >>>>>>> with an application class loader? >>>>>> >>>>>> I hope Ioi can answer that. I assume so because the classes don't >>>>>> change class loaders if restoring shareable info fails. >>>>>> >>>>>> Ioi pointed out to me (not on open list) that I missed making >>>>>> link_method() and creating the constant pool resolved references >>>>>> array restartable, so I'm testing a fix for that also and I'll post >>>>>> an update later. But you've seen most of it. >>>>>> >>>>>> Thanks!! >>>>>> Coleen >>>>>>> >>>>>>> Rest looks good. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On 3/25/2014 1:42 PM, Coleen Phillimore wrote: >>>>>>>> Summary: Keep class in CLD::_klasses list and mirror created for >>>>>>>> CDS classes if OOM during restore_shareable_info(). This keeps >>>>>>>> pointers consistent for CMS. >>>>>>>> >>>>>>>> This change makes restoring the mirror for shared classes >>>>>>>> restartable if there is an OOM in the middle of >>>>>>>> restore_unshareable_info. The mirror field in the classes and >>>>>>>> CLD link is not cleaned up anymore. The class isn't marked loaded >>>>>>>> though so must be loaded again. >>>>>>>> >>>>>>>> Tested with Stefan's test case with hard coded OOM in jvm, so >>>>>>>> can't add the test. Also ran all the tests against -client and >>>>>>>> server with -Xshare:auto and with -XX:+UseConcMarkSweepGC. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8028497/ >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8028497 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>> >>>>>> >>>>> >>>> >>> > From stefan.karlsson at oracle.com Tue Apr 1 08:34:22 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 01 Apr 2014 10:34:22 +0200 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap> Message-ID: <533A7A0E.5040100@oracle.com> Hi Goetz, Thanks for fixing this! One comment below: On 2014-03-27 17:45, Lindenmaier, Goetz wrote: > > Hi, > > Please review and test this change. I please need a sponsor: > > http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ > > http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html I'm not sure what the performance implication is of moving these functions to the .cpp file. Is there a reason why we wouldn't want to put them in the g1CollectedHeap.inline.hpp file? thanks, StefanK > Change 8035330: Remove G1ParScanPartialArrayClosure and > G1ParScanHeapEvacClosure > > broke the dbg build on AIX. That's because do_oop_partial_array() is > added in > > a header, but requires inline function par_write_ref() through several > inlined > > calls. In some cpp files, like arguments.cpp, par_write_ref() is not > defined > > as the corresponding inline header is not included. The aix debug VM > does not start. > > This can be solved by including g1RemSet.inline.hpp in > g1CollectedHeap.inline.hpp. > > Unfortunately this now causes a cyclic dependency that breaks the > linux build. > > A inline.hpp file is included ahead of a .hpp file, so that the code > in the inline.hpp file > > can not see the class declaration. > > This is caused because g1CollectedHeap.inline.hpp is included in > sparsePRT.hpp. > > But .inline.hpp files never should be included in .hpp files. > > To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As > consequence, > > I had to move a row of functions to existing .inline.hpp files. > > I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, > > sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. > > Best regards, > > Goetz > From igor.ignatyev at oracle.com Tue Apr 1 09:38:52 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 01 Apr 2014 13:38:52 +0400 Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag In-Reply-To: <53388795.9070005@oracle.com> References: <53388795.9070005@oracle.com> Message-ID: <533A892C.2090208@oracle.com> adding hotspot-dev alias. On 03/31/2014 01:07 AM, Igor Ignatyev wrote: > Hi all, > > Please review the patch which introduces new WhiteBox methods to get and > set VM flags. > > webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8038756 > testing: jprt From goetz.lindenmaier at sap.com Tue Apr 1 09:53:36 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Apr 2014 09:53:36 +0000 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <533A7A0E.5040100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap> <533A7A0E.5040100@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap> Hi Stefan, thanks for pointing me to that. I think I did that to break the chain at some point. But I only need to move two more functions so that all is in the .inline file: http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.01/ Best regards, Goetz. From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] Sent: Dienstag, 1. April 2014 10:34 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330 Hi Goetz, Thanks for fixing this! One comment below: On 2014-03-27 17:45, Lindenmaier, Goetz wrote: Hi, Please review and test this change. I please need a sponsor: http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html I'm not sure what the performance implication is of moving these functions to the .cpp file. Is there a reason why we wouldn't want to put them in the g1CollectedHeap.inline.hpp file? thanks, StefanK Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure broke the dbg build on AIX. That's because do_oop_partial_array() is added in a header, but requires inline function par_write_ref() through several inlined calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined as the corresponding inline header is not included. The aix debug VM does not start. This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp. Unfortunately this now causes a cyclic dependency that breaks the linux build. A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file can not see the class declaration. This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp. But .inline.hpp files never should be included in .hpp files. To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As consequence, I had to move a row of functions to existing .inline.hpp files. I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. Best regards, Goetz From stefan.karlsson at oracle.com Tue Apr 1 10:07:20 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 01 Apr 2014 12:07:20 +0200 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap> <533A7A0E.5040100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap> Message-ID: <533A8FD8.3090400@oracle.com> Hi Goetz, On 2014-04-01 11:53, Lindenmaier, Goetz wrote: > > Hi Stefan, > > thanks for pointing me to that. > > I think I did that to break the chain at some point. > > But I only need to move two more functions so that all is > > in the .inline file: > > http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.01/ > > I see that you had to move the two G1CollectedHeap::is_obj_dead_cond functions out of g1CollectedHeap.hpp. I don't think they have to be inline functions, since they are only used by the verification code. Would you mind moving them to the g1CollectedHeap.cpp instead? Other than that, I think the patch looks good. thanks! StefanK > Best regards, > > Goetz. > > *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] > *Sent:* Dienstag, 1. April 2014 10:34 > *To:* Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; > hotspot-gc-dev at openjdk.java.net > *Subject:* Re: RFR(M): 8038498: Fix includes and C inlining after 8035330 > > Hi Goetz, > > Thanks for fixing this! > > One comment below: > > On 2014-03-27 17:45, Lindenmaier, Goetz wrote: > > Hi, > > Please review and test this change. I please need a sponsor: > > http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ > > > > http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html > > > I'm not sure what the performance implication is of moving these > functions to the .cpp file. Is there a reason why we wouldn't want to > put them in the g1CollectedHeap.inline.hpp file? > > thanks, > StefanK > > > Change 8035330: Remove G1ParScanPartialArrayClosure and > G1ParScanHeapEvacClosure > > broke the dbg build on AIX. That's because do_oop_partial_array() is > added in > > a header, but requires inline function par_write_ref() through several > inlined > > calls. In some cpp files, like arguments.cpp, par_write_ref() is not > defined > > as the corresponding inline header is not included. The aix debug VM > does not start. > > This can be solved by including g1RemSet.inline.hpp in > g1CollectedHeap.inline.hpp. > > Unfortunately this now causes a cyclic dependency that breaks the > linux build. > > A inline.hpp file is included ahead of a .hpp file, so that the code > in the inline.hpp file > > can not see the class declaration. > > This is caused because g1CollectedHeap.inline.hpp is included in > sparsePRT.hpp. > > But .inline.hpp files never should be included in .hpp files. > > To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As > consequence, > > I had to move a row of functions to existing .inline.hpp files. > > I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, > > sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. > > Best regards, > > Goetz > From goetz.lindenmaier at sap.com Tue Apr 1 10:24:23 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Apr 2014 10:24:23 +0000 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <533A8FD8.3090400@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap> <533A7A0E.5040100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap> <533A8FD8.3090400@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAC0A6@DEWDFEMB12A.global.corp.sap> Sure! I updated the webrev accordingly. Best regards, Goetz. From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] Sent: Dienstag, 1. April 2014 12:07 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330 Hi Goetz, On 2014-04-01 11:53, Lindenmaier, Goetz wrote: Hi Stefan, thanks for pointing me to that. I think I did that to break the chain at some point. But I only need to move two more functions so that all is in the .inline file: http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.01/ I see that you had to move the two G1CollectedHeap::is_obj_dead_cond functions out of g1CollectedHeap.hpp. I don't think they have to be inline functions, since they are only used by the verification code. Would you mind moving them to the g1CollectedHeap.cpp instead? Other than that, I think the patch looks good. thanks! StefanK Best regards, Goetz. From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] Sent: Dienstag, 1. April 2014 10:34 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330 Hi Goetz, Thanks for fixing this! One comment below: On 2014-03-27 17:45, Lindenmaier, Goetz wrote: Hi, Please review and test this change. I please need a sponsor: http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html I'm not sure what the performance implication is of moving these functions to the .cpp file. Is there a reason why we wouldn't want to put them in the g1CollectedHeap.inline.hpp file? thanks, StefanK Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure broke the dbg build on AIX. That's because do_oop_partial_array() is added in a header, but requires inline function par_write_ref() through several inlined calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined as the corresponding inline header is not included. The aix debug VM does not start. This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp. Unfortunately this now causes a cyclic dependency that breaks the linux build. A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file can not see the class declaration. This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp. But .inline.hpp files never should be included in .hpp files. To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As consequence, I had to move a row of functions to existing .inline.hpp files. I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. Best regards, Goetz From vladimir.x.ivanov at oracle.com Tue Apr 1 10:38:27 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 01 Apr 2014 14:38:27 +0400 Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag In-Reply-To: <533A892C.2090208@oracle.com> References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com> Message-ID: <533A9723.4080301@oracle.com> Igor, Why don't you add a method for querying flag type as well? Best regards, Vladimir Ivanov On 4/1/14 1:38 PM, Igor Ignatyev wrote: > adding hotspot-dev alias. > > On 03/31/2014 01:07 AM, Igor Ignatyev wrote: >> Hi all, >> >> Please review the patch which introduces new WhiteBox methods to get and >> set VM flags. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756 >> testing: jprt From volker.simonis at gmail.com Tue Apr 1 11:10:45 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 1 Apr 2014 13:10:45 +0200 Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 In-Reply-To: <533A6C6B.6090203@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap> <533A5681.20607@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap> <533A6C6B.6090203@oracle.com> Message-ID: In C/C++ we have the fundamental problem that, as far as defined by the standard, the compiler can only 'see' the things which are defined in its current compilation unit where a compilation unit is defined by a .cpp file together with all the files it includes. That is exactly the reason why you should not declare a function 'F' as "inline" in a header file (say "f.h") but define it in a .cpp file (say "f.cpp"). This will make it impossible for a compiler to really inline "F" in another compilation unit (say "g.cpp") which includes "f.hpp" (but of course not "g.cpp"). One simple solution to overcome this problem is to not only declare but to also define inline functions directly in their corresponding header files. Unfortunately this only works for very small examples. Once your program gets bigger, you'll get cyclic dependencies between such header files. And that's actually clear, because defining functions in a header file breaks the contract that header files should contain interface declarations while .cpp files contain the actual definitions (i.e. implementations). So the next step (and the solution used in HotSpot) is to restrict oneself to declarations in header files and place definitions which are needed in more than one compilation unit into so called ".inline.hpp" files. These ".inline.hpp" include their corresponding ".hpp" files by default (because they actually implement something which is declared in there - so they need access to it). On the other hand, every compilation unit which requires a definition/implementation of a class or function (and not only its declaration) can now include that ".inline.hpp" file. And they don't need to include the corresponding ".hpp" file, because the ".inline.hpp" already did that. All that is the ideal world which would work perfectly fine. Unfortunately, not all of the current HotSpot code adheres to these conventions. The usual mistake people make is to define a very simple inline function right in the header file (i.e. ".hpp") because it is so simple and has no dependencies at all. But as time goes by, that function grows, becomes more complicated and requires more and more dependencies (i.e. ".inline.hpp" files). But instead of refactoring such functions into their own ".inline.hpp" files, the ingenious programmer naively includes the ".inline.hpp" file into the header. And that's where it starts to get ugly! All that said, there are a few things which influence the situation. The first one is "precompiled headers". Precompiled headers are a compiler hack which is not specified by the C/C++ standard and which is implemented differently by different compilers with the only only goal to speed up the compilation of a compilation unit. To achieve this goal the compiler assumes that many compilation units contain a lot of common code and therefore he "widens" the actual definition of a "compilation unit" a little bit. With precompiled headers, the compiler can see beyond its actual compilation unit because he sees all the declarations and definitions from the precompiled header file (or database or whatever) and not only the ones which are actually transitively included by the current ".cpp" file. That's exactly the reason why you don't realize missing dependencies if you only compile with precompiled headers turned on (and why it is crucial to have a sanity build without precompiled headers). And there's yet another aspect to this: C++ templates. With templates you have exactly the same problem like with inline functions - they are declared in a header file, but their definition is potentially required in several compilation units (actually everywhere they get instantiated at). Now as long as the template functions are simple, they can be defined right in their header files. But we will get very fast to the point where the template definitions get more complicated and where they would introduce cycles in the header files. Because templates where specified later then the "inline mechanism" and the designers were aware of the problem, they tried to somehow address this within the language for examle with the "export" keyword. Unfortunately this was not very successful and has meanwhile been deprecated. As a consequence, a lot of techniques have been developed to overcome these issues: put all template definitions into the headers -> may lead to code bloat, use special template instantiation files -> clumsy, compiler specific solutions like template instantiation repositories -> proprietary. One solution which always works and which is currently used in HotSpot is to treat template definitions like the definition of inline functions and place them into ".inline.hpp" files. We could of course use ".template.hpp" but that's probably not worth the effort. In the end, I absolutely agree with Stefan that we should add these rules for the implementation of inline and template functions to the corresponding HotSpot coding styles. And finally I think that now, just at the beginning of the Java 9 development cycle, it is a perfect point in time to fix the current code base where it violates these rules. Regards, Volker On Tue, Apr 1, 2014 at 9:36 AM, David Holmes wrote: > On 1/04/2014 5:30 PM, Lindenmaier, Goetz wrote: >> >> Hi David, >> >>> Personally I don't see why a cpp file should have to be aware that a >>> member function it uses just happens to have been defined in an >>> inline.hpp file by its author. Seems to break encapsulation to me. :( >> >> Because the .cpp file will not compile if the .inline.hpp header with >> the implementation is not visible during compilation. > > > Understood - but there is more than one way to make the implementation > visible to the cpp file eg cpp include .hpp and .hpp includes .inline.hpp (I > suppose that is a "bad" thing to do?) > > And that still doesn't change the fact it is breaking encapsulation :) > > >>> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I >> >> There are a lot of .hpp files with include methods that don't have >> a corresponding .inline.hpp file. Like taskqueue.hpp, which includes >> the atomic headers. Would be nice if this was cleaned up. >> Also, oop.inline.hpp often makes problems, because methods defined >> there are used in .hpp files, which can not include oop.inline.hpp >> as it causes cycles. If you include that header in a cpp file, you also >> have >> to include oop.inline.hpp, which is really unintuitive. > > > I find the inline situation to be unintuitive in general. There's a flow on > affect that an inline function can't use other inline functions unless they > all get moved to .inline.hpp files. I hope it is okay for one .inline.hpp > file to include another one? Otherwise you have to expose the internal > implementation detail of one class to its clients so they know which set of > .inline.hpp files have to be included! > > Cheers, > David > > >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 1. April 2014 08:03 >> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >> hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330 >> >> Hi Goetz, >> >> Not a review ... >> >> On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> could I please get reviews for this change? I please also need a >>> sponsor. >>> I would like to get this into 8u20, as 8036330 was downported, too. >>> >>> I'd like to make the point of this change clear once more, independent >>> of which compiler does what. >>> >>> I think we agree that basically >>> - a file should include all headers that define symbols or include >>> method bodies used in that file >> >> >> Personally I don't see why a cpp file should have to be aware that a >> member function it uses just happens to have been defined in an >> inline.hpp file by its author. Seems to break encapsulation to me. :( >> >>> - a .hpp header should not include a .inline.hpp header >> >> >> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I >> don't think we can take this as a general rule either. >> >> Note I'm not saying this fix isn't right or needed, just that the >> "rules" you are trying to embody don't seem to generally apply. >> >> David >> ----- >> >>> This is violated >>> >>> 1.) by defining >>> template void immediate_rs_update(HeapRegion* from, T* p, >>> int tid) { >>> if (!from->is_survivor()) { >>> _g1_rem->par_write_ref(from, p, tid); >>> } >>> } >>> in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only >>> defined in >>> g1RemSet.inline.hpp - which is not included and should not be >>> included >>> in g1CollectedHeap.hpp. >>> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp >>> >>> This change fixes these two points by moving functions into .inline.hpp >>> files >>> and fixing the include. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> From: Lindenmaier, Goetz >>> Sent: Donnerstag, 27. M?rz 2014 17:46 >>> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330 >>> >>> Hi, >>> >>> Please review and test this change. I please need a sponsor: >>> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ >>> >>> Change 8035330: Remove G1ParScanPartialArrayClosure and >>> G1ParScanHeapEvacClosure >>> broke the dbg build on AIX. That's because do_oop_partial_array() is >>> added in >>> a header, but requires inline function par_write_ref() through several >>> inlined >>> calls. In some cpp files, like arguments.cpp, par_write_ref() is not >>> defined >>> as the corresponding inline header is not included. The aix debug VM >>> does not start. >>> >>> This can be solved by including g1RemSet.inline.hpp in >>> g1CollectedHeap.inline.hpp. >>> >>> Unfortunately this now causes a cyclic dependency that breaks the linux >>> build. >>> A inline.hpp file is included ahead of a .hpp file, so that the code in >>> the inline.hpp file >>> can not see the class declaration. >>> This is caused because g1CollectedHeap.inline.hpp is included in >>> sparsePRT.hpp. >>> But .inline.hpp files never should be included in .hpp files. >>> >>> To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As >>> consequence, >>> I had to move a row of functions to existing .inline.hpp files. >>> >>> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64, >>> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up. >>> >>> Best regards, >>> Goetz >>> > From coleen.phillimore at oracle.com Tue Apr 1 11:38:00 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Apr 2014 07:38:00 -0400 Subject: RFR: 8033251: Use DWARF debug symbols for Linux 32-bit as default In-Reply-To: <533A5F01.3060200@oracle.com> References: <53359F78.6070503@oracle.com> <5335A38E.6040406@oracle.com> <5335A6F3.7010300@oracle.com> <5335BECD.9050808@oracle.com> <53364F7A.1020903@oracle.com> <53395F6E.4030505@oracle.com> <533A5F01.3060200@oracle.com> Message-ID: <533AA518.4020603@oracle.com> I thought you'd be able to get rid of the entire DEBUG_BINARIES setting with the cleanup too. Or is that additional cleanup? Coleen On 4/1/14 2:38 AM, David Holmes wrote: > Hi Erik, > > On 31/03/2014 10:28 PM, Erik Helin wrote: >> Hi David, >> >> thanks for having a look! Please see my reply inline. > > Thanks for the additional cleanup! > > Looks good. > > David > > >> On 2014-03-29 05:43, David Holmes wrote: >>> On 29/03/2014 4:26 AM, Coleen Phillimore wrote: >>>> >>>> On 3/28/14 12:44 PM, Erik Helin wrote: >>>>> Hi Coleen, >>>>> >>>>> thanks for having a look at the patch! >>>>> >>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>> >>>>>> I thought you'd be able to remove the DEBUG_BINARIES logic with this >>>>>> change. It appears there are no platforms left that use stabs with >>>>>> gcc. >>>>> >>>>> Yeah, I also noticed that this change enables cleanups in the >>>>> Makefiles. However, I think it is better to do these cleanups as a >>>>> second change after this one, what do you think? >>>> >>>> A cleanup CR is fine. >>> >>> Unless the cleanup is coming "tomorrow" I disagree. What have now is >>> comments that make no sense given the change that has been made. And as >>> every defined platform seems to use -g we can get rid of all this >>> per-platform logic and simply check for clang. All of which can be done >>> without doing the DEBUG_BINARIES cleanup. Eg delete the per-platform >>> flags and simply have, for example, >>> >>> # Override per-platform if the default -g doesn't suite >>> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH)) >>> ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) >>> ifeq ($(USE_CLANG), true) >>> # Clang doesn't understand -gstabs >>> OPT_CFLAGS += -g >>> else >>> OPT_CFLAGS += -gstabs >>> endif >>> endif >> >> I wanted this change to only be about changing from STABS to DWARF, but >> based on your feedback I cleaned up some code in the makefile as well: >> >> - Incremental webrev: >> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00-01/ >> - New webrev: >> http://cr.openjdk.java.net/~ehelin/8033251/webrev.01/ >> >> The default is now to use DWARF for all platforms, but this can be >> changed by using CFLAGS, for example FASTDEBUG_CFLAGS/amd64=-gstabs will >> give you STABS debug symbols for a fastdebug build on 64-bit Linux. >> Having -g as default also enables us to get rid of all the $(USE_CLANG) >> checks. >> >> The new patch also fixes a small bug where FASTDEBUG_CFLAGS was set to >> $(DEBUG_CFLAGS/$(BUILDARCH)), it should be set to >> $(FASTDEBUG_CFLAGS/$(BUILDARCH)). >> >> Testing of new patch: >> - JPRT >> - Building builds for different targets with different debug symbols >> locally. >> >> Thanks, >> Erik >> >>> In the future this flag should also potentially be coming in via >>> spec.gmk. >>> >>> David >>> >>>>> >>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>> Does this change add -g for saproc, adlc and jsig compilations also? >>>>> It seems like saproc uses SA_DEBUG_CFLAGS which only is being set if >>>>> DEBUG_BINARIES=true. If DEBUG_BINARIES is not true, then it seems >>>>> like >>>>> we don't generate debug symbols (please correct me if I'm wrong). >>>>> >>>>> The above also seems to be the case for libjsig.so. >>>>> >>>> >>>> These seem broken, but I don't know the makefiles well enough to >>>> comment. >>>> >>>> I think this change is good. People have been asking for it for years >>>> and now that the size problem with dwarf has been fixed, I'm glad you >>>> are making this change. >>>> >>>> Thanks, >>>> Coleen >>>>> Looking in make/linux/makefiles/adlc.make it seems like adlc is using >>>>> -g for GCC 3.3 or newer. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>>> Coleen >>>>>> >>>>>> On 3/28/14 12:12 PM, Erik Helin wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> this patch changes the Linux Makefiles to use DWARF as the default >>>>>>> debug symbol format for Linux 32-bit instead of STABS. The main >>>>>>> arguments for using DWARF are: >>>>>>> >>>>>>> - DWARF provides a superior debugging experience compared to >>>>>>> STABS. >>>>>>> - STABS support in GCC/GDB is in maintenance mode [0]. >>>>>>> - External tools (e.g. perf on Linux) often understands DWARF but >>>>>>> not >>>>>>> STABS. >>>>>>> - Compilation on 32-bit Linux can make use of precompiled >>>>>>> headers. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00/ >>>>>>> >>>>>>> Testing: >>>>>>> - Compiling with GCC 4.3.4, GCC 4.7.3 and GCC 4.8.1 >>>>>>> - JPRT >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>>>> >>>>>>> [0]: https://sourceware.org/ml/binutils/2013-01/msg00028.html >>>>>> >>>> From coleen.phillimore at oracle.com Tue Apr 1 11:39:27 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Apr 2014 07:39:27 -0400 Subject: RFR 8028497: SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool) In-Reply-To: <533A79A5.6050307@oracle.com> References: <5331EA20.6000001@oracle.com> <5332FF22.4010900@oracle.com> <5333438B.8090508@oracle.com> <53338653.6060500@oracle.com> <53341BF7.6060309@oracle.com> <53343DFC.9000904@oracle.com> <53345BD5.5020806@oracle.com> <533A32C3.3090002@oracle.com> <533A79A5.6050307@oracle.com> Message-ID: <533AA56F.704@oracle.com> Oh, that's why testing went so well. Coleen On 4/1/14 4:32 AM, Erik Helin wrote: > On 2014-04-01 05:30, Coleen Phillimore wrote: >> >> Erik, >> >> You are right. The old code would use the Klass->mirror link to clear >> out the mirror->Klass link so that we didn't have a pointer to a >> deallocated Klass in a mirror that might still be live for CMS marking. >> The new code doesn't set the Klass->mirror link unless the mirror fields >> are completely allocated, so we could crash if we deallocated a Klass >> before the mirror because the mirror would still be pointing to the >> class. >> >> I've caught failed allocation in mirror fields so that the link is reset >> in this change. The only change is to the function create_mirror calls >> initialize_mirror_fields. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8028497_3/ > > In javaClasses.cpp: > void java_lang_Class::create_mirror(KlassHandle k, Handle, TRAPS) { > ... > initialize_mirror_fields(k, mirror, protection_domain, THREAD); > if (HAS_PENDING_EXCEPTION) { > // If any of the fields throws an exception like OOM remove the > // klass field from the mirror so GC doesn't follow it after the > // klass has been deallocated. > java_lang_Class::set_klass(mirror(), k()); > return; ^ > } | > | > +------------------------------------------+ > | > +-- Do you really want to use k() here? I thought the idea was to do: > java_lang_Class::set_klass(mirror(), NULL); > > Setting the Klass that the mirror is mirroring will hit the following > check in instanceMirrorKlass.cpp, oop_oop_iterate macro: > > int InstanceMirrorKlass::oop_oop_iterate##nv_suffix(...) { \ > ... \ > if_do_metadata_checked(closure, nv_suffix) { \ > Klass* klass = java_lang_Class::as_Klass(obj); \ > /* We'll get NULL for primitive mirrors. */ \ > if (klass != NULL) { \ > closure->do_klass##nv_suffix(klass); \ > } \ > } > > Setting the Klass that the mirror is mirroring to NULL will make the > mirror look like a primitive mirror (this is the way we encode > primitive mirrors). Will that be a problem? > > Thanks, > Erik > >> Tested with vm.parallel_class_loading.testlist which do hit this case. >> >> Thanks! >> Coleen >> >> >> On 3/27/14 1:11 PM, Erik Helin wrote: >>> Hi Coleen, >>> >>> thanks for taking on this tricky bug! However, I think there is an >>> issue with your fix :( >>> >>> This case is for "normal" (non-CDS) class loading: >>> 1. We create the mirror >>> 2. We set up the link from the mirror to the Klass >>> 3. We fail somewhere before setting the link from the Klass to the >>> mirror, for example when allocating the Java object for the init >>> lock. >>> 4. The destructor for ClassFileParser is run and we add the Klass to >>> the >>> deallocate list. >>> 5. A CMS concurrent cycle is started, it will treat all objects in eden >>> + the survivor area as roots (including the mirror). >>> 6. The above concurrent cycle enters the "final remark" phase and does >>> class unloading which will call free_deallocate_list() which will >>> return the memory for the Klass added to the deallocate list in step >>> 4 to Metaspace. >>> 7. The concurrent CMS cycle ends (the mirror is still in eden or young) >>> 8. A new concurrent CMS cycle is started, the mirror will once again be >>> treated as a root since it is still in eden or young (no YC has been >>> done). >>> 9. During the initial marking, CMS will now follow the pointer to the >>> Klass that the mirror is mirroring, but we returned this memory to >>> Metaspace in step 6. >>> 10. We now crash :( >>> >>> Unfortunately, I don't have any suggestion on how to solve the above >>> scenario at the moment. >>> >>> Thanks, >>> Erik >>> >>> On 2014-03-27 16:04, Coleen Phillimore wrote: >>>> >>>> On 3/27/14 8:39 AM, Stefan Karlsson wrote: >>>>> >>>>> On 2014-03-27 03:00, Coleen Phillimore wrote: >>>>>> >>>>>> I have a new version of this change based on code that Ioi noticed >>>>>> that I was missing for making restoring the method's adapters >>>>>> restartable if something fails during restore_unshareable_info, and >>>>>> the constant pool resolved references array. >>>>>> Please review this new code (only method.* and instanceKlass.cpp and >>>>>> constantPool.cpp have differences). Reran tests with CDS and CMS. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8028497_2/ >>>>> >>>>> This seems good. I'd prefer if someone with more experience with CDS >>>>> also Reviews the change. >>>> >>>> Thanks, Ioi said he'd look at it. >>>> >>>>> >>>>> Small comment: >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8028497_2/src/share/vm/oops/instanceKlass.cpp.udiff.html >>>>> >>>>> >>>>> >>>>> >>>>> - methodHandle m(THREAD, methods->at(index2)); >>>>> - m()->link_method(m, CHECK); >>>>> - // restore method's vtable by calling a virtual function >>>>> - m->restore_vtable(); >>>>> + Method *m = methods->at(index2); >>>>> + m->restore_unshareable_info(CHECK); >>>>> >>>>> >>>>> Do we really want to use a raw Method * here. I know that we wrap the >>>>> method in a handle inside m->restore_unshareable_info, but it's not >>>>> clear from the this context. I'm thinking about this issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8004815 >>>>> >>>>> On the other hand, I guess we can't redefine a class before it has >>>>> been defined. But maybe it would be good to not promote the usage of >>>>> Method* over calls that might hit a Safepoint. >>>>> >>>> >>>> I think you're right, we don't use 'm' after the potential >>>> safepoint and >>>> we can't really redefine this class yet anyway but I'll restore the >>>> code >>>> because we don't want to encourage uses of unhandled Methods unless >>>> proven to be harmless. >>>> >>>> Thanks! >>>> Coleen >>>>> thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 3/26/14 5:15 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Jon, >>>>>>> Thank you for looking at the code changes. >>>>>>> >>>>>>> On 3/26/14 12:24 PM, Jon Masamitsu wrote: >>>>>>>> Coleen, >>>>>>>> >>>>>>>> Did you remove Class_obj_allocate() because it was only >>>>>>>> called in that one spot and use obj_allocate() did most >>>>>>>> of the work? >>>>>>> >>>>>>> I deleted it because GC doesn't need to know how these javaClasses >>>>>>> are set up and I spent way to long looking for this code and didn't >>>>>>> find it where it belongs, so I removed this. This >>>>>>> Class_obj_allocate >>>>>>> is an artifact of the permgen code. >>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/instanceMirrorKlass.cpp.frames.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 373 // the size in the mirror size itself. >>>>>>>> >>>>>>>> Drop the second "size". You know how we GC guys are >>>>>>>> getting with our comments :-). >>>>>>> >>>>>>> Yes, I noticed that. Thanks - fixed. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/klass.cpp.frames.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 498 void Klass::restore_unshareable_info(TRAPS) { >>>>>>>> 499 // If an exception happened during CDS restore, some of >>>>>>>> these fields may already be >>>>>>>> 500 // set. We leave the class on the CLD list, even if >>>>>>>> incomplete so that we don't >>>>>>>> 501 // modify the CLD list outside a safepoint. >>>>>>>> 502 if (class_loader_data() == NULL) { >>>>>>>> 503 ClassLoaderData* loader_data = >>>>>>>> ClassLoaderData::the_null_class_loader_data(); >>>>>>>> >>>>>>>> I can see that this works with the current CDS (sharing only >>>>>>>> classes loader >>>>>>>> with the NULL class loader). Will it work if the shared classes >>>>>>>> are loaded >>>>>>>> with an application class loader? >>>>>>> >>>>>>> I hope Ioi can answer that. I assume so because the classes don't >>>>>>> change class loaders if restoring shareable info fails. >>>>>>> >>>>>>> Ioi pointed out to me (not on open list) that I missed making >>>>>>> link_method() and creating the constant pool resolved references >>>>>>> array restartable, so I'm testing a fix for that also and I'll post >>>>>>> an update later. But you've seen most of it. >>>>>>> >>>>>>> Thanks!! >>>>>>> Coleen >>>>>>>> >>>>>>>> Rest looks good. >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> On 3/25/2014 1:42 PM, Coleen Phillimore wrote: >>>>>>>>> Summary: Keep class in CLD::_klasses list and mirror created for >>>>>>>>> CDS classes if OOM during restore_shareable_info(). This keeps >>>>>>>>> pointers consistent for CMS. >>>>>>>>> >>>>>>>>> This change makes restoring the mirror for shared classes >>>>>>>>> restartable if there is an OOM in the middle of >>>>>>>>> restore_unshareable_info. The mirror field in the classes and >>>>>>>>> CLD link is not cleaned up anymore. The class isn't marked >>>>>>>>> loaded >>>>>>>>> though so must be loaded again. >>>>>>>>> >>>>>>>>> Tested with Stefan's test case with hard coded OOM in jvm, so >>>>>>>>> can't add the test. Also ran all the tests against -client and >>>>>>>>> server with -Xshare:auto and with -XX:+UseConcMarkSweepGC. >>>>>>>>> >>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8028497/ >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8028497 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From dmitry.samersoff at oracle.com Tue Apr 1 12:50:53 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 01 Apr 2014 16:50:53 +0400 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> Message-ID: <533AB62D.1010501@oracle.com> Goetz, Push done. Let it bakes for some times in JDK9 (at least two nightlies) than I'll push it to 8u20 -Dmitry On 2014-03-27 23:52, Lindenmaier, Goetz wrote: > Thanks Dmitry and Vladimir! > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, March 27, 2014 8:18 PM > To: Dmitry Samersoff; Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Thank you, Dmitry > > We need to backport it into 8u20 too. > > Regards, > Vladimir > > On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> I can push it to RT next week. >> >> -Dmitry >> >> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Looks good for me! >>> >>> +1. >>> >>> Dmitry, >>> >>> Do you want me to push it into Comp repo or you will do it into RT repo? >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>> Hi Dmitry, >>>>> >>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>> I had a look at set_boot_path(). That will never return false, >>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>> In addition it would be wrong to return, there should be a >>>>> call to vm_exit_... >>>>> So I removed the test and return statement. >>>>> I added the other missing FREEs. >>>>> >>>>> I also implemented your proposal with only one sprintf >>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>> to get it more similar. Solaris seems too different to >>>>> adapt to that scheme. >>>>> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>> ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Goetz, >>>>> >>>>> Thank you for doing it - code is much cleaner now. >>>>> >>>>> os_aix.cpp: >>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>> >>>>> os_bsd.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>> >>>>> ll.407 sprintf could be moved to ll.420 under else >>>>> >>>>> >>>>> ll.497 (and below) a trick like one below: >>>>> >>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>> char *v_colon = ":"; >>>>> >>>>> if (l != NULL || v != NULL) { >>>>> >>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>> >>>>> t = (char *) ... /* allocate memory for all strings */ >>>>> >>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>> if (ld_library_path != buf){ ... /* free ld_library_path */ } >>>>> ld_library_path = t; >>>>> } >>>>> >>>>> might be useful to assemble the path in one shot, >>>>> without extra copying >>>>> >>>>> >>>>> ll.520 As you appending constant value ":.", you can just >>>>> take it into account at ll. 495 >>>>> >>>>> >>>>> os_linux.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>> >>>>> os_solaris.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>> >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> please have a look at this new webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>> >>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>> the missing parts in here, below. >>>>>> >>>>>> Avoiding big stack allocations I wanted to remove the buf[MAXPATHLEN] >>>>>> at the beginning of the function, too. That's why I said I can't >>>>>> get along >>>>>> with a single allocation. strlen(v) is only known later. >>>>>> >>>>>> I could redesign the whole code, computing sizes first, and then >>>>>> doing a single allocation, but I think that doesn't help the >>>>>> readability of the code. >>>>>> >>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>> beginning >>>>>> and do a single allocation for them. >>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> Goetz, >>>>>> >>>>>>> The allocation in 556 must know about the length of the >>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>> >>>>>> You can use >>>>>> >>>>>> MAX( >>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>> ) >>>>>> >>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>> >>>>>> But I'm fine with two different allocations. >>>>>> >>>>>> Thank you for addressing other concerns. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> see my comments inline. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>> malloc() in init_system_properties_values() >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>> os_aix.cpp: 565 >>>>>>>> >>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>> I need at least two allocations. The first one has a statically >>>>>>> known size. At >>>>>>> least more or less, as I know there will be only one path of >>>>>>> unknown size in the buffer. >>>>>>> The allocation in 556 must know about the length of the >>>>>>> getenv("LIBPATH") result, >>>>>>> which may contain several paths. >>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>> buffers are needed. >>>>>>> >>>>>>>> os_bsd.cpp: 350 >>>>>>>> >>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, it makes >>>>>>>> code much more readable. >>>>>>> I'll fix this. >>>>>>> >>>>>>>> os_bsd.cpp: 485 >>>>>>>> >>>>>>>> you replace malloc to on-stack allocation of more than 4096 bytes. I >>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>> > see also comments to os_aix above - you can allocate large enough >>>>>>>> buffer once and than reuse it. >>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in the >>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>> The space required by the existing buf can be reused by the C >>>>>>> compiler. >>>>>>> >>>>>>> But I'll fix that and only use allocated memory. >>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>> buffer. >>>>>>> I'll do this the same on all four platforms. >>>>>>> >>>>>>>> os_linux.cpp: 434 >>>>>>>> the same comments as above. >>>>>>>> >>>>>>>> os_solaris.cpp: 728 >>>>>>>> >>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>> changed >>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>> respect >>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>> variables. >>>>>>>> >>>>>>>> Could you change it to something like: >>>>>>>> Dl_serinfo info_sz, *info; >>>>>>> Yes, I'll fix that. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == -1) { >>>>>> ... >>>>>> >>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>> mtInternal); >>>>>> ... >>>>>> >>>>>> os_solaris.cpp: 829 >>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review and test this change. I please need a sponsor. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>> >>>>>>> This change addresses the implementation of >>>>>>> init_system_properties_values >>>>>>> on aix, linux, solaris and bsd. >>>>>>> In init_system_properties_values a macro was defined mapping malloc to >>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful allocation >>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>> pointers as >>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>> calls to free(). >>>>>>> >>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>> removes >>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>> local array where >>>>>>> possible. >>>>>>> >>>>>>> The allocated memory is passed to calls that end up at >>>>>>> SystemProperty::set_value(). >>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>> init_system_properties_values must be freed after these calls. >>>>>>> Most of these >>>>>>> frees were missing. >>>>>>> >>>>>>> This change adds the missing frees. >>>>>>> >>>>>>> Testing this change I ran into a warning in ppc code which I fixed, >>>>>>> too. >>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Tue Apr 1 12:53:47 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Apr 2014 12:53:47 +0000 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <533AB62D.1010501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAC14C@DEWDFEMB12A.global.corp.sap> Hi Dmitry, thanks a lot for your help. I tested the webrev with 'const' on linux ppc and aix, works fine! Best regards, Goetz. -----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Dienstag, 1. April 2014 14:51 To: Lindenmaier, Goetz; 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Goetz, Push done. Let it bakes for some times in JDK9 (at least two nightlies) than I'll push it to 8u20 -Dmitry On 2014-03-27 23:52, Lindenmaier, Goetz wrote: > Thanks Dmitry and Vladimir! > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, March 27, 2014 8:18 PM > To: Dmitry Samersoff; Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Thank you, Dmitry > > We need to backport it into 8u20 too. > > Regards, > Vladimir > > On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> I can push it to RT next week. >> >> -Dmitry >> >> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Looks good for me! >>> >>> +1. >>> >>> Dmitry, >>> >>> Do you want me to push it into Comp repo or you will do it into RT repo? >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>> Hi Dmitry, >>>>> >>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>> I had a look at set_boot_path(). That will never return false, >>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>> In addition it would be wrong to return, there should be a >>>>> call to vm_exit_... >>>>> So I removed the test and return statement. >>>>> I added the other missing FREEs. >>>>> >>>>> I also implemented your proposal with only one sprintf >>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>> to get it more similar. Solaris seems too different to >>>>> adapt to that scheme. >>>>> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>> ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Goetz, >>>>> >>>>> Thank you for doing it - code is much cleaner now. >>>>> >>>>> os_aix.cpp: >>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>> >>>>> os_bsd.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>> >>>>> ll.407 sprintf could be moved to ll.420 under else >>>>> >>>>> >>>>> ll.497 (and below) a trick like one below: >>>>> >>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>> char *v_colon = ":"; >>>>> >>>>> if (l != NULL || v != NULL) { >>>>> >>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>> >>>>> t = (char *) ... /* allocate memory for all strings */ >>>>> >>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>> if (ld_library_path != buf){ ... /* free ld_library_path */ } >>>>> ld_library_path = t; >>>>> } >>>>> >>>>> might be useful to assemble the path in one shot, >>>>> without extra copying >>>>> >>>>> >>>>> ll.520 As you appending constant value ":.", you can just >>>>> take it into account at ll. 495 >>>>> >>>>> >>>>> os_linux.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>> >>>>> os_solaris.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>> >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> please have a look at this new webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>> >>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>> the missing parts in here, below. >>>>>> >>>>>> Avoiding big stack allocations I wanted to remove the buf[MAXPATHLEN] >>>>>> at the beginning of the function, too. That's why I said I can't >>>>>> get along >>>>>> with a single allocation. strlen(v) is only known later. >>>>>> >>>>>> I could redesign the whole code, computing sizes first, and then >>>>>> doing a single allocation, but I think that doesn't help the >>>>>> readability of the code. >>>>>> >>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>> beginning >>>>>> and do a single allocation for them. >>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> Goetz, >>>>>> >>>>>>> The allocation in 556 must know about the length of the >>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>> >>>>>> You can use >>>>>> >>>>>> MAX( >>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>> ) >>>>>> >>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>> >>>>>> But I'm fine with two different allocations. >>>>>> >>>>>> Thank you for addressing other concerns. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> see my comments inline. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>> malloc() in init_system_properties_values() >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>> os_aix.cpp: 565 >>>>>>>> >>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>> I need at least two allocations. The first one has a statically >>>>>>> known size. At >>>>>>> least more or less, as I know there will be only one path of >>>>>>> unknown size in the buffer. >>>>>>> The allocation in 556 must know about the length of the >>>>>>> getenv("LIBPATH") result, >>>>>>> which may contain several paths. >>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>> buffers are needed. >>>>>>> >>>>>>>> os_bsd.cpp: 350 >>>>>>>> >>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, it makes >>>>>>>> code much more readable. >>>>>>> I'll fix this. >>>>>>> >>>>>>>> os_bsd.cpp: 485 >>>>>>>> >>>>>>>> you replace malloc to on-stack allocation of more than 4096 bytes. I >>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>> > see also comments to os_aix above - you can allocate large enough >>>>>>>> buffer once and than reuse it. >>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in the >>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>> The space required by the existing buf can be reused by the C >>>>>>> compiler. >>>>>>> >>>>>>> But I'll fix that and only use allocated memory. >>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>> buffer. >>>>>>> I'll do this the same on all four platforms. >>>>>>> >>>>>>>> os_linux.cpp: 434 >>>>>>>> the same comments as above. >>>>>>>> >>>>>>>> os_solaris.cpp: 728 >>>>>>>> >>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>> changed >>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>> respect >>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>> variables. >>>>>>>> >>>>>>>> Could you change it to something like: >>>>>>>> Dl_serinfo info_sz, *info; >>>>>>> Yes, I'll fix that. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == -1) { >>>>>> ... >>>>>> >>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>> mtInternal); >>>>>> ... >>>>>> >>>>>> os_solaris.cpp: 829 >>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review and test this change. I please need a sponsor. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>> >>>>>>> This change addresses the implementation of >>>>>>> init_system_properties_values >>>>>>> on aix, linux, solaris and bsd. >>>>>>> In init_system_properties_values a macro was defined mapping malloc to >>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful allocation >>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>> pointers as >>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>> calls to free(). >>>>>>> >>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>> removes >>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>> local array where >>>>>>> possible. >>>>>>> >>>>>>> The allocated memory is passed to calls that end up at >>>>>>> SystemProperty::set_value(). >>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>> init_system_properties_values must be freed after these calls. >>>>>>> Most of these >>>>>>> frees were missing. >>>>>>> >>>>>>> This change adds the missing frees. >>>>>>> >>>>>>> Testing this change I ran into a warning in ppc code which I fixed, >>>>>>> too. >>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Tue Apr 1 13:02:36 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Apr 2014 15:02:36 +0200 Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag In-Reply-To: <533A892C.2090208@oracle.com> References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com> Message-ID: <330EABDB-3376-4559-A077-2FD853D3C0FA@oracle.com> There is already an API for getting / setting flags in sun.tools.attach.HotSpotVirtualMachine. If at all possible, we should reuse that API instead of adding a new one. Typical use: HotSpotVirtualMachine vm = (HotSpotVirtualMachine) VirtualMachine.attach(pid); vm.setFlag(?MyFlag?, ?MyValue?); There is also an API in sun.management.HotSpotDiagnostic for setting / getting as well as querying for options in JVM. Thanks, /Staffan On 1 apr 2014, at 11:38, Igor Ignatyev wrote: > adding hotspot-dev alias. > > On 03/31/2014 01:07 AM, Igor Ignatyev wrote: >> Hi all, >> >> Please review the patch which introduces new WhiteBox methods to get and >> set VM flags. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756 >> testing: jprt From erik.helin at oracle.com Tue Apr 1 13:03:08 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 01 Apr 2014 15:03:08 +0200 Subject: RFR: 8033251: Use DWARF debug symbols for Linux 32-bit as default In-Reply-To: <533AA518.4020603@oracle.com> References: <53359F78.6070503@oracle.com> <5335A38E.6040406@oracle.com> <5335A6F3.7010300@oracle.com> <5335BECD.9050808@oracle.com> <53364F7A.1020903@oracle.com> <53395F6E.4030505@oracle.com> <533A5F01.3060200@oracle.com> <533AA518.4020603@oracle.com> Message-ID: <533AB90C.5010901@oracle.com> On 2014-04-01 13:38, Coleen Phillimore wrote: > > I thought you'd be able to get rid of the entire DEBUG_BINARIES setting > with the cleanup too. Or is that additional cleanup? I view getting rid of DEBUG_BINARIES as an additional cleanup since DEBUG_BINARIES are used for platforms other than Linux and this patch only changes the Linux makefiles. Are you ok with this? Thanks, Erik > Coleen > > On 4/1/14 2:38 AM, David Holmes wrote: >> Hi Erik, >> >> On 31/03/2014 10:28 PM, Erik Helin wrote: >>> Hi David, >>> >>> thanks for having a look! Please see my reply inline. >> >> Thanks for the additional cleanup! >> >> Looks good. >> >> David >> >> >>> On 2014-03-29 05:43, David Holmes wrote: >>>> On 29/03/2014 4:26 AM, Coleen Phillimore wrote: >>>>> >>>>> On 3/28/14 12:44 PM, Erik Helin wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> thanks for having a look at the patch! >>>>>> >>>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>>> >>>>>>> I thought you'd be able to remove the DEBUG_BINARIES logic with this >>>>>>> change. It appears there are no platforms left that use stabs with >>>>>>> gcc. >>>>>> >>>>>> Yeah, I also noticed that this change enables cleanups in the >>>>>> Makefiles. However, I think it is better to do these cleanups as a >>>>>> second change after this one, what do you think? >>>>> >>>>> A cleanup CR is fine. >>>> >>>> Unless the cleanup is coming "tomorrow" I disagree. What have now is >>>> comments that make no sense given the change that has been made. And as >>>> every defined platform seems to use -g we can get rid of all this >>>> per-platform logic and simply check for clang. All of which can be done >>>> without doing the DEBUG_BINARIES cleanup. Eg delete the per-platform >>>> flags and simply have, for example, >>>> >>>> # Override per-platform if the default -g doesn't suite >>>> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH)) >>>> ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) >>>> ifeq ($(USE_CLANG), true) >>>> # Clang doesn't understand -gstabs >>>> OPT_CFLAGS += -g >>>> else >>>> OPT_CFLAGS += -gstabs >>>> endif >>>> endif >>> >>> I wanted this change to only be about changing from STABS to DWARF, but >>> based on your feedback I cleaned up some code in the makefile as well: >>> >>> - Incremental webrev: >>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00-01/ >>> - New webrev: >>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.01/ >>> >>> The default is now to use DWARF for all platforms, but this can be >>> changed by using CFLAGS, for example FASTDEBUG_CFLAGS/amd64=-gstabs will >>> give you STABS debug symbols for a fastdebug build on 64-bit Linux. >>> Having -g as default also enables us to get rid of all the $(USE_CLANG) >>> checks. >>> >>> The new patch also fixes a small bug where FASTDEBUG_CFLAGS was set to >>> $(DEBUG_CFLAGS/$(BUILDARCH)), it should be set to >>> $(FASTDEBUG_CFLAGS/$(BUILDARCH)). >>> >>> Testing of new patch: >>> - JPRT >>> - Building builds for different targets with different debug symbols >>> locally. >>> >>> Thanks, >>> Erik >>> >>>> In the future this flag should also potentially be coming in via >>>> spec.gmk. >>>> >>>> David >>>> >>>>>> >>>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>>> Does this change add -g for saproc, adlc and jsig compilations also? >>>>>> It seems like saproc uses SA_DEBUG_CFLAGS which only is being set if >>>>>> DEBUG_BINARIES=true. If DEBUG_BINARIES is not true, then it seems >>>>>> like >>>>>> we don't generate debug symbols (please correct me if I'm wrong). >>>>>> >>>>>> The above also seems to be the case for libjsig.so. >>>>>> >>>>> >>>>> These seem broken, but I don't know the makefiles well enough to >>>>> comment. >>>>> >>>>> I think this change is good. People have been asking for it for years >>>>> and now that the size problem with dwarf has been fixed, I'm glad you >>>>> are making this change. >>>>> >>>>> Thanks, >>>>> Coleen >>>>>> Looking in make/linux/makefiles/adlc.make it seems like adlc is using >>>>>> -g for GCC 3.3 or newer. >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 3/28/14 12:12 PM, Erik Helin wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> this patch changes the Linux Makefiles to use DWARF as the default >>>>>>>> debug symbol format for Linux 32-bit instead of STABS. The main >>>>>>>> arguments for using DWARF are: >>>>>>>> >>>>>>>> - DWARF provides a superior debugging experience compared to >>>>>>>> STABS. >>>>>>>> - STABS support in GCC/GDB is in maintenance mode [0]. >>>>>>>> - External tools (e.g. perf on Linux) often understands DWARF but >>>>>>>> not >>>>>>>> STABS. >>>>>>>> - Compilation on 32-bit Linux can make use of precompiled >>>>>>>> headers. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00/ >>>>>>>> >>>>>>>> Testing: >>>>>>>> - Compiling with GCC 4.3.4, GCC 4.7.3 and GCC 4.8.1 >>>>>>>> - JPRT >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Erik >>>>>>>> >>>>>>>> [0]: https://sourceware.org/ml/binutils/2013-01/msg00028.html >>>>>>> >>>>> > From thomas.stuefe at gmail.com Tue Apr 1 13:11:07 2014 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Tue, 1 Apr 2014 15:11:07 +0200 Subject: Small issues with Dict (dict.cpp, dict2.cpp) Message-ID: Hello, I see some smallish issues in the "Dict" class which can be found share/vm/libadt/dict.cpp and in slightly different form in share/vm/adlc/dict2.cpp. Nothing major, and of course I may be wrong... 1) Dict &Dict::operator =( const Dict &d ): ... if( _size < d._size ) { // If must have more buckets _arena = d._arena; _bin = (bucket*)_arena->Arealloc( _bin, sizeof(bucket)*_size, sizeof(bucket)*d._size ); memset( &_bin[_size], 0, (d._size-_size)*sizeof(bucket) ); _size = d._size; } Both Arealloc and memset seem pointless to me, as the buckets are cleared anyway below. Also, we leak the old content if the arena is different - we could at least attempt to Afree() the old bucket list in the old arena. 2) void *Dict::Delete(void *key) : ... b->_cnt--; // Remove key/value from lo bucket b->_keyvals[j+j ] = b->_keyvals[b->_cnt+b->_cnt ]; b->_keyvals[j+j+1] = b->_keyvals[b->_cnt+b->_cnt+1]; if bucket only had one entry (hopefully the rule, if hash works well), the copying is unnecessary. 3) int32 Dict::operator ==(const Dict &d2) const This uses memcmp to compare buckets, so it depends on the order of bucket list entries; I am not sure this was intended. I also did not find any use for these methods, are they actually used somewhere? Kind Regards, Thomas St?fe From coleen.phillimore at oracle.com Tue Apr 1 13:28:10 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Apr 2014 09:28:10 -0400 Subject: RFR: 8033251: Use DWARF debug symbols for Linux 32-bit as default In-Reply-To: <533AB90C.5010901@oracle.com> References: <53359F78.6070503@oracle.com> <5335A38E.6040406@oracle.com> <5335A6F3.7010300@oracle.com> <5335BECD.9050808@oracle.com> <53364F7A.1020903@oracle.com> <53395F6E.4030505@oracle.com> <533A5F01.3060200@oracle.com> <533AA518.4020603@oracle.com> <533AB90C.5010901@oracle.com> Message-ID: <533ABEEA.4040203@oracle.com> On 4/1/14 9:03 AM, Erik Helin wrote: > On 2014-04-01 13:38, Coleen Phillimore wrote: >> >> I thought you'd be able to get rid of the entire DEBUG_BINARIES setting >> with the cleanup too. Or is that additional cleanup? > > I view getting rid of DEBUG_BINARIES as an additional cleanup since > DEBUG_BINARIES are used for platforms other than Linux and this patch > only changes the Linux makefiles. > > Are you ok with this? Yes, I just misunderstood David's cleanup request. Can you file an RFE to remove DEBUG_BINARIES (if you haven't already)? thanks, Coleen > > Thanks, > Erik > >> Coleen >> >> On 4/1/14 2:38 AM, David Holmes wrote: >>> Hi Erik, >>> >>> On 31/03/2014 10:28 PM, Erik Helin wrote: >>>> Hi David, >>>> >>>> thanks for having a look! Please see my reply inline. >>> >>> Thanks for the additional cleanup! >>> >>> Looks good. >>> >>> David >>> >>> >>>> On 2014-03-29 05:43, David Holmes wrote: >>>>> On 29/03/2014 4:26 AM, Coleen Phillimore wrote: >>>>>> >>>>>> On 3/28/14 12:44 PM, Erik Helin wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> thanks for having a look at the patch! >>>>>>> >>>>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> I thought you'd be able to remove the DEBUG_BINARIES logic with >>>>>>>> this >>>>>>>> change. It appears there are no platforms left that use stabs >>>>>>>> with >>>>>>>> gcc. >>>>>>> >>>>>>> Yeah, I also noticed that this change enables cleanups in the >>>>>>> Makefiles. However, I think it is better to do these cleanups as a >>>>>>> second change after this one, what do you think? >>>>>> >>>>>> A cleanup CR is fine. >>>>> >>>>> Unless the cleanup is coming "tomorrow" I disagree. What have now is >>>>> comments that make no sense given the change that has been made. >>>>> And as >>>>> every defined platform seems to use -g we can get rid of all this >>>>> per-platform logic and simply check for clang. All of which can be >>>>> done >>>>> without doing the DEBUG_BINARIES cleanup. Eg delete the per-platform >>>>> flags and simply have, for example, >>>>> >>>>> # Override per-platform if the default -g doesn't suite >>>>> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH)) >>>>> ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) >>>>> ifeq ($(USE_CLANG), true) >>>>> # Clang doesn't understand -gstabs >>>>> OPT_CFLAGS += -g >>>>> else >>>>> OPT_CFLAGS += -gstabs >>>>> endif >>>>> endif >>>> >>>> I wanted this change to only be about changing from STABS to DWARF, >>>> but >>>> based on your feedback I cleaned up some code in the makefile as well: >>>> >>>> - Incremental webrev: >>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00-01/ >>>> - New webrev: >>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.01/ >>>> >>>> The default is now to use DWARF for all platforms, but this can be >>>> changed by using CFLAGS, for example FASTDEBUG_CFLAGS/amd64=-gstabs >>>> will >>>> give you STABS debug symbols for a fastdebug build on 64-bit Linux. >>>> Having -g as default also enables us to get rid of all the >>>> $(USE_CLANG) >>>> checks. >>>> >>>> The new patch also fixes a small bug where FASTDEBUG_CFLAGS was set to >>>> $(DEBUG_CFLAGS/$(BUILDARCH)), it should be set to >>>> $(FASTDEBUG_CFLAGS/$(BUILDARCH)). >>>> >>>> Testing of new patch: >>>> - JPRT >>>> - Building builds for different targets with different debug symbols >>>> locally. >>>> >>>> Thanks, >>>> Erik >>>> >>>>> In the future this flag should also potentially be coming in via >>>>> spec.gmk. >>>>> >>>>> David >>>>> >>>>>>> >>>>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>>>> Does this change add -g for saproc, adlc and jsig compilations >>>>>>>> also? >>>>>>> It seems like saproc uses SA_DEBUG_CFLAGS which only is being >>>>>>> set if >>>>>>> DEBUG_BINARIES=true. If DEBUG_BINARIES is not true, then it seems >>>>>>> like >>>>>>> we don't generate debug symbols (please correct me if I'm wrong). >>>>>>> >>>>>>> The above also seems to be the case for libjsig.so. >>>>>>> >>>>>> >>>>>> These seem broken, but I don't know the makefiles well enough to >>>>>> comment. >>>>>> >>>>>> I think this change is good. People have been asking for it for >>>>>> years >>>>>> and now that the size problem with dwarf has been fixed, I'm glad >>>>>> you >>>>>> are making this change. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>>> Looking in make/linux/makefiles/adlc.make it seems like adlc is >>>>>>> using >>>>>>> -g for GCC 3.3 or newer. >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/28/14 12:12 PM, Erik Helin wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> this patch changes the Linux Makefiles to use DWARF as the >>>>>>>>> default >>>>>>>>> debug symbol format for Linux 32-bit instead of STABS. The main >>>>>>>>> arguments for using DWARF are: >>>>>>>>> >>>>>>>>> - DWARF provides a superior debugging experience compared to >>>>>>>>> STABS. >>>>>>>>> - STABS support in GCC/GDB is in maintenance mode [0]. >>>>>>>>> - External tools (e.g. perf on Linux) often understands >>>>>>>>> DWARF but >>>>>>>>> not >>>>>>>>> STABS. >>>>>>>>> - Compilation on 32-bit Linux can make use of precompiled >>>>>>>>> headers. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00/ >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> - Compiling with GCC 4.3.4, GCC 4.7.3 and GCC 4.8.1 >>>>>>>>> - JPRT >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Erik >>>>>>>>> >>>>>>>>> [0]: https://sourceware.org/ml/binutils/2013-01/msg00028.html >>>>>>>> >>>>>> >> From erik.helin at oracle.com Tue Apr 1 14:03:27 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 01 Apr 2014 16:03:27 +0200 Subject: RFR: 8033251: Use DWARF debug symbols for Linux 32-bit as default In-Reply-To: <533ABEEA.4040203@oracle.com> References: <53359F78.6070503@oracle.com> <5335A38E.6040406@oracle.com> <5335A6F3.7010300@oracle.com> <5335BECD.9050808@oracle.com> <53364F7A.1020903@oracle.com> <53395F6E.4030505@oracle.com> <533A5F01.3060200@oracle.com> <533AA518.4020603@oracle.com> <533AB90C.5010901@oracle.com> <533ABEEA.4040203@oracle.com> Message-ID: <533AC72F.60508@oracle.com> On 2014-04-01 15:28, Coleen Phillimore wrote: > > On 4/1/14 9:03 AM, Erik Helin wrote: >> On 2014-04-01 13:38, Coleen Phillimore wrote: >>> >>> I thought you'd be able to get rid of the entire DEBUG_BINARIES setting >>> with the cleanup too. Or is that additional cleanup? >> >> I view getting rid of DEBUG_BINARIES as an additional cleanup since >> DEBUG_BINARIES are used for platforms other than Linux and this patch >> only changes the Linux makefiles. >> >> Are you ok with this? > > Yes, I just misunderstood David's cleanup request. Ok, thanks! > Can you file an RFE to remove DEBUG_BINARIES (if you haven't already)? Sure, https://bugs.openjdk.java.net/browse/JDK-8038957. Thanks, Erik > thanks, > Coleen > >> >> Thanks, >> Erik >> >>> Coleen >>> >>> On 4/1/14 2:38 AM, David Holmes wrote: >>>> Hi Erik, >>>> >>>> On 31/03/2014 10:28 PM, Erik Helin wrote: >>>>> Hi David, >>>>> >>>>> thanks for having a look! Please see my reply inline. >>>> >>>> Thanks for the additional cleanup! >>>> >>>> Looks good. >>>> >>>> David >>>> >>>> >>>>> On 2014-03-29 05:43, David Holmes wrote: >>>>>> On 29/03/2014 4:26 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> On 3/28/14 12:44 PM, Erik Helin wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> thanks for having a look at the patch! >>>>>>>> >>>>>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> I thought you'd be able to remove the DEBUG_BINARIES logic with >>>>>>>>> this >>>>>>>>> change. It appears there are no platforms left that use stabs >>>>>>>>> with >>>>>>>>> gcc. >>>>>>>> >>>>>>>> Yeah, I also noticed that this change enables cleanups in the >>>>>>>> Makefiles. However, I think it is better to do these cleanups as a >>>>>>>> second change after this one, what do you think? >>>>>>> >>>>>>> A cleanup CR is fine. >>>>>> >>>>>> Unless the cleanup is coming "tomorrow" I disagree. What have now is >>>>>> comments that make no sense given the change that has been made. >>>>>> And as >>>>>> every defined platform seems to use -g we can get rid of all this >>>>>> per-platform logic and simply check for clang. All of which can be >>>>>> done >>>>>> without doing the DEBUG_BINARIES cleanup. Eg delete the per-platform >>>>>> flags and simply have, for example, >>>>>> >>>>>> # Override per-platform if the default -g doesn't suite >>>>>> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH)) >>>>>> ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) >>>>>> ifeq ($(USE_CLANG), true) >>>>>> # Clang doesn't understand -gstabs >>>>>> OPT_CFLAGS += -g >>>>>> else >>>>>> OPT_CFLAGS += -gstabs >>>>>> endif >>>>>> endif >>>>> >>>>> I wanted this change to only be about changing from STABS to DWARF, >>>>> but >>>>> based on your feedback I cleaned up some code in the makefile as well: >>>>> >>>>> - Incremental webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00-01/ >>>>> - New webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.01/ >>>>> >>>>> The default is now to use DWARF for all platforms, but this can be >>>>> changed by using CFLAGS, for example FASTDEBUG_CFLAGS/amd64=-gstabs >>>>> will >>>>> give you STABS debug symbols for a fastdebug build on 64-bit Linux. >>>>> Having -g as default also enables us to get rid of all the >>>>> $(USE_CLANG) >>>>> checks. >>>>> >>>>> The new patch also fixes a small bug where FASTDEBUG_CFLAGS was set to >>>>> $(DEBUG_CFLAGS/$(BUILDARCH)), it should be set to >>>>> $(FASTDEBUG_CFLAGS/$(BUILDARCH)). >>>>> >>>>> Testing of new patch: >>>>> - JPRT >>>>> - Building builds for different targets with different debug symbols >>>>> locally. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>>> In the future this flag should also potentially be coming in via >>>>>> spec.gmk. >>>>>> >>>>>> David >>>>>> >>>>>>>> >>>>>>>> On 2014-03-28 17:30, Coleen Phillimore wrote: >>>>>>>>> Does this change add -g for saproc, adlc and jsig compilations >>>>>>>>> also? >>>>>>>> It seems like saproc uses SA_DEBUG_CFLAGS which only is being >>>>>>>> set if >>>>>>>> DEBUG_BINARIES=true. If DEBUG_BINARIES is not true, then it seems >>>>>>>> like >>>>>>>> we don't generate debug symbols (please correct me if I'm wrong). >>>>>>>> >>>>>>>> The above also seems to be the case for libjsig.so. >>>>>>>> >>>>>>> >>>>>>> These seem broken, but I don't know the makefiles well enough to >>>>>>> comment. >>>>>>> >>>>>>> I think this change is good. People have been asking for it for >>>>>>> years >>>>>>> and now that the size problem with dwarf has been fixed, I'm glad >>>>>>> you >>>>>>> are making this change. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>>> Looking in make/linux/makefiles/adlc.make it seems like adlc is >>>>>>>> using >>>>>>>> -g for GCC 3.3 or newer. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Erik >>>>>>>> >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 3/28/14 12:12 PM, Erik Helin wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> this patch changes the Linux Makefiles to use DWARF as the >>>>>>>>>> default >>>>>>>>>> debug symbol format for Linux 32-bit instead of STABS. The main >>>>>>>>>> arguments for using DWARF are: >>>>>>>>>> >>>>>>>>>> - DWARF provides a superior debugging experience compared to >>>>>>>>>> STABS. >>>>>>>>>> - STABS support in GCC/GDB is in maintenance mode [0]. >>>>>>>>>> - External tools (e.g. perf on Linux) often understands >>>>>>>>>> DWARF but >>>>>>>>>> not >>>>>>>>>> STABS. >>>>>>>>>> - Compilation on 32-bit Linux can make use of precompiled >>>>>>>>>> headers. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~ehelin/8033251/webrev.00/ >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> - Compiling with GCC 4.3.4, GCC 4.7.3 and GCC 4.8.1 >>>>>>>>>> - JPRT >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Erik >>>>>>>>>> >>>>>>>>>> [0]: https://sourceware.org/ml/binutils/2013-01/msg00028.html >>>>>>>>> >>>>>>> >>> > From lev.priima at oracle.com Tue Apr 1 14:25:22 2014 From: lev.priima at oracle.com (Lev Priima) Date: Tue, 01 Apr 2014 18:25:22 +0400 Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag In-Reply-To: <330EABDB-3376-4559-A077-2FD853D3C0FA@oracle.com> References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com> <330EABDB-3376-4559-A077-2FD853D3C0FA@oracle.com> Message-ID: <533ACC52.4000000@oracle.com> Staffan, sun.tools.* API(as well as all tools.jar) does not present in compact1 profile. Lev On 04/01/2014 05:02 PM, Staffan Larsen wrote: > There is already an API for getting / setting flags in sun.tools.attach.HotSpotVirtualMachine. If at all possible, we should reuse that API instead of adding a new one. > > Typical use: > > HotSpotVirtualMachine vm = (HotSpotVirtualMachine) VirtualMachine.attach(pid); > vm.setFlag(?MyFlag?, ?MyValue?); > > There is also an API in sun.management.HotSpotDiagnostic for setting / getting as well as querying for options in JVM. > > Thanks, > /Staffan > > > On 1 apr 2014, at 11:38, Igor Ignatyev wrote: > >> adding hotspot-dev alias. >> >> On 03/31/2014 01:07 AM, Igor Ignatyev wrote: >>> Hi all, >>> >>> Please review the patch which introduces new WhiteBox methods to get and >>> set VM flags. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756 >>> testing: jprt From erik.helin at oracle.com Tue Apr 1 15:02:39 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 01 Apr 2014 17:02:39 +0200 Subject: RFR: 8038934: Remove prefix allocated_ from methods and variables in Metaspace Message-ID: <533AD50F.1070207@oracle.com> Hi all, this patch removes the prefix "allocated_" from some members in the class MetaspaceAux. From the beginning, there were only functions named used_in_bytes() and capacity_in_bytes(). These functions iterated over the ClassLoaderDataGraph to reach all metaspaces and then iterated over the chunk list, which made them quite slow. Later, the functions allocated_used_bytes() and allocated_capacity_bytes() were added that used accounting to be able to return a value faster and without using a lock. When these functions were added, the functions used_bytes() and capacity_bytes() were renamed to used_bytes_slow() and capacity_bytes_slow() to clarify the difference (the slow functions were later made private). Since the old, slow functions end in "_slow", we can drop the prefix "allocated_" from the accounting functions. Webrev: http://cr.openjdk.java.net/~ehelin/8038934/webrev.00/ Thanks, Erik From coleen.phillimore at oracle.com Tue Apr 1 16:32:39 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Apr 2014 12:32:39 -0400 Subject: RFR: 8038934: Remove prefix allocated_ from methods and variables in Metaspace In-Reply-To: <533AD50F.1070207@oracle.com> References: <533AD50F.1070207@oracle.com> Message-ID: <533AEA27.7010804@oracle.com> What happened to renaming MetaspaceAux? Coleen On 04/01/2014 11:02 AM, Erik Helin wrote: > Hi all, > > this patch removes the prefix "allocated_" from some members in the > class MetaspaceAux. > > From the beginning, there were only functions named used_in_bytes() > and capacity_in_bytes(). These functions iterated over the > ClassLoaderDataGraph to reach all metaspaces and then iterated over > the chunk list, which made them quite slow. > > Later, the functions allocated_used_bytes() and > allocated_capacity_bytes() were added that used accounting to be able > to return a value faster and without using a lock. When these > functions were added, the functions used_bytes() and capacity_bytes() > were renamed to used_bytes_slow() and capacity_bytes_slow() to clarify > the difference (the slow functions were later made private). > > Since the old, slow functions end in "_slow", we can drop the prefix > "allocated_" from the accounting functions. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8038934/webrev.00/ > > Thanks, > Erik From ruchika.k at servergy.com Tue Apr 1 20:33:36 2014 From: ruchika.k at servergy.com (Ruchika Kharwar) Date: Tue, 01 Apr 2014 15:33:36 -0500 Subject: hi Message-ID: <533B22A0.6060604@servergy.com> Hi, I am new to hotspot and want to compile the hotspot code base on my ppc platform. I cloned the hotspot code base hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot Are there any pointers to the build instructions for this on a 64b ppc platform ? Thank you Regards Ruchika From monica.b at servergy.com Tue Apr 1 20:52:36 2014 From: monica.b at servergy.com (Monica Beckwith) Date: Tue, 1 Apr 2014 15:52:36 -0500 Subject: hi In-Reply-To: <533B22A0.6060604@servergy.com> References: <533B22A0.6060604@servergy.com> Message-ID: Hi Ruchika :) - I have successfully built Hotspot on our 64 bit system. I can help you offline. :) -Monica On Apr 1, 2014 3:45 PM, "Ruchika Kharwar" wrote: > Hi, > I am new to hotspot and want to compile the hotspot code base on my ppc > platform. > > I cloned the hotspot code base > hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot > > Are there any pointers to the build instructions for this on a 64b ppc > platform ? > > Thank you > Regards > Ruchika > > From vladimir.kozlov at oracle.com Tue Apr 1 20:54:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Apr 2014 13:54:10 -0700 Subject: hi (PPC64 build) In-Reply-To: <533B22A0.6060604@servergy.com> References: <533B22A0.6060604@servergy.com> Message-ID: <533B2772.9090200@oracle.com> It is question for ppc-aix-port-dev at openjdk.java.net Oracle does not support ppc-aix in 7u. Regards, Vladimir On 4/1/14 1:33 PM, Ruchika Kharwar wrote: > Hi, > I am new to hotspot and want to compile the hotspot code base on my ppc > platform. > > I cloned the hotspot code base > hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot > > Are there any pointers to the build instructions for this on a 64b ppc > platform ? > > Thank you > Regards > Ruchika > From ruchika.k at servergy.com Tue Apr 1 21:27:45 2014 From: ruchika.k at servergy.com (Ruchika Kharwar) Date: Tue, 01 Apr 2014 16:27:45 -0500 Subject: hi In-Reply-To: References: <533B22A0.6060604@servergy.com> Message-ID: <533B2F51.3000106@servergy.com> Thanks Monica, I'd like to be able to be build on the 64b to be familiar with the build steps and them move over to the 32b platform. Thank you I'll work with you offline :-) On 4/1/2014 3:52 PM, Monica Beckwith wrote: > > Hi Ruchika :) - > > I have successfully built Hotspot on our 64 bit system. I can help you > offline. > > :) > -Monica > > On Apr 1, 2014 3:45 PM, "Ruchika Kharwar" > wrote: > > Hi, > I am new to hotspot and want to compile the hotspot code base on > my ppc platform. > > I cloned the hotspot code base > hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot > > Are there any pointers to the build instructions for this on a 64b > ppc platform ? > > Thank you > Regards > Ruchika > From jon.masamitsu at oracle.com Tue Apr 1 21:59:09 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 01 Apr 2014 14:59:09 -0700 Subject: RFR: 8038934: Remove prefix allocated_ from methods and variables in Metaspace In-Reply-To: <533AD50F.1070207@oracle.com> References: <533AD50F.1070207@oracle.com> Message-ID: <533B36AD.7050103@oracle.com> Looks good. Thanks for the fix. Reviewed. Jon On 4/1/14 8:02 AM, Erik Helin wrote: > Hi all, > > this patch removes the prefix "allocated_" from some members in the > class MetaspaceAux. > > From the beginning, there were only functions named used_in_bytes() > and capacity_in_bytes(). These functions iterated over the > ClassLoaderDataGraph to reach all metaspaces and then iterated over > the chunk list, which made them quite slow. > > Later, the functions allocated_used_bytes() and > allocated_capacity_bytes() were added that used accounting to be able > to return a value faster and without using a lock. When these > functions were added, the functions used_bytes() and capacity_bytes() > were renamed to used_bytes_slow() and capacity_bytes_slow() to clarify > the difference (the slow functions were later made private). > > Since the old, slow functions end in "_slow", we can drop the prefix > "allocated_" from the accounting functions. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8038934/webrev.00/ > > Thanks, > Erik From bengt.rutisson at oracle.com Wed Apr 2 07:49:51 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 02 Apr 2014 09:49:51 +0200 Subject: RFR(XS) 8037959: BitMap::resize frees old map before copying memory if !in_resource_area In-Reply-To: <2824155.PxfOrAZv3Y@mgerdin03> References: <2631026.IWP4C7s2yl@mgerdin03> <1395831662.2866.9.camel@cirrus> <1477884.olpRURzZOt@mgerdin03> <2824155.PxfOrAZv3Y@mgerdin03> Message-ID: <533BC11F.1060806@oracle.com> Hi Mikael, Looks good. Bengt On 2014-03-28 13:40, Mikael Gerdin wrote: > Hi, > > On Wednesday 26 March 2014 12.25.21 Mikael Gerdin wrote: >> Hi Thomas, >> >> On Wednesday 26 March 2014 12.01.02 Thomas Schatzl wrote: >>> Hi Mikael, >>> >>> On Wed, 2014-03-26 at 11:03 +0100, Mikael Gerdin wrote: >>>> Hi, >>>> >>>> I've come up with a solution where I add a reallocate() method to >>>> ArrayAllocator and have BitMap use that for growing its backing memory. >>>> >>>> New webrev at: http://cr.openjdk.java.net/~mgerdin/8037959/webrev.1 >>>> >>> looks okay, two minor nits: >>> - in the test testResizeNonResource(), is it possible to set the >>> ArrayAllocatorMallocLimit in both cases? Command line flags may set that >>> to a value that makes the first test equal to the second. >> Good point, that way I can make sure that I hit both paths in >> ArrayAllocator. > I've added a test for the default value of ArrayAllocatorMallocLimit and cases > to test both allowing and disallowing malloc use. > > Incremental webrev: http://cr.openjdk.java.net/~mgerdin/8037959/webrev.1.to.2 > Full webrev: http://cr.openjdk.java.net/~mgerdin/8037959/webrev.2 > > /Mikael > >>> - ArrayAllocator::reallocate should verify that this is indeed a >>> reallocation and not called incorrectly, i.e. _addr is non-NULL. >> I was attempting to follow the way libc realloc(ptr, sz) works, if you pass >> ptr as null it degenerates to a malloc(sz). >> >> If I change it to a "pure" realloc I would need to change BitMap to keep >> track of its previous allocations or ask ArrayAllocator if anything is >> already allocated as well since the call from BitMap's constructor to >> resize is also the only way in which BitMap allocates memory. >> >> /Mikael >> >>> Thanks, >>> >>> Thomas From volker.simonis at gmail.com Wed Apr 2 08:08:36 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Apr 2014 10:08:36 +0200 Subject: hi In-Reply-To: <533B2F51.3000106@servergy.com> References: <533B22A0.6060604@servergy.com> <533B2F51.3000106@servergy.com> Message-ID: Hi Ruchika, welcome on board! You can consult hg.openjdk.java.net/ppc-aix-port/jdk7u/raw-file/tip/README-ppc.html Regards, Volker On Tue, Apr 1, 2014 at 11:27 PM, Ruchika Kharwar wrote: > Thanks Monica, > I'd like to be able to be build on the 64b to be familiar with the build > steps and them move over to the 32b platform. > Thank you > I'll work with you offline :-) > > > On 4/1/2014 3:52 PM, Monica Beckwith wrote: >> >> >> Hi Ruchika :) - >> >> I have successfully built Hotspot on our 64 bit system. I can help you >> offline. >> >> :) >> -Monica >> >> On Apr 1, 2014 3:45 PM, "Ruchika Kharwar" > > wrote: >> >> Hi, >> I am new to hotspot and want to compile the hotspot code base on >> my ppc platform. >> >> I cloned the hotspot code base >> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot >> >> Are there any pointers to the build instructions for this on a 64b >> ppc platform ? >> >> Thank you >> Regards >> Ruchika >> > From thomas.schatzl at oracle.com Wed Apr 2 08:24:41 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 02 Apr 2014 10:24:41 +0200 Subject: RFR(XS) 8037959: BitMap::resize frees old map before copying memory if !in_resource_area In-Reply-To: <2824155.PxfOrAZv3Y@mgerdin03> References: <2631026.IWP4C7s2yl@mgerdin03> <1395831662.2866.9.camel@cirrus> <1477884.olpRURzZOt@mgerdin03> <2824155.PxfOrAZv3Y@mgerdin03> Message-ID: <1396427081.3183.1.camel@cirrus> Hi Mikael, On Fri, 2014-03-28 at 13:40 +0100, Mikael Gerdin wrote: > Hi, > On Wednesday 26 March 2014 12.25.21 Mikael Gerdin wrote: > > On Wednesday 26 March 2014 12.01.02 Thomas Schatzl wrote: > > > On Wed, 2014-03-26 at 11:03 +0100, Mikael Gerdin wrote: > > > > > > > > I've come up with a solution where I add a reallocate() method to > > > > ArrayAllocator and have BitMap use that for growing its backing memory. > > > > [...] > > ArrayAllocator. > > I've added a test for the default value of ArrayAllocatorMallocLimit and cases > to test both allowing and disallowing malloc use. > > Incremental webrev: http://cr.openjdk.java.net/~mgerdin/8037959/webrev.1.to.2 > Full webrev: http://cr.openjdk.java.net/~mgerdin/8037959/webrev.2 looks good, thanks. Thomas From staffan.larsen at oracle.com Wed Apr 2 10:27:23 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 2 Apr 2014 12:27:23 +0200 Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag In-Reply-To: <533ACC52.4000000@oracle.com> References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com> <330EABDB-3376-4559-A077-2FD853D3C0FA@oracle.com> <533ACC52.4000000@oracle.com> Message-ID: <5EB6C74E-71DC-47DF-A961-053C39C1B3B4@oracle.com> On 1 apr 2014, at 16:25, Lev Priima wrote: > Staffan, > > sun.tools.* API(as well as all tools.jar) does not present in compact1 profile. I see, that?s a reason to add this. However, do we really need to test this specifically on compact1? I?m not sure what tests you are planning to use this feature for, but if it is for testing code that we don?t believe is special for compact1, then I?m not sure we need to run the tests on compact1. Maybe a stupid optimization. One larger problem here is that this introduced yet another way to set the flags. So far we have three other ways: attachListener.cpp, management.cpp, and arguments.cpp. Currently these three all have duplicated code for verifying the consistency of some of the flags. See the calls to Arguments::verify_MinHeapFreeRatio() for example. If we add yet another way, then that code needs to be copied again. I didn?t like the copying in the first place, but allowed it because we were too lazy at that point to refactor the code? At this point, however, I would like to see that duplication taken care of before we add another way to set the flags. I?m sorry that this is going to make this change harder for you, but we really should only have that code in one place. /Staffan > > Lev > > On 04/01/2014 05:02 PM, Staffan Larsen wrote: >> There is already an API for getting / setting flags in sun.tools.attach.HotSpotVirtualMachine. If at all possible, we should reuse that API instead of adding a new one. >> >> Typical use: >> >> HotSpotVirtualMachine vm = (HotSpotVirtualMachine) VirtualMachine.attach(pid); >> vm.setFlag(?MyFlag?, ?MyValue?); >> >> There is also an API in sun.management.HotSpotDiagnostic for setting / getting as well as querying for options in JVM. >> >> Thanks, >> /Staffan >> >> >> On 1 apr 2014, at 11:38, Igor Ignatyev wrote: >> >>> adding hotspot-dev alias. >>> >>> On 03/31/2014 01:07 AM, Igor Ignatyev wrote: >>>> Hi all, >>>> >>>> Please review the patch which introduces new WhiteBox methods to get and >>>> set VM flags. >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756 >>>> testing: jprt > From igor.ignatyev at oracle.com Wed Apr 2 11:37:00 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 02 Apr 2014 15:37:00 +0400 Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag In-Reply-To: <5EB6C74E-71DC-47DF-A961-053C39C1B3B4@oracle.com> References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com> <330EABDB-3376-4559-A077-2FD853D3C0FA@oracle.com> <533ACC52.4000000@oracle.com> <5EB6C74E-71DC-47DF-A961-053C39C1B3B4@oracle.com> Message-ID: <533BF65C.8080509@oracle.com> Staffan, I'd like not to have verifying of flags' value in these WB methods. Since it's a "Unsupported internal testing API", we don't have to have them. Also I'd like to have a possibility to change even "readonly" flags, which is against verifying logic I guess, e.g. UseCodeCacheFlushing for stress testing of code cache (JDK-8028595). Thanks Igor On 04/02/2014 02:27 PM, Staffan Larsen wrote: > > On 1 apr 2014, at 16:25, Lev Priima wrote: > >> Staffan, >> >> sun.tools.* API(as well as all tools.jar) does not present in compact1 profile. > > I see, that?s a reason to add this. However, do we really need to test this specifically on compact1? I?m not sure what tests you are planning to use this feature for, but if it is for testing code that we don?t believe is special for compact1, then I?m not sure we need to run the tests on compact1. Maybe a stupid optimization. > > One larger problem here is that this introduced yet another way to set the flags. So far we have three other ways: attachListener.cpp, management.cpp, and arguments.cpp. Currently these three all have duplicated code for verifying the consistency of some of the flags. See the calls to Arguments::verify_MinHeapFreeRatio() for example. If we add yet another way, then that code needs to be copied again. I didn?t like the copying in the first place, but allowed it because we were too lazy at that point to refactor the code? At this point, however, I would like to see that duplication taken care of before we add another way to set the flags. I?m sorry that this is going to make this change harder for you, but we really should only have that code in one place. > > /Staffan > > >> >> Lev >> >> On 04/01/2014 05:02 PM, Staffan Larsen wrote: >>> There is already an API for getting / setting flags in sun.tools.attach.HotSpotVirtualMachine. If at all possible, we should reuse that API instead of adding a new one. >>> >>> Typical use: >>> >>> HotSpotVirtualMachine vm = (HotSpotVirtualMachine) VirtualMachine.attach(pid); >>> vm.setFlag(?MyFlag?, ?MyValue?); >>> >>> There is also an API in sun.management.HotSpotDiagnostic for setting / getting as well as querying for options in JVM. >>> >>> Thanks, >>> /Staffan >>> >>> >>> On 1 apr 2014, at 11:38, Igor Ignatyev wrote: >>> >>>> adding hotspot-dev alias. >>>> >>>> On 03/31/2014 01:07 AM, Igor Ignatyev wrote: >>>>> Hi all, >>>>> >>>>> Please review the patch which introduces new WhiteBox methods to get and >>>>> set VM flags. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756 >>>>> testing: jprt >> > From staffan.larsen at oracle.com Wed Apr 2 11:46:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 2 Apr 2014 13:46:02 +0200 Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag In-Reply-To: <533BF65C.8080509@oracle.com> References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com> <330EABDB-3376-4559-A077-2FD853D3C0FA@oracle.com> <533ACC52.4000000@oracle.com> <5EB6C74E-71DC-47DF-A961-053C39C1B3B4@oracle.com> <533BF65C.8080509@oracle.com> Message-ID: <4F499D2F-C30C-421F-89A3-6AC3BF1F99D5@oracle.com> On 2 apr 2014, at 13:37, Igor Ignatyev wrote: > Staffan, > > I'd like not to have verifying of flags' value in these WB methods. Since it's a "Unsupported internal testing API", we don't have to have them. That could work. Until someone uses the WB Api to change some flag that really should cause other flags to be updated as well. But I?ll guess we can take that problem when it comes. > Also I'd like to have a possibility to change even "readonly" flags, which is against verifying logic I guess, e.g. UseCodeCacheFlushing for stress testing of code cache (JDK-8028595). Changing a flag that is not meant to be changed at runtime (not marked as ?manageable? or ?read_write') could cause problems. For example if having the flag set requires some init code to have been run. If the flag is safe for changing at runtime, can?t you just mark it as read_write? /Staffan > > Thanks > Igor > > On 04/02/2014 02:27 PM, Staffan Larsen wrote: >> >> On 1 apr 2014, at 16:25, Lev Priima wrote: >> >>> Staffan, >>> >>> sun.tools.* API(as well as all tools.jar) does not present in compact1 profile. >> >> I see, that?s a reason to add this. However, do we really need to test this specifically on compact1? I?m not sure what tests you are planning to use this feature for, but if it is for testing code that we don?t believe is special for compact1, then I?m not sure we need to run the tests on compact1. Maybe a stupid optimization. >> >> One larger problem here is that this introduced yet another way to set the flags. So far we have three other ways: attachListener.cpp, management.cpp, and arguments.cpp. Currently these three all have duplicated code for verifying the consistency of some of the flags. See the calls to Arguments::verify_MinHeapFreeRatio() for example. If we add yet another way, then that code needs to be copied again. I didn?t like the copying in the first place, but allowed it because we were too lazy at that point to refactor the code? At this point, however, I would like to see that duplication taken care of before we add another way to set the flags. I?m sorry that this is going to make this change harder for you, but we really should only have that code in one place. >> >> /Staffan >> >> >>> >>> Lev >>> >>> On 04/01/2014 05:02 PM, Staffan Larsen wrote: >>>> There is already an API for getting / setting flags in sun.tools.attach.HotSpotVirtualMachine. If at all possible, we should reuse that API instead of adding a new one. >>>> >>>> Typical use: >>>> >>>> HotSpotVirtualMachine vm = (HotSpotVirtualMachine) VirtualMachine.attach(pid); >>>> vm.setFlag(?MyFlag?, ?MyValue?); >>>> >>>> There is also an API in sun.management.HotSpotDiagnostic for setting / getting as well as querying for options in JVM. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> On 1 apr 2014, at 11:38, Igor Ignatyev wrote: >>>> >>>>> adding hotspot-dev alias. >>>>> >>>>> On 03/31/2014 01:07 AM, Igor Ignatyev wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review the patch which introduces new WhiteBox methods to get and >>>>>> set VM flags. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756 >>>>>> testing: jprt >>> >> From nt_mahmood at yahoo.com Wed Apr 2 12:59:40 2014 From: nt_mahmood at yahoo.com (Mahmood Naderan) Date: Wed, 2 Apr 2014 05:59:40 -0700 (PDT) Subject: prefetch instructions in Hotspot In-Reply-To: <5339BA4A.6090107@oracle.com> References: <1396269507.45341.YahooMailNeo@web141603.mail.bf1.yahoo.com> <5339BA4A.6090107@oracle.com> Message-ID: <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> Vlad, I added the decelerations and can be verified as below mahmood at orca:~$ grep -r "public native" /usr/lib/jvm/java-6-openjdk-amd64/sun/misc/Unsafe.java ??? public native void prefetchRead (Object o, long offset); ??? public native void prefetchWrite(Object o, long offset); ??? public native int getInt(Object o, long offset); ??? public native void putInt(Object o, long offset, int x); ??? public native Object getObject(Object o, long offset); ??? public native void putObject(Object o, long offset, Object x); ??? public native boolean getBoolean(Object o, long offset); ??? public native void??? putBoolean(Object o, long offset, boolean x); ??? public native byte??? getByte(Object o, long offset); ??? public native void??? putByte(Object o, long offset, byte x); ??? public native short?? getShort(Object o, long offset); ??? public native void??? putShort(Object o, long offset, short x); ??? public native char??? getChar(Object o, long offset); ??? public native void??? putChar(Object o, long offset, char x); ??? public native long??? getLong(Object o, long offset); ??? public native void??? putLong(Object o, long offset, long x); ??? public native float?? getFloat(Object o, long offset); ??? public native void??? putFloat(Object o, long offset, float x); ??? public native double? getDouble(Object o, long offset); ??? public native void??? putDouble(Object o, long offset, double x); ??? public native byte??? getByte(long address); ??? public native void??? putByte(long address, byte x); ??? public native short?? getShort(long address); ??? public native void??? putShort(long address, short x); ??? public native char??? getChar(long address); ??? public native void??? putChar(long address, char x); ??? public native int???? getInt(long address); ??? public native void??? putInt(long address, int x); ??? public native long??? getLong(long address); ??? public native void??? putLong(long address, long x); ??? public native float?? getFloat(long address); ??? public native void??? putFloat(long address, float x); ??? public native double? getDouble(long address); ??? public native void??? putDouble(long address, double x); ??? public native long getAddress(long address); ??? public native void putAddress(long address, long x); ??? public native long allocateMemory(long bytes); ??? public native long reallocateMemory(long address, long bytes); ??? public native void setMemory(long address, long bytes, byte value); ??? public native void copyMemory(Object srcBase, long srcOffset, ??? public native void freeMemory(long address); ??? public native long staticFieldOffset(Field f); ??? public native long objectFieldOffset(Field f); ??? public native Object staticFieldBase(Field f); ??? public native void ensureClassInitialized(Class c); ??? public native int arrayBaseOffset(Class arrayClass); ??? public native int arrayIndexScale(Class arrayClass); ??? public native int addressSize(); ??? public native int pageSize(); ??? public native Class defineClass(String name, byte[] b, int off, int len, ??? public native Class defineClass(String name, byte[] b, int off, int len); ??? public native Object allocateInstance(Class cls) ??? public native void monitorEnter(Object o); ??? public native void monitorExit(Object o); ??? public native boolean tryMonitorEnter(Object o); ??? public native void throwException(Throwable ee); ??? public native Object getObjectVolatile(Object o, long offset); ??? public native void??? putObjectVolatile(Object o, long offset, Object x); ??? public native int???? getIntVolatile(Object o, long offset); ??? public native void??? putIntVolatile(Object o, long offset, int x); ??? public native boolean getBooleanVolatile(Object o, long offset); ??? public native void??? putBooleanVolatile(Object o, long offset, boolean x); ??? public native byte??? getByteVolatile(Object o, long offset); ??? public native void??? putByteVolatile(Object o, long offset, byte x); ??? public native short?? getShortVolatile(Object o, long offset); ??? public native void??? putShortVolatile(Object o, long offset, short x); ??? public native char??? getCharVolatile(Object o, long offset); ??? public native void??? putCharVolatile(Object o, long offset, char x); ??? public native long??? getLongVolatile(Object o, long offset); ??? public native void??? putLongVolatile(Object o, long offset, long x); ??? public native float?? getFloatVolatile(Object o, long offset); ??? public native void??? putFloatVolatile(Object o, long offset, float x); ??? public native double? getDoubleVolatile(Object o, long offset); ??? public native void??? putDoubleVolatile(Object o, long offset, double x); ??? public native void??? putOrderedObject(Object o, long offset, Object x); ??? public native void??? putOrderedInt(Object o, long offset, int x); ??? public native void??? putOrderedLong(Object o, long offset, long x); ??? public native void unpark(Object thread); ??? public native void park(boolean isAbsolute, long time); ??? public native int getLoadAverage(double[] loadavg, int nelems); mahmood at orca:~$ grep -r "public static" /usr/lib/jvm/java-6-openjdk-amd64/sun/misc/Unsafe.java ??? public static native void prefetchReadStatic (Object o, long offset); ??? public static native void prefetchWriteStatic(Object o, long offset); ??? public static Unsafe getUnsafe() { ??? public static final int INVALID_FIELD_OFFSET?? = -1; ? ? But there is no library_call.cpp in /usr/lib/jvm/java-6-openjdk-amd64 Regards, Mahmood On Monday, March 31, 2014 11:58 PM, Vladimir Kozlov wrote: Hi Mahmood You don't need anything additional if you can build and execute java from sources you have. Do you want to use readPrefetch from java code? If yes, you need to add declarations into jdk/src/share/classessun/misc/Unsafe.java: ? ? public native void prefetchRead (Object o, long offset); ? ? public native void prefetchWrite(Object o, long offset); ? ? public static native void prefetchReadStatic (Object o, long offset); ? ? public static native void prefetchWriteStatic(Object o, long offset); And we already have corresponding intrinsics in Hotspot: hotspot/src/share/vm/opto/library_call.cpp LibraryCallKit::inline_unsafe_prefetch() Regards, Vladimir On 3/31/14 5:38 AM, Mahmood Naderan wrote: > Hi, > > I have some naive questions so any answer to the following questions are appreciated. > > 1- I have open-jdk 1.6 and 1.7. Do I have to install additional things? > > 2- I want to use some intrinsics (readPrefetch) but there are little information on how to use the intrinsics. Is there any example for that? The only thing I see is https://bugs.openjdk.java.net/browse/JDK-2146656 > > > Regards, > Mahmood > From coleen.phillimore at oracle.com Wed Apr 2 14:24:56 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 02 Apr 2014 10:24:56 -0400 Subject: RFR: 8038934: Remove prefix allocated_ from methods and variables in Metaspace In-Reply-To: <533AEA27.7010804@oracle.com> References: <533AD50F.1070207@oracle.com> <533AEA27.7010804@oracle.com> Message-ID: <533C1DB8.2000508@oracle.com> BTW, this looks fine. Coleen On 4/1/14 12:32 PM, Coleen Phillimore wrote: > > What happened to renaming MetaspaceAux? > Coleen > > On 04/01/2014 11:02 AM, Erik Helin wrote: >> Hi all, >> >> this patch removes the prefix "allocated_" from some members in the >> class MetaspaceAux. >> >> From the beginning, there were only functions named used_in_bytes() >> and capacity_in_bytes(). These functions iterated over the >> ClassLoaderDataGraph to reach all metaspaces and then iterated over >> the chunk list, which made them quite slow. >> >> Later, the functions allocated_used_bytes() and >> allocated_capacity_bytes() were added that used accounting to be able >> to return a value faster and without using a lock. When these >> functions were added, the functions used_bytes() and capacity_bytes() >> were renamed to used_bytes_slow() and capacity_bytes_slow() to >> clarify the difference (the slow functions were later made private). >> >> Since the old, slow functions end in "_slow", we can drop the prefix >> "allocated_" from the accounting functions. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8038934/webrev.00/ >> >> Thanks, >> Erik > From vladimir.kozlov at oracle.com Wed Apr 2 16:24:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Apr 2014 09:24:01 -0700 Subject: prefetch instructions in Hotspot In-Reply-To: <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> References: <1396269507.45341.YahooMailNeo@web141603.mail.bf1.yahoo.com> <5339BA4A.6090107@oracle.com> <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> Message-ID: <533C39A1.40100@oracle.com> You need to download Hotspot JVM sources too that is where library_call.cpp. Vladimir On 4/2/14 5:59 AM, Mahmood Naderan wrote: > Vlad, > I added the decelerations and can be verified as below > > mahmood at orca:~$ grep -r "public native" /usr/lib/jvm/java-6-openjdk-amd64/sun/misc/Unsafe.java > public native void prefetchRead (Object o, long offset); > public native void prefetchWrite(Object o, long offset); > public native int getInt(Object o, long offset); > public native void putInt(Object o, long offset, int x); > public native Object getObject(Object o, long offset); > public native void putObject(Object o, long offset, Object x); > public native boolean getBoolean(Object o, long offset); > public native void putBoolean(Object o, long offset, boolean x); > public native byte getByte(Object o, long offset); > public native void putByte(Object o, long offset, byte x); > public native short getShort(Object o, long offset); > public native void putShort(Object o, long offset, short x); > public native char getChar(Object o, long offset); > public native void putChar(Object o, long offset, char x); > public native long getLong(Object o, long offset); > public native void putLong(Object o, long offset, long x); > public native float getFloat(Object o, long offset); > public native void putFloat(Object o, long offset, float x); > public native double getDouble(Object o, long offset); > public native void putDouble(Object o, long offset, double x); > public native byte getByte(long address); > public native void putByte(long address, byte x); > public native short getShort(long address); > public native void putShort(long address, short x); > public native char getChar(long address); > public native void putChar(long address, char x); > public native int getInt(long address); > public native void putInt(long address, int x); > public native long getLong(long address); > public native void putLong(long address, long x); > public native float getFloat(long address); > public native void putFloat(long address, float x); > public native double getDouble(long address); > public native void putDouble(long address, double x); > public native long getAddress(long address); > public native void putAddress(long address, long x); > public native long allocateMemory(long bytes); > public native long reallocateMemory(long address, long bytes); > public native void setMemory(long address, long bytes, byte value); > public native void copyMemory(Object srcBase, long srcOffset, > public native void freeMemory(long address); > public native long staticFieldOffset(Field f); > public native long objectFieldOffset(Field f); > public native Object staticFieldBase(Field f); > public native void ensureClassInitialized(Class c); > public native int arrayBaseOffset(Class arrayClass); > public native int arrayIndexScale(Class arrayClass); > public native int addressSize(); > public native int pageSize(); > public native Class defineClass(String name, byte[] b, int off, int len, > public native Class defineClass(String name, byte[] b, int off, int len); > public native Object allocateInstance(Class cls) > public native void monitorEnter(Object o); > public native void monitorExit(Object o); > public native boolean tryMonitorEnter(Object o); > public native void throwException(Throwable ee); > public native Object getObjectVolatile(Object o, long offset); > public native void putObjectVolatile(Object o, long offset, Object x); > public native int getIntVolatile(Object o, long offset); > public native void putIntVolatile(Object o, long offset, int x); > public native boolean getBooleanVolatile(Object o, long offset); > public native void putBooleanVolatile(Object o, long offset, boolean x); > public native byte getByteVolatile(Object o, long offset); > public native void putByteVolatile(Object o, long offset, byte x); > public native short getShortVolatile(Object o, long offset); > public native void putShortVolatile(Object o, long offset, short x); > public native char getCharVolatile(Object o, long offset); > public native void putCharVolatile(Object o, long offset, char x); > public native long getLongVolatile(Object o, long offset); > public native void putLongVolatile(Object o, long offset, long x); > public native float getFloatVolatile(Object o, long offset); > public native void putFloatVolatile(Object o, long offset, float x); > public native double getDoubleVolatile(Object o, long offset); > public native void putDoubleVolatile(Object o, long offset, double x); > public native void putOrderedObject(Object o, long offset, Object x); > public native void putOrderedInt(Object o, long offset, int x); > public native void putOrderedLong(Object o, long offset, long x); > public native void unpark(Object thread); > public native void park(boolean isAbsolute, long time); > public native int getLoadAverage(double[] loadavg, int nelems); > > mahmood at orca:~$ grep -r "public static" /usr/lib/jvm/java-6-openjdk-amd64/sun/misc/Unsafe.java > public static native void prefetchReadStatic (Object o, long offset); > public static native void prefetchWriteStatic(Object o, long offset); > public static Unsafe getUnsafe() { > public static final int INVALID_FIELD_OFFSET = -1; > > > > > But there is no library_call.cpp in /usr/lib/jvm/java-6-openjdk-amd64 > > > > Regards, > Mahmood > On Monday, March 31, 2014 11:58 PM, Vladimir Kozlov wrote: > > Hi Mahmood > > You don't need anything additional if you can build and execute java from sources you have. > > Do you want to use readPrefetch from java code? > If yes, you need to add declarations into jdk/src/share/classessun/misc/Unsafe.java: > > public native void prefetchRead (Object o, long offset); > public native void prefetchWrite(Object o, long offset); > public static native void prefetchReadStatic (Object o, long offset); > public static native void prefetchWriteStatic(Object o, long offset); > > And we already have corresponding intrinsics in Hotspot: > > hotspot/src/share/vm/opto/library_call.cpp > LibraryCallKit::inline_unsafe_prefetch() > > Regards, > Vladimir > > > > On 3/31/14 5:38 AM, Mahmood Naderan wrote: >> Hi, >> >> I have some naive questions so any answer to the following questions are appreciated. >> >> 1- I have open-jdk 1.6 and 1.7. Do I have to install additional things? >> >> 2- I want to use some intrinsics (readPrefetch) but there are little information on how to use the intrinsics. Is there any example for that? The only thing I see is https://bugs.openjdk.java.net/browse/JDK-2146656 >> >> >> Regards, >> Mahmood >> From nt_mahmood at yahoo.com Wed Apr 2 17:15:40 2014 From: nt_mahmood at yahoo.com (Mahmood Naderan) Date: Wed, 2 Apr 2014 10:15:40 -0700 (PDT) Subject: prefetch instructions in Hotspot In-Reply-To: <533C39A1.40100@oracle.com> References: <1396269507.45341.YahooMailNeo@web141603.mail.bf1.yahoo.com> <5339BA4A.6090107@oracle.com> <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> <533C39A1.40100@oracle.com> Message-ID: <1396458940.56395.YahooMailNeo@web141605.mail.bf1.yahoo.com> Right... got it. Since I am more familiar with C++ than Java, just want to know if I have to recompile/rebuild or update the jdk since I have modified Unsafe.java. Here is my simple code which fails $ cat Arr.java public class Arr { ? public static void main(String[] args) ? { ??? int [] a = new int[3]; ??? a[0] = 10; a[1] = 20; a[2] = 30; ??? for (int i = 0; i < 3; i++) ??? { ????? sun.misc.Unsafe.prefetchRead(a[i]); ????? System.out.println(a[i]); ??? } ? } } $ javac Arr.java Arr.java:11: warning: sun.misc.Unsafe is internal proprietary API and may be removed in a future release ????? sun.misc.Unsafe.prefetchRead(a[i]); ????????????? ^ Arr.java:11: cannot find symbol symbol? : method prefetchRead(int) location: class sun.misc.Unsafe ????? sun.misc.Unsafe.prefetchRead(a[i]); ???????????????????? ^ 1 error 1 warning What did I miss? ? Regards, Mahmood On Wednesday, April 2, 2014 8:54 PM, Vladimir Kozlov wrote: >You need to download Hotspot JVM sources too that is where library_call.cpp. > >Vladimir From vladimir.kozlov at oracle.com Wed Apr 2 17:18:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Apr 2014 10:18:51 -0700 Subject: prefetch instructions in Hotspot In-Reply-To: <1396458940.56395.YahooMailNeo@web141605.mail.bf1.yahoo.com> References: <1396269507.45341.YahooMailNeo@web141603.mail.bf1.yahoo.com> <5339BA4A.6090107@oracle.com> <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> <533C39A1.40100@oracle.com> <1396458940.56395.YahooMailNeo@web141605.mail.bf1.yahoo.com> Message-ID: <533C467B.50400@oracle.com> Yes, you need to rebuild jdk after you modified Unsafe.java. Vladimir On 4/2/14 10:15 AM, Mahmood Naderan wrote: > Right... got it. > Since I am more familiar with C++ than Java, just want to know if I have to recompile/rebuild or update the jdk since I have modified Unsafe.java. Here is my simple code which fails > > $ cat Arr.java > public class Arr > { > public static void main(String[] args) > { > int [] a = new int[3]; > a[0] = 10; a[1] = 20; a[2] = 30; > for (int i = 0; i < 3; i++) > { > sun.misc.Unsafe.prefetchRead(a[i]); > System.out.println(a[i]); > } > } > } > > > > $ javac Arr.java > Arr.java:11: warning: sun.misc.Unsafe is internal proprietary API and may be removed in a future release > sun.misc.Unsafe.prefetchRead(a[i]); > ^ > Arr.java:11: cannot find symbol > symbol : method prefetchRead(int) > location: class sun.misc.Unsafe > sun.misc.Unsafe.prefetchRead(a[i]); > ^ > 1 error > 1 warning > > > > What did I miss? > > > Regards, > Mahmood > > > On Wednesday, April 2, 2014 8:54 PM, Vladimir Kozlov wrote: > >> You need to download Hotspot JVM sources too that is where library_call.cpp. >> >> Vladimir From vladimir.kozlov at oracle.com Wed Apr 2 19:00:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Apr 2014 12:00:20 -0700 Subject: [8u20] RFR (S) 8038633: crash in VM_Version::get_processor_features() on startup Message-ID: <533C5E44.3000003@oracle.com> 8u20 backport request. These changes were pushed into jdk9 2 days ago and nightly testing shows no problems. Changes from jdk9 applied to 8u without conflicts. http://cr.openjdk.java.net/~kvn/8038633/webrev.01/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/be5c9920f0e1 https://bugs.openjdk.java.net/browse/JDK-8038633 Thanks, Vladimir From nt_mahmood at yahoo.com Wed Apr 2 19:19:38 2014 From: nt_mahmood at yahoo.com (Mahmood Naderan) Date: Wed, 2 Apr 2014 12:19:38 -0700 (PDT) Subject: prefetch instructions in Hotspot In-Reply-To: <533C467B.50400@oracle.com> References: <1396269507.45341.YahooMailNeo@web141603.mail.bf1.yahoo.com> <5339BA4A.6090107@oracle.com> <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> <533C39A1.40100@oracle.com> <1396458940.56395.YahooMailNeo@web141605.mail.bf1.yahoo.com> <533C467B.50400@oracle.com> Message-ID: <1396466378.3561.YahooMailNeo@web141605.mail.bf1.yahoo.com> OK I downloaded jdk source using ?? hg clone http://hg.openjdk.java.net/jdk6/jdk6 openjdk6 ?? cd openjdk6 && sh ./get_source.sh Then I added the declarations into jdk/src/share/classes/sun/misc/Unsafe.java. I have to say that I removed the jdk packages from apt. Now, before running 'make' in the jdk folder, do I have to point Hotspot location? How? ? Regards, Mahmood On Wednesday, April 2, 2014 9:49 PM, Vladimir Kozlov wrote: >Yes, you need to rebuild jdk after you modified Unsafe.java. > >Vladimir From igor.veresov at oracle.com Wed Apr 2 20:43:21 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Apr 2014 13:43:21 -0700 Subject: [8u20] RFR (S) 8038633: crash in VM_Version::get_processor_features() on startup In-Reply-To: <533C5E44.3000003@oracle.com> References: <533C5E44.3000003@oracle.com> Message-ID: Looks good. igor On Apr 2, 2014, at 12:00 PM, Vladimir Kozlov wrote: > 8u20 backport request. These changes were pushed into jdk9 2 days ago and nightly testing shows no problems. > > Changes from jdk9 applied to 8u without conflicts. > > http://cr.openjdk.java.net/~kvn/8038633/webrev.01/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/be5c9920f0e1 > https://bugs.openjdk.java.net/browse/JDK-8038633 > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Wed Apr 2 21:13:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Apr 2014 14:13:26 -0700 Subject: [8u20] RFR (S) 8038633: crash in VM_Version::get_processor_features() on startup In-Reply-To: References: <533C5E44.3000003@oracle.com> Message-ID: <533C7D76.9020807@oracle.com> Thank you, Igor Vladimir On 4/2/14 1:43 PM, Igor Veresov wrote: > Looks good. > > igor > > On Apr 2, 2014, at 12:00 PM, Vladimir Kozlov wrote: > >> 8u20 backport request. These changes were pushed into jdk9 2 days ago and nightly testing shows no problems. >> >> Changes from jdk9 applied to 8u without conflicts. >> >> http://cr.openjdk.java.net/~kvn/8038633/webrev.01/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/be5c9920f0e1 >> https://bugs.openjdk.java.net/browse/JDK-8038633 >> >> Thanks, >> Vladimir >> > From vladimir.kozlov at oracle.com Wed Apr 2 23:30:15 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Apr 2014 16:30:15 -0700 Subject: [8u20] Request for approval: 8036767: PPC64: Support for little endian execution model Message-ID: <533C9D87.9030301@oracle.com> Please approve backport of ppc64 changes to support little endian. Changes will be pushed through Hotspot repository jdk8u/hs-dev because they have Hotspot changes. Changes applied cleanly (hotspot and top) but I have to regenerate generated-configure.sh (open and closed parts). Bug: https://bugs.openjdk.java.net/browse/JDK-8036767 JDK 9 Changesets: http://hg.openjdk.java.net/jdk9/hs-comp/rev/28e272c4b976 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d Reviews: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013193.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013206.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013287.html Thanks, Vladimir From igor.veresov at oracle.com Wed Apr 2 23:56:51 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Apr 2014 16:56:51 -0700 Subject: [8u20] Request for approval: 8036767: PPC64: Support for little endian execution model In-Reply-To: <533C9D87.9030301@oracle.com> References: <533C9D87.9030301@oracle.com> Message-ID: <64227108-ED03-43B3-9440-FD12FB74E757@oracle.com> Looks fine to me. igor On Apr 2, 2014, at 4:30 PM, Vladimir Kozlov wrote: > Please approve backport of ppc64 changes to support little endian. > Changes will be pushed through Hotspot repository jdk8u/hs-dev because they have Hotspot changes. > > Changes applied cleanly (hotspot and top) but I have to regenerate generated-configure.sh (open and closed parts). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8036767 > > JDK 9 Changesets: > http://hg.openjdk.java.net/jdk9/hs-comp/rev/28e272c4b976 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d > > Reviews: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013193.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013206.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013287.html > > Thanks, > Vladimir From igor.veresov at oracle.com Thu Apr 3 00:11:20 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Apr 2014 17:11:20 -0700 Subject: [8u20] RFR: 8039043: Implicit null check is in the wrong place in C1 -UseCompressedOops Message-ID: 8u20 backport request. The change applied cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8039043 Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2e29e3e5dde2 Webrev: http://cr.openjdk.java.net/~iveresov/8039043/webrev.01/ Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/013906.html Thanks! igor From vladimir.kozlov at oracle.com Thu Apr 3 00:15:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Apr 2014 17:15:41 -0700 Subject: [8u20] RFR: 8039043: Implicit null check is in the wrong place in C1 -UseCompressedOops In-Reply-To: References: Message-ID: <533CA82D.9090904@oracle.com> Looks good. Thanks, Vladimir On 4/2/14 5:11 PM, Igor Veresov wrote: > 8u20 backport request. The change applied cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8039043 > Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2e29e3e5dde2 > Webrev: http://cr.openjdk.java.net/~iveresov/8039043/webrev.01/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/013906.html > > Thanks! > igor > From igor.veresov at oracle.com Thu Apr 3 01:59:37 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Apr 2014 18:59:37 -0700 Subject: [8u20] RFR: 8039043: Implicit null check is in the wrong place in C1 -UseCompressedOops In-Reply-To: <533CA82D.9090904@oracle.com> References: <533CA82D.9090904@oracle.com> Message-ID: Thanks! igor On Apr 2, 2014, at 5:15 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 4/2/14 5:11 PM, Igor Veresov wrote: >> 8u20 backport request. The change applied cleanly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039043 >> Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2e29e3e5dde2 >> Webrev: http://cr.openjdk.java.net/~iveresov/8039043/webrev.01/ >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/013906.html >> >> Thanks! >> igor >> From sean.coffey at oracle.com Thu Apr 3 09:15:04 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 03 Apr 2014 10:15:04 +0100 Subject: [8u20] Request for approval: 8036767: PPC64: Support for little endian execution model In-Reply-To: <64227108-ED03-43B3-9440-FD12FB74E757@oracle.com> References: <533C9D87.9030301@oracle.com> <64227108-ED03-43B3-9440-FD12FB74E757@oracle.com> Message-ID: <533D2698.2020908@oracle.com> Vladimir, no jdk8u-dev approval is necessary for pushing hotspot changes to the hotspot team forest. Alejandro will look after the approval request when he does the bulk push into jdk8u master. regards, Sean. On 03/04/2014 00:56, Igor Veresov wrote: > Looks fine to me. > > igor > > On Apr 2, 2014, at 4:30 PM, Vladimir Kozlov wrote: > >> Please approve backport of ppc64 changes to support little endian. >> Changes will be pushed through Hotspot repository jdk8u/hs-dev because they have Hotspot changes. >> >> Changes applied cleanly (hotspot and top) but I have to regenerate generated-configure.sh (open and closed parts). >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8036767 >> >> JDK 9 Changesets: >> http://hg.openjdk.java.net/jdk9/hs-comp/rev/28e272c4b976 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d >> >> Reviews: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013193.html >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013206.html >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013287.html >> >> Thanks, >> Vladimir From ivan.gerasimov at oracle.com Thu Apr 3 12:23:19 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Apr 2014 16:23:19 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS Message-ID: <533D52B7.2090406@oracle.com> Hi everyone! At the start time hotspot is scanning a couple of environment variables (JAVA_TOOL_OPTIONS and _JAVA_OPTIONS) and picks up the options from them. If these were found, a message is printed to the stderr about what's going on. Sometimes this message is not desirable and we need to have a way to turn it off. May I please have a review for a simple fix which introduces another option (-XX:+SuppressJavaOptsOutput), which when specified among the other options in the env variable, will suppress the message output. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039152 WEBREV: http://cr.openjdk.java.net/~igerasim/8039152/0/webrev/ Sincerely yours, Ivan From staffan.larsen at oracle.com Thu Apr 3 12:36:26 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Apr 2014 14:36:26 +0200 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D52B7.2090406@oracle.com> References: <533D52B7.2090406@oracle.com> Message-ID: <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> My initial reaction is: Nooo! Please don?t add more options and special cases to the parsing of the command line and startup options. My slightly more polished reaction is: can you provide a good use case where this is needed? The options and the message has been around for many years and not caused too much alarm. /Staffan On 3 apr 2014, at 14:23, Ivan Gerasimov wrote: > Hi everyone! > > At the start time hotspot is scanning a couple of environment variables (JAVA_TOOL_OPTIONS and _JAVA_OPTIONS) and picks up the options from them. > If these were found, a message is printed to the stderr about what's going on. > Sometimes this message is not desirable and we need to have a way to turn it off. > > May I please have a review for a simple fix which introduces another option (-XX:+SuppressJavaOptsOutput), which when specified among the other options in the env variable, will suppress the message output. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039152 > WEBREV: http://cr.openjdk.java.net/~igerasim/8039152/0/webrev/ > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Thu Apr 3 12:46:06 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Apr 2014 16:46:06 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> Message-ID: <533D580E.7030108@oracle.com> Thanks Staffan for the comments. On 03.04.2014 16:36, Staffan Larsen wrote: > My initial reaction is: Nooo! Please don?t add more options and special cases to the parsing of the command line and startup options. > > My slightly more polished reaction is: can you provide a good use case where this is needed? The options and the message has been around for many years and not caused too much alarm. We've got a customer who is annoyed by this message. They use the env variable to pass additional options to the jvm. Currently they have to add some additional processing of the output to scrape the stderr and get rid of this message. Sincerely yours, Ivan > /Staffan > > On 3 apr 2014, at 14:23, Ivan Gerasimov wrote: > >> Hi everyone! >> >> At the start time hotspot is scanning a couple of environment variables (JAVA_TOOL_OPTIONS and _JAVA_OPTIONS) and picks up the options from them. >> If these were found, a message is printed to the stderr about what's going on. >> Sometimes this message is not desirable and we need to have a way to turn it off. >> >> May I please have a review for a simple fix which introduces another option (-XX:+SuppressJavaOptsOutput), which when specified among the other options in the env variable, will suppress the message output. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039152 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8039152/0/webrev/ >> >> Sincerely yours, >> Ivan > > From staffan.larsen at oracle.com Thu Apr 3 12:50:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Apr 2014 14:50:42 +0200 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D580E.7030108@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> Message-ID: <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> On 3 apr 2014, at 14:46, Ivan Gerasimov wrote: > Thanks Staffan for the comments. > > On 03.04.2014 16:36, Staffan Larsen wrote: >> My initial reaction is: Nooo! Please don?t add more options and special cases to the parsing of the command line and startup options. >> >> My slightly more polished reaction is: can you provide a good use case where this is needed? The options and the message has been around for many years and not caused too much alarm. > We've got a customer who is annoyed by this message. > They use the env variable to pass additional options to the jvm. > Currently they have to add some additional processing of the output to scrape the stderr and get rid of this message. It sounds like they have a good solution in place and no change is required on our part. Seriously, we have way too many options already and we cannot please everyone by adding options for every single use case. Sorry for being the annoying guy, /Staffan > > Sincerely yours, > Ivan > >> /Staffan >> >> On 3 apr 2014, at 14:23, Ivan Gerasimov wrote: >> >>> Hi everyone! >>> >>> At the start time hotspot is scanning a couple of environment variables (JAVA_TOOL_OPTIONS and _JAVA_OPTIONS) and picks up the options from them. >>> If these were found, a message is printed to the stderr about what's going on. >>> Sometimes this message is not desirable and we need to have a way to turn it off. >>> >>> May I please have a review for a simple fix which introduces another option (-XX:+SuppressJavaOptsOutput), which when specified among the other options in the env variable, will suppress the message output. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039152 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8039152/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >> >> > From dalibor.topic at oracle.com Thu Apr 3 14:06:12 2014 From: dalibor.topic at oracle.com (dalibor.topic at oracle.com) Date: Thu, 3 Apr 2014 16:06:12 +0200 Subject: prefetch instructions in Hotspot In-Reply-To: <1396466378.3561.YahooMailNeo@web141605.mail.bf1.yahoo.com> References: <1396269507.45341.YahooMailNeo@web141603.mail.bf1.yahoo.com> <5339BA4A.6090107@oracle.com> <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> <533C39A1.40100@oracle.com> <1396458940.56395.YahooMailNeo@web141605.mail.bf1.yahoo.com> <533C467B.50400@oracle.com> <1396466378.3561.YahooMailNeo@web141605.mail.bf1.yahoo.com> Message-ID: See top level file Readme-build.html for instructions. -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile:+491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment > On 02.04.2014, at 21:19, Mahmood Naderan wrote: > > OK I downloaded jdk source using > > hg clone http://hg.openjdk.java.net/jdk6/jdk6 openjdk6 > cd openjdk6 && sh ./get_source.sh > > Then I added the declarations into jdk/src/share/classes/sun/misc/Unsafe.java. I have to say that I removed the jdk packages from apt. > > Now, before running 'make' in the jdk folder, do I have to point Hotspot location? How? > > > Regards, > Mahmood > > >> On Wednesday, April 2, 2014 9:49 PM, Vladimir Kozlov wrote: >> >> Yes, you need to rebuild jdk after you modified Unsafe.java. >> >> Vladimir From mikael.gerdin at oracle.com Thu Apr 3 14:10:21 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 03 Apr 2014 16:10:21 +0200 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> References: <533D52B7.2090406@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> Message-ID: <4754048.Rs9h0gtBi0@mgerdin03> On Thursday 03 April 2014 14.50.42 Staffan Larsen wrote: > On 3 apr 2014, at 14:46, Ivan Gerasimov wrote: > > Thanks Staffan for the comments. > > > > On 03.04.2014 16:36, Staffan Larsen wrote: > >> My initial reaction is: Nooo! Please don?t add more options and special > >> cases to the parsing of the command line and startup options. > >> > >> My slightly more polished reaction is: can you provide a good use case > >> where this is needed? The options and the message has been around for > >> many years and not caused too much alarm.> > > We've got a customer who is annoyed by this message. > > They use the env variable to pass additional options to the jvm. > > Currently they have to add some additional processing of the output to > > scrape the stderr and get rid of this message. > It sounds like they have a good solution in place and no change is required > on our part. > > Seriously, we have way too many options already and we cannot please > everyone by adding options for every single use case. I agree with Staffan. If they don't want the output from using JAVA_TOOL_OPTIONS and _JAVA_OPTIONS then they can pass the options as command line options. If they don't want that they can create a text file with all their flags and use -XX:Flags=filename to set their VM flags. /Mikael > > Sorry for being the annoying guy, > /Staffan > > > Sincerely yours, > > Ivan > > > >> /Staffan > >> > >> On 3 apr 2014, at 14:23, Ivan Gerasimov wrote: > >>> Hi everyone! > >>> > >>> At the start time hotspot is scanning a couple of environment variables > >>> (JAVA_TOOL_OPTIONS and _JAVA_OPTIONS) and picks up the options from > >>> them. If these were found, a message is printed to the stderr about > >>> what's going on. Sometimes this message is not desirable and we need to > >>> have a way to turn it off. > >>> > >>> May I please have a review for a simple fix which introduces another > >>> option (-XX:+SuppressJavaOptsOutput), which when specified among the > >>> other options in the env variable, will suppress the message output. > >>> > >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039152 > >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8039152/0/webrev/ > >>> > >>> Sincerely yours, > >>> Ivan From ivan.gerasimov at oracle.com Thu Apr 3 14:21:05 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Apr 2014 18:21:05 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <4754048.Rs9h0gtBi0@mgerdin03> References: <533D52B7.2090406@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <4754048.Rs9h0gtBi0@mgerdin03> Message-ID: <533D6E51.800@oracle.com> Thanks Mikael for the comment! > I agree with Staffan. > If they don't want the output from using JAVA_TOOL_OPTIONS and _JAVA_OPTIONS > then they can pass the options as command line options. > If they don't want that they can create a text file with all their flags and > use -XX:Flags=filename to set their VM flags. Passing the command line options may become complicated when you need to pass the same common options to child processes across the system. Using the JAVA_TOOL_OPTIONS variable was a workaround, which worked, but had its own drawback -- the message printed to the stderr, which has to be processed by each caller. The -XX:Flags option still has to be passed to every newly created process somehow, so I don't see how it can help. Sincerely yours, Ivan From ivan.gerasimov at oracle.com Thu Apr 3 14:28:41 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Apr 2014 18:28:41 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> Message-ID: <533D7019.7090006@oracle.com> Thanks Staffan! >> We've got a customer who is annoyed by this message. >> They use the env variable to pass additional options to the jvm. >> Currently they have to add some additional processing of the output to scrape the stderr and get rid of this message. > It sounds like they have a good solution in place and no change is required on our part. > > Seriously, we have way too many options already and we cannot please everyone by adding options for every single use case. The solution they use now isn't good, that's why they complained. The proposed option might be useful by its own, in the case anyone else will be annoyed by the message about picking up the env variable content. Please also note, that it's not meant to be a command line option. It will only be used as a part of the env variable content. Your point that there are already plenty of other options is true, but doesn't really suggests anything for this particular situation. Sincerely yours, Ivan From staffan.larsen at oracle.com Thu Apr 3 14:40:16 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Apr 2014 16:40:16 +0200 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D7019.7090006@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> Message-ID: <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> On 3 apr 2014, at 16:28, Ivan Gerasimov wrote: > Thanks Staffan! > >>> We've got a customer who is annoyed by this message. >>> They use the env variable to pass additional options to the jvm. >>> Currently they have to add some additional processing of the output to scrape the stderr and get rid of this message. >> It sounds like they have a good solution in place and no change is required on our part. >> >> Seriously, we have way too many options already and we cannot please everyone by adding options for every single use case. > > The solution they use now isn't good, that's why they complained. > > The proposed option might be useful by its own, in the case anyone else will be annoyed by the message about picking up the env variable content. > Please also note, that it's not meant to be a command line option. > It will only be used as a part of the env variable content. > > Your point that there are already plenty of other options is true, but doesn't really suggests anything for this particular situation. I suggest not solving this situation. As I said: "we cannot please everyone by adding options for every single use case.? Sorry, /Staffan > > Sincerely yours, > Ivan > From vladimir.kozlov at oracle.com Thu Apr 3 14:45:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Apr 2014 07:45:19 -0700 Subject: [8u20] Request for approval: 8036767: PPC64: Support for little endian execution model In-Reply-To: <533D2698.2020908@oracle.com> References: <533C9D87.9030301@oracle.com> <64227108-ED03-43B3-9440-FD12FB74E757@oracle.com> <533D2698.2020908@oracle.com> Message-ID: <533D73FF.8000502@oracle.com> Thank you, Sean On 4/3/14 2:15 AM, Se?n Coffey wrote: > Vladimir, > > no jdk8u-dev approval is necessary for pushing hotspot changes to the hotspot team forest. Alejandro will look after the > approval request when he does the bulk push into jdk8u master. It was not clear for me if this rule is applied only to hotspot changes or whole forest. Thanks, Vladimir > > regards, > Sean. > > On 03/04/2014 00:56, Igor Veresov wrote: >> Looks fine to me. >> >> igor >> >> On Apr 2, 2014, at 4:30 PM, Vladimir Kozlov wrote: >> >>> Please approve backport of ppc64 changes to support little endian. >>> Changes will be pushed through Hotspot repository jdk8u/hs-dev because they have Hotspot changes. >>> >>> Changes applied cleanly (hotspot and top) but I have to regenerate generated-configure.sh (open and closed parts). >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8036767 >>> >>> JDK 9 Changesets: >>> http://hg.openjdk.java.net/jdk9/hs-comp/rev/28e272c4b976 >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d >>> >>> Reviews: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013193.html >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013206.html >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013287.html >>> >>> Thanks, >>> Vladimir > From daniel.daugherty at oracle.com Thu Apr 3 15:06:20 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Apr 2014 09:06:20 -0600 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> Message-ID: <533D78EC.2010702@oracle.com> On 4/3/14 8:40 AM, Staffan Larsen wrote: > On 3 apr 2014, at 16:28, Ivan Gerasimov wrote: > >> Thanks Staffan! >> >>>> We've got a customer who is annoyed by this message. >>>> They use the env variable to pass additional options to the jvm. >>>> Currently they have to add some additional processing of the output to scrape the stderr and get rid of this message. >>> It sounds like they have a good solution in place and no change is required on our part. >>> >>> Seriously, we have way too many options already and we cannot please everyone by adding options for every single use case. >> The solution they use now isn't good, that's why they complained. >> >> The proposed option might be useful by its own, in the case anyone else will be annoyed by the message about picking up the env variable content. >> Please also note, that it's not meant to be a command line option. >> It will only be used as a part of the env variable content. >> >> Your point that there are already plenty of other options is true, but doesn't really suggests anything for this particular situation. > I suggest not solving this situation. As I said: "we cannot please everyone by adding options for every single use case.? I've added a somewhat long evaluation to the bug report. My summary line: I strongly recommend that we don't try to change this behavior. Dan > > Sorry, > /Staffan > >> Sincerely yours, >> Ivan >> From ivan.gerasimov at oracle.com Thu Apr 3 15:30:50 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Apr 2014 19:30:50 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> Message-ID: <533D7EAA.9000908@oracle.com> Thanks Staffan for your opinion! On 03.04.2014 18:40, Staffan Larsen wrote: > On 3 apr 2014, at 16:28, Ivan Gerasimov wrote: > >> Thanks Staffan! >> >>>> We've got a customer who is annoyed by this message. >>>> They use the env variable to pass additional options to the jvm. >>>> Currently they have to add some additional processing of the output to scrape the stderr and get rid of this message. >>> It sounds like they have a good solution in place and no change is required on our part. >>> >>> Seriously, we have way too many options already and we cannot please everyone by adding options for every single use case. >> The solution they use now isn't good, that's why they complained. >> >> The proposed option might be useful by its own, in the case anyone else will be annoyed by the message about picking up the env variable content. >> Please also note, that it's not meant to be a command line option. >> It will only be used as a part of the env variable content. >> >> Your point that there are already plenty of other options is true, but doesn't really suggests anything for this particular situation. > I suggest not solving this situation. As I said: "we cannot please everyone by adding options for every single use case.? > Let's see if we can find an alternative approach to not solving it :) There are two env variables which can be used to pass the options: standard JAVA_TOOL_OPTIONS and non-standard _JAVA_OPTIONS. What if we introduce another variable, say _QUIET_JAVA_OPTIONS, which will act in the same way, but with no additional noise? This would be even easier to implement and use. What would you say about another env var instead of another option? Sincerely yours, Ivan From daniel.daugherty at oracle.com Thu Apr 3 15:39:38 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Apr 2014 09:39:38 -0600 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D7EAA.9000908@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> <533D7EAA.9000908@oracle.com> Message-ID: <533D80BA.60304@oracle.com> On 4/3/14 9:30 AM, Ivan Gerasimov wrote: > Thanks Staffan for your opinion! > > On 03.04.2014 18:40, Staffan Larsen wrote: >> On 3 apr 2014, at 16:28, Ivan Gerasimov >> wrote: >> >>> Thanks Staffan! >>> >>>>> We've got a customer who is annoyed by this message. >>>>> They use the env variable to pass additional options to the jvm. >>>>> Currently they have to add some additional processing of the >>>>> output to scrape the stderr and get rid of this message. >>>> It sounds like they have a good solution in place and no change is >>>> required on our part. >>>> >>>> Seriously, we have way too many options already and we cannot >>>> please everyone by adding options for every single use case. >>> The solution they use now isn't good, that's why they complained. >>> >>> The proposed option might be useful by its own, in the case anyone >>> else will be annoyed by the message about picking up the env >>> variable content. >>> Please also note, that it's not meant to be a command line option. >>> It will only be used as a part of the env variable content. >>> >>> Your point that there are already plenty of other options is true, >>> but doesn't really suggests anything for this particular situation. >> I suggest not solving this situation. As I said: "we cannot please >> everyone by adding options for every single use case.? >> > > Let's see if we can find an alternative approach to not solving it :) > > There are two env variables which can be used to pass the options: > standard JAVA_TOOL_OPTIONS and non-standard _JAVA_OPTIONS. > What if we introduce another variable, say _QUIET_JAVA_OPTIONS, which > will act in the same way, but with no additional noise? > This would be even easier to implement and use. > > What would you say about another env var instead of another option? Ivan, The VM squawks about JAVA_TOOL_OPTIONS and _JAVA_OPTIONS being used because they are dangerous. Adding an option that would allow the same mechanism to be used without warning would be... well... even more dangerous. Please read the note that I added to your bug. Dan > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Thu Apr 3 15:55:53 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Apr 2014 19:55:53 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D78EC.2010702@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> <533D78EC.2010702@oracle.com> Message-ID: <533D8489.5050409@oracle.com> Thank you Daniel for your complete analysis! If I get it correctly, your main point is that we should always warn the user about using a dangerous way to pass the options. While I tend to agree with it respecting to the standard JAVA_TOOL_OPTIONS, I think if we can make a compromise dealing with a non-standard env variable. If a user is using a non-standard variable, one should already be aware of the danger. Introducing a new variable which will specifically be said to be quiet would not break the existing behavior. Sincerely yours, Ivan On 03.04.2014 19:06, Daniel D. Daugherty wrote: > On 4/3/14 8:40 AM, Staffan Larsen wrote: >> On 3 apr 2014, at 16:28, Ivan Gerasimov >> wrote: >> >>> Thanks Staffan! >>> >>>>> We've got a customer who is annoyed by this message. >>>>> They use the env variable to pass additional options to the jvm. >>>>> Currently they have to add some additional processing of the >>>>> output to scrape the stderr and get rid of this message. >>>> It sounds like they have a good solution in place and no change is >>>> required on our part. >>>> >>>> Seriously, we have way too many options already and we cannot >>>> please everyone by adding options for every single use case. >>> The solution they use now isn't good, that's why they complained. >>> >>> The proposed option might be useful by its own, in the case anyone >>> else will be annoyed by the message about picking up the env >>> variable content. >>> Please also note, that it's not meant to be a command line option. >>> It will only be used as a part of the env variable content. >>> >>> Your point that there are already plenty of other options is true, >>> but doesn't really suggests anything for this particular situation. >> I suggest not solving this situation. As I said: "we cannot please >> everyone by adding options for every single use case.? > > I've added a somewhat long evaluation to the bug report. > > My summary line: > > I strongly recommend that we don't try to change this behavior. > > Dan > > >> >> Sorry, >> /Staffan >> >>> Sincerely yours, >>> Ivan >>> > > > From daniel.daugherty at oracle.com Thu Apr 3 16:01:26 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Apr 2014 10:01:26 -0600 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D8489.5050409@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> <533D78EC.2010702@oracle.com> <533D8489.5050409@oracle.com> Message-ID: <533D85D6.10709@oracle.com> On 4/3/14 9:55 AM, Ivan Gerasimov wrote: > Thank you Daniel for your complete analysis! > > If I get it correctly, your main point is that we should always warn > the user about using a dangerous way to pass the options. > While I tend to agree with it respecting to the standard > JAVA_TOOL_OPTIONS, I think if we can make a compromise dealing with a > non-standard env variable. > If a user is using a non-standard variable, one should already be > aware of the danger. > > Introducing a new variable which will specifically be said to be quiet > would not break the existing behavior. The problem is that the new variable would not be limited to use by people aware of the danger. The new variable could be used by anyone wanting a quiet avenue of attack into the VM... Dan > > Sincerely yours, > Ivan > > On 03.04.2014 19:06, Daniel D. Daugherty wrote: >> On 4/3/14 8:40 AM, Staffan Larsen wrote: >>> On 3 apr 2014, at 16:28, Ivan Gerasimov >>> wrote: >>> >>>> Thanks Staffan! >>>> >>>>>> We've got a customer who is annoyed by this message. >>>>>> They use the env variable to pass additional options to the jvm. >>>>>> Currently they have to add some additional processing of the >>>>>> output to scrape the stderr and get rid of this message. >>>>> It sounds like they have a good solution in place and no change is >>>>> required on our part. >>>>> >>>>> Seriously, we have way too many options already and we cannot >>>>> please everyone by adding options for every single use case. >>>> The solution they use now isn't good, that's why they complained. >>>> >>>> The proposed option might be useful by its own, in the case anyone >>>> else will be annoyed by the message about picking up the env >>>> variable content. >>>> Please also note, that it's not meant to be a command line option. >>>> It will only be used as a part of the env variable content. >>>> >>>> Your point that there are already plenty of other options is true, >>>> but doesn't really suggests anything for this particular situation. >>> I suggest not solving this situation. As I said: "we cannot please >>> everyone by adding options for every single use case.? >> >> I've added a somewhat long evaluation to the bug report. >> >> My summary line: >> >> I strongly recommend that we don't try to change this behavior. >> >> Dan >> >> >>> >>> Sorry, >>> /Staffan >>> >>>> Sincerely yours, >>>> Ivan >>>> >> >> >> > From ivan.gerasimov at oracle.com Thu Apr 3 16:03:19 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Apr 2014 20:03:19 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D80BA.60304@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> <533D7EAA.9000908@oracle.com> <533D80BA.60304@oracle.com> Message-ID: <533D8647.30803@oracle.com> On 03.04.2014 19:39, Daniel D. Daugherty wrote: > On 4/3/14 9:30 AM, Ivan Gerasimov wrote: >> Thanks Staffan for your opinion! >> >> On 03.04.2014 18:40, Staffan Larsen wrote: >>> On 3 apr 2014, at 16:28, Ivan Gerasimov >>> wrote: >>> >>>> Thanks Staffan! >>>> >>>>>> We've got a customer who is annoyed by this message. >>>>>> They use the env variable to pass additional options to the jvm. >>>>>> Currently they have to add some additional processing of the >>>>>> output to scrape the stderr and get rid of this message. >>>>> It sounds like they have a good solution in place and no change is >>>>> required on our part. >>>>> >>>>> Seriously, we have way too many options already and we cannot >>>>> please everyone by adding options for every single use case. >>>> The solution they use now isn't good, that's why they complained. >>>> >>>> The proposed option might be useful by its own, in the case anyone >>>> else will be annoyed by the message about picking up the env >>>> variable content. >>>> Please also note, that it's not meant to be a command line option. >>>> It will only be used as a part of the env variable content. >>>> >>>> Your point that there are already plenty of other options is true, >>>> but doesn't really suggests anything for this particular situation. >>> I suggest not solving this situation. As I said: "we cannot please >>> everyone by adding options for every single use case.? >>> >> >> Let's see if we can find an alternative approach to not solving it :) >> >> There are two env variables which can be used to pass the options: >> standard JAVA_TOOL_OPTIONS and non-standard _JAVA_OPTIONS. >> What if we introduce another variable, say _QUIET_JAVA_OPTIONS, which >> will act in the same way, but with no additional noise? >> This would be even easier to implement and use. >> >> What would you say about another env var instead of another option? > > Ivan, > > The VM squawks about JAVA_TOOL_OPTIONS and _JAVA_OPTIONS being used > because they are dangerous. Adding an option that would allow the > same mechanism to be used without warning would be... well... > even more dangerous. > The customer already has a way to get rid of the warning: Preprocess the output and filter the warning out. This approach is ugly, hard to make general and leads to errors. I think we should provide an option to achieve the same effect but without that hard work around. Sincerely yours, Ivan > Please read the note that I added to your bug. > > Dan > > >> >> Sincerely yours, >> Ivan > > > From ivan.gerasimov at oracle.com Thu Apr 3 17:01:38 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Apr 2014 21:01:38 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D85D6.10709@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> <533D78EC.2010702@oracle.com> <533D8489.5050409@oracle.com> <533D85D6.10709@oracle.com> Message-ID: <533D93F2.3070705@oracle.com> Thank you Daniel! On 03.04.2014 20:01, Daniel D. Daugherty wrote: > On 4/3/14 9:55 AM, Ivan Gerasimov wrote: >> Thank you Daniel for your complete analysis! >> >> If I get it correctly, your main point is that we should always warn >> the user about using a dangerous way to pass the options. >> While I tend to agree with it respecting to the standard >> JAVA_TOOL_OPTIONS, I think if we can make a compromise dealing with a >> non-standard env variable. >> If a user is using a non-standard variable, one should already be >> aware of the danger. >> >> Introducing a new variable which will specifically be said to be >> quiet would not break the existing behavior. > > The problem is that the new variable would not be limited to use > by people aware of the danger. The new variable could be used by > anyone wanting a quiet avenue of attack into the VM... > Yes, it's a good point. I need some more time to think about it. Sincerely yours, Ivan From sean.coffey at oracle.com Thu Apr 3 17:16:59 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 03 Apr 2014 18:16:59 +0100 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D8647.30803@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> <533D7EAA.9000908@oracle.com> <533D80BA.60304@oracle.com> <533D8647.30803@oracle.com> Message-ID: <533D978B.8060403@oracle.com> On 03/04/2014 17:03, Ivan Gerasimov wrote: >> Ivan, >> >> The VM squawks about JAVA_TOOL_OPTIONS and _JAVA_OPTIONS being used >> because they are dangerous. Adding an option that would allow the >> same mechanism to be used without warning would be... well... >> even more dangerous. >> > The customer already has a way to get rid of the warning: Preprocess > the output and filter the warning out. > This approach is ugly, hard to make general and leads to errors. > > I think we should provide an option to achieve the same effect but > without that hard work around. I think this suggested enhancement would be a plus to many enterprises. The issue stems from the submitter running into issues with how the user.home property works on windows vista and later. Fix was addressed in JDK-6519127 and JDK8 but can't be backported to 7u due to behavioural differences. Given the enterprise and many applications, a per application system property to set the user.home property wasn't suitable. _JAVA_OPTIONS makes for easier deployment of this property. Now - with submitter having to use _JAVA_OPTIONS, it spews out such settings to stderr. Other applications are scraping output from stderr. Yes - not a great design, but that's the way it is. This new option would surely be a useful addition for anyone running into such an issue. Is there a better way without them re-writing application code ? regards, Sean. > > Sincerely yours, > Ivan From zhengyu.gu at oracle.com Thu Apr 3 17:35:00 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 03 Apr 2014 13:35:00 -0400 Subject: [8u20] Request for approval: 8026300 VM warning: increase O_BUFLEN in ostream.hpp -- output truncated occurs with fastdebug VM when printing flags Message-ID: <533D9BC4.3040601@oracle.com> Please approve backport this simple fix on print format string. The backport should go to hotspot repository (jdk8u/hs-dev) Bug: https://bugs.openjdk.java.net/browse/JDK-8026300 JDK9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b7cd330fd5b6 Webrev: http://cr.openjdk.java.net/~zgu/8026300/webrev.00/ Review: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-December/010259.html http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-December/010393.html Thanks, -Zhengyu From kevin.walls at oracle.com Thu Apr 3 18:10:51 2014 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Thu, 03 Apr 2014 18:10:51 +0000 Subject: hg: hsx/jdk7u/hotspot: 8038785: hot workaround fix for a crash in C2 compiler at Node::rematerialize Message-ID: <201404031810.s33IAqWP009873@aojmv0008> Changeset: 7801eaea32d2 Author: sgabdura Date: 2014-04-03 07:33 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/7801eaea32d2 8038785: hot workaround fix for a crash in C2 compiler at Node::rematerialize Summary: This fix will introduce a performance regression. It should be reverted after proper fix will be found. Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp From staffan.larsen at oracle.com Thu Apr 3 18:27:20 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Apr 2014 20:27:20 +0200 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D978B.8060403@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> <533D7EAA.9000908@oracle.com> <533D80BA.60304@oracle.com> <533D8647.30803@oracle.com> <533D978B.8060403@oracle.com> Message-ID: With ?Unified JVM Logging? (JEP-158) we plan to make sure that all warnings/error and other output from the JVM can be redirected to files or muted. I think that is the real solution we are looking for here. That feature is currently planned for JDK 9. /Staffan On 3 apr 2014, at 19:16, Se?n Coffey wrote: > > On 03/04/2014 17:03, Ivan Gerasimov wrote: >>> Ivan, >>> >>> The VM squawks about JAVA_TOOL_OPTIONS and _JAVA_OPTIONS being used >>> because they are dangerous. Adding an option that would allow the >>> same mechanism to be used without warning would be... well... >>> even more dangerous. >>> >> The customer already has a way to get rid of the warning: Preprocess the output and filter the warning out. >> This approach is ugly, hard to make general and leads to errors. >> >> I think we should provide an option to achieve the same effect but without that hard work around. > I think this suggested enhancement would be a plus to many enterprises. The issue stems from the submitter running into issues with how the user.home property works on windows vista and later. Fix was addressed in JDK-6519127 and JDK8 but can't be backported to 7u due to behavioural differences. Given the enterprise and many applications, a per application system property to set the user.home property wasn't suitable. _JAVA_OPTIONS makes for easier deployment of this property. > > Now - with submitter having to use _JAVA_OPTIONS, it spews out such settings to stderr. Other applications are scraping output from stderr. Yes - not a great design, but that's the way it is. > > This new option would surely be a useful addition for anyone running into such an issue. Is there a better way without them re-writing application code ? > > regards, > Sean. >> >> Sincerely yours, >> Ivan > From christian.tornqvist at oracle.com Thu Apr 3 19:58:33 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 3 Apr 2014 15:58:33 -0400 Subject: [8u20] Request for approval: 8026300 VM warning: increase O_BUFLEN in ostream.hpp -- output truncated occurs with fastdebug VM when printing flags In-Reply-To: <533D9BC4.3040601@oracle.com> References: <533D9BC4.3040601@oracle.com> Message-ID: <016e01cf4f77$18670160$49350420$@oracle.com> Looks good. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Zhengyu Gu Sent: Thursday, April 3, 2014 1:35 PM To: jdk8u-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: [8u20] Request for approval: 8026300 VM warning: increase O_BUFLEN in ostream.hpp -- output truncated occurs with fastdebug VM when printing flags Please approve backport this simple fix on print format string. The backport should go to hotspot repository (jdk8u/hs-dev) Bug: https://bugs.openjdk.java.net/browse/JDK-8026300 JDK9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b7cd330fd5b6 Webrev: http://cr.openjdk.java.net/~zgu/8026300/webrev.00/ Review: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-December/010259.html http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-December/010393.html Thanks, -Zhengyu From ivan.gerasimov at oracle.com Thu Apr 3 20:04:59 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 04 Apr 2014 00:04:59 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> <533D7EAA.9000908@oracle.com> <533D80BA.60304@oracle.com> <533D8647.30803@oracle.com> <533D978B.8060403@oracle.com> Message-ID: <533DBEEB.5010404@oracle.com> On 03.04.2014 22:27, Staffan Larsen wrote: > With ?Unified JVM Logging? (JEP-158) we plan to make sure that all warnings/error and other output from the JVM can be redirected to files or muted. I think that is the real solution we are looking for here. That feature is currently planned for JDK 9. What we were asked for is a solution for jdk7u. I don't think Unified JVM Logging is going to be ported back to jdk7 once it is implemented. Sincerely yours, Ivan > /Staffan > > On 3 apr 2014, at 19:16, Se?n Coffey wrote: > >> On 03/04/2014 17:03, Ivan Gerasimov wrote: >>>> Ivan, >>>> >>>> The VM squawks about JAVA_TOOL_OPTIONS and _JAVA_OPTIONS being used >>>> because they are dangerous. Adding an option that would allow the >>>> same mechanism to be used without warning would be... well... >>>> even more dangerous. >>>> >>> The customer already has a way to get rid of the warning: Preprocess the output and filter the warning out. >>> This approach is ugly, hard to make general and leads to errors. >>> >>> I think we should provide an option to achieve the same effect but without that hard work around. >> I think this suggested enhancement would be a plus to many enterprises. The issue stems from the submitter running into issues with how the user.home property works on windows vista and later. Fix was addressed in JDK-6519127 and JDK8 but can't be backported to 7u due to behavioural differences. Given the enterprise and many applications, a per application system property to set the user.home property wasn't suitable. _JAVA_OPTIONS makes for easier deployment of this property. >> >> Now - with submitter having to use _JAVA_OPTIONS, it spews out such settings to stderr. Other applications are scraping output from stderr. Yes - not a great design, but that's the way it is. >> >> This new option would surely be a useful addition for anyone running into such an issue. Is there a better way without them re-writing application code ? >> >> regards, >> Sean. >>> Sincerely yours, >>> Ivan > > From sean.coffey at oracle.com Thu Apr 3 22:52:54 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 03 Apr 2014 23:52:54 +0100 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533DBEEB.5010404@oracle.com> References: <533D52B7.2090406@oracle.com> <69DE602D-86ED-413F-8A08-E569FF474B20@oracle.com> <533D580E.7030108@oracle.com> <2E63825B-F4D9-4E86-9C55-DD8AD5E21D68@oracle.com> <533D7019.7090006@oracle.com> <0BA03000-0653-4FCD-AE4E-9699A2174DE3@oracle.com> <533D7EAA.9000908@oracle.com> <533D80BA.60304@oracle.com> <533D8647.30803@oracle.com> <533D978B.8060403@oracle.com> <533DBEEB.5010404@oracle.com> Message-ID: <533DE646.5010808@oracle.com> On 03/04/2014 21:04, Ivan Gerasimov wrote: > > On 03.04.2014 22:27, Staffan Larsen wrote: >> With ?Unified JVM Logging? (JEP-158) we plan to make sure that all >> warnings/error and other output from the JVM can be redirected to >> files or muted. I think that is the real solution we are looking for >> here. That feature is currently planned for JDK 9. > > What we were asked for is a solution for jdk7u. > I don't think Unified JVM Logging is going to be ported back to jdk7 > once it is implemented. Agreed. Do we have a choice of just fixing this in 7u and 8u ? Probably safer to cover all codelines. regards, Sean. > > Sincerely yours, > Ivan > >> /Staffan >> >> On 3 apr 2014, at 19:16, Se?n Coffey wrote: >> >>> On 03/04/2014 17:03, Ivan Gerasimov wrote: >>>>> Ivan, >>>>> >>>>> The VM squawks about JAVA_TOOL_OPTIONS and _JAVA_OPTIONS being used >>>>> because they are dangerous. Adding an option that would allow the >>>>> same mechanism to be used without warning would be... well... >>>>> even more dangerous. >>>>> >>>> The customer already has a way to get rid of the warning: >>>> Preprocess the output and filter the warning out. >>>> This approach is ugly, hard to make general and leads to errors. >>>> >>>> I think we should provide an option to achieve the same effect but >>>> without that hard work around. >>> I think this suggested enhancement would be a plus to many >>> enterprises. The issue stems from the submitter running into issues >>> with how the user.home property works on windows vista and later. >>> Fix was addressed in JDK-6519127 and JDK8 but can't be backported to >>> 7u due to behavioural differences. Given the enterprise and many >>> applications, a per application system property to set the user.home >>> property wasn't suitable. _JAVA_OPTIONS makes for easier deployment >>> of this property. >>> >>> Now - with submitter having to use _JAVA_OPTIONS, it spews out such >>> settings to stderr. Other applications are scraping output from >>> stderr. Yes - not a great design, but that's the way it is. >>> >>> This new option would surely be a useful addition for anyone running >>> into such an issue. Is there a better way without them re-writing >>> application code ? >>> >>> regards, >>> Sean. >>>> Sincerely yours, >>>> Ivan >> >> > From kirk at kodewerk.com Fri Apr 4 07:56:12 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 4 Apr 2014 09:56:12 +0200 Subject: spurious reportings of System.gc()??? In-Reply-To: <201404031810.s33IAqWP009873@aojmv0008> References: <201404031810.s33IAqWP009873@aojmv0008> Message-ID: <932DDB72-56DA-43B3-A9BD-46260AEE4C07@kodewerk.com> Hi all, I?ve been puzzling over this?. 0.925: [GC (System.gc()) Desired Survivor size 11010048 bytes, new threshold 7 (max 15) [PSYoungGen: 19838->4025K(76800K)] 19838K->4097K(251392K), 0.0047450 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] Aside from 3 cases of Allocation Failure, System.gc() is the only cause that is ever printed for every other GC record. Am I to assume this is a bug as my understanding is that this cause is only suppose to be printed when the application or RMI triggers a collection. Regards, Kirk PS apologies for not providing JVM version, I?m not sure what it is at the moment but I?m assuming 7 but it might be from a preview version of 8. From per.liden at oracle.com Fri Apr 4 10:28:38 2014 From: per.liden at oracle.com (Per Liden) Date: Fri, 04 Apr 2014 12:28:38 +0200 Subject: spurious reportings of System.gc()??? In-Reply-To: <932DDB72-56DA-43B3-A9BD-46260AEE4C07@kodewerk.com> References: <201404031810.s33IAqWP009873@aojmv0008> <932DDB72-56DA-43B3-A9BD-46260AEE4C07@kodewerk.com> Message-ID: <533E8956.60005@oracle.com> Hi, On 04/04/2014 09:56 AM, Kirk Pepperdine wrote: > Hi all, > > I?ve been puzzling over this?. > > 0.925: [GC (System.gc()) > Desired Survivor size 11010048 bytes, new threshold 7 (max 15) > [PSYoungGen: 19838->4025K(76800K)] 19838K->4097K(251392K), 0.0047450 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] > > Aside from 3 cases of Allocation Failure, System.gc() is the only cause that is ever printed for every other GC record. Am I to assume this is a bug as my understanding is that this cause is only suppose to be printed when the application or RMI triggers a collection. There are at least two uses of System.gc() inside the JDK itself. The first case is heavy use of ByteBuffer.allocateDirect(), which could cause a System.gc() if reference processing isn't keeping up and you're bumping into the MaxDirectMemorySize limit. I think the other case is heavy use of FileChannel.transferFrom/To(). Maybe that's what you're seeing? cheer, /Per > > Regards, > Kirk > > PS apologies for not providing JVM version, I?m not sure what it is at the moment but I?m assuming 7 but it might be from a preview version of 8. > From kirk at kodewerk.com Fri Apr 4 10:52:28 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 4 Apr 2014 12:52:28 +0200 Subject: spurious reportings of System.gc()??? In-Reply-To: <533E8956.60005@oracle.com> References: <201404031810.s33IAqWP009873@aojmv0008> <932DDB72-56DA-43B3-A9BD-46260AEE4C07@kodewerk.com> <533E8956.60005@oracle.com> Message-ID: Hi Per, Thanks for the response. The confusion here is that the System.gc() isn?t being reported as a Full GC. In fact this all looks like a young gen collection. Regards, Kirk On Apr 4, 2014, at 12:28 PM, Per Liden wrote: > Hi, > > On 04/04/2014 09:56 AM, Kirk Pepperdine wrote: >> Hi all, >> >> I?ve been puzzling over this?. >> >> 0.925: [GC (System.gc()) >> Desired Survivor size 11010048 bytes, new threshold 7 (max 15) >> [PSYoungGen: 19838->4025K(76800K)] 19838K->4097K(251392K), 0.0047450 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] >> >> Aside from 3 cases of Allocation Failure, System.gc() is the only cause that is ever printed for every other GC record. Am I to assume this is a bug as my understanding is that this cause is only suppose to be printed when the application or RMI triggers a collection. > > There are at least two uses of System.gc() inside the JDK itself. The first case is heavy use of ByteBuffer.allocateDirect(), which could cause a System.gc() if reference processing isn't keeping up and you're bumping into the MaxDirectMemorySize limit. I think the other case is heavy use of FileChannel.transferFrom/To(). Maybe that's what you're seeing? > > cheer, > /Per > >> >> Regards, >> Kirk >> >> PS apologies for not providing JVM version, I?m not sure what it is at the moment but I?m assuming 7 but it might be from a preview version of 8. >> > From Alan.Bateman at oracle.com Fri Apr 4 11:14:07 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Apr 2014 12:14:07 +0100 Subject: spurious reportings of System.gc()??? In-Reply-To: <533E8956.60005@oracle.com> References: <201404031810.s33IAqWP009873@aojmv0008> <932DDB72-56DA-43B3-A9BD-46260AEE4C07@kodewerk.com> <533E8956.60005@oracle.com> Message-ID: <533E93FF.7090306@oracle.com> On 04/04/2014 11:28, Per Liden wrote: > > There are at least two uses of System.gc() inside the JDK itself. The > first case is heavy use of ByteBuffer.allocateDirect(), which could > cause a System.gc() if reference processing isn't keeping up and > you're bumping into the MaxDirectMemorySize limit. I think the other > case is heavy use of FileChannel.transferFrom/To(). Maybe that's what > you're seeing? I suspect you meant FileChannel.map rather than the transferXXX methods (the transfer methods do use memory mapping for some cases but they unmap so the memory doesn't increase). One thing to mention here is that direct and mapped buffers have instrumentation so if this is JDK 7 or newer then their usage can be monitored with JMX tools. The other one that comes up periodically is RMI as the distributed GC does result in explicit calls to System.gc, Kirk probably knows about that one. -Alan. From kirk at kodewerk.com Fri Apr 4 11:23:58 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 4 Apr 2014 13:23:58 +0200 Subject: spurious reportings of System.gc()??? In-Reply-To: <533E93FF.7090306@oracle.com> References: <201404031810.s33IAqWP009873@aojmv0008> <932DDB72-56DA-43B3-A9BD-46260AEE4C07@kodewerk.com> <533E8956.60005@oracle.com> <533E93FF.7090306@oracle.com> Message-ID: Hi Alan, Thanks for your response. > >> >> There are at least two uses of System.gc() inside the JDK itself. The first case is heavy use of ByteBuffer.allocateDirect(), which could cause a System.gc() if reference processing isn't keeping up and you're bumping into the MaxDirectMemorySize limit. I think the other case is heavy use of FileChannel.transferFrom/To(). Maybe that's what you're seeing? > I suspect you meant FileChannel.map rather than the transferXXX methods (the transfer methods do use memory mapping for some cases but they unmap so the memory doesn't increase). One thing to mention here is that direct and mapped buffers have instrumentation so if this is JDK 7 or newer then their usage can be monitored with JMX tools. > > The other one that comes up periodically is RMI as the distributed GC does result in explicit calls to System.gc, Kirk probably knows about that one. I mentioned RMI in my original email along with the call developers can make to System.gc() or Runtime.gc(). However I would expect that these calls result in a Full collection but all the log records (with the exception of the records labeled as Full GC) look like this; 0.925: [GC (System.gc()) Desired Survivor size 11010048 bytes, new threshold 7 (max 15) [PSYoungGen: 19838->4025K(76800K)] 19838K->4097K(251392K), 0.0047450 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] That is a young gen collection and hence my confusion. To be clear my question is; has this call to System.gc() resulted in a young gen collection (and not a full) or is the cause wrong or should this record be treated as a Full GC? Regards, Kirk PS I?ve attached the zipped up log file. From nt_mahmood at yahoo.com Fri Apr 4 11:24:43 2014 From: nt_mahmood at yahoo.com (Mahmood Naderan) Date: Fri, 4 Apr 2014 04:24:43 -0700 (PDT) Subject: prefetch instructions in Hotspot In-Reply-To: References: <1396269507.45341.YahooMailNeo@web141603.mail.bf1.yahoo.com> <5339BA4A.6090107@oracle.com> <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> <533C39A1.40100@oracle.com> <1396458940.56395.YahooMailNeo@web141605.mail.bf1.yahoo.com> <533C467B.50400@oracle.com> <1396466378.3561.YahooMailNeo@web141605.mail.bf1.yahoo.com> Message-ID: <1396610683.77833.YahooMailNeo@web141603.mail.bf1.yahoo.com> OK guys. Thanks to Vladimir and others I added the declarations and compiled JDK6 successfully. Then based on the test example provided here (http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/d98807bff770/test/compiler/6968348/Test6968348.java) I wrote the following code to see if I am using the prefetchRead correctly. import sun.misc.Unsafe; import java.lang.reflect.*; public class Arr { ? static int [] a = new int[3]; ? static Unsafe unsafe; ? static int baseOffset, indexScale; ? public static void main(String[] args)? throws Exception { ??? a[0] = 10; ??? a[1] = 20; ??? a[2] = 30; ??? ??? Class c = Arr.class.getClassLoader().loadClass("sun.misc.Unsafe"); ??? Field f = c.getDeclaredField("theUnsafe"); ??? f.setAccessible(true); ??? unsafe = (Unsafe)f.get(c); ??? ??? baseOffset = unsafe.arrayBaseOffset(int[].class); ??? indexScale = unsafe.arrayIndexScale(int[].class); ??? for (int i = 0; i < 3; i++)? { ????? unsafe.prefetchReadStatic(a, baseOffset+indexScale*i); ????? System.out.println(a[i]); ??? } ? } } Running the code shows everything is fine and the values are printed on the screen. Just need a confirmation; is that a correct usage of prefetchRead()? Is that all? ? Regards, Mahmood On Thursday, April 3, 2014 6:36 PM, "dalibor.topic at oracle.com" wrote: >See top level file Readme-build.html for instructions. > >-->Oracle >Dalibor Topic | Principal Product Manager >Phone:?+494089091214 | Mobile:+491737185961 >Oracle Java Platform Group > >ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > >ORACLE Deutschland B.V. & Co. KG >Hauptverwaltung:?Riesstr. 25, D-80992 M?nchen >Registergericht: Amtsgericht M?nchen, HRA 95603 >Gesch?ftsf?hrer: J?rgen Kunz > >Komplement?rin: ORACLE Deutschland Verwaltung B.V. >Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >Handelsregister der Handelskammer Midden-Niederlande, Nr.?30143697 >Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > >Green Oracle Oracle is committed to developing practices and products that help protect the environment From jaromir.hamala at gmail.com Fri Apr 4 11:32:48 2014 From: jaromir.hamala at gmail.com (Jaromir Hamala) Date: Fri, 4 Apr 2014 12:32:48 +0100 Subject: spurious reportings of System.gc()??? In-Reply-To: References: <201404031810.s33IAqWP009873@aojmv0008> <932DDB72-56DA-43B3-A9BD-46260AEE4C07@kodewerk.com> <533E8956.60005@oracle.com> <533E93FF.7090306@oracle.com> Message-ID: Hi Kirk On Fri, Apr 4, 2014 at 12:23 PM, Kirk Pepperdine wrote: > > I mentioned RMI in my original email along with the call developers can > make to System.gc() or Runtime.gc(). However I would expect that these > calls result in a Full collection but all the log records (with the > exception of the records labeled as Full GC) look like this; [...] What are the exceptions look like? I'm running System.gc() on Java8 and I'm getting this in the GC log: [GC (System.gc()) [PSYoungGen: 41984K->624K(611840K)] 41984K->632K(2010112K), 0.0010397 secs] [Times: user=0.00 sys=0.01, real=0.00 secs] [Full GC (System.gc()) [PSYoungGen: 624K->0K(611840K)] [ParOldGen: 8K->500K(1398272K)] 632K->500K(2010112K), [Metaspace: 2926K->2926K(1056768K)], 0.0056682 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] There is indeed a Full GC line, but there is a line with Young GC results as well. The attachment has been probably swallowed by the mailing list. Cheers, Jaromir From per.liden at oracle.com Fri Apr 4 11:35:51 2014 From: per.liden at oracle.com (Per Liden) Date: Fri, 04 Apr 2014 13:35:51 +0200 Subject: spurious reportings of System.gc()??? In-Reply-To: References: <201404031810.s33IAqWP009873@aojmv0008> <932DDB72-56DA-43B3-A9BD-46260AEE4C07@kodewerk.com> <533E8956.60005@oracle.com> <533E93FF.7090306@oracle.com> Message-ID: <533E9917.9010004@oracle.com> Hi, On 04/04/2014 01:23 PM, Kirk Pepperdine wrote: > Hi Alan, > > Thanks for your response. > >> >>> >>> There are at least two uses of System.gc() inside the JDK itself. The first case is heavy use of ByteBuffer.allocateDirect(), which could cause a System.gc() if reference processing isn't keeping up and you're bumping into the MaxDirectMemorySize limit. I think the other case is heavy use of FileChannel.transferFrom/To(). Maybe that's what you're seeing? >> I suspect you meant FileChannel.map rather than the transferXXX methods (the transfer methods do use memory mapping for some cases but they unmap so the memory doesn't increase). One thing to mention here is that direct and mapped buffers have instrumentation so if this is JDK 7 or newer then their usage can be monitored with JMX tools. >> >> The other one that comes up periodically is RMI as the distributed GC does result in explicit calls to System.gc, Kirk probably knows about that one. > > I mentioned RMI in my original email along with the call developers can make to System.gc() or Runtime.gc(). However I would expect that these calls result in a Full collection but all the log records (with the exception of the records labeled as Full GC) look like this; > > 0.925: [GC (System.gc()) > Desired Survivor size 11010048 bytes, new threshold 7 (max 15) > [PSYoungGen: 19838->4025K(76800K)] 19838K->4097K(251392K), 0.0047450 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] > > That is a young gen collection and hence my confusion. > > To be clear my question is; has this call to System.gc() resulted in a young gen collection (and not a full) or is the cause wrong or should this record be treated as a Full GC? Ah, now I understand what you mean. This is the default behavior for ParallelGC. You can disable the young collections in these cases with -XX:-ScavengeBeforeFullGC. cheers, /Per From kevin.walls at oracle.com Fri Apr 4 14:21:10 2014 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Fri, 04 Apr 2014 14:21:10 +0000 Subject: hg: hsx/jdk7u/hotspot: 8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR Message-ID: <201404041421.s34ELBUY026273@aojmv0008> Changeset: ee18e60e7e8d Author: sgabdura Date: 2014-04-04 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ee18e60e7e8d 8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR Summary: Check that the _java_thread parameter is valid when it is possible that the JavaThread has exited after the initial checks were made in generated/jvmtifiles/jvmtiEnter.cpp: jvmti_GetCurrentContendedMonitor() Reviewed-by: dcubed, dsamersoff ! src/share/vm/prims/jvmtiEnvBase.hpp From yasuenag at gmail.com Fri Apr 4 14:55:54 2014 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 04 Apr 2014 23:55:54 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <20140303190102.GE2045@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53144E4D.8080606@redhat.com> <20140303190102.GE2045@redhat.com> Message-ID: <533EC7FA.9030700@gmail.com> Hi all, > This should fix it: > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb I updated OpenJDK8 to java-1.8.0-openjdk-1.8.0.0-0.34.b132.fc20 . However, debuginfo files are not contained ELF sections for debugging. (I checked libjvm.so.debug and libnio.so.debug with "readelf -S") According to SPEC file of OpenJDK8, following options are passed to "make": ----------------- make \ SCTP_WERROR= \ DEBUG_BINARIES=true \ FULL_DEBUG_SYMBOLS=0 \ STRIP_POLICY=none \ ALT_OBJCOPY=/does_not_exist \ LOG=trace \ all ----------------- I ran "grep" with DEBUG_BINARIES in jdk makefiles, however I could not find it. At least, DEBUG_BINARIES does not affect to jdk sources, and also does not affect to hotspot sources. I've succeeded to make binaries which are contained debuginfo as following: http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html $ make images STRIP_POLICY=no_strip POST_STRIP_CMD="" I guess that we should run "make" above options to avoid this issue in currently. Thanks, Yasumasa On 03/04/2014 04:01 AM, Omair Majid wrote: > * Andrew Haley [2014-03-03 04:43]: >> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote: >>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>> contain debug information. Actual debug information is shipped by OpenJDK >>> debuginfo package. >> That's a bug in Fedora's build. We should fix it. > This should fix it: > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb > > Thanks, > Omair > From coleen.phillimore at oracle.com Fri Apr 4 15:28:07 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 04 Apr 2014 11:28:07 -0400 Subject: RFR 8028497: SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool) In-Reply-To: <533A79A5.6050307@oracle.com> References: <5331EA20.6000001@oracle.com> <5332FF22.4010900@oracle.com> <5333438B.8090508@oracle.com> <53338653.6060500@oracle.com> <53341BF7.6060309@oracle.com> <53343DFC.9000904@oracle.com> <53345BD5.5020806@oracle.com> <533A32C3.3090002@oracle.com> <533A79A5.6050307@oracle.com> Message-ID: <533ECF87.4030506@oracle.com> Erik, Thank you for the discussion and thorough code reviews. See below. (other reviewers: there's a new version of webrev, read down a little). On 4/1/14 4:32 AM, Erik Helin wrote: > On 2014-04-01 05:30, Coleen Phillimore wrote: >> >> Erik, >> >> You are right. The old code would use the Klass->mirror link to clear >> out the mirror->Klass link so that we didn't have a pointer to a >> deallocated Klass in a mirror that might still be live for CMS marking. >> The new code doesn't set the Klass->mirror link unless the mirror fields >> are completely allocated, so we could crash if we deallocated a Klass >> before the mirror because the mirror would still be pointing to the >> class. >> >> I've caught failed allocation in mirror fields so that the link is reset >> in this change. The only change is to the function create_mirror calls >> initialize_mirror_fields. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8028497_3/ > > In javaClasses.cpp: > void java_lang_Class::create_mirror(KlassHandle k, Handle, TRAPS) { > ... > initialize_mirror_fields(k, mirror, protection_domain, THREAD); > if (HAS_PENDING_EXCEPTION) { > // If any of the fields throws an exception like OOM remove the > // klass field from the mirror so GC doesn't follow it after the > // klass has been deallocated. > java_lang_Class::set_klass(mirror(), k()); > return; ^ > } | > | > +------------------------------------------+ > | > +-- Do you really want to use k() here? I thought the idea was to do: > java_lang_Class::set_klass(mirror(), NULL); > I had meant to change this to NULL. > Setting the Klass that the mirror is mirroring will hit the following > check in instanceMirrorKlass.cpp, oop_oop_iterate macro: > > int InstanceMirrorKlass::oop_oop_iterate##nv_suffix(...) { \ > ... \ > if_do_metadata_checked(closure, nv_suffix) { \ > Klass* klass = java_lang_Class::as_Klass(obj); \ > /* We'll get NULL for primitive mirrors. */ \ > if (klass != NULL) { \ > closure->do_klass##nv_suffix(klass); \ > } \ > } > > Setting the Klass that the mirror is mirroring to NULL will make the > mirror look like a primitive mirror (this is the way we encode > primitive mirrors). Will that be a problem? > No, this is fine. I added a comment that this mirror isn't a primitive type but it's also not representative of a class. I had internal code to generate lots of these mirrors and CMS and G1 work fine because they don't follow the klass. We don't want them to. We also clean up these orphaned mirrors, which I also verified manually. I also tested heap walking with temporary code to create lots of orphaned mirrors. I tried to create an internal test or a white box test but wasn't able to generate the right set of circumstances to exercise this code. If necessary, we can open another bug to add a test but I found it noreg-hard. This is also tested with Stefan's TreeMapTest.java test case that also required temporary code in the jvm. So yes, I think we want to be able to set the Klass field in the mirror to null. If other bugs fall out because of this in the future, I think we should fix the other bugs separately. New webrev with only this classfile/javaClasses.cpp change is here. open webrev at http://cr.openjdk.java.net/~coleenp/8028497_4/ Thanks! Coleen > Thanks, > Erik > >> Tested with vm.parallel_class_loading.testlist which do hit this case. >> >> Thanks! >> Coleen >> >> >> On 3/27/14 1:11 PM, Erik Helin wrote: >>> Hi Coleen, >>> >>> thanks for taking on this tricky bug! However, I think there is an >>> issue with your fix :( >>> >>> This case is for "normal" (non-CDS) class loading: >>> 1. We create the mirror >>> 2. We set up the link from the mirror to the Klass >>> 3. We fail somewhere before setting the link from the Klass to the >>> mirror, for example when allocating the Java object for the init >>> lock. >>> 4. The destructor for ClassFileParser is run and we add the Klass to >>> the >>> deallocate list. >>> 5. A CMS concurrent cycle is started, it will treat all objects in eden >>> + the survivor area as roots (including the mirror). >>> 6. The above concurrent cycle enters the "final remark" phase and does >>> class unloading which will call free_deallocate_list() which will >>> return the memory for the Klass added to the deallocate list in step >>> 4 to Metaspace. >>> 7. The concurrent CMS cycle ends (the mirror is still in eden or young) >>> 8. A new concurrent CMS cycle is started, the mirror will once again be >>> treated as a root since it is still in eden or young (no YC has been >>> done). >>> 9. During the initial marking, CMS will now follow the pointer to the >>> Klass that the mirror is mirroring, but we returned this memory to >>> Metaspace in step 6. >>> 10. We now crash :( >>> >>> Unfortunately, I don't have any suggestion on how to solve the above >>> scenario at the moment. >>> >>> Thanks, >>> Erik >>> >>> On 2014-03-27 16:04, Coleen Phillimore wrote: >>>> >>>> On 3/27/14 8:39 AM, Stefan Karlsson wrote: >>>>> >>>>> On 2014-03-27 03:00, Coleen Phillimore wrote: >>>>>> >>>>>> I have a new version of this change based on code that Ioi noticed >>>>>> that I was missing for making restoring the method's adapters >>>>>> restartable if something fails during restore_unshareable_info, and >>>>>> the constant pool resolved references array. >>>>>> Please review this new code (only method.* and instanceKlass.cpp and >>>>>> constantPool.cpp have differences). Reran tests with CDS and CMS. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8028497_2/ >>>>> >>>>> This seems good. I'd prefer if someone with more experience with CDS >>>>> also Reviews the change. >>>> >>>> Thanks, Ioi said he'd look at it. >>>> >>>>> >>>>> Small comment: >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8028497_2/src/share/vm/oops/instanceKlass.cpp.udiff.html >>>>> >>>>> >>>>> >>>>> >>>>> - methodHandle m(THREAD, methods->at(index2)); >>>>> - m()->link_method(m, CHECK); >>>>> - // restore method's vtable by calling a virtual function >>>>> - m->restore_vtable(); >>>>> + Method *m = methods->at(index2); >>>>> + m->restore_unshareable_info(CHECK); >>>>> >>>>> >>>>> Do we really want to use a raw Method * here. I know that we wrap the >>>>> method in a handle inside m->restore_unshareable_info, but it's not >>>>> clear from the this context. I'm thinking about this issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8004815 >>>>> >>>>> On the other hand, I guess we can't redefine a class before it has >>>>> been defined. But maybe it would be good to not promote the usage of >>>>> Method* over calls that might hit a Safepoint. >>>>> >>>> >>>> I think you're right, we don't use 'm' after the potential >>>> safepoint and >>>> we can't really redefine this class yet anyway but I'll restore the >>>> code >>>> because we don't want to encourage uses of unhandled Methods unless >>>> proven to be harmless. >>>> >>>> Thanks! >>>> Coleen >>>>> thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 3/26/14 5:15 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Jon, >>>>>>> Thank you for looking at the code changes. >>>>>>> >>>>>>> On 3/26/14 12:24 PM, Jon Masamitsu wrote: >>>>>>>> Coleen, >>>>>>>> >>>>>>>> Did you remove Class_obj_allocate() because it was only >>>>>>>> called in that one spot and use obj_allocate() did most >>>>>>>> of the work? >>>>>>> >>>>>>> I deleted it because GC doesn't need to know how these javaClasses >>>>>>> are set up and I spent way to long looking for this code and didn't >>>>>>> find it where it belongs, so I removed this. This >>>>>>> Class_obj_allocate >>>>>>> is an artifact of the permgen code. >>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/instanceMirrorKlass.cpp.frames.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 373 // the size in the mirror size itself. >>>>>>>> >>>>>>>> Drop the second "size". You know how we GC guys are >>>>>>>> getting with our comments :-). >>>>>>> >>>>>>> Yes, I noticed that. Thanks - fixed. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/klass.cpp.frames.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 498 void Klass::restore_unshareable_info(TRAPS) { >>>>>>>> 499 // If an exception happened during CDS restore, some of >>>>>>>> these fields may already be >>>>>>>> 500 // set. We leave the class on the CLD list, even if >>>>>>>> incomplete so that we don't >>>>>>>> 501 // modify the CLD list outside a safepoint. >>>>>>>> 502 if (class_loader_data() == NULL) { >>>>>>>> 503 ClassLoaderData* loader_data = >>>>>>>> ClassLoaderData::the_null_class_loader_data(); >>>>>>>> >>>>>>>> I can see that this works with the current CDS (sharing only >>>>>>>> classes loader >>>>>>>> with the NULL class loader). Will it work if the shared classes >>>>>>>> are loaded >>>>>>>> with an application class loader? >>>>>>> >>>>>>> I hope Ioi can answer that. I assume so because the classes don't >>>>>>> change class loaders if restoring shareable info fails. >>>>>>> >>>>>>> Ioi pointed out to me (not on open list) that I missed making >>>>>>> link_method() and creating the constant pool resolved references >>>>>>> array restartable, so I'm testing a fix for that also and I'll post >>>>>>> an update later. But you've seen most of it. >>>>>>> >>>>>>> Thanks!! >>>>>>> Coleen >>>>>>>> >>>>>>>> Rest looks good. >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> On 3/25/2014 1:42 PM, Coleen Phillimore wrote: >>>>>>>>> Summary: Keep class in CLD::_klasses list and mirror created for >>>>>>>>> CDS classes if OOM during restore_shareable_info(). This keeps >>>>>>>>> pointers consistent for CMS. >>>>>>>>> >>>>>>>>> This change makes restoring the mirror for shared classes >>>>>>>>> restartable if there is an OOM in the middle of >>>>>>>>> restore_unshareable_info. The mirror field in the classes and >>>>>>>>> CLD link is not cleaned up anymore. The class isn't marked >>>>>>>>> loaded >>>>>>>>> though so must be loaded again. >>>>>>>>> >>>>>>>>> Tested with Stefan's test case with hard coded OOM in jvm, so >>>>>>>>> can't add the test. Also ran all the tests against -client and >>>>>>>>> server with -Xshare:auto and with -XX:+UseConcMarkSweepGC. >>>>>>>>> >>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8028497/ >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8028497 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From dmitry.samersoff at oracle.com Fri Apr 4 17:03:47 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 04 Apr 2014 21:03:47 +0400 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53301478.8000809@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> <532C080A.9020002@oracle.com> <53301478.8000809@oracle.com> Message-ID: <533EE5F3.1020806@oracle.com> Magnus, Not, we are not doing it now. But we should consider doing it in a future and therefore keep it in mind when designing option to choose debug symbol mode. -Dmitry On 2014-03-24 15:18, Magnus Ihse Bursie wrote: > On 2014-03-21 10:36, Dmitry Samersoff wrote: >> >> (c) Compression mode: >> >> 1. none >> 2. per-section compression, SHF_GNU_COMPRESSED [1] >> 3. zip entire file >> > > Is 2 something we're doing? I couldn't find any references to it in the > code. Or is it something we're planning to do? > > /Magnus -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vladimir.kozlov at oracle.com Fri Apr 4 17:06:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Apr 2014 10:06:49 -0700 Subject: prefetch instructions in Hotspot In-Reply-To: <1396610683.77833.YahooMailNeo@web141603.mail.bf1.yahoo.com> References: <1396269507.45341.YahooMailNeo@web141603.mail.bf1.yahoo.com> <5339BA4A.6090107@oracle.com> <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> <533C39A1.40100@oracle.com> <1396458940.56395.YahooMailNeo@web141605.mail.bf1.yahoo.com> <533C467B.50400@oracle.com> <1396466378.3561.YahooMailNeo@web141605.mail.bf1.yahoo.com> <1396610683.77833.YahooMailNeo@web141603.mail.bf1.yahoo.com> Message-ID: <533EE6A9.9070300@oracle.com> Code looks fine. But you should know that such software prefetches only help when you access memory without patterns otherwise hardware prefetches in modern cpus will give you much better results. You also need to prefetch far a head of load instructions. Regards, Vladimir On 4/4/14 4:24 AM, Mahmood Naderan wrote: > OK guys. Thanks to Vladimir and others I added the declarations and compiled JDK6 successfully. Then based on the test example provided here (http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/d98807bff770/test/compiler/6968348/Test6968348.java) I wrote the following code to see if I am using the prefetchRead correctly. > > import sun.misc.Unsafe; > import java.lang.reflect.*; > public class Arr { > static int [] a = new int[3]; > static Unsafe unsafe; > static int baseOffset, indexScale; > public static void main(String[] args) throws Exception { > a[0] = 10; > a[1] = 20; > a[2] = 30; > > Class c = Arr.class.getClassLoader().loadClass("sun.misc.Unsafe"); > Field f = c.getDeclaredField("theUnsafe"); > f.setAccessible(true); > unsafe = (Unsafe)f.get(c); > > baseOffset = unsafe.arrayBaseOffset(int[].class); > indexScale = unsafe.arrayIndexScale(int[].class); > for (int i = 0; i < 3; i++) { > unsafe.prefetchReadStatic(a, baseOffset+indexScale*i); > System.out.println(a[i]); > } > } > } > > > > Running the code shows everything is fine and the values are printed on the screen. > Just need a confirmation; is that a correct usage of prefetchRead()? Is that all? > > > Regards, > Mahmood > > > > > > On Thursday, April 3, 2014 6:36 PM, "dalibor.topic at oracle.com" wrote: > >> See top level file Readme-build.html for instructions. >> > >> -->Oracle >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 | Mobile:+491737185961 >> Oracle Java Platform Group >> >> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> Gesch?ftsf?hrer: J?rgen Kunz >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >> >> Green Oracle Oracle is committed to developing practices and products that help protect the environment From alejandro.murillo at oracle.com Fri Apr 4 17:45:20 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 04 Apr 2014 11:45:20 -0600 Subject: New repo for Hotspot fixes going into 7u releases Message-ID: <533EEFB0.3090902@oracle.com> Hi All, Currently all 7u Hotspot backports (7u60 and 7u80) are pushed to hsx/jdk7u/hotspot [1]. I'm taking a snapshot of that repo today and will push that to the jdk7u master next Tuesday, AFTER THAT all Hotspot changes destined for a 7u release (7u60, 7u80) should be pushed straight to jdk7u/jdk7u-dev/hotspot [2]. So from now on, please do not push anything to hsx/jdk7u/hotspot. If you have a change ready to go in, please wait until I push the snapshot to master (and jdk7u-dev) on Tuesday and then push the change to jdk7u/jdk7u-dev/hotspot. Please keep reading for the implications: (1) The major implication of that change is that hotspot fixes will be taken to the master without going through a Hotspot specific PIT (regular PIT for jdk7u-dev integrations will continue to happen as usual), so if you need to push a significant change, you will need to make sure adequate testing is done before pushing to jdk7u/jdk7u-dev/hotspot, because the PIT safety net is not available anymore. Depending on the magnitude of the change, developers should work with SQE to do pre integration testing if they think is appropriate. Most changes should have been tested in 8u and 9, before going to 7u, so that should help making those decisions. However, there are differences between the 7u and 8u/9 code bases, like perm gen does not exists on 8u/9 and some other substantial differences. (2) Pushes should continue to be done via JPRT, so for external users, create your webrevs and committed patches based on the jdk7u/jdk7u-dev/hotspot repo and continue to request a sponsor to make the final push to the repo, via JPRT, once changes have been reviewed and approved. (3) Hotspot developers did not have to request permission to push changes to 7u repos, because they were pushed to master as a bulk integration. Going forward, Hotspot developers will need to request permission to push to 7u repos as non hotspot developers do. Those requests need to be sent to jdk7u-dev at openjdk.java.net, please continue to use hotspot-dev at openjdk.java.net (and other hotspot group repos) for discussions and reviews Let me know if you have any question/concern Thanks [1] http://hg.openjdk.java.net/hsx/jdk7u/hotspot/ [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/ -- Alejandro From nt_mahmood at yahoo.com Fri Apr 4 18:28:00 2014 From: nt_mahmood at yahoo.com (Mahmood Naderan) Date: Fri, 4 Apr 2014 11:28:00 -0700 (PDT) Subject: prefetch instructions in Hotspot In-Reply-To: <533EE6A9.9070300@oracle.com> References: <1396269507.45341.YahooMailNeo@web141603.mail.bf1.yahoo.com> <5339BA4A.6090107@oracle.com> <1396443580.78954.YahooMailNeo@web141601.mail.bf1.yahoo.com> <533C39A1.40100@oracle.com> <1396458940.56395.YahooMailNeo@web141605.mail.bf1.yahoo.com> <533C467B.50400@oracle.com> <1396466378.3561.YahooMailNeo@web141605.mail.bf1.yahoo.com> <1396610683.77833.YahooMailNeo@web141603.mail.bf1.yahoo.com> <533EE6A9.9070300@oracle.com> Message-ID: <1396636080.27948.YahooMailNeo@web141602.mail.bf1.yahoo.com> Thanks Vladimir for the feedback. Indeed what you said is what I am trying to analyze. ? Regards, Mahmood On Friday, April 4, 2014 9:37 PM, Vladimir Kozlov wrote: >Code looks fine. But you should know that such software prefetches only help when you access memory without >patterns >otherwise hardware prefetches in modern cpus will give you much better results. You also need to prefetch far a >head of >load instructions. > >Regards, >Vladimir From alejandro.murillo at oracle.com Sat Apr 5 00:22:15 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 05 Apr 2014 00:22:15 +0000 Subject: hg: hsx/jdk7u/hotspot: Added tag hs24.80-b06 for changeset ee18e60e7e8d Message-ID: <201404050022.s350MGEw004095@aojmv0008> Changeset: c0f53284e788 Author: amurillo Date: 2014-04-04 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c0f53284e788 Added tag hs24.80-b06 for changeset ee18e60e7e8d ! .hgtags From alejandro.murillo at oracle.com Sat Apr 5 03:00:16 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 05 Apr 2014 03:00:16 +0000 Subject: hg: hsx/jdk7u/hotspot: 8039292: new hotspot build - hs24.80-b07 Message-ID: <201404050300.s3530HaJ026583@aojmv0008> Changeset: d3128ba6d218 Author: amurillo Date: 2014-04-04 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d3128ba6d218 8039292: new hotspot build - hs24.80-b07 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Mon Apr 7 01:16:19 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Apr 2014 11:16:19 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <533EC7FA.9030700@gmail.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53144E4D.8080606@redhat.com> <20140303190102.GE2045@redhat.com> <533EC7FA.9030700@gmail.com> Message-ID: <5341FC63.60602@oracle.com> On 5/04/2014 12:55 AM, Yasumasa Suenaga wrote: > Hi all, > >> This should fix it: >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb >> > > I updated OpenJDK8 to java-1.8.0-openjdk-1.8.0.0-0.34.b132.fc20 . > However, debuginfo files are not contained ELF sections for debugging. > (I checked libjvm.so.debug and libnio.so.debug with "readelf -S") > > According to SPEC file of OpenJDK8, following options are passed to "make": > ----------------- > make \ > SCTP_WERROR= \ > DEBUG_BINARIES=true \ > FULL_DEBUG_SYMBOLS=0 \ > STRIP_POLICY=none \ > ALT_OBJCOPY=/does_not_exist \ > LOG=trace \ > all > ----------------- > > I ran "grep" with DEBUG_BINARIES in jdk makefiles, however I could not > find it. > At least, DEBUG_BINARIES does not affect to jdk sources, and also does not > affect to hotspot sources. DEBUG_BINARIES is used in the hotspot makefiles. ./linux/makefiles/gcc.make ifeq ($(DEBUG_BINARIES), true) CFLAGS += -g else David ----- > > I've succeeded to make binaries which are contained debuginfo as following: > > http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html > $ make images STRIP_POLICY=no_strip POST_STRIP_CMD="" > > > I guess that we should run "make" above options to avoid this issue in > currently. > > > Thanks, > > Yasumasa > > > On 03/04/2014 04:01 AM, Omair Majid wrote: >> * Andrew Haley [2014-03-03 04:43]: >>> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote: >>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and >>>> libjvm.debuginfo . >>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it >>>> does not >>>> contain debug information. Actual debug information is shipped by >>>> OpenJDK >>>> debuginfo package. >>> That's a bug in Fedora's build. We should fix it. >> This should fix it: >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb >> >> >> Thanks, >> Omair >> > From david.holmes at oracle.com Mon Apr 7 01:49:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Apr 2014 11:49:07 +1000 Subject: Testlibrary changes need their own changesets Message-ID: <53420413.50207@oracle.com> Unfortunately enhancements to the testlibrary infrastructure code tend to be done in conjunction with the changes to the tests (and sometimes corresponding VM changes) that need the enhancement. This makes it very difficult (sometimes impossible) to backport updates to the testlibrary. Can I suggest that all updates to the testlibrary classes be done under their own CR (they can still be reviewed alongside the main changes) and committed into a distinct changeset so that they can be readily backported. Thanks, David From neugens at redhat.com Mon Apr 7 07:51:04 2014 From: neugens at redhat.com (Mario Torre) Date: Mon, 07 Apr 2014 09:51:04 +0200 Subject: [8u20] RFR (XS): 8036619: Shark: add LLVM 3.4 support In-Reply-To: <1395062146.3881.4.camel@galactica.localdomain> References: <1395062146.3881.4.camel@galactica.localdomain> Message-ID: <1396857064.3726.2.camel@galactica.localdomain> On Mon, 2014-03-17 at 14:15 +0100, Mario Torre wrote: > Resending with correct webrev and subject :) > > I would like to ask the backport of the changes made for the following > bug report into JDK 8 (jdk8u20): > > https://bugs.openjdk.java.net/browse/JDK-8036619 > > The changes apply cleanly without modification: > > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ > > The related changes for JDK 9 are here: > > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.02/ > > The discussion here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/012814.html > > and here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012679.html > > I can't push myself, so if OK, someone would need to do for me. > > Cheers, > Mario > > ping? Cheers, Mario From yekaterina.kantserova at oracle.com Mon Apr 7 08:49:20 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 7 Apr 2014 01:49:20 -0700 (PDT) Subject: Testlibrary changes need their own changesets Message-ID: <2b65a081-b79b-4ee6-b3d2-d4c501cbb64f@default> Since the testlibrary exists even in the JDK part I would like to add the Serviceability and Corelibs teams to this discussion. Thanks, Katja ----- Original Message ----- From: david.holmes at oracle.com To: hotspot-dev at openjdk.java.net Sent: Monday, April 7, 2014 3:50:14 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Testlibrary changes need their own changesets Unfortunately enhancements to the testlibrary infrastructure code tend to be done in conjunction with the changes to the tests (and sometimes corresponding VM changes) that need the enhancement. This makes it very difficult (sometimes impossible) to backport updates to the testlibrary. Can I suggest that all updates to the testlibrary classes be done under their own CR (they can still be reviewed alongside the main changes) and committed into a distinct changeset so that they can be readily backported. Thanks, David From cleber at nightcoders.com.br Mon Apr 7 15:15:18 2014 From: cleber at nightcoders.com.br (Cleber Muramoto) Date: Mon, 7 Apr 2014 12:15:18 -0300 Subject: JDK 8 great performance increase on ByteBuffer read performance!? Message-ID: Hello, I'm curious to know if there has been any low-level optmizations regarding direct buffers getXXX methods on JDK8 and, if they're planned to be integrated in JDK7, if applicable. I googled and took a look at the bug database but I couldn't find anything related. I have a microbenchmark that does millions of iterations serializing and deserializing objects to/from ByteBuffers and I noticed that read performance on JDK 8 has increased by almost 45% in comparison to earliear JDK 7 releases in the serial case and more than 200% on the concurrent case! I think that the concurrent test is perhaps benefiniting from newer ForkJoinPool/concurrency code, but the difference in the serial case is still very large! Bellow are the VM arguments that I'm using for the test: $JAVA -server -XX:+UseParallelGC \ -XX:+UseLargePages -XX:MaxDirectMemorySize=10G -Xmx1g -XX:MaxInlineSize=256 \ -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -XX:+LogCompilation JDK8 seems to generate much more compiling information than the previous versions, but I wasn't able to find any indicators for such huge performance difference. Here are the test results (collected with the diagnostic flags off, on a HP G7 48 CPU box). Concurrent Reads: 503K Reads/s|Writes/s 161K (jdk7U10) 940K Reads/s|Writes/s 165K (jdk7U40) 956K Reads/s|Writes/s 159K (jdk7U60 EA) 1644K Reads/s|Writes/s 172K (jdk8-more than 3x faster than U10!) Serial Reads: 137K Reads/s|Writes/s 146K 145K Reads/s|Writes/s 145K 143K Reads/s|Writes/s 155K 198K Reads/s|Writes/s 172K Upon deserialization the test does a lot of short-lived allocations, but GC reports show very similar results for every JDK versions used in the test (about ~500 Young Gen Collections and ~1800ms spent by PS Scavenge). Anyway, great work!!! I hope I can migrate to JDK8 as soon as possible. Regards Cleber From alejandro.murillo at oracle.com Mon Apr 7 18:02:08 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 07 Apr 2014 12:02:08 -0600 Subject: RFR 8039392: Make jdk8u20 the default jprt release for hs25.20 Message-ID: <5342E820.9090005@oracle.com> can I get a quick review for this change? http://cr.openjdk.java.net/~amurillo/8u20/8039392/ Thanks -- Alejandro From vladimir.kozlov at oracle.com Mon Apr 7 18:33:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Apr 2014 11:33:36 -0700 Subject: RFR 8039392: Make jdk8u20 the default jprt release for hs25.20 In-Reply-To: <5342E820.9090005@oracle.com> References: <5342E820.9090005@oracle.com> Message-ID: <5342EF80.3070700@oracle.com> Looks good. Thanks, Vladimir On 4/7/14 11:02 AM, Alejandro E Murillo wrote: > > can I get a quick review for this change? > > http://cr.openjdk.java.net/~amurillo/8u20/8039392/ > > Thanks > From christian.thalinger at oracle.com Mon Apr 7 19:52:38 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Apr 2014 12:52:38 -0700 Subject: [8u20] RFR (XS): 8036619: Shark: add LLVM 3.4 support In-Reply-To: <1396857064.3726.2.camel@galactica.localdomain> References: <1395062146.3881.4.camel@galactica.localdomain> <1396857064.3726.2.camel@galactica.localdomain> Message-ID: <7A82F14C-FFF4-4076-8AE3-ED5684860643@oracle.com> You need to send a request for approval to jdk8u-dev. On Apr 7, 2014, at 12:51 AM, Mario Torre wrote: > On Mon, 2014-03-17 at 14:15 +0100, Mario Torre wrote: >> Resending with correct webrev and subject :) >> >> I would like to ask the backport of the changes made for the following >> bug report into JDK 8 (jdk8u20): >> >> https://bugs.openjdk.java.net/browse/JDK-8036619 >> >> The changes apply cleanly without modification: >> >> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ >> >> The related changes for JDK 9 are here: >> >> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.02/ >> >> The discussion here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/012814.html >> >> and here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012679.html >> >> I can't push myself, so if OK, someone would need to do for me. >> >> Cheers, >> Mario >> >> > > ping? > > Cheers, > Mario > From vladimir.kozlov at oracle.com Mon Apr 7 20:02:09 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Apr 2014 13:02:09 -0700 Subject: [8u20] RFR (XS): 8036619: Shark: add LLVM 3.4 support In-Reply-To: <7A82F14C-FFF4-4076-8AE3-ED5684860643@oracle.com> References: <1395062146.3881.4.camel@galactica.localdomain> <1396857064.3726.2.camel@galactica.localdomain> <7A82F14C-FFF4-4076-8AE3-ED5684860643@oracle.com> Message-ID: <53430441.90403@oracle.com> Hotspot changes does not require approval on jdk8u-dev. Alejandro does bulk requests. Mario, your changes are good. Christian, can you sponsor backport? 8u20 hotspot staging repo is: http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot Thanks, Vladimir On 4/7/14 12:52 PM, Christian Thalinger wrote: > You need to send a request for approval to jdk8u-dev. > > On Apr 7, 2014, at 12:51 AM, Mario Torre wrote: > >> On Mon, 2014-03-17 at 14:15 +0100, Mario Torre wrote: >>> Resending with correct webrev and subject :) >>> >>> I would like to ask the backport of the changes made for the following >>> bug report into JDK 8 (jdk8u20): >>> >>> https://bugs.openjdk.java.net/browse/JDK-8036619 >>> >>> The changes apply cleanly without modification: >>> >>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ >>> >>> The related changes for JDK 9 are here: >>> >>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.02/ >>> >>> The discussion here: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/012814.html >>> >>> and here: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012679.html >>> >>> I can't push myself, so if OK, someone would need to do for me. >>> >>> Cheers, >>> Mario >>> >>> >> >> ping? >> >> Cheers, >> Mario >> > From christian.thalinger at oracle.com Mon Apr 7 20:08:57 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Apr 2014 13:08:57 -0700 Subject: [8u20] RFR (XS): 8036619: Shark: add LLVM 3.4 support In-Reply-To: <53430441.90403@oracle.com> References: <1395062146.3881.4.camel@galactica.localdomain> <1396857064.3726.2.camel@galactica.localdomain> <7A82F14C-FFF4-4076-8AE3-ED5684860643@oracle.com> <53430441.90403@oracle.com> Message-ID: On Apr 7, 2014, at 1:02 PM, Vladimir Kozlov wrote: > Hotspot changes does not require approval on jdk8u-dev. Alejandro does bulk requests. That?s true but in this case I thought it might not hurt. Do all HotSpot backports require no approval no matter how big they are? > > Mario, your changes are good. Christian, can you sponsor backport? > > 8u20 hotspot staging repo is: > http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot > > Thanks, > Vladimir > > On 4/7/14 12:52 PM, Christian Thalinger wrote: >> You need to send a request for approval to jdk8u-dev. >> >> On Apr 7, 2014, at 12:51 AM, Mario Torre wrote: >> >>> On Mon, 2014-03-17 at 14:15 +0100, Mario Torre wrote: >>>> Resending with correct webrev and subject :) >>>> >>>> I would like to ask the backport of the changes made for the following >>>> bug report into JDK 8 (jdk8u20): >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8036619 >>>> >>>> The changes apply cleanly without modification: >>>> >>>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ >>>> >>>> The related changes for JDK 9 are here: >>>> >>>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.02/ >>>> >>>> The discussion here: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/012814.html >>>> >>>> and here: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012679.html >>>> >>>> I can't push myself, so if OK, someone would need to do for me. >>>> >>>> Cheers, >>>> Mario >>>> >>>> >>> >>> ping? >>> >>> Cheers, >>> Mario >>> >> From vladimir.kozlov at oracle.com Mon Apr 7 20:59:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Apr 2014 13:59:59 -0700 Subject: [8u20] RFR (XS): 8036619: Shark: add LLVM 3.4 support In-Reply-To: References: <1395062146.3881.4.camel@galactica.localdomain> <1396857064.3726.2.camel@galactica.localdomain> <7A82F14C-FFF4-4076-8AE3-ED5684860643@oracle.com> <53430441.90403@oracle.com> Message-ID: <534311CF.8020204@oracle.com> On 4/7/14 1:08 PM, Christian Thalinger wrote: > > On Apr 7, 2014, at 1:02 PM, Vladimir Kozlov wrote: > >> Hotspot changes does not require approval on jdk8u-dev. Alejandro does bulk requests. > > That?s true but in this case I thought it might not hurt. Do all HotSpot backports require no approval no matter how big they are? I think, we should be notified what is backported. The only document we have is Alejandro's mail: > The process to get hotspot changes for 8u20 is the same > as the one to get changes for 7u releases. In a nutshell: > > (1) Request a review (not permission) on hotspot-dev at openjdk > (2) Push to jdk8u/hs-dev/hotspot (via jprt) > (3) NO NEED TO REQUEST approval for integration > > once the changes are in hs-dev, I will push then to the master after PIT > and I will request the approval for a bulk integration then So it is not, technically, an approval but a notification and review. It is always good to have other people look on your changes. Thanks, Vladimir > >> >> Mario, your changes are good. Christian, can you sponsor backport? >> >> 8u20 hotspot staging repo is: >> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot >> >> Thanks, >> Vladimir >> >> On 4/7/14 12:52 PM, Christian Thalinger wrote: >>> You need to send a request for approval to jdk8u-dev. >>> >>> On Apr 7, 2014, at 12:51 AM, Mario Torre wrote: >>> >>>> On Mon, 2014-03-17 at 14:15 +0100, Mario Torre wrote: >>>>> Resending with correct webrev and subject :) >>>>> >>>>> I would like to ask the backport of the changes made for the following >>>>> bug report into JDK 8 (jdk8u20): >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8036619 >>>>> >>>>> The changes apply cleanly without modification: >>>>> >>>>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ >>>>> >>>>> The related changes for JDK 9 are here: >>>>> >>>>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.02/ >>>>> >>>>> The discussion here: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/012814.html >>>>> >>>>> and here: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012679.html >>>>> >>>>> I can't push myself, so if OK, someone would need to do for me. >>>>> >>>>> Cheers, >>>>> Mario >>>>> >>>>> >>>> >>>> ping? >>>> >>>> Cheers, >>>> Mario >>>> >>> > From vladimir.kozlov at oracle.com Mon Apr 7 21:04:45 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Apr 2014 14:04:45 -0700 Subject: [8u20] RFR (XS): 8036619: Shark: add LLVM 3.4 support In-Reply-To: <534311CF.8020204@oracle.com> References: <1395062146.3881.4.camel@galactica.localdomain> <1396857064.3726.2.camel@galactica.localdomain> <7A82F14C-FFF4-4076-8AE3-ED5684860643@oracle.com> <53430441.90403@oracle.com> <534311CF.8020204@oracle.com> Message-ID: <534312ED.2070202@oracle.com> On 4/7/14 1:59 PM, Vladimir Kozlov wrote: > On 4/7/14 1:08 PM, Christian Thalinger wrote: >> >> On Apr 7, 2014, at 1:02 PM, Vladimir Kozlov >> wrote: >> >>> Hotspot changes does not require approval on jdk8u-dev. Alejandro >>> does bulk requests. >> >> That?s true but in this case I thought it might not hurt. Do all >> HotSpot backports require no approval no matter how big they are? I did NOT request an approval for PPC64 backport, Alejandro did it for me :) Regards, Vladimir > > I think, we should be notified what is backported. > The only document we have is Alejandro's mail: > > > The process to get hotspot changes for 8u20 is the same > > as the one to get changes for 7u releases. In a nutshell: > > > > (1) Request a review (not permission) on hotspot-dev at openjdk > > (2) Push to jdk8u/hs-dev/hotspot (via jprt) > > (3) NO NEED TO REQUEST approval for integration > > > > once the changes are in hs-dev, I will push then to the master after PIT > > and I will request the approval for a bulk integration then > > So it is not, technically, an approval but a notification and review. > It is always good to have other people look on your changes. > > Thanks, > Vladimir > >> >>> >>> Mario, your changes are good. Christian, can you sponsor backport? >>> >>> 8u20 hotspot staging repo is: >>> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot >>> >>> Thanks, >>> Vladimir >>> >>> On 4/7/14 12:52 PM, Christian Thalinger wrote: >>>> You need to send a request for approval to jdk8u-dev. >>>> >>>> On Apr 7, 2014, at 12:51 AM, Mario Torre wrote: >>>> >>>>> On Mon, 2014-03-17 at 14:15 +0100, Mario Torre wrote: >>>>>> Resending with correct webrev and subject :) >>>>>> >>>>>> I would like to ask the backport of the changes made for the >>>>>> following >>>>>> bug report into JDK 8 (jdk8u20): >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8036619 >>>>>> >>>>>> The changes apply cleanly without modification: >>>>>> >>>>>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ >>>>>> >>>>>> The related changes for JDK 9 are here: >>>>>> >>>>>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.02/ >>>>>> >>>>>> The discussion here: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/012814.html >>>>>> >>>>>> >>>>>> and here: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012679.html >>>>>> >>>>>> >>>>>> I can't push myself, so if OK, someone would need to do for me. >>>>>> >>>>>> Cheers, >>>>>> Mario >>>>>> >>>>>> >>>>> >>>>> ping? >>>>> >>>>> Cheers, >>>>> Mario >>>>> >>>> >> From christian.thalinger at oracle.com Mon Apr 7 21:25:16 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Apr 2014 14:25:16 -0700 Subject: [8u20] RFR (XS): 8036619: Shark: add LLVM 3.4 support In-Reply-To: <534312ED.2070202@oracle.com> References: <1395062146.3881.4.camel@galactica.localdomain> <1396857064.3726.2.camel@galactica.localdomain> <7A82F14C-FFF4-4076-8AE3-ED5684860643@oracle.com> <53430441.90403@oracle.com> <534311CF.8020204@oracle.com> <534312ED.2070202@oracle.com> Message-ID: <39780877-7FE1-41FF-AD77-EB1F7C2A4141@oracle.com> On Apr 7, 2014, at 2:04 PM, Vladimir Kozlov wrote: > On 4/7/14 1:59 PM, Vladimir Kozlov wrote: >> On 4/7/14 1:08 PM, Christian Thalinger wrote: >>> >>> On Apr 7, 2014, at 1:02 PM, Vladimir Kozlov >>> wrote: >>> >>>> Hotspot changes does not require approval on jdk8u-dev. Alejandro >>>> does bulk requests. >>> >>> That?s true but in this case I thought it might not hurt. Do all >>> HotSpot backports require no approval no matter how big they are? > > I did NOT request an approval for PPC64 backport, Alejandro did it for me :) Ok, that?s a clear precedent :-) > > Regards, > Vladimir > >> >> I think, we should be notified what is backported. >> The only document we have is Alejandro's mail: >> >> > The process to get hotspot changes for 8u20 is the same >> > as the one to get changes for 7u releases. In a nutshell: >> > >> > (1) Request a review (not permission) on hotspot-dev at openjdk >> > (2) Push to jdk8u/hs-dev/hotspot (via jprt) >> > (3) NO NEED TO REQUEST approval for integration >> > >> > once the changes are in hs-dev, I will push then to the master after PIT >> > and I will request the approval for a bulk integration then >> >> So it is not, technically, an approval but a notification and review. >> It is always good to have other people look on your changes. >> >> Thanks, >> Vladimir >> >>> >>>> >>>> Mario, your changes are good. Christian, can you sponsor backport? >>>> >>>> 8u20 hotspot staging repo is: >>>> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/7/14 12:52 PM, Christian Thalinger wrote: >>>>> You need to send a request for approval to jdk8u-dev. >>>>> >>>>> On Apr 7, 2014, at 12:51 AM, Mario Torre wrote: >>>>> >>>>>> On Mon, 2014-03-17 at 14:15 +0100, Mario Torre wrote: >>>>>>> Resending with correct webrev and subject :) >>>>>>> >>>>>>> I would like to ask the backport of the changes made for the >>>>>>> following >>>>>>> bug report into JDK 8 (jdk8u20): >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036619 >>>>>>> >>>>>>> The changes apply cleanly without modification: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ >>>>>>> >>>>>>> The related changes for JDK 9 are here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.02/ >>>>>>> >>>>>>> The discussion here: >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/012814.html >>>>>>> >>>>>>> >>>>>>> and here: >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012679.html >>>>>>> >>>>>>> >>>>>>> I can't push myself, so if OK, someone would need to do for me. >>>>>>> >>>>>>> Cheers, >>>>>>> Mario >>>>>>> >>>>>>> >>>>>> >>>>>> ping? >>>>>> >>>>>> Cheers, >>>>>> Mario >>>>>> >>>>> >>> From david.holmes at oracle.com Tue Apr 8 00:27:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Apr 2014 10:27:28 +1000 Subject: RFR 8039392: Make jdk8u20 the default jprt release for hs25.20 In-Reply-To: <5342E820.9090005@oracle.com> References: <5342E820.9090005@oracle.com> Message-ID: <53434270.2030609@oracle.com> On 8/04/2014 4:02 AM, Alejandro E Murillo wrote: > > can I get a quick review for this change? > > http://cr.openjdk.java.net/~amurillo/8u20/8039392/ Looks okay. David > Thanks > From ivan.gerasimov at oracle.com Tue Apr 8 08:30:56 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Apr 2014 12:30:56 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <533D52B7.2090406@oracle.com> References: <533D52B7.2090406@oracle.com> Message-ID: <5343B3C0.3090704@oracle.com> Hi everyone! That's the second round. First, here are a few thoughts about the issue: - When a console application is created, the user expects its output (both stdout and stderr) to be predictable. If I created a 'hello world' program, I would expect it to print only what it's supposed to print, but nothing more. - The runtime should not intermix its output with the program output, unless it is specifically told to do that. In the documentation [1][2], it's not written that using JAVA_TOOL_OPTIONS environment variable will make the runtime produce warnings in the application stderr. - It is already specified, that in the cases when it might be unsafe to pick up the options from the environment variable, the runtime does not process them. Here's the extract from [2]: "Platforms may disable this feature in cases where security is a concern." [1] http://docs.oracle.com/javase/8/docs/technotes/guides/tsgvm/envvars.html#env_var_sys_prop [2] http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#tooloptions I totally agree that with JEP-158 implemented, this warning message should definitely appear in the application logs. It would always be useful it the logs, but not always is it useful in the application stderr, because it can make the application caller unnecessary complicated. I changed the fix to implement an alternative environment variable, _QUIET_JAVA_OPTIONS, which behaves in the same way _JAVA_OPTIONS does, but does not produce the warning message. The change is quiet simple and does not change the current behavior of JAVA_TOOL_OPTIONS or _JAVA_OPTIONS variables. This variable is not meant to be documented. We will only suggest it to the users which need to get rid of the warning and complain about it. Would you please help review the new webrev: http://cr.openjdk.java.net/~igerasim/8039152/1/webrev/ Sincerely yours, Ivan From aleksey.shipilev at oracle.com Tue Apr 8 09:33:22 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 08 Apr 2014 13:33:22 +0400 Subject: JDK 8 great performance increase on ByteBuffer read performance!? In-Reply-To: References: Message-ID: <5343C262.3080403@oracle.com> Hi Cleber, On 04/07/2014 07:15 PM, Cleber Muramoto wrote: > I have a microbenchmark that does millions of iterations serializing and > deserializing objects to/from ByteBuffers Care to share the benchmark code? -Aleksey. From goetz.lindenmaier at sap.com Tue Apr 8 13:22:37 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 8 Apr 2014 13:22:37 +0000 Subject: FW: Your Report (Bug ID: 9009439 ) - Problems when rendering Thai texts on OS X 10.9 Mavericks In-Reply-To: References: <14372770.01389100426602.JavaMail.daemon@localhost> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAF22E@DEWDFEMB12A.global.corp.sap> Hi, a colleague of mine reported an issue on this page: http://bugreport.java.com/bugreport/ in January, see below. We would like to know the status of this issue. We can not find it in the bug database. Is there some way to access it? I also wonder why it has a number starting with 90. Is this a separate bug system? Thanks and best regards, Goetz. From: Straub, Robert Sent: Dienstag, 8. April 2014 15:15 To: Lindenmaier, Goetz Subject: Fwd: Your Report (Bug ID: 9009439 ) - Problems when rendering Thai texts on OS X 10.9 Mavericks Es dreht sich darum, dass diakritische Zeichen unter Mavericks (OS X 10.9) als Rechtecke dargestellt werden wenn ein Proportionalzeichensatz verwendet wird. Mer?i Robert Begin forwarded message: From: "Bug-Report-Daemon_WW at ORACLE.COM" > Subject: Your Report (Bug ID: 9009439 ) - Problems when rendering Thai texts on OS X 10.9 Mavericks Date: 7. Januar 2014 14:13:46 MEZ To: > Dear Java Developer, Thank you for reporting this issue. We have determined that this report is a new bug and have entered the bug into our bug tracking system under Bug Id: 9009439 . You can look for related issues on the Java Bug Database at http://bugs.sun.com. We will try to process all newly posted bugs in a timely manner, but we make no promises about the amount of time in which a bug will be fixed. If you just reported a bug that could have a major impact on your project, consider using one of the technical support offerings available at Oracle Support. Thanks again for your submission! Regards, Java Developer Support From Alan.Bateman at oracle.com Tue Apr 8 13:34:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Apr 2014 14:34:38 +0100 Subject: FW: Your Report (Bug ID: 9009439 ) - Problems when rendering Thai texts on OS X 10.9 Mavericks In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAF22E@DEWDFEMB12A.global.corp.sap> References: <14372770.01389100426602.JavaMail.daemon@localhost> <4295855A5C1DE049A61835A1887419CC2CEAF22E@DEWDFEMB12A.global.corp.sap> Message-ID: <5343FAEE.9070204@oracle.com> On 08/04/2014 14:22, Lindenmaier, Goetz wrote: > Hi, > > a colleague of mine reported an issue on this page: > http://bugreport.java.com/bugreport/ in January, see below. > > We would like to know the status of this issue. We can not > find it in the bug database. Is there some way to access it? > > I also wonder why it has a number starting with 90. Is this > a separate bug system? > Incidents submitted via bugs.sun.com go into a separate JIRA project, they don't go immediately into a project that you can access via bugs.openjdk.java.net. I've just moved this one to the JDK project so you can access it here: https://bugs.openjdk.java.net/browse/JDK-8039468 It gets a new issue number when moved. The 2d-dev list is probably the right list to bring up this issue if you need to. -Alan From goetz.lindenmaier at sap.com Tue Apr 8 13:50:37 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 8 Apr 2014 13:50:37 +0000 Subject: FW: Your Report (Bug ID: 9009439 ) - Problems when rendering Thai texts on OS X 10.9 Mavericks In-Reply-To: <5343FAEE.9070204@oracle.com> References: <14372770.01389100426602.JavaMail.daemon@localhost> <4295855A5C1DE049A61835A1887419CC2CEAF22E@DEWDFEMB12A.global.corp.sap> <5343FAEE.9070204@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAF281@DEWDFEMB12A.global.corp.sap> HI Alan, thanks for the fast answer! Best regards, Goetz. -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Dienstag, 8. April 2014 15:35 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; Simonis, Volker; Straub, Robert; Wintergerst, Michael Subject: Re: FW: Your Report (Bug ID: 9009439 ) - Problems when rendering Thai texts on OS X 10.9 Mavericks On 08/04/2014 14:22, Lindenmaier, Goetz wrote: > Hi, > > a colleague of mine reported an issue on this page: > http://bugreport.java.com/bugreport/ in January, see below. > > We would like to know the status of this issue. We can not > find it in the bug database. Is there some way to access it? > > I also wonder why it has a number starting with 90. Is this > a separate bug system? > Incidents submitted via bugs.sun.com go into a separate JIRA project, they don't go immediately into a project that you can access via bugs.openjdk.java.net. I've just moved this one to the JDK project so you can access it here: https://bugs.openjdk.java.net/browse/JDK-8039468 It gets a new issue number when moved. The 2d-dev list is probably the right list to bring up this issue if you need to. -Alan From erik.helin at oracle.com Tue Apr 8 15:43:42 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 08 Apr 2014 17:43:42 +0200 Subject: RFR 8028497: SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool) In-Reply-To: <533ECF87.4030506@oracle.com> References: <5331EA20.6000001@oracle.com> <5332FF22.4010900@oracle.com> <5333438B.8090508@oracle.com> <53338653.6060500@oracle.com> <53341BF7.6060309@oracle.com> <53343DFC.9000904@oracle.com> <53345BD5.5020806@oracle.com> <533A32C3.3090002@oracle.com> <533A79A5.6050307@oracle.com> <533ECF87.4030506@oracle.com> Message-ID: <5344192E.9080202@oracle.com> Coleen, the change http://cr.openjdk.java.net/~coleenp/8028497_4/ looks good. Thanks for taking care of this patch! Erik On 2014-04-04 17:28, Coleen Phillimore wrote: > > Erik, > Thank you for the discussion and thorough code reviews. See below. > (other reviewers: there's a new version of webrev, read down a little). > > On 4/1/14 4:32 AM, Erik Helin wrote: >> On 2014-04-01 05:30, Coleen Phillimore wrote: >>> >>> Erik, >>> >>> You are right. The old code would use the Klass->mirror link to clear >>> out the mirror->Klass link so that we didn't have a pointer to a >>> deallocated Klass in a mirror that might still be live for CMS marking. >>> The new code doesn't set the Klass->mirror link unless the mirror fields >>> are completely allocated, so we could crash if we deallocated a Klass >>> before the mirror because the mirror would still be pointing to the >>> class. >>> >>> I've caught failed allocation in mirror fields so that the link is reset >>> in this change. The only change is to the function create_mirror calls >>> initialize_mirror_fields. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8028497_3/ >> >> In javaClasses.cpp: >> void java_lang_Class::create_mirror(KlassHandle k, Handle, TRAPS) { >> ... >> initialize_mirror_fields(k, mirror, protection_domain, THREAD); >> if (HAS_PENDING_EXCEPTION) { >> // If any of the fields throws an exception like OOM remove the >> // klass field from the mirror so GC doesn't follow it after the >> // klass has been deallocated. >> java_lang_Class::set_klass(mirror(), k()); >> return; ^ >> } | >> | >> +------------------------------------------+ >> | >> +-- Do you really want to use k() here? I thought the idea was to do: >> java_lang_Class::set_klass(mirror(), NULL); >> > > I had meant to change this to NULL. >> Setting the Klass that the mirror is mirroring will hit the following >> check in instanceMirrorKlass.cpp, oop_oop_iterate macro: >> >> int InstanceMirrorKlass::oop_oop_iterate##nv_suffix(...) { \ >> ... \ >> if_do_metadata_checked(closure, nv_suffix) { \ >> Klass* klass = java_lang_Class::as_Klass(obj); \ >> /* We'll get NULL for primitive mirrors. */ \ >> if (klass != NULL) { \ >> closure->do_klass##nv_suffix(klass); \ >> } \ >> } >> >> Setting the Klass that the mirror is mirroring to NULL will make the >> mirror look like a primitive mirror (this is the way we encode >> primitive mirrors). Will that be a problem? >> > > No, this is fine. I added a comment that this mirror isn't a primitive > type but it's also not representative of a class. I had internal code > to generate lots of these mirrors and CMS and G1 work fine because they > don't follow the klass. We don't want them to. We also clean up these > orphaned mirrors, which I also verified manually. > > I also tested heap walking with temporary code to create lots of > orphaned mirrors. I tried to create an internal test or a white box > test but wasn't able to generate the right set of circumstances to > exercise this code. If necessary, we can open another bug to add a > test but I found it noreg-hard. > > This is also tested with Stefan's TreeMapTest.java test case that also > required temporary code in the jvm. > > So yes, I think we want to be able to set the Klass field in the mirror > to null. If other bugs fall out because of this in the future, I think > we should fix the other bugs separately. > > New webrev with only this classfile/javaClasses.cpp change is here. > > open webrev at http://cr.openjdk.java.net/~coleenp/8028497_4/ > > Thanks! > Coleen >> Thanks, >> Erik >> >>> Tested with vm.parallel_class_loading.testlist which do hit this case. >>> >>> Thanks! >>> Coleen >>> >>> >>> On 3/27/14 1:11 PM, Erik Helin wrote: >>>> Hi Coleen, >>>> >>>> thanks for taking on this tricky bug! However, I think there is an >>>> issue with your fix :( >>>> >>>> This case is for "normal" (non-CDS) class loading: >>>> 1. We create the mirror >>>> 2. We set up the link from the mirror to the Klass >>>> 3. We fail somewhere before setting the link from the Klass to the >>>> mirror, for example when allocating the Java object for the init >>>> lock. >>>> 4. The destructor for ClassFileParser is run and we add the Klass to >>>> the >>>> deallocate list. >>>> 5. A CMS concurrent cycle is started, it will treat all objects in eden >>>> + the survivor area as roots (including the mirror). >>>> 6. The above concurrent cycle enters the "final remark" phase and does >>>> class unloading which will call free_deallocate_list() which will >>>> return the memory for the Klass added to the deallocate list in step >>>> 4 to Metaspace. >>>> 7. The concurrent CMS cycle ends (the mirror is still in eden or young) >>>> 8. A new concurrent CMS cycle is started, the mirror will once again be >>>> treated as a root since it is still in eden or young (no YC has been >>>> done). >>>> 9. During the initial marking, CMS will now follow the pointer to the >>>> Klass that the mirror is mirroring, but we returned this memory to >>>> Metaspace in step 6. >>>> 10. We now crash :( >>>> >>>> Unfortunately, I don't have any suggestion on how to solve the above >>>> scenario at the moment. >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 2014-03-27 16:04, Coleen Phillimore wrote: >>>>> >>>>> On 3/27/14 8:39 AM, Stefan Karlsson wrote: >>>>>> >>>>>> On 2014-03-27 03:00, Coleen Phillimore wrote: >>>>>>> >>>>>>> I have a new version of this change based on code that Ioi noticed >>>>>>> that I was missing for making restoring the method's adapters >>>>>>> restartable if something fails during restore_unshareable_info, and >>>>>>> the constant pool resolved references array. >>>>>>> Please review this new code (only method.* and instanceKlass.cpp and >>>>>>> constantPool.cpp have differences). Reran tests with CDS and CMS. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/8028497_2/ >>>>>> >>>>>> This seems good. I'd prefer if someone with more experience with CDS >>>>>> also Reviews the change. >>>>> >>>>> Thanks, Ioi said he'd look at it. >>>>> >>>>>> >>>>>> Small comment: >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8028497_2/src/share/vm/oops/instanceKlass.cpp.udiff.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> - methodHandle m(THREAD, methods->at(index2)); >>>>>> - m()->link_method(m, CHECK); >>>>>> - // restore method's vtable by calling a virtual function >>>>>> - m->restore_vtable(); >>>>>> + Method *m = methods->at(index2); >>>>>> + m->restore_unshareable_info(CHECK); >>>>>> >>>>>> >>>>>> Do we really want to use a raw Method * here. I know that we wrap the >>>>>> method in a handle inside m->restore_unshareable_info, but it's not >>>>>> clear from the this context. I'm thinking about this issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8004815 >>>>>> >>>>>> On the other hand, I guess we can't redefine a class before it has >>>>>> been defined. But maybe it would be good to not promote the usage of >>>>>> Method* over calls that might hit a Safepoint. >>>>>> >>>>> >>>>> I think you're right, we don't use 'm' after the potential >>>>> safepoint and >>>>> we can't really redefine this class yet anyway but I'll restore the >>>>> code >>>>> because we don't want to encourage uses of unhandled Methods unless >>>>> proven to be harmless. >>>>> >>>>> Thanks! >>>>> Coleen >>>>>> thanks, >>>>>> StefanK >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 3/26/14 5:15 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Hi Jon, >>>>>>>> Thank you for looking at the code changes. >>>>>>>> >>>>>>>> On 3/26/14 12:24 PM, Jon Masamitsu wrote: >>>>>>>>> Coleen, >>>>>>>>> >>>>>>>>> Did you remove Class_obj_allocate() because it was only >>>>>>>>> called in that one spot and use obj_allocate() did most >>>>>>>>> of the work? >>>>>>>> >>>>>>>> I deleted it because GC doesn't need to know how these javaClasses >>>>>>>> are set up and I spent way to long looking for this code and didn't >>>>>>>> find it where it belongs, so I removed this. This >>>>>>>> Class_obj_allocate >>>>>>>> is an artifact of the permgen code. >>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/instanceMirrorKlass.cpp.frames.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 373 // the size in the mirror size itself. >>>>>>>>> >>>>>>>>> Drop the second "size". You know how we GC guys are >>>>>>>>> getting with our comments :-). >>>>>>>> >>>>>>>> Yes, I noticed that. Thanks - fixed. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/klass.cpp.frames.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 498 void Klass::restore_unshareable_info(TRAPS) { >>>>>>>>> 499 // If an exception happened during CDS restore, some of >>>>>>>>> these fields may already be >>>>>>>>> 500 // set. We leave the class on the CLD list, even if >>>>>>>>> incomplete so that we don't >>>>>>>>> 501 // modify the CLD list outside a safepoint. >>>>>>>>> 502 if (class_loader_data() == NULL) { >>>>>>>>> 503 ClassLoaderData* loader_data = >>>>>>>>> ClassLoaderData::the_null_class_loader_data(); >>>>>>>>> >>>>>>>>> I can see that this works with the current CDS (sharing only >>>>>>>>> classes loader >>>>>>>>> with the NULL class loader). Will it work if the shared classes >>>>>>>>> are loaded >>>>>>>>> with an application class loader? >>>>>>>> >>>>>>>> I hope Ioi can answer that. I assume so because the classes don't >>>>>>>> change class loaders if restoring shareable info fails. >>>>>>>> >>>>>>>> Ioi pointed out to me (not on open list) that I missed making >>>>>>>> link_method() and creating the constant pool resolved references >>>>>>>> array restartable, so I'm testing a fix for that also and I'll post >>>>>>>> an update later. But you've seen most of it. >>>>>>>> >>>>>>>> Thanks!! >>>>>>>> Coleen >>>>>>>>> >>>>>>>>> Rest looks good. >>>>>>>>> >>>>>>>>> Jon >>>>>>>>> >>>>>>>>> On 3/25/2014 1:42 PM, Coleen Phillimore wrote: >>>>>>>>>> Summary: Keep class in CLD::_klasses list and mirror created for >>>>>>>>>> CDS classes if OOM during restore_shareable_info(). This keeps >>>>>>>>>> pointers consistent for CMS. >>>>>>>>>> >>>>>>>>>> This change makes restoring the mirror for shared classes >>>>>>>>>> restartable if there is an OOM in the middle of >>>>>>>>>> restore_unshareable_info. The mirror field in the classes and >>>>>>>>>> CLD link is not cleaned up anymore. The class isn't marked >>>>>>>>>> loaded >>>>>>>>>> though so must be loaded again. >>>>>>>>>> >>>>>>>>>> Tested with Stefan's test case with hard coded OOM in jvm, so >>>>>>>>>> can't add the test. Also ran all the tests against -client and >>>>>>>>>> server with -Xshare:auto and with -XX:+UseConcMarkSweepGC. >>>>>>>>>> >>>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8028497/ >>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8028497 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From alejandro.murillo at oracle.com Tue Apr 8 15:56:58 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 08 Apr 2014 09:56:58 -0600 Subject: New repo for Hotspot fixes going into 7u releases In-Reply-To: <533EEFB0.3090902@oracle.com> References: <533EEFB0.3090902@oracle.com> Message-ID: <53441C4A.1050305@oracle.com> On 4/4/2014 11:45 AM, Alejandro E Murillo wrote: > > Hi All, > Currently all 7u Hotspot backports (7u60 and 7u80) are pushed to > hsx/jdk7u/hotspot [1]. > I'm taking a snapshot of that repo today and will push that to the > jdk7u master next Tuesday, > AFTER THAT all Hotspot changes destined for a 7u release (7u60, 7u80) > should be pushed straight to jdk7u/jdk7u-dev/hotspot [2]. > > So from now on, please do not push anything to hsx/jdk7u/hotspot. > If you have a change ready to go in, please wait until I push the > snapshot to master > (and jdk7u-dev) on Tuesday and then push the change to > jdk7u/jdk7u-dev/hotspot. > Please keep reading for the implications: > > (1) The major implication of that change is that hotspot fixes will > be taken to the master without going through a Hotspot specific PIT > (regular PIT for jdk7u-dev integrations will continue to happen as > usual), > so if you need to push a significant change, you will need to make sure > adequate testing is done before pushing to jdk7u/jdk7u-dev/hotspot, > because the PIT safety net is not available anymore. > > Depending on the magnitude of the change, developers should work > with SQE to do pre integration testing if they think is appropriate. > Most changes should have been tested in 8u and 9, before going to 7u, > so that should help making those decisions. However, there are > differences > between the 7u and 8u/9 code bases, like perm gen does not exists on > 8u/9 > and some other substantial differences. > > (2) Pushes should continue to be done via JPRT, so for external > users, create your webrevs > and committed patches based on the jdk7u/jdk7u-dev/hotspot repo and > continue to request a sponsor to make the final push to the repo, via > JPRT, > once changes have been reviewed and approved. > > (3) Hotspot developers did not have to request permission to push > changes to 7u repos, > because they were pushed to master as a bulk integration. Going > forward, Hotspot developers > will need to request permission to push to 7u repos as non hotspot > developers do. > Those requests need to be sent to jdk7u-dev at openjdk.java.net, > please continue to use hotspot-dev at openjdk.java.net (and other hotspot > group repos) > for discussions and reviews > > Let me know if you have any question/concern > Thanks > > [1] http://hg.openjdk.java.net/hsx/jdk7u/hotspot/ > [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/ > The last snapshot of hsx/jdk7u/hotspot (hs24.80-b06) has just been pushed to both jdk7u/jdk7u/hotspot and jdk7u/jdk7u-dev/hotspot, so hsx/jdk7u/hotspot will be switched to read only, please start pushing your hotspot changes for 7u releases to jdk7u/jdk7u-dev/hotspot as indicated above Thanks -- Alejandro From daniel.daugherty at oracle.com Tue Apr 8 17:16:07 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 08 Apr 2014 11:16:07 -0600 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <5343B3C0.3090704@oracle.com> References: <533D52B7.2090406@oracle.com> <5343B3C0.3090704@oracle.com> Message-ID: <53442ED7.1090505@oracle.com> > This variable is not meant to be documented. > We will only suggest it to the users which need to get rid of the > warning and complain about it. Given that the code you are changing is in the OpenJDK code base, not documenting the new _QUIET_JAVA_OPTIONS environment variable doesn't have a whole lot of meaning. It will be visible to anyone that has access to Google. Dan On 4/8/14 2:30 AM, Ivan Gerasimov wrote: > Hi everyone! > > That's the second round. > > First, here are a few thoughts about the issue: > > - When a console application is created, the user expects its output > (both stdout and stderr) to be predictable. > If I created a 'hello world' program, I would expect it to print only > what it's supposed to print, but nothing more. > > - The runtime should not intermix its output with the program output, > unless it is specifically told to do that. > In the documentation [1][2], it's not written that using > JAVA_TOOL_OPTIONS environment variable will make the runtime produce > warnings in the application stderr. > > - It is already specified, that in the cases when it might be unsafe > to pick up the options from the environment variable, the runtime does > not process them. > Here's the extract from [2]: "Platforms may disable this feature in > cases where security is a concern." > > [1] > http://docs.oracle.com/javase/8/docs/technotes/guides/tsgvm/envvars.html#env_var_sys_prop > [2] > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#tooloptions > > I totally agree that with JEP-158 implemented, this warning message > should definitely appear in the application logs. > It would always be useful it the logs, but not always is it useful in > the application stderr, because it can make the application caller > unnecessary complicated. > > I changed the fix to implement an alternative environment variable, > _QUIET_JAVA_OPTIONS, which behaves in the same way _JAVA_OPTIONS does, > but does not produce the warning message. > The change is quiet simple and does not change the current behavior of > JAVA_TOOL_OPTIONS or _JAVA_OPTIONS variables. > This variable is not meant to be documented. > We will only suggest it to the users which need to get rid of the > warning and complain about it. > > Would you please help review the new webrev: > http://cr.openjdk.java.net/~igerasim/8039152/1/webrev/ > > Sincerely yours, > Ivan > > > From coleen.phillimore at oracle.com Tue Apr 8 17:58:10 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 08 Apr 2014 13:58:10 -0400 Subject: RFR 8028497: SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool) In-Reply-To: <5344192E.9080202@oracle.com> References: <5331EA20.6000001@oracle.com> <5332FF22.4010900@oracle.com> <5333438B.8090508@oracle.com> <53338653.6060500@oracle.com> <53341BF7.6060309@oracle.com> <53343DFC.9000904@oracle.com> <53345BD5.5020806@oracle.com> <533A32C3.3090002@oracle.com> <533A79A5.6050307@oracle.com> <533ECF87.4030506@oracle.com> <5344192E.9080202@oracle.com> Message-ID: <534438B2.3010308@oracle.com> Thank you, Erik! Coleen On 4/8/14, 11:43 AM, Erik Helin wrote: > Coleen, > > the change http://cr.openjdk.java.net/~coleenp/8028497_4/ looks good. > > Thanks for taking care of this patch! > Erik > > On 2014-04-04 17:28, Coleen Phillimore wrote: >> >> Erik, >> Thank you for the discussion and thorough code reviews. See below. >> (other reviewers: there's a new version of webrev, read down a little). >> >> On 4/1/14 4:32 AM, Erik Helin wrote: >>> On 2014-04-01 05:30, Coleen Phillimore wrote: >>>> >>>> Erik, >>>> >>>> You are right. The old code would use the Klass->mirror link to clear >>>> out the mirror->Klass link so that we didn't have a pointer to a >>>> deallocated Klass in a mirror that might still be live for CMS >>>> marking. >>>> The new code doesn't set the Klass->mirror link unless the mirror >>>> fields >>>> are completely allocated, so we could crash if we deallocated a Klass >>>> before the mirror because the mirror would still be pointing to the >>>> class. >>>> >>>> I've caught failed allocation in mirror fields so that the link is >>>> reset >>>> in this change. The only change is to the function create_mirror >>>> calls >>>> initialize_mirror_fields. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8028497_3/ >>> >>> In javaClasses.cpp: >>> void java_lang_Class::create_mirror(KlassHandle k, Handle, TRAPS) { >>> ... >>> initialize_mirror_fields(k, mirror, protection_domain, THREAD); >>> if (HAS_PENDING_EXCEPTION) { >>> // If any of the fields throws an exception like OOM remove the >>> // klass field from the mirror so GC doesn't follow it after the >>> // klass has been deallocated. >>> java_lang_Class::set_klass(mirror(), k()); >>> return; ^ >>> } | >>> | >>> +------------------------------------------+ >>> | >>> +-- Do you really want to use k() here? I thought the idea was to do: >>> java_lang_Class::set_klass(mirror(), NULL); >>> >> >> I had meant to change this to NULL. >>> Setting the Klass that the mirror is mirroring will hit the following >>> check in instanceMirrorKlass.cpp, oop_oop_iterate macro: >>> >>> int InstanceMirrorKlass::oop_oop_iterate##nv_suffix(...) >>> { \ >>> ... \ >>> if_do_metadata_checked(closure, nv_suffix) >>> { \ >>> Klass* klass = >>> java_lang_Class::as_Klass(obj); \ >>> /* We'll get NULL for primitive mirrors. >>> */ \ >>> if (klass != NULL) >>> { \ >>> closure->do_klass##nv_suffix(klass); \ >>> } \ >>> } >>> >>> Setting the Klass that the mirror is mirroring to NULL will make the >>> mirror look like a primitive mirror (this is the way we encode >>> primitive mirrors). Will that be a problem? >>> >> >> No, this is fine. I added a comment that this mirror isn't a primitive >> type but it's also not representative of a class. I had internal code >> to generate lots of these mirrors and CMS and G1 work fine because they >> don't follow the klass. We don't want them to. We also clean up these >> orphaned mirrors, which I also verified manually. >> >> I also tested heap walking with temporary code to create lots of >> orphaned mirrors. I tried to create an internal test or a white box >> test but wasn't able to generate the right set of circumstances to >> exercise this code. If necessary, we can open another bug to add a >> test but I found it noreg-hard. >> >> This is also tested with Stefan's TreeMapTest.java test case that also >> required temporary code in the jvm. >> >> So yes, I think we want to be able to set the Klass field in the mirror >> to null. If other bugs fall out because of this in the future, I think >> we should fix the other bugs separately. >> >> New webrev with only this classfile/javaClasses.cpp change is here. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8028497_4/ >> >> Thanks! >> Coleen >>> Thanks, >>> Erik >>> >>>> Tested with vm.parallel_class_loading.testlist which do hit this case. >>>> >>>> Thanks! >>>> Coleen >>>> >>>> >>>> On 3/27/14 1:11 PM, Erik Helin wrote: >>>>> Hi Coleen, >>>>> >>>>> thanks for taking on this tricky bug! However, I think there is an >>>>> issue with your fix :( >>>>> >>>>> This case is for "normal" (non-CDS) class loading: >>>>> 1. We create the mirror >>>>> 2. We set up the link from the mirror to the Klass >>>>> 3. We fail somewhere before setting the link from the Klass to the >>>>> mirror, for example when allocating the Java object for the init >>>>> lock. >>>>> 4. The destructor for ClassFileParser is run and we add the Klass to >>>>> the >>>>> deallocate list. >>>>> 5. A CMS concurrent cycle is started, it will treat all objects in >>>>> eden >>>>> + the survivor area as roots (including the mirror). >>>>> 6. The above concurrent cycle enters the "final remark" phase and >>>>> does >>>>> class unloading which will call free_deallocate_list() which will >>>>> return the memory for the Klass added to the deallocate list in >>>>> step >>>>> 4 to Metaspace. >>>>> 7. The concurrent CMS cycle ends (the mirror is still in eden or >>>>> young) >>>>> 8. A new concurrent CMS cycle is started, the mirror will once >>>>> again be >>>>> treated as a root since it is still in eden or young (no YC has >>>>> been >>>>> done). >>>>> 9. During the initial marking, CMS will now follow the pointer to the >>>>> Klass that the mirror is mirroring, but we returned this memory to >>>>> Metaspace in step 6. >>>>> 10. We now crash :( >>>>> >>>>> Unfortunately, I don't have any suggestion on how to solve the above >>>>> scenario at the moment. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>> On 2014-03-27 16:04, Coleen Phillimore wrote: >>>>>> >>>>>> On 3/27/14 8:39 AM, Stefan Karlsson wrote: >>>>>>> >>>>>>> On 2014-03-27 03:00, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> I have a new version of this change based on code that Ioi noticed >>>>>>>> that I was missing for making restoring the method's adapters >>>>>>>> restartable if something fails during restore_unshareable_info, >>>>>>>> and >>>>>>>> the constant pool resolved references array. >>>>>>>> Please review this new code (only method.* and >>>>>>>> instanceKlass.cpp and >>>>>>>> constantPool.cpp have differences). Reran tests with CDS and CMS. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/8028497_2/ >>>>>>> >>>>>>> This seems good. I'd prefer if someone with more experience with >>>>>>> CDS >>>>>>> also Reviews the change. >>>>>> >>>>>> Thanks, Ioi said he'd look at it. >>>>>> >>>>>>> >>>>>>> Small comment: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/8028497_2/src/share/vm/oops/instanceKlass.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> - methodHandle m(THREAD, methods->at(index2)); >>>>>>> - m()->link_method(m, CHECK); >>>>>>> - // restore method's vtable by calling a virtual function >>>>>>> - m->restore_vtable(); >>>>>>> + Method *m = methods->at(index2); >>>>>>> + m->restore_unshareable_info(CHECK); >>>>>>> >>>>>>> >>>>>>> Do we really want to use a raw Method * here. I know that we >>>>>>> wrap the >>>>>>> method in a handle inside m->restore_unshareable_info, but it's not >>>>>>> clear from the this context. I'm thinking about this issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8004815 >>>>>>> >>>>>>> On the other hand, I guess we can't redefine a class before it has >>>>>>> been defined. But maybe it would be good to not promote the >>>>>>> usage of >>>>>>> Method* over calls that might hit a Safepoint. >>>>>>> >>>>>> >>>>>> I think you're right, we don't use 'm' after the potential >>>>>> safepoint and >>>>>> we can't really redefine this class yet anyway but I'll restore the >>>>>> code >>>>>> because we don't want to encourage uses of unhandled Methods unless >>>>>> proven to be harmless. >>>>>> >>>>>> Thanks! >>>>>> Coleen >>>>>>> thanks, >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/26/14 5:15 PM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> Hi Jon, >>>>>>>>> Thank you for looking at the code changes. >>>>>>>>> >>>>>>>>> On 3/26/14 12:24 PM, Jon Masamitsu wrote: >>>>>>>>>> Coleen, >>>>>>>>>> >>>>>>>>>> Did you remove Class_obj_allocate() because it was only >>>>>>>>>> called in that one spot and use obj_allocate() did most >>>>>>>>>> of the work? >>>>>>>>> >>>>>>>>> I deleted it because GC doesn't need to know how these >>>>>>>>> javaClasses >>>>>>>>> are set up and I spent way to long looking for this code and >>>>>>>>> didn't >>>>>>>>> find it where it belongs, so I removed this. This >>>>>>>>> Class_obj_allocate >>>>>>>>> is an artifact of the permgen code. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/instanceMirrorKlass.cpp.frames.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 373 // the size in the mirror size itself. >>>>>>>>>> >>>>>>>>>> Drop the second "size". You know how we GC guys are >>>>>>>>>> getting with our comments :-). >>>>>>>>> >>>>>>>>> Yes, I noticed that. Thanks - fixed. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8028497/src/share/vm/oops/klass.cpp.frames.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 498 void Klass::restore_unshareable_info(TRAPS) { >>>>>>>>>> 499 // If an exception happened during CDS restore, some of >>>>>>>>>> these fields may already be >>>>>>>>>> 500 // set. We leave the class on the CLD list, even if >>>>>>>>>> incomplete so that we don't >>>>>>>>>> 501 // modify the CLD list outside a safepoint. >>>>>>>>>> 502 if (class_loader_data() == NULL) { >>>>>>>>>> 503 ClassLoaderData* loader_data = >>>>>>>>>> ClassLoaderData::the_null_class_loader_data(); >>>>>>>>>> >>>>>>>>>> I can see that this works with the current CDS (sharing only >>>>>>>>>> classes loader >>>>>>>>>> with the NULL class loader). Will it work if the shared classes >>>>>>>>>> are loaded >>>>>>>>>> with an application class loader? >>>>>>>>> >>>>>>>>> I hope Ioi can answer that. I assume so because the classes >>>>>>>>> don't >>>>>>>>> change class loaders if restoring shareable info fails. >>>>>>>>> >>>>>>>>> Ioi pointed out to me (not on open list) that I missed making >>>>>>>>> link_method() and creating the constant pool resolved references >>>>>>>>> array restartable, so I'm testing a fix for that also and I'll >>>>>>>>> post >>>>>>>>> an update later. But you've seen most of it. >>>>>>>>> >>>>>>>>> Thanks!! >>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> Rest looks good. >>>>>>>>>> >>>>>>>>>> Jon >>>>>>>>>> >>>>>>>>>> On 3/25/2014 1:42 PM, Coleen Phillimore wrote: >>>>>>>>>>> Summary: Keep class in CLD::_klasses list and mirror created >>>>>>>>>>> for >>>>>>>>>>> CDS classes if OOM during restore_shareable_info(). This keeps >>>>>>>>>>> pointers consistent for CMS. >>>>>>>>>>> >>>>>>>>>>> This change makes restoring the mirror for shared classes >>>>>>>>>>> restartable if there is an OOM in the middle of >>>>>>>>>>> restore_unshareable_info. The mirror field in the classes and >>>>>>>>>>> CLD link is not cleaned up anymore. The class isn't marked >>>>>>>>>>> loaded >>>>>>>>>>> though so must be loaded again. >>>>>>>>>>> >>>>>>>>>>> Tested with Stefan's test case with hard coded OOM in jvm, so >>>>>>>>>>> can't add the test. Also ran all the tests against -client >>>>>>>>>>> and >>>>>>>>>>> server with -Xshare:auto and with -XX:+UseConcMarkSweepGC. >>>>>>>>>>> >>>>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8028497/ >>>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8028497 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From ivan.gerasimov at oracle.com Tue Apr 8 17:59:18 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Apr 2014 21:59:18 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <53442ED7.1090505@oracle.com> References: <533D52B7.2090406@oracle.com> <5343B3C0.3090704@oracle.com> <53442ED7.1090505@oracle.com> Message-ID: <534438F6.1080104@oracle.com> On 08.04.2014 21:16, Daniel D. Daugherty wrote: > > This variable is not meant to be documented. > > We will only suggest it to the users which need to get rid of the > > warning and complain about it. > > Given that the code you are changing is in the OpenJDK code base, > not documenting the new _QUIET_JAVA_OPTIONS environment variable > doesn't have a whole lot of meaning. It will be visible to anyone > that has access to Google. > Yes, of course. I only meant that it's not going to become the recommended way to pass options with an environment variable. It will only be suggested to the users who really need it. Sincerely yours, Ivan > Dan > > > On 4/8/14 2:30 AM, Ivan Gerasimov wrote: >> Hi everyone! >> >> That's the second round. >> >> First, here are a few thoughts about the issue: >> >> - When a console application is created, the user expects its output >> (both stdout and stderr) to be predictable. >> If I created a 'hello world' program, I would expect it to print only >> what it's supposed to print, but nothing more. >> >> - The runtime should not intermix its output with the program output, >> unless it is specifically told to do that. >> In the documentation [1][2], it's not written that using >> JAVA_TOOL_OPTIONS environment variable will make the runtime produce >> warnings in the application stderr. >> >> - It is already specified, that in the cases when it might be unsafe >> to pick up the options from the environment variable, the runtime >> does not process them. >> Here's the extract from [2]: "Platforms may disable this feature in >> cases where security is a concern." >> >> [1] >> http://docs.oracle.com/javase/8/docs/technotes/guides/tsgvm/envvars.html#env_var_sys_prop >> [2] >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#tooloptions >> >> I totally agree that with JEP-158 implemented, this warning message >> should definitely appear in the application logs. >> It would always be useful it the logs, but not always is it useful in >> the application stderr, because it can make the application caller >> unnecessary complicated. >> >> I changed the fix to implement an alternative environment variable, >> _QUIET_JAVA_OPTIONS, which behaves in the same way _JAVA_OPTIONS >> does, but does not produce the warning message. >> The change is quiet simple and does not change the current behavior >> of JAVA_TOOL_OPTIONS or _JAVA_OPTIONS variables. >> This variable is not meant to be documented. >> We will only suggest it to the users which need to get rid of the >> warning and complain about it. >> >> Would you please help review the new webrev: >> http://cr.openjdk.java.net/~igerasim/8039152/1/webrev/ >> >> Sincerely yours, >> Ivan >> >> >> > > > From cleber at nightcoders.com.br Tue Apr 8 19:57:18 2014 From: cleber at nightcoders.com.br (Cleber Muramoto) Date: Tue, 8 Apr 2014 16:57:18 -0300 Subject: hotspot-dev Digest, Vol 84, Issue 18 In-Reply-To: References: Message-ID: Hi Aleksey, the code essentially uses specialized classes to avoid reflection during serialization. I will try to "proxy" the test bellow, if you need more details please let me know. Given public class A{ int i; long j; //can have references as well } There will be an associated serializer to read/write A instances: public class A$Ser implements Serializer { @Override public void write(Object o, ByteBuffer dst){ //writes class metadata doWrite(o,dst); } //writes object's payload @Override public void doWrite(Object o, ByteBuffer dst){ A a = (A)o; dst.putInt(a.i); dst.putLong(a.j); } //reads object's payload @Override public void doRead(Object o, ByteBuffer src){ A a = (A)o; a.i=dst.getInt(); b.j=dst.getLong(); } @Override public A read(ByteBuffer src){ //reads metadata and instantiate A a =new A(); doRead(a,src); return a; } } The benchmark code essentially does: ForkJoinPool fjp = ...(created using Available Processors = 48) final ByteBuffer bb=ByteBuffer.allocateDirect(HUGE_BLOCK); int[] index=new int[max]; //writes are always serial on the test for(int i=0;iwrote: > > > Message: 6 > Date: Tue, 08 Apr 2014 13:33:22 +0400 > From: Aleksey Shipilev > To: Cleber Muramoto , > hotspot-dev at openjdk.java.net > Subject: Re: JDK 8 great performance increase on ByteBuffer read > performance!? > Message-ID: <5343C262.3080403 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Cleber, > > On 04/07/2014 07:15 PM, Cleber Muramoto wrote: > > I have a microbenchmark that does millions of iterations serializing and > > deserializing objects to/from ByteBuffers > > Care to share the benchmark code? > > -Aleksey. > > > From vladimir.kozlov at oracle.com Tue Apr 8 20:32:50 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Apr 2014 13:32:50 -0700 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <533AB62D.1010501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> Message-ID: <53445CF2.50909@oracle.com> Hi Dmitry, Could you tell when you are planning to backport these changes into 8u20? Thanks, Vladimir On 4/1/14 5:50 AM, Dmitry Samersoff wrote: > Goetz, > > Push done. > > Let it bakes for some times in JDK9 (at least two nightlies) than I'll > push it to 8u20 > > -Dmitry > > On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >> Thanks Dmitry and Vladimir! >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, March 27, 2014 8:18 PM >> To: Dmitry Samersoff; Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() >> >> Thank you, Dmitry >> >> We need to backport it into 8u20 too. >> >> Regards, >> Vladimir >> >> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> I can push it to RT next week. >>> >>> -Dmitry >>> >>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Looks good for me! >>>> >>>> +1. >>>> >>>> Dmitry, >>>> >>>> Do you want me to push it into Comp repo or you will do it into RT repo? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>> I had a look at set_boot_path(). That will never return false, >>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>> In addition it would be wrong to return, there should be a >>>>>> call to vm_exit_... >>>>>> So I removed the test and return statement. >>>>>> I added the other missing FREEs. >>>>>> >>>>>> I also implemented your proposal with only one sprintf >>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>> to get it more similar. Solaris seems too different to >>>>>> adapt to that scheme. >>>>>> >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Goetz, >>>>>> >>>>>> Thank you for doing it - code is much cleaner now. >>>>>> >>>>>> os_aix.cpp: >>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>> >>>>>> os_bsd.cpp: >>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>> >>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>> >>>>>> >>>>>> ll.497 (and below) a trick like one below: >>>>>> >>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>> char *v_colon = ":"; >>>>>> >>>>>> if (l != NULL || v != NULL) { >>>>>> >>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>> >>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>> >>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>>> if (ld_library_path != buf){ ... /* free ld_library_path */ } >>>>>> ld_library_path = t; >>>>>> } >>>>>> >>>>>> might be useful to assemble the path in one shot, >>>>>> without extra copying >>>>>> >>>>>> >>>>>> ll.520 As you appending constant value ":.", you can just >>>>>> take it into account at ll. 495 >>>>>> >>>>>> >>>>>> os_linux.cpp: >>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>> >>>>>> os_solaris.cpp: >>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>> >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please have a look at this new webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>> >>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>> the missing parts in here, below. >>>>>>> >>>>>>> Avoiding big stack allocations I wanted to remove the buf[MAXPATHLEN] >>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>> get along >>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>> >>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>> readability of the code. >>>>>>> >>>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>>> beginning >>>>>>> and do a single allocation for them. >>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Goetz, >>>>>>> >>>>>>>> The allocation in 556 must know about the length of the >>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>> >>>>>>> You can use >>>>>>> >>>>>>> MAX( >>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>>> ) >>>>>>> >>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>> >>>>>>> But I'm fine with two different allocations. >>>>>>> >>>>>>> Thank you for addressing other concerns. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> see my comments inline. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> os_aix.cpp: 565 >>>>>>>>> >>>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>> known size. At >>>>>>>> least more or less, as I know there will be only one path of >>>>>>>> unknown size in the buffer. >>>>>>>> The allocation in 556 must know about the length of the >>>>>>>> getenv("LIBPATH") result, >>>>>>>> which may contain several paths. >>>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>>> buffers are needed. >>>>>>>> >>>>>>>>> os_bsd.cpp: 350 >>>>>>>>> >>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, it makes >>>>>>>>> code much more readable. >>>>>>>> I'll fix this. >>>>>>>> >>>>>>>>> os_bsd.cpp: 485 >>>>>>>>> >>>>>>>>> you replace malloc to on-stack allocation of more than 4096 bytes. I >>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>> > see also comments to os_aix above - you can allocate large enough >>>>>>>>> buffer once and than reuse it. >>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in the >>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>> compiler. >>>>>>>> >>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>>> buffer. >>>>>>>> I'll do this the same on all four platforms. >>>>>>>> >>>>>>>>> os_linux.cpp: 434 >>>>>>>>> the same comments as above. >>>>>>>>> >>>>>>>>> os_solaris.cpp: 728 >>>>>>>>> >>>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>>> changed >>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>> respect >>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>> variables. >>>>>>>>> >>>>>>>>> Could you change it to something like: >>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>> Yes, I'll fix that. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == -1) { >>>>>>> ... >>>>>>> >>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>> mtInternal); >>>>>>> ... >>>>>>> >>>>>>> os_solaris.cpp: 829 >>>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>> >>>>>>>> This change addresses the implementation of >>>>>>>> init_system_properties_values >>>>>>>> on aix, linux, solaris and bsd. >>>>>>>> In init_system_properties_values a macro was defined mapping malloc to >>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful allocation >>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>> pointers as >>>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>>> calls to free(). >>>>>>>> >>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>> removes >>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>> local array where >>>>>>>> possible. >>>>>>>> >>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>> SystemProperty::set_value(). >>>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>> Most of these >>>>>>>> frees were missing. >>>>>>>> >>>>>>>> This change adds the missing frees. >>>>>>>> >>>>>>>> Testing this change I ran into a warning in ppc code which I fixed, >>>>>>>> too. >>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> > > From dmitry.samersoff at oracle.com Tue Apr 8 21:19:07 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 01:19:07 +0400 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53445CF2.50909@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> Message-ID: <534467CB.8010307@oracle.com> Vladimir, On 2014-04-09 00:32, Vladimir Kozlov wrote: > Could you tell when you are planning to backport these changes into 8u20? This week. Do I need any additional approvals? -Dmitry > > Thanks, > Vladimir > > On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >> Goetz, >> >> Push done. >> >> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >> push it to 8u20 >> >> -Dmitry >> >> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>> Thanks Dmitry and Vladimir! >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Thursday, March 27, 2014 8:18 PM >>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>> in init_system_properties_values() >>> >>> Thank you, Dmitry >>> >>> We need to backport it into 8u20 too. >>> >>> Regards, >>> Vladimir >>> >>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>> Vladimir, >>>> >>>> I can push it to RT next week. >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>> Goetz, >>>>>> >>>>>> Looks good for me! >>>>> >>>>> +1. >>>>> >>>>> Dmitry, >>>>> >>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>> repo? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>> In addition it would be wrong to return, there should be a >>>>>>> call to vm_exit_... >>>>>>> So I removed the test and return statement. >>>>>>> I added the other missing FREEs. >>>>>>> >>>>>>> I also implemented your proposal with only one sprintf >>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>> to get it more similar. Solaris seems too different to >>>>>>> adapt to that scheme. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>>> in init_system_properties_values() >>>>>>> >>>>>>> Goetz, >>>>>>> >>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>> >>>>>>> os_aix.cpp: >>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>> >>>>>>> os_bsd.cpp: >>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>> >>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>> >>>>>>> >>>>>>> ll.497 (and below) a trick like one below: >>>>>>> >>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>> char *v_colon = ":"; >>>>>>> >>>>>>> if (l != NULL || v != NULL) { >>>>>>> >>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>> >>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>> >>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>> ld_library_path */ } >>>>>>> ld_library_path = t; >>>>>>> } >>>>>>> >>>>>>> might be useful to assemble the path in one shot, >>>>>>> without extra copying >>>>>>> >>>>>>> >>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>> take it into account at ll. 495 >>>>>>> >>>>>>> >>>>>>> os_linux.cpp: >>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>> >>>>>>> os_solaris.cpp: >>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>> >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please have a look at this new webrev: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>> >>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>> the missing parts in here, below. >>>>>>>> >>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>> buf[MAXPATHLEN] >>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>> get along >>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>> >>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>> readability of the code. >>>>>>>> >>>>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>>>> beginning >>>>>>>> and do a single allocation for them. >>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>> >>>>>>>> You can use >>>>>>>> >>>>>>>> MAX( >>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>>>> ) >>>>>>>> >>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>> >>>>>>>> But I'm fine with two different allocations. >>>>>>>> >>>>>>>> Thank you for addressing other concerns. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> see my comments inline. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>> >>>>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>> known size. At >>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>> unknown size in the buffer. >>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>> getenv("LIBPATH") result, >>>>>>>>> which may contain several paths. >>>>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>>>> buffers are needed. >>>>>>>>> >>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>> >>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>> it makes >>>>>>>>>> code much more readable. >>>>>>>>> I'll fix this. >>>>>>>>> >>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>> >>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>> bytes. I >>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>> large enough >>>>>>>>>> buffer once and than reuse it. >>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>> the >>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>> compiler. >>>>>>>>> >>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>>>> buffer. >>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>> >>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>> the same comments as above. >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>> >>>>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>>>> changed >>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>> respect >>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>> variables. >>>>>>>>>> >>>>>>>>>> Could you change it to something like: >>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>> Yes, I'll fix that. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>> -1) { >>>>>>>> ... >>>>>>>> >>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>> mtInternal); >>>>>>>> ... >>>>>>>> >>>>>>>> os_solaris.cpp: 829 >>>>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>> >>>>>>>>> This change addresses the implementation of >>>>>>>>> init_system_properties_values >>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>> malloc to >>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>> allocation >>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>> pointers as >>>>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>>>> calls to free(). >>>>>>>>> >>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>> removes >>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>> local array where >>>>>>>>> possible. >>>>>>>>> >>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>> SystemProperty::set_value(). >>>>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>> Most of these >>>>>>>>> frees were missing. >>>>>>>>> >>>>>>>>> This change adds the missing frees. >>>>>>>>> >>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>> fixed, >>>>>>>>> too. >>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Tue Apr 8 21:31:14 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 01:31:14 +0400 Subject: RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS In-Reply-To: <534438F6.1080104@oracle.com> References: <533D52B7.2090406@oracle.com> <5343B3C0.3090704@oracle.com> <53442ED7.1090505@oracle.com> <534438F6.1080104@oracle.com> Message-ID: <53446AA2.2000406@oracle.com> Ivan, As this option allows silently alter a class path it's ever more dangerous than providing a key to suppress warning. I would prefer not to have these changes. Sorry! -Dmitry On 2014-04-08 21:59, Ivan Gerasimov wrote: > > On 08.04.2014 21:16, Daniel D. Daugherty wrote: >> > This variable is not meant to be documented. >> > We will only suggest it to the users which need to get rid of the >> > warning and complain about it. >> >> Given that the code you are changing is in the OpenJDK code base, >> not documenting the new _QUIET_JAVA_OPTIONS environment variable >> doesn't have a whole lot of meaning. It will be visible to anyone >> that has access to Google. >> > Yes, of course. > I only meant that it's not going to become the recommended way to pass > options with an environment variable. > It will only be suggested to the users who really need it. > > Sincerely yours, > Ivan > >> Dan >> >> >> On 4/8/14 2:30 AM, Ivan Gerasimov wrote: >>> Hi everyone! >>> >>> That's the second round. >>> >>> First, here are a few thoughts about the issue: >>> >>> - When a console application is created, the user expects its output >>> (both stdout and stderr) to be predictable. >>> If I created a 'hello world' program, I would expect it to print only >>> what it's supposed to print, but nothing more. >>> >>> - The runtime should not intermix its output with the program output, >>> unless it is specifically told to do that. >>> In the documentation [1][2], it's not written that using >>> JAVA_TOOL_OPTIONS environment variable will make the runtime produce >>> warnings in the application stderr. >>> >>> - It is already specified, that in the cases when it might be unsafe >>> to pick up the options from the environment variable, the runtime >>> does not process them. >>> Here's the extract from [2]: "Platforms may disable this feature in >>> cases where security is a concern." >>> >>> [1] >>> http://docs.oracle.com/javase/8/docs/technotes/guides/tsgvm/envvars.html#env_var_sys_prop >>> >>> [2] >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#tooloptions >>> >>> >>> I totally agree that with JEP-158 implemented, this warning message >>> should definitely appear in the application logs. >>> It would always be useful it the logs, but not always is it useful in >>> the application stderr, because it can make the application caller >>> unnecessary complicated. >>> >>> I changed the fix to implement an alternative environment variable, >>> _QUIET_JAVA_OPTIONS, which behaves in the same way _JAVA_OPTIONS >>> does, but does not produce the warning message. >>> The change is quiet simple and does not change the current behavior >>> of JAVA_TOOL_OPTIONS or _JAVA_OPTIONS variables. >>> This variable is not meant to be documented. >>> We will only suggest it to the users which need to get rid of the >>> warning and complain about it. >>> >>> Would you please help review the new webrev: >>> http://cr.openjdk.java.net/~igerasim/8039152/1/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> >> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vladimir.kozlov at oracle.com Tue Apr 8 21:43:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Apr 2014 14:43:38 -0700 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <534467CB.8010307@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> Message-ID: <53446D8A.5020207@oracle.com> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: > Vladimir, > > On 2014-04-09 00:32, Vladimir Kozlov wrote: > >> Could you tell when you are planning to backport these changes into 8u20? > > This week. Do I need any additional approvals? No need for approval but, please, send new [8u20] RFR to hotspot-dev with links to jbs and jdk9 changeset and say that it applies cleanly (if it is). I will review it and you can push. It is to let people know that you backport it. Thanks, Vladimir > > -Dmitry > >> >> Thanks, >> Vladimir >> >> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>> Goetz, >>> >>> Push done. >>> >>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>> push it to 8u20 >>> >>> -Dmitry >>> >>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>> Thanks Dmitry and Vladimir! >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Thursday, March 27, 2014 8:18 PM >>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>> in init_system_properties_values() >>>> >>>> Thank you, Dmitry >>>> >>>> We need to backport it into 8u20 too. >>>> >>>> Regards, >>>> Vladimir >>>> >>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>> Vladimir, >>>>> >>>>> I can push it to RT next week. >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>> Goetz, >>>>>>> >>>>>>> Looks good for me! >>>>>> >>>>>> +1. >>>>>> >>>>>> Dmitry, >>>>>> >>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>> repo? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>> call to vm_exit_... >>>>>>>> So I removed the test and return statement. >>>>>>>> I added the other missing FREEs. >>>>>>>> >>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>> adapt to that scheme. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>>>> in init_system_properties_values() >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>> >>>>>>>> os_aix.cpp: >>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>> >>>>>>>> os_bsd.cpp: >>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>> >>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>> >>>>>>>> >>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>> >>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>> char *v_colon = ":"; >>>>>>>> >>>>>>>> if (l != NULL || v != NULL) { >>>>>>>> >>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>> >>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>> >>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>> ld_library_path */ } >>>>>>>> ld_library_path = t; >>>>>>>> } >>>>>>>> >>>>>>>> might be useful to assemble the path in one shot, >>>>>>>> without extra copying >>>>>>>> >>>>>>>> >>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>> take it into account at ll. 495 >>>>>>>> >>>>>>>> >>>>>>>> os_linux.cpp: >>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>> >>>>>>>> os_solaris.cpp: >>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please have a look at this new webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>> >>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>> the missing parts in here, below. >>>>>>>>> >>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>> buf[MAXPATHLEN] >>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>> get along >>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>> >>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>> readability of the code. >>>>>>>>> >>>>>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>>>>> beginning >>>>>>>>> and do a single allocation for them. >>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>> >>>>>>>>> You can use >>>>>>>>> >>>>>>>>> MAX( >>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>>>>> ) >>>>>>>>> >>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>> >>>>>>>>> But I'm fine with two different allocations. >>>>>>>>> >>>>>>>>> Thank you for addressing other concerns. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> see my comments inline. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>> >>>>>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>> known size. At >>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>> unknown size in the buffer. >>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>> which may contain several paths. >>>>>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>>>>> buffers are needed. >>>>>>>>>> >>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>> >>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>> it makes >>>>>>>>>>> code much more readable. >>>>>>>>>> I'll fix this. >>>>>>>>>> >>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>> >>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>> bytes. I >>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>> large enough >>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>> the >>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>> compiler. >>>>>>>>>> >>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>>>>> buffer. >>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>> >>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>> the same comments as above. >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>> >>>>>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>>>>> changed >>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>> respect >>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>> variables. >>>>>>>>>>> >>>>>>>>>>> Could you change it to something like: >>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>> Yes, I'll fix that. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>> -1) { >>>>>>>>> ... >>>>>>>>> >>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>> mtInternal); >>>>>>>>> ... >>>>>>>>> >>>>>>>>> os_solaris.cpp: 829 >>>>>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>> >>>>>>>>>> This change addresses the implementation of >>>>>>>>>> init_system_properties_values >>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>> malloc to >>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>> allocation >>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>> pointers as >>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>>>>> calls to free(). >>>>>>>>>> >>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>> removes >>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>> local array where >>>>>>>>>> possible. >>>>>>>>>> >>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>> Most of these >>>>>>>>>> frees were missing. >>>>>>>>>> >>>>>>>>>> This change adds the missing frees. >>>>>>>>>> >>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>> fixed, >>>>>>>>>> too. >>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From dmitry.samersoff at oracle.com Tue Apr 8 22:08:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 02:08:18 +0400 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53446D8A.5020207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> Message-ID: <53447352.9020603@oracle.com> Vladimir, OK. Thank you for clarification. -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alejandro.murillo at oracle.com Wed Apr 9 00:15:38 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 08 Apr 2014 18:15:38 -0600 Subject: [8u20] RFR (XS): 8036619: Shark: add LLVM 3.4 support In-Reply-To: <1396857064.3726.2.camel@galactica.localdomain> References: <1395062146.3881.4.camel@galactica.localdomain> <1396857064.3726.2.camel@galactica.localdomain> Message-ID: <5344912A.7060900@oracle.com> On 4/7/2014 1:51 AM, Mario Torre wrote: > On Mon, 2014-03-17 at 14:15 +0100, Mario Torre wrote: >> Resending with correct webrev and subject :) >> >> I would like to ask the backport of the changes made for the following >> bug report into JDK 8 (jdk8u20): >> >> https://bugs.openjdk.java.net/browse/JDK-8036619 >> >> The changes apply cleanly without modification: >> >> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ >> >> The related changes for JDK 9 are here: >> >> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.02/ >> >> The discussion here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/012814.html >> >> and here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012679.html >> >> I can't push myself, so if OK, someone would need to do for me. >> >> Cheers, >> Mario >> >> > ping? > > Cheers, > Mario > Hi there, I just pushed this patch: http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ to jdk8u/hs-dev/hotspot: http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/81d7a4b28dc5 BTW, jcheck complained about a few tabs in http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/src/share/vm/shark/sharkMemoryManager.cpp.udiff.html next time please run jcheck before sending out a patch to make sure those are fixed cheers -- Alejandro From goetz.lindenmaier at sap.com Wed Apr 9 06:40:52 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 9 Apr 2014 06:40:52 +0000 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53447352.9020603@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53447352.9020603@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAF4B6@DEWDFEMB12A.global.corp.sap> Vladimir, Dmitry, Thanks for handling this! Sorry I can't help. Best regards, Goetz -----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Mittwoch, 9. April 2014 00:08 To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Vladimir, OK. Thank you for clarification. -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From roland.westrelin at oracle.com Wed Apr 9 07:54:36 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Apr 2014 09:54:36 +0200 Subject: [8u20] RFR(S): 8032011 nsk/stress/jck60/jck60022 crashes in src\share\vm\runtime\synchronizer.cpp:239 Message-ID: Please, review backport to 8u20. The patch applies cleanly. This was pushed to jdk9 more than 1 month ago. http://cr.openjdk.java.net/~roland/8032011/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8032011 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3df21373e577 Roland. From Tobias.Hartmann at oracle.com Wed Apr 9 13:19:44 2014 From: Tobias.Hartmann at oracle.com (Tobias Hartmann) Date: Wed, 09 Apr 2014 15:19:44 +0200 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray Message-ID: <534548F0.3010401@oracle.com> Hi, please review the following patch. *Problem:* The implementation of "JDK-8015774: Add support for multiple code heaps" needs to manage multiple code heaps in the code cache. They will be stored in a GrowableArray data structure. Frequent accesses to the array using indices make the code more unreadable and error prone and result in code duplication. Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 *Solution:* To simplify the access to the code heaps, the GrowableArray is adapted to support STL-style iterators. Further, custom iterators allow to only iterate over elements that satisfy a given predicate. This helps to access only specific code heaps. Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ *Tests:* JPRT with segmented code cache implementation (to be reviewed) Thanks, Tobias From dmitry.samersoff at oracle.com Wed Apr 9 14:53:32 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 18:53:32 +0400 Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53446D8A.5020207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> Message-ID: <53455EEC.3030900@oracle.com> Hi Everybody, I would like to ask the backport of the changes made for the following bug report into JDK 8 (jdk8u20): Changes applies clearly, without modifications. CR: https://bugs.openjdk.java.net/browse/JDK-8038201 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/goetz/JDK-8038201/webrev.8u20/ JDK9 changeset http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/bba041a9a030 -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From volker.simonis at gmail.com Wed Apr 9 16:34:41 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Apr 2014 18:34:41 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp Message-ID: Hi, could you please review and sponsor the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8039805/ https://bugs.openjdk.java.net/browse/JDK-8039805 which fixes the signature of the global new/delete operators in allocation.cpp For non-product builds allocation.cpp defines global new/delete operators which shut down the VM if they get called at runtime. The rational behind this is that the these global operators should never be used in HotSpot. Unfortunately, the signature of some of these operators doesn't conform to the C++ standard which confuses some C++ compilers. For a more detailed explanation of the C++ background of this issue see the new comments in allcoation.cpp and the end of this mail. This change also replaces the asserts in the operators with guarantees because the code may also be active in not-product (aka. 'optimized') builds. Finally, the webrev fixes two places in the AIX-port which used the global new operator. After the change we can now remove the definition of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. I have also removed ALLOW_OPERATOR_NEW_USAGE from bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp which state that on Mac OS X the global new/delete operators from the HotSpot cause problems together with usages of these operators from the class library such as the ones from Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t observe any such problems but if anybody has some concrete concerns I'm ready to remove this part from the webrev. I've build and tested these changes on Linux/x86_64, Linux/ppc64, Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially run the regression tests from sun/security/ec which exercise the method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which was mentioned to cause problems in conjunction with the globally defined new/delete operators from the HotSpot but couldn't see any issues, neither in the slowdebug nor in the optimized build. Following some C++ background regarding the global new/delete operators: In C++98/03 the throwing new operators are defined with the following signature: void* operator new(std::size_tsize) throw(std::bad_alloc); void* operator new[](std::size_tsize) throw(std::bad_alloc); while all the other (non-throwing) new and delete operators are defined with an empty throw clause (i.e. "operator delete(void* p) throw()") which means that they do not throw any exceptions (see section 18.4 of the C++ standard http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). In the new C++11/14 standard (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), the signature of the throwing new operators was changed by completely omitting the throw clause (which effectively means they could throw any exception) while all the other new/delete operators where changed to have a 'nothrow' clause instead of an empty throw clause. Unfortunately, the support for exception specifications among C++ compilers is still very fragile. While some more strict compilers like AIX xlC or HP aCC reject to override the default throwing new operator with a user operator with an empty throw() clause, the MS Visual C++ compiler warns for every non-empty throw clause like throw(std::bad_alloc) that it will ignore the exception specification (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). I've therefore changed the operator definitions such that they correctly work with all currently supported compilers and in way which should be upwards compatible with C++11/14. Please notice that I'm aware of the discussion around "8021954: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced" (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) which introduced empty throw() clauses on all user defined new operators. But I think the rational used for that change doesn't apply here, because these global, user user defined new operators changed in this webrev aren't meant to be really used. There only task is to override the default, global operators (and therefore they need to have the right signature) and to shut the VM down if they get called. Thank you and best regards, Volker From vladimir.kozlov at oracle.com Wed Apr 9 17:22:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 10:22:00 -0700 Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53455EEC.3030900@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53455EEC.3030900@oracle.com> Message-ID: <534581B8.6020304@oracle.com> Looks good. Thanks, Vladimir On 4/9/14 7:53 AM, Dmitry Samersoff wrote: > Hi Everybody, > > I would like to ask the backport of the changes made for the following > bug report into JDK 8 (jdk8u20): > > Changes applies clearly, without modifications. > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8038201 > > Webrev: > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/goetz/JDK-8038201/webrev.8u20/ > > JDK9 changeset > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/bba041a9a030 > > -Dmitry > > On 2014-04-09 01:43, Vladimir Kozlov wrote: >> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> On 2014-04-09 00:32, Vladimir Kozlov wrote: >>> >>>> Could you tell when you are planning to backport these changes into >>>> 8u20? >>> >>> This week. Do I need any additional approvals? >> >> No need for approval but, please, send new [8u20] RFR to hotspot-dev >> with links to jbs and jdk9 changeset and say that it applies cleanly (if >> it is). I will review it and you can push. >> It is to let people know that you backport it. >> >> Thanks, >> Vladimir >> >>> >>> -Dmitry >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Push done. >>>>> >>>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>>> push it to 8u20 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>>> Thanks Dmitry and Vladimir! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Thank you, Dmitry >>>>>> >>>>>> We need to backport it into 8u20 too. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I can push it to RT next week. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Looks good for me! >>>>>>>> >>>>>>>> +1. >>>>>>>> >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>>> repo? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>>> call to vm_exit_... >>>>>>>>>> So I removed the test and return statement. >>>>>>>>>> I added the other missing FREEs. >>>>>>>>>> >>>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>>> adapt to that scheme. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() >>>>>>>>>> in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>>> >>>>>>>>>> os_aix.cpp: >>>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>>> >>>>>>>>>> os_bsd.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>>> >>>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>>> >>>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>>> char *v_colon = ":"; >>>>>>>>>> >>>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>>> >>>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>>> >>>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>>> >>>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>>> ld_library_path); >>>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>>> ld_library_path */ } >>>>>>>>>> ld_library_path = t; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>>> without extra copying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>>> take it into account at ll. 495 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> os_linux.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please have a look at this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>>> the missing parts in here, below. >>>>>>>>>>> >>>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>>> get along >>>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>>> >>>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>>> readability of the code. >>>>>>>>>>> >>>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> and do a single allocation for them. >>>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>>> >>>>>>>>>>> You can use >>>>>>>>>>> >>>>>>>>>>> MAX( >>>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>>> >>>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>>> >>>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> see my comments inline. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>>> >>>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>>> three >>>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>>> known size. At >>>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>>> which may contain several paths. >>>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>>> two >>>>>>>>>>>> buffers are needed. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>>> it makes >>>>>>>>>>>>> code much more readable. >>>>>>>>>>>> I'll fix this. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>>> >>>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>>> bytes. I >>>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>>> large enough >>>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>>> the >>>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>>> compiler. >>>>>>>>>>>> >>>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>>> spaces >>>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>>> allocated >>>>>>>>>>>> buffer. >>>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>>> >>>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>>> the same comments as above. >>>>>>>>>>>>> >>>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>>> >>>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>>> code >>>>>>>>>>>>> changed >>>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>>> respect >>>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>>> variables. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>>> -1) { >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>>> mtInternal); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>>> os_bsd.cpp >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>>> init_system_properties_values >>>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>>> malloc to >>>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>>> allocation >>>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>>> pointers as >>>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>>> and >>>>>>>>>>>> calls to free(). >>>>>>>>>>>> >>>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>>> removes >>>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>>> local array where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>>> allocated in >>>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>>> Most of these >>>>>>>>>>>> frees were missing. >>>>>>>>>>>> >>>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>>> >>>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>>> fixed, >>>>>>>>>>>> too. >>>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From thomas.stuefe at gmail.com Wed Apr 9 17:50:02 2014 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Wed, 9 Apr 2014 19:50:02 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: Message-ID: Hi Volker, > This change also replaces the asserts in the operators with guarantees > because the code may also be active in not-product (aka. 'optimized') > builds. > > I think defining global operator new in production code would be a bad idea; the most obvious reason would be that any third party binary loaded into the process space could do a new() which would trigger the guarantee. So, I'd prefer a #ifndef ASSERT #error #endif in the code... If we really want to enable global operator new/delete for production code, we should provide allocations instead of guaranteeing or returning NULL. But this still would be dangerous, mainly because it is possible that other libraries bring their own versions of op new/delete and they may interfere with our operators. Kind Regards, Thomas From vladimir.kozlov at oracle.com Wed Apr 9 18:36:12 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 11:36:12 -0700 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray In-Reply-To: <534548F0.3010401@oracle.com> References: <534548F0.3010401@oracle.com> Message-ID: <5345931C.8080705@oracle.com> Hi Tobias Changes looks fine to me. I would only move initial pre-declaration of 2 new templates after GenericGrowableArray definition and before GrowableArray template which uses them. Thanks, Vladimir On 4/9/14 6:19 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > *Problem:* > The implementation of "JDK-8015774: Add support for multiple code heaps" > needs to manage multiple code heaps in the code cache. They will be > stored in a GrowableArray data structure. Frequent accesses to the array > using indices make the code more unreadable and error prone and result > in code duplication. > Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 > > *Solution:* > To simplify the access to the code heaps, the GrowableArray is adapted > to support STL-style iterators. Further, custom iterators allow to only > iterate over elements that satisfy a given predicate. This helps to > access only specific code heaps. > Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ > > *Tests:* > JPRT with segmented code cache implementation (to be reviewed) > > Thanks, > > Tobias From vitalyd at gmail.com Wed Apr 9 19:53:44 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 9 Apr 2014 15:53:44 -0400 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray In-Reply-To: <5345931C.8080705@oracle.com> References: <534548F0.3010401@oracle.com> <5345931C.8080705@oracle.com> Message-ID: I would add a few asserts: 1) verify that position provided to iterator is within valid range 2) equality operators should verify that both iterators point to same GA instances These are pedantic given how these iterators will be used, but wouldn't hurt, IMHO. Sent from my phone On Apr 9, 2014 2:37 PM, "Vladimir Kozlov" wrote: > Hi Tobias > > Changes looks fine to me. I would only move initial pre-declaration of 2 > new templates after GenericGrowableArray definition and before > GrowableArray template which uses them. > > Thanks, > Vladimir > > On 4/9/14 6:19 AM, Tobias Hartmann wrote: > >> Hi, >> >> please review the following patch. >> >> *Problem:* >> The implementation of "JDK-8015774: Add support for multiple code heaps" >> needs to manage multiple code heaps in the code cache. They will be >> stored in a GrowableArray data structure. Frequent accesses to the array >> using indices make the code more unreadable and error prone and result >> in code duplication. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 >> >> *Solution:* >> To simplify the access to the code heaps, the GrowableArray is adapted >> to support STL-style iterators. Further, custom iterators allow to only >> iterate over elements that satisfy a given predicate. This helps to >> access only specific code heaps. >> Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ >> >> *Tests:* >> JPRT with segmented code cache implementation (to be reviewed) >> >> Thanks, >> >> Tobias >> > From volker.simonis at gmail.com Wed Apr 9 22:21:53 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Apr 2014 00:21:53 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: Message-ID: On Wednesday, April 9, 2014, Thomas St?fe wrote: > Hi Volker, > > > >> This change also replaces the asserts in the operators with guarantees >> because the code may also be active in not-product (aka. 'optimized') >> builds. >> >> > I think defining global operator new in production code would be a bad > idea; > But that's not what I want and not what I actually did. As I wrote, the global operators are only defined in a not-product configuration. That's exactly how it should be and I didn't change that. 'optimized' is a Hotspot build configuration which builds the Hotspot in optimized mode but without defining 'PRODUCT' - i.e. an optimized non-product build (just take look at the Hotspot make files). Of course you have no assertions in an optimized build, that's why I changed the asserts in the global operators into guarantees. In a 'release' build - i.e. and an optimized product build, the global operators (and thus the guarantees) of course won't be visible because of the obvious reasons mentioned by you and by the corresponding comments in allocation.cpp. Regards, Volker > the most obvious reason would be that any third party binary loaded into > the > process space could do a new() which would trigger the guarantee. > > So, I'd prefer a > #ifndef ASSERT > #error > #endif > in the code... > > If we really want to enable global operator new/delete for production > code, we > should provide allocations instead of guaranteeing or returning NULL. > > But this still would be dangerous, mainly because it is possible that > other > libraries bring their own versions of op new/delete and they may interfere > with our operators. > > Kind Regards, Thomas > > > From vladimir.kozlov at oracle.com Wed Apr 9 22:47:03 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 15:47:03 -0700 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: Message-ID: <5345CDE7.90808@oracle.com> Hi Volker I am worried about ALLOW_OPERATOR_NEW_USAGE change. I read https://bugs.openjdk.java.net/browse/JDK-8012902 and I think runtime group should do review of these changes and test them. You can use fatal(msg) instead of guarantee(false, msg). thanks, Vladimir On 4/9/14 9:34 AM, Volker Simonis wrote: > Hi, > > could you please review and sponsor the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8039805/ > https://bugs.openjdk.java.net/browse/JDK-8039805 > > which fixes the signature of the global new/delete operators in allocation.cpp > > For non-product builds allocation.cpp defines global new/delete > operators which shut down the VM if they get called at runtime. The > rational behind this is that the these global operators should never > be used in HotSpot. > > Unfortunately, the signature of some of these operators doesn't > conform to the C++ standard which confuses some C++ compilers. For a > more detailed explanation of the C++ background of this issue see the > new comments in allcoation.cpp and the end of this mail. > > This change also replaces the asserts in the operators with guarantees > because the code may also be active in not-product (aka. 'optimized') > builds. > > Finally, the webrev fixes two places in the AIX-port which used the > global new operator. After the change we can now remove the definition > of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. > > I have also removed ALLOW_OPERATOR_NEW_USAGE from > bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp > which state that on Mac OS X the global new/delete operators from the > HotSpot cause problems together with usages of these operators from > the class library such as the ones from > Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t > observe any such problems but if anybody has some concrete concerns > I'm ready to remove this part from the webrev. > > I've build and tested these changes on Linux/x86_64, Linux/ppc64, > Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially > run the regression tests from sun/security/ec which exercise the > method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which > was mentioned to cause problems in conjunction with the globally > defined new/delete operators from the HotSpot but couldn't see any > issues, neither in the slowdebug nor in the optimized build. > > Following some C++ background regarding the global new/delete operators: > > In C++98/03 the throwing new operators are defined with the following signature: > > void* operator new(std::size_tsize) throw(std::bad_alloc); > void* operator new[](std::size_tsize) throw(std::bad_alloc); > > while all the other (non-throwing) new and delete operators are > defined with an empty throw clause (i.e. "operator delete(void* p) > throw()") which means that they do not throw any exceptions (see > section 18.4 of the C++ standard > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). > > In the new C++11/14 standard > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), > the signature of the throwing new operators was changed by completely > omitting the throw clause (which effectively means they could throw > any exception) while all the other new/delete operators where changed > to have a 'nothrow' clause instead of an empty throw clause. > > Unfortunately, the support for exception specifications among C++ > compilers is still very fragile. While some more strict compilers like > AIX xlC or HP aCC reject to override the default throwing new operator > with a user operator with an empty throw() clause, the MS Visual C++ > compiler warns for every non-empty throw clause like > throw(std::bad_alloc) that it will ignore the exception specification > (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). > > I've therefore changed the operator definitions such that they > correctly work with all currently supported compilers and in way which > should be upwards compatible with C++11/14. > > Please notice that I'm aware of the discussion around "8021954: VM > SIGSEGV during classloading on MacOS; hs_err_pid file produced" > (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) > which introduced empty throw() clauses on all user defined new > operators. But I think the rational used for that change doesn't apply > here, because these global, user user defined new operators changed in > this webrev aren't meant to be really used. There only task is to > override the default, global operators (and therefore they need to > have the right signature) and to shut the VM down if they get called. > > Thank you and best regards, > Volker > From vladimir.kozlov at oracle.com Wed Apr 9 22:53:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 15:53:37 -0700 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAF4B6@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53447352.9020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAF4B6@DEWDFEMB12A.global.corp.sap> Message-ID: <5345CF71.8070303@oracle.com> Hi Goetz, You can help :) When Dmitry push the patch into jdk8u/hs-dev can you build and test from it on your platforms (ppc64)? If everything is fine I will do the final merge into ppc-aix-port/stage and we will freeze it. thanks, Vladimir On 4/8/14 11:40 PM, Lindenmaier, Goetz wrote: > Vladimir, Dmitry, > > Thanks for handling this! > Sorry I can't help. > > Best regards, > Goetz > > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Mittwoch, 9. April 2014 00:08 > To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Vladimir, > > OK. Thank you for clarification. > > -Dmitry > > On 2014-04-09 01:43, Vladimir Kozlov wrote: >> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> On 2014-04-09 00:32, Vladimir Kozlov wrote: >>> >>>> Could you tell when you are planning to backport these changes into >>>> 8u20? >>> >>> This week. Do I need any additional approvals? >> >> No need for approval but, please, send new [8u20] RFR to hotspot-dev >> with links to jbs and jdk9 changeset and say that it applies cleanly (if >> it is). I will review it and you can push. >> It is to let people know that you backport it. >> >> Thanks, >> Vladimir >> >>> >>> -Dmitry >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Push done. >>>>> >>>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>>> push it to 8u20 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>>> Thanks Dmitry and Vladimir! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Thank you, Dmitry >>>>>> >>>>>> We need to backport it into 8u20 too. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I can push it to RT next week. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Looks good for me! >>>>>>>> >>>>>>>> +1. >>>>>>>> >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>>> repo? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>>> call to vm_exit_... >>>>>>>>>> So I removed the test and return statement. >>>>>>>>>> I added the other missing FREEs. >>>>>>>>>> >>>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>>> adapt to that scheme. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() >>>>>>>>>> in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>>> >>>>>>>>>> os_aix.cpp: >>>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>>> >>>>>>>>>> os_bsd.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>>> >>>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>>> >>>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>>> char *v_colon = ":"; >>>>>>>>>> >>>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>>> >>>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>>> >>>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>>> >>>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>>> ld_library_path); >>>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>>> ld_library_path */ } >>>>>>>>>> ld_library_path = t; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>>> without extra copying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>>> take it into account at ll. 495 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> os_linux.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please have a look at this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>>> the missing parts in here, below. >>>>>>>>>>> >>>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>>> get along >>>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>>> >>>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>>> readability of the code. >>>>>>>>>>> >>>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> and do a single allocation for them. >>>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>>> >>>>>>>>>>> You can use >>>>>>>>>>> >>>>>>>>>>> MAX( >>>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>>> >>>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>>> >>>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> see my comments inline. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>>> >>>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>>> three >>>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>>> known size. At >>>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>>> which may contain several paths. >>>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>>> two >>>>>>>>>>>> buffers are needed. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>>> it makes >>>>>>>>>>>>> code much more readable. >>>>>>>>>>>> I'll fix this. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>>> >>>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>>> bytes. I >>>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>>> large enough >>>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>>> the >>>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>>> compiler. >>>>>>>>>>>> >>>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>>> spaces >>>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>>> allocated >>>>>>>>>>>> buffer. >>>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>>> >>>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>>> the same comments as above. >>>>>>>>>>>>> >>>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>>> >>>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>>> code >>>>>>>>>>>>> changed >>>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>>> respect >>>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>>> variables. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>>> -1) { >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>>> mtInternal); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>>> os_bsd.cpp >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>>> init_system_properties_values >>>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>>> malloc to >>>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>>> allocation >>>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>>> pointers as >>>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>>> and >>>>>>>>>>>> calls to free(). >>>>>>>>>>>> >>>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>>> removes >>>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>>> local array where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>>> allocated in >>>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>>> Most of these >>>>>>>>>>>> frees were missing. >>>>>>>>>>>> >>>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>>> >>>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>>> fixed, >>>>>>>>>>>> too. >>>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From alejandro.murillo at oracle.com Thu Apr 10 00:15:11 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 09 Apr 2014 18:15:11 -0600 Subject: RFR 8030011: Update Hotspot version string output Message-ID: <5345E28F.5050108@oracle.com> Please review this change to make the hotspot related output produced by "java -version" match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo being built and add it to the hotspot version output, but that will require changes in the JPRT, so we have decided to split the change in 2 bugs. One to make the version match (above webrev) and another one, an RFE, to add additional information extracted from the repo. Note that in the current version of vm_version.cpp, there is no error checking in product mode, I was suggested to make that explicit. Release Engineering did some testing and I also ran several cases with full and just hotspot JPRT builds. Here is a summary of how the new output compares to the old one: (1) Release Engineering builds (9-dev): from jdk9-dev build: java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) compared with what we currently have java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (2) Release Engineering builds (jdk9): java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) compared with what we currently have java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (3) JPRT Full builds: java version "1.9.0-internal" # Java(TM) SE Runtime Environment (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode) (4) JPRT hotspot only builds: java version "1.9.0-ea-fastdebug" # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed mode) in this one the built VM is inserted into a promoted build bundle, since we do not have the JDK build number info in the hotspot repo, we can't match the build number in the JDK portion. With the RFE mentioned above, we can extract the build info from the repo and add it to the hotspot portion. I want to mention, that this may change once the new JDK version change is implemented but we don't know when that will be implemented yet, so we need to go ahead with this to get rid of the old hotspot express output. And most of these changes will still have to be done anyways BTW, john Coomes and Dan Daugherty provided feedback in some pieces of this webrev, but I need full reviews now. Thanks -- Alejandro From christian.thalinger at oracle.com Thu Apr 10 02:12:43 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Apr 2014 16:12:43 -1000 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray In-Reply-To: <534548F0.3010401@oracle.com> References: <534548F0.3010401@oracle.com> Message-ID: <9BD57EFC-7E31-4710-B77C-469E00C6226B@oracle.com> That?s good thinking. I like the change. On Apr 9, 2014, at 3:19 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Problem: > The implementation of "JDK-8015774: Add support for multiple code heaps" needs to manage multiple code heaps in the code cache. They will be stored in a GrowableArray data structure. Frequent accesses to the array using indices make the code more unreadable and error prone and result in code duplication. > Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 > > Solution: > To simplify the access to the code heaps, the GrowableArray is adapted to support STL-style iterators. Further, custom iterators allow to only iterate over elements that satisfy a given predicate. This helps to access only specific code heaps. > Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ > > Tests: > JPRT with segmented code cache implementation (to be reviewed) > > Thanks, > > Tobias From david.holmes at oracle.com Thu Apr 10 02:38:44 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Apr 2014 12:38:44 +1000 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <5345E28F.5050108@oracle.com> References: <5345E28F.5050108@oracle.com> Message-ID: <53460434.50400@oracle.com> Hi Alejandro, Given we have to maintain the JDK version information in two places (top level repo and hotspot repo) wouldn't it have been simpler to keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set the major/minor/build values to match those of the JDK version? That aside, in jdk_version file hotspot copyright should now be 2014 */vm.make: This line is way too long. ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" -DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\"" -DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\"" Not clear why we suddenly need defines for all the component pieces either. You could have kept the HS_XXX variables, just adding the micro part. David On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: > > Please review this change to make the hotspot related output produced by > "java -version" > match the corresponding JDK output: > > webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 > > Note that we initially wanted to obtain more information from the repo > being built and add > it to the hotspot version output, but that will require changes in the > JPRT, so > we have decided to split the change in 2 bugs. One to make the version > match > (above webrev) and another one, an RFE, to add additional information > extracted from the repo. > > Note that in the current version of vm_version.cpp, there is no error > checking in product mode, > I was suggested to make that explicit. > > Release Engineering did some testing and I also ran several cases with > full and just hotspot JPRT builds. > > Here is a summary of how the new output compares to the old one: > > (1) Release Engineering builds (9-dev): > > from jdk9-dev build: > java version "1.9.0-ea" > Java(TM) SE Runtime Environment (build > 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) > Java HotSpot(TM) 64-Bit Server VM (build > 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) > > compared with what we currently have > java version "1.9.0-ea" > Java(TM) SE Runtime Environment (build > 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) > > (2) Release Engineering builds (jdk9): > > java version "1.9.0-ea" > Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) > Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) > > compared with what we currently have > java version "1.9.0-ea" > Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) > > (3) JPRT Full builds: > > java version "1.9.0-internal" > # Java(TM) SE Runtime Environment (build > 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) > # Java HotSpot(TM) Server VM (build > 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode) > > > (4) JPRT hotspot only builds: > > java version "1.9.0-ea-fastdebug" > # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) > # Java HotSpot(TM) Server VM (build > 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed > mode) > > > in this one the built VM is inserted into a promoted build bundle, > since we do not have the JDK build number info in the hotspot repo, > we can't match the build number in the JDK portion. > With the RFE mentioned above, we can extract the build info from the repo > and add it to the hotspot portion. > > I want to mention, that this may change once the new JDK version change > is implemented > but we don't know when that will be implemented yet, so we need to go > ahead with this to > get rid of the old hotspot express output. And most of these changes > will still have to be done > anyways > > BTW, john Coomes and Dan Daugherty provided feedback in some pieces of > this webrev, > but I need full reviews now. > > Thanks > From david.holmes at oracle.com Thu Apr 10 02:48:10 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Apr 2014 12:48:10 +1000 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: Message-ID: <5346066A.3000401@oracle.com> Hi Volker, Need more time to consider this in full but from the existing code: 689 // On certain platforms, such as Mac OS X (Darwin), in debug version, new is being called 690 // from jdk source and causing data corruption. Such as 691 // Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair 692 // define ALLOW_OPERATOR_NEW_USAGE for platform on which global operator new allowed. we actually fixed that by using the mapfiles to ensure the hotspot operator new was not visible externally. The existence of ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the time :( https://bugs.openjdk.java.net/browse/JDK-8014326 David On 10/04/2014 2:34 AM, Volker Simonis wrote: > Hi, > > could you please review and sponsor the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8039805/ > https://bugs.openjdk.java.net/browse/JDK-8039805 > > which fixes the signature of the global new/delete operators in allocation.cpp > > For non-product builds allocation.cpp defines global new/delete > operators which shut down the VM if they get called at runtime. The > rational behind this is that the these global operators should never > be used in HotSpot. > > Unfortunately, the signature of some of these operators doesn't > conform to the C++ standard which confuses some C++ compilers. For a > more detailed explanation of the C++ background of this issue see the > new comments in allcoation.cpp and the end of this mail. > > This change also replaces the asserts in the operators with guarantees > because the code may also be active in not-product (aka. 'optimized') > builds. > > Finally, the webrev fixes two places in the AIX-port which used the > global new operator. After the change we can now remove the definition > of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. > > I have also removed ALLOW_OPERATOR_NEW_USAGE from > bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp > which state that on Mac OS X the global new/delete operators from the > HotSpot cause problems together with usages of these operators from > the class library such as the ones from > Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t > observe any such problems but if anybody has some concrete concerns > I'm ready to remove this part from the webrev. > > I've build and tested these changes on Linux/x86_64, Linux/ppc64, > Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially > run the regression tests from sun/security/ec which exercise the > method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which > was mentioned to cause problems in conjunction with the globally > defined new/delete operators from the HotSpot but couldn't see any > issues, neither in the slowdebug nor in the optimized build. > > Following some C++ background regarding the global new/delete operators: > > In C++98/03 the throwing new operators are defined with the following signature: > > void* operator new(std::size_tsize) throw(std::bad_alloc); > void* operator new[](std::size_tsize) throw(std::bad_alloc); > > while all the other (non-throwing) new and delete operators are > defined with an empty throw clause (i.e. "operator delete(void* p) > throw()") which means that they do not throw any exceptions (see > section 18.4 of the C++ standard > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). > > In the new C++11/14 standard > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), > the signature of the throwing new operators was changed by completely > omitting the throw clause (which effectively means they could throw > any exception) while all the other new/delete operators where changed > to have a 'nothrow' clause instead of an empty throw clause. > > Unfortunately, the support for exception specifications among C++ > compilers is still very fragile. While some more strict compilers like > AIX xlC or HP aCC reject to override the default throwing new operator > with a user operator with an empty throw() clause, the MS Visual C++ > compiler warns for every non-empty throw clause like > throw(std::bad_alloc) that it will ignore the exception specification > (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). > > I've therefore changed the operator definitions such that they > correctly work with all currently supported compilers and in way which > should be upwards compatible with C++11/14. > > Please notice that I'm aware of the discussion around "8021954: VM > SIGSEGV during classloading on MacOS; hs_err_pid file produced" > (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) > which introduced empty throw() clauses on all user defined new > operators. But I think the rational used for that change doesn't apply > here, because these global, user user defined new operators changed in > this webrev aren't meant to be really used. There only task is to > override the default, global operators (and therefore they need to > have the right signature) and to shut the VM down if they get called. > > Thank you and best regards, > Volker > From christian.thalinger at oracle.com Thu Apr 10 02:49:54 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Apr 2014 16:49:54 -1000 Subject: [8u20] RFR(S): 8032011 nsk/stress/jck60/jck60022 crashes in src\share\vm\runtime\synchronizer.cpp:239 In-Reply-To: References: Message-ID: Looks good. On Apr 8, 2014, at 9:54 PM, Roland Westrelin wrote: > Please, review backport to 8u20. The patch applies cleanly. This was pushed to jdk9 more than 1 month ago. > > http://cr.openjdk.java.net/~roland/8032011/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8032011 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3df21373e577 > > Roland. From vladimir.kozlov at oracle.com Thu Apr 10 02:53:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 19:53:14 -0700 Subject: [8u20] RFR(S): 8032011 nsk/stress/jck60/jck60022 crashes in src\share\vm\runtime\synchronizer.cpp:239 In-Reply-To: References: Message-ID: <5346079A.30804@oracle.com> On 4/9/14 7:49 PM, Christian Thalinger wrote: > Looks good. +1. Thanks, Vladimir > > On Apr 8, 2014, at 9:54 PM, Roland Westrelin wrote: > >> Please, review backport to 8u20. The patch applies cleanly. This was pushed to jdk9 more than 1 month ago. >> >> http://cr.openjdk.java.net/~roland/8032011/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8032011 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3df21373e577 >> >> Roland. > From vladimir.kozlov at oracle.com Thu Apr 10 03:01:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 20:01:00 -0700 Subject: [8u20] RFR 8038939: Some options related to RTM locking optimization works inconsistently Message-ID: <5346096C.80700@oracle.com> Please, review 8u20 backport. These changes were pushed into jdk9 today. They were tested by SQE using RTM tests (in review to be added to Hotspot jtreg tests). Current Nightly testing will show nothing because RTM optimization is off by default. Changes from jdk9 applied to 8u without conflicts. http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ee2e2f0fe8bb http://cr.openjdk.java.net/~kvn/8038939/webrev https://bugs.openjdk.java.net/browse/JDK-8038939 Thanks, Vladimir From david.holmes at oracle.com Thu Apr 10 03:19:22 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Apr 2014 13:19:22 +1000 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <5346066A.3000401@oracle.com> References: <5346066A.3000401@oracle.com> Message-ID: <53460DBA.4010708@oracle.com> I think we should just delete the whole ALLOW_OPERATOR_NEW block. We fixed the problem of it being called outside the VM under 8014326. David On 10/04/2014 12:48 PM, David Holmes wrote: > Hi Volker, > > Need more time to consider this in full but from the existing code: > > 689 // On certain platforms, such as Mac OS X (Darwin), in debug > version, new is being called > 690 // from jdk source and causing data corruption. Such as > 691 // Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair > 692 // define ALLOW_OPERATOR_NEW_USAGE for platform on which global > operator new allowed. > > we actually fixed that by using the mapfiles to ensure the hotspot > operator new was not visible externally. The existence of > ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the time :( > > https://bugs.openjdk.java.net/browse/JDK-8014326 > > David > > On 10/04/2014 2:34 AM, Volker Simonis wrote: >> Hi, >> >> could you please review and sponsor the following small change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8039805/ >> https://bugs.openjdk.java.net/browse/JDK-8039805 >> >> which fixes the signature of the global new/delete operators in >> allocation.cpp >> >> For non-product builds allocation.cpp defines global new/delete >> operators which shut down the VM if they get called at runtime. The >> rational behind this is that the these global operators should never >> be used in HotSpot. >> >> Unfortunately, the signature of some of these operators doesn't >> conform to the C++ standard which confuses some C++ compilers. For a >> more detailed explanation of the C++ background of this issue see the >> new comments in allcoation.cpp and the end of this mail. >> >> This change also replaces the asserts in the operators with guarantees >> because the code may also be active in not-product (aka. 'optimized') >> builds. >> >> Finally, the webrev fixes two places in the AIX-port which used the >> global new operator. After the change we can now remove the definition >> of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. >> >> I have also removed ALLOW_OPERATOR_NEW_USAGE from >> bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp >> which state that on Mac OS X the global new/delete operators from the >> HotSpot cause problems together with usages of these operators from >> the class library such as the ones from >> Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t >> observe any such problems but if anybody has some concrete concerns >> I'm ready to remove this part from the webrev. >> >> I've build and tested these changes on Linux/x86_64, Linux/ppc64, >> Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially >> run the regression tests from sun/security/ec which exercise the >> method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which >> was mentioned to cause problems in conjunction with the globally >> defined new/delete operators from the HotSpot but couldn't see any >> issues, neither in the slowdebug nor in the optimized build. >> >> Following some C++ background regarding the global new/delete operators: >> >> In C++98/03 the throwing new operators are defined with the following >> signature: >> >> void* operator new(std::size_tsize) throw(std::bad_alloc); >> void* operator new[](std::size_tsize) throw(std::bad_alloc); >> >> while all the other (non-throwing) new and delete operators are >> defined with an empty throw clause (i.e. "operator delete(void* p) >> throw()") which means that they do not throw any exceptions (see >> section 18.4 of the C++ standard >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). >> >> In the new C++11/14 standard >> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), >> the signature of the throwing new operators was changed by completely >> omitting the throw clause (which effectively means they could throw >> any exception) while all the other new/delete operators where changed >> to have a 'nothrow' clause instead of an empty throw clause. >> >> Unfortunately, the support for exception specifications among C++ >> compilers is still very fragile. While some more strict compilers like >> AIX xlC or HP aCC reject to override the default throwing new operator >> with a user operator with an empty throw() clause, the MS Visual C++ >> compiler warns for every non-empty throw clause like >> throw(std::bad_alloc) that it will ignore the exception specification >> (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). >> >> I've therefore changed the operator definitions such that they >> correctly work with all currently supported compilers and in way which >> should be upwards compatible with C++11/14. >> >> Please notice that I'm aware of the discussion around "8021954: VM >> SIGSEGV during classloading on MacOS; hs_err_pid file produced" >> (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, >> >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) >> which introduced empty throw() clauses on all user defined new >> operators. But I think the rational used for that change doesn't apply >> here, because these global, user user defined new operators changed in >> this webrev aren't meant to be really used. There only task is to >> override the default, global operators (and therefore they need to >> have the right signature) and to shut the VM down if they get called. >> >> Thank you and best regards, >> Volker >> From christian.thalinger at oracle.com Thu Apr 10 03:33:57 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Apr 2014 17:33:57 -1000 Subject: [8u20] RFR 8038939: Some options related to RTM locking optimization works inconsistently In-Reply-To: <5346096C.80700@oracle.com> References: <5346096C.80700@oracle.com> Message-ID: Looks good. On Apr 9, 2014, at 5:01 PM, Vladimir Kozlov wrote: > Please, review 8u20 backport. > > These changes were pushed into jdk9 today. They were tested by SQE using RTM tests (in review to be added to Hotspot jtreg tests). Current Nightly testing will show nothing because RTM optimization is off by default. > > Changes from jdk9 applied to 8u without conflicts. > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ee2e2f0fe8bb > http://cr.openjdk.java.net/~kvn/8038939/webrev > https://bugs.openjdk.java.net/browse/JDK-8038939 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Apr 10 05:02:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 22:02:01 -0700 Subject: [8u20] RFR 8038939: Some options related to RTM locking optimization works inconsistently In-Reply-To: References: <5346096C.80700@oracle.com> Message-ID: <534625C9.5030009@oracle.com> Thank you, Christian Vladimir On 4/9/14 8:33 PM, Christian Thalinger wrote: > Looks good. > > On Apr 9, 2014, at 5:01 PM, Vladimir Kozlov wrote: > >> Please, review 8u20 backport. >> >> These changes were pushed into jdk9 today. They were tested by SQE using RTM tests (in review to be added to Hotspot jtreg tests). Current Nightly testing will show nothing because RTM optimization is off by default. >> >> Changes from jdk9 applied to 8u without conflicts. >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ee2e2f0fe8bb >> http://cr.openjdk.java.net/~kvn/8038939/webrev >> https://bugs.openjdk.java.net/browse/JDK-8038939 >> >> Thanks, >> Vladimir > From thomas.stuefe at gmail.com Thu Apr 10 05:49:35 2014 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Thu, 10 Apr 2014 07:49:35 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: Message-ID: > > But that's not what I want and not what I actually did. As I wrote, the > global operators are only defined in a not-product configuration. That's > exactly how it should be and I didn't change that. > > 'optimized' is a Hotspot build configuration which builds the Hotspot in > optimized mode but without defining 'PRODUCT' - i.e. an optimized > non-product build (just take look at the Hotspot make files). Of course you > have no assertions in an optimized build, that's why I changed the asserts > in the global operators into guarantees. > > > Hi Volker, I did not think you wanted to define global operator new in production code. What I meant is that I think that defining global operator new is dangerous and I do not want to ship that even accidentally; accidents happen, makefiles can change. To make that intention clear, I would generate a compile time error in the to-be-shipped code right in the source code where the operators are defined. A guarantee() is not a compile time error and does not make this intention clear. Kind Regards, Thomas From roland.westrelin at oracle.com Thu Apr 10 08:11:45 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 10 Apr 2014 10:11:45 +0200 Subject: [8u20] RFR(S): 8032011 nsk/stress/jck60/jck60022 crashes in src\share\vm\runtime\synchronizer.cpp:239 In-Reply-To: <5346079A.30804@oracle.com> References: <5346079A.30804@oracle.com> Message-ID: <4715DB96-3584-4620-9838-42639A8E5E5A@oracle.com> Thanks Chris & Vladimir. Roland. On Apr 10, 2014, at 4:53 AM, Vladimir Kozlov wrote: > On 4/9/14 7:49 PM, Christian Thalinger wrote: >> Looks good. > > +1. > > Thanks, > Vladimir > >> >> On Apr 8, 2014, at 9:54 PM, Roland Westrelin wrote: >> >>> Please, review backport to 8u20. The patch applies cleanly. This was pushed to jdk9 more than 1 month ago. >>> >>> http://cr.openjdk.java.net/~roland/8032011/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8032011 >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3df21373e577 >>> >>> Roland. >> From goetz.lindenmaier at sap.com Thu Apr 10 09:06:26 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Apr 2014 09:06:26 +0000 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <5345CF71.8070303@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53447352.9020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAF4B6@DEWDFEMB12A.global.corp.sap> <5345CF71.8070303@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAF94A@DEWDFEMB12A.global.corp.sap> Sure, I'll run a build and tests with it. I can also do this with the webrev he might mail around. Also, you can always see daily test results of builds of a lot of repositories on http://cr.openjdk.java.net/~simonis/ppc-aix-port/ Where we do full builds of: ppc-aix-port/jdk7u weekly jdk8u/jdk8u-dev daily jdk9/dev daily And daily hotspot-only builds of jdk9/hs jdk9/hs-comp jdk9/hs-gc jdk9/hs-rt jdk9/hs-emb jdk8u/hs-dev Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 10. April 2014 00:54 To: Lindenmaier, Goetz; Dmitry Samersoff; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Hi Goetz, You can help :) When Dmitry push the patch into jdk8u/hs-dev can you build and test from it on your platforms (ppc64)? If everything is fine I will do the final merge into ppc-aix-port/stage and we will freeze it. thanks, Vladimir On 4/8/14 11:40 PM, Lindenmaier, Goetz wrote: > Vladimir, Dmitry, > > Thanks for handling this! > Sorry I can't help. > > Best regards, > Goetz > > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Mittwoch, 9. April 2014 00:08 > To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Vladimir, > > OK. Thank you for clarification. > > -Dmitry > > On 2014-04-09 01:43, Vladimir Kozlov wrote: >> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> On 2014-04-09 00:32, Vladimir Kozlov wrote: >>> >>>> Could you tell when you are planning to backport these changes into >>>> 8u20? >>> >>> This week. Do I need any additional approvals? >> >> No need for approval but, please, send new [8u20] RFR to hotspot-dev >> with links to jbs and jdk9 changeset and say that it applies cleanly (if >> it is). I will review it and you can push. >> It is to let people know that you backport it. >> >> Thanks, >> Vladimir >> >>> >>> -Dmitry >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Push done. >>>>> >>>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>>> push it to 8u20 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>>> Thanks Dmitry and Vladimir! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Thank you, Dmitry >>>>>> >>>>>> We need to backport it into 8u20 too. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I can push it to RT next week. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Looks good for me! >>>>>>>> >>>>>>>> +1. >>>>>>>> >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>>> repo? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>>> call to vm_exit_... >>>>>>>>>> So I removed the test and return statement. >>>>>>>>>> I added the other missing FREEs. >>>>>>>>>> >>>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>>> adapt to that scheme. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() >>>>>>>>>> in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>>> >>>>>>>>>> os_aix.cpp: >>>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>>> >>>>>>>>>> os_bsd.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>>> >>>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>>> >>>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>>> char *v_colon = ":"; >>>>>>>>>> >>>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>>> >>>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>>> >>>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>>> >>>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>>> ld_library_path); >>>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>>> ld_library_path */ } >>>>>>>>>> ld_library_path = t; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>>> without extra copying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>>> take it into account at ll. 495 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> os_linux.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please have a look at this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>>> the missing parts in here, below. >>>>>>>>>>> >>>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>>> get along >>>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>>> >>>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>>> readability of the code. >>>>>>>>>>> >>>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> and do a single allocation for them. >>>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>>> >>>>>>>>>>> You can use >>>>>>>>>>> >>>>>>>>>>> MAX( >>>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>>> >>>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>>> >>>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> see my comments inline. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>>> >>>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>>> three >>>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>>> known size. At >>>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>>> which may contain several paths. >>>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>>> two >>>>>>>>>>>> buffers are needed. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>>> it makes >>>>>>>>>>>>> code much more readable. >>>>>>>>>>>> I'll fix this. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>>> >>>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>>> bytes. I >>>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>>> large enough >>>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>>> the >>>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>>> compiler. >>>>>>>>>>>> >>>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>>> spaces >>>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>>> allocated >>>>>>>>>>>> buffer. >>>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>>> >>>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>>> the same comments as above. >>>>>>>>>>>>> >>>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>>> >>>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>>> code >>>>>>>>>>>>> changed >>>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>>> respect >>>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>>> variables. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>>> -1) { >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>>> mtInternal); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>>> os_bsd.cpp >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>>> init_system_properties_values >>>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>>> malloc to >>>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>>> allocation >>>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>>> pointers as >>>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>>> and >>>>>>>>>>>> calls to free(). >>>>>>>>>>>> >>>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>>> removes >>>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>>> local array where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>>> allocated in >>>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>>> Most of these >>>>>>>>>>>> frees were missing. >>>>>>>>>>>> >>>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>>> >>>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>>> fixed, >>>>>>>>>>>> too. >>>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From Tobias.Hartmann at oracle.com Thu Apr 10 09:34:59 2014 From: Tobias.Hartmann at oracle.com (Tobias Hartmann) Date: Thu, 10 Apr 2014 11:34:59 +0200 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray In-Reply-To: References: <534548F0.3010401@oracle.com> <5345931C.8080705@oracle.com> Message-ID: <534665C3.6060401@oracle.com> Vladimir, Vitaly, thanks for the reviews. Please see comments inline. New webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.02/ On 04/09/2014 09:53 PM, Vitaly Davidovich wrote: > > I would add a few asserts: > > 1) verify that position provided to iterator is within valid range > 2) equality operators should verify that both iterators point to same > GA instances > > These are pedantic given how these iterators will be used, but > wouldn't hurt, IMHO. > I added asserts to the constructor and the equality operators. > On Apr 9, 2014 2:37 PM, "Vladimir Kozlov" > wrote: > > Hi Tobias > > Changes looks fine to me. I would only move initial > pre-declaration of 2 new templates after GenericGrowableArray > definition and before GrowableArray template which uses them. > > Thanks, > Vladimir > Done. Thanks, Tobias > > On 4/9/14 6:19 AM, Tobias Hartmann wrote: > > Hi, > > please review the following patch. > > *Problem:* > The implementation of "JDK-8015774: Add support for multiple > code heaps" > needs to manage multiple code heaps in the code cache. They > will be > stored in a GrowableArray data structure. Frequent accesses to > the array > using indices make the code more unreadable and error prone > and result > in code duplication. > Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 > > *Solution:* > To simplify the access to the code heaps, the GrowableArray is > adapted > to support STL-style iterators. Further, custom iterators > allow to only > iterate over elements that satisfy a given predicate. This > helps to > access only specific code heaps. > Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ > > > *Tests:* > JPRT with segmented code cache implementation (to be reviewed) > > Thanks, > > Tobias > From goetz.lindenmaier at sap.com Thu Apr 10 10:12:43 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Apr 2014 10:12:43 +0000 Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53455EEC.3030900@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53455EEC.3030900@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAFA1E@DEWDFEMB12A.global.corp.sap> Hi, I tested the webrev, it works fine on both ppc platforms. Thanks, Goetz. -----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Mittwoch, 9. April 2014 16:54 To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Hi Everybody, I would like to ask the backport of the changes made for the following bug report into JDK 8 (jdk8u20): Changes applies clearly, without modifications. CR: https://bugs.openjdk.java.net/browse/JDK-8038201 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/goetz/JDK-8038201/webrev.8u20/ JDK9 changeset http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/bba041a9a030 -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Tobias.Hartmann at oracle.com Thu Apr 10 12:08:52 2014 From: Tobias.Hartmann at oracle.com (Tobias Hartmann) Date: Thu, 10 Apr 2014 14:08:52 +0200 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray In-Reply-To: <534665C3.6060401@oracle.com> References: <534548F0.3010401@oracle.com> <5345931C.8080705@oracle.com> <534665C3.6060401@oracle.com> Message-ID: <534689D4.5060507@oracle.com> Rickard noticed that it does not make sense to declare the iterators as ResourceObj. They are now declared as StackObj. The updated webrev can be found at: http://cr.openjdk.java.net/~anoll/8039498/webrev.03/ Thanks, Tobias On 04/10/2014 11:34 AM, Tobias Hartmann wrote: > Vladimir, Vitaly, thanks for the reviews. Please see comments inline. > > New webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.02/ > > On 04/09/2014 09:53 PM, Vitaly Davidovich wrote: >> >> I would add a few asserts: >> >> 1) verify that position provided to iterator is within valid range >> 2) equality operators should verify that both iterators point to same >> GA instances >> >> These are pedantic given how these iterators will be used, but >> wouldn't hurt, IMHO. >> > > I added asserts to the constructor and the equality operators. > >> On Apr 9, 2014 2:37 PM, "Vladimir Kozlov" > > wrote: >> >> Hi Tobias >> >> Changes looks fine to me. I would only move initial >> pre-declaration of 2 new templates after GenericGrowableArray >> definition and before GrowableArray template which uses them. >> >> Thanks, >> Vladimir >> > > Done. > > Thanks, > Tobias > >> >> On 4/9/14 6:19 AM, Tobias Hartmann wrote: >> >> Hi, >> >> please review the following patch. >> >> *Problem:* >> The implementation of "JDK-8015774: Add support for multiple >> code heaps" >> needs to manage multiple code heaps in the code cache. They >> will be >> stored in a GrowableArray data structure. Frequent accesses >> to the array >> using indices make the code more unreadable and error prone >> and result >> in code duplication. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 >> >> *Solution:* >> To simplify the access to the code heaps, the GrowableArray >> is adapted >> to support STL-style iterators. Further, custom iterators >> allow to only >> iterate over elements that satisfy a given predicate. This >> helps to >> access only specific code heaps. >> Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ >> >> >> *Tests:* >> JPRT with segmented code cache implementation (to be reviewed) >> >> Thanks, >> >> Tobias >> > From vitalyd at gmail.com Thu Apr 10 12:37:51 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 10 Apr 2014 08:37:51 -0400 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray In-Reply-To: <534689D4.5060507@oracle.com> References: <534548F0.3010401@oracle.com> <5345931C.8080705@oracle.com> <534665C3.6060401@oracle.com> <534689D4.5060507@oracle.com> Message-ID: Hi Tobias, That looks good to me - thanks (not a Reviewer). Vitaly Sent from my phone On Apr 10, 2014 8:09 AM, "Tobias Hartmann" wrote: > Rickard noticed that it does not make sense to declare the iterators as > ResourceObj. They are now declared as StackObj. > > The updated webrev can be found at: http://cr.openjdk.java.net/~ > anoll/8039498/webrev.03/ 7Eanoll/8039498/webrev.03/> > > Thanks, > Tobias > > On 04/10/2014 11:34 AM, Tobias Hartmann wrote: > >> Vladimir, Vitaly, thanks for the reviews. Please see comments inline. >> >> New webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.02/ >> >> On 04/09/2014 09:53 PM, Vitaly Davidovich wrote: >> >>> >>> I would add a few asserts: >>> >>> 1) verify that position provided to iterator is within valid range >>> 2) equality operators should verify that both iterators point to same GA >>> instances >>> >>> These are pedantic given how these iterators will be used, but wouldn't >>> hurt, IMHO. >>> >>> >> I added asserts to the constructor and the equality operators. >> >> On Apr 9, 2014 2:37 PM, "Vladimir Kozlov" >> vladimir.kozlov at oracle.com>> wrote: >>> >>> Hi Tobias >>> >>> Changes looks fine to me. I would only move initial >>> pre-declaration of 2 new templates after GenericGrowableArray >>> definition and before GrowableArray template which uses them. >>> >>> Thanks, >>> Vladimir >>> >>> >> Done. >> >> Thanks, >> Tobias >> >> >>> On 4/9/14 6:19 AM, Tobias Hartmann wrote: >>> >>> Hi, >>> >>> please review the following patch. >>> >>> *Problem:* >>> The implementation of "JDK-8015774: Add support for multiple >>> code heaps" >>> needs to manage multiple code heaps in the code cache. They >>> will be >>> stored in a GrowableArray data structure. Frequent accesses >>> to the array >>> using indices make the code more unreadable and error prone >>> and result >>> in code duplication. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 >>> >>> *Solution:* >>> To simplify the access to the code heaps, the GrowableArray >>> is adapted >>> to support STL-style iterators. Further, custom iterators >>> allow to only >>> iterate over elements that satisfy a given predicate. This >>> helps to >>> access only specific code heaps. >>> Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ >>> >>> >>> *Tests:* >>> JPRT with segmented code cache implementation (to be reviewed) >>> >>> Thanks, >>> >>> Tobias >>> >>> >> > From rickard.backman at oracle.com Thu Apr 10 12:28:43 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Thu, 10 Apr 2014 14:28:43 +0200 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray In-Reply-To: <534689D4.5060507@oracle.com> References: <534548F0.3010401@oracle.com> <5345931C.8080705@oracle.com> <534665C3.6060401@oracle.com> <534689D4.5060507@oracle.com> Message-ID: <20140410122843.GF3029@rbackman> Tobias, just noticed I didn't CC hotspot-dev on the original mail. Sorry about that. Looks good to me, but not a Reviewer. /R On 04/10, Tobias Hartmann wrote: > Rickard noticed that it does not make sense to declare the iterators > as ResourceObj. They are now declared as StackObj. > > The updated webrev can be found at: > http://cr.openjdk.java.net/~anoll/8039498/webrev.03/ > > > Thanks, > Tobias > > On 04/10/2014 11:34 AM, Tobias Hartmann wrote: > >Vladimir, Vitaly, thanks for the reviews. Please see comments inline. > > > >New webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.02/ > > > >On 04/09/2014 09:53 PM, Vitaly Davidovich wrote: > >> > >>I would add a few asserts: > >> > >>1) verify that position provided to iterator is within valid range > >>2) equality operators should verify that both iterators point to > >>same GA instances > >> > >>These are pedantic given how these iterators will be used, but > >>wouldn't hurt, IMHO. > >> > > > >I added asserts to the constructor and the equality operators. > > > >>On Apr 9, 2014 2:37 PM, "Vladimir Kozlov" > >>> > >>wrote: > >> > >> Hi Tobias > >> > >> Changes looks fine to me. I would only move initial > >> pre-declaration of 2 new templates after GenericGrowableArray > >> definition and before GrowableArray template which uses them. > >> > >> Thanks, > >> Vladimir > >> > > > >Done. > > > >Thanks, > >Tobias > > > >> > >> On 4/9/14 6:19 AM, Tobias Hartmann wrote: > >> > >> Hi, > >> > >> please review the following patch. > >> > >> *Problem:* > >> The implementation of "JDK-8015774: Add support for multiple > >> code heaps" > >> needs to manage multiple code heaps in the code cache. They > >> will be > >> stored in a GrowableArray data structure. Frequent accesses > >> to the array > >> using indices make the code more unreadable and error prone > >> and result > >> in code duplication. > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 > >> > >> *Solution:* > >> To simplify the access to the code heaps, the GrowableArray > >> is adapted > >> to support STL-style iterators. Further, custom iterators > >> allow to only > >> iterate over elements that satisfy a given predicate. This > >> helps to > >> access only specific code heaps. > >> Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ > >> > >> > >> *Tests:* > >> JPRT with segmented code cache implementation (to be reviewed) > >> > >> Thanks, > >> > >> Tobias > >> > > > From dmitry.samersoff at oracle.com Thu Apr 10 13:00:33 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Apr 2014 17:00:33 +0400 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53446D8A.5020207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> Message-ID: <534695F1.6060100@oracle.com> Goetz, Vladimir, done. http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/6048424d3865 -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From lois.foltan at oracle.com Thu Apr 10 13:34:03 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 10 Apr 2014 09:34:03 -0400 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: Message-ID: <53469DCB.3010300@oracle.com> Hi Volker, Overall I understand the motivation for this change but have some concerns. make/aix/makefiles/vm.make No comments. make/bsd/makefiles/vm.make No comments, but I do share Vladimir Kozlov's concern that this change to remove the definition of ALLOW_OPERATOR_NEW_USAGE may need to be considered further by the runtime group. src/os/aiz/vm/os_aix.cpp No comments. src/os/aix/vm/porting_aix.cpp No comments. src/share/vm/memory/allocation.cpp I would prefer not to remove the empty "throw()" specifications. For consistency reasons, any user-defined operator new within the JVM should be defined with the empty "throw()" specification in order to ensure that the issues encountered within JDK-8021954 do not resurface. I think this type of consistency is important whether in production or debug mode to avoid confusion. We are still a long way off before adopting the C++11/14 standard. The intent was that in the future, when C++11 is adopted, all "throw()" specifications would be changed to use the "nothrow" keyword. Since JDK-8021954 addressed issues with the clang++ compiler on MacOS, I am curious to know if you completed any testing of the JVM built with clang++? Thanks, Lois On 4/9/2014 12:34 PM, Volker Simonis wrote: > Hi, > > could you please review and sponsor the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8039805/ > https://bugs.openjdk.java.net/browse/JDK-8039805 > > which fixes the signature of the global new/delete operators in allocation.cpp > > For non-product builds allocation.cpp defines global new/delete > operators which shut down the VM if they get called at runtime. The > rational behind this is that the these global operators should never > be used in HotSpot. > > Unfortunately, the signature of some of these operators doesn't > conform to the C++ standard which confuses some C++ compilers. For a > more detailed explanation of the C++ background of this issue see the > new comments in allcoation.cpp and the end of this mail. > > This change also replaces the asserts in the operators with guarantees > because the code may also be active in not-product (aka. 'optimized') > builds. > > Finally, the webrev fixes two places in the AIX-port which used the > global new operator. After the change we can now remove the definition > of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. > > I have also removed ALLOW_OPERATOR_NEW_USAGE from > bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp > which state that on Mac OS X the global new/delete operators from the > HotSpot cause problems together with usages of these operators from > the class library such as the ones from > Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t > observe any such problems but if anybody has some concrete concerns > I'm ready to remove this part from the webrev. > > I've build and tested these changes on Linux/x86_64, Linux/ppc64, > Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially > run the regression tests from sun/security/ec which exercise the > method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which > was mentioned to cause problems in conjunction with the globally > defined new/delete operators from the HotSpot but couldn't see any > issues, neither in the slowdebug nor in the optimized build. > > Following some C++ background regarding the global new/delete operators: > > In C++98/03 the throwing new operators are defined with the following signature: > > void* operator new(std::size_tsize) throw(std::bad_alloc); > void* operator new[](std::size_tsize) throw(std::bad_alloc); > > while all the other (non-throwing) new and delete operators are > defined with an empty throw clause (i.e. "operator delete(void* p) > throw()") which means that they do not throw any exceptions (see > section 18.4 of the C++ standard > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). > > In the new C++11/14 standard > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), > the signature of the throwing new operators was changed by completely > omitting the throw clause (which effectively means they could throw > any exception) while all the other new/delete operators where changed > to have a 'nothrow' clause instead of an empty throw clause. > > Unfortunately, the support for exception specifications among C++ > compilers is still very fragile. While some more strict compilers like > AIX xlC or HP aCC reject to override the default throwing new operator > with a user operator with an empty throw() clause, the MS Visual C++ > compiler warns for every non-empty throw clause like > throw(std::bad_alloc) that it will ignore the exception specification > (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). > > I've therefore changed the operator definitions such that they > correctly work with all currently supported compilers and in way which > should be upwards compatible with C++11/14. > > Please notice that I'm aware of the discussion around "8021954: VM > SIGSEGV during classloading on MacOS; hs_err_pid file produced" > (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) > which introduced empty throw() clauses on all user defined new > operators. But I think the rational used for that change doesn't apply > here, because these global, user user defined new operators changed in > this webrev aren't meant to be really used. There only task is to > override the default, global operators (and therefore they need to > have the right signature) and to shut the VM down if they get called. > > Thank you and best regards, > Volker From goetz.lindenmaier at sap.com Thu Apr 10 14:08:11 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Apr 2014 14:08:11 +0000 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <534695F1.6060100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <534695F1.6060100@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAFB4F@DEWDFEMB12A.global.corp.sap> Thanks for the help! Works fine. Best regards, Goetz -----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Donnerstag, 10. April 2014 15:01 To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Goetz, Vladimir, done. http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/6048424d3865 -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From neugens at redhat.com Thu Apr 10 14:42:29 2014 From: neugens at redhat.com (Mario Torre) Date: Thu, 10 Apr 2014 16:42:29 +0200 Subject: [8u20] RFR (XS): 8036619: Shark: add LLVM 3.4 support In-Reply-To: <5344912A.7060900@oracle.com> References: <1395062146.3881.4.camel@galactica.localdomain> <1396857064.3726.2.camel@galactica.localdomain> <5344912A.7060900@oracle.com> Message-ID: <1397140949.12179.2.camel@galactica.localdomain> On Tue, 2014-04-08 at 18:15 -0600, Alejandro E Murillo wrote: > On 4/7/2014 1:51 AM, Mario Torre wrote: > > On Mon, 2014-03-17 at 14:15 +0100, Mario Torre wrote: > >> Resending with correct webrev and subject :) > >> > >> I would like to ask the backport of the changes made for the following > >> bug report into JDK 8 (jdk8u20): > >> > >> https://bugs.openjdk.java.net/browse/JDK-8036619 > >> > >> The changes apply cleanly without modification: > >> > >> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ > >> > >> The related changes for JDK 9 are here: > >> > >> http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.02/ > >> > >> The discussion here: > >> > >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/012814.html > >> > >> and here: > >> > >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012679.html > >> > >> I can't push myself, so if OK, someone would need to do for me. > >> > >> Cheers, > >> Mario > >> > >> > > ping? > > > > Cheers, > > Mario > > > Hi there, I just pushed this patch: > > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/ > > to jdk8u/hs-dev/hotspot: > http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/81d7a4b28dc5 > > BTW, jcheck complained about a few tabs in > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.03/src/share/vm/shark/sharkMemoryManager.cpp.udiff.html > > next time please run jcheck before sending out a patch to make sure > those are fixed > Thanks, and sorry for the tabs! Cheers, Mario From alejandro.murillo at oracle.com Thu Apr 10 15:42:47 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 10 Apr 2014 09:42:47 -0600 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <53460434.50400@oracle.com> References: <5345E28F.5050108@oracle.com> <53460434.50400@oracle.com> Message-ID: <5346BBF7.9080501@oracle.com> Hi David, thanks for the feedback, see below On 4/9/2014 8:38 PM, David Holmes wrote: > Hi Alejandro, > > Given we have to maintain the JDK version information in two places > (top level repo and hotspot repo) wouldn't it have been simpler to > keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set > the major/minor/build values to match those of the JDK version? The file is still used, just renamed as only jdk info is in there. HOTSPOT_RELEASE_VERSION was also kept, we just don't get the major,minor,micro and build number from it anymore, mainly it is now set very similar to the JDK_RELEASE_VERSION (plus other values), and that format it's not fixed as it used to be for hotspot express. Those values (major,minor,micro and build number) are already defined in the makefiles, so we just pass them to vm_version.cpp, so no more parsing in it. > > That aside, in jdk_version file hotspot copyright should now be 2014 will fix that > > */vm.make: > > This line is way too long. > > ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" > -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" > -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" > -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" > -DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\"" > -DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\"" ok > > Not clear why we suddenly need defines for all the component pieces > either. You could have kept the HS_XXX variables, just adding the > micro part. as mentioned above, the micro part was actually added to HOTSPOT_RELEASE_VERSION, we just don't get those values by parsing it, so we just pass those values to the vm_version.cpp, since they are already defined in the makefiles. The format of the JDK version is not that fixed. Thanks Alejandro > > David > > > On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: >> >> Please review this change to make the hotspot related output produced by >> "java -version" >> match the corresponding JDK output: >> >> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 >> >> Note that we initially wanted to obtain more information from the repo >> being built and add >> it to the hotspot version output, but that will require changes in the >> JPRT, so >> we have decided to split the change in 2 bugs. One to make the version >> match >> (above webrev) and another one, an RFE, to add additional information >> extracted from the repo. >> >> Note that in the current version of vm_version.cpp, there is no error >> checking in product mode, >> I was suggested to make that explicit. >> >> Release Engineering did some testing and I also ran several cases with >> full and just hotspot JPRT builds. >> >> Here is a summary of how the new output compares to the old one: >> >> (1) Release Engineering builds (9-dev): >> >> from jdk9-dev build: >> java version "1.9.0-ea" >> Java(TM) SE Runtime Environment (build >> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) >> Java HotSpot(TM) 64-Bit Server VM (build >> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) >> >> compared with what we currently have >> java version "1.9.0-ea" >> Java(TM) SE Runtime Environment (build >> 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) >> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) >> >> (2) Release Engineering builds (jdk9): >> >> java version "1.9.0-ea" >> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) >> Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) >> >> compared with what we currently have >> java version "1.9.0-ea" >> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) >> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) >> >> (3) JPRT Full builds: >> >> java version "1.9.0-internal" >> # Java(TM) SE Runtime Environment (build >> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) >> # Java HotSpot(TM) Server VM (build >> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode) >> >> >> (4) JPRT hotspot only builds: >> >> java version "1.9.0-ea-fastdebug" >> # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) >> # Java HotSpot(TM) Server VM (build >> 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed >> mode) >> >> >> in this one the built VM is inserted into a promoted build bundle, >> since we do not have the JDK build number info in the hotspot repo, >> we can't match the build number in the JDK portion. >> With the RFE mentioned above, we can extract the build info from the >> repo >> and add it to the hotspot portion. >> >> I want to mention, that this may change once the new JDK version change >> is implemented >> but we don't know when that will be implemented yet, so we need to go >> ahead with this to >> get rid of the old hotspot express output. And most of these changes >> will still have to be done >> anyways >> >> BTW, john Coomes and Dan Daugherty provided feedback in some pieces of >> this webrev, >> but I need full reviews now. >> >> Thanks >> -- Alejandro From vladimir.kozlov at oracle.com Thu Apr 10 16:18:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Apr 2014 09:18:52 -0700 Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAFA1E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53455EEC.3030900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAFA1E@DEWDFEMB12A.global.corp.sap> Message-ID: <5346C46C.2030407@oracle.com> Thank you, Goetz Vladimir On 4/10/14 3:12 AM, Lindenmaier, Goetz wrote: > Hi, > > I tested the webrev, it works fine on both ppc platforms. > > Thanks, > Goetz. > > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Mittwoch, 9. April 2014 16:54 > To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Hi Everybody, > > I would like to ask the backport of the changes made for the following > bug report into JDK 8 (jdk8u20): > > Changes applies clearly, without modifications. > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8038201 > > Webrev: > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/goetz/JDK-8038201/webrev.8u20/ > > JDK9 changeset > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/bba041a9a030 > > -Dmitry > > On 2014-04-09 01:43, Vladimir Kozlov wrote: >> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> On 2014-04-09 00:32, Vladimir Kozlov wrote: >>> >>>> Could you tell when you are planning to backport these changes into >>>> 8u20? >>> >>> This week. Do I need any additional approvals? >> >> No need for approval but, please, send new [8u20] RFR to hotspot-dev >> with links to jbs and jdk9 changeset and say that it applies cleanly (if >> it is). I will review it and you can push. >> It is to let people know that you backport it. >> >> Thanks, >> Vladimir >> >>> >>> -Dmitry >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Push done. >>>>> >>>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>>> push it to 8u20 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>>> Thanks Dmitry and Vladimir! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Thank you, Dmitry >>>>>> >>>>>> We need to backport it into 8u20 too. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I can push it to RT next week. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Looks good for me! >>>>>>>> >>>>>>>> +1. >>>>>>>> >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>>> repo? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>>> call to vm_exit_... >>>>>>>>>> So I removed the test and return statement. >>>>>>>>>> I added the other missing FREEs. >>>>>>>>>> >>>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>>> adapt to that scheme. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() >>>>>>>>>> in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>>> >>>>>>>>>> os_aix.cpp: >>>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>>> >>>>>>>>>> os_bsd.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>>> >>>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>>> >>>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>>> char *v_colon = ":"; >>>>>>>>>> >>>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>>> >>>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>>> >>>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>>> >>>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>>> ld_library_path); >>>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>>> ld_library_path */ } >>>>>>>>>> ld_library_path = t; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>>> without extra copying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>>> take it into account at ll. 495 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> os_linux.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please have a look at this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>>> the missing parts in here, below. >>>>>>>>>>> >>>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>>> get along >>>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>>> >>>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>>> readability of the code. >>>>>>>>>>> >>>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> and do a single allocation for them. >>>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>>> >>>>>>>>>>> You can use >>>>>>>>>>> >>>>>>>>>>> MAX( >>>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>>> >>>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>>> >>>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> see my comments inline. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>>> >>>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>>> three >>>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>>> known size. At >>>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>>> which may contain several paths. >>>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>>> two >>>>>>>>>>>> buffers are needed. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>>> it makes >>>>>>>>>>>>> code much more readable. >>>>>>>>>>>> I'll fix this. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>>> >>>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>>> bytes. I >>>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>>> large enough >>>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>>> the >>>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>>> compiler. >>>>>>>>>>>> >>>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>>> spaces >>>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>>> allocated >>>>>>>>>>>> buffer. >>>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>>> >>>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>>> the same comments as above. >>>>>>>>>>>>> >>>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>>> >>>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>>> code >>>>>>>>>>>>> changed >>>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>>> respect >>>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>>> variables. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>>> -1) { >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>>> mtInternal); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>>> os_bsd.cpp >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>>> init_system_properties_values >>>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>>> malloc to >>>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>>> allocation >>>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>>> pointers as >>>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>>> and >>>>>>>>>>>> calls to free(). >>>>>>>>>>>> >>>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>>> removes >>>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>>> local array where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>>> allocated in >>>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>>> Most of these >>>>>>>>>>>> frees were missing. >>>>>>>>>>>> >>>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>>> >>>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>>> fixed, >>>>>>>>>>>> too. >>>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From vladimir.kozlov at oracle.com Thu Apr 10 16:25:39 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Apr 2014 09:25:39 -0700 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray In-Reply-To: <534689D4.5060507@oracle.com> References: <534548F0.3010401@oracle.com> <5345931C.8080705@oracle.com> <534665C3.6060401@oracle.com> <534689D4.5060507@oracle.com> Message-ID: <5346C603.2050608@oracle.com> Good. Thanks, Vladimir On 4/10/14 5:08 AM, Tobias Hartmann wrote: > Rickard noticed that it does not make sense to declare the iterators as ResourceObj. They are now declared as StackObj. > > The updated webrev can be found at: http://cr.openjdk.java.net/~anoll/8039498/webrev.03/ > > > Thanks, > Tobias > > On 04/10/2014 11:34 AM, Tobias Hartmann wrote: >> Vladimir, Vitaly, thanks for the reviews. Please see comments inline. >> >> New webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.02/ >> >> On 04/09/2014 09:53 PM, Vitaly Davidovich wrote: >>> >>> I would add a few asserts: >>> >>> 1) verify that position provided to iterator is within valid range >>> 2) equality operators should verify that both iterators point to same GA instances >>> >>> These are pedantic given how these iterators will be used, but wouldn't hurt, IMHO. >>> >> >> I added asserts to the constructor and the equality operators. >> >>> On Apr 9, 2014 2:37 PM, "Vladimir Kozlov" > wrote: >>> >>> Hi Tobias >>> >>> Changes looks fine to me. I would only move initial pre-declaration of 2 new templates after GenericGrowableArray >>> definition and before GrowableArray template which uses them. >>> >>> Thanks, >>> Vladimir >>> >> >> Done. >> >> Thanks, >> Tobias >> >>> >>> On 4/9/14 6:19 AM, Tobias Hartmann wrote: >>> >>> Hi, >>> >>> please review the following patch. >>> >>> *Problem:* >>> The implementation of "JDK-8015774: Add support for multiple code heaps" >>> needs to manage multiple code heaps in the code cache. They will be >>> stored in a GrowableArray data structure. Frequent accesses to the array >>> using indices make the code more unreadable and error prone and result >>> in code duplication. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 >>> >>> *Solution:* >>> To simplify the access to the code heaps, the GrowableArray is adapted >>> to support STL-style iterators. Further, custom iterators allow to only >>> iterate over elements that satisfy a given predicate. This helps to >>> access only specific code heaps. >>> Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ >>> >>> >>> *Tests:* >>> JPRT with segmented code cache implementation (to be reviewed) >>> >>> Thanks, >>> >>> Tobias >>> >> > From volker.simonis at gmail.com Thu Apr 10 18:04:54 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Apr 2014 20:04:54 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <53469DCB.3010300@oracle.com> References: <53469DCB.3010300@oracle.com> Message-ID: Hi Lois, thanks for the review. Please find my comments inline: On Thu, Apr 10, 2014 at 3:34 PM, Lois Foltan wrote: > Hi Volker, > > Overall I understand the motivation for this change but have some concerns. > > make/aix/makefiles/vm.make > No comments. > > make/bsd/makefiles/vm.make > No comments, but I do share Vladimir Kozlov's concern that this change to > remove the definition of ALLOW_OPERATOR_NEW_USAGE may need to be considered > further by the runtime group. > > src/os/aiz/vm/os_aix.cpp > No comments. > > src/os/aix/vm/porting_aix.cpp > No comments. > > src/share/vm/memory/allocation.cpp > I would prefer not to remove the empty "throw()" specifications. For But removing the empty "throw()" specifications is actually the only reason for this change! Some compilers simply can not override the global new operators if the user provided operators have a different exception specification. And as I wrote, specifying "throw()" means that the operator won't throw any exception which is actually quite the opposit of the standard new operators which have "throw(std::bad_alloc)" and which means that they can throw "std::bad_alloc". > consistency reasons, any user-defined operator new within the JVM should be > defined with the empty "throw()" specification in order to ensure that the > issues encountered within JDK-8021954 do not resurface. I think this type > of consistency is important whether in production or debug mode to avoid > confusion. There is really no need for consistency here - especially if we only insist on consistency as an end in itself. The two global new allocators which I've changed are there for error checking only. They should never be called and if they are called they will never return because they'll shut down the VM immediately. So there's absolutely no need to do any checks on their return values. > We are still a long way off before adopting the C++11/14 > standard. The intent was that in the future, when C++11 is adopted, all > "throw()" specifications would be changed to use the "nothrow" keyword. > Since JDK-8021954 addressed issues with the clang++ compiler on MacOS, I am > curious to know if you completed any testing of the JVM built with clang++? > I've just build with clang as well and run the jdk regression test suite without any special issues (besides jdk/sun/misc/CopyMemory.java which crashes. But it crashes with the global new operators from allocation.cpp as well as without. And it doesn't crash if compiled with g++, so that seems a different problem) . Do you have any special test in mind which I could run to see the problems you are afraid off? Regards, Volker > Thanks, > Lois > > > > On 4/9/2014 12:34 PM, Volker Simonis wrote: >> >> Hi, >> >> could you please review and sponsor the following small change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8039805/ >> https://bugs.openjdk.java.net/browse/JDK-8039805 >> >> which fixes the signature of the global new/delete operators in >> allocation.cpp >> >> For non-product builds allocation.cpp defines global new/delete >> operators which shut down the VM if they get called at runtime. The >> rational behind this is that the these global operators should never >> be used in HotSpot. >> >> Unfortunately, the signature of some of these operators doesn't >> conform to the C++ standard which confuses some C++ compilers. For a >> more detailed explanation of the C++ background of this issue see the >> new comments in allcoation.cpp and the end of this mail. >> >> This change also replaces the asserts in the operators with guarantees >> because the code may also be active in not-product (aka. 'optimized') >> builds. >> >> Finally, the webrev fixes two places in the AIX-port which used the >> global new operator. After the change we can now remove the definition >> of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. >> >> I have also removed ALLOW_OPERATOR_NEW_USAGE from >> bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp >> which state that on Mac OS X the global new/delete operators from the >> HotSpot cause problems together with usages of these operators from >> the class library such as the ones from >> Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t >> observe any such problems but if anybody has some concrete concerns >> I'm ready to remove this part from the webrev. >> >> I've build and tested these changes on Linux/x86_64, Linux/ppc64, >> Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially >> run the regression tests from sun/security/ec which exercise the >> method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which >> was mentioned to cause problems in conjunction with the globally >> defined new/delete operators from the HotSpot but couldn't see any >> issues, neither in the slowdebug nor in the optimized build. >> >> Following some C++ background regarding the global new/delete operators: >> >> In C++98/03 the throwing new operators are defined with the following >> signature: >> >> void* operator new(std::size_tsize) throw(std::bad_alloc); >> void* operator new[](std::size_tsize) throw(std::bad_alloc); >> >> while all the other (non-throwing) new and delete operators are >> defined with an empty throw clause (i.e. "operator delete(void* p) >> throw()") which means that they do not throw any exceptions (see >> section 18.4 of the C++ standard >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). >> >> In the new C++11/14 standard >> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), >> the signature of the throwing new operators was changed by completely >> omitting the throw clause (which effectively means they could throw >> any exception) while all the other new/delete operators where changed >> to have a 'nothrow' clause instead of an empty throw clause. >> >> Unfortunately, the support for exception specifications among C++ >> compilers is still very fragile. While some more strict compilers like >> AIX xlC or HP aCC reject to override the default throwing new operator >> with a user operator with an empty throw() clause, the MS Visual C++ >> compiler warns for every non-empty throw clause like >> throw(std::bad_alloc) that it will ignore the exception specification >> (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). >> >> I've therefore changed the operator definitions such that they >> correctly work with all currently supported compilers and in way which >> should be upwards compatible with C++11/14. >> >> Please notice that I'm aware of the discussion around "8021954: VM >> SIGSEGV during classloading on MacOS; hs_err_pid file produced" >> >> (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) >> which introduced empty throw() clauses on all user defined new >> operators. But I think the rational used for that change doesn't apply >> here, because these global, user user defined new operators changed in >> this webrev aren't meant to be really used. There only task is to >> override the default, global operators (and therefore they need to >> have the right signature) and to shut the VM down if they get called. >> >> Thank you and best regards, >> Volker > > From christian.thalinger at oracle.com Thu Apr 10 18:16:12 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Apr 2014 08:16:12 -1000 Subject: [9] RFR(S): JDK-8039498: Add iterators to GrowableArray In-Reply-To: <534689D4.5060507@oracle.com> References: <534548F0.3010401@oracle.com> <5345931C.8080705@oracle.com> <534665C3.6060401@oracle.com> <534689D4.5060507@oracle.com> Message-ID: <80AE4208-0B5D-4856-8517-ADB93A1B1011@oracle.com> Looks good. On Apr 10, 2014, at 2:08 AM, Tobias Hartmann wrote: > Rickard noticed that it does not make sense to declare the iterators as ResourceObj. They are now declared as StackObj. > > The updated webrev can be found at:http://cr.openjdk.java.net/~anoll/8039498/webrev.03/ > > Thanks, > Tobias > > On 04/10/2014 11:34 AM, Tobias Hartmann wrote: >> Vladimir, Vitaly, thanks for the reviews. Please see comments inline. >> >> New webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.02/ >> >> On 04/09/2014 09:53 PM, Vitaly Davidovich wrote: >>> >>> I would add a few asserts: >>> >>> 1) verify that position provided to iterator is within valid range >>> 2) equality operators should verify that both iterators point to same GA instances >>> >>> These are pedantic given how these iterators will be used, but wouldn't hurt, IMHO. >>> >> >> I added asserts to the constructor and the equality operators. >> >>> On Apr 9, 2014 2:37 PM, "Vladimir Kozlov" > wrote: >>> >>> Hi Tobias >>> >>> Changes looks fine to me. I would only move initial >>> pre-declaration of 2 new templates after GenericGrowableArray >>> definition and before GrowableArray template which uses them. >>> >>> Thanks, >>> Vladimir >>> >> >> Done. >> >> Thanks, >> Tobias >> >>> >>> On 4/9/14 6:19 AM, Tobias Hartmann wrote: >>> >>> Hi, >>> >>> please review the following patch. >>> >>> *Problem:* >>> The implementation of "JDK-8015774: Add support for multiple >>> code heaps" >>> needs to manage multiple code heaps in the code cache. They >>> will be >>> stored in a GrowableArray data structure. Frequent accesses >>> to the array >>> using indices make the code more unreadable and error prone >>> and result >>> in code duplication. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039498 >>> >>> *Solution:* >>> To simplify the access to the code heaps, the GrowableArray >>> is adapted >>> to support STL-style iterators. Further, custom iterators >>> allow to only >>> iterate over elements that satisfy a given predicate. This >>> helps to >>> access only specific code heaps. >>> Webrev: http://cr.openjdk.java.net/~anoll/8039498/webrev.01/ >>> >>> >>> *Tests:* >>> JPRT with segmented code cache implementation (to be reviewed) >>> >>> Thanks, >>> >>> Tobias From volker.simonis at gmail.com Thu Apr 10 18:33:25 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Apr 2014 20:33:25 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <53460DBA.4010708@oracle.com> References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> Message-ID: Hi David, thanks for looking at this issue. I agree with you and I've completely removed ALLOW_OPERATOR_NEW now: http://cr.openjdk.java.net/~simonis/webrevs/8039805.v2/ I've also changed the "guarantee" into "fatal" as proposed by Vladimir. I've thought a little while about the problem that some other code may unintentionally use these operators but I couldn?t really find a scenario where this could happen. Because as you correctly pointed out, these operators aren't exported from libjvm.so - after all, that's the whole reason for compiling with visibility=hidden and using of export maps. So if another program/library will load libjvm.so, the operators won't be visible. On the other hand, if the libjvm.so loads another shared libraries which use these operators they either have their own, private versions of them or they are dynamically linked against another library (most probably the standard library) which provides versions of the operators. So if I'm not totally wrong, we could in principle also enable these operators in the product build. However, I'm not proposing that for this change. Let's first fix the signatures and get rid of ALLOW_OPERATOR_NEW with this change. If everything works fine, we can think about enabling these global operators in product builds as well. By the way - are you from the runtime group? I was asked to get a review from a runtime-group member - anybody out there willing to volunteer? Thank you and best regards, Volker On Thu, Apr 10, 2014 at 5:19 AM, David Holmes wrote: > I think we should just delete the whole ALLOW_OPERATOR_NEW block. We fixed > the problem of it being called outside the VM under 8014326. > > David > > > On 10/04/2014 12:48 PM, David Holmes wrote: >> >> Hi Volker, >> >> Need more time to consider this in full but from the existing code: >> >> 689 // On certain platforms, such as Mac OS X (Darwin), in debug >> version, new is being called >> 690 // from jdk source and causing data corruption. Such as >> 691 // Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair >> 692 // define ALLOW_OPERATOR_NEW_USAGE for platform on which global >> operator new allowed. >> >> we actually fixed that by using the mapfiles to ensure the hotspot >> operator new was not visible externally. The existence of >> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the time :( >> >> https://bugs.openjdk.java.net/browse/JDK-8014326 >> >> David >> >> On 10/04/2014 2:34 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review and sponsor the following small change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8039805/ >>> https://bugs.openjdk.java.net/browse/JDK-8039805 >>> >>> which fixes the signature of the global new/delete operators in >>> allocation.cpp >>> >>> For non-product builds allocation.cpp defines global new/delete >>> operators which shut down the VM if they get called at runtime. The >>> rational behind this is that the these global operators should never >>> be used in HotSpot. >>> >>> Unfortunately, the signature of some of these operators doesn't >>> conform to the C++ standard which confuses some C++ compilers. For a >>> more detailed explanation of the C++ background of this issue see the >>> new comments in allcoation.cpp and the end of this mail. >>> >>> This change also replaces the asserts in the operators with guarantees >>> because the code may also be active in not-product (aka. 'optimized') >>> builds. >>> >>> Finally, the webrev fixes two places in the AIX-port which used the >>> global new operator. After the change we can now remove the definition >>> of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. >>> >>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >>> bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp >>> which state that on Mac OS X the global new/delete operators from the >>> HotSpot cause problems together with usages of these operators from >>> the class library such as the ones from >>> Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t >>> observe any such problems but if anybody has some concrete concerns >>> I'm ready to remove this part from the webrev. >>> >>> I've build and tested these changes on Linux/x86_64, Linux/ppc64, >>> Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially >>> run the regression tests from sun/security/ec which exercise the >>> method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which >>> was mentioned to cause problems in conjunction with the globally >>> defined new/delete operators from the HotSpot but couldn't see any >>> issues, neither in the slowdebug nor in the optimized build. >>> >>> Following some C++ background regarding the global new/delete operators: >>> >>> In C++98/03 the throwing new operators are defined with the following >>> signature: >>> >>> void* operator new(std::size_tsize) throw(std::bad_alloc); >>> void* operator new[](std::size_tsize) throw(std::bad_alloc); >>> >>> while all the other (non-throwing) new and delete operators are >>> defined with an empty throw clause (i.e. "operator delete(void* p) >>> throw()") which means that they do not throw any exceptions (see >>> section 18.4 of the C++ standard >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). >>> >>> In the new C++11/14 standard >>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), >>> the signature of the throwing new operators was changed by completely >>> omitting the throw clause (which effectively means they could throw >>> any exception) while all the other new/delete operators where changed >>> to have a 'nothrow' clause instead of an empty throw clause. >>> >>> Unfortunately, the support for exception specifications among C++ >>> compilers is still very fragile. While some more strict compilers like >>> AIX xlC or HP aCC reject to override the default throwing new operator >>> with a user operator with an empty throw() clause, the MS Visual C++ >>> compiler warns for every non-empty throw clause like >>> throw(std::bad_alloc) that it will ignore the exception specification >>> (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). >>> >>> I've therefore changed the operator definitions such that they >>> correctly work with all currently supported compilers and in way which >>> should be upwards compatible with C++11/14. >>> >>> Please notice that I'm aware of the discussion around "8021954: VM >>> SIGSEGV during classloading on MacOS; hs_err_pid file produced" >>> >>> (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, >>> >>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) >>> which introduced empty throw() clauses on all user defined new >>> operators. But I think the rational used for that change doesn't apply >>> here, because these global, user user defined new operators changed in >>> this webrev aren't meant to be really used. There only task is to >>> override the default, global operators (and therefore they need to >>> have the right signature) and to shut the VM down if they get called. >>> >>> Thank you and best regards, >>> Volker >>> > From vladimir.kozlov at oracle.com Thu Apr 10 19:13:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Apr 2014 12:13:35 -0700 Subject: [8u20] RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top Message-ID: <5346ED5F.5020002@oracle.com> 8u20 backport request. These changes were pushed into jdk9 3 days ago and nightly testing shows no problems. Changes from jdk9 applied to 8u without conflicts. http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/53471abb7fa0 http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8039146 Thanks, Vladimir From daniel.daugherty at oracle.com Thu Apr 10 19:30:19 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 10 Apr 2014 13:30:19 -0600 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> Message-ID: <5346F14B.90108@oracle.com> > By the way - are you from the runtime group? > I was asked to get a review from a runtime-group member - anybody out > there willing to volunteer? Lois is from the Runtime group so once you two reach agreement, I think you'll be in good shape... Dan On 4/10/14 12:33 PM, Volker Simonis wrote: > Hi David, > > thanks for looking at this issue. > > I agree with you and I've completely removed ALLOW_OPERATOR_NEW now: > > http://cr.openjdk.java.net/~simonis/webrevs/8039805.v2/ > > I've also changed the "guarantee" into "fatal" as proposed by Vladimir. > > I've thought a little while about the problem that some other code may > unintentionally use these operators but I couldn?t really find a > scenario where this could happen. Because as you correctly pointed > out, these operators aren't exported from libjvm.so - after all, > that's the whole reason for compiling with visibility=hidden and using > of export maps. So if another program/library will load libjvm.so, the > operators won't be visible. On the other hand, if the libjvm.so loads > another shared libraries which use these operators they either have > their own, private versions of them or they are dynamically linked > against another library (most probably the standard library) which > provides versions of the operators. > > So if I'm not totally wrong, we could in principle also enable these > operators in the product build. However, I'm not proposing that for > this change. Let's first fix the signatures and get rid of > ALLOW_OPERATOR_NEW with this change. If everything works fine, we can > think about enabling these global operators in product builds as well. > > By the way - are you from the runtime group? > I was asked to get a review from a runtime-group member - anybody out > there willing to volunteer? > > Thank you and best regards, > Volker > > > On Thu, Apr 10, 2014 at 5:19 AM, David Holmes wrote: >> I think we should just delete the whole ALLOW_OPERATOR_NEW block. We fixed >> the problem of it being called outside the VM under 8014326. >> >> David >> >> >> On 10/04/2014 12:48 PM, David Holmes wrote: >>> Hi Volker, >>> >>> Need more time to consider this in full but from the existing code: >>> >>> 689 // On certain platforms, such as Mac OS X (Darwin), in debug >>> version, new is being called >>> 690 // from jdk source and causing data corruption. Such as >>> 691 // Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair >>> 692 // define ALLOW_OPERATOR_NEW_USAGE for platform on which global >>> operator new allowed. >>> >>> we actually fixed that by using the mapfiles to ensure the hotspot >>> operator new was not visible externally. The existence of >>> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the time :( >>> >>> https://bugs.openjdk.java.net/browse/JDK-8014326 >>> >>> David >>> >>> On 10/04/2014 2:34 AM, Volker Simonis wrote: >>>> Hi, >>>> >>>> could you please review and sponsor the following small change: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8039805/ >>>> https://bugs.openjdk.java.net/browse/JDK-8039805 >>>> >>>> which fixes the signature of the global new/delete operators in >>>> allocation.cpp >>>> >>>> For non-product builds allocation.cpp defines global new/delete >>>> operators which shut down the VM if they get called at runtime. The >>>> rational behind this is that the these global operators should never >>>> be used in HotSpot. >>>> >>>> Unfortunately, the signature of some of these operators doesn't >>>> conform to the C++ standard which confuses some C++ compilers. For a >>>> more detailed explanation of the C++ background of this issue see the >>>> new comments in allcoation.cpp and the end of this mail. >>>> >>>> This change also replaces the asserts in the operators with guarantees >>>> because the code may also be active in not-product (aka. 'optimized') >>>> builds. >>>> >>>> Finally, the webrev fixes two places in the AIX-port which used the >>>> global new operator. After the change we can now remove the definition >>>> of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. >>>> >>>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >>>> bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp >>>> which state that on Mac OS X the global new/delete operators from the >>>> HotSpot cause problems together with usages of these operators from >>>> the class library such as the ones from >>>> Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t >>>> observe any such problems but if anybody has some concrete concerns >>>> I'm ready to remove this part from the webrev. >>>> >>>> I've build and tested these changes on Linux/x86_64, Linux/ppc64, >>>> Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially >>>> run the regression tests from sun/security/ec which exercise the >>>> method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which >>>> was mentioned to cause problems in conjunction with the globally >>>> defined new/delete operators from the HotSpot but couldn't see any >>>> issues, neither in the slowdebug nor in the optimized build. >>>> >>>> Following some C++ background regarding the global new/delete operators: >>>> >>>> In C++98/03 the throwing new operators are defined with the following >>>> signature: >>>> >>>> void* operator new(std::size_tsize) throw(std::bad_alloc); >>>> void* operator new[](std::size_tsize) throw(std::bad_alloc); >>>> >>>> while all the other (non-throwing) new and delete operators are >>>> defined with an empty throw clause (i.e. "operator delete(void* p) >>>> throw()") which means that they do not throw any exceptions (see >>>> section 18.4 of the C++ standard >>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). >>>> >>>> In the new C++11/14 standard >>>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), >>>> the signature of the throwing new operators was changed by completely >>>> omitting the throw clause (which effectively means they could throw >>>> any exception) while all the other new/delete operators where changed >>>> to have a 'nothrow' clause instead of an empty throw clause. >>>> >>>> Unfortunately, the support for exception specifications among C++ >>>> compilers is still very fragile. While some more strict compilers like >>>> AIX xlC or HP aCC reject to override the default throwing new operator >>>> with a user operator with an empty throw() clause, the MS Visual C++ >>>> compiler warns for every non-empty throw clause like >>>> throw(std::bad_alloc) that it will ignore the exception specification >>>> (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). >>>> >>>> I've therefore changed the operator definitions such that they >>>> correctly work with all currently supported compilers and in way which >>>> should be upwards compatible with C++11/14. >>>> >>>> Please notice that I'm aware of the discussion around "8021954: VM >>>> SIGSEGV during classloading on MacOS; hs_err_pid file produced" >>>> >>>> (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) >>>> which introduced empty throw() clauses on all user defined new >>>> operators. But I think the rational used for that change doesn't apply >>>> here, because these global, user user defined new operators changed in >>>> this webrev aren't meant to be really used. There only task is to >>>> override the default, global operators (and therefore they need to >>>> have the right signature) and to shut the VM down if they get called. >>>> >>>> Thank you and best regards, >>>> Volker >>>> From coleen.phillimore at oracle.com Thu Apr 10 20:00:50 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Apr 2014 16:00:50 -0400 Subject: [8u20] RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top In-Reply-To: <5346ED5F.5020002@oracle.com> References: <5346ED5F.5020002@oracle.com> Message-ID: <5346F872.10107@oracle.com> This is fine. Coleen On 4/10/14, 3:13 PM, Vladimir Kozlov wrote: > 8u20 backport request. These changes were pushed into jdk9 3 days ago > and nightly testing shows no problems. > > Changes from jdk9 applied to 8u without conflicts. > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/53471abb7fa0 > http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8039146 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Apr 10 20:23:55 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Apr 2014 13:23:55 -0700 Subject: [8u20] RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top In-Reply-To: <5346F872.10107@oracle.com> References: <5346ED5F.5020002@oracle.com> <5346F872.10107@oracle.com> Message-ID: <5346FDDB.6060606@oracle.com> Thank you, Coleen Vladimir On 4/10/14 1:00 PM, Coleen Phillimore wrote: > > This is fine. > Coleen > > On 4/10/14, 3:13 PM, Vladimir Kozlov wrote: >> 8u20 backport request. These changes were pushed into jdk9 3 days ago >> and nightly testing shows no problems. >> >> Changes from jdk9 applied to 8u without conflicts. >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/53471abb7fa0 >> http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8039146 >> >> Thanks, >> Vladimir > From leventov at ya.ru Thu Apr 10 20:38:42 2014 From: leventov at ya.ru (Roman Leventov) Date: Fri, 11 Apr 2014 00:38:42 +0400 Subject: Java 8 Integer and Long unsigned methods - are there plans to add intrinsics for them? Message-ID: <812701397162322@web11m.yandex.ru> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/vmSymbols.hpp -- there aren't currently. From lois.foltan at oracle.com Thu Apr 10 22:05:16 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 10 Apr 2014 18:05:16 -0400 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: <53469DCB.3010300@oracle.com> Message-ID: <5347159C.2080606@oracle.com> On 4/10/2014 2:04 PM, Volker Simonis wrote: > Hi Lois, > > thanks for the review. Please find my comments inline: Hi Volker, My comments are inlined below as well. > > On Thu, Apr 10, 2014 at 3:34 PM, Lois Foltan wrote: >> Hi Volker, >> >> Overall I understand the motivation for this change but have some concerns. >> >> make/aix/makefiles/vm.make >> No comments. >> >> make/bsd/makefiles/vm.make >> No comments, but I do share Vladimir Kozlov's concern that this change to >> remove the definition of ALLOW_OPERATOR_NEW_USAGE may need to be considered >> further by the runtime group. >> >> src/os/aiz/vm/os_aix.cpp >> No comments. >> >> src/os/aix/vm/porting_aix.cpp >> No comments. >> >> src/share/vm/memory/allocation.cpp >> I would prefer not to remove the empty "throw()" specifications. For > But removing the empty "throw()" specifications is actually the only > reason for this change! Understood. > > Some compilers simply can not override the global new operators if the > user provided operators have a different exception specification. And > as I wrote, specifying "throw()" means that the operator won't throw > any exception which is actually quite the opposit of the standard new > operators which have "throw(std::bad_alloc)" and which means that they > can throw "std::bad_alloc". This is unfortunate for two reasons, the JVM really doesn't want any new operators whether user or globally defined to throw exceptions and secondly most compilers (g++, clang, Solaris C++, Visual C++) can override the global new operators. >> consistency reasons, any user-defined operator new within the JVM should be >> defined with the empty "throw()" specification in order to ensure that the >> issues encountered within JDK-8021954 do not resurface. I think this type >> of consistency is important whether in production or debug mode to avoid >> confusion. > There is really no need for consistency here - especially if we only > insist on consistency as an end in itself. > > The two global new allocators which I've changed are there for error > checking only. They should never be called and if they are called they > will never return because they'll shut down the VM immediately. So > there's absolutely no need to do any checks on their return values. Again, I understand and since you are correct that this is a situation where these definitions of global new operators should never be called, I am okay with you going ahead with the change. I would just like to go on record as stating that I think consistency is good in this case because the issue within JDK-8021954 was actually quite subtle. Without indicating to the clang compiler that a user defined operator new would not throw an exception, needed internally generated C++ constructor prolog code that the JVM relies on, was not being generated by default. > >> We are still a long way off before adopting the C++11/14 >> standard. The intent was that in the future, when C++11 is adopted, all >> "throw()" specifications would be changed to use the "nothrow" keyword. >> Since JDK-8021954 addressed issues with the clang++ compiler on MacOS, I am >> curious to know if you completed any testing of the JVM built with clang++? >> > I've just build with clang as well and run the jdk regression test > suite without any special issues (besides jdk/sun/misc/CopyMemory.java > which crashes. But it crashes with the global new operators from > allocation.cpp as well as without. And it doesn't crash if compiled > with g++, so that seems a different problem) . > > Do you have any special test in mind which I could run to see the > problems you are afraid off? Thank you for completing this testing. I think the original test cases in JDK-8021954 and JDK-8022140 were in the hotspot/test/runtime area as well, so it would be good to run those tests. The issue with jdk/sun/misc/CopyMemory.java does concern me but I agree this seems to be a separate issue. There was a MacOS clang C++ compiler optimization issue, see JDK-8022407 , that was fixed in JDK 8. What version of Xcode are you compiling with? One final comment, since you are modifying make files I think you also should sent the RFR to the build-dev at openjdk.java.net distro as well. Thanks, Lois > > Regards, > Volker > >> Thanks, >> Lois >> >> >> >> On 4/9/2014 12:34 PM, Volker Simonis wrote: >>> Hi, >>> >>> could you please review and sponsor the following small change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8039805/ >>> https://bugs.openjdk.java.net/browse/JDK-8039805 >>> >>> which fixes the signature of the global new/delete operators in >>> allocation.cpp >>> >>> For non-product builds allocation.cpp defines global new/delete >>> operators which shut down the VM if they get called at runtime. The >>> rational behind this is that the these global operators should never >>> be used in HotSpot. >>> >>> Unfortunately, the signature of some of these operators doesn't >>> conform to the C++ standard which confuses some C++ compilers. For a >>> more detailed explanation of the C++ background of this issue see the >>> new comments in allcoation.cpp and the end of this mail. >>> >>> This change also replaces the asserts in the operators with guarantees >>> because the code may also be active in not-product (aka. 'optimized') >>> builds. >>> >>> Finally, the webrev fixes two places in the AIX-port which used the >>> global new operator. After the change we can now remove the definition >>> of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. >>> >>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >>> bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp >>> which state that on Mac OS X the global new/delete operators from the >>> HotSpot cause problems together with usages of these operators from >>> the class library such as the ones from >>> Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t >>> observe any such problems but if anybody has some concrete concerns >>> I'm ready to remove this part from the webrev. >>> >>> I've build and tested these changes on Linux/x86_64, Linux/ppc64, >>> Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially >>> run the regression tests from sun/security/ec which exercise the >>> method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which >>> was mentioned to cause problems in conjunction with the globally >>> defined new/delete operators from the HotSpot but couldn't see any >>> issues, neither in the slowdebug nor in the optimized build. >>> >>> Following some C++ background regarding the global new/delete operators: >>> >>> In C++98/03 the throwing new operators are defined with the following >>> signature: >>> >>> void* operator new(std::size_tsize) throw(std::bad_alloc); >>> void* operator new[](std::size_tsize) throw(std::bad_alloc); >>> >>> while all the other (non-throwing) new and delete operators are >>> defined with an empty throw clause (i.e. "operator delete(void* p) >>> throw()") which means that they do not throw any exceptions (see >>> section 18.4 of the C++ standard >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). >>> >>> In the new C++11/14 standard >>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), >>> the signature of the throwing new operators was changed by completely >>> omitting the throw clause (which effectively means they could throw >>> any exception) while all the other new/delete operators where changed >>> to have a 'nothrow' clause instead of an empty throw clause. >>> >>> Unfortunately, the support for exception specifications among C++ >>> compilers is still very fragile. While some more strict compilers like >>> AIX xlC or HP aCC reject to override the default throwing new operator >>> with a user operator with an empty throw() clause, the MS Visual C++ >>> compiler warns for every non-empty throw clause like >>> throw(std::bad_alloc) that it will ignore the exception specification >>> (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). >>> >>> I've therefore changed the operator definitions such that they >>> correctly work with all currently supported compilers and in way which >>> should be upwards compatible with C++11/14. >>> >>> Please notice that I'm aware of the discussion around "8021954: VM >>> SIGSEGV during classloading on MacOS; hs_err_pid file produced" >>> >>> (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, >>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) >>> which introduced empty throw() clauses on all user defined new >>> operators. But I think the rational used for that change doesn't apply >>> here, because these global, user user defined new operators changed in >>> this webrev aren't meant to be really used. There only task is to >>> override the default, global operators (and therefore they need to >>> have the right signature) and to shut the VM down if they get called. >>> >>> Thank you and best regards, >>> Volker >> From christian.thalinger at oracle.com Thu Apr 10 22:51:27 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Apr 2014 12:51:27 -1000 Subject: Java 8 Integer and Long unsigned methods - are there plans to add intrinsics for them? In-Reply-To: <812701397162322@web11m.yandex.ru> References: <812701397162322@web11m.yandex.ru> Message-ID: [BCC?ing hotspot-dev.] On Apr 10, 2014, at 10:38 AM, Roman Leventov wrote: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/vmSymbols.hpp -- there aren't currently. A little more context would have been nice but I guess you?re talking about compareUnsigned, toUnsignedLong, divideUnsigned, remainderUnsigned. I don?t think there is an enhancement filed to intrinsify these. Do you see a performance problem with these methods? From david.holmes at oracle.com Fri Apr 11 01:58:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Apr 2014 11:58:35 +1000 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> Message-ID: <53474C4B.9000006@oracle.com> On 11/04/2014 4:33 AM, Volker Simonis wrote: > Hi David, > > thanks for looking at this issue. > > I agree with you and I've completely removed ALLOW_OPERATOR_NEW now: > > http://cr.openjdk.java.net/~simonis/webrevs/8039805.v2/ I actually meant delete the whole block guarded by ALLOW_OPERATOR_NEW - we don't need these error-trapping definitions now we have fixed the export problem. FYI I'm not in the runtime group. David ----- > I've also changed the "guarantee" into "fatal" as proposed by Vladimir. > > I've thought a little while about the problem that some other code may > unintentionally use these operators but I couldn?t really find a > scenario where this could happen. Because as you correctly pointed > out, these operators aren't exported from libjvm.so - after all, > that's the whole reason for compiling with visibility=hidden and using > of export maps. So if another program/library will load libjvm.so, the > operators won't be visible. On the other hand, if the libjvm.so loads > another shared libraries which use these operators they either have > their own, private versions of them or they are dynamically linked > against another library (most probably the standard library) which > provides versions of the operators. > > So if I'm not totally wrong, we could in principle also enable these > operators in the product build. However, I'm not proposing that for > this change. Let's first fix the signatures and get rid of > ALLOW_OPERATOR_NEW with this change. If everything works fine, we can > think about enabling these global operators in product builds as well. > > By the way - are you from the runtime group? > I was asked to get a review from a runtime-group member - anybody out > there willing to volunteer? > > Thank you and best regards, > Volker > > > On Thu, Apr 10, 2014 at 5:19 AM, David Holmes wrote: >> I think we should just delete the whole ALLOW_OPERATOR_NEW block. We fixed >> the problem of it being called outside the VM under 8014326. >> >> David >> >> >> On 10/04/2014 12:48 PM, David Holmes wrote: >>> >>> Hi Volker, >>> >>> Need more time to consider this in full but from the existing code: >>> >>> 689 // On certain platforms, such as Mac OS X (Darwin), in debug >>> version, new is being called >>> 690 // from jdk source and causing data corruption. Such as >>> 691 // Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair >>> 692 // define ALLOW_OPERATOR_NEW_USAGE for platform on which global >>> operator new allowed. >>> >>> we actually fixed that by using the mapfiles to ensure the hotspot >>> operator new was not visible externally. The existence of >>> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the time :( >>> >>> https://bugs.openjdk.java.net/browse/JDK-8014326 >>> >>> David >>> >>> On 10/04/2014 2:34 AM, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> could you please review and sponsor the following small change: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8039805/ >>>> https://bugs.openjdk.java.net/browse/JDK-8039805 >>>> >>>> which fixes the signature of the global new/delete operators in >>>> allocation.cpp >>>> >>>> For non-product builds allocation.cpp defines global new/delete >>>> operators which shut down the VM if they get called at runtime. The >>>> rational behind this is that the these global operators should never >>>> be used in HotSpot. >>>> >>>> Unfortunately, the signature of some of these operators doesn't >>>> conform to the C++ standard which confuses some C++ compilers. For a >>>> more detailed explanation of the C++ background of this issue see the >>>> new comments in allcoation.cpp and the end of this mail. >>>> >>>> This change also replaces the asserts in the operators with guarantees >>>> because the code may also be active in not-product (aka. 'optimized') >>>> builds. >>>> >>>> Finally, the webrev fixes two places in the AIX-port which used the >>>> global new operator. After the change we can now remove the definition >>>> of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. >>>> >>>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >>>> bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp >>>> which state that on Mac OS X the global new/delete operators from the >>>> HotSpot cause problems together with usages of these operators from >>>> the class library such as the ones from >>>> Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t >>>> observe any such problems but if anybody has some concrete concerns >>>> I'm ready to remove this part from the webrev. >>>> >>>> I've build and tested these changes on Linux/x86_64, Linux/ppc64, >>>> Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially >>>> run the regression tests from sun/security/ec which exercise the >>>> method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which >>>> was mentioned to cause problems in conjunction with the globally >>>> defined new/delete operators from the HotSpot but couldn't see any >>>> issues, neither in the slowdebug nor in the optimized build. >>>> >>>> Following some C++ background regarding the global new/delete operators: >>>> >>>> In C++98/03 the throwing new operators are defined with the following >>>> signature: >>>> >>>> void* operator new(std::size_tsize) throw(std::bad_alloc); >>>> void* operator new[](std::size_tsize) throw(std::bad_alloc); >>>> >>>> while all the other (non-throwing) new and delete operators are >>>> defined with an empty throw clause (i.e. "operator delete(void* p) >>>> throw()") which means that they do not throw any exceptions (see >>>> section 18.4 of the C++ standard >>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). >>>> >>>> In the new C++11/14 standard >>>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), >>>> the signature of the throwing new operators was changed by completely >>>> omitting the throw clause (which effectively means they could throw >>>> any exception) while all the other new/delete operators where changed >>>> to have a 'nothrow' clause instead of an empty throw clause. >>>> >>>> Unfortunately, the support for exception specifications among C++ >>>> compilers is still very fragile. While some more strict compilers like >>>> AIX xlC or HP aCC reject to override the default throwing new operator >>>> with a user operator with an empty throw() clause, the MS Visual C++ >>>> compiler warns for every non-empty throw clause like >>>> throw(std::bad_alloc) that it will ignore the exception specification >>>> (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). >>>> >>>> I've therefore changed the operator definitions such that they >>>> correctly work with all currently supported compilers and in way which >>>> should be upwards compatible with C++11/14. >>>> >>>> Please notice that I'm aware of the discussion around "8021954: VM >>>> SIGSEGV during classloading on MacOS; hs_err_pid file produced" >>>> >>>> (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924, >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) >>>> which introduced empty throw() clauses on all user defined new >>>> operators. But I think the rational used for that change doesn't apply >>>> here, because these global, user user defined new operators changed in >>>> this webrev aren't meant to be really used. There only task is to >>>> override the default, global operators (and therefore they need to >>>> have the right signature) and to shut the VM down if they get called. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >> From david.holmes at oracle.com Fri Apr 11 02:11:15 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Apr 2014 12:11:15 +1000 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <5346BBF7.9080501@oracle.com> References: <5345E28F.5050108@oracle.com> <53460434.50400@oracle.com> <5346BBF7.9080501@oracle.com> Message-ID: <53474F43.4060706@oracle.com> On 11/04/2014 1:42 AM, Alejandro E Murillo wrote: > Hi David, thanks for the feedback, see below > On 4/9/2014 8:38 PM, David Holmes wrote: >> Hi Alejandro, >> >> Given we have to maintain the JDK version information in two places >> (top level repo and hotspot repo) wouldn't it have been simpler to >> keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set >> the major/minor/build values to match those of the JDK version? > The file is still used, just renamed as only jdk info is in there. > HOTSPOT_RELEASE_VERSION was also kept, we just don't get the > major,minor,micro and build number > from it anymore, mainly it is now set very similar to the > JDK_RELEASE_VERSION (plus other values), > and that format it's not fixed as it used to be for hotspot express. > Those values (major,minor,micro and build number) > are already defined in the makefiles, so we just pass them to > vm_version.cpp, so no more parsing in it. I still think the overall changes could have been much smaller but okay. Thanks, David ----- >> >> That aside, in jdk_version file hotspot copyright should now be 2014 > will fix that >> >> */vm.make: >> >> This line is way too long. >> >> ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" >> -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" >> -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" >> -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" >> -DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\"" >> -DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\"" > ok >> >> Not clear why we suddenly need defines for all the component pieces >> either. You could have kept the HS_XXX variables, just adding the >> micro part. > as mentioned above, the micro part was actually added to > HOTSPOT_RELEASE_VERSION, > we just don't get those values by parsing it, so we just pass those > values to the vm_version.cpp, > since they are already defined in the makefiles. The format of the JDK > version is not that fixed. > > Thanks > Alejandro >> >> David >> >> >> On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: >>> >>> Please review this change to make the hotspot related output produced by >>> "java -version" >>> match the corresponding JDK output: >>> >>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 >>> >>> Note that we initially wanted to obtain more information from the repo >>> being built and add >>> it to the hotspot version output, but that will require changes in the >>> JPRT, so >>> we have decided to split the change in 2 bugs. One to make the version >>> match >>> (above webrev) and another one, an RFE, to add additional information >>> extracted from the repo. >>> >>> Note that in the current version of vm_version.cpp, there is no error >>> checking in product mode, >>> I was suggested to make that explicit. >>> >>> Release Engineering did some testing and I also ran several cases with >>> full and just hotspot JPRT builds. >>> >>> Here is a summary of how the new output compares to the old one: >>> >>> (1) Release Engineering builds (9-dev): >>> >>> from jdk9-dev build: >>> java version "1.9.0-ea" >>> Java(TM) SE Runtime Environment (build >>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) >>> Java HotSpot(TM) 64-Bit Server VM (build >>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) >>> >>> compared with what we currently have >>> java version "1.9.0-ea" >>> Java(TM) SE Runtime Environment (build >>> 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) >>> >>> (2) Release Engineering builds (jdk9): >>> >>> java version "1.9.0-ea" >>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) >>> Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) >>> >>> compared with what we currently have >>> java version "1.9.0-ea" >>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) >>> >>> (3) JPRT Full builds: >>> >>> java version "1.9.0-internal" >>> # Java(TM) SE Runtime Environment (build >>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) >>> # Java HotSpot(TM) Server VM (build >>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode) >>> >>> >>> (4) JPRT hotspot only builds: >>> >>> java version "1.9.0-ea-fastdebug" >>> # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) >>> # Java HotSpot(TM) Server VM (build >>> 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed >>> mode) >>> >>> >>> in this one the built VM is inserted into a promoted build bundle, >>> since we do not have the JDK build number info in the hotspot repo, >>> we can't match the build number in the JDK portion. >>> With the RFE mentioned above, we can extract the build info from the >>> repo >>> and add it to the hotspot portion. >>> >>> I want to mention, that this may change once the new JDK version change >>> is implemented >>> but we don't know when that will be implemented yet, so we need to go >>> ahead with this to >>> get rid of the old hotspot express output. And most of these changes >>> will still have to be done >>> anyways >>> >>> BTW, john Coomes and Dan Daugherty provided feedback in some pieces of >>> this webrev, >>> but I need full reviews now. >>> >>> Thanks >>> > From goetz.lindenmaier at sap.com Fri Apr 11 06:40:09 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 11 Apr 2014 06:40:09 +0000 Subject: [8u20] RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top In-Reply-To: <5346FDDB.6060606@oracle.com> References: <5346ED5F.5020002@oracle.com> <5346F872.10107@oracle.com> <5346FDDB.6060606@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAFE61@DEWDFEMB12A.global.corp.sap> Vladimir, Coleen, thanks for pushing this down! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Donnerstag, 10. April 2014 22:24 To: hotspot-dev at openjdk.java.net Subject: Re: [8u20] RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top Thank you, Coleen Vladimir On 4/10/14 1:00 PM, Coleen Phillimore wrote: > > This is fine. > Coleen > > On 4/10/14, 3:13 PM, Vladimir Kozlov wrote: >> 8u20 backport request. These changes were pushed into jdk9 3 days ago >> and nightly testing shows no problems. >> >> Changes from jdk9 applied to 8u without conflicts. >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/53471abb7fa0 >> http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8039146 >> >> Thanks, >> Vladimir > From volker.simonis at gmail.com Fri Apr 11 10:30:03 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Apr 2014 12:30:03 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <5347159C.2080606@oracle.com> References: <53469DCB.3010300@oracle.com> <5347159C.2080606@oracle.com> Message-ID: Hi Lois, sorry, the last webrev accidentally contained some additional, unrelated makefile changes which fix another problem. Here's the clean version: http://cr.openjdk.java.net/~simonis/webrevs/8039805.v3/ On Fri, Apr 11, 2014 at 12:05 AM, Lois Foltan wrote: > > On 4/10/2014 2:04 PM, Volker Simonis wrote: > > Hi Lois, > > thanks for the review. Please find my comments inline: > > Hi Volker, > My comments are inlined below as well. > > > On Thu, Apr 10, 2014 at 3:34 PM, Lois Foltan wrote: > > Hi Volker, > > Overall I understand the motivation for this change but have some concerns. > > make/aix/makefiles/vm.make > No comments. > > make/bsd/makefiles/vm.make > No comments, but I do share Vladimir Kozlov's concern that this change to > remove the definition of ALLOW_OPERATOR_NEW_USAGE may need to be considered > further by the runtime group. > > src/os/aiz/vm/os_aix.cpp > No comments. > > src/os/aix/vm/porting_aix.cpp > No comments. > > src/share/vm/memory/allocation.cpp > I would prefer not to remove the empty "throw()" specifications. For > > But removing the empty "throw()" specifications is actually the only > reason for this change! > > Understood. > > > Some compilers simply can not override the global new operators if the > user provided operators have a different exception specification. And > as I wrote, specifying "throw()" means that the operator won't throw > any exception which is actually quite the opposit of the standard new > operators which have "throw(std::bad_alloc)" and which means that they > can throw "std::bad_alloc". > > This is unfortunate for two reasons, the JVM really doesn't want any new > operators whether user or globally defined to throw exceptions and secondly > most compilers (g++, clang, Solaris C++, Visual C++) can override the > global new operators. > > consistency reasons, any user-defined operator new within the JVM should be > defined with the empty "throw()" specification in order to ensure that the > issues encountered within JDK-8021954 do not resurface. I think this type > of consistency is important whether in production or debug mode to avoid > confusion. > > There is really no need for consistency here - especially if we only > insist on consistency as an end in itself. > > The two global new allocators which I've changed are there for error > checking only. They should never be called and if they are called they > will never return because they'll shut down the VM immediately. So > there's absolutely no need to do any checks on their return values. > > > Again, I understand and since you are correct that this is a situation > where these definitions of global new operators should never be called, I > am okay with you going ahead with the change. I would just like to go on > record as stating that I think consistency is good in this case because the > issue within JDK-8021954 was actually quite subtle. Without indicating to > the clang compiler that a user defined operator new would not throw an > exception, needed internally generated C++ constructor prolog code that the > JVM relies on, was not being generated by default. > > > We are still a long way off before adopting the C++11/14 > standard. The intent was that in the future, when C++11 is adopted, all > "throw()" specifications would be changed to use the "nothrow" keyword. > Since JDK-8021954 addressed issues with the clang++ compiler on MacOS, I am > curious to know if you completed any testing of the JVM built with clang++? > > > I've just build with clang as well and run the jdk regression test > suite without any special issues (besides jdk/sun/misc/CopyMemory.java > which crashes. But it crashes with the global new operators from > allocation.cpp as well as without. And it doesn't crash if compiled > with g++, so that seems a different problem) . > > Do you have any special test in mind which I could run to see the > problems you are afraid off? > > Thank you for completing this testing. I think the original test cases > in JDK-8021954 and JDK-8022140 were in the hotspot/test/runtime area as > well, so it would be good to run those tests. > Done. The hotspot/test/runtime tests run without any regressions compared to the original version (they revealed that -XX:+UseMallocOnly is currently not working for HS 'optimized' builds but that's again another problem). > The issue with jdk/sun/misc/CopyMemory.java does concern me but I agree > this seems to be a separate issue. There was a MacOS clang C++ compiler > optimization issue, see JDK-8022407, > that was fixed in JDK 8. What version of Xcode are you compiling with? > > You're right, this is indeed JDK-8022407. It seems I'm using an older compiler (I'm actually not very familiar with MacOS X - just have ssh access to a server box). $ xcodebuild -version Xcode 4.4.1 Build version 4F1003 $ clang++ --version Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix Which is not covered by your patch. If I extend it to also cover clang 4.0, the test succeeds. I'll let it up to you if you want to include this small change (it is currently not in the webrev) but I personally think it would be a good idea. Considering the fact that it happens with Xcode 4.4.1 and Xcode 4.6.2, but not with Xcode 4.5.2 may also justify to unconditionally compile unsafe.cpp with -O1 only. diff -r a694dbf1c497 make/bsd/makefiles/gcc.make --- a/make/bsd/makefiles/gcc.make Wed Apr 09 17:39:43 2014 +0200 +++ b/make/bsd/makefiles/gcc.make Fri Apr 11 12:23:08 2014 +0200 @@ -313,7 +313,7 @@ # Work around some compiler bugs. ifeq ($(USE_CLANG), true) - ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 2), 1) + ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 2 \| $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 0), 1) OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) OPT_CFLAGS/unsafe.o += -O1 endif One final comment, since you are modifying make files I think you also > should sent the RFR to the build-dev at openjdk.java.net distro as well. > Thanks, > Lois > > My last webrev contained some unrelated makefile changes. I think the current changes are quite trivial - they just remove the ALLOW_OPERATOR_NEW define. Lois, can you please sponsor this change and run it trough JPRT? Thank you and best regards, Volker > > Regards, > Volker > > > Thanks, > Lois > > > > On 4/9/2014 12:34 PM, Volker Simonis wrote: > > Hi, > > could you please review and sponsor the following small change: > http://cr.openjdk.java.net/~simonis/webrevs/8039805/https://bugs.openjdk.java.net/browse/JDK-8039805 > > which fixes the signature of the global new/delete operators in > allocation.cpp > > For non-product builds allocation.cpp defines global new/delete > operators which shut down the VM if they get called at runtime. The > rational behind this is that the these global operators should never > be used in HotSpot. > > Unfortunately, the signature of some of these operators doesn't > conform to the C++ standard which confuses some C++ compilers. For a > more detailed explanation of the C++ background of this issue see the > new comments in allcoation.cpp and the end of this mail. > > This change also replaces the asserts in the operators with guarantees > because the code may also be active in not-product (aka. 'optimized') > builds. > > Finally, the webrev fixes two places in the AIX-port which used the > global new operator. After the change we can now remove the definition > of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. > > I have also removed ALLOW_OPERATOR_NEW_USAGE from > bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp > which state that on Mac OS X the global new/delete operators from the > HotSpot cause problems together with usages of these operators from > the class library such as the ones from > Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t > observe any such problems but if anybody has some concrete concerns > I'm ready to remove this part from the webrev. > > I've build and tested these changes on Linux/x86_64, Linux/ppc64, > Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially > run the regression tests from sun/security/ec which exercise the > method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which > was mentioned to cause problems in conjunction with the globally > defined new/delete operators from the HotSpot but couldn't see any > issues, neither in the slowdebug nor in the optimized build. > > Following some C++ background regarding the global new/delete operators: > > In C++98/03 the throwing new operators are defined with the following > signature: > > void* operator new(std::size_tsize) throw(std::bad_alloc); > void* operator new[](std::size_tsize) throw(std::bad_alloc); > > while all the other (non-throwing) new and delete operators are > defined with an empty throw clause (i.e. "operator delete(void* p) > throw()") which means that they do not throw any exceptions (see > section 18.4 of the C++ standardhttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). > > In the new C++11/14 standard > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), > the signature of the throwing new operators was changed by completely > omitting the throw clause (which effectively means they could throw > any exception) while all the other new/delete operators where changed > to have a 'nothrow' clause instead of an empty throw clause. > > Unfortunately, the support for exception specifications among C++ > compilers is still very fragile. While some more strict compilers like > AIX xlC or HP aCC reject to override the default throwing new operator > with a user operator with an empty throw() clause, the MS Visual C++ > compiler warns for every non-empty throw clause like > throw(std::bad_alloc) that it will ignore the exception specification > (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). > > I've therefore changed the operator definitions such that they > correctly work with all currently supported compilers and in way which > should be upwards compatible with C++11/14. > > Please notice that I'm aware of the discussion around "8021954: VM > SIGSEGV during classloading on MacOS; hs_err_pid file produced" > > (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924,http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) > which introduced empty throw() clauses on all user defined new > operators. But I think the rational used for that change doesn't apply > here, because these global, user user defined new operators changed in > this webrev aren't meant to be really used. There only task is to > override the default, global operators (and therefore they need to > have the right signature) and to shut the VM down if they get called. > > Thank you and best regards, > Volker > > > From volker.simonis at gmail.com Fri Apr 11 10:34:32 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Apr 2014 12:34:32 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <53474C4B.9000006@oracle.com> References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> Message-ID: On Fri, Apr 11, 2014 at 3:58 AM, David Holmes wrote: > On 11/04/2014 4:33 AM, Volker Simonis wrote: > >> Hi David, >> >> thanks for looking at this issue. >> >> I agree with you and I've completely removed ALLOW_OPERATOR_NEW now: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8039805.v2/ >> > > I actually meant delete the whole block guarded by ALLOW_OPERATOR_NEW - we > don't need these error-trapping definitions now we have fixed the export > problem. > > OK, but arguing this way, we could remove remove all asserts from the code, once we fixed an error revealed by them. I think the error-trapping new/delete operators are still valuable in protecting people from accidentally calling them (and they don't really hurt anybody in terms of performance or space). Regards, Volker > FYI I'm not in the runtime group. > > David > ----- > > > I've also changed the "guarantee" into "fatal" as proposed by Vladimir. >> >> I've thought a little while about the problem that some other code may >> unintentionally use these operators but I couldn?t really find a >> scenario where this could happen. Because as you correctly pointed >> out, these operators aren't exported from libjvm.so - after all, >> that's the whole reason for compiling with visibility=hidden and using >> of export maps. So if another program/library will load libjvm.so, the >> operators won't be visible. On the other hand, if the libjvm.so loads >> another shared libraries which use these operators they either have >> their own, private versions of them or they are dynamically linked >> against another library (most probably the standard library) which >> provides versions of the operators. >> >> So if I'm not totally wrong, we could in principle also enable these >> operators in the product build. However, I'm not proposing that for >> this change. Let's first fix the signatures and get rid of >> ALLOW_OPERATOR_NEW with this change. If everything works fine, we can >> think about enabling these global operators in product builds as well. >> >> By the way - are you from the runtime group? >> I was asked to get a review from a runtime-group member - anybody out >> there willing to volunteer? >> >> Thank you and best regards, >> Volker >> >> >> On Thu, Apr 10, 2014 at 5:19 AM, David Holmes >> wrote: >> >>> I think we should just delete the whole ALLOW_OPERATOR_NEW block. We >>> fixed >>> the problem of it being called outside the VM under 8014326. >>> >>> David >>> >>> >>> On 10/04/2014 12:48 PM, David Holmes wrote: >>> >>>> >>>> Hi Volker, >>>> >>>> Need more time to consider this in full but from the existing code: >>>> >>>> 689 // On certain platforms, such as Mac OS X (Darwin), in debug >>>> version, new is being called >>>> 690 // from jdk source and causing data corruption. Such as >>>> 691 // Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair >>>> 692 // define ALLOW_OPERATOR_NEW_USAGE for platform on which global >>>> operator new allowed. >>>> >>>> we actually fixed that by using the mapfiles to ensure the hotspot >>>> operator new was not visible externally. The existence of >>>> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the time :( >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8014326 >>>> >>>> David >>>> >>>> On 10/04/2014 2:34 AM, Volker Simonis wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> could you please review and sponsor the following small change: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8039805/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8039805 >>>>> >>>>> which fixes the signature of the global new/delete operators in >>>>> allocation.cpp >>>>> >>>>> For non-product builds allocation.cpp defines global new/delete >>>>> operators which shut down the VM if they get called at runtime. The >>>>> rational behind this is that the these global operators should never >>>>> be used in HotSpot. >>>>> >>>>> Unfortunately, the signature of some of these operators doesn't >>>>> conform to the C++ standard which confuses some C++ compilers. For a >>>>> more detailed explanation of the C++ background of this issue see the >>>>> new comments in allcoation.cpp and the end of this mail. >>>>> >>>>> This change also replaces the asserts in the operators with guarantees >>>>> because the code may also be active in not-product (aka. 'optimized') >>>>> builds. >>>>> >>>>> Finally, the webrev fixes two places in the AIX-port which used the >>>>> global new operator. After the change we can now remove the definition >>>>> of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. >>>>> >>>>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >>>>> bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp >>>>> which state that on Mac OS X the global new/delete operators from the >>>>> HotSpot cause problems together with usages of these operators from >>>>> the class library such as the ones from >>>>> Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn?t >>>>> observe any such problems but if anybody has some concrete concerns >>>>> I'm ready to remove this part from the webrev. >>>>> >>>>> I've build and tested these changes on Linux/x86_64, Linux/ppc64, >>>>> Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially >>>>> run the regression tests from sun/security/ec which exercise the >>>>> method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which >>>>> was mentioned to cause problems in conjunction with the globally >>>>> defined new/delete operators from the HotSpot but couldn't see any >>>>> issues, neither in the slowdebug nor in the optimized build. >>>>> >>>>> Following some C++ background regarding the global new/delete >>>>> operators: >>>>> >>>>> In C++98/03 the throwing new operators are defined with the following >>>>> signature: >>>>> >>>>> void* operator new(std::size_tsize) throw(std::bad_alloc); >>>>> void* operator new[](std::size_tsize) throw(std::bad_alloc); >>>>> >>>>> while all the other (non-throwing) new and delete operators are >>>>> defined with an empty throw clause (i.e. "operator delete(void* p) >>>>> throw()") which means that they do not throw any exceptions (see >>>>> section 18.4 of the C++ standard >>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf). >>>>> >>>>> In the new C++11/14 standard >>>>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf), >>>>> the signature of the throwing new operators was changed by completely >>>>> omitting the throw clause (which effectively means they could throw >>>>> any exception) while all the other new/delete operators where changed >>>>> to have a 'nothrow' clause instead of an empty throw clause. >>>>> >>>>> Unfortunately, the support for exception specifications among C++ >>>>> compilers is still very fragile. While some more strict compilers like >>>>> AIX xlC or HP aCC reject to override the default throwing new operator >>>>> with a user operator with an empty throw() clause, the MS Visual C++ >>>>> compiler warns for every non-empty throw clause like >>>>> throw(std::bad_alloc) that it will ignore the exception specification >>>>> (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx). >>>>> >>>>> I've therefore changed the operator definitions such that they >>>>> correctly work with all currently supported compilers and in way which >>>>> should be upwards compatible with C++11/14. >>>>> >>>>> Please notice that I'm aware of the discussion around "8021954: VM >>>>> SIGSEGV during classloading on MacOS; hs_err_pid file produced" >>>>> >>>>> (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/ >>>>> 2013-August/thread.html#8924, >>>>> >>>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299) >>>>> which introduced empty throw() clauses on all user defined new >>>>> operators. But I think the rational used for that change doesn't apply >>>>> here, because these global, user user defined new operators changed in >>>>> this webrev aren't meant to be really used. There only task is to >>>>> override the default, global operators (and therefore they need to >>>>> have the right signature) and to shut the VM down if they get called. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> >>> From david.holmes at oracle.com Fri Apr 11 10:43:17 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Apr 2014 20:43:17 +1000 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> Message-ID: <5347C745.2040901@oracle.com> On 11/04/2014 8:34 PM, Volker Simonis wrote: > On Fri, Apr 11, 2014 at 3:58 AM, David Holmes > wrote: > > On 11/04/2014 4:33 AM, Volker Simonis wrote: > > Hi David, > > thanks for looking at this issue. > > I agree with you and I've completely removed ALLOW_OPERATOR_NEW now: > > http://cr.openjdk.java.net/~__simonis/webrevs/8039805.v2/ > > > > I actually meant delete the whole block guarded by > ALLOW_OPERATOR_NEW - we don't need these error-trapping definitions > now we have fixed the export problem. > > > OK, but arguing this way, we could remove remove all asserts from the > code, once we fixed an error revealed by them. Obviously you have to draw a line somewhere. But I don't think these particular methods are worth the problem they are now causing. Cheers, David > I think the error-trapping new/delete operators are still valuable in > protecting people from accidentally calling them (and they don't really > hurt anybody in terms of performance or space). > > Regards, > Volker > > FYI I'm not in the runtime group. > > David > ----- > > > I've also changed the "guarantee" into "fatal" as proposed by > Vladimir. > > I've thought a little while about the problem that some other > code may > unintentionally use these operators but I couldn?t really find a > scenario where this could happen. Because as you correctly pointed > out, these operators aren't exported from libjvm.so - after all, > that's the whole reason for compiling with visibility=hidden and > using > of export maps. So if another program/library will load > libjvm.so, the > operators won't be visible. On the other hand, if the libjvm.so > loads > another shared libraries which use these operators they either have > their own, private versions of them or they are dynamically linked > against another library (most probably the standard library) which > provides versions of the operators. > > So if I'm not totally wrong, we could in principle also enable these > operators in the product build. However, I'm not proposing that for > this change. Let's first fix the signatures and get rid of > ALLOW_OPERATOR_NEW with this change. If everything works fine, > we can > think about enabling these global operators in product builds as > well. > > By the way - are you from the runtime group? > I was asked to get a review from a runtime-group member - > anybody out > there willing to volunteer? > > Thank you and best regards, > Volker > > > On Thu, Apr 10, 2014 at 5:19 AM, David Holmes > > wrote: > > I think we should just delete the whole ALLOW_OPERATOR_NEW > block. We fixed > the problem of it being called outside the VM under 8014326. > > David > > > On 10/04/2014 12:48 PM, David Holmes wrote: > > > Hi Volker, > > Need more time to consider this in full but from the > existing code: > > 689 // On certain platforms, such as Mac OS X > (Darwin), in debug > version, new is being called > 690 // from jdk source and causing data corruption. > Such as > 691 // > Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair > 692 // define ALLOW_OPERATOR_NEW_USAGE for platform > on which global > operator new allowed. > > we actually fixed that by using the mapfiles to ensure > the hotspot > operator new was not visible externally. The existence of > ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the time :( > > https://bugs.openjdk.java.net/__browse/JDK-8014326 > > > David > > On 10/04/2014 2:34 AM, Volker Simonis wrote: > > > Hi, > > could you please review and sponsor the following > small change: > > http://cr.openjdk.java.net/~__simonis/webrevs/8039805/ > > https://bugs.openjdk.java.net/__browse/JDK-8039805 > > > which fixes the signature of the global new/delete > operators in > allocation.cpp > > For non-product builds allocation.cpp defines global > new/delete > operators which shut down the VM if they get called > at runtime. The > rational behind this is that the these global > operators should never > be used in HotSpot. > > Unfortunately, the signature of some of these > operators doesn't > conform to the C++ standard which confuses some C++ > compilers. For a > more detailed explanation of the C++ background of > this issue see the > new comments in allcoation.cpp and the end of this mail. > > This change also replaces the asserts in the > operators with guarantees > because the code may also be active in not-product > (aka. 'optimized') > builds. > > Finally, the webrev fixes two places in the AIX-port > which used the > global new operator. After the change we can now > remove the definition > of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make. > > I have also removed ALLOW_OPERATOR_NEW_USAGE from > bsd/makefiles/vm.make and the corresponding comments > in allcoation.cpp > which state that on Mac OS X the global new/delete > operators from the > HotSpot cause problems together with usages of these > operators from > the class library such as the ones from > Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair. > I couldn?t > observe any such problems but if anybody has some > concrete concerns > I'm ready to remove this part from the webrev. > > I've build and tested these changes on Linux/x86_64, > Linux/ppc64, > Solaris/Sparc, Windows/x86_64, MacOS X and > AIX/ppc64. I've especially > run the regression tests from sun/security/ec which > exercise the > method > Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair > which > was mentioned to cause problems in conjunction with > the globally > defined new/delete operators from the HotSpot but > couldn't see any > issues, neither in the slowdebug nor in the > optimized build. > > Following some C++ background regarding the global > new/delete operators: > > In C++98/03 the throwing new operators are defined > with the following > signature: > > void* operator new(std::size_tsize) > throw(std::bad_alloc); > void* operator new[](std::size_tsize) > throw(std::bad_alloc); > > while all the other (non-throwing) new and delete > operators are > defined with an empty throw clause (i.e. "operator > delete(void* p) > throw()") which means that they do not throw any > exceptions (see > section 18.4 of the C++ standard > http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2005/__n1905.pdf > ). > > In the new C++11/14 standard > (http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2013/__n3797.pdf > ), > the signature of the throwing new operators was > changed by completely > omitting the throw clause (which effectively means > they could throw > any exception) while all the other new/delete > operators where changed > to have a 'nothrow' clause instead of an empty throw > clause. > > Unfortunately, the support for exception > specifications among C++ > compilers is still very fragile. While some more > strict compilers like > AIX xlC or HP aCC reject to override the default > throwing new operator > with a user operator with an empty throw() clause, > the MS Visual C++ > compiler warns for every non-empty throw clause like > throw(std::bad_alloc) that it will ignore the > exception specification > (see > http://msdn.microsoft.com/en-__us/library/sa28fef8.aspx > ). > > I've therefore changed the operator definitions such > that they > correctly work with all currently supported > compilers and in way which > should be upwards compatible with C++11/14. > > Please notice that I'm aware of the discussion > around "8021954: VM > SIGSEGV during classloading on MacOS; hs_err_pid > file produced" > > (http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2013-August/thread.html#8924 > , > > http://hg.openjdk.java.net/__hsx/hotspot-comp/hotspot/rev/__9758d9f36299 > ) > which introduced empty throw() clauses on all user > defined new > operators. But I think the rational used for that > change doesn't apply > here, because these global, user user defined new > operators changed in > this webrev aren't meant to be really used. There > only task is to > override the default, global operators (and > therefore they need to > have the right signature) and to shut the VM down if > they get called. > > Thank you and best regards, > Volker > > > From david.holmes at oracle.com Fri Apr 11 11:15:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Apr 2014 21:15:29 +1000 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <5347C745.2040901@oracle.com> References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> <5347C745.2040901@oracle.com> Message-ID: <5347CED1.3000908@oracle.com> On 11/04/2014 8:43 PM, David Holmes wrote: > On 11/04/2014 8:34 PM, Volker Simonis wrote: >> On Fri, Apr 11, 2014 at 3:58 AM, David Holmes > > wrote: >> >> On 11/04/2014 4:33 AM, Volker Simonis wrote: >> >> Hi David, >> >> thanks for looking at this issue. >> >> I agree with you and I've completely removed >> ALLOW_OPERATOR_NEW now: >> >> http://cr.openjdk.java.net/~__simonis/webrevs/8039805.v2/ >> >> >> >> I actually meant delete the whole block guarded by >> ALLOW_OPERATOR_NEW - we don't need these error-trapping definitions >> now we have fixed the export problem. >> >> >> OK, but arguing this way, we could remove remove all asserts from the >> code, once we fixed an error revealed by them. > > Obviously you have to draw a line somewhere. But I don't think these > particular methods are worth the problem they are now causing. Ignore that. I just realized it is not the external linkage to these methods that is the main issue, but some internal hotspot code calling the global operator new/delete. David > Cheers, > David > >> I think the error-trapping new/delete operators are still valuable in >> protecting people from accidentally calling them (and they don't really >> hurt anybody in terms of performance or space). >> >> Regards, >> Volker >> >> FYI I'm not in the runtime group. >> >> David >> ----- >> >> >> I've also changed the "guarantee" into "fatal" as proposed by >> Vladimir. >> >> I've thought a little while about the problem that some other >> code may >> unintentionally use these operators but I couldn?t really find a >> scenario where this could happen. Because as you correctly >> pointed >> out, these operators aren't exported from libjvm.so - after all, >> that's the whole reason for compiling with visibility=hidden and >> using >> of export maps. So if another program/library will load >> libjvm.so, the >> operators won't be visible. On the other hand, if the libjvm.so >> loads >> another shared libraries which use these operators they either >> have >> their own, private versions of them or they are dynamically >> linked >> against another library (most probably the standard library) >> which >> provides versions of the operators. >> >> So if I'm not totally wrong, we could in principle also enable >> these >> operators in the product build. However, I'm not proposing >> that for >> this change. Let's first fix the signatures and get rid of >> ALLOW_OPERATOR_NEW with this change. If everything works fine, >> we can >> think about enabling these global operators in product builds as >> well. >> >> By the way - are you from the runtime group? >> I was asked to get a review from a runtime-group member - >> anybody out >> there willing to volunteer? >> >> Thank you and best regards, >> Volker >> >> >> On Thu, Apr 10, 2014 at 5:19 AM, David Holmes >> > wrote: >> >> I think we should just delete the whole ALLOW_OPERATOR_NEW >> block. We fixed >> the problem of it being called outside the VM under 8014326. >> >> David >> >> >> On 10/04/2014 12:48 PM, David Holmes wrote: >> >> >> Hi Volker, >> >> Need more time to consider this in full but from the >> existing code: >> >> 689 // On certain platforms, such as Mac OS X >> (Darwin), in debug >> version, new is being called >> 690 // from jdk source and causing data corruption. >> Such as >> 691 // >> >> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >> 692 // define ALLOW_OPERATOR_NEW_USAGE for platform >> on which global >> operator new allowed. >> >> we actually fixed that by using the mapfiles to ensure >> the hotspot >> operator new was not visible externally. The existence of >> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the >> time :( >> >> https://bugs.openjdk.java.net/__browse/JDK-8014326 >> >> >> David >> >> On 10/04/2014 2:34 AM, Volker Simonis wrote: >> >> >> Hi, >> >> could you please review and sponsor the following >> small change: >> >> >> http://cr.openjdk.java.net/~__simonis/webrevs/8039805/ >> >> >> https://bugs.openjdk.java.net/__browse/JDK-8039805 >> >> >> which fixes the signature of the global new/delete >> operators in >> allocation.cpp >> >> For non-product builds allocation.cpp defines global >> new/delete >> operators which shut down the VM if they get called >> at runtime. The >> rational behind this is that the these global >> operators should never >> be used in HotSpot. >> >> Unfortunately, the signature of some of these >> operators doesn't >> conform to the C++ standard which confuses some C++ >> compilers. For a >> more detailed explanation of the C++ background of >> this issue see the >> new comments in allcoation.cpp and the end of this >> mail. >> >> This change also replaces the asserts in the >> operators with guarantees >> because the code may also be active in not-product >> (aka. 'optimized') >> builds. >> >> Finally, the webrev fixes two places in the AIX-port >> which used the >> global new operator. After the change we can now >> remove the definition >> of ALLOW_OPERATOR_NEW_USAGE from >> aix/makefiles/vm.make. >> >> I have also removed ALLOW_OPERATOR_NEW_USAGE from >> bsd/makefiles/vm.make and the corresponding comments >> in allcoation.cpp >> which state that on Mac OS X the global new/delete >> operators from the >> HotSpot cause problems together with usages of these >> operators from >> the class library such as the ones from >> >> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair. >> I couldn?t >> observe any such problems but if anybody has some >> concrete concerns >> I'm ready to remove this part from the webrev. >> >> I've build and tested these changes on Linux/x86_64, >> Linux/ppc64, >> Solaris/Sparc, Windows/x86_64, MacOS X and >> AIX/ppc64. I've especially >> run the regression tests from sun/security/ec which >> exercise the >> method >> >> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >> which >> was mentioned to cause problems in conjunction with >> the globally >> defined new/delete operators from the HotSpot but >> couldn't see any >> issues, neither in the slowdebug nor in the >> optimized build. >> >> Following some C++ background regarding the global >> new/delete operators: >> >> In C++98/03 the throwing new operators are defined >> with the following >> signature: >> >> void* operator new(std::size_tsize) >> throw(std::bad_alloc); >> void* operator new[](std::size_tsize) >> throw(std::bad_alloc); >> >> while all the other (non-throwing) new and delete >> operators are >> defined with an empty throw clause (i.e. "operator >> delete(void* p) >> throw()") which means that they do not throw any >> exceptions (see >> section 18.4 of the C++ standard >> >> http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2005/__n1905.pdf >> >> ). >> >> In the new C++11/14 standard >> >> (http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2013/__n3797.pdf >> >> ), >> the signature of the throwing new operators was >> changed by completely >> omitting the throw clause (which effectively means >> they could throw >> any exception) while all the other new/delete >> operators where changed >> to have a 'nothrow' clause instead of an empty throw >> clause. >> >> Unfortunately, the support for exception >> specifications among C++ >> compilers is still very fragile. While some more >> strict compilers like >> AIX xlC or HP aCC reject to override the default >> throwing new operator >> with a user operator with an empty throw() clause, >> the MS Visual C++ >> compiler warns for every non-empty throw clause like >> throw(std::bad_alloc) that it will ignore the >> exception specification >> (see >> >> http://msdn.microsoft.com/en-__us/library/sa28fef8.aspx >> >> ). >> >> I've therefore changed the operator definitions such >> that they >> correctly work with all currently supported >> compilers and in way which >> should be upwards compatible with C++11/14. >> >> Please notice that I'm aware of the discussion >> around "8021954: VM >> SIGSEGV during classloading on MacOS; hs_err_pid >> file produced" >> >> >> (http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2013-August/thread.html#8924 >> >> >> , >> >> >> >> http://hg.openjdk.java.net/__hsx/hotspot-comp/hotspot/rev/__9758d9f36299 >> >> ) >> which introduced empty throw() clauses on all user >> defined new >> operators. But I think the rational used for that >> change doesn't apply >> here, because these global, user user defined new >> operators changed in >> this webrev aren't meant to be really used. There >> only task is to >> override the default, global operators (and >> therefore they need to >> have the right signature) and to shut the VM down if >> they get called. >> >> Thank you and best regards, >> Volker >> >> >> From lev.priima at oracle.com Fri Apr 11 11:46:00 2014 From: lev.priima at oracle.com (Lev Priima) Date: Fri, 11 Apr 2014 15:46:00 +0400 Subject: [9] RFR (XS): 8039260: c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean, String... ) must also take test.java.opts Message-ID: <5347D5F8.4060800@oracle.com> Hi all, Please review small patch: http://cr.openjdk.java.net/~iignatyev/lpriima/8039260/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8039260 6 lines changed: 0 ins; 3 del; 3 mod; Problem: method c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean addTestVmOptions, String... command) starts "java" launcher without passing to it "test.java.opts" received from jtreg harness. Fix: Add both "test.vm.opts" and "test.java.opts" to newly created java process by new parameter name "addTestVmAndJavaOptions" Testing: jprt default set + all hotspot regression tests -- Lev From jaromir.hamala at gmail.com Fri Apr 11 13:34:01 2014 From: jaromir.hamala at gmail.com (Jaromir Hamala) Date: Fri, 11 Apr 2014 14:34:01 +0100 Subject: Change thread dump location? Message-ID: Hi, I'd like to create a patch allowing to change a location of a threaddump when it's triggered by sending a signal. My understanding is that currently there is no option to specify a custom path. Is this a feature you would consider to accept & eventually merge? I'm aware one could use eg. jstack to save the threaddump into an arbitrary location, but this tooling is not always available as it's part of JDK and not JRE. Cheers, Jaromir -- ?Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.? Antoine de Saint Exup?ry From alejandro.murillo at oracle.com Fri Apr 11 19:20:58 2014 From: alejandro.murillo at oracle.com (alejandro murillo) Date: Fri, 11 Apr 2014 13:20:58 -0600 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <53474F43.4060706@oracle.com> References: <5345E28F.5050108@oracle.com> <53460434.50400@oracle.com> <5346BBF7.9080501@oracle.com> <53474F43.4060706@oracle.com> Message-ID: <5348409A.5060803@oracle.com> On 4/10/2014 8:11 PM, David Holmes wrote: > On 11/04/2014 1:42 AM, Alejandro E Murillo wrote: >> Hi David, thanks for the feedback, see below >> On 4/9/2014 8:38 PM, David Holmes wrote: >>> Hi Alejandro, >>> >>> Given we have to maintain the JDK version information in two places >>> (top level repo and hotspot repo) wouldn't it have been simpler to >>> keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set >>> the major/minor/build values to match those of the JDK version? >> The file is still used, just renamed as only jdk info is in there. >> HOTSPOT_RELEASE_VERSION was also kept, we just don't get the >> major,minor,micro and build number >> from it anymore, mainly it is now set very similar to the >> JDK_RELEASE_VERSION (plus other values), >> and that format it's not fixed as it used to be for hotspot express. >> Those values (major,minor,micro and build number) >> are already defined in the makefiles, so we just pass them to >> vm_version.cpp, so no more parsing in it. > > I still think the overall changes could have been much smaller but okay. The change actually is not that big, what happens is that due to the makefile structure the exact same change has to be replicated on each platform. Then, some of the changes themselves are actually comment changes, to remove references to the hsx hs version, and/or removal of lines of code that had been removed in some platform (Solaris) but not in others; also renaming some macros to better reflect what they are for. I also fixed some typos on macros names that were incorrect already, like these: http://cr.openjdk.java.net/~amurillo/9/8030011/make/windows/makefiles/defs.make.wdiff.html In a nutshell I just added the ability to get major,minor,micro and build number available to vm_version.cpp, in addition to hotspot_release_version, so that we don't have parse that to obtain those. And of course, adding additional testing of those values that is minimal right now. The other changes are related to now having to handle the micro_version, which was ignored with the old hotspot_version, but that has to be done regardless of how the values were obtained. The change is actually simple, compared to understanding how the makefiles work and how vm_version receives the values. Alejandro > > Thanks, > David > ----- > > >>> >>> That aside, in jdk_version file hotspot copyright should now be 2014 >> will fix that >>> >>> */vm.make: >>> >>> This line is way too long. >>> >>> ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" >>> -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" >>> -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" >>> -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" >>> -DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\"" >>> -DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\"" >> ok >>> >>> Not clear why we suddenly need defines for all the component pieces >>> either. You could have kept the HS_XXX variables, just adding the >>> micro part. >> as mentioned above, the micro part was actually added to >> HOTSPOT_RELEASE_VERSION, >> we just don't get those values by parsing it, so we just pass those >> values to the vm_version.cpp, >> since they are already defined in the makefiles. The format of the JDK >> version is not that fixed. >> >> Thanks >> Alejandro >>> >>> David >>> >>> >>> On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: >>>> >>>> Please review this change to make the hotspot related output >>>> produced by >>>> "java -version" >>>> match the corresponding JDK output: >>>> >>>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 >>>> >>>> Note that we initially wanted to obtain more information from the repo >>>> being built and add >>>> it to the hotspot version output, but that will require changes in the >>>> JPRT, so >>>> we have decided to split the change in 2 bugs. One to make the version >>>> match >>>> (above webrev) and another one, an RFE, to add additional information >>>> extracted from the repo. >>>> >>>> Note that in the current version of vm_version.cpp, there is no error >>>> checking in product mode, >>>> I was suggested to make that explicit. >>>> >>>> Release Engineering did some testing and I also ran several cases with >>>> full and just hotspot JPRT builds. >>>> >>>> Here is a summary of how the new output compares to the old one: >>>> >>>> (1) Release Engineering builds (9-dev): >>>> >>>> from jdk9-dev build: >>>> java version "1.9.0-ea" >>>> Java(TM) SE Runtime Environment (build >>>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) >>>> Java HotSpot(TM) 64-Bit Server VM (build >>>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) >>>> >>>> compared with what we currently have >>>> java version "1.9.0-ea" >>>> Java(TM) SE Runtime Environment (build >>>> 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) >>>> >>>> (2) Release Engineering builds (jdk9): >>>> >>>> java version "1.9.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) >>>> Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) >>>> >>>> compared with what we currently have >>>> java version "1.9.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) >>>> >>>> (3) JPRT Full builds: >>>> >>>> java version "1.9.0-internal" >>>> # Java(TM) SE Runtime Environment (build >>>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) >>>> # Java HotSpot(TM) Server VM (build >>>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed >>>> mode) >>>> >>>> >>>> (4) JPRT hotspot only builds: >>>> >>>> java version "1.9.0-ea-fastdebug" >>>> # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) >>>> # Java HotSpot(TM) Server VM (build >>>> 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, >>>> mixed >>>> mode) >>>> >>>> >>>> in this one the built VM is inserted into a promoted build bundle, >>>> since we do not have the JDK build number info in the hotspot repo, >>>> we can't match the build number in the JDK portion. >>>> With the RFE mentioned above, we can extract the build info from the >>>> repo >>>> and add it to the hotspot portion. >>>> >>>> I want to mention, that this may change once the new JDK version >>>> change >>>> is implemented >>>> but we don't know when that will be implemented yet, so we need to go >>>> ahead with this to >>>> get rid of the old hotspot express output. And most of these changes >>>> will still have to be done >>>> anyways >>>> >>>> BTW, john Coomes and Dan Daugherty provided feedback in some >>>> pieces of >>>> this webrev, >>>> but I need full reviews now. >>>> >>>> Thanks >>>> >> -- Alejandro From aph at redhat.com Mon Apr 14 18:01:39 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Apr 2014 19:01:39 +0100 Subject: AArch64 in JDK 9? Message-ID: <534C2283.2010108@redhat.com> We'd like to propose contributing AArch64 support to the main HotSpot tree. SAP have already done this with PowerPC, so we hope to be able to follow the path they took. The changes to HotSpot outside the cpu/ and os_cpu/ directories are fairly minimal. There are quite a few changes we had to make to C1. C1's patching scheme is impossible on AArch64, which (except in some very restricted cases) does not allow the concurrent execution and patching of code. However, we can simply #ifndef these and do our own thing in our back end. We still have some performance tuning to do, and there are undoubtedly cleanups we'd like to make. Also, there are one or two remaining big ticket items, in particular vector support. However, the port works well, passes all its tests, and is IMO ready for the next stage. To begin with I'll create a JDK9 repository which tracks JDK9 with the minimum changes to shared code, then I guess the best thing would be for us to discuss the changes we need on this list. Does that make sense? Thanks, Andrew. From fuudtorrentsru at gmail.com Sun Apr 13 15:09:11 2014 From: fuudtorrentsru at gmail.com (Fedor Bobin) Date: Sun, 13 Apr 2014 19:09:11 +0400 Subject: JDK-4834738 NullPointerException: Better info Message-ID: Can you please review patch for JDK-4834738. Currently I added more information to NPE if it is handled by interpreter or template interpreter on x86-64. On other platforms and after compilation jdk will handle NPE as usual. From igor.veresov at oracle.com Tue Apr 15 03:51:29 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 14 Apr 2014 20:51:29 -0700 Subject: [8u20] RFR(M): 8038297: Avoid placing CTI immediately following cbcond instruction on T4 Message-ID: <76A9A7C1-64B9-4677-8181-70941F1834CD@oracle.com> I?d like to backport JDK-8038297. Nightlies seem to be fine and the patch applies cleanly. Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c86f5b83df67 JBS: https://bugs.openjdk.java.net/browse/JDK-8038297 Webrev: http://cr.openjdk.java.net/~iveresov/8038297/webrev.01/ Thanks! igor From christian.thalinger at oracle.com Tue Apr 15 05:09:43 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Apr 2014 19:09:43 -1000 Subject: [8u20] RFR(M): 8038297: Avoid placing CTI immediately following cbcond instruction on T4 In-Reply-To: <76A9A7C1-64B9-4677-8181-70941F1834CD@oracle.com> References: <76A9A7C1-64B9-4677-8181-70941F1834CD@oracle.com> Message-ID: Good. On Apr 14, 2014, at 5:51 PM, Igor Veresov wrote: > I?d like to backport JDK-8038297. Nightlies seem to be fine and the patch applies cleanly. > > Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c86f5b83df67 > JBS: https://bugs.openjdk.java.net/browse/JDK-8038297 > Webrev: http://cr.openjdk.java.net/~iveresov/8038297/webrev.01/ > > > Thanks! > igor From vladimir.kozlov at oracle.com Tue Apr 15 05:40:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Apr 2014 22:40:04 -0700 Subject: [8u20] RFR(M): 8038297: Avoid placing CTI immediately following cbcond instruction on T4 In-Reply-To: <76A9A7C1-64B9-4677-8181-70941F1834CD@oracle.com> References: <76A9A7C1-64B9-4677-8181-70941F1834CD@oracle.com> Message-ID: <534CC634.3080609@oracle.com> Good. Thanks, Vladimir On 4/14/14 8:51 PM, Igor Veresov wrote: > I?d like to backport JDK-8038297. Nightlies seem to be fine and the patch applies cleanly. > > Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c86f5b83df67 > JBS: https://bugs.openjdk.java.net/browse/JDK-8038297 > Webrev: http://cr.openjdk.java.net/~iveresov/8038297/webrev.01/ > > > Thanks! > igor > From david.holmes at oracle.com Tue Apr 15 06:21:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Apr 2014 16:21:29 +1000 Subject: Change thread dump location? In-Reply-To: References: Message-ID: <534CCFE9.8090208@oracle.com> Hi Jaromir, On 11/04/2014 11:34 PM, Jaromir Hamala wrote: > I'd like to create a patch allowing to change a location of a threaddump > when it's triggered by sending a signal. My understanding is that currently > there is no option to specify a custom path. Do you mean the thread-dump in response to SIGQUIT (which goes to the VM's output stream) or the hs-err log file produced when the VM crashes? The SIGQUIT thread-dump doesn't go to a file unless you happen to be redirecting VM output to a file. David > Is this a feature you would consider to accept & eventually merge? I'm > aware one could use eg. jstack to save the threaddump into an arbitrary > location, but this tooling is not always available as it's part of JDK and > not JRE. > > Cheers, > Jaromir > From david.holmes at oracle.com Tue Apr 15 06:32:09 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Apr 2014 16:32:09 +1000 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: References: Message-ID: <534CD269.2060900@oracle.com> Hi Fedor, On 14/04/2014 1:09 AM, Fedor Bobin wrote: > Can you please review patch for JDK-4834738. Patches are stripped when sent as attachments. > Currently I added more information to NPE if it is handled by interpreter > or template interpreter on x86-64. On other platforms and after compilation > jdk will handle NPE as usual. Can you explain what information you add? Thanks, David From fuudtorrentsru at gmail.com Tue Apr 15 07:16:39 2014 From: fuudtorrentsru at gmail.com (Fedor Bobin) Date: Tue, 15 Apr 2014 11:16:39 +0400 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: <534CD269.2060900@oracle.com> References: <534CD269.2060900@oracle.com> Message-ID: Hello. What is the best way to submit patch? Currently you can see it at https://gist.github.com/Fuud/10709048 >>Can you explain what information you add? This java code will produce NPE; ((String)null).length(); Before patch exception stack trace looks like this: java.lang.NullPointerException at Test.testNPE(Test.java:14) at Test.main(Test.java:8) After patch if code is executing by interpreter NPE will have additional information java.lang.NullPointerException: can not invoke method java.lang.String.length()I on null object at Test.testNPE(Test.java:14) at Test.main(Test.java:8) This additional information can help to understand cause of NPE in case of call chains. For example, let we have java code a.b().c(); if we get NPE without message we can not understand is a==null or a.b()==null. After patch we will get enough information: java.lang.NullPointerException: can not invoke method A.b() on null object So we can understand that a is null. Thanks. Fedor Bobin 2014-04-15 10:32 GMT+04:00 David Holmes : > Hi Fedor, > > > On 14/04/2014 1:09 AM, Fedor Bobin wrote: > >> Can you please review patch for JDK-4834738. >> > > Patches are stripped when sent as attachments. > > > Currently I added more information to NPE if it is handled by interpreter >> or template interpreter on x86-64. On other platforms and after >> compilation >> jdk will handle NPE as usual. >> > > Can you explain what information you add? > > Thanks, > David > > From david.holmes at oracle.com Tue Apr 15 07:35:54 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Apr 2014 17:35:54 +1000 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: References: <534CD269.2060900@oracle.com> Message-ID: <534CE15A.9030909@oracle.com> On 15/04/2014 5:16 PM, Fedor Bobin wrote: > Hello. > > What is the best way to submit patch? > Currently you can see it at https://gist.github.com/Fuud/10709048 If you become a regular contributor to OpenJDK you can get access to cr.openjdk.java.net to upload patches. Otherwise inline attachments or a link to something like github is okay. >>>Can you explain what information you add? > > This java code will produce NPE; > > ((String)null).length(); > > Before patch exception stack trace looks like this: > > java.lang.NullPointerException > at Test.testNPE(Test.java:14) > at Test.main(Test.java:8) > > After patch if code is executing by interpreter NPE will have additional > information > > java.lang.NullPointerException: can not invoke method > java.lang.String.length()I on null object > at Test.testNPE(Test.java:14) > at Test.main(Test.java:8) > > This additional information can help to understand cause of NPE in case > of call chains. For example, let we have java code > > a.b().c(); > > if we get NPE without message we can not understand is a==null or > a.b()==null. After patch we will get enough information: > > java.lang.NullPointerException: can not invoke method A.b() on null object > > So we can understand that a is null. There have been a couple of RFEs on this in the past, one very recently, and they have been closed as "will not fix" - mainly because except in some limited circumstances the VM does not have much additional information to add. That said your patch is the "inverse" of the other requests - they wanted to know which "variable" was null, whereas you are showing which method invocation was attempted on a null reference. Hopefully some folks from the runtime team will be able to take a look at this and evaluate it. But it would be nice to be able to get similar information from compiled code too - though that may not be feasible. Thanks, David > > Thanks. > Fedor Bobin > > > > 2014-04-15 10:32 GMT+04:00 David Holmes >: > > Hi Fedor, > > > On 14/04/2014 1:09 AM, Fedor Bobin wrote: > > Can you please review patch for JDK-4834738. > > > Patches are stripped when sent as attachments. > > > Currently I added more information to NPE if it is handled by > interpreter > or template interpreter on x86-64. On other platforms and after > compilation > jdk will handle NPE as usual. > > > Can you explain what information you add? > > Thanks, > David > > From jaromir.hamala at gmail.com Tue Apr 15 07:45:47 2014 From: jaromir.hamala at gmail.com (Jaromir Hamala) Date: Tue, 15 Apr 2014 08:45:47 +0100 Subject: Change thread dump location? In-Reply-To: <534CCFE9.8090208@oracle.com> References: <534CCFE9.8090208@oracle.com> Message-ID: Hi David, I mean a response to SIGQUIT. I'd like to add an ability to specify a file/directory where threaddumps will be written to even when stdout/err are not redirected. I believe having separated threadumps from rest of the logs might be useful when troubleshooting. It's actually not my idea - there was a user asking how to do it in other mailing-list. Cheers, Jaromir On Tue, Apr 15, 2014 at 7:21 AM, David Holmes wrote: > Hi Jaromir, > > > On 11/04/2014 11:34 PM, Jaromir Hamala wrote: > >> I'd like to create a patch allowing to change a location of a threaddump >> when it's triggered by sending a signal. My understanding is that >> currently >> there is no option to specify a custom path. >> > > Do you mean the thread-dump in response to SIGQUIT (which goes to the VM's > output stream) or the hs-err log file produced when the VM crashes? > > The SIGQUIT thread-dump doesn't go to a file unless you happen to be > redirecting VM output to a file. > > David > > > Is this a feature you would consider to accept & eventually merge? I'm >> aware one could use eg. jstack to save the threaddump into an arbitrary >> location, but this tooling is not always available as it's part of JDK and >> not JRE. >> >> Cheers, >> Jaromir >> >> -- ?Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.? Antoine de Saint Exup?ry From staffan.larsen at oracle.com Tue Apr 15 09:25:26 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Apr 2014 11:25:26 +0200 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: <534CE15A.9030909@oracle.com> References: <534CD269.2060900@oracle.com> <534CE15A.9030909@oracle.com> Message-ID: <7781F45D-B257-4C2D-9DE6-5DA9563D30FA@oracle.com> On 15 apr 2014, at 09:35, David Holmes wrote: > On 15/04/2014 5:16 PM, Fedor Bobin wrote: >> Hello. >> >> What is the best way to submit patch? >> Currently you can see it at https://gist.github.com/Fuud/10709048 > > If you become a regular contributor to OpenJDK you can get access to cr.openjdk.java.net to upload patches. Otherwise inline attachments or a link to something like github is okay. > >>>> Can you explain what information you add? >> >> This java code will produce NPE; >> >> ((String)null).length(); >> >> Before patch exception stack trace looks like this: >> >> java.lang.NullPointerException >> at Test.testNPE(Test.java:14) >> at Test.main(Test.java:8) >> >> After patch if code is executing by interpreter NPE will have additional >> information >> >> java.lang.NullPointerException: can not invoke method >> java.lang.String.length()I on null object >> at Test.testNPE(Test.java:14) >> at Test.main(Test.java:8) >> >> This additional information can help to understand cause of NPE in case >> of call chains. For example, let we have java code >> >> a.b().c(); >> >> if we get NPE without message we can not understand is a==null or >> a.b()==null. After patch we will get enough information: >> >> java.lang.NullPointerException: can not invoke method A.b() on null object >> >> So we can understand that a is null. > > There have been a couple of RFEs on this in the past, one very recently, and they have been closed as "will not fix" - mainly because except in some limited circumstances the VM does not have much additional information to add. That said your patch is the "inverse" of the other requests - they wanted to know which "variable" was null, whereas you are showing which method invocation was attempted on a null reference. > > Hopefully some folks from the runtime team will be able to take a look at this and evaluate it. But it would be nice to be able to get similar information from compiled code too - though that may not be feasible. I don?t feel comfortable reviewing the code, by I support the effort even if it is only for the interpreter. If at a later stage we can add the same information from the compilers, that would of course be good. /Staffan > > Thanks, > David > >> >> Thanks. >> Fedor Bobin >> >> >> >> 2014-04-15 10:32 GMT+04:00 David Holmes > >: >> >> Hi Fedor, >> >> >> On 14/04/2014 1:09 AM, Fedor Bobin wrote: >> >> Can you please review patch for JDK-4834738. >> >> >> Patches are stripped when sent as attachments. >> >> >> Currently I added more information to NPE if it is handled by >> interpreter >> or template interpreter on x86-64. On other platforms and after >> compilation >> jdk will handle NPE as usual. >> >> >> Can you explain what information you add? >> >> Thanks, >> David >> >> From staffan.larsen at oracle.com Tue Apr 15 09:36:39 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Apr 2014 11:36:39 +0200 Subject: Change thread dump location? In-Reply-To: References: <534CCFE9.8090208@oracle.com> Message-ID: I think this is a valid use-case and it would be good to fix it. Having said that, there is currently work underway to revise the logging/output from the JVM in JDK 9 (see JEP-158). If that framework was used for the SIGQUIT threaddumps, then it would be possible to configure the output to go to a file instead of tty. Using that would be my preferred solution to this problem. However, it is unlikely that this framework will be backported to JDK 8, so perhaps a different solution is needed there. /Staffan On 15 apr 2014, at 09:45, Jaromir Hamala wrote: > Hi David, > > I mean a response to SIGQUIT. I'd like to add an ability to specify a > file/directory where threaddumps will be written to even when stdout/err > are not redirected. I believe having separated threadumps from rest of the > logs might be useful when troubleshooting. It's actually not my idea - > there was a user asking how to do it in other mailing-list. > > Cheers, > Jaromir > > > On Tue, Apr 15, 2014 at 7:21 AM, David Holmes wrote: > >> Hi Jaromir, >> >> >> On 11/04/2014 11:34 PM, Jaromir Hamala wrote: >> >>> I'd like to create a patch allowing to change a location of a threaddump >>> when it's triggered by sending a signal. My understanding is that >>> currently >>> there is no option to specify a custom path. >>> >> >> Do you mean the thread-dump in response to SIGQUIT (which goes to the VM's >> output stream) or the hs-err log file produced when the VM crashes? >> >> The SIGQUIT thread-dump doesn't go to a file unless you happen to be >> redirecting VM output to a file. >> >> David >> >> >> Is this a feature you would consider to accept & eventually merge? I'm >>> aware one could use eg. jstack to save the threaddump into an arbitrary >>> location, but this tooling is not always available as it's part of JDK and >>> not JRE. >>> >>> Cheers, >>> Jaromir >>> >>> > > > -- > ?Perfection is achieved, not when there is nothing more to add, but when > there is nothing left to take away.? > Antoine de Saint Exup?ry From david.holmes at oracle.com Tue Apr 15 09:42:04 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Apr 2014 19:42:04 +1000 Subject: Change thread dump location? In-Reply-To: References: <534CCFE9.8090208@oracle.com> Message-ID: <534CFEEC.5060802@oracle.com> On 15/04/2014 7:36 PM, Staffan Larsen wrote: > I think this is a valid use-case and it would be good to fix it. > > Having said that, there is currently work underway to revise the logging/output from the JVM in JDK 9 (see JEP-158). If that framework was used for the SIGQUIT threaddumps, then it would be possible to configure the output to go to a file instead of tty. Using that would be my preferred solution to this problem. Agreed. > However, it is unlikely that this framework will be backported to JDK 8, so perhaps a different solution is needed there. I'm not convinced this is worthwhile enough to add yet-another-vm-option to specify the output file. David > /Staffan > > On 15 apr 2014, at 09:45, Jaromir Hamala wrote: > >> Hi David, >> >> I mean a response to SIGQUIT. I'd like to add an ability to specify a >> file/directory where threaddumps will be written to even when stdout/err >> are not redirected. I believe having separated threadumps from rest of the >> logs might be useful when troubleshooting. It's actually not my idea - >> there was a user asking how to do it in other mailing-list. >> >> Cheers, >> Jaromir >> >> >> On Tue, Apr 15, 2014 at 7:21 AM, David Holmes wrote: >> >>> Hi Jaromir, >>> >>> >>> On 11/04/2014 11:34 PM, Jaromir Hamala wrote: >>> >>>> I'd like to create a patch allowing to change a location of a threaddump >>>> when it's triggered by sending a signal. My understanding is that >>>> currently >>>> there is no option to specify a custom path. >>>> >>> >>> Do you mean the thread-dump in response to SIGQUIT (which goes to the VM's >>> output stream) or the hs-err log file produced when the VM crashes? >>> >>> The SIGQUIT thread-dump doesn't go to a file unless you happen to be >>> redirecting VM output to a file. >>> >>> David >>> >>> >>> Is this a feature you would consider to accept & eventually merge? I'm >>>> aware one could use eg. jstack to save the threaddump into an arbitrary >>>> location, but this tooling is not always available as it's part of JDK and >>>> not JRE. >>>> >>>> Cheers, >>>> Jaromir >>>> >>>> >> >> >> -- >> ?Perfection is achieved, not when there is nothing more to add, but when >> there is nothing left to take away.? >> Antoine de Saint Exup?ry > From igor.veresov at oracle.com Tue Apr 15 16:43:09 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 15 Apr 2014 09:43:09 -0700 Subject: [8u20] RFR(M): 8038297: Avoid placing CTI immediately following cbcond instruction on T4 In-Reply-To: <534CC634.3080609@oracle.com> References: <76A9A7C1-64B9-4677-8181-70941F1834CD@oracle.com> <534CC634.3080609@oracle.com> Message-ID: <00431C52-5BFC-4173-9679-8CE45407242A@oracle.com> Thanks Vladimir and Chris! igor On Apr 14, 2014, at 10:40 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 4/14/14 8:51 PM, Igor Veresov wrote: >> I?d like to backport JDK-8038297. Nightlies seem to be fine and the patch applies cleanly. >> >> Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c86f5b83df67 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8038297 >> Webrev: http://cr.openjdk.java.net/~iveresov/8038297/webrev.01/ >> >> >> Thanks! >> igor >> From lev.priima at oracle.com Wed Apr 16 11:58:46 2014 From: lev.priima at oracle.com (Lev Priima) Date: Wed, 16 Apr 2014 15:58:46 +0400 Subject: [9] RFR (XS): 8039260: c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean, String... ) must also take test.java.opts In-Reply-To: <5347D5F8.4060800@oracle.com> References: <5347D5F8.4060800@oracle.com> Message-ID: <534E7076.5050604@oracle.com> adding other aliases explicitly Lev On 04/11/2014 03:46 PM, Lev Priima wrote: > Hi all, > > Please review small patch: > > http://cr.openjdk.java.net/~iignatyev/lpriima/8039260/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8039260 > 6 lines changed: 0 ins; 3 del; 3 mod; > > Problem: > method c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean > addTestVmOptions, String... command) starts "java" launcher without > passing to it "test.java.opts" received from jtreg harness. > > Fix: > Add both "test.vm.opts" and "test.java.opts" to newly created java > process by new parameter name "addTestVmAndJavaOptions" > > Testing: jprt default set + all hotspot regression tests > From jaromir.hamala at gmail.com Wed Apr 16 15:54:05 2014 From: jaromir.hamala at gmail.com (Jaromir Hamala) Date: Wed, 16 Apr 2014 16:54:05 +0100 Subject: Change thread dump location? In-Reply-To: <534CFEEC.5060802@oracle.com> References: <534CCFE9.8090208@oracle.com> <534CFEEC.5060802@oracle.com> Message-ID: Hi, On Tue, Apr 15, 2014 at 10:42 AM, David Holmes wrote: > On 15/04/2014 7:36 PM, Staffan Larsen wrote: > >> I think this is a valid use-case and it would be good to fix it. >> >> Having said that, there is currently work underway to revise the >> logging/output from the JVM in JDK 9 (see JEP-158). If that framework was >> used for the SIGQUIT threaddumps, then it would be possible to configure >> the output to go to a file instead of tty. Using that would be my preferred >> solution to this problem. >> > > Agreed. > > > However, it is unlikely that this framework will be backported to JDK 8, >> so perhaps a different solution is needed there. >> > > I'm not convinced this is worthwhile enough to add yet-another-vm-option > to specify the output file. What is an alternative to JVM option? Cheers, Jaromir > > David > > > /Staffan >> >> On 15 apr 2014, at 09:45, Jaromir Hamala >> wrote: >> >> Hi David, >>> >>> I mean a response to SIGQUIT. I'd like to add an ability to specify a >>> file/directory where threaddumps will be written to even when stdout/err >>> are not redirected. I believe having separated threadumps from rest of >>> the >>> logs might be useful when troubleshooting. It's actually not my idea - >>> there was a user asking how to do it in other mailing-list. >>> >>> Cheers, >>> Jaromir >>> >>> >>> On Tue, Apr 15, 2014 at 7:21 AM, David Holmes >>> wrote: >>> >>> Hi Jaromir, >>>> >>>> >>>> On 11/04/2014 11:34 PM, Jaromir Hamala wrote: >>>> >>>> I'd like to create a patch allowing to change a location of a >>>>> threaddump >>>>> when it's triggered by sending a signal. My understanding is that >>>>> currently >>>>> there is no option to specify a custom path. >>>>> >>>>> >>>> Do you mean the thread-dump in response to SIGQUIT (which goes to the >>>> VM's >>>> output stream) or the hs-err log file produced when the VM crashes? >>>> >>>> The SIGQUIT thread-dump doesn't go to a file unless you happen to be >>>> redirecting VM output to a file. >>>> >>>> David >>>> >>>> >>>> Is this a feature you would consider to accept & eventually merge? I'm >>>> >>>>> aware one could use eg. jstack to save the threaddump into an arbitrary >>>>> location, but this tooling is not always available as it's part of JDK >>>>> and >>>>> not JRE. >>>>> >>>>> Cheers, >>>>> Jaromir >>>>> >>>>> >>>>> >>> >>> -- >>> ?Perfection is achieved, not when there is nothing more to add, but when >>> there is nothing left to take away.? >>> Antoine de Saint Exup?ry >>> >> >> -- ?Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.? Antoine de Saint Exup?ry From vladimir.kozlov at oracle.com Wed Apr 16 18:01:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Apr 2014 11:01:01 -0700 Subject: [9] RFR (XS): 8039260: c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean, String... ) must also take test.java.opts In-Reply-To: <534E7076.5050604@oracle.com> References: <5347D5F8.4060800@oracle.com> <534E7076.5050604@oracle.com> Message-ID: <534EC55D.6080604@oracle.com> Looks good to me. Thanks, Vladimir On 4/16/14 4:58 AM, Lev Priima wrote: > adding other aliases explicitly > > Lev > > On 04/11/2014 03:46 PM, Lev Priima wrote: >> Hi all, >> >> Please review small patch: >> >> http://cr.openjdk.java.net/~iignatyev/lpriima/8039260/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8039260 >> 6 lines changed: 0 ins; 3 del; 3 mod; >> >> Problem: >> method c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean >> addTestVmOptions, String... command) starts "java" launcher without >> passing to it "test.java.opts" received from jtreg harness. >> >> Fix: >> Add both "test.vm.opts" and "test.java.opts" to newly created java >> process by new parameter name "addTestVmAndJavaOptions" >> >> Testing: jprt default set + all hotspot regression tests >> > From vladimir.kozlov at oracle.com Wed Apr 16 22:50:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Apr 2014 15:50:38 -0700 Subject: [8u20] RFR (XS) 8039050: Crash in C2 compiler at Node::rematerialize Message-ID: <534F093E.5020906@oracle.com> 8u20 backport request. These changes were pushed into jdk9 yesterday and nightly testing shows no problems. I will wait one more night and push it tomorrow morning if approved. Changes from jdk9 applied to 8u without conflicts. http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/218bc7e588be https://bugs.openjdk.java.net/browse/JDK-8039050 Thanks, Vladimir From igor.veresov at oracle.com Wed Apr 16 23:15:08 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Apr 2014 16:15:08 -0700 Subject: [8u20] RFR (XS) 8039050: Crash in C2 compiler at Node::rematerialize In-Reply-To: <534F093E.5020906@oracle.com> References: <534F093E.5020906@oracle.com> Message-ID: <37A07145-DE5C-4BD4-AB84-E46864327A30@oracle.com> Looks fine. igor On Apr 16, 2014, at 3:50 PM, Vladimir Kozlov wrote: > 8u20 backport request. These changes were pushed into jdk9 yesterday and nightly testing shows no problems. I will wait one more night and push it tomorrow morning if approved. > > Changes from jdk9 applied to 8u without conflicts. > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/218bc7e588be > https://bugs.openjdk.java.net/browse/JDK-8039050 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Apr 16 23:16:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Apr 2014 16:16:10 -0700 Subject: [8u20] RFR (XS) 8039050: Crash in C2 compiler at Node::rematerialize In-Reply-To: <37A07145-DE5C-4BD4-AB84-E46864327A30@oracle.com> References: <534F093E.5020906@oracle.com> <37A07145-DE5C-4BD4-AB84-E46864327A30@oracle.com> Message-ID: <534F0F3A.1070603@oracle.com> Thanks you, Igor Vladimir On 4/16/14 4:15 PM, Igor Veresov wrote: > Looks fine. > > igor > > On Apr 16, 2014, at 3:50 PM, Vladimir Kozlov wrote: > >> 8u20 backport request. These changes were pushed into jdk9 yesterday and nightly testing shows no problems. I will wait one more night and push it tomorrow morning if approved. >> >> Changes from jdk9 applied to 8u without conflicts. >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/218bc7e588be >> https://bugs.openjdk.java.net/browse/JDK-8039050 >> >> Thanks, >> Vladimir > From david.holmes at oracle.com Thu Apr 17 01:18:02 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Apr 2014 11:18:02 +1000 Subject: Change thread dump location? In-Reply-To: References: <534CCFE9.8090208@oracle.com> <534CFEEC.5060802@oracle.com> Message-ID: <534F2BCA.7080004@oracle.com> On 17/04/2014 1:54 AM, Jaromir Hamala wrote: > Hi, > > > On Tue, Apr 15, 2014 at 10:42 AM, David Holmes > wrote: > > On 15/04/2014 7:36 PM, Staffan Larsen wrote: > > I think this is a valid use-case and it would be good to fix it. > > Having said that, there is currently work underway to revise the > logging/output from the JVM in JDK 9 (see JEP-158). If that > framework was used for the SIGQUIT threaddumps, then it would be > possible to configure the output to go to a file instead of tty. > Using that would be my preferred solution to this problem. > > > Agreed. > > > However, it is unlikely that this framework will be backported > to JDK 8, so perhaps a different solution is needed there. > > > I'm not convinced this is worthwhile enough to add > yet-another-vm-option to specify the output file. > > What is an alternative to JVM option? There isn't one. Basically I don't think this feature is needed enough to warrant this change. Can't tools like jconsole/VisualVM be attached to the process before sending the dump request, so you can trap it there? David > Cheers, > Jaromir > > > > David > > > /Staffan > > On 15 apr 2014, at 09:45, Jaromir Hamala > > wrote: > > Hi David, > > I mean a response to SIGQUIT. I'd like to add an ability to > specify a > file/directory where threaddumps will be written to even > when stdout/err > are not redirected. I believe having separated threadumps > from rest of the > logs might be useful when troubleshooting. It's actually not > my idea - > there was a user asking how to do it in other mailing-list. > > Cheers, > Jaromir > > > On Tue, Apr 15, 2014 at 7:21 AM, David Holmes > >__wrote: > > Hi Jaromir, > > > On 11/04/2014 11:34 PM, Jaromir Hamala wrote: > > I'd like to create a patch allowing to change a > location of a threaddump > when it's triggered by sending a signal. My > understanding is that > currently > there is no option to specify a custom path. > > > Do you mean the thread-dump in response to SIGQUIT > (which goes to the VM's > output stream) or the hs-err log file produced when the > VM crashes? > > The SIGQUIT thread-dump doesn't go to a file unless you > happen to be > redirecting VM output to a file. > > David > > > Is this a feature you would consider to accept & > eventually merge? I'm > > aware one could use eg. jstack to save the > threaddump into an arbitrary > location, but this tooling is not always available > as it's part of JDK and > not JRE. > > Cheers, > Jaromir > > > > > -- > ?Perfection is achieved, not when there is nothing more to > add, but when > there is nothing left to take away.? > Antoine de Saint Exup?ry > > > > > > -- > ?Perfection is achieved, not when there is nothing more to add, but when > there is nothing left to take away.? > Antoine de Saint Exup?ry From frederic.parain at oracle.com Thu Apr 17 07:56:38 2014 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 17 Apr 2014 09:56:38 +0200 Subject: Change thread dump location? In-Reply-To: <534F2BCA.7080004@oracle.com> References: <534CCFE9.8090208@oracle.com> <534CFEEC.5060802@oracle.com> <534F2BCA.7080004@oracle.com> Message-ID: <534F8936.4040601@oracle.com> On 04/17/2014 03:18 AM, David Holmes wrote: > On 17/04/2014 1:54 AM, Jaromir Hamala wrote: >> Hi, >> >> >> On Tue, Apr 15, 2014 at 10:42 AM, David Holmes > > wrote: >> >> On 15/04/2014 7:36 PM, Staffan Larsen wrote: >> >> I think this is a valid use-case and it would be good to fix it. >> >> Having said that, there is currently work underway to revise the >> logging/output from the JVM in JDK 9 (see JEP-158). If that >> framework was used for the SIGQUIT threaddumps, then it would be >> possible to configure the output to go to a file instead of tty. >> Using that would be my preferred solution to this problem. >> >> >> Agreed. >> >> >> However, it is unlikely that this framework will be backported >> to JDK 8, so perhaps a different solution is needed there. >> >> >> I'm not convinced this is worthwhile enough to add >> yet-another-vm-option to specify the output file. >> >> What is an alternative to JVM option? > > There isn't one. Basically I don't think this feature is needed enough > to warrant this change. > > Can't tools like jconsole/VisualVM be attached to the process before > sending the dump request, so you can trap it there? Could jcmd be useful in this case? $jcmd Thread.print jcmd is shipped with JDKs (not JREs) but you can use the jcmd binary on a JRE VM. The command above prints a thread dump on the standard output of the jcmd process (not on the output of the VM process). Hope this help. Fred >> Cheers, >> Jaromir >> >> >> >> David >> >> >> /Staffan >> >> On 15 apr 2014, at 09:45, Jaromir Hamala >> > >> wrote: >> >> Hi David, >> >> I mean a response to SIGQUIT. I'd like to add an ability to >> specify a >> file/directory where threaddumps will be written to even >> when stdout/err >> are not redirected. I believe having separated threadumps >> from rest of the >> logs might be useful when troubleshooting. It's actually not >> my idea - >> there was a user asking how to do it in other mailing-list. >> >> Cheers, >> Jaromir >> >> >> On Tue, Apr 15, 2014 at 7:21 AM, David Holmes >> > >__wrote: >> >> Hi Jaromir, >> >> >> On 11/04/2014 11:34 PM, Jaromir Hamala wrote: >> >> I'd like to create a patch allowing to change a >> location of a threaddump >> when it's triggered by sending a signal. My >> understanding is that >> currently >> there is no option to specify a custom path. >> >> >> Do you mean the thread-dump in response to SIGQUIT >> (which goes to the VM's >> output stream) or the hs-err log file produced when the >> VM crashes? >> >> The SIGQUIT thread-dump doesn't go to a file unless you >> happen to be >> redirecting VM output to a file. >> >> David >> >> >> Is this a feature you would consider to accept & >> eventually merge? I'm >> >> aware one could use eg. jstack to save the >> threaddump into an arbitrary >> location, but this tooling is not always available >> as it's part of JDK and >> not JRE. >> >> Cheers, >> Jaromir >> >> >> >> >> -- >> ?Perfection is achieved, not when there is nothing more to >> add, but when >> there is nothing left to take away.? >> Antoine de Saint Exup?ry >> >> >> >> >> >> -- >> ?Perfection is achieved, not when there is nothing more to add, but when >> there is nothing left to take away.? >> Antoine de Saint Exup?ry -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From thomas.stuefe at gmail.com Thu Apr 17 08:38:35 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Apr 2014 10:38:35 +0200 Subject: Questions about java heap allocation and memory management Message-ID: Hi everyone, I have some questions about the allocation of the java heap. The reason for these questions is that we are working at our (SAP JVM) AIX port and right now we are thinking of reimplementing our java heap allocation. This would then find its way into the OpenJDK AIX port. Our initial implementation was very different from the way all other platforms implement the heap allocation, due to some AIX specialities. This difference between our code base and the OpenJDK hurts us continuously, so now we are looking for a way to reimplement it closer to the OpenJDK. For that I am investigating other platform implementations, especially some corner cases I do not understand. My questions: 1) Large page mode with compressed oops, Windows and Linux: - when large pages are active on Linux, sysV shm is used with the SHM_HUGETLB flag. (ignoring for now the -XX:+UseHugeTLBFS mode). - large pages on windows are implemented using VirtualAlloc() with MEM_LARGE_PAGES - Now, if compressed oops mode is active and we run in heap based mode (high address range), we attempt to protect the heap base zone (that first page needed for implicit nullchecks, ReservedSpace::no_access_prefix). My question is, does this combination work and get tested in reality? On Windows, VirtualProtect() will not work on large pages - at least it does not work on my machine. On Linux, I do not know for certain, but Posix states that mprotect can only be used on mmap'ed memory. 2) os::split_reserved_memory() At various places in the heap allocation ReservedSpace objects are split into two entities; os::split_reserved_memory() is called. I guess this is to deal with cases where the memory is one entity, e.g. VirtualAlloc() on windows and sysV shared mem on Unix? As opposed to mmap(), which can be released page-wise. On Unix platforms, this is a noop. I guess the assumption is that the memory was allocated by mmap(), so not splitting is needed. But what happens if the original memory was allocated using sys V shm, e.g. via os::reserve_memory_special()? In that case the first ReservedSpace would quietly inherit the ownership of the whole area, including the second ReservedSpace, and release both halves. On Windows, this function releases the whole memory and re-allocates it in the same address space in two chunks. This sounds dangerous, because someone else in the process may allocate concurrently and populate that address space. Am I overlooking something, does the code deal with this somehow? Thanks a lot! Kind Regards, Thomas From volker.simonis at gmail.com Thu Apr 17 10:16:37 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 17 Apr 2014 12:16:37 +0200 Subject: AArch64 in JDK 9? In-Reply-To: <534C2283.2010108@redhat.com> References: <534C2283.2010108@redhat.com> Message-ID: Hi Andrew, I'd highly welcome your port in the main HotSpot tree! Unfortunately I'm not the decision maker here, but I can try to outline the steps we took to bring in our port and cc some people (Iris, Azeem) who may know how to help. - First of all we were told to and finally filed a JEP for the integration project (in our case it was JEP 175: PowerPC/AIX Port - http://openjdk.java.net/jeps/175). I think the main reason why this is necessary is that such a project requires a certain amount of help from Oracle and in order to get that you'll need to get your project sponsored and funded. This all is formalized trough the JEP process. - You'll probably need to have a "staging" repository as a mirror of the current jdk9-dev forest. The staging repository will be kept in sync with its mirror and additionally collect all your porting changes as valid (i.e. in the sense of 'jcheck') and reviewed OpenJDK changesets. Once your port is completed in the staging repository, Oracle will probably want to do some bigger testing on it before the complete port will be bulk integrated into the main repositories. Notice that we actually had two staging repositories, one for jdk8 and one for jdk9. I'd suggest you start with jdk9 and once you're finished with that and depending on your wishes, you may also do the same with jdk8u. But notice that Oracle is not following the HotSpot Express model any more. This means that downporting your AArch64 port to jdk8u will get continuously harder over time, even if you manage to get into the main jdk9 repositories. - After we got the our JEP approved and funded, we created a detailed "Integration Plan" in the OpenJDK Wiki (see https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959) where we outlined the different integration steps in some more detail. I assume that you mainly only have HotSpot changes, so in one sense your integration plan will be simpler. On the other hand, bringing in HotSpot changes is the more intricate part of a port integration because you can not check in changes yourself, even if you are a committer, because of the known infrastructure problems (i.e. the need to run all the changes trough the Oracle-internal JPRT test system). There's also the problem that Oracle maintains some closed repositories (e.g. their ppc ar arm ports) in parallel to the OpenJDK repositories and changes in shared code may require modifications in their closed ports. Therefore most changes to the "staging" repository will have to be done by Oracle folks who can take care of their proprietary port as well. I'd therefore wait with the creation of a new repository as you suggested until you synchronised with some of the Oracle folks. You really need to find some good friends in the HotSpot group to get this project done:) If you have any questions or if there's anything I can do please don't hesitate to let me know. Regards, Volker On Mon, Apr 14, 2014 at 8:01 PM, Andrew Haley wrote: > We'd like to propose contributing AArch64 support to the main HotSpot > tree. SAP have already done this with PowerPC, so we hope to be able > to follow the path they took. > > The changes to HotSpot outside the cpu/ and os_cpu/ directories are > fairly minimal. There are quite a few changes we had to make to C1. > C1's patching scheme is impossible on AArch64, which (except in some > very restricted cases) does not allow the concurrent execution and > patching of code. However, we can simply #ifndef these and do our > own thing in our back end. > > We still have some performance tuning to do, and there are undoubtedly > cleanups we'd like to make. Also, there are one or two remaining big > ticket items, in particular vector support. However, the port works > well, passes all its tests, and is IMO ready for the next stage. > > To begin with I'll create a JDK9 repository which tracks JDK9 with > the minimum changes to shared code, then I guess the best thing would > be for us to discuss the changes we need on this list. > > Does that make sense? > > Thanks, > Andrew. From fweimer at redhat.com Thu Apr 17 11:11:53 2014 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 17 Apr 2014 13:11:53 +0200 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: <7781F45D-B257-4C2D-9DE6-5DA9563D30FA@oracle.com> References: <534CD269.2060900@oracle.com> <534CE15A.9030909@oracle.com> <7781F45D-B257-4C2D-9DE6-5DA9563D30FA@oracle.com> Message-ID: <534FB6F9.4010709@redhat.com> On 04/15/2014 11:25 AM, Staffan Larsen wrote: > I don?t feel comfortable reviewing the code, by I support the effort even if it is only for the interpreter. If at a later stage we can add the same information from the compilers, that would of course be good. Is there any precedent for such a difference in exception reporting between the interpreter and the compilers (beyond VM errors)? It seems a bit unusual to me, but perhaps I'm wrong. -- Florian Weimer / Red Hat Product Security Team From vladimir.kempik at oracle.com Thu Apr 17 11:47:48 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Thu, 17 Apr 2014 15:47:48 +0400 Subject: RFR: 8024677: [TESTBUG] Move tests for classes in /testlibrary Message-ID: <534FBF64.1010906@oracle.com> Hello Please review this patch. We've recently backported changes to testlibrary from jdk8 to jdk7 and now I want to bring TL tests to jdk7 as well. jdk7u-dev/jdk already has these tests, it's only hotspot that missing them. Its partially backport of 8024677, but I don't remove old files and don't edit TEST.groups as these files don't exist in jdk7/hotspot. I want to push these changes as backport of 8024677 to jdk7/hotspot, but since I've removed part of original patch (as mentioned before) I think I need to get a review. Original fix: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5b1191bf0b4b Webrev: http://cr.openjdk.java.net/~vkempik/8024677/webrev.00/ Thanks. Vladimir. From lev.priima at oracle.com Thu Apr 17 13:42:35 2014 From: lev.priima at oracle.com (Lev Priima) Date: Thu, 17 Apr 2014 17:42:35 +0400 Subject: [9] RFR (XS): 8039260: c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean, String... ) must also take test.java.opts In-Reply-To: <534EC55D.6080604@oracle.com> References: <5347D5F8.4060800@oracle.com> <534E7076.5050604@oracle.com> <534EC55D.6080604@oracle.com> Message-ID: <534FDA4B.1040306@oracle.com> Thanks, Vladimir. Igor, Could you please push it? Lev On 04/16/2014 10:01 PM, Vladimir Kozlov wrote: > Looks good to me. > > Thanks, > Vladimir > > On 4/16/14 4:58 AM, Lev Priima wrote: >> adding other aliases explicitly >> >> Lev >> >> On 04/11/2014 03:46 PM, Lev Priima wrote: >>> Hi all, >>> >>> Please review small patch: >>> >>> http://cr.openjdk.java.net/~iignatyev/lpriima/8039260/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8039260 >>> 6 lines changed: 0 ins; 3 del; 3 mod; >>> >>> Problem: >>> method c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean >>> addTestVmOptions, String... command) starts "java" launcher without >>> passing to it "test.java.opts" received from jtreg harness. >>> >>> Fix: >>> Add both "test.vm.opts" and "test.java.opts" to newly created java >>> process by new parameter name "addTestVmAndJavaOptions" >>> >>> Testing: jprt default set + all hotspot regression tests >>> >> From Tobias.Hartmann at oracle.com Thu Apr 17 14:28:22 2014 From: Tobias.Hartmann at oracle.com (Tobias Hartmann) Date: Thu, 17 Apr 2014 16:28:22 +0200 Subject: [8u20] RFR(S): JDK-8036898: assert(t != NULL) failed: must set before get Message-ID: <534FE506.2030409@oracle.com> Hi, I would like to request a 8u20 backport of my patch for JDK-8036898. The changes were pushed into jdk9 one week ago and nightly testing showed no problems. The changes applied to 8u20 without conflicts. *Master bug:* https://bugs.openjdk.java.net/browse/JDK-8036898 *Backport bug:* https://bugs.openjdk.java.net/browse/JDK-8038921 *Webrev:* http://cr.openjdk.java.net/~anoll/8036898/webrev.00/ *Changeset:* http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b9d45b765b60 Thanks, Tobias From vladimir.kozlov at oracle.com Thu Apr 17 14:44:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Apr 2014 07:44:58 -0700 Subject: [8u20] RFR(S): JDK-8036898: assert(t != NULL) failed: must set before get In-Reply-To: <534FE506.2030409@oracle.com> References: <534FE506.2030409@oracle.com> Message-ID: <534FE8EA.604@oracle.com> Looks good. Thanks, Vladimir On 4/17/14 7:28 AM, Tobias Hartmann wrote: > Hi, > > I would like to request a 8u20 backport of my patch for JDK-8036898. > > The changes were pushed into jdk9 one week ago and nightly testing showed no problems. The changes applied to 8u20 > without conflicts. > > *Master bug:* https://bugs.openjdk.java.net/browse/JDK-8036898 > *Backport bug:* https://bugs.openjdk.java.net/browse/JDK-8038921 > *Webrev:* http://cr.openjdk.java.net/~anoll/8036898/webrev.00/ > *Changeset:* http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b9d45b765b60 > > Thanks, > Tobias From Tobias.Hartmann at oracle.com Thu Apr 17 15:34:18 2014 From: Tobias.Hartmann at oracle.com (Tobias Hartmann) Date: Thu, 17 Apr 2014 17:34:18 +0200 Subject: [8u20] RFR(S): JDK-8036898: assert(t != NULL) failed: must set before get In-Reply-To: <534FE8EA.604@oracle.com> References: <534FE506.2030409@oracle.com> <534FE8EA.604@oracle.com> Message-ID: <534FF47A.8080302@oracle.com> On 04/17/2014 04:44 PM, Vladimir Kozlov wrote: > Looks good. Thanks Vladimir. Regards, Tobias > > Thanks, > Vladimir > > On 4/17/14 7:28 AM, Tobias Hartmann wrote: >> Hi, >> >> I would like to request a 8u20 backport of my patch for JDK-8036898. >> >> The changes were pushed into jdk9 one week ago and nightly testing >> showed no problems. The changes applied to 8u20 >> without conflicts. >> >> *Master bug:* https://bugs.openjdk.java.net/browse/JDK-8036898 >> *Backport bug:* https://bugs.openjdk.java.net/browse/JDK-8038921 >> *Webrev:* http://cr.openjdk.java.net/~anoll/8036898/webrev.00/ >> *Changeset:* >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b9d45b765b60 >> >> Thanks, >> Tobias From david.r.chase at oracle.com Thu Apr 17 19:32:14 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 17 Apr 2014 15:32:14 -0400 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: <534FB6F9.4010709@redhat.com> References: <534CD269.2060900@oracle.com> <534CE15A.9030909@oracle.com> <7781F45D-B257-4C2D-9DE6-5DA9563D30FA@oracle.com> <534FB6F9.4010709@redhat.com> Message-ID: <0C35DFCE-B32A-47E9-AF75-A38AAAFF3022@oracle.com> The difference in reporting sometimes happens -- I've definitely seen it with IllegalAccessError and AbstractMethodError. There's a test for 8016839 where you (may) see this in the output. David On 2014-04-17, at 7:11 AM, Florian Weimer wrote: > On 04/15/2014 11:25 AM, Staffan Larsen wrote: > >> I don?t feel comfortable reviewing the code, by I support the effort even if it is only for the interpreter. If at a later stage we can add the same information from the compilers, that would of course be good. > > Is there any precedent for such a difference in exception reporting between the interpreter and the compilers (beyond VM errors)? It seems a bit unusual to me, but perhaps I'm wrong. > > -- > Florian Weimer / Red Hat Product Security Team From david.r.chase at oracle.com Thu Apr 17 20:16:24 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 17 Apr 2014 16:16:24 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang Message-ID: BUG: recent changes to enabled warnings cause clang builds on Mavericks to fail. Format checking now complains when a non-constant string is used as a format. WEBREV: http://cr.openjdk.java.net/~drchase/8037816/webrev.00/ FIX: This patch is adapted from Gerard Ziemski?s patch for XCode5 on Mavericks. It seemed to me that the "right" way to do this was not to disable the checking with pragmas that we had just enabled on the command line, but rather to correct the problems as much as possible. I attempted to even enhance the checking by decorating some internal printf-like methods with the format-printf attribute, but was not able to deal with the spew of errors from newer versions of gcc. I did, however, manage to get it clean on Mavericks with those attributes enabled, so the problem has been reduced to dealing with one compiler's warnings. The patch includes four sorts of changes: (1) printf-like functions and methods that are marked as printf-like will no longer trigger complaints about their internal uses of format strings. A macro conditional on platform was introduced for this. ATTRIBUTE_PRINTF(fmt,vargs) (2) The warning can be disabled on a case-by-case basis; a family of macros conditional on platform were introduced for this. PRAGMA_FORMAT_NONLITERAL_IGNORED PRAGMA_DIAG_PUSH PRAGMA_DIAG_POP PRAGMA_FORMAT_NONLITERAL_IGNORED_EXTERNAL PRAGMA_FORMAT_NONLITERAL_IGNORED_INTERNAL The last two are for use with older versions of gcc that do not support PUSH and POP, in combination with large methods containing many formatting calls -- newer gcc compilers will get sharper checking. (3) In many cases, the best fix is to replace a call to a method expecting a format with one to a method expecting only a string. That is, replace ?print(s)? with ?print_raw(s)?. Note that when there is a single parameter this cannot possibly be a mistake. (4) Use new P2I macro to clean up some of the Linux format warnings; this was feasible for some of the printf-like internal methods that were not called too often with technically-mismatched types and format specifiers. #define P2I(p) ((intptr_t)(p)) #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR The fix is conditional for compilation on other platforms where warnings and pragmas differ. There is a potentially conflicting fix from Coleen Phillimore also in flight through the repositories; those two calls are left unchanged in this fix to avoid conflicts. Copyright changes deferred till later, because those will just inflate the size of the diffs; I have a script for fixing those quickly. NON-FIX: because recent versions of gcc also complain about incorrect integer size/signedness and pointer conversions in format strings, I had to retract the printf attribute from two frequently-called methods; that would have required an even larger and more invasive patch. I considered making this conditional on compilation with clang, but (1) without Coleen?s patch, this will fail on Mavericks+XCode 5. I can wait, and introduce a more-conditional ATTRIBUTE_PRINTF macro. and (2) until it can be checked on more than just that platform or we have a Mavericks+clang machine in the JPRT stable, the build risks being semi-broken for up-to-date Mac users with future changes. A next RFE would be to make progress towards that goal; the attributes to enable are present in two comments in header files (debug.hpp and ostream.hpp), and formatting can be cleaned up to deal with the recent-version gcc complaints. The remaining gcc warnings fall into several categories: 1) printing pointer with an integer format (fix this with P2I and macros for pointer format). 2) printing size_t with a ?wrong? format (on some platforms). 3) printing intptr_t with a ?wrong? format (on some platforms). One complication is use of archaic tools that don?t support c99; this forces the use of more cumbersome methods for specifying format strings. TESTING: Built on: MountainLion + XCode 4.6.3 Mavericks + XCode 5.1.1 Ubuntu (64-bit) + gcc 4.7 Ubuntu (64-bit) + gcc 4.8 Ubuntu (64-bit) + gcc 4.4 Solaris11-sparc+SS12u1 (mixture of open and closed builds above; Mavericks was built both open and closed). JPRT built clean for all the usual suspects Run (fastdebug) on: jtreg local Note that most of the changes are not tested because many of them involve code that is only executed with particular flags or in error cases. I hand-verified that after preprocessing, the one formatting macro inserted into ostream.cpp expanded into something sensible. On a 64-bit OS, this: indent().print(SIZE_FORMAT_XW(07)":", i); expands to indent().print("%" "07" "lx"":", i); vs the old indent().print("%07x:", i); (i is size_t, so lx is the appropriate format specifier) I also hand-checked the changes using two different ways of viewing the diffs (BBEdit diff, and webrev-new). David From vladimir.kozlov at oracle.com Thu Apr 17 21:11:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Apr 2014 14:11:27 -0700 Subject: [8u20] RFR(XS): 8038048: assert(null_obj->escape_state() == PointsToNode::NoEscape, etc) Message-ID: <5350437F.3030203@oracle.com> 8u20 backport request. These changes were pushed into jdk9 yesterday and nightly testing shows no problems. I will wait one more night and push it tomorrow if everything okay. Changes from jdk9 applied to 8u without conflicts. http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/054e88be4820 https://bugs.openjdk.java.net/browse/JDK-8038048 Thanks, Vladimir From christian.thalinger at oracle.com Thu Apr 17 22:26:47 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Apr 2014 12:26:47 -1000 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: References: Message-ID: On Apr 17, 2014, at 10:16 AM, David Chase wrote: > BUG: recent changes to enabled warnings cause clang builds on Mavericks to fail. > Format checking now complains when a non-constant string is used as a format. > > WEBREV: http://cr.openjdk.java.net/~drchase/8037816/webrev.00/ > > FIX: This patch is adapted from Gerard Ziemski?s patch for XCode5 on Mavericks. > It seemed to me that the "right" way to do this was not to disable the checking with > pragmas that we had just enabled on the command line, but rather to correct the > problems as much as possible. I attempted to even enhance the checking by > decorating some internal printf-like methods with the format-printf attribute, > but was not able to deal with the spew of errors from newer versions of gcc. > I did, however, manage to get it clean on Mavericks with those attributes enabled, > so the problem has been reduced to dealing with one compiler's warnings. > > The patch includes four sorts of changes: > > (1) printf-like functions and methods that are marked as printf-like will no longer trigger complaints about their internal uses of format strings. A macro conditional on platform was introduced for this. > ATTRIBUTE_PRINTF(fmt,vargs) > > (2) The warning can be disabled on a case-by-case basis; a family of macros conditional on platform were introduced for this. > PRAGMA_FORMAT_NONLITERAL_IGNORED > PRAGMA_DIAG_PUSH > PRAGMA_DIAG_POP > PRAGMA_FORMAT_NONLITERAL_IGNORED_EXTERNAL > PRAGMA_FORMAT_NONLITERAL_IGNORED_INTERNAL > The last two are for use with older versions of gcc that do not support PUSH and POP, in combination with large methods containing many formatting calls -- newer gcc compilers will get sharper checking. + #if defined(__clang_major__) || (__GNUC__ >= 4) && (__GNUC_MINOR__ >= 6) Do all versions of Clang support push and pop? > > (3) In many cases, the best fix is to replace a call to a method expecting a format with one to a method expecting only a string. That is, replace ?print(s)? with ?print_raw(s)?. Note that when there is a single parameter this cannot possibly be a mistake. Yes, it fixes the problem but it will be difficult to remember or know (for new people) that you should use print_raw instead. > > (4) Use new P2I macro to clean up some of the Linux format warnings; this was feasible for some of the printf-like internal methods that were not called too often with technically-mismatched types and format specifiers. > #define P2I(p) ((intptr_t)(p)) Can we please not use a macro for this? Use an inline method instead. > #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR > > The fix is conditional for compilation on other platforms where warnings and pragmas differ. > > There is a potentially conflicting fix from Coleen Phillimore also in flight through the repositories; those two calls are left unchanged in this fix to avoid conflicts. > > Copyright changes deferred till later, because those will just inflate the size of the diffs; I have a script for fixing those quickly. > > > NON-FIX: because recent versions of gcc also complain about incorrect integer size/signedness and pointer conversions in format strings, I had to retract the printf attribute from two frequently-called methods; that would have required an even larger and more invasive patch. > > I considered making this conditional on compilation with clang, but > > (1) without Coleen?s patch, this will fail on Mavericks+XCode 5. > I can wait, and introduce a more-conditional ATTRIBUTE_PRINTF macro. > > and > > (2) until it can be checked on more than just that platform or we have a Mavericks+clang machine in the JPRT stable, the build risks being semi-broken for up-to-date Mac users with future changes. > > A next RFE would be to make progress towards that goal; the attributes to enable are present in two comments in header files (debug.hpp and ostream.hpp), and formatting can be cleaned up to deal with the recent-version gcc complaints. > > The remaining gcc warnings fall into several categories: > > 1) printing pointer with an integer format (fix this with P2I and macros for pointer format). > > 2) printing size_t with a ?wrong? format (on some platforms). > > 3) printing intptr_t with a ?wrong? format (on some platforms). > > One complication is use of archaic tools that don?t support c99; this forces the use of more cumbersome methods for specifying format strings. > > TESTING: > > Built on: > MountainLion + XCode 4.6.3 > Mavericks + XCode 5.1.1 > Ubuntu (64-bit) + gcc 4.7 > Ubuntu (64-bit) + gcc 4.8 > Ubuntu (64-bit) + gcc 4.4 > Solaris11-sparc+SS12u1 > (mixture of open and closed builds above; Mavericks was built both open and closed). > > JPRT built clean for all the usual suspects > > Run (fastdebug) on: > jtreg local > > Note that most of the changes are not tested because many of them involve code that is only executed with particular flags or in error cases. I hand-verified that after preprocessing, the one formatting macro inserted into ostream.cpp expanded into something sensible. On a 64-bit OS, this: > > indent().print(SIZE_FORMAT_XW(07)":", i); > > expands to > > indent().print("%" "07" "lx"":", i); > > vs the old > > indent().print("%07x:", i); > > (i is size_t, so lx is the appropriate format specifier) > > I also hand-checked the changes using two different ways of viewing the diffs (BBEdit diff, and webrev-new). > > David > From coleen.phillimore at oracle.com Thu Apr 17 22:27:11 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Apr 2014 18:27:11 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: References: Message-ID: <5350553F.5010405@oracle.com> These PRAGMA_FORMAT_NONLITERAL_IGNORED macros are gross. I can't believe they complain if the format string is const char*. Can you replace some like the ones in metaspace.cpp at least with macros? I didn't see any others that could be replaced with macros. Overall, I think (don't take this wrong) this doesn't look as bad as I was afraid it would. Thanks, Coleen On 4/17/14, 4:16 PM, David Chase wrote: > BUG: recent changes to enabled warnings cause clang builds on Mavericks to fail. > Format checking now complains when a non-constant string is used as a format. > > WEBREV: http://cr.openjdk.java.net/~drchase/8037816/webrev.00/ > > FIX: This patch is adapted from Gerard Ziemski?s patch for XCode5 on Mavericks. > It seemed to me that the "right" way to do this was not to disable the checking with > pragmas that we had just enabled on the command line, but rather to correct the > problems as much as possible. I attempted to even enhance the checking by > decorating some internal printf-like methods with the format-printf attribute, > but was not able to deal with the spew of errors from newer versions of gcc. > I did, however, manage to get it clean on Mavericks with those attributes enabled, > so the problem has been reduced to dealing with one compiler's warnings. > > The patch includes four sorts of changes: > > (1) printf-like functions and methods that are marked as printf-like will no longer trigger complaints about their internal uses of format strings. A macro conditional on platform was introduced for this. > ATTRIBUTE_PRINTF(fmt,vargs) > > (2) The warning can be disabled on a case-by-case basis; a family of macros conditional on platform were introduced for this. > PRAGMA_FORMAT_NONLITERAL_IGNORED > PRAGMA_DIAG_PUSH > PRAGMA_DIAG_POP > PRAGMA_FORMAT_NONLITERAL_IGNORED_EXTERNAL > PRAGMA_FORMAT_NONLITERAL_IGNORED_INTERNAL > The last two are for use with older versions of gcc that do not support PUSH and POP, in combination with large methods containing many formatting calls -- newer gcc compilers will get sharper checking. > > (3) In many cases, the best fix is to replace a call to a method expecting a format with one to a method expecting only a string. That is, replace ?print(s)? with ?print_raw(s)?. Note that when there is a single parameter this cannot possibly be a mistake. > > (4) Use new P2I macro to clean up some of the Linux format warnings; this was feasible for some of the printf-like internal methods that were not called too often with technically-mismatched types and format specifiers. > #define P2I(p) ((intptr_t)(p)) > #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR > > The fix is conditional for compilation on other platforms where warnings and pragmas differ. > > There is a potentially conflicting fix from Coleen Phillimore also in flight through the repositories; those two calls are left unchanged in this fix to avoid conflicts. > > Copyright changes deferred till later, because those will just inflate the size of the diffs; I have a script for fixing those quickly. > > > NON-FIX: because recent versions of gcc also complain about incorrect integer size/signedness and pointer conversions in format strings, I had to retract the printf attribute from two frequently-called methods; that would have required an even larger and more invasive patch. > > I considered making this conditional on compilation with clang, but > > (1) without Coleen?s patch, this will fail on Mavericks+XCode 5. > I can wait, and introduce a more-conditional ATTRIBUTE_PRINTF macro. > > and > > (2) until it can be checked on more than just that platform or we have a Mavericks+clang machine in the JPRT stable, the build risks being semi-broken for up-to-date Mac users with future changes. > > A next RFE would be to make progress towards that goal; the attributes to enable are present in two comments in header files (debug.hpp and ostream.hpp), and formatting can be cleaned up to deal with the recent-version gcc complaints. > > The remaining gcc warnings fall into several categories: > > 1) printing pointer with an integer format (fix this with P2I and macros for pointer format). > > 2) printing size_t with a ?wrong? format (on some platforms). > > 3) printing intptr_t with a ?wrong? format (on some platforms). > > One complication is use of archaic tools that don?t support c99; this forces the use of more cumbersome methods for specifying format strings. > > TESTING: > > Built on: > MountainLion + XCode 4.6.3 > Mavericks + XCode 5.1.1 > Ubuntu (64-bit) + gcc 4.7 > Ubuntu (64-bit) + gcc 4.8 > Ubuntu (64-bit) + gcc 4.4 > Solaris11-sparc+SS12u1 > (mixture of open and closed builds above; Mavericks was built both open and closed). > > JPRT built clean for all the usual suspects > > Run (fastdebug) on: > jtreg local > > Note that most of the changes are not tested because many of them involve code that is only executed with particular flags or in error cases. I hand-verified that after preprocessing, the one formatting macro inserted into ostream.cpp expanded into something sensible. On a 64-bit OS, this: > > indent().print(SIZE_FORMAT_XW(07)":", i); > > expands to > > indent().print("%" "07" "lx"":", i); > > vs the old > > indent().print("%07x:", i); > > (i is size_t, so lx is the appropriate format specifier) > > I also hand-checked the changes using two different ways of viewing the diffs (BBEdit diff, and webrev-new). > > David > From christian.thalinger at oracle.com Thu Apr 17 23:08:19 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Apr 2014 13:08:19 -1000 Subject: [8u20] RFR(XS): 8038048: assert(null_obj->escape_state() == PointsToNode::NoEscape, etc) In-Reply-To: <5350437F.3030203@oracle.com> References: <5350437F.3030203@oracle.com> Message-ID: <5895AD10-64C7-4527-B24A-E60047557620@oracle.com> Good. On Apr 17, 2014, at 11:11 AM, Vladimir Kozlov wrote: > 8u20 backport request. These changes were pushed into jdk9 yesterday and nightly testing shows no problems. I will wait one more night and push it tomorrow if everything okay. > > Changes from jdk9 applied to 8u without conflicts. > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/054e88be4820 > https://bugs.openjdk.java.net/browse/JDK-8038048 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Apr 17 23:10:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Apr 2014 16:10:00 -0700 Subject: [8u20] RFR(XS): 8038048: assert(null_obj->escape_state() == PointsToNode::NoEscape, etc) In-Reply-To: <5895AD10-64C7-4527-B24A-E60047557620@oracle.com> References: <5350437F.3030203@oracle.com> <5895AD10-64C7-4527-B24A-E60047557620@oracle.com> Message-ID: <53505F48.1030106@oracle.com> Thank you, Christian Vladimir On 4/17/14 4:08 PM, Christian Thalinger wrote: > Good. > > On Apr 17, 2014, at 11:11 AM, Vladimir Kozlov wrote: > >> 8u20 backport request. These changes were pushed into jdk9 yesterday and nightly testing shows no problems. I will wait one more night and push it tomorrow if everything okay. >> >> Changes from jdk9 applied to 8u without conflicts. >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/054e88be4820 >> https://bugs.openjdk.java.net/browse/JDK-8038048 >> >> Thanks, >> Vladimir > From david.r.chase at oracle.com Thu Apr 17 23:31:47 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 17 Apr 2014 19:31:47 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: References: Message-ID: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> On 2014-04-17, at 6:26 PM, Christian Thalinger wrote: > > + #if defined(__clang_major__) || (__GNUC__ >= 4) && (__GNUC_MINOR__ >= 6) > Do all versions of Clang support push and pop? I don't know -- what versions of clang are we likely to use? >> (3) In many cases, the best fix is to replace a call to a method expecting a format with one to a method expecting only a string. That is, replace ?print(s)? with ?print_raw(s)?. Note that when there is a single parameter this cannot possibly be a mistake. > > Yes, it fixes the problem but it will be difficult to remember or know (for new people) that you should use print_raw instead. What's the alternative? Once we get our compilers up to decent revisions, the checking will just be there, and anyone who writes print(s) will get an error. The reason I used "print_raw" was that it was already there, and it was the least-violence change to the code; no need to insert "%s", before the string, etc. "raw" makes it sound sort of unsafe, but it's the moral equivalent of puts(s). >> (4) Use new P2I macro to clean up some of the Linux format warnings; this was feasible for some of the printf-like internal methods that were not called too often with technically-mismatched types and format specifiers. >> #define P2I(p) ((intptr_t)(p)) > > Can we please not use a macro for this? Use an inline method instead. Will do. What does a top-level inline method look like? Would this do? static inline intptr_t p2i(void * p) { return (intptr_t) p; } David From david.r.chase at oracle.com Thu Apr 17 23:38:49 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 17 Apr 2014 19:38:49 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <5350553F.5010405@oracle.com> References: <5350553F.5010405@oracle.com> Message-ID: On 2014-04-17, at 6:27 PM, Coleen Phillimore wrote: > These PRAGMA_FORMAT_NONLITERAL_IGNORED macros are gross. I can't believe they complain if the format string is const char*. Can you replace some like the ones in metaspace.cpp at least with macros? i.e., #define fmt ... ? and how does Christian feel about this? I think the reason the "const char * = constant" does not fly has to do with the nature of the format checking; it happens early, before terribly much flow analysis occurs. David From christian.thalinger at oracle.com Fri Apr 18 00:01:09 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Apr 2014 14:01:09 -1000 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> Message-ID: <978D2BB8-4315-421B-9DBE-7315E215D29B@oracle.com> On Apr 17, 2014, at 1:31 PM, David Chase wrote: > > On 2014-04-17, at 6:26 PM, Christian Thalinger wrote: >> >> + #if defined(__clang_major__) || (__GNUC__ >= 4) && (__GNUC_MINOR__ >= 6) >> Do all versions of Clang support push and pop? > > I don't know -- what versions of clang are we likely to use? The most likely ones are 4.2, 5.0, and 5.1 but there is also a comment in the makefiles mentioning 3.1: # Before Clang 3.1, we had to pass the stack alignment specification directly to llvm with the help of '-mllvm' > >>> (3) In many cases, the best fix is to replace a call to a method expecting a format with one to a method expecting only a string. That is, replace ?print(s)? with ?print_raw(s)?. Note that when there is a single parameter this cannot possibly be a mistake. >> >> Yes, it fixes the problem but it will be difficult to remember or know (for new people) that you should use print_raw instead. > > What's the alternative? Once we get our compilers up to decent revisions, the checking will just be there, and > anyone who writes print(s) will get an error. Not sure. Can we make: void print_raw(const char* str) { write(str, strlen(str)); } just void print(const char* str) { write(str, strlen(str)); } ? That would help a lot, I think. > > The reason I used "print_raw" was that it was already there, and it was the least-violence change to the code; > no need to insert "%s", before the string, etc. "raw" makes it sound sort of unsafe, but it's the moral equivalent of puts(s). > > >>> (4) Use new P2I macro to clean up some of the Linux format warnings; this was feasible for some of the printf-like internal methods that were not called too often with technically-mismatched types and format specifiers. >>> #define P2I(p) ((intptr_t)(p)) >> >> Can we please not use a macro for this? Use an inline method instead. > > Will do. What does a top-level inline method look like? > Would this do? > > static inline intptr_t p2i(void * p) { return (intptr_t) p; } Yes, thanks. > > David From john.r.rose at oracle.com Fri Apr 18 00:03:21 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Apr 2014 17:03:21 -0700 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> Message-ID: <591C5784-AFBB-4B84-9CB3-6D7EB34719CA@oracle.com> On Apr 17, 2014, at 4:31 PM, David Chase wrote: >> Can we please not use a macro for this? Use an inline method instead. > > Will do. What does a top-level inline method look like? > Would this do? > > static inline intptr_t p2i(void * p) { return (intptr_t) p; } There are similar functions in globalDefinitions.hpp; see castable_address and pointer_delta. You should use them as a model. This is what you could get to: inline intptr_t p2i(const void* x) { return (intptr_t) x; } I am not enough of a C Wizard to know whether you can just repurpose castable_address, or whether it should really be "void* x" or "const void* x". You can put the definition either near castable_address and friends, or near the other defs that pertain to format hackery. ? John From david.r.chase at oracle.com Fri Apr 18 04:03:09 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 18 Apr 2014 00:03:09 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <978D2BB8-4315-421B-9DBE-7315E215D29B@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <978D2BB8-4315-421B-9DBE-7315E215D29B@oracle.com> Message-ID: On 2014-04-17, at 8:01 PM, Christian Thalinger wrote: > > On Apr 17, 2014, at 1:31 PM, David Chase wrote: > >> >> On 2014-04-17, at 6:26 PM, Christian Thalinger wrote: >>> >>> + #if defined(__clang_major__) || (__GNUC__ >= 4) && (__GNUC_MINOR__ >= 6) >>> Do all versions of Clang support push and pop? >> >> I don't know -- what versions of clang are we likely to use? > > The most likely ones are 4.2, 5.0, and 5.1 but there is also a comment in the makefiles mentioning 3.1: > > # Before Clang 3.1, we had to pass the stack alignment specification directly to llvm with the help of '-mllvm' MacPorts for the win: port search clang clang-2.9 @2.9_13 (lang) C, C++, Objective C and Objective C++ compiler clang-3.0 @3.0_12 (lang) C, C++, Objective C and Objective C++ compiler clang-3.1 @3.1_7 (lang) C, C++, Objective C and Objective C++ compiler clang-3.2 @3.2_2 (lang) C, C++, Objective C and Objective C++ compiler clang-3.3 @3.3_2 (lang) C, C++, Objective C and Objective C++ compiler clang-3.4 @3.4 (lang) C, C++, Objective C and Objective C++ compiler clang-3.5 @3.5-r205259 (lang) C, C++, Objective C and Objective C++ compiler There's mention in the online documentation of support for those pragmas with clang-3.5. Do you know what to say to splice clang into the build on Mountain Lion? Lacking guidance and/or luck, I plan to just write little test programs to see if the pragmas behave in the proper way. David From rednaxelafx at gmail.com Fri Apr 18 09:06:21 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 18 Apr 2014 02:06:21 -0700 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: <0C35DFCE-B32A-47E9-AF75-A38AAAFF3022@oracle.com> References: <534CD269.2060900@oracle.com> <534CE15A.9030909@oracle.com> <7781F45D-B257-4C2D-9DE6-5DA9563D30FA@oracle.com> <534FB6F9.4010709@redhat.com> <0C35DFCE-B32A-47E9-AF75-A38AAAFF3022@oracle.com> Message-ID: There could be quite some differences for the same exception when thrown by the interpreter and compiled code. An example is the "fast throw" feature in C2. There would be no detail message nor stack trace for "fast throw" exceptions. When I was debugging Java applications around Java-level exceptions, what I always wanted was the bytecode index of the throwing bytecode, which allows pinpointing of where something bad happened. That could easily be provided by both the interpreter and the compiled code (unless it gets into "fast throw" and you get nothing). - Kris On Thu, Apr 17, 2014 at 12:32 PM, David Chase wrote: > The difference in reporting sometimes happens -- I've definitely seen it > with IllegalAccessError and AbstractMethodError. > There's a test for 8016839 where you (may) see this in the output. > > David > > On 2014-04-17, at 7:11 AM, Florian Weimer wrote: > > > On 04/15/2014 11:25 AM, Staffan Larsen wrote: > > > >> I don?t feel comfortable reviewing the code, by I support the effort > even if it is only for the interpreter. If at a later stage we can add the > same information from the compilers, that would of course be good. > > > > Is there any precedent for such a difference in exception reporting > between the interpreter and the compilers (beyond VM errors)? It seems a > bit unusual to me, but perhaps I'm wrong. > > > > -- > > Florian Weimer / Red Hat Product Security Team > > From david.r.chase at oracle.com Fri Apr 18 17:17:55 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 18 Apr 2014 13:17:55 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <978D2BB8-4315-421B-9DBE-7315E215D29B@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <978D2BB8-4315-421B-9DBE-7315E215D29B@oracle.com> Message-ID: <943A2E86-762D-4188-A68E-D36CC86AE2CC@oracle.com> On 2014-04-17, at 8:01 PM, Christian Thalinger wrote: >>>> (3) In many cases, the best fix is to replace a call to a method expecting a format with one to a method expecting only a string. That is, replace ?print(s)? with ?print_raw(s)?. Note that when there is a single parameter this cannot possibly be a mistake. >>> >>> Yes, it fixes the problem but it will be difficult to remember or know (for new people) that you should use print_raw instead. >> >> What's the alternative? Once we get our compilers up to decent revisions, the checking will just be there, and >> anyone who writes print(s) will get an error. > > Not sure. Can we make: > > void print_raw(const char* str) { write(str, strlen(str)); } > > just > > void print(const char* str) { write(str, strlen(str)); } > > ? That would help a lot, I think. I'm planning to make (and test) the following changes, which I've run past multiple compilers already in a test program. Assuming all goes well, there will be a new webrev in a while. HOWEVER, I could not figure out how to overload two definitions of "print" when one of them is fmt + varargs and the other is just a string. I get ambiguous overloading errors like this: Test print(const char * s) overloading. test.cpp:30:3: error: call to 'my_print' is ambiguous my_print(s); ^~~~~~~~ test.cpp:12:6: note: candidate function void my_print(const char * fmt, ...) { ^ test.cpp:18:6: note: candidate function void my_print(const char * s) { ^ So unless someone has a better idea, we're stuck with print/print_raw, and it would be a good idea to run the compiler with -Wformat-security to avoid mistakes. I'm not quite clear on why gcc was not also reporting these errors already in our builds, since it is able to do so and it looked like the flag was set that enabled them. Anyone have a better idea? --------------------------- Changes to fix: Replace const char * fmt = string with #define fmt string to work around literal-minded format-checking. Test push/pop with older versions of clang (works). Add _Pragma("GCC diagnostic ignored \"-Wformat-security\"") for older clang. P2I inline method. static inline intptr_t p2i(void * p) { return (intptr_t) p; } --------------------------- From christian.thalinger at oracle.com Fri Apr 18 18:27:34 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Apr 2014 08:27:34 -1000 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <943A2E86-762D-4188-A68E-D36CC86AE2CC@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <978D2BB8-4315-421B-9DBE-7315E215D29B@oracle.com> <943A2E86-762D-4188-A68E-D36CC86AE2CC@oracle.com> Message-ID: <6A81E83E-B552-443E-8C72-3922B233C7CE@oracle.com> On Apr 18, 2014, at 7:17 AM, David Chase wrote: > > On 2014-04-17, at 8:01 PM, Christian Thalinger wrote: >>>>> (3) In many cases, the best fix is to replace a call to a method expecting a format with one to a method expecting only a string. That is, replace ?print(s)? with ?print_raw(s)?. Note that when there is a single parameter this cannot possibly be a mistake. >>>> >>>> Yes, it fixes the problem but it will be difficult to remember or know (for new people) that you should use print_raw instead. >>> >>> What's the alternative? Once we get our compilers up to decent revisions, the checking will just be there, and >>> anyone who writes print(s) will get an error. >> >> Not sure. Can we make: >> >> void print_raw(const char* str) { write(str, strlen(str)); } >> >> just >> >> void print(const char* str) { write(str, strlen(str)); } >> >> ? That would help a lot, I think. > > I'm planning to make (and test) the following changes, which I've run past multiple > compilers already in a test program. Assuming all goes well, there will be a new webrev > in a while. HOWEVER, I could not figure out how to overload two definitions of "print" > when one of them is fmt + varargs and the other is just a string. I get ambiguous overloading > errors like this: > > Test print(const char * s) overloading. > test.cpp:30:3: error: call to 'my_print' is ambiguous > my_print(s); > ^~~~~~~~ > test.cpp:12:6: note: candidate function > void my_print(const char * fmt, ...) { > ^ > test.cpp:18:6: note: candidate function > void my_print(const char * s) { > ^ That?s what I thought. Never mind then. > > So unless someone has a better idea, we're stuck with print/print_raw, and it would be > a good idea to run the compiler with -Wformat-security to avoid mistakes. I'm not quite > clear on why gcc was not also reporting these errors already in our builds, since it is > able to do so and it looked like the flag was set that enabled them. > > Anyone have a better idea? Nope. > > --------------------------- > Changes to fix: > Replace const char * fmt = string with #define fmt string to work around literal-minded format-checking. > > Test push/pop with older versions of clang (works). > > Add _Pragma("GCC diagnostic ignored \"-Wformat-security\"") for older clang. > > P2I inline method. > static inline intptr_t p2i(void * p) { return (intptr_t) p; } > > --------------------------- > From vladimir.kozlov at oracle.com Fri Apr 18 21:12:22 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Apr 2014 14:12:22 -0700 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: References: Message-ID: <53519536.8050104@oracle.com> Hi David, In general I agree with changes. So for older gcc the warning will be ignored for the rest of file or only for the following method body after pragma. Right? Why you need pragmas around outputStream::vprint_cr()? There is no pragma for vprint(). In heapInspection.hpp empty line in wring place (should be before pragma). Spacint is off (in globalDefinitions.hpp): + #ifndef ATTRIBUTE_PRINTF + #define ATTRIBUTE_PRINTF(fmt,vargs) Thanks, Vladimir On 4/17/14 1:16 PM, David Chase wrote: > BUG: recent changes to enabled warnings cause clang builds on Mavericks to fail. > Format checking now complains when a non-constant string is used as a format. > > WEBREV: http://cr.openjdk.java.net/~drchase/8037816/webrev.00/ > > FIX: This patch is adapted from Gerard Ziemski?s patch for XCode5 on Mavericks. > It seemed to me that the "right" way to do this was not to disable the checking with > pragmas that we had just enabled on the command line, but rather to correct the > problems as much as possible. I attempted to even enhance the checking by > decorating some internal printf-like methods with the format-printf attribute, > but was not able to deal with the spew of errors from newer versions of gcc. > I did, however, manage to get it clean on Mavericks with those attributes enabled, > so the problem has been reduced to dealing with one compiler's warnings. > > The patch includes four sorts of changes: > > (1) printf-like functions and methods that are marked as printf-like will no longer trigger complaints about their internal uses of format strings. A macro conditional on platform was introduced for this. > ATTRIBUTE_PRINTF(fmt,vargs) > > (2) The warning can be disabled on a case-by-case basis; a family of macros conditional on platform were introduced for this. > PRAGMA_FORMAT_NONLITERAL_IGNORED > PRAGMA_DIAG_PUSH > PRAGMA_DIAG_POP > PRAGMA_FORMAT_NONLITERAL_IGNORED_EXTERNAL > PRAGMA_FORMAT_NONLITERAL_IGNORED_INTERNAL > The last two are for use with older versions of gcc that do not support PUSH and POP, in combination with large methods containing many formatting calls -- newer gcc compilers will get sharper checking. > > (3) In many cases, the best fix is to replace a call to a method expecting a format with one to a method expecting only a string. That is, replace ?print(s)? with ?print_raw(s)?. Note that when there is a single parameter this cannot possibly be a mistake. > > (4) Use new P2I macro to clean up some of the Linux format warnings; this was feasible for some of the printf-like internal methods that were not called too often with technically-mismatched types and format specifiers. > #define P2I(p) ((intptr_t)(p)) > #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR > > The fix is conditional for compilation on other platforms where warnings and pragmas differ. > > There is a potentially conflicting fix from Coleen Phillimore also in flight through the repositories; those two calls are left unchanged in this fix to avoid conflicts. > > Copyright changes deferred till later, because those will just inflate the size of the diffs; I have a script for fixing those quickly. > > > NON-FIX: because recent versions of gcc also complain about incorrect integer size/signedness and pointer conversions in format strings, I had to retract the printf attribute from two frequently-called methods; that would have required an even larger and more invasive patch. > > I considered making this conditional on compilation with clang, but > > (1) without Coleen?s patch, this will fail on Mavericks+XCode 5. > I can wait, and introduce a more-conditional ATTRIBUTE_PRINTF macro. > > and > > (2) until it can be checked on more than just that platform or we have a Mavericks+clang machine in the JPRT stable, the build risks being semi-broken for up-to-date Mac users with future changes. > > A next RFE would be to make progress towards that goal; the attributes to enable are present in two comments in header files (debug.hpp and ostream.hpp), and formatting can be cleaned up to deal with the recent-version gcc complaints. > > The remaining gcc warnings fall into several categories: > > 1) printing pointer with an integer format (fix this with P2I and macros for pointer format). > > 2) printing size_t with a ?wrong? format (on some platforms). > > 3) printing intptr_t with a ?wrong? format (on some platforms). > > One complication is use of archaic tools that don?t support c99; this forces the use of more cumbersome methods for specifying format strings. > > TESTING: > > Built on: > MountainLion + XCode 4.6.3 > Mavericks + XCode 5.1.1 > Ubuntu (64-bit) + gcc 4.7 > Ubuntu (64-bit) + gcc 4.8 > Ubuntu (64-bit) + gcc 4.4 > Solaris11-sparc+SS12u1 > (mixture of open and closed builds above; Mavericks was built both open and closed). > > JPRT built clean for all the usual suspects > > Run (fastdebug) on: > jtreg local > > Note that most of the changes are not tested because many of them involve code that is only executed with particular flags or in error cases. I hand-verified that after preprocessing, the one formatting macro inserted into ostream.cpp expanded into something sensible. On a 64-bit OS, this: > > indent().print(SIZE_FORMAT_XW(07)":", i); > > expands to > > indent().print("%" "07" "lx"":", i); > > vs the old > > indent().print("%07x:", i); > > (i is size_t, so lx is the appropriate format specifier) > > I also hand-checked the changes using two different ways of viewing the diffs (BBEdit diff, and webrev-new). > > David > From John.Coomes at oracle.com Sat Apr 19 00:50:50 2014 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 18 Apr 2014 17:50:50 -0700 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <5345E28F.5050108@oracle.com> References: <5345E28F.5050108@oracle.com> Message-ID: <21329.51306.466788.318656@mykonos.us.oracle.com> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: > > Please review this change to make the hotspot related output produced by > "java -version" > match the corresponding JDK output: > > webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 > > Note that we initially wanted to obtain more information from the repo > being built and add > it to the hotspot version output, but that will require changes in the > JPRT, so > we have decided to split the change in 2 bugs. One to make the version match > (above webrev) and another one, an RFE, to add additional information > extracted from the repo. Generally looks good, but I agree with David that the long lines should be wrapped, and it might even be clearer to separate them into two variables, e.g., JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \ -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \ ... other defs ... VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \ -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \ $(JDK_VERSION_DEFS) Also the change to this part of vm.make differs between at least the solaris version and the linux version (didn't check bsd or windows). Please make them all consistent. > Note that in the current version of vm_version.cpp, there is no error > checking in product mode, > I was suggested to make that explicit. I like the additional error checking. I think you could eliminate the 4 copies of similar code with a function that does the checks and sets the field, e.g., void set_version_field(int * version_field, const char * version_str, const char * const assert_msg) { if (version_str != NULL ...) { DEBUG_ONLY(assert_digits(version_str, assert_msg)); *version_field = atoi(version_str); } } -John From aph at redhat.com Sat Apr 19 08:17:13 2014 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Apr 2014 09:17:13 +0100 Subject: AArch64 in JDK 9? In-Reply-To: References: <534C2283.2010108@redhat.com> Message-ID: <53523109.7040002@redhat.com> Hi, On 04/17/2014 11:16 AM, Volker Simonis wrote: > > I'd highly welcome your port in the main HotSpot tree! > > Unfortunately I'm not the decision maker here, but I can try to > outline the steps we took to bring in our port and cc some people > (Iris, Azeem) who may know how to help. > > - First of all we were told to and finally filed a JEP for the > integration project (in our case it was JEP 175: PowerPC/AIX Port - > http://openjdk.java.net/jeps/175). I think the main reason why this is > necessary is that such a project requires a certain amount of help > from Oracle and in order to get that you'll need to get your project > sponsored and funded. This all is formalized trough the JEP process. OK. > - You'll probably need to have a "staging" repository as a mirror of > the current jdk9-dev forest. The staging repository will be kept in > sync with its mirror and additionally collect all your porting changes > as valid (i.e. in the sense of 'jcheck') and reviewed OpenJDK > changesets. Sure, I was planning to do that anyway. There is one thing I don't understand how to do, though. jcheck wants bug IDs for all changes, right? So does that mean that you have to create bug IDs when you create the staging repository? > Once your port is completed in the staging repository, Oracle will > probably want to do some bigger testing on it before the complete > port will be bulk integrated into the main repositories. Notice > that we actually had two staging repositories, one for jdk8 and one > for jdk9. I'd suggest you start with jdk9 and once you're finished > with that and depending on your wishes, you may also do the same > with jdk8u. But notice that Oracle is not following the HotSpot > Express model any more. This means that downporting your AArch64 > port to jdk8u will get continuously harder over time, even if you > manage to get into the main jdk9 repositories. > > - After we got the our JEP approved and funded, we created a detailed > "Integration Plan" in the OpenJDK Wiki (see > https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959) > where we outlined the different integration steps in some more detail. > I assume that you mainly only have HotSpot changes, so in one sense > your integration plan will be simpler. On the other hand, bringing in > HotSpot changes is the more intricate part of a port integration > because you can not check in changes yourself, even if you are a > committer, because of the known infrastructure problems (i.e. the need > to run all the changes trough the Oracle-internal JPRT test system). Right. > There's also the problem that Oracle maintains some closed > repositories (e.g. their ppc ar arm ports) in parallel to the > OpenJDK repositories and changes in shared code may require > modifications in their closed ports. Therefore most changes to the > "staging" repository will have to be done by Oracle folks who can > take care of their proprietary port as well. Sure, I get that. I'll have to go over our code changes to see if anything affects non-AArch64 ports. > I'd therefore wait with the creation of a new repository as you > suggested until you synchronised with some of the Oracle folks. You > really need to find some good friends in the HotSpot group to get this > project done:) Well, yes. And this is going to get more common, I hope, so we need to establish a smooth pathway to help people get ports in. One interesting challenge here is that there really isn't much AArch64 hardware around for other people to test on, but I hope that it will be common enough later in the year. > If you have any questions or if there's anything I can do please don't > hesitate to let me know. OK, I'll remember that. Thanks, Andrew. From vladimir.kozlov at oracle.com Sat Apr 19 19:23:15 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 19 Apr 2014 12:23:15 -0700 Subject: AArch64 in JDK 9? In-Reply-To: <53523109.7040002@redhat.com> References: <534C2283.2010108@redhat.com> <53523109.7040002@redhat.com> Message-ID: <5352CD23.5050700@oracle.com> On 4/19/14 1:17 AM, Andrew Haley wrote: > Hi, > > On 04/17/2014 11:16 AM, Volker Simonis wrote: >> >> I'd highly welcome your port in the main HotSpot tree! >> >> Unfortunately I'm not the decision maker here, but I can try to >> outline the steps we took to bring in our port and cc some people >> (Iris, Azeem) who may know how to help. >> >> - First of all we were told to and finally filed a JEP for the >> integration project (in our case it was JEP 175: PowerPC/AIX Port - >> http://openjdk.java.net/jeps/175). I think the main reason why this is >> necessary is that such a project requires a certain amount of help >> from Oracle and in order to get that you'll need to get your project >> sponsored and funded. This all is formalized trough the JEP process. > > OK. Yes, until JEP is funded we can do nothing from Oracle side. It could take time based on ppc-aix port experience. >> - You'll probably need to have a "staging" repository as a mirror of >> the current jdk9-dev forest. The staging repository will be kept in >> sync with its mirror and additionally collect all your porting changes >> as valid (i.e. in the sense of 'jcheck') and reviewed OpenJDK >> changesets. > > Sure, I was planning to do that anyway. There is one thing I don't > understand how to do, though. jcheck wants bug IDs for all changes, > right? So does that mean that you have to create bug IDs when you > create the staging repository? Staging repository is created by cloning jdk9-dev forest. After that any changeset which will be pushed into that repo have to have a valid changeset descriptor/comment: http://openjdk.java.net/guide/producingChangeset.html You have to file a separate bug in JBS for each patch, preferable with "AArch64:" prefix in bug's subject. Here is what we had for first ppc64 changes: https://bugs.openjdk.java.net/browse/JDK-8016476 https://bugs.openjdk.java.net/browse/JDK-8016491 It also helped a lot with ppc-aix port when SAP prepared list of all patches they wanted to push so we could preview them and estimate needed efforts during JEP review: http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/ It was also important to break the port into separate small/medium patches for easy review and testing. Regards, Vladimir > >> Once your port is completed in the staging repository, Oracle will >> probably want to do some bigger testing on it before the complete >> port will be bulk integrated into the main repositories. Notice >> that we actually had two staging repositories, one for jdk8 and one >> for jdk9. I'd suggest you start with jdk9 and once you're finished >> with that and depending on your wishes, you may also do the same >> with jdk8u. But notice that Oracle is not following the HotSpot >> Express model any more. This means that downporting your AArch64 >> port to jdk8u will get continuously harder over time, even if you >> manage to get into the main jdk9 repositories. >> >> - After we got the our JEP approved and funded, we created a detailed >> "Integration Plan" in the OpenJDK Wiki (see >> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959) >> where we outlined the different integration steps in some more detail. >> I assume that you mainly only have HotSpot changes, so in one sense >> your integration plan will be simpler. On the other hand, bringing in >> HotSpot changes is the more intricate part of a port integration >> because you can not check in changes yourself, even if you are a >> committer, because of the known infrastructure problems (i.e. the need >> to run all the changes trough the Oracle-internal JPRT test system). > > Right. > >> There's also the problem that Oracle maintains some closed >> repositories (e.g. their ppc ar arm ports) in parallel to the >> OpenJDK repositories and changes in shared code may require >> modifications in their closed ports. Therefore most changes to the >> "staging" repository will have to be done by Oracle folks who can >> take care of their proprietary port as well. > > Sure, I get that. I'll have to go over our code changes to see if > anything affects non-AArch64 ports. > >> I'd therefore wait with the creation of a new repository as you >> suggested until you synchronised with some of the Oracle folks. You >> really need to find some good friends in the HotSpot group to get this >> project done:) > > Well, yes. And this is going to get more common, I hope, so we need > to establish a smooth pathway to help people get ports in. > > One interesting challenge here is that there really isn't much AArch64 > hardware around for other people to test on, but I hope that it will > be common enough later in the year. > >> If you have any questions or if there's anything I can do please don't >> hesitate to let me know. > > OK, I'll remember that. > > Thanks, > Andrew. > From vladimir.kozlov at oracle.com Sat Apr 19 19:30:12 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 19 Apr 2014 12:30:12 -0700 Subject: AArch64 in JDK 9? In-Reply-To: <5352CD23.5050700@oracle.com> References: <534C2283.2010108@redhat.com> <53523109.7040002@redhat.com> <5352CD23.5050700@oracle.com> Message-ID: <5352CEC4.7080500@oracle.com> On 4/19/14 12:23 PM, Vladimir Kozlov wrote: > On 4/19/14 1:17 AM, Andrew Haley wrote: >> Hi, >> >> On 04/17/2014 11:16 AM, Volker Simonis wrote: >>> >>> I'd highly welcome your port in the main HotSpot tree! >>> >>> Unfortunately I'm not the decision maker here, but I can try to >>> outline the steps we took to bring in our port and cc some people >>> (Iris, Azeem) who may know how to help. >>> >>> - First of all we were told to and finally filed a JEP for the >>> integration project (in our case it was JEP 175: PowerPC/AIX Port - >>> http://openjdk.java.net/jeps/175). I think the main reason why this is >>> necessary is that such a project requires a certain amount of help >>> from Oracle and in order to get that you'll need to get your project >>> sponsored and funded. This all is formalized trough the JEP process. >> >> OK. > > Yes, until JEP is funded we can do nothing from Oracle side. It could take time based on ppc-aix port experience. > >>> - You'll probably need to have a "staging" repository as a mirror of >>> the current jdk9-dev forest. The staging repository will be kept in >>> sync with its mirror and additionally collect all your porting changes >>> as valid (i.e. in the sense of 'jcheck') and reviewed OpenJDK >>> changesets. >> >> Sure, I was planning to do that anyway. There is one thing I don't >> understand how to do, though. jcheck wants bug IDs for all changes, >> right? So does that mean that you have to create bug IDs when you >> create the staging repository? It may be was not clear but the official staging repo is created by Oracle because the forest should contain closed repository. And it is created after JEP is approved/funded. You can have your own staging repo for your patches preparation and testing. But you will have to manage it yourself. Regards, Vladimir > > Staging repository is created by cloning jdk9-dev forest. After that any changeset which will be pushed into that repo > have to have a valid changeset descriptor/comment: > > http://openjdk.java.net/guide/producingChangeset.html > > You have to file a separate bug in JBS for each patch, preferable with "AArch64:" prefix in bug's subject. Here is what > we had for first ppc64 changes: > > https://bugs.openjdk.java.net/browse/JDK-8016476 > https://bugs.openjdk.java.net/browse/JDK-8016491 > > It also helped a lot with ppc-aix port when SAP prepared list of all patches they wanted to push so we could preview > them and estimate needed efforts during JEP review: > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/ > > It was also important to break the port into separate small/medium patches for easy review and testing. > > Regards, > Vladimir > >> >>> Once your port is completed in the staging repository, Oracle will >>> probably want to do some bigger testing on it before the complete >>> port will be bulk integrated into the main repositories. Notice >>> that we actually had two staging repositories, one for jdk8 and one >>> for jdk9. I'd suggest you start with jdk9 and once you're finished >>> with that and depending on your wishes, you may also do the same >>> with jdk8u. But notice that Oracle is not following the HotSpot >>> Express model any more. This means that downporting your AArch64 >>> port to jdk8u will get continuously harder over time, even if you >>> manage to get into the main jdk9 repositories. >>> >>> - After we got the our JEP approved and funded, we created a detailed >>> "Integration Plan" in the OpenJDK Wiki (see >>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959) >>> where we outlined the different integration steps in some more detail. >>> I assume that you mainly only have HotSpot changes, so in one sense >>> your integration plan will be simpler. On the other hand, bringing in >>> HotSpot changes is the more intricate part of a port integration >>> because you can not check in changes yourself, even if you are a >>> committer, because of the known infrastructure problems (i.e. the need >>> to run all the changes trough the Oracle-internal JPRT test system). >> >> Right. >> >>> There's also the problem that Oracle maintains some closed >>> repositories (e.g. their ppc ar arm ports) in parallel to the >>> OpenJDK repositories and changes in shared code may require >>> modifications in their closed ports. Therefore most changes to the >>> "staging" repository will have to be done by Oracle folks who can >>> take care of their proprietary port as well. >> >> Sure, I get that. I'll have to go over our code changes to see if >> anything affects non-AArch64 ports. >> >>> I'd therefore wait with the creation of a new repository as you >>> suggested until you synchronised with some of the Oracle folks. You >>> really need to find some good friends in the HotSpot group to get this >>> project done:) >> >> Well, yes. And this is going to get more common, I hope, so we need >> to establish a smooth pathway to help people get ports in. >> >> One interesting challenge here is that there really isn't much AArch64 >> hardware around for other people to test on, but I hope that it will >> be common enough later in the year. >> >>> If you have any questions or if there's anything I can do please don't >>> hesitate to let me know. >> >> OK, I'll remember that. >> >> Thanks, >> Andrew. >> From omajid at redhat.com Mon Apr 21 15:19:56 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 21 Apr 2014 11:19:56 -0400 Subject: Undefined behaviour in hotspot Message-ID: <20140421151956.GB2422@redhat.com> Hi, I recently tried to build OpenJDK on i686 using a prerelease version of GCC 4.9. It turns out that new optimizations have been enabled in GCC which now cause hotspot to break in a few places where hotspot relies on undefined behaviour. $ uname -a Linux rawhide 3.15.0-0.rc1.git1.1.fc21.i686+PAE #1 SMP Tue Apr 15 14:40:42 UTC 2014 i686 i686 i386 GNU/Linux $ gcc --version gcc (GCC) 4.9.0 20140411 (Red Hat 4.9.0-0.10) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. A `java -version` is sufficient to trigger a crash: $ ./build/images/j2sdk-image/bin/java -version # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xb637a10e, pid=1014, tid=3053837120 # # JRE version: (8.0_05-b13) (build ) # Java VM: OpenJDK Server VM (25.5-b02-fastdebug mixed mode linux-x86 ) # Problematic frame: # V [libjvm.so+0x31c10e] Assembler::push(RegisterImpl*)+0x4e # # Failed to write core dump. 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: # /home/omajid/java-1.8.0-openjdk/hs_err_pid1014.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The above report is from jdk8u5b13 (also, [1]), but this is reproducible on jdk8-b132 [2] and jdk7u [3] as well. Following the advice posted here [4], I built OpenJDK8 with "-fsanitize=undefined" which pointed out: /home/omajid/java-1.8.0-openjdk/java-1.8.0-openjdk/jdk8/hotspot/src/share/vm/code/relocInfo.hpp:855:24: runtime error: load of null pointer of type ' *' /home/omajid/java-1.8.0-openjdk/java-1.8.0-openjdk/jdk8/hotspot/src/share/vm/asm/codeBuffer.hpp:181:51: runtime error: member access within null pointer of type 'struct CodeSection' ==15676==ERROR: SanitizerTool failed to allocate 0x200000 (2097152) bytes of SizeClassAllocator32: 12 ==15676==Process memory map follows: 0x00100000-0x00200000 (snip) 0xbff8f000-0xbffb0000 [stack] ==15676==End of process memory map. ==15676==Sanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_posix.cc:66 (("unable to mmap" && 0)) != (0) (0, 0) I ran through the code with gdb. Please ignore the java-abrt executable name: on Fedora, jre/bin/java-abrt is the original jre/bin/java and jre/bin/java is a shell script that runs jre/bin/java-abrt with additional options. (gdb) r -version Starting program: /home/omajid/java-1.8.0-openjdk/java-1.8.0-openjdk/jdk8/build/jdk8.build/images/j2sdk-image/jre/bin/java-abrt -version [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". [New Thread 0xb689bb40 (LWP 15144)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb689bb40 (LWP 15144)] 0xb6bb810e in Assembler::push (this=0xb689ae14, src=0x0) at /home/omajid/java-1.8.0-openjdk/java-1.8.0-openjdk/jdk8/hotspot/src/cpu/x86/vm/assembler_x86.cpp:2580 2580 emit_int8(0x50 | encode); (gdb) l 2575 } 2576 2577 void Assembler::push(Register src) { 2578 int encode = prefix_and_encode(src->encoding()); 2579 2580 emit_int8(0x50 | encode); 2581 } 2582 2583 void Assembler::pushf() { 2584 emit_int8((unsigned char)0x9C); (gdb) p encode $1 = (gdb) p src $2 = (Register) 0x0 Dereferencing a NULL pointer is undefined behaviour in C++ [5] and it seems perfectly acceptable for a compiler to compile hotspot in a way so that it ends up not working. If I disable optimizations done by the compiler (using slowdebug), then the built copy of hotspot works correctly. Both fastdebug and release (which keep compiler optimizations enabled) result in builds that crash when run. Obviously, I would like to get hotspot to work correctly when compiled against GCC 4.9. But I believe the micro-optimizations made to use the address of the object instead of using a field in the object is to save space and I would rather not blindly undo it. Does anyone here have any advice on what the best course of action there is? Thanks, Omair [1] http://kojipkgs.fedoraproject.org//work/tasks/4320/6744320/build.log [2] http://kojipkgs.fedoraproject.org//work/tasks/6501/6746501/build.log [3] http://kojipkgs.fedoraproject.org//work/tasks/5509/6755509/build.log [4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197741.html [5] http://stackoverflow.com/questions/2474018/ -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.r.chase at oracle.com Mon Apr 21 15:29:18 2014 From: david.r.chase at oracle.com (David Chase) Date: Mon, 21 Apr 2014 11:29:18 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <53519536.8050104@oracle.com> References: <53519536.8050104@oracle.com> Message-ID: <2A6454F4-D158-4027-B24D-98CECCBF47E2@oracle.com> On 2014-04-18, at 5:12 PM, Vladimir Kozlov wrote: > Hi David, > > In general I agree with changes. > > So for older gcc the warning will be ignored for the rest of file or only for the following method body after pragma. Right? This is correct, though unfortunate. (Right now, we're ignoring it all the time for all the files). > Why you need pragmas around outputStream::vprint_cr()? There is no pragma for vprint(). I am not 100% sure. I will check this. (I.e, I will remove this and test it to see if anything breaks). > In heapInspection.hpp empty line in wring place (should be before pragma). > > Spacint is off (in globalDefinitions.hpp): > + #ifndef ATTRIBUTE_PRINTF > + #define ATTRIBUTE_PRINTF(fmt,vargs) I'll get these. As you surely know from the compiler chat (but non-compiler-team might not) there is more to come. The rough estimate of what's coming: 1) printf-attribute annotation of all our printf-like methods, enabled for clang >= 3.1 and gcc >= 4.2. 2) 275 files touched, 121 of those with a more-work-needed-for-picky-gcc pragma macro. 3) 6700 line patch file. Here's my notes on what's coming, which is still being tested and needs a round of porting to non-x86 gcc platforms, both of which should take at least till late Tuesday. Changes to fix: Decorated several more printf-like internal routines with ATTRIBUTE_PRINTF(x,y) Left ATTRIBUTE_PRINTF(x,y) enabled for all clang and gcc compilations. (This causes substantial amounts of noise, but ensures that there shall be no backsliding on these improvements in the future.) Added some additional format-string macros to allow repair of some of our formats. The intent for all changes was to not modify the output at all unless it was almost certainly correct (e.g., printing a default case for unknown constant type with a %f format, or printing a known-integer with %s). #define UINT64_FORMAT_X "%" PRIx64 #define PTR_FORMAT_W(width) "%" #width PRIxPTR #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR #define SIZE_FORMAT_X "%" PRIxPTR At least two very-recently-fixed bugs were detected in this automated sweep, and I see quite a few cases of could-be-a-bug but lacked the time to construct a test case to prove it, so I just fixed it as the warning specified. Replace const char * fmt = string with #define fmt string to work around literal-minded format-checking. Rename two occurrences of ?fmt? to be different, more descriptive, less likely to clash. Test push/pop with older versions of clang (works, as far as 3.1). Add _Pragma("GCC diagnostic ignored \"-Wformat-security\"") to check-disabling macro for older clang. P2I inline method, not macro. static inline intptr_t p2i(void * p) { return (intptr_t) p; } Tested print(const char * s) overloading. test.cpp:30:3: error: call to 'my_print' is ambiguous my_print(s); ^~~~~~~~ test.cpp:12:6: note: candidate function void my_print(const char * fmt, ...) { ^ test.cpp:18:6: note: candidate function void my_print(const char * s) { ^ Instead, add print_cr() for the most common use. Constructors taking format and args are unfortunately forced to take (?%s?, ??) for an empty string. To tone down gcc?s hypersensitivity to format mismatches, add a use of this macro after header inclusions for source files whose format strings cannot be easily and surely corrected (e.g., through addition of p2i() not too often): #define PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC _Pragma("GCC diagnostic ignored \"-Wformat\"") _Pragma("GCC diagnostic error \"-Wformat-nonliteral\"") _Pragma("GCC diagnostic error \"-Wformat-security\"") Use of this macros does not silence warnings for nonliteral, non-constant, empty, or mismatched arg length parameter strings. For two files, src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp the macro ATTRIBUTE_PRINTF(x,y) is defined to be empty above the header inclusions; the format strings are wrong in peculiar ways, and they are buried in macros. David From david.r.chase at oracle.com Mon Apr 21 15:52:55 2014 From: david.r.chase at oracle.com (David Chase) Date: Mon, 21 Apr 2014 11:52:55 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: <20140421151956.GB2422@redhat.com> References: <20140421151956.GB2422@redhat.com> Message-ID: <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> On 2014-04-21, at 11:19 AM, Omair Majid wrote: > I recently tried to build OpenJDK on i686 using a prerelease version of GCC > 4.9. It turns out that new optimizations have been enabled in GCC which now > cause hotspot to break in a few places where hotspot relies on undefined > behaviour. > ... > Dereferencing a NULL pointer is undefined behaviour in C++ [5] and it seems > perfectly acceptable for a compiler to compile hotspot in a way so that it ends > up not working. > Obviously, I would like to get hotspot to work correctly when compiled against > GCC 4.9. But I believe the micro-optimizations made to use the address of the > object instead of using a field in the object is to save space and I would > rather not blindly undo it. Does anyone here have any advice on what the best > course of action there is? Is there a chance that (because you work for redhat) you might have some influence over the gcc implementers, and get them to implement/document a flag or pragma that will cause it to cut that crap out? I've seen discussions of other "it's undefined, ha-ha, let's party!" optimizations that make overflow detection impossible, e.g.: if (buf + len < buf) { // check for address space wraparound and overflow return EINVAL; } is optimized to if ( len < 0) { return EINVAL; } and if (a > 0 && b > 0) { sum = (a + b) if (sum < a) { // detect integer overflow ... } } becomes if (a > 0 && b > 0) { sum = (a + b) } We used to joke about doing this kind of thing back when I worked on optimizing C/C++ compilers, but we always assumed that we could never get away with it because saving a few nanoseconds is not as important as the checks in the two examples above. Which is to say, the modeled execution speed of code that I can't run because I don't trust it is zero, so it's not really an optimization. Just because we can get hotspot to run on correct inputs without crashing doesn't mean that we haven't accidentally disabled security-critical checking by using this hyperactive optimizer. I would think that this is even more important now than it was 20 years ago. So, step one is to locate all the places where undefined behavior occurs, and then we have to figure out what to do next, but we can't do anything without knowing the full scope of the problem. David From omajid at redhat.com Mon Apr 21 16:17:48 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 21 Apr 2014 12:17:48 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> Message-ID: <20140421161748.GD2422@redhat.com> * David Chase [2014-04-21 11:53]: > > On 2014-04-21, at 11:19 AM, Omair Majid wrote: > > I recently tried to build OpenJDK on i686 using a prerelease version of GCC > > 4.9. It turns out that new optimizations have been enabled in GCC which now > > cause hotspot to break in a few places where hotspot relies on undefined > > behaviour. > > ... > > Dereferencing a NULL pointer is undefined behaviour in C++ [5] and it seems > > perfectly acceptable for a compiler to compile hotspot in a way so that it ends > > up not working. > > > > Obviously, I would like to get hotspot to work correctly when compiled against > > GCC 4.9. But I believe the micro-optimizations made to use the address of the > > object instead of using a field in the object is to save space and I would > > rather not blindly undo it. Does anyone here have any advice on what the best > > course of action there is? > > Is there a chance that (because you work for redhat) you might have > some influence over the gcc implementers, and get them to > implement/document a flag or pragma that will cause it to cut that > crap out? I can ping them, but honestly, I wouldn't be surprised at all if the only response I get is "no". I don't have any official communication channels with them, so my input is not any different from anyone else's. Can you elaborate on what flag/pragma you have in mind? Just something to play nice with NULL pointers? > So, step one is to locate all the places where undefined behavior > occurs, and then we have to figure out what to do next, but we can't > do anything without knowing the full scope of the problem. Static analysis tools would come in handy here: - gcc's -fsanitize=address|thread|undefined - clang static analyzer - cppcheck - coverity Should I start running whatever tools I can get my hands on and gathering results? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From alejandro.murillo at oracle.com Mon Apr 21 17:13:05 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 21 Apr 2014 11:13:05 -0600 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <21329.51306.466788.318656@mykonos.us.oracle.com> References: <5345E28F.5050108@oracle.com> <21329.51306.466788.318656@mykonos.us.oracle.com> Message-ID: <535551A1.2080601@oracle.com> On 4/18/2014 6:50 PM, John Coomes wrote: > Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: >> Please review this change to make the hotspot related output produced by >> "java -version" >> match the corresponding JDK output: >> >> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 >> >> Note that we initially wanted to obtain more information from the repo >> being built and add >> it to the hotspot version output, but that will require changes in the >> JPRT, so >> we have decided to split the change in 2 bugs. One to make the version match >> (above webrev) and another one, an RFE, to add additional information >> extracted from the repo. > Generally looks good, but I agree with David that the long lines > should be wrapped, and it might even be clearer to separate them into > two variables, e.g., > > JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \ > -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \ > ... other defs ... > VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \ > -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \ > $(JDK_VERSION_DEFS) > > Also the change to this part of vm.make differs between at least the > solaris version and the linux version (didn't check bsd or windows). > Please make them all consistent. > >> Note that in the current version of vm_version.cpp, there is no error >> checking in product mode, >> I was suggested to make that explicit. > I like the additional error checking. I think you could eliminate the > 4 copies of similar code with a function that does the checks and sets > the field, e.g., > > void set_version_field(int * version_field, const char * version_str, > const char * const assert_msg) { > if (version_str != NULL ...) { > DEBUG_ONLY(assert_digits(version_str, assert_msg)); > *version_field = atoi(version_str); > } > } > > -John Thanks John, working on adding these changes and sanity testing Thanks -- Alejandro From david.r.chase at oracle.com Mon Apr 21 17:53:13 2014 From: david.r.chase at oracle.com (David Chase) Date: Mon, 21 Apr 2014 13:53:13 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: <20140421161748.GD2422@redhat.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> Message-ID: <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> On 2014-04-21, at 12:17 PM, Omair Majid wrote: > I can ping them, but honestly, I wouldn't be surprised at all if the > only response I get is "no". I don't have any official communication > channels with them, so my input is not any different from anyone else's. > > Can you elaborate on what flag/pragma you have in mind? Just something > to play nice with NULL pointers? Not just null pointers. Also optimizations that pretend that integer overflow doesn't happen (i.e., optimizations that change program behavior when it does) also need to be disabled. >> So, step one is to locate all the places where undefined behavior >> occurs, and then we have to figure out what to do next, but we can't >> do anything without knowing the full scope of the problem. > > Static analysis tools would come in handy here: > - gcc's -fsanitize=address|thread|undefined > - clang static analyzer > - cppcheck > - coverity > > Should I start running whatever tools I can get my hands on and > gathering results? It would be interesting and probably useful. I don't recommend going after printf formats quite yet, since I'm trying to clean those up right now (and you would be horrified). David From omajid at redhat.com Mon Apr 21 18:30:56 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 21 Apr 2014 14:30:56 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> Message-ID: <20140421183055.GE2422@redhat.com> * David Chase [2014-04-21 13:53]: > > On 2014-04-21, at 12:17 PM, Omair Majid wrote: > > I can ping them, but honestly, I wouldn't be surprised at all if the > > only response I get is "no". I don't have any official communication > > channels with them, so my input is not any different from anyone else's. > > > > Can you elaborate on what flag/pragma you have in mind? Just something > > to play nice with NULL pointers? > > Not just null pointers. Also optimizations that pretend that integer overflow > doesn't happen (i.e., optimizations that change program behavior when it > does) also need to be disabled. My knowledge of C/C++ is fairly limited, so please bear with me. There are a few relevant options already listed in 'man gcc': -Wstrict-overflow=n This option is only active when -fstrict-overflow is active. It warns about cases where the compiler optimizes based on the assumption that signed overflow does not occur -fwrapv This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. Do you mean others? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From vladimir.kozlov at oracle.com Mon Apr 21 19:18:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Apr 2014 12:18:36 -0700 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <535551A1.2080601@oracle.com> References: <5345E28F.5050108@oracle.com> <21329.51306.466788.318656@mykonos.us.oracle.com> <535551A1.2080601@oracle.com> Message-ID: <53556F0C.3010305@oracle.com> Hi Alejandro, I don't think we need to rename make/hotspot_version file. It is still used to set JVM's version string and not JDK's version. Next should be 2014 (I think David pointed it too but there is no new webrev): HOTSPOT_VM_COPYRIGHT=Copyright 2013 If you pass major, micro etc numbers to avoid parsing you need to verify that constructed from them string is equal to passed HOTSPOT_RELEASE_VERSION. Next assert message is not consistent with previous messages which use "vm", I think it should be "vm" here too: DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build number")); Abstract_VM_Version::jvm_version() should include micro version. See JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in jdk/src/share/javavm/export/jvm.h. Use corresponding test in jdk for testing of these changes: jdk/test/sun/misc/Version/Version.java jvm.h: Next comment is not accurate: + /* VM version string: JDK version string */ If we build VM separately (for example, in JPRT) VM version will not be JDK version in which VM is installed. It will take numbers either from passed make parameters or from make/hotspot_version. I think it should say: + /* VM version string follows the JDK release version naming convention + * ..-bxx[-][-] Based on your examples [-][-] is still used so it should be reflected in the comment. Don't remove next comments from vm_version.cpp but fix it ("follow the JDK release"): -// HOTSPOT_RELEASE_VERSION must follow the release version naming convention -// .-b[-][-] You did not show default VM version example when VM is built locally by engineer. Please test that correct version string is constructed when you build VM using make/build.sh, for example 'sh make/build.sh debug LP64=1' Next comment change in buildtree.make is not correct because HOTSPOT_RELEASE_VERSION make parameter does not include HOTSPOT_BUILD_VERSION: -# HOTSPOT_RELEASE_VERSION - .-b (11.0-b07) +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus HOTSPOT_BUILD_VERSION see JPRT logs where HOTSPOT_BUILD_VERSION is set separately. I think next change in make/defs.make is not safe (removing make parameter) due to complexity of our builds: -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION) I know that windows build is mess. Please verify it carefully. For example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but build.make uses them: JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER) Regards, Vladimir On 4/21/14 10:13 AM, Alejandro E Murillo wrote: > > On 4/18/2014 6:50 PM, John Coomes wrote: >> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: >>> Please review this change to make the hotspot related output produced by >>> "java -version" >>> match the corresponding JDK output: >>> >>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 >>> >>> Note that we initially wanted to obtain more information from the repo >>> being built and add >>> it to the hotspot version output, but that will require changes in the >>> JPRT, so >>> we have decided to split the change in 2 bugs. One to make the >>> version match >>> (above webrev) and another one, an RFE, to add additional information >>> extracted from the repo. >> Generally looks good, but I agree with David that the long lines >> should be wrapped, and it might even be clearer to separate them into >> two variables, e.g., >> >> JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \ >> -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \ >> ... other defs ... >> VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \ >> -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \ >> $(JDK_VERSION_DEFS) >> >> Also the change to this part of vm.make differs between at least the >> solaris version and the linux version (didn't check bsd or windows). >> Please make them all consistent. >> >>> Note that in the current version of vm_version.cpp, there is no error >>> checking in product mode, >>> I was suggested to make that explicit. >> I like the additional error checking. I think you could eliminate the >> 4 copies of similar code with a function that does the checks and sets >> the field, e.g., >> >> void set_version_field(int * version_field, const char * >> version_str, >> const char * const assert_msg) { >> if (version_str != NULL ...) { >> DEBUG_ONLY(assert_digits(version_str, assert_msg)); >> *version_field = atoi(version_str); >> } >> } >> >> -John > Thanks John, > working on adding these changes and sanity testing > > Thanks > From david.holmes at oracle.com Tue Apr 22 01:57:49 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Apr 2014 11:57:49 +1000 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> Message-ID: <5355CC9D.3090609@oracle.com> On 18/04/2014 9:31 AM, David Chase wrote: > > On 2014-04-17, at 6:26 PM, Christian Thalinger wrote: >> >> + #if defined(__clang_major__) || (__GNUC__ >= 4) && (__GNUC_MINOR__ >= 6) >> Do all versions of Clang support push and pop? > > I don't know -- what versions of clang are we likely to use? > >>> (3) In many cases, the best fix is to replace a call to a method expecting a format with one to a method expecting only a string. That is, replace ?print(s)? with ?print_raw(s)?. Note that when there is a single parameter this cannot possibly be a mistake. >> >> Yes, it fixes the problem but it will be difficult to remember or know (for new people) that you should use print_raw instead. > > What's the alternative? Once we get our compilers up to decent revisions, the checking will just be there, and > anyone who writes print(s) will get an error. > > The reason I used "print_raw" was that it was already there, and it was the least-violence change to the code; > no need to insert "%s", before the string, etc. "raw" makes it sound sort of unsafe, but it's the moral equivalent of puts(s). Sorry but I much prefer putting the %s before the string and keeping a nice clean simple API. I don't know the history of the existing raw usage but this broad change looks very ugly to me - and given you had to change the call-sites anyway, it seems the addition of "%s" is the more correct fix. Cheers, David H. > >>> (4) Use new P2I macro to clean up some of the Linux format warnings; this was feasible for some of the printf-like internal methods that were not called too often with technically-mismatched types and format specifiers. >>> #define P2I(p) ((intptr_t)(p)) >> >> Can we please not use a macro for this? Use an inline method instead. > > Will do. What does a top-level inline method look like? > Would this do? > > static inline intptr_t p2i(void * p) { return (intptr_t) p; } > > David > From fweimer at redhat.com Tue Apr 22 07:42:13 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 22 Apr 2014 09:42:13 +0200 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: <0C35DFCE-B32A-47E9-AF75-A38AAAFF3022@oracle.com> References: <534CD269.2060900@oracle.com> <534CE15A.9030909@oracle.com> <7781F45D-B257-4C2D-9DE6-5DA9563D30FA@oracle.com> <534FB6F9.4010709@redhat.com> <0C35DFCE-B32A-47E9-AF75-A38AAAFF3022@oracle.com> Message-ID: <53561D55.4090209@redhat.com> On 04/17/2014 09:32 PM, David Chase wrote: > The difference in reporting sometimes happens -- I've definitely seen it with IllegalAccessError and AbstractMethodError. > There's a test for 8016839 where you (may) see this in the output. Ah, you are right, I would have considered those VM errors as well, but technically, they are not. -- Florian Weimer / Red Hat Product Security Team From mikael.gerdin at oracle.com Tue Apr 22 08:31:37 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 22 Apr 2014 10:31:37 +0200 Subject: Undefined behaviour in hotspot In-Reply-To: <20140421151956.GB2422@redhat.com> References: <20140421151956.GB2422@redhat.com> Message-ID: <1797376.pEA2155MG7@mgerdin03> Hi Omair, On Monday 21 April 2014 11.19.56 Omair Majid wrote: > Hi, > > I recently tried to build OpenJDK on i686 using a prerelease version of GCC > 4.9. It turns out that new optimizations have been enabled in GCC which now > cause hotspot to break in a few places where hotspot relies on undefined > behaviour. > > $ uname -a > Linux rawhide 3.15.0-0.rc1.git1.1.fc21.i686+PAE #1 SMP Tue Apr 15 14:40:42 > UTC 2014 i686 i686 i386 GNU/Linux > > $ gcc --version > gcc (GCC) 4.9.0 20140411 (Red Hat 4.9.0-0.10) > Copyright (C) 2014 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > A `java -version` is sufficient to trigger a crash: > > $ ./build/images/j2sdk-image/bin/java -version > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0xb637a10e, pid=1014, tid=3053837120 > # > # JRE version: (8.0_05-b13) (build ) > # Java VM: OpenJDK Server VM (25.5-b02-fastdebug mixed mode linux-x86 ) > # Problematic frame: > # V [libjvm.so+0x31c10e] Assembler::push(RegisterImpl*)+0x4e > # > # Failed to write core dump. 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: > # /home/omajid/java-1.8.0-openjdk/hs_err_pid1014.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > > The above report is from jdk8u5b13 (also, [1]), but this is reproducible on > jdk8-b132 [2] and jdk7u [3] as well. > > Following the advice posted here [4], I built OpenJDK8 with > "-fsanitize=undefined" which pointed out: > > /home/omajid/java-1.8.0-openjdk/java-1.8.0-openjdk/jdk8/hotspot/src/share/vm > /code/relocInfo.hpp:855:24: runtime error: load of null pointer of type > ' *' > /home/omajid/java-1.8.0-openjdk/java-1.8.0-openjdk/jdk8/hotspot/src/share/v > m/asm/codeBuffer.hpp:181:51: runtime error: member access within null > pointer of type 'struct CodeSection' ==15676==ERROR: SanitizerTool failed > to allocate 0x200000 (2097152) bytes of SizeClassAllocator32: 12 > ==15676==Process memory map follows: > 0x00100000-0x00200000 > > (snip) > > 0xbff8f000-0xbffb0000 [stack] > ==15676==End of process memory map. > ==15676==Sanitizer CHECK failed: > ../../../../libsanitizer/sanitizer_common/sanitizer_posix.cc:66 (("unable > to mmap" && 0)) != (0) (0, 0) > > I ran through the code with gdb. Please ignore the java-abrt executable > name: on Fedora, jre/bin/java-abrt is the original jre/bin/java and > jre/bin/java is a shell script that runs jre/bin/java-abrt with additional > options. > > (gdb) r -version > Starting program: > /home/omajid/java-1.8.0-openjdk/java-1.8.0-openjdk/jdk8/build/jdk8.build/im > ages/j2sdk-image/jre/bin/java-abrt -version [Thread debugging using > libthread_db enabled] > Using host libthread_db library "/lib/libthread_db.so.1". > [New Thread 0xb689bb40 (LWP 15144)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb689bb40 (LWP 15144)] > 0xb6bb810e in Assembler::push (this=0xb689ae14, src=0x0) > at > /home/omajid/java-1.8.0-openjdk/java-1.8.0-openjdk/jdk8/hotspot/src/cpu/x86 > /vm/assembler_x86.cpp:2580 2580 emit_int8(0x50 | encode); > (gdb) l > 2575 } > 2576 > 2577 void Assembler::push(Register src) { > 2578 int encode = prefix_and_encode(src->encoding()); > 2579 > 2580 emit_int8(0x50 | encode); > 2581 } > 2582 > 2583 void Assembler::pushf() { > 2584 emit_int8((unsigned char)0x9C); > (gdb) p encode > $1 = > (gdb) p src > $2 = (Register) 0x0 > > Dereferencing a NULL pointer is undefined behaviour in C++ [5] and it seems > perfectly acceptable for a compiler to compile hotspot in a way so that it > ends up not working. A related (questionable) practice of calling member functions on null pointers is pretty common in hotspot, for example: inline bool oopDesc::is_oop_or_null(bool ignore_mark_word) const { return this == NULL ? true : is_oop(ignore_mark_word); } I think it would be a good idea to try to address as many as possible of the undefined behaviors we rely on since I believe it will significantly reduce the problems we will face in future porting and compiler version upgrade projects. /Mikael > > If I disable optimizations done by the compiler (using slowdebug), then the > built copy of hotspot works correctly. Both fastdebug and release (which > keep compiler optimizations enabled) result in builds that crash when run. > > Obviously, I would like to get hotspot to work correctly when compiled > against GCC 4.9. But I believe the micro-optimizations made to use the > address of the object instead of using a field in the object is to save > space and I would rather not blindly undo it. Does anyone here have any > advice on what the best course of action there is? > > Thanks, > Omair > > [1] http://kojipkgs.fedoraproject.org//work/tasks/4320/6744320/build.log > [2] http://kojipkgs.fedoraproject.org//work/tasks/6501/6746501/build.log > [3] http://kojipkgs.fedoraproject.org//work/tasks/5509/6755509/build.log > [4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197741.html > [5] http://stackoverflow.com/questions/2474018/ From volker.simonis at gmail.com Tue Apr 22 08:41:47 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Apr 2014 10:41:47 +0200 Subject: Undefined behaviour in hotspot In-Reply-To: <20140421183055.GE2422@redhat.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> Message-ID: Hi, I think the simplest and safest fix would be to make encoding() (and all the corresponding functions) static functions which take a Register as argument like: static int encoding(const RegisterImpl* r) { assert(is_valid(r), "invalid register"); return (intptr_t)r; } This wouldn't waste any more memory and it would be fully C++ compliant at the price of a slightly more verbose usage: 2577 void Assembler::push(Register src) { 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); 2579 And of course this would work with any compiler. What do you think? Regards, Volker On Mon, Apr 21, 2014 at 8:30 PM, Omair Majid wrote: > * David Chase [2014-04-21 13:53]: >> >> On 2014-04-21, at 12:17 PM, Omair Majid wrote: >> > I can ping them, but honestly, I wouldn't be surprised at all if the >> > only response I get is "no". I don't have any official communication >> > channels with them, so my input is not any different from anyone else's. >> > >> > Can you elaborate on what flag/pragma you have in mind? Just something >> > to play nice with NULL pointers? >> >> Not just null pointers. Also optimizations that pretend that integer overflow >> doesn't happen (i.e., optimizations that change program behavior when it >> does) also need to be disabled. > > My knowledge of C/C++ is fairly limited, so please bear with me. There > are a few relevant options already listed in 'man gcc': > > -Wstrict-overflow=n > This option is only active when -fstrict-overflow is active. > It warns about cases where the compiler optimizes based on > the assumption that signed overflow does not occur > > -fwrapv > This option instructs the compiler to assume that signed > arithmetic overflow of addition, subtraction and > multiplication wraps around using twos-complement > representation. > > Do you mean others? > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From aph at redhat.com Tue Apr 22 09:41:53 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Apr 2014 10:41:53 +0100 Subject: AArch64 in JDK 9? In-Reply-To: <5352CD23.5050700@oracle.com> References: <534C2283.2010108@redhat.com> <53523109.7040002@redhat.com> <5352CD23.5050700@oracle.com> Message-ID: <53563961.5040408@redhat.com> On 04/19/2014 08:23 PM, Vladimir Kozlov wrote: > On 4/19/14 1:17 AM, Andrew Haley wrote: >> Hi, >> >> On 04/17/2014 11:16 AM, Volker Simonis wrote: >>> >>> I'd highly welcome your port in the main HotSpot tree! >>> >>> Unfortunately I'm not the decision maker here, but I can try to >>> outline the steps we took to bring in our port and cc some people >>> (Iris, Azeem) who may know how to help. >>> >>> - First of all we were told to and finally filed a JEP for the >>> integration project (in our case it was JEP 175: PowerPC/AIX Port - >>> http://openjdk.java.net/jeps/175). I think the main reason why this is >>> necessary is that such a project requires a certain amount of help >>> from Oracle and in order to get that you'll need to get your project >>> sponsored and funded. This all is formalized trough the JEP process. >> >> OK. > > Yes, until JEP is funded we can do nothing from Oracle side. It > could take time based on ppc-aix port experience. I understand. >>> - You'll probably need to have a "staging" repository as a mirror of >>> the current jdk9-dev forest. The staging repository will be kept in >>> sync with its mirror and additionally collect all your porting changes >>> as valid (i.e. in the sense of 'jcheck') and reviewed OpenJDK >>> changesets. >> >> Sure, I was planning to do that anyway. There is one thing I don't >> understand how to do, though. jcheck wants bug IDs for all changes, >> right? So does that mean that you have to create bug IDs when you >> create the staging repository? > > Staging repository is created by cloning jdk9-dev forest. After that > any changeset which will be pushed into that repo have to have a > valid changeset descriptor/comment: > > http://openjdk.java.net/guide/producingChangeset.html > > You have to file a separate bug in JBS for each patch, preferable > with "AArch64:" prefix in bug's subject. Here is what we had for > first ppc64 changes: > > https://bugs.openjdk.java.net/browse/JDK-8016476 > https://bugs.openjdk.java.net/browse/JDK-8016491 > > It also helped a lot with ppc-aix port when SAP prepared list of all > patches they wanted to push so we could preview them and estimate > needed efforts during JEP review: > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/ > > It was also important to break the port into separate small/medium patches for easy review and testing. Right, I can now see a plan. Thanks, Andrew. From aph at redhat.com Tue Apr 22 09:42:57 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Apr 2014 10:42:57 +0100 Subject: AArch64 in JDK 9? In-Reply-To: <5352CEC4.7080500@oracle.com> References: <534C2283.2010108@redhat.com> <53523109.7040002@redhat.com> <5352CD23.5050700@oracle.com> <5352CEC4.7080500@oracle.com> Message-ID: <535639A1.2090209@redhat.com> On 04/19/2014 08:30 PM, Vladimir Kozlov wrote: > It may be was not clear but the official staging repo is created by Oracle because the forest should contain closed > repository. And it is created after JEP is approved/funded. > You can have your own staging repo for your patches preparation and testing. But you will have to manage it yourself. Err no, that was not clear. Thanks! I will write the JEP proposal. Andrew. From david.r.chase at oracle.com Tue Apr 22 12:20:17 2014 From: david.r.chase at oracle.com (David Chase) Date: Tue, 22 Apr 2014 08:20:17 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: <20140421183055.GE2422@redhat.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> Message-ID: <81C5E090-E3C8-4D21-B079-AAA7D223F1EA@oracle.com> I'm pretty sure that -Wstrict-overflow is the one that we want, and that to do this study we (we?) would compile with -Wstrict-overflow=5 -Wno-error but not -fwrapv and not -fno-strict-overflow. -Wno-error is so you'll get to see all of them. The flags are discussed here: http://www.airs.com/blog/archives/120 http://thiemonagel.de/2010/01/signed-integer-overflow/ David On 2014-04-21, at 2:30 PM, Omair Majid wrote: > My knowledge of C/C++ is fairly limited, so please bear with me. There > are a few relevant options already listed in 'man gcc': > > -Wstrict-overflow=n > This option is only active when -fstrict-overflow is active. > It warns about cases where the compiler optimizes based on > the assumption that signed overflow does not occur > > -fwrapv > This option instructs the compiler to assume that signed > arithmetic overflow of addition, subtraction and > multiplication wraps around using twos-complement > representation. > > Do you mean others? From fweimer at redhat.com Tue Apr 22 12:48:27 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 22 Apr 2014 14:48:27 +0200 Subject: Undefined behaviour in hotspot In-Reply-To: <81C5E090-E3C8-4D21-B079-AAA7D223F1EA@oracle.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <81C5E090-E3C8-4D21-B079-AAA7D223F1EA@oracle.com> Message-ID: <5356651B.6060803@redhat.com> On 04/22/2014 02:20 PM, David Chase wrote: > I'm pretty sure that -Wstrict-overflow is the one that we want, > and that to do this study we (we?) would compile with > > -Wstrict-overflow=5 -Wno-error > > but not -fwrapv and not -fno-strict-overflow. > -Wno-error is so you'll get to see all of them. Note that these options do not cover overflows/wraparounds in pointer arithmetic. -- Florian Weimer / Red Hat Product Security Team From david.r.chase at oracle.com Tue Apr 22 13:21:25 2014 From: david.r.chase at oracle.com (David Chase) Date: Tue, 22 Apr 2014 09:21:25 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: <5356651B.6060803@redhat.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <81C5E090-E3C8-4D21-B079-AAA7D223F1EA@oracle.com> <5356651B.6060803@redhat.com> Message-ID: <47520CD3-7B92-41AF-8D18-2B7D29DA4A44@oracle.com> On 2014-04-22, at 8:48 AM, Florian Weimer wrote: > On 04/22/2014 02:20 PM, David Chase wrote: >> I'm pretty sure that -Wstrict-overflow is the one that we want, >> and that to do this study we (we?) would compile with >> >> -Wstrict-overflow=5 -Wno-error >> >> but not -fwrapv and not -fno-strict-overflow. >> -Wno-error is so you'll get to see all of them. > > Note that these options do not cover overflows/wraparounds in pointer arithmetic. In what sense? Are there versions of gcc that will optimize if (ptr + len < ptr) to if (len < 0) even if we set -fno-strict-overflow or -fwrapv ? Or is it rather the case that the optimizations will never happen? David From fweimer at redhat.com Tue Apr 22 14:56:06 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 22 Apr 2014 16:56:06 +0200 Subject: Undefined behaviour in hotspot In-Reply-To: <47520CD3-7B92-41AF-8D18-2B7D29DA4A44@oracle.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <81C5E090-E3C8-4D21-B079-AAA7D223F1EA@oracle.com> <5356651B.6060803@redhat.com> <47520CD3-7B92-41AF-8D18-2B7D29DA4A44@oracle.com> Message-ID: <53568306.3020206@redhat.com> On 04/22/2014 03:21 PM, David Chase wrote: > In what sense? Are there versions of gcc that will optimize > > if (ptr + len < ptr) > > to > > if (len < 0) > > even if we set -fno-strict-overflow or -fwrapv ? It turns it into (uintptr_t) ptr + (uintptr_t) len < (uintptr_t) ptr which may or may not be what you want, depending whether you view addresses as signed or not. (I still need to check MIPS, the obvious candidates behave the indicated way.) -- Florian Weimer / Red Hat Product Security Team From omajid at redhat.com Tue Apr 22 16:34:07 2014 From: omajid at redhat.com (Omair Majid) Date: Tue, 22 Apr 2014 12:34:07 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> Message-ID: <20140422163406.GB30387@redhat.com> * Volker Simonis [2014-04-22 04:41]: > I think the simplest and safest fix would be to make encoding() (and > all the corresponding functions) static functions which take a > Register as argument like: > > static int encoding(const RegisterImpl* r) { assert(is_valid(r), > "invalid register"); return (intptr_t)r; } > > This wouldn't waste any more memory and it would be fully C++ > compliant at the price of a slightly more verbose usage: > > 2577 void Assembler::push(Register src) { > 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); > 2579 > > And of course this would work with any compiler. Are you sure about this? It seems to me that a pointer created from an int does not satisfy the conditions for a "safely-derived pointer". It has implementation defined behaviour [1]. > What do you think? That certainly works for me, but not sure for others. For the sake of safety, I would rather use a typedef for registers and a separate class with static methods to operate on the typedef. Thanks, Omair [1] http://cpp0x.centaur.ath.cx/basic.stc.dynamic.safety.html -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From volker.simonis at gmail.com Tue Apr 22 19:11:01 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Apr 2014 21:11:01 +0200 Subject: Undefined behaviour in hotspot In-Reply-To: <20140422163406.GB30387@redhat.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <20140422163406.GB30387@redhat.com> Message-ID: Hi Omair, I've downloaded and compiled a brand new version of gcc 4.9.0 (it was actually released today!) I could reproduce your problem on x86. On x86_64 there's a problem as well - the VM hangs during the initialization. Funny enough I had no problems on ppc64. A freshly compiled VM from jdk9/hs-comp ran without any problems. So this seems to be x86 related. I've further analyzed the problem you described and the good news is that it is not related to calling encoding() on a zero pointer - so hopefully no need to massively change HotSpot code. The assembly code of "Assembler::push(RegisterImpl* src)" looks as follows: 0xf6959174 <_ZN9Assembler4pushEP12RegisterImpl+20>: mov 0xc(%ebp),%esi 0xf6959177 <_ZN9Assembler4pushEP12RegisterImpl+23>: mov 0x8(%ebp),%edi 0xf695917a <_ZN9Assembler4pushEP12RegisterImpl+26>: cmp $0x7,%esi 0xf695917d <_ZN9Assembler4pushEP12RegisterImpl+29>: jbe 0xf69591a3 <_ZN9Assembler4pushEP12RegisterImpl+67> 0xf695917f <_ZN9Assembler4pushEP12RegisterImpl+31>: lea -0x3a0c4e(%ebx),%eax 0xf6959185 <_ZN9Assembler4pushEP12RegisterImpl+37>: push %eax 0xf6959186 <_ZN9Assembler4pushEP12RegisterImpl+38>: lea -0x3a0c3d(%ebx),%eax 0xf695918c <_ZN9Assembler4pushEP12RegisterImpl+44>: push %eax 0xf695918d <_ZN9Assembler4pushEP12RegisterImpl+45>: lea -0x39be48(%ebx),%eax 0xf6959193 <_ZN9Assembler4pushEP12RegisterImpl+51>: push $0x41 0xf6959195 <_ZN9Assembler4pushEP12RegisterImpl+53>: push %eax 0xf6959196 <_ZN9Assembler4pushEP12RegisterImpl+54>: call 0xf6c9b730 <_Z15report_vm_errorPKciS0_S0_> 0xf695919b <_ZN9Assembler4pushEP12RegisterImpl+59>: call 0xf72bc1c0 0xf69591a0 <_ZN9Assembler4pushEP12RegisterImpl+64>: add $0x10,%esp 0xf69591a3 <_ZN9Assembler4pushEP12RegisterImpl+67>: mov 0xc(%edi),%edx 0xf69591a6 <_ZN9Assembler4pushEP12RegisterImpl+70>: mov %esi,%eax 0xf69591a8 <_ZN9Assembler4pushEP12RegisterImpl+72>: or $0x50,%eax 0xf69591ab <_ZN9Assembler4pushEP12RegisterImpl+75>: mov 0x8(%edx),%ecx 0xf69591ae <_ZN9Assembler4pushEP12RegisterImpl+78>: mov %al,(%ecx) 'this' is loaded into register 'edi' and 'src' is loaded into register 'esi'. 'src' (i.e. 'esi') is compared against '0x7' which comes from the call to 'is_valid()'. If everything is fine, we proceed at address '0xf69591a3'. There we load the '_code_section' field with offest 0xc from the AbstractAssembler which is in register 'edi' and stroe it in register 'edx'. We OR the register encoding with '0x50' which succeeds altough the actual RegisterImpl pointer (i.e. 'src') is NULL. We then load the '_end' field with offest '0x8' from the CodeSection in register 'edx' into 'ecx'. But this gives us a wrong address (i.e. 0xcccccccc) and that's the reason why we crash when we try to write (i.e. emit_int8()) the register encoding from register 'al' to that address in 'ecx'. So the problem is that for some reason the CodeSection of the AbstractAssembler isn't initialized correctly. This may be related to the "codeBuffer.hpp:181:51: runtime error: member access within null pointer of type 'struct CodeSection'" - problem when compiling with "-fsanitize=undefined" as reported by you. I'll take a look at that tomorrow. Regards, Volker On Tue, Apr 22, 2014 at 6:34 PM, Omair Majid wrote: > * Volker Simonis [2014-04-22 04:41]: >> I think the simplest and safest fix would be to make encoding() (and >> all the corresponding functions) static functions which take a >> Register as argument like: >> >> static int encoding(const RegisterImpl* r) { assert(is_valid(r), >> "invalid register"); return (intptr_t)r; } >> >> This wouldn't waste any more memory and it would be fully C++ >> compliant at the price of a slightly more verbose usage: >> >> 2577 void Assembler::push(Register src) { >> 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); >> 2579 >> >> And of course this would work with any compiler. > > Are you sure about this? > > It seems to me that a pointer created from an int does not satisfy the > conditions for a "safely-derived pointer". It has implementation defined > behaviour [1]. > >> What do you think? > > That certainly works for me, but not sure for others. > > For the sake of safety, I would rather use a typedef for registers and a > separate class with static methods to operate on the typedef. > > Thanks, > Omair > > [1] http://cpp0x.centaur.ath.cx/basic.stc.dynamic.safety.html > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From alejandro.murillo at oracle.com Tue Apr 22 23:42:18 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 22 Apr 2014 17:42:18 -0600 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <53556F0C.3010305@oracle.com> References: <5345E28F.5050108@oracle.com> <21329.51306.466788.318656@mykonos.us.oracle.com> <535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com> Message-ID: <5356FE5A.4000005@oracle.com> On 4/21/2014 1:18 PM, Vladimir Kozlov wrote: > Hi Alejandro, > > I don't think we need to rename make/hotspot_version file. It is still > used to set JVM's version string and not JDK's version. > > Next should be 2014 (I think David pointed it too but there is no new > webrev): HOTSPOT_VM_COPYRIGHT=Copyright 2013 correct. I haven't changed that yet > > If you pass major, micro etc numbers to avoid parsing you need to > verify that constructed from them string is equal to passed > HOTSPOT_RELEASE_VERSION. yes, there's a test for that, which is run when I submit a full jprt job. > > Next assert message is not consistent with previous messages which use > "vm", I think it should be "vm" here too: > > DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build > number")); we do not have hotspot build number anymore, so I think we should not mention hotspot build numberls > > Abstract_VM_Version::jvm_version() should include micro version. See > JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in > jdk/src/share/javavm/export/jvm.h. I added that here, is that what you are referring? http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html > > Use corresponding test in jdk for testing of these changes: > > jdk/test/sun/misc/Version/Version.java yeah, I run that test as part of jprt full builds, That test handles both JDK and Hotspot express versions > > jvm.h: Next comment is not accurate: > > + /* VM version string: JDK version string */ > > If we build VM separately (for example, in JPRT) VM version will not > be JDK version in which VM is installed. It will take numbers either > from passed make parameters or from make/hotspot_version. I think it > should say: > > + /* VM version string follows the JDK release version naming > convention > + * ..-bxx[-][-] > > Based on your examples [-][-] is still used > so it should be reflected in the comment. Let me make that explicit. > > Don't remove next comments from vm_version.cpp but fix it ("follow the > JDK release"): > > -// HOTSPOT_RELEASE_VERSION must follow the release version naming > convention > -// .-b[-][-] ok > > You did not show default VM version example when VM is built locally > by engineer. It will be similar to the hotspot only jprt build. There will be a mismatch, I tested by dropping the resulting libjvm into a promoted build, so it looks like this: java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b01) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed mode) > > Please test that correct version string is constructed when you build > VM using make/build.sh, for example 'sh make/build.sh debug LP64=1' Haven't tested that, thanks for pointing that out. > > Next comment change in buildtree.make is not correct because > HOTSPOT_RELEASE_VERSION make parameter does not include > HOTSPOT_BUILD_VERSION: > > -# HOTSPOT_RELEASE_VERSION - .-b (11.0-b07) > +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus > HOTSPOT_BUILD_VERSION > > see JPRT logs where HOTSPOT_BUILD_VERSION is set separately. let me check that again > > I think next change in make/defs.make is not safe (removing make > parameter) due to complexity of our builds: > > -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION) I checked the code, and HOTSPOT_RELEASE_VERSION is only used in vm_version.cpp, so I think is fine to remove it. Note that if we keep it there, since the JDK version string sometimes might have time stamps, it may affect ccache, that's why at some point they separated the options for vm_version.cpp from the options for other components. See this comment on vm,make: # This is VERY important! The version define must only be supplied to vm_version.o # If not, ccache will not re-use the cache at all, since the version string might contain # a time and date. > > > I know that windows build is mess. Please verify it carefully. For > example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but > build.make uses them: > > JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER) > That was a typo. Note that I changed the left handside, so they were incorrectly reassigning those. The places were JDK_MINOR_VER is used, the value is read from jdk_version (formerly hotspot_version) Thanks a lot for the feedback! Alejandro > > > Regards, > Vladimir > > On 4/21/14 10:13 AM, Alejandro E Murillo wrote: >> >> On 4/18/2014 6:50 PM, John Coomes wrote: >>> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: >>>> Please review this change to make the hotspot related output >>>> produced by >>>> "java -version" >>>> match the corresponding JDK output: >>>> >>>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 >>>> >>>> Note that we initially wanted to obtain more information from the repo >>>> being built and add >>>> it to the hotspot version output, but that will require changes in the >>>> JPRT, so >>>> we have decided to split the change in 2 bugs. One to make the >>>> version match >>>> (above webrev) and another one, an RFE, to add additional information >>>> extracted from the repo. >>> Generally looks good, but I agree with David that the long lines >>> should be wrapped, and it might even be clearer to separate them into >>> two variables, e.g., >>> >>> JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \ >>> -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \ >>> ... other defs ... >>> VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \ >>> -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \ >>> $(JDK_VERSION_DEFS) >>> >>> Also the change to this part of vm.make differs between at least the >>> solaris version and the linux version (didn't check bsd or windows). >>> Please make them all consistent. >>> >>>> Note that in the current version of vm_version.cpp, there is no error >>>> checking in product mode, >>>> I was suggested to make that explicit. >>> I like the additional error checking. I think you could eliminate the >>> 4 copies of similar code with a function that does the checks and sets >>> the field, e.g., >>> >>> void set_version_field(int * version_field, const char * >>> version_str, >>> const char * const assert_msg) { >>> if (version_str != NULL ...) { >>> DEBUG_ONLY(assert_digits(version_str, assert_msg)); >>> *version_field = atoi(version_str); >>> } >>> } >>> >>> -John >> Thanks John, >> working on adding these changes and sanity testing >> >> Thanks >> -- Alejandro From vladimir.kozlov at oracle.com Wed Apr 23 00:12:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Apr 2014 17:12:35 -0700 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <5356FE5A.4000005@oracle.com> References: <5345E28F.5050108@oracle.com> <21329.51306.466788.318656@mykonos.us.oracle.com> <535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com> <5356FE5A.4000005@oracle.com> Message-ID: <53570573.5070205@oracle.com> On 4/22/14 4:42 PM, Alejandro E Murillo wrote: > > On 4/21/2014 1:18 PM, Vladimir Kozlov wrote: >> Hi Alejandro, >> >> I don't think we need to rename make/hotspot_version file. It is still >> used to set JVM's version string and not JDK's version. > >> >> Next assert message is not consistent with previous messages which use >> "vm", I think it should be "vm" here too: >> >> DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build >> number")); > we do not have hotspot build number anymore, so I think we should not > mention hotspot build numberls Can we simple say "wrong build number"? So you don't want update build number in make/*_version files? ;) Yes, I see in your example of JPRT build VM does not have build number anymore. >> >> Abstract_VM_Version::jvm_version() should include micro version. See >> JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in >> jdk/src/share/javavm/export/jvm.h. > I added that here, is that what you are referring? > http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html > > http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html No, I mean next code should encode micro version too: unsigned int Abstract_VM_Version::jvm_version() { return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | + ((Abstract_VM_Version::vm_micro_version() & 0xFF) << 8) | (Abstract_VM_Version::vm_build_number() & 0xFF); } > >> >> Use corresponding test in jdk for testing of these changes: >> >> jdk/test/sun/misc/Version/Version.java > yeah, I run that test as part of jprt full builds, > That test handles both JDK and Hotspot express versions Good. >> >> jvm.h: Next comment is not accurate: >> >> + /* VM version string: JDK version string */ >> >> If we build VM separately (for example, in JPRT) VM version will not >> be JDK version in which VM is installed. It will take numbers either >> from passed make parameters or from make/hotspot_version. I think it >> should say: >> >> + /* VM version string follows the JDK release version naming >> convention >> + * ..-bxx[-][-] >> >> Based on your examples [-][-] is still used >> so it should be reflected in the comment. > Let me make that explicit. >> >> Don't remove next comments from vm_version.cpp but fix it ("follow the >> JDK release"): >> >> -// HOTSPOT_RELEASE_VERSION must follow the release version naming >> convention >> -// .-b[-][-] > ok >> >> You did not show default VM version example when VM is built locally >> by engineer. > It will be similar to the hotspot only jprt build. There will be a > mismatch, > I tested by dropping the resulting libjvm into a promoted build, so it > looks like this: > > java version "1.9.0-ea" > Java(TM) SE Runtime Environment (build 1.9.0-ea-b01) > Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed mode) okay > >> >> Please test that correct version string is constructed when you build >> VM using make/build.sh, for example 'sh make/build.sh debug LP64=1' > Haven't tested that, thanks for pointing that out. thank you >> >> Next comment change in buildtree.make is not correct because >> HOTSPOT_RELEASE_VERSION make parameter does not include >> HOTSPOT_BUILD_VERSION: >> >> -# HOTSPOT_RELEASE_VERSION - .-b (11.0-b07) >> +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus >> HOTSPOT_BUILD_VERSION >> >> see JPRT logs where HOTSPOT_BUILD_VERSION is set separately. > let me check that again >> >> I think next change in make/defs.make is not safe (removing make >> parameter) due to complexity of our builds: >> >> -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION) > I checked the code, and HOTSPOT_RELEASE_VERSION is only used in > vm_version.cpp, > so I think is fine to remove it. Note that if we keep it there, since > the JDK version string > sometimes might have time stamps, it may affect ccache, that's why at > some point they > separated the options for vm_version.cpp from the options for other > components. See this > comment on vm,make: > > # This is VERY important! The version define must only be supplied to > vm_version.o > # If not, ccache will not re-use the cache at all, since the version > string might contain > # a time and date. > I was concern that it will not be passed into nested make so that, for example, buildtree.make will not get it. > >> >> >> I know that windows build is mess. Please verify it carefully. For >> example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but >> build.make uses them: >> >> JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER) >> > That was a typo. Note that I changed the left handside, so they were > incorrectly reassigning those. > The places were JDK_MINOR_VER is used, the value is read from > jdk_version (formerly hotspot_version) Okay. Thanks, Vladimir > > Thanks a lot for the feedback! > Alejandro >> >> >> Regards, >> Vladimir >> >> On 4/21/14 10:13 AM, Alejandro E Murillo wrote: >>> >>> On 4/18/2014 6:50 PM, John Coomes wrote: >>>> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: >>>>> Please review this change to make the hotspot related output >>>>> produced by >>>>> "java -version" >>>>> match the corresponding JDK output: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 >>>>> >>>>> Note that we initially wanted to obtain more information from the repo >>>>> being built and add >>>>> it to the hotspot version output, but that will require changes in the >>>>> JPRT, so >>>>> we have decided to split the change in 2 bugs. One to make the >>>>> version match >>>>> (above webrev) and another one, an RFE, to add additional information >>>>> extracted from the repo. >>>> Generally looks good, but I agree with David that the long lines >>>> should be wrapped, and it might even be clearer to separate them into >>>> two variables, e.g., >>>> >>>> JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \ >>>> -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \ >>>> ... other defs ... >>>> VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \ >>>> -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \ >>>> $(JDK_VERSION_DEFS) >>>> >>>> Also the change to this part of vm.make differs between at least the >>>> solaris version and the linux version (didn't check bsd or windows). >>>> Please make them all consistent. >>>> >>>>> Note that in the current version of vm_version.cpp, there is no error >>>>> checking in product mode, >>>>> I was suggested to make that explicit. >>>> I like the additional error checking. I think you could eliminate the >>>> 4 copies of similar code with a function that does the checks and sets >>>> the field, e.g., >>>> >>>> void set_version_field(int * version_field, const char * >>>> version_str, >>>> const char * const assert_msg) { >>>> if (version_str != NULL ...) { >>>> DEBUG_ONLY(assert_digits(version_str, assert_msg)); >>>> *version_field = atoi(version_str); >>>> } >>>> } >>>> >>>> -John >>> Thanks John, >>> working on adding these changes and sanity testing >>> >>> Thanks >>> > From alejandro.murillo at oracle.com Wed Apr 23 02:32:58 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 22 Apr 2014 20:32:58 -0600 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <53570573.5070205@oracle.com> References: <5345E28F.5050108@oracle.com> <21329.51306.466788.318656@mykonos.us.oracle.com> <535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com> <5356FE5A.4000005@oracle.com> <53570573.5070205@oracle.com> Message-ID: <5357265A.5090603@oracle.com> On 4/22/2014 6:12 PM, Vladimir Kozlov wrote: > On 4/22/14 4:42 PM, Alejandro E Murillo wrote: >> >> On 4/21/2014 1:18 PM, Vladimir Kozlov wrote: >>> Hi Alejandro, >>> >>> I don't think we need to rename make/hotspot_version file. It is still >>> used to set JVM's version string and not JDK's version. >> >>> >>> Next assert message is not consistent with previous messages which use >>> "vm", I think it should be "vm" here too: >>> >>> DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build >>> number")); >> we do not have hotspot build number anymore, so I think we should not >> mention hotspot build numberls > > Can we simple say "wrong build number"? sounds good! > > So you don't want update build number in make/*_version files? ;) > Yes, I see in your example of JPRT build VM does not have build number > anymore. it's gone! > >>> >>> Abstract_VM_Version::jvm_version() should include micro version. See >>> JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in >>> jdk/src/share/javavm/export/jvm.h. >> I added that here, is that what you are referring? >> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html >> >> >> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html >> > > No, I mean next code should encode micro version too: > > unsigned int Abstract_VM_Version::jvm_version() { > return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | > ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | > + ((Abstract_VM_Version::vm_micro_version() & 0xFF) << 8) | > (Abstract_VM_Version::vm_build_number() & 0xFF); > } > you are right. I recall having added that earlier :( it's back int the webrev >> >>> >>> Use corresponding test in jdk for testing of these changes: >>> >>> jdk/test/sun/misc/Version/Version.java >> yeah, I run that test as part of jprt full builds, >> That test handles both JDK and Hotspot express versions > > Good. > >>> >>> jvm.h: Next comment is not accurate: >>> >>> + /* VM version string: JDK version string */ >>> >>> If we build VM separately (for example, in JPRT) VM version will not >>> be JDK version in which VM is installed. It will take numbers either >>> from passed make parameters or from make/hotspot_version. I think it >>> should say: >>> >>> + /* VM version string follows the JDK release version naming >>> convention >>> + * ..-bxx[-][-] >>> >>> Based on your examples [-][-] is still used >>> so it should be reflected in the comment. >> Let me make that explicit. >>> >>> Don't remove next comments from vm_version.cpp but fix it ("follow the >>> JDK release"): >>> >>> -// HOTSPOT_RELEASE_VERSION must follow the release version naming >>> convention >>> -// .-b[-][-] >> ok >>> >>> You did not show default VM version example when VM is built locally >>> by engineer. >> It will be similar to the hotspot only jprt build. There will be a >> mismatch, >> I tested by dropping the resulting libjvm into a promoted build, so it >> looks like this: >> >> java version "1.9.0-ea" >> Java(TM) SE Runtime Environment (build 1.9.0-ea-b01) >> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed >> mode) > > okay > >> >>> >>> Please test that correct version string is constructed when you build >>> VM using make/build.sh, for example 'sh make/build.sh debug LP64=1' >> Haven't tested that, thanks for pointing that out. > > thank you > >>> >>> Next comment change in buildtree.make is not correct because >>> HOTSPOT_RELEASE_VERSION make parameter does not include >>> HOTSPOT_BUILD_VERSION: >>> >>> -# HOTSPOT_RELEASE_VERSION - .-b (11.0-b07) >>> +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus >>> HOTSPOT_BUILD_VERSION >>> >>> see JPRT logs where HOTSPOT_BUILD_VERSION is set separately. >> let me check that again >>> >>> I think next change in make/defs.make is not safe (removing make >>> parameter) due to complexity of our builds: >>> >>> -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION) >> I checked the code, and HOTSPOT_RELEASE_VERSION is only used in >> vm_version.cpp, >> so I think is fine to remove it. Note that if we keep it there, since >> the JDK version string >> sometimes might have time stamps, it may affect ccache, that's why at >> some point they >> separated the options for vm_version.cpp from the options for other >> components. See this >> comment on vm,make: >> >> # This is VERY important! The version define must only be supplied to >> vm_version.o >> # If not, ccache will not re-use the cache at all, since the version >> string might contain >> # a time and date. >> > > I was concern that it will not be passed into nested make so that, for > example, buildtree.make will not get it. I see. I don't think it's needed I think I incorporated all the changes David, John and you suggested and started some sanity testing; Here's is the latest webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Please review (don't forget to refresh each file on your browser) and let me know if I missed anything. thanks guys! -- Alejandro From omajid at redhat.com Wed Apr 23 14:53:44 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 23 Apr 2014 10:53:44 -0400 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <533EC7FA.9030700@gmail.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53144E4D.8080606@redhat.com> <20140303190102.GE2045@redhat.com> <533EC7FA.9030700@gmail.com> Message-ID: <20140423145343.GA24358@redhat.com> Hi, * Yasumasa Suenaga [2014-04-04 10:56]: > I've succeeded to make binaries which are contained debuginfo as following: > > http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html > $ make images STRIP_POLICY=no_strip POST_STRIP_CMD="" > > I guess that we should run "make" above options to avoid this issue > in currently. Thanks. I have verified that this works. Sorry about the delay in getting it pushed; I haven't had the time due to the security update and now rawhide being broken due to a GCC 4.9 bump. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From vladimir.kempik at oracle.com Wed Apr 23 16:20:15 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 23 Apr 2014 20:20:15 +0400 Subject: RFR: 8024677: [TESTBUG] Move tests for classes in /testlibrary In-Reply-To: <534FBF64.1010906@oracle.com> References: <534FBF64.1010906@oracle.com> Message-ID: <5357E83F.4050208@oracle.com> Hello Can I have a couple of reviews for this please? Thanks. On 17.04.2014 15:47, Vladimir Kempik wrote: > Hello > > Please review this patch. > We've recently backported changes to testlibrary from jdk8 to jdk7 and > now I want to bring TL tests to jdk7 as well. jdk7u-dev/jdk already > has these tests, it's only hotspot that missing them. > Its partially backport of 8024677, but I don't remove old files and > don't edit TEST.groups as these files don't exist in jdk7/hotspot. > I want to push these changes as backport of 8024677 to jdk7/hotspot, > but since I've removed part of original patch (as mentioned before) I > think I need to get a review. > > Original fix: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5b1191bf0b4b > Webrev: http://cr.openjdk.java.net/~vkempik/8024677/webrev.00/ > > Thanks. Vladimir. From volker.simonis at gmail.com Wed Apr 23 17:47:05 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 23 Apr 2014 19:47:05 +0200 Subject: Undefined behaviour in hotspot In-Reply-To: References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <20140422163406.GB30387@redhat.com> Message-ID: Hi, this didn't let me sleep so I did some deeper investigation. The outcome is that I'm pretty sure this is a bug in gcc 4.9. Following the details: It seems that 'MacroAssembler::jump_cc(Assembler::Condition, AddressLiteral)' is getting compiled incorrectly. Looking at the assembly of this function in gdb shows the following: 0xf7195db0 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral>: push %ebp 0xf7195db1 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+1>: mov %esp,%ebp 0xf7195db3 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+3>: push %esi 0xf7195db4 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+4>: push %ebx 0xf7195db5 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+5>: call 0xf67a88e5 <__x86.get_pc_thunk.bx> 0xf7195dba <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+10>: add $0x7b61de,%ebx 0xf7195dc0 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+16>: mov 0x8(%ebp),%esi 0xf7195dc3 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+19>: mov 0xc(%esi),%eax 0xf7195dc6 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+22>: mov 0x4(%eax),%edx 0xf7195dc9 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+25>: test %edx,%edx 0xf7195dcb <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+27>: je 0xf7195df7 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+71> 0xf7195dcd <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+29>: lea -0x386e28(%ebx),%eax 0xf7195dd3 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+35>: push %eax 0xf7195dd4 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+36>: lea -0x386884(%ebx),%eax 0xf7195dda <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+42>: push %eax 0xf7195ddb <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+43>: lea -0x3872f0(%ebx),%eax 0xf7195de1 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+49>: push $0xe3 0xf7195de6 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+54>: push %eax 0xf7195de7 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+55>: call 0xf6c9b730 <_Z15report_vm_errorPKciS0_S0_> 0xf7195dec <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+60>: call 0xf72bc1c0 0xf7195df1 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+65>: mov 0xc(%esi),%eax 0xf7195df4 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+68>: add $0x10,%esp 0xf7195df7 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+71>: mov 0x8(%eax),%edx 0xf7195dfa <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+74>: mov %edx,0x4(%eax) 0xf7195dfd: nop 0xf7195dfe: xchg %ax,%ax 0xf7195e00 <_ZN14MacroAssembler10verify_oopEP12RegisterImplPKc.part.49>: push %ebp 0xf7195e01 <_ZN14MacroAssembler10verify_oopEP12RegisterImplPKc.part.49+1>: mov %esp,%ebp Besides the fact that the assembly for this functions is much too small, you can see that the function has no return statement. Ath the end it just runs into the following function (in this case ''MacroAssembler::verify_oop(RegisterImpl*, char const*)"). The check at: 0xf7195dc6 : mov 0x4(%eax),%edx 0xf7195dc9 : test %edx,%edx is from the assertion in InstructionMark constructor: InstructionMark(AbstractAssembler* assm) : _assm(assm) { assert(assm->inst_mark() == NULL, "overlapping instructions"); _assm->set_inst_mark(); } which is at the beginning of MacroAssembler::jump_cc(): void MacroAssembler::jump_cc(Condition cc, AddressLiteral dst) { if (reachable(dst)) { InstructionMark im(this); If 'assm->inst_mark()' is not zero, we jump right to 0xf7195df7 where we set the instruction mark of the code section: 0xf7195df7 : mov 0x8(%eax),%edx 0xf7195dfa : mov %edx,0x4(%eax) '_assm->set_inst_mark()' expands to 'code_section()->set_mark()' which in turn expands to '{ _mark = _end; }'. In register 'eax' we have the CodeSection object where the members '_end' and '_mark' have the offsets 8 and 4 respectively. So far so good - everything looks pretty until here. But afterwards we have two NOPs and then we unconditionally enter 'MacroAssembler::verify_oop()" which is obviously wrong! Later we indirectly call "Assembler::push(RegisterImpl*)" from 'MacroAssembler::verify_oop()" but at that point we're already lost and we end up with a wrong CodeSection pointer as described in my previous mail. Funny enough, the "-fsanitize=undefined" warnings are simply wrong for the exactly same reason. If we disassemble a version of 'MacroAssembler::jump_cc(Assembler::Condition, AddressLiteral)' wich was compiled with '-fsanitize=undefined' we will see: 0xf71935d4 <+100>: mov -0x1c(%ebp),%esi 0xf71935d7 <+103>: test %esi,%esi 0xf71935d9 <+105>: je 0xf719362f <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+191> 0xf71935db <+107>: mov 0xc(%esi),%esi 0xf71935de <+110>: test %esi,%esi 0xf71935e0 <+112>: je 0xf719361a <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+170> 0xf71935e2 <+114>: mov 0x8(%esi),%edi 0xf71935e5 <+117>: test %esi,%esi 0xf71935e7 <+119>: je 0xf7193605 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+149> 0xf71935e9 <+121>: mov %edi,0x4(%esi) 0xf71935ec <+124>: cmpl $0xfffffff8,0x10(%ebp) 0xf71935f0 <+128>: je 0xf71935f2 <_ZN14MacroAssembler7jump_ccEN9Assembler9ConditionE14AddressLiteral+130> 0xf71935f2 <+130>: push %eax 0xf71935f3 <+131>: push %eax 0xf71935f4 <+132>: lea 0xb750(%ebx),%eax 0xf71935fa <+138>: push $0x0 0xf71935fc <+140>: push %eax 0xf71935fd <+141>: call 0xf6797260 <__ubsan_handle_type_mismatch at plt > 0xf7193602 <+146>: add $0x10,%esp 0xf7193605 <+149>: lea 0xb768(%ebx),%eax 0xf719360b <+155>: push %edx 0xf719360c <+156>: push %edx 0xf719360d <+157>: push $0x0 0xf719360f <+159>: push %eax 0xf7193610 <+160>: call 0xf6797260 <__ubsan_handle_type_mismatch at plt > We now have NULL-checks all over in the code (which doesn't fire in our case) but after we executed 'code_section()->set_mark()' at address 0xf71935e2 to 0xf71935e9 we unconditionally run into the ubsan ("undefined behavior sanitizer) erro handlers which print the two warnings (noticed that I've debugged the code to verify that we didn't jump into the ubsan handlers after a 'test' instruction). So to cut a long story short, I've identified '-fdevirtualize' as the culprit. '-fdevirtualize' is automatically set if we compile with -O2 but if I compile macroAssembler_x86.o only with '-O2 -fno-devirtualize' I get a VM which at least starts up and passes some smoke tests. @Omair: could you please verify this. I haven't tried x86_64 until now so I can not say if this fix also helps there. I'll try to prepare a usefully bug-report for GCC although I've no idea how I could cut this down to a small and reproducible test case. Regards, Volker On Tue, Apr 22, 2014 at 9:11 PM, Volker Simonis wrote: > Hi Omair, > > I've downloaded and compiled a brand new version of gcc 4.9.0 (it was > actually released today!) > > I could reproduce your problem on x86. On x86_64 there's a problem as > well - the VM hangs during the initialization. Funny enough I had no > problems on ppc64. A freshly compiled VM from jdk9/hs-comp ran without > any problems. So this seems to be x86 related. > > I've further analyzed the problem you described and the good news is > that it is not related to calling encoding() on a zero pointer - so > hopefully no need to massively change HotSpot code. The assembly code > of "Assembler::push(RegisterImpl* src)" looks as follows: > > 0xf6959174 <_ZN9Assembler4pushEP12RegisterImpl+20>: mov > 0xc(%ebp),%esi > 0xf6959177 <_ZN9Assembler4pushEP12RegisterImpl+23>: mov > 0x8(%ebp),%edi > 0xf695917a <_ZN9Assembler4pushEP12RegisterImpl+26>: cmp $0x7,%esi > 0xf695917d <_ZN9Assembler4pushEP12RegisterImpl+29>: jbe > 0xf69591a3 <_ZN9Assembler4pushEP12RegisterImpl+67> > > 0xf695917f <_ZN9Assembler4pushEP12RegisterImpl+31>: lea > -0x3a0c4e(%ebx),%eax > 0xf6959185 <_ZN9Assembler4pushEP12RegisterImpl+37>: push %eax > 0xf6959186 <_ZN9Assembler4pushEP12RegisterImpl+38>: lea > -0x3a0c3d(%ebx),%eax > 0xf695918c <_ZN9Assembler4pushEP12RegisterImpl+44>: push %eax > 0xf695918d <_ZN9Assembler4pushEP12RegisterImpl+45>: lea > -0x39be48(%ebx),%eax > 0xf6959193 <_ZN9Assembler4pushEP12RegisterImpl+51>: push $0x41 > 0xf6959195 <_ZN9Assembler4pushEP12RegisterImpl+53>: push %eax > 0xf6959196 <_ZN9Assembler4pushEP12RegisterImpl+54>: call > 0xf6c9b730 <_Z15report_vm_errorPKciS0_S0_> > 0xf695919b <_ZN9Assembler4pushEP12RegisterImpl+59>: call > 0xf72bc1c0 > 0xf69591a0 <_ZN9Assembler4pushEP12RegisterImpl+64>: add $0x10,%esp > > 0xf69591a3 <_ZN9Assembler4pushEP12RegisterImpl+67>: mov > 0xc(%edi),%edx > 0xf69591a6 <_ZN9Assembler4pushEP12RegisterImpl+70>: mov %esi,%eax > 0xf69591a8 <_ZN9Assembler4pushEP12RegisterImpl+72>: or $0x50,%eax > 0xf69591ab <_ZN9Assembler4pushEP12RegisterImpl+75>: mov > 0x8(%edx),%ecx > 0xf69591ae <_ZN9Assembler4pushEP12RegisterImpl+78>: mov %al,(%ecx) > > 'this' is loaded into register 'edi' and 'src' is loaded into register > 'esi'. 'src' (i.e. 'esi') is compared against '0x7' which comes from > the call to 'is_valid()'. If everything is fine, we proceed at address > '0xf69591a3'. There we load the '_code_section' field with offest 0xc > from the AbstractAssembler which is in register 'edi' and stroe it in > register 'edx'. We OR the register encoding with '0x50' which succeeds > altough the actual RegisterImpl pointer (i.e. 'src') is NULL. > > We then load the '_end' field with offest '0x8' from the CodeSection > in register 'edx' into 'ecx'. But this gives us a wrong address (i.e. > 0xcccccccc) and that's the reason why we crash when we try to write > (i.e. emit_int8()) the register encoding from register 'al' to that > address in 'ecx'. > > So the problem is that for some reason the CodeSection of the > AbstractAssembler isn't initialized correctly. This may be related to > the "codeBuffer.hpp:181:51: runtime error: member access within null > pointer of type 'struct CodeSection'" - problem when compiling with > "-fsanitize=undefined" as reported by you. I'll take a look at that > tomorrow. > > Regards, > Volker > > > > > On Tue, Apr 22, 2014 at 6:34 PM, Omair Majid wrote: > > * Volker Simonis [2014-04-22 04:41]: > >> I think the simplest and safest fix would be to make encoding() (and > >> all the corresponding functions) static functions which take a > >> Register as argument like: > >> > >> static int encoding(const RegisterImpl* r) { assert(is_valid(r), > >> "invalid register"); return (intptr_t)r; } > >> > >> This wouldn't waste any more memory and it would be fully C++ > >> compliant at the price of a slightly more verbose usage: > >> > >> 2577 void Assembler::push(Register src) { > >> 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); > >> 2579 > >> > >> And of course this would work with any compiler. > > > > Are you sure about this? > > > > It seems to me that a pointer created from an int does not satisfy the > > conditions for a "safely-derived pointer". It has implementation defined > > behaviour [1]. > > > >> What do you think? > > > > That certainly works for me, but not sure for others. > > > > For the sake of safety, I would rather use a typedef for registers and a > > separate class with static methods to operate on the typedef. > > > > Thanks, > > Omair > > > > [1] http://cpp0x.centaur.ath.cx/basic.stc.dynamic.safety.html > > > > -- > > PGP Key: 66484681 (http://pgp.mit.edu/) > > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > From vladimir.kozlov at oracle.com Wed Apr 23 17:53:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Apr 2014 10:53:19 -0700 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <5357265A.5090603@oracle.com> References: <5345E28F.5050108@oracle.com> <21329.51306.466788.318656@mykonos.us.oracle.com> <535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com> <5356FE5A.4000005@oracle.com> <53570573.5070205@oracle.com> <5357265A.5090603@oracle.com> Message-ID: <5357FE0F.4050206@oracle.com> Looks good. Thanks, Vladimir On 4/22/14 7:32 PM, Alejandro E Murillo wrote: > > On 4/22/2014 6:12 PM, Vladimir Kozlov wrote: >> On 4/22/14 4:42 PM, Alejandro E Murillo wrote: >>> >>> On 4/21/2014 1:18 PM, Vladimir Kozlov wrote: >>>> Hi Alejandro, >>>> >>>> I don't think we need to rename make/hotspot_version file. It is still >>>> used to set JVM's version string and not JDK's version. >>> >>>> >>>> Next assert message is not consistent with previous messages which use >>>> "vm", I think it should be "vm" here too: >>>> >>>> DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build >>>> number")); >>> we do not have hotspot build number anymore, so I think we should not >>> mention hotspot build numberls >> >> Can we simple say "wrong build number"? > sounds good! >> >> So you don't want update build number in make/*_version files? ;) >> Yes, I see in your example of JPRT build VM does not have build number >> anymore. > it's gone! >> >>>> >>>> Abstract_VM_Version::jvm_version() should include micro version. See >>>> JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in >>>> jdk/src/share/javavm/export/jvm.h. >>> I added that here, is that what you are referring? >>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html >>> >> >> No, I mean next code should encode micro version too: >> >> unsigned int Abstract_VM_Version::jvm_version() { >> return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | >> ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | >> + ((Abstract_VM_Version::vm_micro_version() & 0xFF) << 8) | >> (Abstract_VM_Version::vm_build_number() & 0xFF); >> } >> > you are right. I recall having added that earlier :( > it's back int the webrev >>> >>>> >>>> Use corresponding test in jdk for testing of these changes: >>>> >>>> jdk/test/sun/misc/Version/Version.java >>> yeah, I run that test as part of jprt full builds, >>> That test handles both JDK and Hotspot express versions >> >> Good. >> >>>> >>>> jvm.h: Next comment is not accurate: >>>> >>>> + /* VM version string: JDK version string */ >>>> >>>> If we build VM separately (for example, in JPRT) VM version will not >>>> be JDK version in which VM is installed. It will take numbers either >>>> from passed make parameters or from make/hotspot_version. I think it >>>> should say: >>>> >>>> + /* VM version string follows the JDK release version naming >>>> convention >>>> + * ..-bxx[-][-] >>>> >>>> Based on your examples [-][-] is still used >>>> so it should be reflected in the comment. >>> Let me make that explicit. >>>> >>>> Don't remove next comments from vm_version.cpp but fix it ("follow the >>>> JDK release"): >>>> >>>> -// HOTSPOT_RELEASE_VERSION must follow the release version naming >>>> convention >>>> -// .-b[-][-] >>> ok >>>> >>>> You did not show default VM version example when VM is built locally >>>> by engineer. >>> It will be similar to the hotspot only jprt build. There will be a >>> mismatch, >>> I tested by dropping the resulting libjvm into a promoted build, so it >>> looks like this: >>> >>> java version "1.9.0-ea" >>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b01) >>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed >>> mode) >> >> okay >> >>> >>>> >>>> Please test that correct version string is constructed when you build >>>> VM using make/build.sh, for example 'sh make/build.sh debug LP64=1' >>> Haven't tested that, thanks for pointing that out. >> >> thank you >> >>>> >>>> Next comment change in buildtree.make is not correct because >>>> HOTSPOT_RELEASE_VERSION make parameter does not include >>>> HOTSPOT_BUILD_VERSION: >>>> >>>> -# HOTSPOT_RELEASE_VERSION - .-b (11.0-b07) >>>> +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus >>>> HOTSPOT_BUILD_VERSION >>>> >>>> see JPRT logs where HOTSPOT_BUILD_VERSION is set separately. >>> let me check that again >>>> >>>> I think next change in make/defs.make is not safe (removing make >>>> parameter) due to complexity of our builds: >>>> >>>> -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION) >>> I checked the code, and HOTSPOT_RELEASE_VERSION is only used in >>> vm_version.cpp, >>> so I think is fine to remove it. Note that if we keep it there, since >>> the JDK version string >>> sometimes might have time stamps, it may affect ccache, that's why at >>> some point they >>> separated the options for vm_version.cpp from the options for other >>> components. See this >>> comment on vm,make: >>> >>> # This is VERY important! The version define must only be supplied to >>> vm_version.o >>> # If not, ccache will not re-use the cache at all, since the version >>> string might contain >>> # a time and date. >>> >> >> I was concern that it will not be passed into nested make so that, for >> example, buildtree.make will not get it. > I see. I don't think it's needed > > I think I incorporated all the changes David, John and you suggested and > started some sanity testing; > Here's is the latest webrev: > > http://cr.openjdk.java.net/~amurillo/9/8030011/ > > Please review (don't forget to refresh each file on your browser) and > let me know if I missed anything. > thanks guys! > From omajid at redhat.com Wed Apr 23 18:10:36 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 23 Apr 2014 14:10:36 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <20140422163406.GB30387@redhat.com> Message-ID: <20140423181036.GC24358@redhat.com> Hi Volker, * Volker Simonis [2014-04-22 15:11]: > I could reproduce your problem on x86. On x86_64 there's a problem as > well - the VM hangs during the initialization. Funny enough I had no > problems on ppc64. A freshly compiled VM from jdk9/hs-comp ran without > any problems. So this seems to be x86 related. Thanks for looking into this. I asked Andrew Haley for help and he pointed me to the "-fno-devirtualize" flag for gcc. Compiling all of jdk8u with this flag makes hotspot work :/ I don't understand this code, but maybe Andrew Haley can chime in and explain why this makes things work. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From vladimir.kozlov at oracle.com Wed Apr 23 18:18:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Apr 2014 11:18:16 -0700 Subject: RFR: 8024677: [TESTBUG] Move tests for classes in /testlibrary In-Reply-To: <5357E83F.4050208@oracle.com> References: <534FBF64.1010906@oracle.com> <5357E83F.4050208@oracle.com> Message-ID: <535803E8.7030100@oracle.com> Okay. Vladimir On 4/23/14 9:20 AM, Vladimir Kempik wrote: > Hello > Can I have a couple of reviews for this please? > > Thanks. > On 17.04.2014 15:47, Vladimir Kempik wrote: >> Hello >> >> Please review this patch. >> We've recently backported changes to testlibrary from jdk8 to jdk7 and >> now I want to bring TL tests to jdk7 as well. jdk7u-dev/jdk already >> has these tests, it's only hotspot that missing them. >> Its partially backport of 8024677, but I don't remove old files and >> don't edit TEST.groups as these files don't exist in jdk7/hotspot. >> I want to push these changes as backport of 8024677 to jdk7/hotspot, >> but since I've removed part of original patch (as mentioned before) I >> think I need to get a review. >> >> Original fix: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5b1191bf0b4b >> Webrev: http://cr.openjdk.java.net/~vkempik/8024677/webrev.00/ >> >> Thanks. Vladimir. > From omajid at redhat.com Wed Apr 23 18:21:54 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 23 Apr 2014 14:21:54 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <20140422163406.GB30387@redhat.com> Message-ID: <20140423182154.GD24358@redhat.com> Hi Volker, * Volker Simonis [2014-04-23 13:47]: > So to cut a long story short, I've identified '-fdevirtualize' as the culprit. > '-fdevirtualize' is automatically set if we compile with -O2 but if I compile > macroAssembler_x86.o only with '-O2 -fno-devirtualize' I get a VM which at > least starts up and passes some smoke tests. Aha, Andrew Haley just walked me through similar logic and the same flag! Though I don't really understand how (either of) you jumped from miscompiled-code to -fno-devirtualize. > @Omair: could you please verify this. I haven't tried x86_64 until now > so I can not say if this fix also helps there. Confirmed. On i686, Hotspot built with this is good enough to run javac to compile small programs. I will test x86_64 now. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From christian.tornqvist at oracle.com Wed Apr 23 18:30:25 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 23 Apr 2014 14:30:25 -0400 Subject: RFR: 8024677: [TESTBUG] Move tests for classes in /testlibrary In-Reply-To: <535803E8.7030100@oracle.com> References: <534FBF64.1010906@oracle.com> <5357E83F.4050208@oracle.com> <535803E8.7030100@oracle.com> Message-ID: <012701cf5f22$185e8c50$491ba4f0$@oracle.com> Looks good. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Wednesday, April 23, 2014 2:18 PM To: Vladimir Kempik; hotspot-dev at openjdk.java.net Subject: Re: RFR: 8024677: [TESTBUG] Move tests for classes in /testlibrary Okay. Vladimir On 4/23/14 9:20 AM, Vladimir Kempik wrote: > Hello > Can I have a couple of reviews for this please? > > Thanks. > On 17.04.2014 15:47, Vladimir Kempik wrote: >> Hello >> >> Please review this patch. >> We've recently backported changes to testlibrary from jdk8 to jdk7 >> and now I want to bring TL tests to jdk7 as well. jdk7u-dev/jdk >> already has these tests, it's only hotspot that missing them. >> Its partially backport of 8024677, but I don't remove old files and >> don't edit TEST.groups as these files don't exist in jdk7/hotspot. >> I want to push these changes as backport of 8024677 to jdk7/hotspot, >> but since I've removed part of original patch (as mentioned before) I >> think I need to get a review. >> >> Original fix: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5b1191bf0b4b >> Webrev: http://cr.openjdk.java.net/~vkempik/8024677/webrev.00/ >> >> Thanks. Vladimir. > From vladimir.kozlov at oracle.com Wed Apr 23 19:51:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Apr 2014 12:51:27 -0700 Subject: [8u20] RFR (XS) 8041351: Crash in src/share/vm/opto/loopnode.cpp:3215 - assert(!had_error) failed: bad dominance Message-ID: <535819BF.2060706@oracle.com> 8u20 backport request. These changes were pushed into jdk9 yesterday and nightly testing shows no problems. Changes from jdk9 applied to 8u without conflicts. http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4bc3f8fa071f https://bugs.openjdk.java.net/browse/JDK-8041351 Thanks, Vladimir From Miroslaw.Niemiec at Oracle.COM Wed Apr 23 20:00:27 2014 From: Miroslaw.Niemiec at Oracle.COM (Miroslaw Niemiec) Date: Wed, 23 Apr 2014 13:00:27 -0700 Subject: sawindbg.dll - compilation option for debugging support in Java6 Message-ID: <53581BDB.6010409@Oracle.COM> Hi, In Java6 hotspot I have change compilation option for sawindbg.dll from /ZI (enable Edit and Continue debug info) to /Zi (enable debugging information) in order to force Visual Studio 2003 (Java6) include a table of safe exceptions handlers in sawindbg.dll. While working on: https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=18420609 Can anyone evaluate this fix: https://java.se.oracle.com/code/cru/CR-JDK6UCPU-329 if this option change won't break SA functionality Thank you Miroslaw From daniel.daugherty at oracle.com Wed Apr 23 20:16:58 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Apr 2014 14:16:58 -0600 Subject: sawindbg.dll - compilation option for debugging support in Java6 In-Reply-To: <53581BDB.6010409@Oracle.COM> References: <53581BDB.6010409@Oracle.COM> Message-ID: <53581FBA.10604@oracle.com> Adding Serviceability to the thread since this is SA (Serviceability Agent) code... Dan On 4/23/14 2:00 PM, Miroslaw Niemiec wrote: > > Hi, > > In Java6 hotspot > I have change compilation option for sawindbg.dll > from /ZI (enable Edit and Continue debug info) > to /Zi (enable debugging information) > > in order to force Visual Studio 2003 (Java6) > include a table of safe exceptions handlers in sawindbg.dll. > > While working on: > https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=18420609 > > > > Can anyone evaluate this fix: > https://java.se.oracle.com/code/cru/CR-JDK6UCPU-329 > > if this option change won't break SA functionality > > > Thank you > Miroslaw From gnu.andrew at redhat.com Wed Apr 23 21:13:01 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Apr 2014 17:13:01 -0400 (EDT) Subject: Undefined behaviour in hotspot In-Reply-To: <20140423182154.GD24358@redhat.com> References: <20140421151956.GB2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <20140422163406.GB30387@redhat.com> <20140423182154.GD24358@redhat.com> Message-ID: <1241536745.8984225.1398287581245.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Volker, > > * Volker Simonis [2014-04-23 13:47]: > > So to cut a long story short, I've identified '-fdevirtualize' as the > > culprit. > > '-fdevirtualize' is automatically set if we compile with -O2 but if I > > compile > > macroAssembler_x86.o only with '-O2 -fno-devirtualize' I get a VM which at > > least starts up and passes some smoke tests. > > Aha, Andrew Haley just walked me through similar logic and the same > flag! Though I don't really understand how (either of) you jumped from > miscompiled-code to -fno-devirtualize. > > > @Omair: could you please verify this. I haven't tried x86_64 until now > > so I can not say if this fix also helps there. > > Confirmed. On i686, Hotspot built with this is good enough to run javac to > compile small programs. I will test x86_64 now. > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > This should turn it off in the right place: http://cr.openjdk.java.net/~andrew/8041658/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8041658 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From vladimir.kozlov at oracle.com Wed Apr 23 21:56:55 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Apr 2014 14:56:55 -0700 Subject: Undefined behaviour in hotspot In-Reply-To: <1241536745.8984225.1398287581245.JavaMail.zimbra@redhat.com> References: <20140421151956.GB2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <20140422163406.GB30387@redhat.com> <20140423182154.GD24358@redhat.com> <1241536745.8984225.1398287581245.JavaMail.zimbra@redhat.com> Message-ID: <53583727.9030806@oracle.com> Hi Andrew, The fix looks fine to me. Please, send your webrev in a separate mail to get attention and sponsor. Use subject: "RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM" RFR is request for review. [XS] - extra small change. Thanks, Vladimir On 4/23/14 2:13 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi Volker, >> >> * Volker Simonis [2014-04-23 13:47]: >>> So to cut a long story short, I've identified '-fdevirtualize' as the >>> culprit. >>> '-fdevirtualize' is automatically set if we compile with -O2 but if I >>> compile >>> macroAssembler_x86.o only with '-O2 -fno-devirtualize' I get a VM which at >>> least starts up and passes some smoke tests. >> >> Aha, Andrew Haley just walked me through similar logic and the same >> flag! Though I don't really understand how (either of) you jumped from >> miscompiled-code to -fno-devirtualize. >> >>> @Omair: could you please verify this. I haven't tried x86_64 until now >>> so I can not say if this fix also helps there. >> >> Confirmed. On i686, Hotspot built with this is good enough to run javac to >> compile small programs. I will test x86_64 now. >> >> Thanks, >> Omair >> >> -- >> PGP Key: 66484681 (http://pgp.mit.edu/) >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >> > > This should turn it off in the right place: > > http://cr.openjdk.java.net/~andrew/8041658/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8041658 > From serguei.spitsyn at oracle.com Wed Apr 23 22:49:45 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 23 Apr 2014 15:49:45 -0700 Subject: sawindbg.dll - compilation option for debugging support in Java6 In-Reply-To: <53581BDB.6010409@Oracle.COM> References: <53581BDB.6010409@Oracle.COM> Message-ID: <53584389.1040608@oracle.com> I've added a comment into this form as the fix looks good to me. Not sure this has to be reviewed in the open as it is a security issue. I've added the serviceability group to the mailing list. Thanks, Serguei On 4/23/14 1:00 PM, Miroslaw Niemiec wrote: > > Hi, > > In Java6 hotspot > I have change compilation option for sawindbg.dll > from /ZI (enable Edit and Continue debug info) > to /Zi (enable debugging information) > > in order to force Visual Studio 2003 (Java6) > include a table of safe exceptions handlers in sawindbg.dll. > > While working on: > https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=18420609 > > > > Can anyone evaluate this fix: > https://java.se.oracle.com/code/cru/CR-JDK6UCPU-329 > > if this option change won't break SA functionality > > > Thank you > Miroslaw From gnu.andrew at redhat.com Thu Apr 24 03:10:25 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Apr 2014 23:10:25 -0400 (EDT) Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> Message-ID: <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> Webrev: http://cr.openjdk.java.net/~andrew/8041658/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8041658 Earlier discussion: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013577.html It is necessary to pass -fno-devirtualize to gcc when building macroAssembler_x86.o with gcc 4.9.0, as otherwise a return statement is missing in MacroAssembler::jump_cc(Assembler::Condition, AddressLiteral) and control flow enters whatever method happens to follow it. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Apr 24 03:12:46 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Apr 2014 23:12:46 -0400 (EDT) Subject: sawindbg.dll - compilation option for debugging support in Java6 In-Reply-To: <53581BDB.6010409@Oracle.COM> References: <53581BDB.6010409@Oracle.COM> Message-ID: <522755079.9103104.1398309166234.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > Hi, > > In Java6 hotspot > I have change compilation option for sawindbg.dll > from /ZI (enable Edit and Continue debug info) > to /Zi (enable debugging information) > > in order to force Visual Studio 2003 (Java6) > include a table of safe exceptions handlers in sawindbg.dll. > > While working on: > https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=18420609 > > > Can anyone evaluate this fix: > https://java.se.oracle.com/code/cru/CR-JDK6UCPU-329 > > if this option change won't break SA functionality > > > Thank you > Miroslaw > Both of these URLs seem to be inaccessible. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From roland.westrelin at oracle.com Thu Apr 24 08:41:16 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 24 Apr 2014 10:41:16 +0200 Subject: [8u20] RFR(XS): 8039975: SIGSEGV in MethodData::next_data(ProfileData*) Message-ID: <279DADDD-92BB-40E5-A03E-15409DF0A3C1@oracle.com> 8u20 backport request. The change was pushed to jdk9 a week ago and nightly testing hasn?t shown any problem. The change applies cleanly to 8u. http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eb8897b2687e https://bugs.openjdk.java.net/browse/JDK-8041110 Roland. From volker.simonis at gmail.com Thu Apr 24 08:45:53 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 24 Apr 2014 10:45:53 +0200 Subject: Undefined behaviour in hotspot In-Reply-To: <20140423182154.GD24358@redhat.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <20140422163406.GB30387@redhat.com> <20140423182154.GD24358@redhat.com> Message-ID: On Wed, Apr 23, 2014 at 8:21 PM, Omair Majid wrote: > Hi Volker, > > * Volker Simonis [2014-04-23 13:47]: > > So to cut a long story short, I've identified '-fdevirtualize' as the > culprit. > > '-fdevirtualize' is automatically set if we compile with -O2 but if I > compile > > macroAssembler_x86.o only with '-O2 -fno-devirtualize' I get a VM which > at > > least starts up and passes some smoke tests. > > Aha, Andrew Haley just walked me through similar logic and the same > flag! Though I don't really understand how (either of) you jumped from > miscompiled-code to -fno-devirtualize. > > Simple binary search trough the extra optimizations -O2 applies compared to O1 :) > > @Omair: could you please verify this. I haven't tried x86_64 until now > > so I can not say if this fix also helps there. > > Confirmed. On i686, Hotspot built with this is good enough to run javac to > compile small programs. I will test x86_64 now. > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > From volker.simonis at gmail.com Thu Apr 24 09:42:09 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 24 Apr 2014 11:42:09 +0200 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> Message-ID: Hi Andrew, could you pleas hold on a little bit. I just found out that for x86_64 we additionally need -fno-devirtualize when compiling 'assembler_x86.cpp'. Without the option, the compilation of "Assembler::reachable(AddressLiteral adr)" is totally broken: 0x7ffff6046910 <_ZN9Assembler9reachableE14AddressLiteral>: push %rbp 0x7ffff6046911 <_ZN9Assembler9reachableE14AddressLiteral+1>: mov %rsp,%rbp 0x7ffff6046914: data32 data32 nopw %cs:0x0(%rax,%rax,1) 0x7ffff6046920 <_ZN9Assembler19is_polling_page_farEv>: mov 0x12d7e69(%rip),%rax As you can see it only contains two instructions before it unconditionally falls into 'Assembler::is_polling_page_far()' Maybe we should do some more thorough tests on both, x86 and x86_64 with these settings to avoid follow-up changes. What bothers me however is the fact that we now get this sever error at several places in the OpenJDK while it doesn't seem to affect others and I can not see what's special in the coding that triggers the misbehavior? Regards, Volker On Thu, Apr 24, 2014 at 5:10 AM, Andrew Hughes wrote: > Webrev: http://cr.openjdk.java.net/~andrew/8041658/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8041658 > Earlier discussion: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013577.html > > It is necessary to pass -fno-devirtualize to gcc when building > macroAssembler_x86.o with > gcc 4.9.0, as otherwise a return statement is missing in > MacroAssembler::jump_cc(Assembler::Condition, AddressLiteral) and control > flow enters whatever > method happens to follow it. > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > From aph at redhat.com Thu Apr 24 12:12:49 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 24 Apr 2014 13:12:49 +0100 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> Message-ID: <5358FFC1.7020709@redhat.com> On 04/24/2014 10:42 AM, Volker Simonis wrote: > could you pleas hold on a little bit. > > I just found out that for x86_64 we additionally need -fno-devirtualize > when compiling 'assembler_x86.cpp'. Without the option, the compilation of > "Assembler::reachable(AddressLiteral adr)" is totally broken: > > 0x7ffff6046910 <_ZN9Assembler9reachableE14AddressLiteral>: push %rbp > 0x7ffff6046911 <_ZN9Assembler9reachableE14AddressLiteral+1>: mov > %rsp,%rbp > 0x7ffff6046914: data32 data32 nopw %cs:0x0(%rax,%rax,1) > 0x7ffff6046920 <_ZN9Assembler19is_polling_page_farEv>: mov > 0x12d7e69(%rip),%rax > > As you can see it only contains two instructions before it unconditionally > falls into 'Assembler::is_polling_page_far()' > > Maybe we should do some more thorough tests on both, x86 and x86_64 with > these settings to avoid follow-up changes. > > What bothers me however is the fact that we now get this sever error at > several places in the OpenJDK while it doesn't seem to affect others and I > can not see what's special in the coding that triggers the misbehavior? I think I might be able to. I'm debugging GCC now. Andrew. From aph at redhat.com Thu Apr 24 14:51:05 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 24 Apr 2014 15:51:05 +0100 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <5358FFC1.7020709@redhat.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> Message-ID: <535924D9.2070404@redhat.com> On 04/24/2014 01:12 PM, Andrew Haley wrote: > On 04/24/2014 10:42 AM, Volker Simonis wrote: > >> could you pleas hold on a little bit. >> >> I just found out that for x86_64 we additionally need -fno-devirtualize >> when compiling 'assembler_x86.cpp'. Without the option, the compilation of >> "Assembler::reachable(AddressLiteral adr)" is totally broken: >> >> 0x7ffff6046910 <_ZN9Assembler9reachableE14AddressLiteral>: push %rbp >> 0x7ffff6046911 <_ZN9Assembler9reachableE14AddressLiteral+1>: mov >> %rsp,%rbp >> 0x7ffff6046914: data32 data32 nopw %cs:0x0(%rax,%rax,1) >> 0x7ffff6046920 <_ZN9Assembler19is_polling_page_farEv>: mov >> 0x12d7e69(%rip),%rax >> >> As you can see it only contains two instructions before it unconditionally >> falls into 'Assembler::is_polling_page_far()' >> >> Maybe we should do some more thorough tests on both, x86 and x86_64 with >> these settings to avoid follow-up changes. >> >> What bothers me however is the fact that we now get this sever error at >> several places in the OpenJDK while it doesn't seem to affect others and I >> can not see what's special in the coding that triggers the misbehavior? > > I think I might be able to. I'm debugging GCC now. I've found it, and I don't think this is a bug. GCC's interprocedural analysis looks at this type: class RelocationHolder VALUE_OBJ_CLASS_SPEC { friend class Relocation; friend class CodeSection; private: // this preallocated memory must accommodate all subclasses of Relocation // (this number is assertion-checked in Relocation::operator new) enum { _relocbuf_size = 5 }; void* _relocbuf[ _relocbuf_size ]; public: Relocation* reloc() const { return (Relocation*) &_relocbuf[0]; } ... and decides that no object of type Relocation is reachable from it. This is correct: strictly speaking, you can't portably copy a Relocation into an array of void* and then cast the void* to a Relocation* and expect to use it. It could be argued that -fno-strict-aliasing should mean that this analysis is incorrect, and all types are reachable. The attached patch fixes GCC to do that. However, I think it would be better to fix HotSpot so that it's correct C++. Andrew. Index: gcc/ipa-devirt.c =================================================================== --- gcc/ipa-devirt.c (revision 209656) +++ gcc/ipa-devirt.c (working copy) @@ -1362,8 +1362,9 @@ /* Only type inconsistent programs can have otr_type that is not part of outer type. */ - if (!contains_type_p (TREE_TYPE (base), - context->offset + offset2, *otr_type)) + if (flag_strict_aliasing + && !contains_type_p (TREE_TYPE (base), + context->offset + offset2, *otr_type)) { /* Use OTR_TOKEN = INT_MAX as a marker of probably type inconsistent code sequences; we arrange the calls to be builtin_unreachable @@ -1441,7 +1442,8 @@ gcc_assert (!POINTER_TYPE_P (context->outer_type)); /* Only type inconsistent programs can have otr_type that is not part of outer type. */ - if (!contains_type_p (context->outer_type, context->offset, + if (flag_strict_aliasing + && !contains_type_p (context->outer_type, context->offset, *otr_type)) { /* Use OTR_TOKEN = INT_MAX as a marker of probably type inconsistent From volker.simonis at gmail.com Thu Apr 24 15:10:06 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 24 Apr 2014 17:10:06 +0200 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <535924D9.2070404@redhat.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> Message-ID: Wow, that was fast! I had just distilled a preprocessed version of 'assembler_x86.cpp' down to about 1800 lines of code and guess what - I just discovered and analyzed the strange way how RelocationHolder is allocated and casted to a Relocation. Thanks for the patch and I agree with you that we should fix the HotSpot. Nevertheless I think gcc should be fixed as well. I shouldn't generate incomplete functions like for "Assembler::reachable(AddressLiteral adr)" in the example from my previous mail. Regards, Volker On Thu, Apr 24, 2014 at 4:51 PM, Andrew Haley wrote: > On 04/24/2014 01:12 PM, Andrew Haley wrote: >> On 04/24/2014 10:42 AM, Volker Simonis wrote: >> >>> could you pleas hold on a little bit. >>> >>> I just found out that for x86_64 we additionally need -fno-devirtualize >>> when compiling 'assembler_x86.cpp'. Without the option, the compilation of >>> "Assembler::reachable(AddressLiteral adr)" is totally broken: >>> >>> 0x7ffff6046910 <_ZN9Assembler9reachableE14AddressLiteral>: push %rbp >>> 0x7ffff6046911 <_ZN9Assembler9reachableE14AddressLiteral+1>: mov >>> %rsp,%rbp >>> 0x7ffff6046914: data32 data32 nopw %cs:0x0(%rax,%rax,1) >>> 0x7ffff6046920 <_ZN9Assembler19is_polling_page_farEv>: mov >>> 0x12d7e69(%rip),%rax >>> >>> As you can see it only contains two instructions before it unconditionally >>> falls into 'Assembler::is_polling_page_far()' >>> >>> Maybe we should do some more thorough tests on both, x86 and x86_64 with >>> these settings to avoid follow-up changes. >>> >>> What bothers me however is the fact that we now get this sever error at >>> several places in the OpenJDK while it doesn't seem to affect others and I >>> can not see what's special in the coding that triggers the misbehavior? >> >> I think I might be able to. I'm debugging GCC now. > > I've found it, and I don't think this is a bug. GCC's interprocedural > analysis looks at this type: > > class RelocationHolder VALUE_OBJ_CLASS_SPEC { > friend class Relocation; > friend class CodeSection; > > private: > // this preallocated memory must accommodate all subclasses of Relocation > // (this number is assertion-checked in Relocation::operator new) > enum { _relocbuf_size = 5 }; > void* _relocbuf[ _relocbuf_size ]; > > public: > Relocation* reloc() const { return (Relocation*) &_relocbuf[0]; } > ... > > and decides that no object of type Relocation is reachable from it. > > This is correct: strictly speaking, you can't portably copy a > Relocation into an array of void* and then cast the void* to a > Relocation* and expect to use it. > > It could be argued that -fno-strict-aliasing should mean that this > analysis is incorrect, and all types are reachable. The attached > patch fixes GCC to do that. However, I think it would be better to > fix HotSpot so that it's correct C++. > > Andrew. > > > Index: gcc/ipa-devirt.c > =================================================================== > --- gcc/ipa-devirt.c (revision 209656) > +++ gcc/ipa-devirt.c (working copy) > @@ -1362,8 +1362,9 @@ > > /* Only type inconsistent programs can have otr_type that is > not part of outer type. */ > - if (!contains_type_p (TREE_TYPE (base), > - context->offset + offset2, *otr_type)) > + if (flag_strict_aliasing > + && !contains_type_p (TREE_TYPE (base), > + context->offset + offset2, *otr_type)) > { > /* Use OTR_TOKEN = INT_MAX as a marker of probably type inconsistent > code sequences; we arrange the calls to be builtin_unreachable > @@ -1441,7 +1442,8 @@ > gcc_assert (!POINTER_TYPE_P (context->outer_type)); > /* Only type inconsistent programs can have otr_type that is > not part of outer type. */ > - if (!contains_type_p (context->outer_type, context->offset, > + if (flag_strict_aliasing > + && !contains_type_p (context->outer_type, context->offset, > *otr_type)) > { > /* Use OTR_TOKEN = INT_MAX as a marker of probably type inconsistent > > > > > From alejandro.murillo at oracle.com Thu Apr 24 16:16:38 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 24 Apr 2014 10:16:38 -0600 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <5357FE0F.4050206@oracle.com> References: <5345E28F.5050108@oracle.com> <21329.51306.466788.318656@mykonos.us.oracle.com> <535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com> <5356FE5A.4000005@oracle.com> <53570573.5070205@oracle.com> <5357265A.5090603@oracle.com> <5357FE0F.4050206@oracle.com> Message-ID: <535938E6.9040200@oracle.com> Thanks Vladimir Alejandro On 4/23/2014 11:53 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 4/22/14 7:32 PM, Alejandro E Murillo wrote: >> >> On 4/22/2014 6:12 PM, Vladimir Kozlov wrote: >>> On 4/22/14 4:42 PM, Alejandro E Murillo wrote: >>>> >>>> On 4/21/2014 1:18 PM, Vladimir Kozlov wrote: >>>>> Hi Alejandro, >>>>> >>>>> I don't think we need to rename make/hotspot_version file. It is >>>>> still >>>>> used to set JVM's version string and not JDK's version. >>>> >>>>> >>>>> Next assert message is not consistent with previous messages which >>>>> use >>>>> "vm", I think it should be "vm" here too: >>>>> >>>>> DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build >>>>> number")); >>>> we do not have hotspot build number anymore, so I think we should not >>>> mention hotspot build numberls >>> >>> Can we simple say "wrong build number"? >> sounds good! >>> >>> So you don't want update build number in make/*_version files? ;) >>> Yes, I see in your example of JPRT build VM does not have build number >>> anymore. >> it's gone! >>> >>>>> >>>>> Abstract_VM_Version::jvm_version() should include micro version. See >>>>> JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in >>>>> jdk/src/share/javavm/export/jvm.h. >>>> I added that here, is that what you are referring? >>>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html >>>> >>>> >>>> >>>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html >>>> >>>> >>> >>> No, I mean next code should encode micro version too: >>> >>> unsigned int Abstract_VM_Version::jvm_version() { >>> return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | >>> ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | >>> + ((Abstract_VM_Version::vm_micro_version() & 0xFF) << 8) | >>> (Abstract_VM_Version::vm_build_number() & 0xFF); >>> } >>> >> you are right. I recall having added that earlier :( >> it's back int the webrev >>>> >>>>> >>>>> Use corresponding test in jdk for testing of these changes: >>>>> >>>>> jdk/test/sun/misc/Version/Version.java >>>> yeah, I run that test as part of jprt full builds, >>>> That test handles both JDK and Hotspot express versions >>> >>> Good. >>> >>>>> >>>>> jvm.h: Next comment is not accurate: >>>>> >>>>> + /* VM version string: JDK version string */ >>>>> >>>>> If we build VM separately (for example, in JPRT) VM version will not >>>>> be JDK version in which VM is installed. It will take numbers either >>>>> from passed make parameters or from make/hotspot_version. I think it >>>>> should say: >>>>> >>>>> + /* VM version string follows the JDK release version naming >>>>> convention >>>>> + * ..-bxx[-][-] >>>>> >>>>> Based on your examples [-][-] is still used >>>>> so it should be reflected in the comment. >>>> Let me make that explicit. >>>>> >>>>> Don't remove next comments from vm_version.cpp but fix it ("follow >>>>> the >>>>> JDK release"): >>>>> >>>>> -// HOTSPOT_RELEASE_VERSION must follow the release version naming >>>>> convention >>>>> -// .-b[-][-] >>>> ok >>>>> >>>>> You did not show default VM version example when VM is built locally >>>>> by engineer. >>>> It will be similar to the hotspot only jprt build. There will be a >>>> mismatch, >>>> I tested by dropping the resulting libjvm into a promoted build, >>>> so it >>>> looks like this: >>>> >>>> java version "1.9.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b01) >>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed >>>> mode) >>> >>> okay >>> >>>> >>>>> >>>>> Please test that correct version string is constructed when you build >>>>> VM using make/build.sh, for example 'sh make/build.sh debug LP64=1' >>>> Haven't tested that, thanks for pointing that out. >>> >>> thank you >>> >>>>> >>>>> Next comment change in buildtree.make is not correct because >>>>> HOTSPOT_RELEASE_VERSION make parameter does not include >>>>> HOTSPOT_BUILD_VERSION: >>>>> >>>>> -# HOTSPOT_RELEASE_VERSION - .-b (11.0-b07) >>>>> +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus >>>>> HOTSPOT_BUILD_VERSION >>>>> >>>>> see JPRT logs where HOTSPOT_BUILD_VERSION is set separately. >>>> let me check that again >>>>> >>>>> I think next change in make/defs.make is not safe (removing make >>>>> parameter) due to complexity of our builds: >>>>> >>>>> -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION) >>>> I checked the code, and HOTSPOT_RELEASE_VERSION is only used in >>>> vm_version.cpp, >>>> so I think is fine to remove it. Note that if we keep it there, since >>>> the JDK version string >>>> sometimes might have time stamps, it may affect ccache, that's why at >>>> some point they >>>> separated the options for vm_version.cpp from the options for other >>>> components. See this >>>> comment on vm,make: >>>> >>>> # This is VERY important! The version define must only be supplied to >>>> vm_version.o >>>> # If not, ccache will not re-use the cache at all, since the version >>>> string might contain >>>> # a time and date. >>>> >>> >>> I was concern that it will not be passed into nested make so that, for >>> example, buildtree.make will not get it. >> I see. I don't think it's needed >> >> I think I incorporated all the changes David, John and you suggested and >> started some sanity testing; >> Here's is the latest webrev: >> >> http://cr.openjdk.java.net/~amurillo/9/8030011/ >> >> Please review (don't forget to refresh each file on your browser) and >> let me know if I missed anything. >> thanks guys! >> -- Alejandro From volker.simonis at gmail.com Thu Apr 24 16:21:10 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 24 Apr 2014 18:21:10 +0200 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> Message-ID: And I'm not quite sure how to fix this in HotSpot. I first thought I could solve this with an anonymous union like: union { void* _relocbuf[ _relocbuf_size ]; Relocation _reloc; } Relocation* reloc() const { return &_reloc; } but unfortunately I can't put a Relocation into a union because it is not a POD (at least not with C++98). Any other ideas how we could fool GCC 4.9? I more and more think this should be fixed in GCC because I can imagine this will also break other code. Regards, Volker On Thu, Apr 24, 2014 at 5:10 PM, Volker Simonis wrote: > Wow, that was fast! > > I had just distilled a preprocessed version of 'assembler_x86.cpp' > down to about 1800 lines of code and guess what - I just discovered > and analyzed the strange way how RelocationHolder is allocated and > casted to a Relocation. > > Thanks for the patch and I agree with you that we should fix the HotSpot. > > Nevertheless I think gcc should be fixed as well. I shouldn't generate > incomplete functions like for "Assembler::reachable(AddressLiteral > adr)" in the example from my previous mail. > > Regards, > Volker > > > On Thu, Apr 24, 2014 at 4:51 PM, Andrew Haley wrote: >> On 04/24/2014 01:12 PM, Andrew Haley wrote: >>> On 04/24/2014 10:42 AM, Volker Simonis wrote: >>> >>>> could you pleas hold on a little bit. >>>> >>>> I just found out that for x86_64 we additionally need -fno-devirtualize >>>> when compiling 'assembler_x86.cpp'. Without the option, the compilation of >>>> "Assembler::reachable(AddressLiteral adr)" is totally broken: >>>> >>>> 0x7ffff6046910 <_ZN9Assembler9reachableE14AddressLiteral>: push %rbp >>>> 0x7ffff6046911 <_ZN9Assembler9reachableE14AddressLiteral+1>: mov >>>> %rsp,%rbp >>>> 0x7ffff6046914: data32 data32 nopw %cs:0x0(%rax,%rax,1) >>>> 0x7ffff6046920 <_ZN9Assembler19is_polling_page_farEv>: mov >>>> 0x12d7e69(%rip),%rax >>>> >>>> As you can see it only contains two instructions before it unconditionally >>>> falls into 'Assembler::is_polling_page_far()' >>>> >>>> Maybe we should do some more thorough tests on both, x86 and x86_64 with >>>> these settings to avoid follow-up changes. >>>> >>>> What bothers me however is the fact that we now get this sever error at >>>> several places in the OpenJDK while it doesn't seem to affect others and I >>>> can not see what's special in the coding that triggers the misbehavior? >>> >>> I think I might be able to. I'm debugging GCC now. >> >> I've found it, and I don't think this is a bug. GCC's interprocedural >> analysis looks at this type: >> >> class RelocationHolder VALUE_OBJ_CLASS_SPEC { >> friend class Relocation; >> friend class CodeSection; >> >> private: >> // this preallocated memory must accommodate all subclasses of Relocation >> // (this number is assertion-checked in Relocation::operator new) >> enum { _relocbuf_size = 5 }; >> void* _relocbuf[ _relocbuf_size ]; >> >> public: >> Relocation* reloc() const { return (Relocation*) &_relocbuf[0]; } >> ... >> >> and decides that no object of type Relocation is reachable from it. >> >> This is correct: strictly speaking, you can't portably copy a >> Relocation into an array of void* and then cast the void* to a >> Relocation* and expect to use it. >> >> It could be argued that -fno-strict-aliasing should mean that this >> analysis is incorrect, and all types are reachable. The attached >> patch fixes GCC to do that. However, I think it would be better to >> fix HotSpot so that it's correct C++. >> >> Andrew. >> >> >> Index: gcc/ipa-devirt.c >> =================================================================== >> --- gcc/ipa-devirt.c (revision 209656) >> +++ gcc/ipa-devirt.c (working copy) >> @@ -1362,8 +1362,9 @@ >> >> /* Only type inconsistent programs can have otr_type that is >> not part of outer type. */ >> - if (!contains_type_p (TREE_TYPE (base), >> - context->offset + offset2, *otr_type)) >> + if (flag_strict_aliasing >> + && !contains_type_p (TREE_TYPE (base), >> + context->offset + offset2, *otr_type)) >> { >> /* Use OTR_TOKEN = INT_MAX as a marker of probably type inconsistent >> code sequences; we arrange the calls to be builtin_unreachable >> @@ -1441,7 +1442,8 @@ >> gcc_assert (!POINTER_TYPE_P (context->outer_type)); >> /* Only type inconsistent programs can have otr_type that is >> not part of outer type. */ >> - if (!contains_type_p (context->outer_type, context->offset, >> + if (flag_strict_aliasing >> + && !contains_type_p (context->outer_type, context->offset, >> *otr_type)) >> { >> /* Use OTR_TOKEN = INT_MAX as a marker of probably type inconsistent >> >> >> >> >> From aph at redhat.com Thu Apr 24 16:41:05 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 24 Apr 2014 17:41:05 +0100 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> Message-ID: <53593EA1.2060308@redhat.com> On 04/24/2014 05:21 PM, Volker Simonis wrote: > And I'm not quite sure how to fix this in HotSpot. > > I first thought I could solve this with an anonymous union like: > > union { > void* _relocbuf[ _relocbuf_size ]; > Relocation _reloc; > } > Relocation* reloc() const { return &_reloc; } > > but unfortunately I can't put a Relocation into a union because it is > not a POD (at least not with C++98). > > Any other ideas how we could fool GCC 4.9? > > I more and more think this should be fixed in GCC because I can > imagine this will also break other code. Only code that is not legal C++, and GCC developers have historically been very reluctant to support that. So, it might not happen. AFAICS there is no C++98 way to embed a non-POD object in an object in this way. It could be done via a pointer, but that wastes some space. Andrew. From vladimir.kozlov at oracle.com Thu Apr 24 17:18:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Apr 2014 10:18:00 -0700 Subject: [8u20] RFR(XS): 8039975: SIGSEGV in MethodData::next_data(ProfileData*) In-Reply-To: <279DADDD-92BB-40E5-A03E-15409DF0A3C1@oracle.com> References: <279DADDD-92BB-40E5-A03E-15409DF0A3C1@oracle.com> Message-ID: <53594748.9050000@oracle.com> Good. Vladimir On 4/24/14 1:41 AM, Roland Westrelin wrote: > 8u20 backport request. The change was pushed to jdk9 a week ago and nightly testing hasn?t shown any problem. > > The change applies cleanly to 8u. > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eb8897b2687e > https://bugs.openjdk.java.net/browse/JDK-8041110 > > Roland. > From christian.thalinger at oracle.com Thu Apr 24 18:17:43 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Apr 2014 08:17:43 -1000 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <535924D9.2070404@redhat.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> Message-ID: <5D71C5FD-6E4B-4E32-8D3E-A8500432FE8E@oracle.com> On Apr 24, 2014, at 4:51 AM, Andrew Haley wrote: > On 04/24/2014 01:12 PM, Andrew Haley wrote: >> On 04/24/2014 10:42 AM, Volker Simonis wrote: >> >>> could you pleas hold on a little bit. >>> >>> I just found out that for x86_64 we additionally need -fno-devirtualize >>> when compiling 'assembler_x86.cpp'. Without the option, the compilation of >>> "Assembler::reachable(AddressLiteral adr)" is totally broken: >>> >>> 0x7ffff6046910 <_ZN9Assembler9reachableE14AddressLiteral>: push %rbp >>> 0x7ffff6046911 <_ZN9Assembler9reachableE14AddressLiteral+1>: mov >>> %rsp,%rbp >>> 0x7ffff6046914: data32 data32 nopw %cs:0x0(%rax,%rax,1) >>> 0x7ffff6046920 <_ZN9Assembler19is_polling_page_farEv>: mov >>> 0x12d7e69(%rip),%rax >>> >>> As you can see it only contains two instructions before it unconditionally >>> falls into 'Assembler::is_polling_page_far()' >>> >>> Maybe we should do some more thorough tests on both, x86 and x86_64 with >>> these settings to avoid follow-up changes. >>> >>> What bothers me however is the fact that we now get this sever error at >>> several places in the OpenJDK while it doesn't seem to affect others and I >>> can not see what's special in the coding that triggers the misbehavior? >> >> I think I might be able to. I'm debugging GCC now. > > I've found it, and I don't think this is a bug. GCC's interprocedural > analysis looks at this type: > > class RelocationHolder VALUE_OBJ_CLASS_SPEC { > friend class Relocation; > friend class CodeSection; > > private: > // this preallocated memory must accommodate all subclasses of Relocation > // (this number is assertion-checked in Relocation::operator new) > enum { _relocbuf_size = 5 }; > void* _relocbuf[ _relocbuf_size ]; Why is it void* after all? Can?t it just be a Relocation*? Not sure if that would fix the problem, though. > > public: > Relocation* reloc() const { return (Relocation*) &_relocbuf[0]; } > ... > > and decides that no object of type Relocation is reachable from it. > > This is correct: strictly speaking, you can't portably copy a > Relocation into an array of void* and then cast the void* to a > Relocation* and expect to use it. > > It could be argued that -fno-strict-aliasing should mean that this > analysis is incorrect, and all types are reachable. The attached > patch fixes GCC to do that. However, I think it would be better to > fix HotSpot so that it's correct C++. > > Andrew. > > > Index: gcc/ipa-devirt.c > =================================================================== > --- gcc/ipa-devirt.c (revision 209656) > +++ gcc/ipa-devirt.c (working copy) > @@ -1362,8 +1362,9 @@ > > /* Only type inconsistent programs can have otr_type that is > not part of outer type. */ > - if (!contains_type_p (TREE_TYPE (base), > - context->offset + offset2, *otr_type)) > + if (flag_strict_aliasing > + && !contains_type_p (TREE_TYPE (base), > + context->offset + offset2, *otr_type)) > { > /* Use OTR_TOKEN = INT_MAX as a marker of probably type inconsistent > code sequences; we arrange the calls to be builtin_unreachable > @@ -1441,7 +1442,8 @@ > gcc_assert (!POINTER_TYPE_P (context->outer_type)); > /* Only type inconsistent programs can have otr_type that is > not part of outer type. */ > - if (!contains_type_p (context->outer_type, context->offset, > + if (flag_strict_aliasing > + && !contains_type_p (context->outer_type, context->offset, > *otr_type)) > { > /* Use OTR_TOKEN = INT_MAX as a marker of probably type inconsistent From david.r.chase at oracle.com Thu Apr 24 18:52:04 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 24 Apr 2014 14:52:04 -0400 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <53593EA1.2060308@redhat.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> <53593EA1.2060308@redhat.com> Message-ID: <71D3D6AE-D87E-4C79-BD92-9C2BA0D0249F@oracle.com> Could you do a placement new into that array of void*? I can't even remember the syntax, but I recall the semantics. David On 2014-04-24, at 12:41 PM, Andrew Haley wrote: > On 04/24/2014 05:21 PM, Volker Simonis wrote: >> And I'm not quite sure how to fix this in HotSpot. >> >> I first thought I could solve this with an anonymous union like: >> >> union { >> void* _relocbuf[ _relocbuf_size ]; >> Relocation _reloc; >> } >> Relocation* reloc() const { return &_reloc; } >> >> but unfortunately I can't put a Relocation into a union because it is >> not a POD (at least not with C++98). >> >> Any other ideas how we could fool GCC 4.9? >> >> I more and more think this should be fixed in GCC because I can >> imagine this will also break other code. > > Only code that is not legal C++, and GCC developers have historically > been very reluctant to support that. So, it might not happen. > > AFAICS there is no C++98 way to embed a non-POD object in an object in this > way. It could be done via a pointer, but that wastes some space. > > Andrew. > From john.r.rose at oracle.com Thu Apr 24 19:38:20 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 Apr 2014 12:38:20 -0700 Subject: FORK In-Reply-To: References: Message-ID: (Moving this conversation from http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-April/005745.html to hotspot-dev.) On Apr 24, 2014, at 12:44 AM, Charles Oliver Nutter wrote: > What would it take to make Hotspot forkable? Obviously we'd need to > pause all VM threads and restarting them on the other side (or perhaps > a prefork mode that doesn't spin up threads?) but I know there's > challenges with signal handlers etc. > > I ask for a few reasons... > > * Dalvik has shown what you can do with a "larval" preforking setup. > This is a big reason why Android apps can run in such a small amount > of memory and start up so quickly. They had to do a lot of work to segregate sharable stuff from non-sharable. I think it would be a useful exercise for us, but it is difficult. We have pointers everywhere, and every pointer is a chance to break sharing (if it points to something that a process needs to move). They also have the luxury of running on exactly one Unix OS, whose code they can adjust. Java runs everywhere, so it cannot easily make deep demands on the OS, like "don't give performance surprises when we fork our VM". But, two other reasons to work on this problem is data sharing (class and/or application) and AOT compilation; both win bigger to the extent they can can work with untransposed data, directly out of a file (= shared RO memory). > * Startup time! If we could fork an already-hot JVM, we could hit the > ground running with *every* command, *and* still have truly separate > processes. Yup. How much does nailgun address this use case, already? That is, what don't you get today with pre-warmed JVMs? > * There's a lot of development and scaling patterns that depend on > forking, and we get constant questions about forking on JRuby. Over time, we have experimented at length with both forking and single-process multi-tasking (MVM). Since MVM doesn't make as many demands on the operating system for complex operations, we are more comfortable with that approach. > * Rubinius -- a Ruby VM with partially-concurrent GC, a > signal-handling thread, JIT threads, and real parallel Ruby threads -- > supports forking. They bring the threads to a safe point, fork, and > restart them on the other side. Color me jealous. Me too. It's a cute move. How many OS's does that trick work well on? > So...given that OpenJDK is rapidly expanding into smaller-profile > devices and new languages and development patterns, perhaps it's time > to make it fit into the UNIX philosophy. Where do we start? In my opinion, with CDS and AOT. And with squinting suspiciously at our data structures. (But when I say that it scares folks; who knows where that will end!? :-) ) But a forkable-VM experiment, as a patch within MLVM project, would be a lightweight and easy thing to try. It might not produce a usable result, but would at least illuminate the problem areas. ? John From christian.thalinger at oracle.com Thu Apr 24 20:33:31 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Apr 2014 10:33:31 -1000 Subject: Undefined behaviour in hotspot In-Reply-To: References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> Message-ID: On Apr 21, 2014, at 10:41 PM, Volker Simonis wrote: > Hi, > > I think the simplest and safest fix would be to make encoding() (and > all the corresponding functions) static functions which take a > Register as argument like: > > static int encoding(const RegisterImpl* r) { assert(is_valid(r), > "invalid register"); return (intptr_t)r; } > > This wouldn't waste any more memory and it would be fully C++ > compliant at the price of a slightly more verbose usage: > > 2577 void Assembler::push(Register src) { > 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); > 2579 > > And of course this would work with any compiler. > > What do you think? I?d rather make Register a real C++ class with an _encoding field. There are not that many registers used or allocated that it would make a big difference in memory usage. > > Regards, > Volker > > > On Mon, Apr 21, 2014 at 8:30 PM, Omair Majid wrote: >> * David Chase [2014-04-21 13:53]: >>> >>> On 2014-04-21, at 12:17 PM, Omair Majid wrote: >>>> I can ping them, but honestly, I wouldn't be surprised at all if the >>>> only response I get is "no". I don't have any official communication >>>> channels with them, so my input is not any different from anyone else's. >>>> >>>> Can you elaborate on what flag/pragma you have in mind? Just something >>>> to play nice with NULL pointers? >>> >>> Not just null pointers. Also optimizations that pretend that integer overflow >>> doesn't happen (i.e., optimizations that change program behavior when it >>> does) also need to be disabled. >> >> My knowledge of C/C++ is fairly limited, so please bear with me. There >> are a few relevant options already listed in 'man gcc': >> >> -Wstrict-overflow=n >> This option is only active when -fstrict-overflow is active. >> It warns about cases where the compiler optimizes based on >> the assumption that signed overflow does not occur >> >> -fwrapv >> This option instructs the compiler to assume that signed >> arithmetic overflow of addition, subtraction and >> multiplication wraps around using twos-complement >> representation. >> >> Do you mean others? >> >> Thanks, >> Omair >> >> -- >> PGP Key: 66484681 (http://pgp.mit.edu/) >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.r.chase at oracle.com Thu Apr 24 20:49:16 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 24 Apr 2014 16:49:16 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <5355CC9D.3090609@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> Message-ID: <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> Revised webrev. Webrev: http://cr.openjdk.java.net/~drchase/8037816/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8037816 Testing: built everywhere that JPRT builds, personally checked on Mountain Lion (gcc), Mavericks (clang), Linux-32 (gcc), Linux-64 (gcc), Solaris-11-sparc (solstudio). Before you look at the webrev, four things: (0) I'll handle copyrights in an automated post-pass, if that's okay. In defense of its absurd size, this patch is wide but not very deep; the most common changes were: sprinkle in calls to p2i (277 lines) MUTE_WARNINGS_FOR_GCC (128 lines) white space (120 lines) print_raw[_cr] (108) print_cr() (68) PRAGMA_ defines or push/pop/diagnostic macros. (90) matching format/arg for SIZE_FORMAT (47) ATTRIBUTE_PRINTF (26) Other macro definitions (#endif, #else, remaining format macros) (24) Added "%s" format strings to resolve-nonliteral-string warnings. (20) Other instances of _FORMAT (may be format change or cast arg change) (19) Comments (11) Stray copyright updates (6) "fmt_" macros (6) "PRI.PTR" (5) I've appended the remaining uncategorized added/changed lines at the bottom. (1) the revised change set leaves all the format checking enabled as much as possible for gcc and clang compilation, and all gross format errors have been repaired. This includes our own functions and methods with printf-like behavior. Not only with this build with clang, it should generally tend to continue to build with clang. No new big format mistakes (*) will be allowed anywhere, and new little mistakes will be warned except in those files currently marked with PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC. The intent is that those files will get cleaned up incrementally (one by one, maybe dozen by dozen). (*) Defined to be: mismatched format/arg lengths, empty format string, non-literal format string. (2) there will be additional RFEs covering code I was unsure of; it's as broken/unportable as it ever was, but now we know it. (a) For two files, src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp the macro ATTRIBUTE_PRINTF(x,y) is defined to be empty above the header inclusions; the format strings are wrong in peculiar ways, and they are buried in macros. This is conditional on not-clang, because clang (1) doesn?t warn about the formats in the same way and (2) has a problem with conflicting definitions before includes and within precompiled header files. (b) The xsl file used to generate some of the jvmti sources now generates a mute-warnings macro after the header inclusions, because gcc doesn't like some of the format/arg pairs in that generated code, and fixing it was beyond me. (3) these are the parts/questions I think need opinions/resolution: (a) print_raw(foo) vs print(?%s?, foo)? (b) print_cr() vs print_raw_cr(??) vs print_cr(?%s?, ??) vs cr(). Note that some of our format-related constructors demand a format, hence they go with print("%s", "") when they start empty. (c) Parameter was passed with no format (two cases). I removed it. What do we really want here? --- old/src/share/vm/opto/gcm.cpp 2014-04-23 14:08:48.000000000 -0400 +++ new/src/share/vm/opto/gcm.cpp 2014-04-23 14:08:47.000000000 -0400 @@ -2014,7 +2014,7 @@ tty->print("%s: %d trip_count: %6.0f freq: %6.0f\n", _depth == 0 ? "Method" : "Loop", _id, trip_count(), _freq); for (int i = 0; i < _depth; i++) tty->print(" "); - tty->print(" members:", _id); + tty->print(" members:"); int k = 0; for (int i = 0; i < _members.length(); i++) { if (k++ >= 6) { --- old/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 +++ new/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 @@ -634,7 +636,7 @@ } void ParametersTypeData::print_data_on(outputStream* st, const char* extra) const { - st->print("parameter types", extra); + st->print("parameter types"); // FIXME extra ignored? _parameters.print_data_on(st); } --------------------------------------------------------------------- Among the changes/observations: int64_t and jlong are NOT NOT NOT the same type on all platforms. I tested the various pragma/macros idioms for clang as far back as 3.1, gcc as far back as 4.2 . Added some formatting macros: #define UINT64_FORMAT_X "%" PRIx64 #define PTR_FORMAT_W(width) "%" #width PRIxPTR #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR #define SIZE_FORMAT_X "%" PRIxPTR The garbage collector seems to be a little bit nutty about the uintx type. Look at some of the command-line options parameters that are uintx, in many cases a uint8_t would be completely adequate. The mute-gcc macro: #define PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC _Pragma("GCC diagnostic ignored \"-Wformat\"") _Pragma("GCC diagnostic error \"-Wformat-nonliteral\"") _Pragma("GCC diagnostic error \"-Wformat-security\"") --------------------------------------------------------------------- + warning("Failed to reserve shared memory (errno = %d).", errno); + warning("Failed to attach shared memory (errno = %d).", err); + _level, (int) MaxBCEAEstimateLevel); + tty->print_cr("code size (%d) exceeds MaxBCEAEstimateSize (%d).", + method()->code_size(), (int) MaxBCEAEstimateSize); + out->print(" %d %s", (int)(dp_to_di(vdata->dp() + in_bytes(vdata->receiver_offset(i))) / sizeof(intptr_t)), k->name()->as_quoted_ascii()); + out->print(" %d %s", (int)(dp_to_di(vdata->dp() + in_bytes(vdata->receiver_offset(i))) / sizeof(intptr_t)), k->name()->as_quoted_ascii()); +inline void assert_property(bool b, const char* msg, TRAPS) { + tty->print_cr(" #%d %s = %dK (hdr %d%%, loc %d%%, code %d%%, stub %d%%, [oops %d%%, metadata %d%%, data %d%%, pcs %d%%])", + (int)(total() / K), + mark_stack_size, (uintx) 1, MarkStackSizeMax); + MarkStackSize, (uintx) 1, MarkStackSizeMax); + (reserved().byte_size()/K), reserved().byte_size()); + (working_promoted/K), working_promoted); + (used_in_bytes()/K), used_in_bytes()); + (min_gen_size()/K), min_gen_size()); + (max_contraction/K), max_contraction); + (policy->promo_increment(max_contraction)/K), + err_msg("MaxTenuringThreshold should be 0 or markOopDesc::max_age + 1, but is %d", (int) MaxTenuringThreshold)); + (int) active_workers, (int) new_active_workers, (int) prev_active_workers, + (int) active_workers_by_JT, (int) active_workers_by_heap_size); + "of %d%%", (int) GCTimeLimit); + (int) GCTimeLimit, gc_overhead_limit_count()); + uintx age = 1; + desired_survivor_size*oopSize, (uintx) result, MaxTenuringThreshold); + age, sizes[age]*oopSize, total*oopSize); + gclog_or_tty->print_cr( + demand, old_rate, rate, new_rate, old_desired, _desired); + st->print_cr("%d not in CP[*]?", i); + st->print_cr("%d not in OBJ[*]?", i); + st->print(" ", kind, i2); + st->print("parameter types"); // FIXME extra ignored? + tty->print(" members:"); + (int) (hi-lo+1), nsing, _max_switch_depth, _est_switch_depth); + (int) _verify_full_passes); + (int) _verify_counter, (int) _verify_full_passes); + const char * trace_mesg, TRAPS) { + (unsigned int) (MarkStackSize / K), (unsigned int) (MarkStackSizeMax / K)); + tty->print_cr("ConcGCThreads: %u", (unsigned int) ConcGCThreads); + " based on pause goal of %d (ms)", (int) MaxGCPauseMillis); + (unsigned int) (MarkStackSize / K), (unsigned int) (MarkStackSizeMax / K)); + tty->print_cr("ConcGCThreads: %u", (unsigned int) ConcGCThreads); +inline void Events::log(Thread* thread, const char* format, ...) { + return (intptr_t) p; +} From John.Coomes at oracle.com Thu Apr 24 20:52:41 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 24 Apr 2014 13:52:41 -0700 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <5357265A.5090603@oracle.com> References: <5345E28F.5050108@oracle.com> <21329.51306.466788.318656@mykonos.us.oracle.com> <535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com> <5356FE5A.4000005@oracle.com> <53570573.5070205@oracle.com> <5357265A.5090603@oracle.com> Message-ID: <21337.31129.618939.569412@mykonos.us.oracle.com> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: > ... > I think I incorporated all the changes David, John and you suggested and > started some sanity testing; > Here's is the latest webrev: > > http://cr.openjdk.java.net/~amurillo/9/8030011/ > > Please review (don't forget to refresh each file on your browser) and > let me know if I missed anything. > thanks guys! Looks good. Might be nice to shorten the rest of the assert messages in vm_version.cpp to match the one for the build number, e.g., "bad major version"). -John From alejandro.murillo at oracle.com Thu Apr 24 21:28:11 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 24 Apr 2014 15:28:11 -0600 Subject: RFR 8030011: Update Hotspot version string output In-Reply-To: <21337.31129.618939.569412@mykonos.us.oracle.com> References: <5345E28F.5050108@oracle.com> <21329.51306.466788.318656@mykonos.us.oracle.com> <535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com> <5356FE5A.4000005@oracle.com> <53570573.5070205@oracle.com> <5357265A.5090603@oracle.com> <21337.31129.618939.569412@mykonos.us.oracle.com> Message-ID: <535981EB.9030403@oracle.com> On 4/24/2014 2:52 PM, John Coomes wrote: > Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: >> ... >> I think I incorporated all the changes David, John and you suggested and >> started some sanity testing; >> Here's is the latest webrev: >> >> http://cr.openjdk.java.net/~amurillo/9/8030011/ >> >> Please review (don't forget to refresh each file on your browser) and >> let me know if I missed anything. >> thanks guys! > Looks good. Might be nice to shorten the rest of the assert messages > in vm_version.cpp to match the one for the build number, e.g., "bad > major version"). > > -John Will do, thanks John -- Alejandro From Peter.B.Kessler at Oracle.COM Thu Apr 24 22:46:57 2014 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 24 Apr 2014 15:46:57 -0700 Subject: FORK In-Reply-To: References: Message-ID: <53599461.7090105@Oracle.COM> On 04/24/14 12:38, John Rose wrote: > (Moving this conversation from http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-April/005745.html to hotspot-dev.) > > On Apr 24, 2014, at 12:44 AM, Charles Oliver Nutter wrote: > >> What would it take to make Hotspot forkable? Obviously we'd need to >> pause all VM threads and restarting them on the other side (or perhaps >> a prefork mode that doesn't spin up threads?) but I know there's >> challenges with signal handlers etc. >> >> I ask for a few reasons... >> >> * Dalvik has shown what you can do with a "larval" preforking setup. >> This is a big reason why Android apps can run in such a small amount >> of memory and start up so quickly. > > They had to do a lot of work to segregate sharable stuff from non-sharable. I think it would be a useful exercise for us, but it is difficult. We have pointers everywhere, and every pointer is a chance to break sharing (if it points to something that a process needs to move). > > They also have the luxury of running on exactly one Unix OS, whose code they can adjust. Java runs everywhere, so it cannot easily make deep demands on the OS, like "don't give performance surprises when we fork our VM". > > But, two other reasons to work on this problem is data sharing (class and/or application) and AOT compilation; both win bigger to the extent they can can work with untransposed data, directly out of a file (= shared RO memory). > >> * Startup time! If we could fork an already-hot JVM, we could hit the >> ground running with *every* command, *and* still have truly separate >> processes. > > Yup. How much does nailgun address this use case, already? That is, what don't you get today with pre-warmed JVMs? What I remember about nailgun is that everything runs in the same server process, separated only by classloaders. That's obviously good enough for some applications. But it has a lot of security issues (the nailgun web page points that out). It also doesn't protect you from memory pigs running in the same VM causing a lot of GC activity, etc. And if the VM crashes it takes down everything running in that process. "Truly separate processes" as Charlie asks for would solve many of those problems. Maybe by "pre-warmed JVM's" you mean a service that starts (and warms up) a JVM for you to run on when you eventually type a "java" command. That would just (?) take cycles and memory. ... peter >> * There's a lot of development and scaling patterns that depend on >> forking, and we get constant questions about forking on JRuby. > > Over time, we have experimented at length with both forking and single-process multi-tasking (MVM). Since MVM doesn't make as many demands on the operating system for complex operations, we are more comfortable with that approach. > >> * Rubinius -- a Ruby VM with partially-concurrent GC, a >> signal-handling thread, JIT threads, and real parallel Ruby threads -- >> supports forking. They bring the threads to a safe point, fork, and >> restart them on the other side. Color me jealous. > > Me too. It's a cute move. How many OS's does that trick work well on? > >> So...given that OpenJDK is rapidly expanding into smaller-profile >> devices and new languages and development patterns, perhaps it's time >> to make it fit into the UNIX philosophy. Where do we start? > > In my opinion, with CDS and AOT. > > And with squinting suspiciously at our data structures. (But when I say that it scares folks; who knows where that will end!? :-) ) > > But a forkable-VM experiment, as a patch within MLVM project, would be a lightweight and easy thing to try. It might not produce a usable result, but would at least illuminate the problem areas. > > ? John > From john.r.rose at oracle.com Fri Apr 25 00:10:09 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 Apr 2014 17:10:09 -0700 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <53593EA1.2060308@redhat.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> <53593EA1.2060308@redhat.com> Message-ID: <3645314C-08FB-467D-92A4-C59775FC7093@oracle.com> On Apr 24, 2014, at 9:41 AM, Andrew Haley wrote: > On 04/24/2014 05:21 PM, Volker Simonis wrote: >> And I'm not quite sure how to fix this in HotSpot. >> >> I first thought I could solve this with an anonymous union like: >> >> union { >> void* _relocbuf[ _relocbuf_size ]; >> Relocation _reloc; >> } >> Relocation* reloc() const { return &_reloc; } >> >> but unfortunately I can't put a Relocation into a union because it is >> not a POD (at least not with C++98). >> >> Any other ideas how we could fool GCC 4.9? >> >> I more and more think this should be fixed in GCC because I can >> imagine this will also break other code. > > Only code that is not legal C++, and GCC developers have historically > been very reluctant to support that. So, it might not happen. > > AFAICS there is no C++98 way to embed a non-POD object in an object in this > way. It could be done via a pointer, but that wastes some space. That design (RelocationHolder, bitwise non-PODS copy) was committed 1998-02-27. (Full discl.?courtesy of yours truly.) It may well be illegal C++98. Sorry it got in your way. We've seen occasional problems with it before at high optimization levels. And I agree that current C++ standards make this doubtful usage. The goal of it (as nearby comments suggest) is to allow all three of these things to be true at once: - we are traversing a stored stream of N records - each record can have a class with class-specific behaviors (virtual methods, vtbl) - storage consumption is O(1), and there are O(1) mallocs and frees This can be done easily (I think it is still the case) by allocating a suitable buffer in the stream object, and using placed new to create each successive record produced by the stream. These guys can be non-PODS with virtuals. (I hope that's still the case...) A fourth goal makes everything more dicey: - buffers containing records can be copied around without malloc; functions can bitwise-return PODS buffers containing the non-PODS This is a hack for allowing functions to create a non-PODS record (with virtuals, etc.) without allocating it. Perhaps we lean too hard on the fourth point; it's hard to tell without detailed investigation. Easy workaround: Functions which need to do this thing could require the caller to pass a scratch buffer (RelocationHolder) to use with placed new, if a new record is to be returned. Perhaps also there are better, more standard ways to do this sort of thing. ? John P.S. As a separate detail, the stream of 16-bit data, as a way to reduce size, was already out of date in 1998, and I regret the cleverness I spent enhancing it. I've wanted for a long time to rewrite that stuff using compressedStream.hpp as a carrier for the bits. From john.r.rose at oracle.com Fri Apr 25 00:13:39 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 Apr 2014 17:13:39 -0700 Subject: FORK In-Reply-To: <53599461.7090105@Oracle.COM> References: <53599461.7090105@Oracle.COM> Message-ID: <3F79D813-FEC5-4E6C-B7E6-1C491863F67C@oracle.com> On Apr 24, 2014, at 3:46 PM, "Peter B. Kessler" wrote: > "Truly separate processes" as Charlie asks for would solve many of those problems. Maybe by "pre-warmed JVM's" you mean a service that starts (and warms up) a JVM for you to run on when you eventually type a "java" command. That would just (?) take cycles and memory. ...Showing my ignorance of nailgun. From the descriptions, I assumed it was using that technique. ? John From john.r.rose at oracle.com Fri Apr 25 01:04:31 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 Apr 2014 18:04:31 -0700 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> Message-ID: <245C208D-C35B-4508-A28A-086C9348655A@oracle.com> On Apr 24, 2014, at 1:49 PM, David Chase wrote: > (3) these are the parts/questions I think need opinions/resolution: > > (a) print_raw(foo) vs print(?%s?, foo)? This seems to want some API clarification: What does print_raw really mean, etc... But if you start improving APIs and refactoring uses more than absolutely necessary you'll never get this work done. I favor print_raw(foo) as a more direct (but now legal) rendering of what the programmer wrote. I sympathize partially with David H.'s objection to print_raw(s) over print("%s", s), but the programmer was not writing a format string here, so don't introduce one. And sorry, David, I don't buy that printf("%s", s) obviates puts(s). The latter produces more compact code. I would favor a rename of print_raw to prints or print_str, but *not* in this change set. Replacing print_raw feels like "why don't you clean it up as long as you are changing the code". I think you are right to resist the temptation to do cleanups in this change set, because it is already absurdly large just doing the bare minimum. > (b) print_cr() vs print_raw_cr(??) vs print_cr(?%s?, ??) vs cr(). > Note that some of our format-related constructors demand a format, hence they go > with print("%s", "") when they start empty. Applying the above reasoning, I do not support introducing "print_cr()" as an alias for "cr()". If we don't like the name of "cr()" we should change it in a cleanup. Adding an alias is (a) API tweaking, and (b) leads to pseudo-information in the code which will need cleaning later. (By pseudo-information, I mean what amounts to a free choice between cr and print_cr injecting a random bit at each use point, and causing future programmers to muse, "he must have a reason for making the distinction; some tool or audience must need that information".) > (c) Parameter was passed with no format (two cases). I removed it. What do we really want here? > > --- old/src/share/vm/opto/gcm.cpp 2014-04-23 14:08:48.000000000 -0400 > +++ new/src/share/vm/opto/gcm.cpp 2014-04-23 14:08:47.000000000 -0400 > @@ -2014,7 +2014,7 @@ > tty->print("%s: %d trip_count: %6.0f freq: %6.0f\n", > _depth == 0 ? "Method" : "Loop", _id, trip_count(), _freq); > for (int i = 0; i < _depth; i++) tty->print(" "); > - tty->print(" members:", _id); > + tty->print(" members:"); > int k = 0; > for (int i = 0; i < _members.length(); i++) { > if (k++ >= 6) { Correct change. The _id value is already printed above. > --- old/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 > +++ new/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 > @@ -634,7 +636,7 @@ > } > > void ParametersTypeData::print_data_on(outputStream* st, const char* extra) const { > - st->print("parameter types", extra); > + st->print("parameter types"); // FIXME extra ignored? > _parameters.print_data_on(st); > } That's a reasonable fix. I think Roland will want to take a look at it. > --------------------------------------------------------------------- > > Among the changes/observations: > > int64_t and jlong are NOT NOT NOT the same type on all platforms. Lovely. C has favored us with not only signed and unsigned types, but "unspecified" types as a the portable superposition of both. Truly the sign of int64_t is the silence of the Tao. > I tested the various pragma/macros idioms for clang as far back as 3.1, gcc as far back as 4.2 . > > Added some formatting macros: > #define UINT64_FORMAT_X "%" PRIx64 > #define PTR_FORMAT_W(width) "%" #width PRIxPTR > #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR > #define SIZE_FORMAT_X "%" PRIxPTR A good step. That large herd of macros may need further taming later. Your thoughts on this (now that it's all in your head) would be welcome. > The garbage collector seems to be a little bit nutty about the uintx type. > Look at some of the command-line options parameters that are uintx, > in many cases a uint8_t would be completely adequate. > > The mute-gcc macro: > #define PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC _Pragma("GCC diagnostic ignored \"-Wformat\"") _Pragma("GCC diagnostic error \"-Wformat-nonliteral\"") _Pragma("GCC diagnostic error \"-Wformat-security\"") > > --------------------------------------------------------------------- > > + warning("Failed to reserve shared memory (errno = %d).", errno); I'm not sure what to do with the snippets at the end of your note, except to say I agree that it is reasonable to insert "(int)" casts for arguments to "%d", at least when there is reason to believe that the programmer would accept a format string containing a truncated value. The presence of "%d" strongly suggests the programmer expects a small int; same with "%u". And truncating the value does not add a bug; at most the risk is of continuing to hide a smaller bug. ? John From david.r.chase at oracle.com Fri Apr 25 01:48:30 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 24 Apr 2014 21:48:30 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <245C208D-C35B-4508-A28A-086C9348655A@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <245C208D-C35B-4508-A28A-086C9348655A@oracle.com> Message-ID: <97FD4143-6B61-4E67-B1FA-8500F2722CB3@oracle.com> On 2014-04-24, at 9:04 PM, John Rose wrote: > On Apr 24, 2014, at 1:49 PM, David Chase wrote: > >> (3) these are the parts/questions I think need opinions/resolution: >> >> (a) print_raw(foo) vs print(?%s?, foo)? TBD, pending other comments, I think. >> (b) print_cr() vs print_raw_cr(??) vs print_cr(?%s?, ??) vs cr(). >> Note that some of our format-related constructors demand a format, hence they go >> with print("%s", "") when they start empty. > > Applying the above reasoning, I do not support introducing "print_cr()" as an alias for "cr()". If we don't like the name of "cr()" we should change it in a cleanup. Adding an alias is (a) API tweaking, and (b) leads to pseudo-information in the code which will need cleaning later. > > (By pseudo-information, I mean what amounts to a free choice between cr and print_cr injecting a random bit at each use point, and causing future programmers to muse, "he must have a reason for making the distinction; some tool or audience must need that information".) I know exactly what you mean. I did not remove prints of the empty string because someone must have had some reason for doing this, right? I'll replace all instances of print_cr() with cr() and remove print_cr(). >> I tested the various pragma/macros idioms for clang as far back as 3.1, gcc as far back as 4.2 . >> >> Added some formatting macros: >> #define UINT64_FORMAT_X "%" PRIx64 >> #define PTR_FORMAT_W(width) "%" #width PRIxPTR >> #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR >> #define SIZE_FORMAT_X "%" PRIxPTR > > A good step. That large herd of macros may need further taming later. Your thoughts on this (now that it's all in your head) would be welcome. I don't know for sure; it seemed like a hodge-podge. I'll think some more. >> + warning("Failed to reserve shared memory (errno = %d).", errno); > > I'm not sure what to do with the snippets at the end of your note, except to say I agree that it is reasonable to insert "(int)" casts for arguments to "%d", at least when there is reason to believe that the programmer would accept a format string containing a truncated value. The presence of "%d" strongly suggests the programmer expects a small int; same with "%u". And truncating the value does not add a bug; at most the risk is of continuing to hide a smaller bug. I've gone back and forth on this; on the one hand casting to (int) for a %d format "doesn't add any new truncation", but it gives the impression of intent. I was a little unsure whether we ever need to worry about dealing with more than 2 trillion bytes (a billion K) of storage, but it seemed remotely possible, so I actually backed out a bunch of changes for %d K and converted them to UINTX_FORMAT K or SIZE_FORMAT K, depending on the type coming in. David From christian.thalinger at oracle.com Fri Apr 25 02:10:28 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Apr 2014 16:10:28 -1000 Subject: Undefined behaviour in hotspot In-Reply-To: References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> Message-ID: On Apr 24, 2014, at 10:33 AM, Christian Thalinger wrote: > > On Apr 21, 2014, at 10:41 PM, Volker Simonis wrote: > >> Hi, >> >> I think the simplest and safest fix would be to make encoding() (and >> all the corresponding functions) static functions which take a >> Register as argument like: >> >> static int encoding(const RegisterImpl* r) { assert(is_valid(r), >> "invalid register"); return (intptr_t)r; } >> >> This wouldn't waste any more memory and it would be fully C++ >> compliant at the price of a slightly more verbose usage: >> >> 2577 void Assembler::push(Register src) { >> 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); >> 2579 >> >> And of course this would work with any compiler. >> >> What do you think? > > I?d rather make Register a real C++ class with an _encoding field. There are not that many registers used or allocated that it would make a big difference in memory usage. I filed: https://bugs.openjdk.java.net/browse/JDK-8041796 and here is an initial cut of the changes: http://cr.openjdk.java.net/~twisti/8041796/webrev.00/ Right now it?s x86 only and of course must be done for all the other architectures as well. By inspecting some Clang generated code it seems the resulting code is the same in most (all?) cases. > >> >> Regards, >> Volker >> >> >> On Mon, Apr 21, 2014 at 8:30 PM, Omair Majid wrote: >>> * David Chase [2014-04-21 13:53]: >>>> >>>> On 2014-04-21, at 12:17 PM, Omair Majid wrote: >>>>> I can ping them, but honestly, I wouldn't be surprised at all if the >>>>> only response I get is "no". I don't have any official communication >>>>> channels with them, so my input is not any different from anyone else's. >>>>> >>>>> Can you elaborate on what flag/pragma you have in mind? Just something >>>>> to play nice with NULL pointers? >>>> >>>> Not just null pointers. Also optimizations that pretend that integer overflow >>>> doesn't happen (i.e., optimizations that change program behavior when it >>>> does) also need to be disabled. >>> >>> My knowledge of C/C++ is fairly limited, so please bear with me. There >>> are a few relevant options already listed in 'man gcc': >>> >>> -Wstrict-overflow=n >>> This option is only active when -fstrict-overflow is active. >>> It warns about cases where the compiler optimizes based on >>> the assumption that signed overflow does not occur >>> >>> -fwrapv >>> This option instructs the compiler to assume that signed >>> arithmetic overflow of addition, subtraction and >>> multiplication wraps around using twos-complement >>> representation. >>> >>> Do you mean others? >>> >>> Thanks, >>> Omair >>> >>> -- >>> PGP Key: 66484681 (http://pgp.mit.edu/) >>> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From headius at headius.com Fri Apr 25 02:22:10 2014 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 25 Apr 2014 10:22:10 +0800 Subject: FORK In-Reply-To: References: Message-ID: Thanks for moving the thread John! On Fri, Apr 25, 2014 at 3:38 AM, John Rose wrote: >> * Dalvik has shown what you can do with a "larval" preforking setup. >> This is a big reason why Android apps can run in such a small amount >> of memory and start up so quickly. > > They had to do a lot of work to segregate sharable stuff from non-sharable. I think it would be a useful exercise for us, but it is difficult. We have pointers everywhere, and every pointer is a chance to break sharing (if it points to something that a process needs to move). Perhaps I'll belie my knowledge of kernel-level memory management here, but I'm confused by this. Wouldn't all such pointers be indirected through a kernel-level virtual memory table? And wouldn't any moves be done transparently behind that table? I'm thinking in terms of vfork here, of course. I mean...I know Rubinius isn't going back and fixing up pointers after a fork, and they've got plenty of direct memory references in both C++ and jitted code. To be clear, I'm also not (initially) interested copy-on-write capabilities, though there's interesting opportunities there, nor am I interested in forking as a means to have many small child processes sharing a large amount of read-only memory. I just want to easily carry bootstrapped runtime + jitted code to the children. > They also have the luxury of running on exactly one Unix OS, whose code they can adjust. Java runs everywhere, so it cannot easily make deep demands on the OS, like "don't give performance surprises when we fork our VM". I'm also not necessarily interested in this as a standard or official Java/JVM feature. I am interested in exactly one case: being able to preboot OpenJDK and fork it. I'd even be satisfied if it only worked on a few platforms initially, because 99% of our users are on a combination of OS X and/or Linux64. > But, two other reasons to work on this problem is data sharing (class and/or application) and AOT compilation; both win bigger to the extent they can can work with untransposed data, directly out of a file (= shared RO memory). Class data sharing and AOT address some portion of fork's use cases, indeed. For my purposes, those would be enough. But the application data sharing, even as a one-off fork, is a commonly-exploited case among Rubyists, Pythonistas, UNIXers, and so on. Not being able to fork *at all* seems more and more like going against the grain. >> * Startup time! If we could fork an already-hot JVM, we could hit the >> ground running with *every* command, *and* still have truly separate >> processes. > > Yup. How much does nailgun address this use case, already? That is, what don't you get today with pre-warmed JVMs? Addressed by Peter, but I'll add a few other nasty bits: * Native-level code (e.g. FFI, file descriptors, ...) is impossible to sort out under nailgun * Nailgun clients don't (can't) propagate TTY to the pseudo-processes, which rules out a large class of command-line uses...exactly why we wanted Nailgun to begin with. * Signal handling...totally effed. A better alternative these days is Drip, which boots the next JVM while the current command is running. Great return-on-investment, but you *really* need to make sure that prebooting is accompanied with something to warm up the JVM, and that's usually very app-specific. >> * There's a lot of development and scaling patterns that depend on >> forking, and we get constant questions about forking on JRuby. > > Over time, we have experimented at length with both forking and single-process multi-tasking (MVM). Since MVM doesn't make as many demands on the operating system for complex operations, we are more comfortable with that approach. MVM works only as far as Nailgun in this respect. I'd love to see it for other reasons, but it has all the same problems. >> * Rubinius -- a Ruby VM with partially-concurrent GC, a >> signal-handling thread, JIT threads, and real parallel Ruby threads -- >> supports forking. They bring the threads to a safe point, fork, and >> restart them on the other side. Color me jealous. > > Me too. It's a cute move. How many OS's does that trick work well on? They test on and have users on several Linux and BSD variants, and of course most Rubinius users run OS X for dev. Of course the lack of issues reports is not proof there's no bugs in the approach, but I've only ever seen people report mundane forking bugs (threads not getting paused or restarted exactly right, etc), rather than anything severe. >> So...given that OpenJDK is rapidly expanding into smaller-profile >> devices and new languages and development patterns, perhaps it's time >> to make it fit into the UNIX philosophy. Where do we start? > > In my opinion, with CDS and AOT. > > And with squinting suspiciously at our data structures. (But when I say that it scares folks; who knows where that will end!? :-) ) > > But a forkable-VM experiment, as a patch within MLVM project, would be a lightweight and easy thing to try. It might not produce a usable result, but would at least illuminate the problem areas. Now I need to find a patsy -- er, hero -- to work on such a patch under my dubiously helpful guidance :-) - Charlie From stefan.karlsson at oracle.com Fri Apr 25 05:29:18 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 25 Apr 2014 07:29:18 +0200 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> Message-ID: <5359F2AE.8010808@oracle.com> Hi David, On 2014-04-24 22:49, David Chase wrote: > Revised webrev. > > Webrev: http://cr.openjdk.java.net/~drchase/8037816/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037816 > > Testing: built everywhere that JPRT builds, personally checked on Mountain Lion (gcc), > Mavericks (clang), Linux-32 (gcc), Linux-64 (gcc), Solaris-11-sparc (solstudio). > > Before you look at the webrev, four things: > > (0) I'll handle copyrights in an automated post-pass, if that's okay. In defense of its absurd size, > this patch is wide but not very deep; the most common changes were: > sprinkle in calls to p2i (277 lines) > MUTE_WARNINGS_FOR_GCC (128 lines) > white space (120 lines) > print_raw[_cr] (108) > print_cr() (68) > PRAGMA_ defines or push/pop/diagnostic macros. (90) > matching format/arg for SIZE_FORMAT (47) > ATTRIBUTE_PRINTF (26) > Other macro definitions (#endif, #else, remaining format macros) (24) > Added "%s" format strings to resolve-nonliteral-string warnings. (20) > Other instances of _FORMAT (may be format change or cast arg change) (19) > Comments (11) > Stray copyright updates (6) > "fmt_" macros (6) > "PRI.PTR" (5) > I've appended the remaining uncategorized added/changed lines at the bottom. > > (1) the revised change set leaves all the format checking enabled as much as possible for gcc > and clang compilation, and all gross format errors have been repaired. This includes our own > functions and methods with printf-like behavior. Not only with this build with clang, it should generally > tend to continue to build with clang. > > No new big format mistakes (*) will be allowed anywhere, and new little mistakes will be warned > except in those files currently marked with PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC. > The intent is that those files will get cleaned up incrementally (one by one, maybe dozen by dozen). > (*) Defined to be: mismatched format/arg lengths, empty format string, non-literal format string. > > (2) there will be additional RFEs covering code I was unsure of; it's as broken/unportable > as it ever was, but now we know it. > > (a) For two files, > src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp > the macro ATTRIBUTE_PRINTF(x,y) > is defined to be empty above the header inclusions; the format strings are wrong in peculiar ways, and they are buried in macros. This is conditional on not-clang, because clang (1) doesn?t warn about the formats in the same way and (2) has a problem with conflicting definitions before includes and within precompiled header files. > > (b) The xsl file used to generate some of the jvmti sources now generates a mute-warnings macro after the header inclusions, because gcc doesn't like some of the format/arg pairs in that generated code, and fixing it was beyond me. > > > (3) these are the parts/questions I think need opinions/resolution: > > (a) print_raw(foo) vs print(?%s?, foo)? > > (b) print_cr() vs print_raw_cr(??) vs print_cr(?%s?, ??) vs cr(). > Note that some of our format-related constructors demand a format, hence they go > with print("%s", "") when they start empty. > > (c) Parameter was passed with no format (two cases). I removed it. What do we really want here? > > --- old/src/share/vm/opto/gcm.cpp 2014-04-23 14:08:48.000000000 -0400 > +++ new/src/share/vm/opto/gcm.cpp 2014-04-23 14:08:47.000000000 -0400 > @@ -2014,7 +2014,7 @@ > tty->print("%s: %d trip_count: %6.0f freq: %6.0f\n", > _depth == 0 ? "Method" : "Loop", _id, trip_count(), _freq); > for (int i = 0; i < _depth; i++) tty->print(" "); > - tty->print(" members:", _id); > + tty->print(" members:"); > int k = 0; > for (int i = 0; i < _members.length(); i++) { > if (k++ >= 6) { > > > --- old/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 > +++ new/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 > @@ -634,7 +636,7 @@ > } > > void ParametersTypeData::print_data_on(outputStream* st, const char* extra) const { > - st->print("parameter types", extra); > + st->print("parameter types"); // FIXME extra ignored? > _parameters.print_data_on(st); > } > > --------------------------------------------------------------------- > > Among the changes/observations: > > int64_t and jlong are NOT NOT NOT the same type on all platforms. Could you clarify this? To me they both look like 64 bit signed integers. What am I missing? thanks, StefanK > > I tested the various pragma/macros idioms for clang as far back as 3.1, gcc as far back as 4.2 . > > Added some formatting macros: > #define UINT64_FORMAT_X "%" PRIx64 > #define PTR_FORMAT_W(width) "%" #width PRIxPTR > #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR > #define SIZE_FORMAT_X "%" PRIxPTR > > The garbage collector seems to be a little bit nutty about the uintx type. > Look at some of the command-line options parameters that are uintx, > in many cases a uint8_t would be completely adequate. > > The mute-gcc macro: > #define PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC _Pragma("GCC diagnostic ignored \"-Wformat\"") _Pragma("GCC diagnostic error \"-Wformat-nonliteral\"") _Pragma("GCC diagnostic error \"-Wformat-security\"") > > --------------------------------------------------------------------- > > + warning("Failed to reserve shared memory (errno = %d).", errno); > + warning("Failed to attach shared memory (errno = %d).", err); > + _level, (int) MaxBCEAEstimateLevel); > + tty->print_cr("code size (%d) exceeds MaxBCEAEstimateSize (%d).", > + method()->code_size(), (int) MaxBCEAEstimateSize); > + out->print(" %d %s", (int)(dp_to_di(vdata->dp() + in_bytes(vdata->receiver_offset(i))) / sizeof(intptr_t)), k->name()->as_quoted_ascii()); > + out->print(" %d %s", (int)(dp_to_di(vdata->dp() + in_bytes(vdata->receiver_offset(i))) / sizeof(intptr_t)), k->name()->as_quoted_ascii()); > +inline void assert_property(bool b, const char* msg, TRAPS) { > + tty->print_cr(" #%d %s = %dK (hdr %d%%, loc %d%%, code %d%%, stub %d%%, [oops %d%%, metadata %d%%, data %d%%, pcs %d%%])", > + (int)(total() / K), > + mark_stack_size, (uintx) 1, MarkStackSizeMax); > + MarkStackSize, (uintx) 1, MarkStackSizeMax); > + (reserved().byte_size()/K), reserved().byte_size()); > + (working_promoted/K), working_promoted); > + (used_in_bytes()/K), used_in_bytes()); > + (min_gen_size()/K), min_gen_size()); > + (max_contraction/K), max_contraction); > + (policy->promo_increment(max_contraction)/K), > + err_msg("MaxTenuringThreshold should be 0 or markOopDesc::max_age + 1, but is %d", (int) MaxTenuringThreshold)); > + (int) active_workers, (int) new_active_workers, (int) prev_active_workers, > + (int) active_workers_by_JT, (int) active_workers_by_heap_size); > + "of %d%%", (int) GCTimeLimit); > + (int) GCTimeLimit, gc_overhead_limit_count()); > + uintx age = 1; > + desired_survivor_size*oopSize, (uintx) result, MaxTenuringThreshold); > + age, sizes[age]*oopSize, total*oopSize); > + gclog_or_tty->print_cr( > + demand, old_rate, rate, new_rate, old_desired, _desired); > + st->print_cr("%d not in CP[*]?", i); > + st->print_cr("%d not in OBJ[*]?", i); > + st->print(" ", kind, i2); > + st->print("parameter types"); // FIXME extra ignored? > + tty->print(" members:"); > + (int) (hi-lo+1), nsing, _max_switch_depth, _est_switch_depth); > + (int) _verify_full_passes); > + (int) _verify_counter, (int) _verify_full_passes); > + const char * trace_mesg, TRAPS) { > + (unsigned int) (MarkStackSize / K), (unsigned int) (MarkStackSizeMax / K)); > + tty->print_cr("ConcGCThreads: %u", (unsigned int) ConcGCThreads); > + " based on pause goal of %d (ms)", (int) MaxGCPauseMillis); > + (unsigned int) (MarkStackSize / K), (unsigned int) (MarkStackSizeMax / K)); > + tty->print_cr("ConcGCThreads: %u", (unsigned int) ConcGCThreads); > +inline void Events::log(Thread* thread, const char* format, ...) { > + return (intptr_t) p; > +} > > From Tobias.Hartmann at oracle.com Fri Apr 25 07:43:37 2014 From: Tobias.Hartmann at oracle.com (Tobias Hartmann) Date: Fri, 25 Apr 2014 09:43:37 +0200 Subject: [8u20] RFR(S): 8029436: CICompilerCount is not updated when the number of compiler threads is adjusted to the number of CPUs Message-ID: <535A1229.9050602@oracle.com> Hi, I would like to request a 8u20 backport of my patch for 8029436. The changes were pushed into jdk9 11 days ago and nightly testing showed no problems. The changes applied to 8u20 without conflicts. Master bug: https://bugs.openjdk.java.net/browse/JDK-8029436 Webrev: http://cr.openjdk.java.net/~anoll/8029436/webrev.02/ Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ba83e8806d8d Thanks, Tobias From roland.westrelin at oracle.com Fri Apr 25 08:09:07 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 25 Apr 2014 10:09:07 +0200 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <245C208D-C35B-4508-A28A-086C9348655A@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <245C208D-C35B-4508-A28A-086C9348655A@oracle.com> Message-ID: <46878107-77D9-45DA-8A1D-674B31766B5D@oracle.com> >> --- old/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 >> +++ new/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 >> @@ -634,7 +636,7 @@ >> } >> >> void ParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >> - st->print("parameter types", extra); >> + st->print("parameter types"); // FIXME extra ignored? >> _parameters.print_data_on(st); >> } > > That's a reasonable fix. I think Roland will want to take a look at it. That change is good. Thanks for fixing this. And thanks for bringing that to my attention, John. Roland. From volker.simonis at gmail.com Fri Apr 25 08:38:34 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 25 Apr 2014 10:38:34 +0200 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <5D71C5FD-6E4B-4E32-8D3E-A8500432FE8E@oracle.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> <5D71C5FD-6E4B-4E32-8D3E-A8500432FE8E@oracle.com> Message-ID: No that doesn't help. I've already tried that. On Thu, Apr 24, 2014 at 8:17 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > On Apr 24, 2014, at 4:51 AM, Andrew Haley wrote: > > On 04/24/2014 01:12 PM, Andrew Haley wrote: > > On 04/24/2014 10:42 AM, Volker Simonis wrote: > > could you pleas hold on a little bit. > > I just found out that for x86_64 we additionally need -fno-devirtualize > when compiling 'assembler_x86.cpp'. Without the option, the compilation of > "Assembler::reachable(AddressLiteral adr)" is totally broken: > > 0x7ffff6046910 <_ZN9Assembler9reachableE14AddressLiteral>: push %rbp > 0x7ffff6046911 <_ZN9Assembler9reachableE14AddressLiteral+1>: mov > %rsp,%rbp > 0x7ffff6046914: data32 data32 nopw %cs:0x0(%rax,%rax,1) > 0x7ffff6046920 <_ZN9Assembler19is_polling_page_farEv>: mov > 0x12d7e69(%rip),%rax > > As you can see it only contains two instructions before it unconditionally > falls into 'Assembler::is_polling_page_far()' > > Maybe we should do some more thorough tests on both, x86 and x86_64 with > these settings to avoid follow-up changes. > > What bothers me however is the fact that we now get this sever error at > several places in the OpenJDK while it doesn't seem to affect others and I > can not see what's special in the coding that triggers the misbehavior? > > > I think I might be able to. I'm debugging GCC now. > > > I've found it, and I don't think this is a bug. GCC's interprocedural > analysis looks at this type: > > class RelocationHolder VALUE_OBJ_CLASS_SPEC { > friend class Relocation; > friend class CodeSection; > > private: > // this preallocated memory must accommodate all subclasses of Relocation > // (this number is assertion-checked in Relocation::operator new) > enum { _relocbuf_size = 5 }; > void* _relocbuf[ _relocbuf_size ]; > > > Why is it void* after all? Can?t it just be a Relocation*? Not sure if > that would fix the problem, though. > > > public: > Relocation* reloc() const { return (Relocation*) &_relocbuf[0]; } > ... > > and decides that no object of type Relocation is reachable from it. > > This is correct: strictly speaking, you can't portably copy a > Relocation into an array of void* and then cast the void* to a > Relocation* and expect to use it. > > It could be argued that -fno-strict-aliasing should mean that this > analysis is incorrect, and all types are reachable. The attached > patch fixes GCC to do that. However, I think it would be better to > fix HotSpot so that it's correct C++. > > Andrew. > > > Index: gcc/ipa-devirt.c > =================================================================== > --- gcc/ipa-devirt.c (revision 209656) > +++ gcc/ipa-devirt.c (working copy) > @@ -1362,8 +1362,9 @@ > > /* Only type inconsistent programs can have otr_type that is > not part of outer type. */ > - if (!contains_type_p (TREE_TYPE (base), > - context->offset + offset2, *otr_type)) > + if (flag_strict_aliasing > + && !contains_type_p (TREE_TYPE (base), > + context->offset + offset2, *otr_type)) > { > /* Use OTR_TOKEN = INT_MAX as a marker of probably type > inconsistent > code sequences; we arrange the calls to be builtin_unreachable > @@ -1441,7 +1442,8 @@ > gcc_assert (!POINTER_TYPE_P (context->outer_type)); > /* Only type inconsistent programs can have otr_type that is > not part of outer type. */ > - if (!contains_type_p (context->outer_type, context->offset, > + if (flag_strict_aliasing > + && !contains_type_p (context->outer_type, context->offset, > *otr_type)) > { > /* Use OTR_TOKEN = INT_MAX as a marker of probably type inconsistent > > > From volker.simonis at gmail.com Fri Apr 25 08:39:44 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 25 Apr 2014 10:39:44 +0200 Subject: Undefined behaviour in hotspot In-Reply-To: References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> Message-ID: Hi Christian, while I think that this change is good, it meanwhile turned out that calling a method on a zero this pointer was not the real cause of the problem (see the problem analysis in this thread and in http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013614.html). Regards, Volker On Fri, Apr 25, 2014 at 4:10 AM, Christian Thalinger wrote: > > On Apr 24, 2014, at 10:33 AM, Christian Thalinger > wrote: > > > On Apr 21, 2014, at 10:41 PM, Volker Simonis > wrote: > > Hi, > > I think the simplest and safest fix would be to make encoding() (and > all the corresponding functions) static functions which take a > Register as argument like: > > static int encoding(const RegisterImpl* r) { assert(is_valid(r), > "invalid register"); return (intptr_t)r; } > > This wouldn't waste any more memory and it would be fully C++ > compliant at the price of a slightly more verbose usage: > > 2577 void Assembler::push(Register src) { > 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); > 2579 > > And of course this would work with any compiler. > > What do you think? > > > I?d rather make Register a real C++ class with an _encoding field. There > are not that many registers used or allocated that it would make a big > difference in memory usage. > > > I filed: > > https://bugs.openjdk.java.net/browse/JDK-8041796 > > and here is an initial cut of the changes: > > http://cr.openjdk.java.net/~twisti/8041796/webrev.00/ > > Right now it?s x86 only and of course must be done for all the other > architectures as well. By inspecting some Clang generated code it seems the > resulting code is the same in most (all?) cases. > > > > Regards, > Volker > > > On Mon, Apr 21, 2014 at 8:30 PM, Omair Majid wrote: > > * David Chase [2014-04-21 13:53]: > > > On 2014-04-21, at 12:17 PM, Omair Majid wrote: > > I can ping them, but honestly, I wouldn't be surprised at all if the > only response I get is "no". I don't have any official communication > channels with them, so my input is not any different from anyone else's. > > Can you elaborate on what flag/pragma you have in mind? Just something > to play nice with NULL pointers? > > > Not just null pointers. Also optimizations that pretend that integer > overflow > doesn't happen (i.e., optimizations that change program behavior when it > does) also need to be disabled. > > > My knowledge of C/C++ is fairly limited, so please bear with me. There > are a few relevant options already listed in 'man gcc': > > -Wstrict-overflow=n > This option is only active when -fstrict-overflow is active. > It warns about cases where the compiler optimizes based on > the assumption that signed overflow does not occur > > -fwrapv > This option instructs the compiler to assume that signed > arithmetic overflow of addition, subtraction and > multiplication wraps around using twos-complement > representation. > > Do you mean others? > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > > From aph at redhat.com Fri Apr 25 10:31:28 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Apr 2014 11:31:28 +0100 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <3645314C-08FB-467D-92A4-C59775FC7093@oracle.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> <53593EA1.2060308@redhat.com> <3645314C-08FB-467D-92A4-C59775FC7093@oracle.com> Message-ID: <535A3980.9020606@redhat.com> On 04/25/2014 01:10 AM, John Rose wrote: > On Apr 24, 2014, at 9:41 AM, Andrew Haley wrote: > >> On 04/24/2014 05:21 PM, Volker Simonis wrote: >>> And I'm not quite sure how to fix this in HotSpot. >>> >>> I first thought I could solve this with an anonymous union like: >>> >>> union { >>> void* _relocbuf[ _relocbuf_size ]; >>> Relocation _reloc; >>> } >>> Relocation* reloc() const { return &_reloc; } >>> >>> but unfortunately I can't put a Relocation into a union because it is >>> not a POD (at least not with C++98). >>> >>> Any other ideas how we could fool GCC 4.9? >>> >>> I more and more think this should be fixed in GCC because I can >>> imagine this will also break other code. >> >> Only code that is not legal C++, and GCC developers have historically >> been very reluctant to support that. So, it might not happen. >> >> AFAICS there is no C++98 way to embed a non-POD object in an object in this >> way. It could be done via a pointer, but that wastes some space. > > That design (RelocationHolder, bitwise non-PODS copy) was committed > 1998-02-27. (Full discl.?courtesy of yours truly.) :-) > Sorry it got in your way. We've seen occasional problems with it > before at high optimization levels. And I agree that current C++ > standards make this doubtful usage. I don't think that this transformation in GCC does anything useful. I have proposed a patch to GCC: http://gcc.gnu.org/ml/gcc/2014-04/msg00236.html Andrew. From aph at redhat.com Fri Apr 25 10:46:09 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Apr 2014 11:46:09 +0100 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> Message-ID: <535A3CF1.9040100@redhat.com> On 04/24/2014 04:10 PM, Volker Simonis wrote: > Wow, that was fast! Haha, I cheated! I debugged GCC and put a breakpoint on the point where the call site was marked unreachable. g++ -fdump-tree-all -fdump-ipa-all ... gets you a lot of dump files. I looked in these files to see where it all went wrong. If you look at embed.cpp.043i.whole-program generated when compiling the example I posted to the GCC list you'll see _2 = MEM[(struct EmbeddedObject *)&o]._vptr.EmbeddedObject; _3 = *_2; _5 = _4(D); __builtin_unreachable (&o.buffer); and with no-devirtualize: _2 = MEM[(struct EmbeddedObject *)&o]._vptr.EmbeddedObject; _3 = *_2; _5 = OBJ_TYPE_REF(_3;(struct EmbeddedObject)&o.buffer->0) (&o.buffer); Andrew. From roland.westrelin at oracle.com Fri Apr 25 11:10:27 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 25 Apr 2014 13:10:27 +0200 Subject: [8u20] RFR(XS): 8039975: SIGSEGV in MethodData::next_data(ProfileData*) In-Reply-To: <53594748.9050000@oracle.com> References: <279DADDD-92BB-40E5-A03E-15409DF0A3C1@oracle.com> <53594748.9050000@oracle.com> Message-ID: <2B22B9D5-4277-4151-8505-68A86B8A845D@oracle.com> Thanks Vladimir. Roland. On Apr 24, 2014, at 7:18 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 4/24/14 1:41 AM, Roland Westrelin wrote: >> 8u20 backport request. The change was pushed to jdk9 a week ago and nightly testing hasn?t shown any problem. >> >> The change applies cleanly to 8u. >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eb8897b2687e >> https://bugs.openjdk.java.net/browse/JDK-8041110 >> >> Roland. >> From david.r.chase at oracle.com Fri Apr 25 12:10:54 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 25 Apr 2014 08:10:54 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <5359F2AE.8010808@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <5359F2AE.8010808@oracle.com> Message-ID: <2F5B7196-8CB1-4D70-92AE-E2FE76A1378D@oracle.com> On 2014-04-25, at 1:29 AM, Stefan Karlsson wrote: > Hi David, >> Among the changes/observations: >> >> int64_t and jlong are NOT NOT NOT the same type on all platforms. > > Could you clarify this? To me they both look like 64 bit signed integers. What am I missing? On at least one 64-bit platform (I think at least XCode 4.6.3 / gcc 4.2 on Mountain Lion) one of the two is defined to be "long" and the other "long long". Even though both of those are 64 bits, gcc "knows" that there are platforms where long is only 32 bits, and hence this could be a problem when you recompile on different platform. Thus the warnings, against future unportability. Gcc doesn't "know" that we plan to change our macro definitions for that platform. David From aph at redhat.com Fri Apr 25 13:38:15 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Apr 2014 14:38:15 +0100 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <535A3980.9020606@redhat.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> <53593EA1.2060308@redhat.com> <3645314C-08FB-467D-92A4-C59775FC7093@oracle.com> <535A3980.9020606@redhat.com> Message-ID: <535A6547.3070906@redhat.com> On 04/25/2014 11:31 AM, Andrew Haley wrote: > On 04/25/2014 01:10 AM, John Rose wrote: >> On Apr 24, 2014, at 9:41 AM, Andrew Haley wrote: >> >>> On 04/24/2014 05:21 PM, Volker Simonis wrote: >>>> And I'm not quite sure how to fix this in HotSpot. >>>> >>>> I first thought I could solve this with an anonymous union like: >>>> >>>> union { >>>> void* _relocbuf[ _relocbuf_size ]; >>>> Relocation _reloc; >>>> } >>>> Relocation* reloc() const { return &_reloc; } >>>> >>>> but unfortunately I can't put a Relocation into a union because it is >>>> not a POD (at least not with C++98). >>>> >>>> Any other ideas how we could fool GCC 4.9? >>>> >>>> I more and more think this should be fixed in GCC because I can >>>> imagine this will also break other code. >>> >>> Only code that is not legal C++, and GCC developers have historically >>> been very reluctant to support that. So, it might not happen. >>> >>> AFAICS there is no C++98 way to embed a non-POD object in an object in this >>> way. It could be done via a pointer, but that wastes some space. >> >> That design (RelocationHolder, bitwise non-PODS copy) was committed >> 1998-02-27. (Full discl.?courtesy of yours truly.) > > :-) > >> Sorry it got in your way. We've seen occasional problems with it >> before at high optimization levels. And I agree that current C++ >> standards make this doubtful usage. > > I don't think that this transformation in GCC does anything useful. GCC list seems to think it is a bug in GCC. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 Andrew. From volker.simonis at gmail.com Fri Apr 25 14:19:50 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 25 Apr 2014 16:19:50 +0200 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: <535A6547.3070906@redhat.com> References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> <53593EA1.2060308@redhat.com> <3645314C-08FB-467D-92A4-C59775FC7093@oracle.com> <535A3980.9020606@redhat.com> <535A6547.3070906@redhat.com> Message-ID: Thanks for opening the bug! They first opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60963 but categorized it as 'ubsan' (i.e. sanitizer bug) which it isn't. Hopefully they'll fix it soon:) Regards, Volker On Fri, Apr 25, 2014 at 3:38 PM, Andrew Haley wrote: > On 04/25/2014 11:31 AM, Andrew Haley wrote: >> On 04/25/2014 01:10 AM, John Rose wrote: >>> On Apr 24, 2014, at 9:41 AM, Andrew Haley wrote: >>> >>>> On 04/24/2014 05:21 PM, Volker Simonis wrote: >>>>> And I'm not quite sure how to fix this in HotSpot. >>>>> >>>>> I first thought I could solve this with an anonymous union like: >>>>> >>>>> union { >>>>> void* _relocbuf[ _relocbuf_size ]; >>>>> Relocation _reloc; >>>>> } >>>>> Relocation* reloc() const { return &_reloc; } >>>>> >>>>> but unfortunately I can't put a Relocation into a union because it is >>>>> not a POD (at least not with C++98). >>>>> >>>>> Any other ideas how we could fool GCC 4.9? >>>>> >>>>> I more and more think this should be fixed in GCC because I can >>>>> imagine this will also break other code. >>>> >>>> Only code that is not legal C++, and GCC developers have historically >>>> been very reluctant to support that. So, it might not happen. >>>> >>>> AFAICS there is no C++98 way to embed a non-POD object in an object in this >>>> way. It could be done via a pointer, but that wastes some space. >>> >>> That design (RelocationHolder, bitwise non-PODS copy) was committed >>> 1998-02-27. (Full discl.?courtesy of yours truly.) >> >> :-) >> >>> Sorry it got in your way. We've seen occasional problems with it >>> before at high optimization levels. And I agree that current C++ >>> standards make this doubtful usage. >> >> I don't think that this transformation in GCC does anything useful. > > GCC list seems to think it is a bug in GCC. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 > > Andrew. > From aph at redhat.com Fri Apr 25 14:26:28 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Apr 2014 15:26:28 +0100 Subject: RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM In-Reply-To: References: <1699862096.9102793.1398308854043.JavaMail.zimbra@redhat.com> <1742674290.9102964.1398309025077.JavaMail.zimbra@redhat.com> <5358FFC1.7020709@redhat.com> <535924D9.2070404@redhat.com> <53593EA1.2060308@redhat.com> <3645314C-08FB-467D-92A4-C59775FC7093@oracle.com> <535A3980.9020606@redhat.com> <535A6547.3070906@redhat.com> Message-ID: <535A7094.1030007@redhat.com> On 04/25/2014 03:19 PM, Volker Simonis wrote: > Thanks for opening the bug! > > They first opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60963 > but categorized it as 'ubsan' (i.e. sanitizer bug) which it isn't. > > Hopefully they'll fix it soon:) It's really easy to fix once we figure out what the fix should be. Even I could do it. :-) One idea suggested was that if the data member in the virtual call is a POD- type we should assume nothing about its type and make the call. That sounds sensible to me, but I'm waiting for the author of the code to express an opinion. Andrew. From david.simms at oracle.com Fri Apr 25 15:14:36 2014 From: david.simms at oracle.com (David Simms) Date: Fri, 25 Apr 2014 17:14:36 +0200 Subject: RFR [XS] JDK-6616502: JNI specification should discuss multiple invocations of DetachCurrentThread Message-ID: <535A7BDC.1060703@oracle.com> JDK-6616502 : JNI Specificatio n should discuss multiple invocations of DetachCurrentThread Slight improvement to DetachCurrentThread() : Similar to wording for "attach"; "Trying to detach a thread that is already detached is a no-op". Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/6616502/ *Old Text* *New Text* DetachCurrentThread |jint DetachCurrentThread(JavaVM *vm);| Detaches the current thread from a Java VM. All Java monitors held by this thread are released. All Java threads waiting for this thread to die are notified. The main thread can be detached from the VM. DetachCurrentThread |jint DetachCurrentThread(JavaVM *vm);| Detaches the current thread from a Java VM. All Java monitors held by this thread are released. All Java threads waiting for this thread to die are notified. The main thread can be detached from the VM. Trying to detach a thread that is not attached is a no-op. From david.simms at oracle.com Fri Apr 25 15:14:44 2014 From: david.simms at oracle.com (David Simms) Date: Fri, 25 Apr 2014 17:14:44 +0200 Subject: RFR [XS] JDK-6590839: JNI Spec should point out Java objects created in JNI using AllocObject are not finalized Message-ID: <535A7BE4.30007@oracle.com> JDK-6590839 Minor addition to the JNI Specification : Explain the lack of finalization AllocObject (). Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/6590839/ *Old Text* *New Text* AllocObject |jobject AllocObject(JNIEnv *env, jclass clazz);| Allocates a new Java object without invoking any of the constructors for the object. Returns a reference to the object. The clazz argument must not refer to an array class. AllocObject |jobject AllocObject(JNIEnv *env, jclass clazz);| Allocates a new Java object without invoking any of the constructors for the object. Returns a reference to the object. *Note:*The Java Language Specification, "Implementing Finalization" (JLS ?12.6.1 ) states: "An object o is not finalizable until its constructor has invoked the constructor for Object on o and that invocation has completed successfully". Since AllocObject() does not invoke a constructor, objects created with this function are not eligible for finalization. The clazz argument must not refer to an array class. From david.simms at oracle.com Fri Apr 25 15:17:25 2014 From: david.simms at oracle.com (David Simms) Date: Fri, 25 Apr 2014 17:17:25 +0200 Subject: RFR [XS] JDK-6462398: jni spec should specify which characters are unicode-escaped when mangling Message-ID: <535A7C85.2060502@oracle.com> JDK-6462398 : jni spec should specify which characters are unicode-escaped when mangling Minor change to the JNI Specification : The section "Resolving Native Method Names " should be slightly more specific in describing how characters are mangled. Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/6462398/ *Old Text* *New Text* Unicode Character TranslationEscape Sequence Denotes |_0XXXX| a Unicode character|XXXX|. Note that lower case is used to represent non-ASCII Unicode characters, for example,|_0abcd|as opposed to|_0ABCD|. Unicode Character TranslationEscape Sequence Denotes |_0xxxx| a Unicode character|xxxx|, representing characters other than ASCII alphanumeric ([A-Za-z0-9]). Note that lower case is used, for example,|_0abcd|as opposed to|_0ABCD|. From david.simms at oracle.com Fri Apr 25 15:20:24 2014 From: david.simms at oracle.com (David Simms) Date: Fri, 25 Apr 2014 17:20:24 +0200 Subject: RFR [XS] JDK-8039184: JNI Spec missing documentation on calling default methods Message-ID: <535A7D38.2070402@oracle.com> JDK-8039184 : JNI Spec missing documentation on calling default methods Minor addition to the JNI Specification : Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/8039184/ *Old Text* *New Text* GetMethodID |jmethodID GetMethodID(JNIEnv *env, jclass clazz, const char *name, const char *sig);| Returns the method ID for an instance (nonstatic) method of a class or interface. The method may be defined in one of the|clazz|'s superclasses and inherited by|clazz|. The method is determined by its name and signature. |GetMethodID()|causes an uninitialized class to be initialized. To obtain the method ID of a constructor, supply||as the method name and|void|(|V|) as the return type. GetMethodID |jmethodID GetMethodID(JNIEnv *env, jclass clazz, const char *name, const char *sig);| Returns the method ID for an instance (nonstatic) method of a class or interface. The method may be defined in one of the|clazz|'s supertypes and inherited by|clazz|. The method is determined by its name and signature. |GetMethodID()|causes an uninitialized class to be initialized. To obtain the method ID of a constructor, supply||as the method name and|void|(|V|) as the return type. CallNonvirtualMethod Routines, CallNonvirtualMethodA Routines, CallNonvirtualMethodV Routines /NativeType//CallNonvirtualMethod/|(JNIEnv *env, jobject obj, jclass clazz, jmethodID methodID, ...);| /NativeType//CallNonvirtualMethodA/|(JNIEnv *env, jobject obj, jclass clazz, jmethodID methodID, const jvalue *args);| /NativeType//CallNonvirtualMethodV/|(JNIEnv *env, jobject obj, jclass clazz, jmethodID methodID, va_list args);| These families of operations invoke an instance (nonstatic) method on a Java object, according to the specified class and method ID. The|methodID|argument must be obtained by calling|GetMethodID||()|on the class|clazz|. The/CallNonvirtualMethod/families of routines and the/CallMethod/families of routines are different./CallMethod/routines invoke the method based on the class of the object, while/CallNonvirtualMethod/routines invoke the method based on the class, designated by the|clazz|parameter, from which the method ID is obtained. The method ID must be obtained from the real class of the object or from one of its superclasses. CallNonvirtualMethod Routines, CallNonvirtualMethodA Routines, CallNonvirtualMethodV Routines /NativeType//CallNonvirtualMethod/|(JNIEnv *env, jobject obj, jclass clazz, jmethodID methodID, ...);| /NativeType//CallNonvirtualMethodA/|(JNIEnv *env, jobject obj, jclass clazz, jmethodID methodID, const jvalue *args);| /NativeType//CallNonvirtualMethodV/|(JNIEnv *env, jobject obj, jclass clazz, jmethodID methodID, va_list args);| These families of operations invoke an instance (nonstatic) method on a Java object, according to the specified class and method ID. The|methodID|argument must be obtained by calling|GetMethodID||()|on the class|clazz|. The/CallNonvirtualMethod/families of routines and the/CallMethod/families of routines are different./CallMethod/routines invoke the method based on the class or interface of the object, while/CallNonvirtualMethod/routines invoke the method based on the class, designated by the|clazz|parameter, from which the method ID is obtained. The method ID must be obtained from the real class of the object or from one of its supertypes. /CallNonvirtualMethod/routines are the mechanism for invoking/"default interface methods"/introduced in Java 8. From david.simms at oracle.com Fri Apr 25 15:40:25 2014 From: david.simms at oracle.com (David Simms) Date: Fri, 25 Apr 2014 17:40:25 +0200 Subject: Apologies for formatting (JDK-6616502, JDK-6590839, JDK-6462398, JDK-8039184 ), HTML only format to mailing list not working ? Message-ID: <535A81E9.8070402@oracle.com> Apologies for the formatting of reviews for JDK-6616502, JDK-6590839, JDK-6462398, JDK-8039184. The intention was HTML only, as they were changes to HTML...mailing list appears to have trashed them. Sending HTML only, appears to have ended up in a black hole :-( The web reviews are still quite readable, please fall-back to these... /David Simms # Of course, it's Friday end-of-business (CET) :-) From karen.kinnear at oracle.com Fri Apr 25 15:42:02 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 25 Apr 2014 11:42:02 -0400 Subject: RFR [XS] JDK-6616502: JNI specification should discuss multiple invocations of DetachCurrentThread In-Reply-To: <535A7BDC.1060703@oracle.com> References: <535A7BDC.1060703@oracle.com> Message-ID: Looks good. thanks, Karen On Apr 25, 2014, at 11:14 AM, David Simms wrote: > JDK-6616502 : > > JNI Specificatio n should discuss multiple invocations of DetachCurrentThread Slight improvement to DetachCurrentThread() : Similar to wording for "attach"; "Trying to detach a thread that is already detached is a no-op". > > Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/6616502/ > > *Old Text* > *New Text* > > > DetachCurrentThread > > |jint DetachCurrentThread(JavaVM *vm);| > > Detaches the current thread from a Java VM. All Java monitors held by this thread are released. All Java threads waiting for this thread to die are notified. > > The main thread can be detached from the VM. > > > DetachCurrentThread > > |jint DetachCurrentThread(JavaVM *vm);| > > Detaches the current thread from a Java VM. All Java monitors held by this thread are released. All Java threads waiting for this thread to die are notified. > > The main thread can be detached from the VM. > > Trying to detach a thread that is not attached is a no-op. > > From karen.kinnear at oracle.com Fri Apr 25 15:42:29 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 25 Apr 2014 11:42:29 -0400 Subject: RFR [XS] JDK-6590839: JNI Spec should point out Java objects created in JNI using AllocObject are not finalized In-Reply-To: <535A7BE4.30007@oracle.com> References: <535A7BE4.30007@oracle.com> Message-ID: Looks good. thanks, Karen On Apr 25, 2014, at 11:14 AM, David Simms wrote: > JDK-6590839 > > Minor addition to the JNI Specification : > > Explain the lack of finalization AllocObject (). Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/6590839/ > > *Old Text* > *New Text* > > > AllocObject > > |jobject AllocObject(JNIEnv *env, jclass clazz);| > > Allocates a new Java object without invoking any of the constructors for the object. Returns a reference to the object. > > The clazz argument must not refer to an array class. > > > > > AllocObject > > |jobject AllocObject(JNIEnv *env, jclass clazz);| > > Allocates a new Java object without invoking any of the constructors for the object. Returns a reference to the object. > > *Note:*The Java Language Specification, "Implementing Finalization" (JLS ?12.6.1 ) states: "An object o is not finalizable until its constructor has invoked the constructor for Object on o and that invocation has completed successfully". Since AllocObject() does not invoke a constructor, objects created with this function are not eligible for finalization. > > The clazz argument must not refer to an array class. > > From karen.kinnear at oracle.com Fri Apr 25 15:42:55 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 25 Apr 2014 11:42:55 -0400 Subject: RFR [XS] JDK-6462398: jni spec should specify which characters are unicode-escaped when mangling In-Reply-To: <535A7C85.2060502@oracle.com> References: <535A7C85.2060502@oracle.com> Message-ID: <3B00D44C-4B5E-4195-B915-963F0BB70DFE@oracle.com> Looks good. thanks, Karen On Apr 25, 2014, at 11:17 AM, David Simms wrote: > JDK-6462398 : jni spec should specify which characters are unicode-escaped when mangling > > Minor change to the JNI Specification : > > The section "Resolving Native Method Names " should be slightly more specific in describing how characters are mangled. > > Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/6462398/ > > *Old Text* > *New Text* > Unicode Character TranslationEscape Sequence Denotes > |_0XXXX| a Unicode character|XXXX|. Note that lower case is used to represent non-ASCII Unicode characters, for example,|_0abcd|as opposed to|_0ABCD|. > > > > Unicode Character TranslationEscape Sequence Denotes > |_0xxxx| a Unicode character|xxxx|, representing characters other than ASCII alphanumeric ([A-Za-z0-9]). Note that lower case is used, for example,|_0abcd|as opposed to|_0ABCD|. > > From karen.kinnear at oracle.com Fri Apr 25 15:44:57 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 25 Apr 2014 11:44:57 -0400 Subject: RFR [XS] JDK-8039184: JNI Spec missing documentation on calling default methods In-Reply-To: <535A7D38.2070402@oracle.com> References: <535A7D38.2070402@oracle.com> Message-ID: Looks good. thanks, Karen On Apr 25, 2014, at 11:20 AM, David Simms wrote: > JDK-8039184 : JNI Spec missing documentation on calling default methods > > Minor addition to the JNI Specification : > > Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/8039184/ > > *Old Text* > *New Text* > > > GetMethodID > > |jmethodID GetMethodID(JNIEnv *env, jclass clazz, > const char *name, const char *sig);| > > Returns the method ID for an instance (nonstatic) method of a class or interface. The method may be defined in one of the|clazz|'s superclasses and inherited by|clazz|. The method is determined by its name and signature. > > |GetMethodID()|causes an uninitialized class to be initialized. > > To obtain the method ID of a constructor, supply||as the method name and|void|(|V|) as the return type. > > > > > GetMethodID > > |jmethodID GetMethodID(JNIEnv *env, jclass clazz, > const char *name, const char *sig);| > > Returns the method ID for an instance (nonstatic) method of a class or interface. The method may be defined in one of the|clazz|'s supertypes and inherited by|clazz|. The method is determined by its name and signature. > > |GetMethodID()|causes an uninitialized class to be initialized. > > To obtain the method ID of a constructor, supply||as the method name and|void|(|V|) as the return type. > > > CallNonvirtualMethod Routines, CallNonvirtualMethodA > Routines, CallNonvirtualMethodV Routines > > /NativeType//CallNonvirtualMethod/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, ...);| > > /NativeType//CallNonvirtualMethodA/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, const jvalue *args);| > > /NativeType//CallNonvirtualMethodV/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, va_list args);| > > These families of operations invoke an instance (nonstatic) method on a Java object, according to the specified class and method ID. The|methodID|argument must be obtained by calling|GetMethodID||()|on the class|clazz|. > > The/CallNonvirtualMethod/families of routines and the/CallMethod/families of routines are different./CallMethod/routines invoke the method based on the class of the object, while/CallNonvirtualMethod/routines invoke the method based on the class, designated by the|clazz|parameter, from which the method ID is obtained. The method ID must be obtained from the real class of the object or from one of its superclasses. > > > > > CallNonvirtualMethod Routines, CallNonvirtualMethodA > Routines, CallNonvirtualMethodV Routines > > /NativeType//CallNonvirtualMethod/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, ...);| > > /NativeType//CallNonvirtualMethodA/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, const jvalue *args);| > > /NativeType//CallNonvirtualMethodV/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, va_list args);| > > These families of operations invoke an instance (nonstatic) method on a Java object, according to the specified class and method ID. The|methodID|argument must be obtained by calling|GetMethodID||()|on the class|clazz|. > > The/CallNonvirtualMethod/families of routines and the/CallMethod/families of routines are different./CallMethod/routines invoke the method based on the class or interface of the object, while/CallNonvirtualMethod/routines invoke the method based on the class, designated by the|clazz|parameter, from which the method ID is obtained. The method ID must be obtained from the real class of the object or from one of its supertypes. > > /CallNonvirtualMethod/routines are the mechanism for invoking/"default interface methods"/introduced in Java 8. > From vladimir.kozlov at oracle.com Fri Apr 25 16:51:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Apr 2014 09:51:16 -0700 Subject: [8u20] RFR(S): 8029436: CICompilerCount is not updated when the number of compiler threads is adjusted to the number of CPUs In-Reply-To: <535A1229.9050602@oracle.com> References: <535A1229.9050602@oracle.com> Message-ID: <535A9284.3060701@oracle.com> Looks good. Please, use 'hg export ba83e8806d8d > patch / hg import patch' without modifying the patch so the bug id and whole description stay the same. Thanks, Vladimir On 4/25/14 12:43 AM, Tobias Hartmann wrote: > Hi, > > I would like to request a 8u20 backport of my patch for 8029436. > > The changes were pushed into jdk9 11 days ago and nightly testing showed no problems. The changes applied to 8u20 > without conflicts. > > Master bug: https://bugs.openjdk.java.net/browse/JDK-8029436 > Webrev: http://cr.openjdk.java.net/~anoll/8029436/webrev.02/ > Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ba83e8806d8d > > Thanks, > Tobias From daniel.daugherty at oracle.com Fri Apr 25 19:54:13 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Apr 2014 13:54:13 -0600 Subject: RFR [XS] JDK-6616502: JNI specification should discuss multiple invocations of DetachCurrentThread In-Reply-To: <535A7BDC.1060703@oracle.com> References: <535A7BDC.1060703@oracle.com> Message-ID: <535ABD65.1080209@oracle.com> Thumbs up. Dan On 4/25/14 9:14 AM, David Simms wrote: > JDK-6616502 : > > JNI Specificatio > n > should discuss multiple invocations of DetachCurrentThread Slight > improvement to DetachCurrentThread() > : > Similar to wording for "attach"; "Trying to detach a thread that is > already detached is a no-op". > > Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/6616502/ > > > *Old Text* > *New Text* > > > DetachCurrentThread > > |jint DetachCurrentThread(JavaVM *vm);| > > Detaches the current thread from a Java VM. All Java monitors held by > this thread are released. All Java threads waiting for this thread to > die are notified. > > The main thread can be detached from the VM. > > > DetachCurrentThread > > |jint DetachCurrentThread(JavaVM *vm);| > > Detaches the current thread from a Java VM. All Java monitors held by > this thread are released. All Java threads waiting for this thread to > die are notified. > > The main thread can be detached from the VM. > > Trying to detach a thread that is not attached is a no-op. > > From daniel.daugherty at oracle.com Fri Apr 25 19:56:50 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Apr 2014 13:56:50 -0600 Subject: RFR [XS] JDK-6590839: JNI Spec should point out Java objects created in JNI using AllocObject are not finalized In-Reply-To: <535A7BE4.30007@oracle.com> References: <535A7BE4.30007@oracle.com> Message-ID: <535ABE02.2050300@oracle.com> Thumbs up. Dan On 4/25/14 9:14 AM, David Simms wrote: > JDK-6590839 > > Minor addition to the JNI Specification > : > > > Explain the lack of finalization AllocObject > (). > Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/6590839/ > > > *Old Text* > *New Text* > > > AllocObject > > |jobject AllocObject(JNIEnv *env, jclass clazz);| > > Allocates a new Java object without invoking any of the constructors > for the object. Returns a reference to the object. > > The clazz argument must not refer to an array class. > > > > > AllocObject > > |jobject AllocObject(JNIEnv *env, jclass clazz);| > > Allocates a new Java object without invoking any of the constructors > for the object. Returns a reference to the object. > > *Note:*The Java Language Specification, "Implementing Finalization" > (JLS ?12.6.1 > ) > states: "An object o is not finalizable until its constructor has > invoked the constructor for Object on o and that invocation has > completed successfully". Since AllocObject() does not invoke a > constructor, objects created with this function are not eligible for > finalization. > > The clazz argument must not refer to an array class. > > From daniel.daugherty at oracle.com Fri Apr 25 19:59:00 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Apr 2014 13:59:00 -0600 Subject: RFR [XS] JDK-6462398: jni spec should specify which characters are unicode-escaped when mangling In-Reply-To: <535A7C85.2060502@oracle.com> References: <535A7C85.2060502@oracle.com> Message-ID: <535ABE84.50207@oracle.com> Thumbs up. Dan On 4/25/14 9:17 AM, David Simms wrote: > JDK-6462398 : jni > spec should specify which characters are unicode-escaped when mangling > > Minor change to the JNI Specification > : > > The section "Resolving Native Method Names > " > should be slightly more specific in describing how characters are > mangled. > > Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/6462398/ > > > *Old Text* > *New Text* > Unicode Character TranslationEscape Sequence Denotes > |_0XXXX| a Unicode character|XXXX|. Note that lower case is used > to represent non-ASCII Unicode characters, for example,|_0abcd|as > opposed to|_0ABCD|. > > > > Unicode Character TranslationEscape Sequence Denotes > |_0xxxx| a Unicode character|xxxx|, representing characters other > than ASCII alphanumeric ([A-Za-z0-9]). Note that lower case is used, > for example,|_0abcd|as opposed to|_0ABCD|. > > From daniel.daugherty at oracle.com Fri Apr 25 20:08:40 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Apr 2014 14:08:40 -0600 Subject: RFR [XS] JDK-8039184: JNI Spec missing documentation on calling default methods In-Reply-To: <535A7D38.2070402@oracle.com> References: <535A7D38.2070402@oracle.com> Message-ID: <535AC0C8.3060708@oracle.com> This one got a little confusing because it looks like old and new got mushed together (interleaved). Once I figured out which parts were old and new, the review became easier. Thumbs up. Dan On 4/25/14 9:20 AM, David Simms wrote: > JDK-8039184 : JNI > Spec missing documentation on calling default methods > > Minor addition to the JNI Specification > : > > Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/8039184/ > > > *Old Text* > *New Text* > > > GetMethodID > > |jmethodID GetMethodID(JNIEnv *env, jclass clazz, > const char *name, const char *sig);| > > Returns the method ID for an instance (nonstatic) method of a class or > interface. The method may be defined in one of the|clazz|'s > superclasses and inherited by|clazz|. The method is determined by its > name and signature. > > |GetMethodID()|causes an uninitialized class to be initialized. > > To obtain the method ID of a constructor, supply||as the method > name and|void|(|V|) as the return type. > > > > > GetMethodID > > |jmethodID GetMethodID(JNIEnv *env, jclass clazz, > const char *name, const char *sig);| > > Returns the method ID for an instance (nonstatic) method of a class or > interface. The method may be defined in one of the|clazz|'s supertypes > and inherited by|clazz|. The method is determined by its name and > signature. > > |GetMethodID()|causes an uninitialized class to be initialized. > > To obtain the method ID of a constructor, supply||as the method > name and|void|(|V|) as the return type. > > > CallNonvirtualMethod Routines, CallNonvirtualMethodA > Routines, CallNonvirtualMethodV Routines > > /NativeType//CallNonvirtualMethod/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, ...);| > > /NativeType//CallNonvirtualMethodA/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, const jvalue *args);| > > /NativeType//CallNonvirtualMethodV/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, va_list args);| > > These families of operations invoke an instance (nonstatic) method on > a Java object, according to the specified class and method ID. > The|methodID|argument must be obtained by calling|GetMethodID||()|on > the class|clazz|. > > The/CallNonvirtualMethod/families of routines and > the/CallMethod/families of routines are > different./CallMethod/routines invoke the method based on the > class of the object, while/CallNonvirtualMethod/routines invoke > the method based on the class, designated by the|clazz|parameter, from > which the method ID is obtained. The method ID must be obtained from > the real class of the object or from one of its superclasses. > > > > > CallNonvirtualMethod Routines, CallNonvirtualMethodA > Routines, CallNonvirtualMethodV Routines > > /NativeType//CallNonvirtualMethod/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, ...);| > > /NativeType//CallNonvirtualMethodA/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, const jvalue *args);| > > /NativeType//CallNonvirtualMethodV/|(JNIEnv *env, jobject obj, > jclass clazz, jmethodID methodID, va_list args);| > > These families of operations invoke an instance (nonstatic) method on > a Java object, according to the specified class and method ID. > The|methodID|argument must be obtained by calling|GetMethodID||()|on > the class|clazz|. > > The/CallNonvirtualMethod/families of routines and > the/CallMethod/families of routines are > different./CallMethod/routines invoke the method based on the > class or interface of the object, > while/CallNonvirtualMethod/routines invoke the method based on > the class, designated by the|clazz|parameter, from which the method ID > is obtained. The method ID must be obtained from the real class of the > object or from one of its supertypes. > > /CallNonvirtualMethod/routines are the mechanism for > invoking/"default interface methods"/introduced in Java 8. > From dean.long at oracle.com Fri Apr 25 21:37:49 2014 From: dean.long at oracle.com (Dean Long) Date: Fri, 25 Apr 2014 14:37:49 -0700 Subject: Undefined behaviour in hotspot In-Reply-To: References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> Message-ID: <535AD5AD.6080401@oracle.com> On 4/24/2014 7:10 PM, Christian Thalinger wrote: > On Apr 24, 2014, at 10:33 AM, Christian Thalinger wrote: > >> On Apr 21, 2014, at 10:41 PM, Volker Simonis wrote: >> >>> Hi, >>> >>> I think the simplest and safest fix would be to make encoding() (and >>> all the corresponding functions) static functions which take a >>> Register as argument like: >>> >>> static int encoding(const RegisterImpl* r) { assert(is_valid(r), >>> "invalid register"); return (intptr_t)r; } >>> >>> This wouldn't waste any more memory and it would be fully C++ >>> compliant at the price of a slightly more verbose usage: >>> >>> 2577 void Assembler::push(Register src) { >>> 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); >>> 2579 >>> >>> And of course this would work with any compiler. >>> >>> What do you think? >> I?d rather make Register a real C++ class with an _encoding field. There are not that many registers used or allocated that it would make a big difference in memory usage. > I filed: > > https://bugs.openjdk.java.net/browse/JDK-8041796 > > and here is an initial cut of the changes: > > http://cr.openjdk.java.net/~twisti/8041796/webrev.00/ > > Right now it?s x86 only and of course must be done for all the other architectures as well. By inspecting some Clang generated code it seems the resulting code is the same in most (all?) cases. You should be able to define an operator -> for compatibility, allowing more of the existing code to continue working. dl >>> Regards, >>> Volker >>> >>> >>> On Mon, Apr 21, 2014 at 8:30 PM, Omair Majid wrote: >>>> * David Chase [2014-04-21 13:53]: >>>>> On 2014-04-21, at 12:17 PM, Omair Majid wrote: >>>>>> I can ping them, but honestly, I wouldn't be surprised at all if the >>>>>> only response I get is "no". I don't have any official communication >>>>>> channels with them, so my input is not any different from anyone else's. >>>>>> >>>>>> Can you elaborate on what flag/pragma you have in mind? Just something >>>>>> to play nice with NULL pointers? >>>>> Not just null pointers. Also optimizations that pretend that integer overflow >>>>> doesn't happen (i.e., optimizations that change program behavior when it >>>>> does) also need to be disabled. >>>> My knowledge of C/C++ is fairly limited, so please bear with me. There >>>> are a few relevant options already listed in 'man gcc': >>>> >>>> -Wstrict-overflow=n >>>> This option is only active when -fstrict-overflow is active. >>>> It warns about cases where the compiler optimizes based on >>>> the assumption that signed overflow does not occur >>>> >>>> -fwrapv >>>> This option instructs the compiler to assume that signed >>>> arithmetic overflow of addition, subtraction and >>>> multiplication wraps around using twos-complement >>>> representation. >>>> >>>> Do you mean others? >>>> >>>> Thanks, >>>> Omair >>>> >>>> -- >>>> PGP Key: 66484681 (http://pgp.mit.edu/) >>>> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From christian.thalinger at oracle.com Sat Apr 26 00:54:31 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 25 Apr 2014 14:54:31 -1000 Subject: Undefined behaviour in hotspot In-Reply-To: <535AD5AD.6080401@oracle.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <535AD5AD.6080401@oracle.com> Message-ID: On Apr 25, 2014, at 11:37 AM, Dean Long wrote: > On 4/24/2014 7:10 PM, Christian Thalinger wrote: >> On Apr 24, 2014, at 10:33 AM, Christian Thalinger wrote: >> >>> On Apr 21, 2014, at 10:41 PM, Volker Simonis wrote: >>> >>>> Hi, >>>> >>>> I think the simplest and safest fix would be to make encoding() (and >>>> all the corresponding functions) static functions which take a >>>> Register as argument like: >>>> >>>> static int encoding(const RegisterImpl* r) { assert(is_valid(r), >>>> "invalid register"); return (intptr_t)r; } >>>> >>>> This wouldn't waste any more memory and it would be fully C++ >>>> compliant at the price of a slightly more verbose usage: >>>> >>>> 2577 void Assembler::push(Register src) { >>>> 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); >>>> 2579 >>>> >>>> And of course this would work with any compiler. >>>> >>>> What do you think? >>> I?d rather make Register a real C++ class with an _encoding field. There are not that many registers used or allocated that it would make a big difference in memory usage. >> I filed: >> >> https://bugs.openjdk.java.net/browse/JDK-8041796 >> >> and here is an initial cut of the changes: >> >> http://cr.openjdk.java.net/~twisti/8041796/webrev.00/ >> >> Right now it?s x86 only and of course must be done for all the other architectures as well. By inspecting some Clang generated code it seems the resulting code is the same in most (all?) cases. > You should be able to define an operator -> for compatibility, allowing more of the existing code to continue working. It would probably work but I?d rather not. It would trick people into thinking that Register is still a pointer which it isn?t anymore. Real problems would arise if someone were to actually new a Register. > > dl > >>>> Regards, >>>> Volker >>>> >>>> >>>> On Mon, Apr 21, 2014 at 8:30 PM, Omair Majid wrote: >>>>> * David Chase [2014-04-21 13:53]: >>>>>> On 2014-04-21, at 12:17 PM, Omair Majid wrote: >>>>>>> I can ping them, but honestly, I wouldn't be surprised at all if the >>>>>>> only response I get is "no". I don't have any official communication >>>>>>> channels with them, so my input is not any different from anyone else's. >>>>>>> >>>>>>> Can you elaborate on what flag/pragma you have in mind? Just something >>>>>>> to play nice with NULL pointers? >>>>>> Not just null pointers. Also optimizations that pretend that integer overflow >>>>>> doesn't happen (i.e., optimizations that change program behavior when it >>>>>> does) also need to be disabled. >>>>> My knowledge of C/C++ is fairly limited, so please bear with me. There >>>>> are a few relevant options already listed in 'man gcc': >>>>> >>>>> -Wstrict-overflow=n >>>>> This option is only active when -fstrict-overflow is active. >>>>> It warns about cases where the compiler optimizes based on >>>>> the assumption that signed overflow does not occur >>>>> >>>>> -fwrapv >>>>> This option instructs the compiler to assume that signed >>>>> arithmetic overflow of addition, subtraction and >>>>> multiplication wraps around using twos-complement >>>>> representation. >>>>> >>>>> Do you mean others? >>>>> >>>>> Thanks, >>>>> Omair >>>>> >>>>> -- >>>>> PGP Key: 66484681 (http://pgp.mit.edu/) >>>>> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From milan.mimica at infobip.com Sat Apr 26 08:10:02 2014 From: milan.mimica at infobip.com (Milan Mimica) Date: Sat, 26 Apr 2014 10:10:02 +0200 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: References: <534CD269.2060900@oracle.com> Message-ID: <535B69DA.2020603@infobip.com> Milan Mimica,?Software Engineer / Team Leader Milan Mimica,?Software Engineer / Team Leader On 04/15/2014 09:16 AM, Fedor Bobin wrote: > java.lang.NullPointerException: can not invoke method > java.lang.String.length()I on null object > at Test.testNPE(Test.java:14) > at Test.main(Test.java:8) > > This additional information can help to understand cause of NPE in case of > call chains. For example, let we have java code What does it say in this situation? static void func(int i) {...} { func((Integer) null); } From fuudtorrentsru at gmail.com Sat Apr 26 12:45:05 2014 From: fuudtorrentsru at gmail.com (Fedor Bobin) Date: Sat, 26 Apr 2014 16:45:05 +0400 Subject: JDK-4834738 NullPointerException: Better info In-Reply-To: <535B69DA.2020603@infobip.com> References: <534CD269.2060900@oracle.com> <535B69DA.2020603@infobip.com> Message-ID: func((Integer) null) expanded by javac to func(((Integer) null).intValue()) So message will be "can not invoke method java.lang.Integer.intValue()I on null object" 26.04.2014 12:10 ???????????? "Milan Mimica" ???????: > Milan Mimica, Software Engineer / Team Leader > > Milan Mimica, Software Engineer / Team Leader > > On 04/15/2014 09:16 AM, Fedor Bobin wrote: > > java.lang.NullPointerException: can not invoke method >> java.lang.String.length()I on null object >> at Test.testNPE(Test.java:14) >> at Test.main(Test.java:8) >> >> This additional information can help to understand cause of NPE in case of >> call chains. For example, let we have java code >> > > What does it say in this situation? > > static void func(int i) {...} > > { > func((Integer) null); > } > > From aph at redhat.com Sun Apr 27 09:03:09 2014 From: aph at redhat.com (Andrew Haley) Date: Sun, 27 Apr 2014 10:03:09 +0100 Subject: Undefined behaviour in hotspot In-Reply-To: References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> Message-ID: <535CC7CD.5010805@redhat.com> On 04/25/2014 03:10 AM, Christian Thalinger wrote: > > On Apr 24, 2014, at 10:33 AM, Christian Thalinger wrote: > >> >> On Apr 21, 2014, at 10:41 PM, Volker Simonis wrote: >> >>> Hi, >>> >>> I think the simplest and safest fix would be to make encoding() (and >>> all the corresponding functions) static functions which take a >>> Register as argument like: >>> >>> static int encoding(const RegisterImpl* r) { assert(is_valid(r), >>> "invalid register"); return (intptr_t)r; } >>> >>> This wouldn't waste any more memory and it would be fully C++ >>> compliant at the price of a slightly more verbose usage: >>> >>> 2577 void Assembler::push(Register src) { >>> 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); >>> 2579 >>> >>> And of course this would work with any compiler. >>> >>> What do you think? >> >> I?d rather make Register a real C++ class with an _encoding field. >> There are not that many registers used or allocated that it would >> make a big difference in memory usage. I don't think this is a good idea. Some ABIs pass structs in memory, even structs with a single word field. You'd be be pessimizing such systems, for no good reason AFAICS. Andrew. From igor.veresov at oracle.com Mon Apr 28 02:28:54 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 27 Apr 2014 19:28:54 -0700 Subject: [8u20] RFR (XS) 8041351: Crash in src/share/vm/opto/loopnode.cpp:3215 - assert(!had_error) failed: bad dominance In-Reply-To: <535819BF.2060706@oracle.com> References: <535819BF.2060706@oracle.com> Message-ID: Looks fine. igor On Apr 23, 2014, at 12:51 PM, Vladimir Kozlov wrote: > 8u20 backport request. These changes were pushed into jdk9 yesterday and nightly testing shows no problems. > > Changes from jdk9 applied to 8u without conflicts. > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4bc3f8fa071f > https://bugs.openjdk.java.net/browse/JDK-8041351 > > Thanks, > Vladimir From david.holmes at oracle.com Mon Apr 28 07:07:39 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Apr 2014 17:07:39 +1000 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <2F5B7196-8CB1-4D70-92AE-E2FE76A1378D@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <5359F2AE.8010808@oracle.com> <2F5B7196-8CB1-4D70-92AE-E2FE76A1378D@oracle.com> Message-ID: <535DFE3B.60903@oracle.com> On 25/04/2014 10:10 PM, David Chase wrote: > > On 2014-04-25, at 1:29 AM, Stefan Karlsson wrote: > >> Hi David, >>> Among the changes/observations: >>> >>> int64_t and jlong are NOT NOT NOT the same type on all platforms. >> >> Could you clarify this? To me they both look like 64 bit signed integers. What am I missing? > > On at least one 64-bit platform (I think at least XCode 4.6.3 / gcc 4.2 on Mountain Lion) one > of the two is defined to be "long" and the other "long long". Even though both of those are > 64 bits, gcc "knows" that there are platforms where long is only 32 bits, and hence this could > be a problem when you recompile on different platform. That doesn't make sense to me. gcc should be looking at the current definitions of those types in the current build, not considering some absolute truth as to what these types might be across different platforms. David H. -------- > Thus the warnings, against future unportability. > > Gcc doesn't "know" that we plan to change our macro definitions for that platform. > > David > From david.simms at oracle.com Mon Apr 28 09:07:35 2014 From: david.simms at oracle.com (David Simms) Date: Mon, 28 Apr 2014 11:07:35 +0200 Subject: RFR [XS] JDK-8039184: JNI Spec missing documentation on calling default methods In-Reply-To: <535AC0C8.3060708@oracle.com> References: <535A7D38.2070402@oracle.com> <535AC0C8.3060708@oracle.com> Message-ID: <535E1A57.2060001@oracle.com> Thanks Dan, Sorry the mailing list stole my HTML, but the webrev was still reasonable. Thanks for the reviews... /David On 04/25/2014 10:08 PM, Daniel D. Daugherty wrote: > This one got a little confusing because it looks like old and new > got mushed together (interleaved). Once I figured out which parts > were old and new, the review became easier. > > Thumbs up. > > Dan > > > > > On 4/25/14 9:20 AM, David Simms wrote: >> JDK-8039184 : JNI >> Spec missing documentation on calling default methods >> >> Minor addition to the JNI Specification >> : >> >> Web review here: http://cr.openjdk.java.net/~dsimms/jnispec/8039184/ >> >> >> *Old Text* >> *New Text* >> >> >> GetMethodID >> >> |jmethodID GetMethodID(JNIEnv *env, jclass clazz, >> const char *name, const char *sig);| >> >> Returns the method ID for an instance (nonstatic) method of a class >> or interface. The method may be defined in one of the|clazz|'s >> superclasses and inherited by|clazz|. The method is determined by its >> name and signature. >> >> |GetMethodID()|causes an uninitialized class to be initialized. >> >> To obtain the method ID of a constructor, supply||as the method >> name and|void|(|V|) as the return type. >> >> >> >> >> GetMethodID >> >> |jmethodID GetMethodID(JNIEnv *env, jclass clazz, >> const char *name, const char *sig);| >> >> Returns the method ID for an instance (nonstatic) method of a class >> or interface. The method may be defined in one of the|clazz|'s >> supertypes and inherited by|clazz|. The method is determined by its >> name and signature. >> >> |GetMethodID()|causes an uninitialized class to be initialized. >> >> To obtain the method ID of a constructor, supply||as the method >> name and|void|(|V|) as the return type. >> >> >> CallNonvirtualMethod Routines, CallNonvirtualMethodA >> Routines, CallNonvirtualMethodV Routines >> >> /NativeType//CallNonvirtualMethod/|(JNIEnv *env, jobject obj, >> jclass clazz, jmethodID methodID, ...);| >> >> /NativeType//CallNonvirtualMethodA/|(JNIEnv *env, jobject obj, >> jclass clazz, jmethodID methodID, const jvalue *args);| >> >> /NativeType//CallNonvirtualMethodV/|(JNIEnv *env, jobject obj, >> jclass clazz, jmethodID methodID, va_list args);| >> >> These families of operations invoke an instance (nonstatic) method on >> a Java object, according to the specified class and method ID. >> The|methodID|argument must be obtained by calling|GetMethodID||()|on >> the class|clazz|. >> >> The/CallNonvirtualMethod/families of routines and >> the/CallMethod/families of routines are >> different./CallMethod/routines invoke the method based on the >> class of the object, while/CallNonvirtualMethod/routines invoke >> the method based on the class, designated by the|clazz|parameter, >> from which the method ID is obtained. The method ID must be obtained >> from the real class of the object or from one of its superclasses. >> >> >> >> >> CallNonvirtualMethod Routines, CallNonvirtualMethodA >> Routines, CallNonvirtualMethodV Routines >> >> /NativeType//CallNonvirtualMethod/|(JNIEnv *env, jobject obj, >> jclass clazz, jmethodID methodID, ...);| >> >> /NativeType//CallNonvirtualMethodA/|(JNIEnv *env, jobject obj, >> jclass clazz, jmethodID methodID, const jvalue *args);| >> >> /NativeType//CallNonvirtualMethodV/|(JNIEnv *env, jobject obj, >> jclass clazz, jmethodID methodID, va_list args);| >> >> These families of operations invoke an instance (nonstatic) method on >> a Java object, according to the specified class and method ID. >> The|methodID|argument must be obtained by calling|GetMethodID||()|on >> the class|clazz|. >> >> The/CallNonvirtualMethod/families of routines and >> the/CallMethod/families of routines are >> different./CallMethod/routines invoke the method based on the >> class or interface of the object, >> while/CallNonvirtualMethod/routines invoke the method based on >> the class, designated by the|clazz|parameter, from which the method >> ID is obtained. The method ID must be obtained from the real class of >> the object or from one of its supertypes. >> >> /CallNonvirtualMethod/routines are the mechanism for >> invoking/"default interface methods"/introduced in Java 8. >> > From sgehwolf at redhat.com Mon Apr 28 11:42:02 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 28 Apr 2014 13:42:02 +0200 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs Message-ID: <1398685322.3241.19.camel@localhost.localdomain> Hi, Bug: JI-9011998 (I don't seem to be able to create JDK bugs) Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ The fix for JDK-8034775 introduced a start-up check requiring the number of compiler threads to be >= 1, which does not make sense for non-JIT VMs such as the zero JVM variant. This causes zero JVMs to fail initialization with: CICompilerCount of 0 is invalid; must be at least 1 Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. This is caused by a wrong start-up check in src/share/vm/runtime/arguments.cpp where a minimal value of 1 is required no matter the JVM variant. The proposed fix uses the defined CI_COMPILER_COUNT pre-processor constant over a static 1 to pass to verify_min_value(). Since CI_COMPILER_COUNT is going to be defined differently for JVM variants it will make the lower water mark check correct for all JVM variants. There was an error in defining CI_COMPILER_COUNT as well. On line 196 in src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is defined to be 0 (since COMPILER1, COMPILER2 and SHARK are not defined for a Zero build. Then on line 201 in src/share/vm/runtime/globals.hpp the "else" branch of ifdef COMPILER2 is entered and the earlier definition of CI_COMPILER_COUNT (with value 0) overridden to 1. I've amended test/compiler/startup/NumCompilerThreadsCheck.java so as to verify that the lower water mark for Zero JVMs is 0. Thoughts? Cheers, Severin From david.r.chase at oracle.com Mon Apr 28 11:57:55 2014 From: david.r.chase at oracle.com (David Chase) Date: Mon, 28 Apr 2014 07:57:55 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <535DFE3B.60903@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <5359F2AE.8010808@oracle.com> <2F5B7196-8CB1-4D70-92AE-E2FE76A1378D@oracle.com> <535DFE3B.60903@oracle.com> Message-ID: On 2014-04-28, at 3:07 AM, David Holmes wrote: > On 25/04/2014 10:10 PM, David Chase wrote: >> >> On 2014-04-25, at 1:29 AM, Stefan Karlsson wrote: >> >>> Hi David, >>>> Among the changes/observations: >>>> >>>> int64_t and jlong are NOT NOT NOT the same type on all platforms. >>> >>> Could you clarify this? To me they both look like 64 bit signed integers. What am I missing? >> >> On at least one 64-bit platform (I think at least XCode 4.6.3 / gcc 4.2 on Mountain Lion) one >> of the two is defined to be "long" and the other "long long". Even though both of those are >> 64 bits, gcc "knows" that there are platforms where long is only 32 bits, and hence this could >> be a problem when you recompile on different platform. > > That doesn't make sense to me. gcc should be looking at the current definitions of those types in the current build, not considering some absolute truth as to what these types might be across different platforms. I am just the messenger -- if we intend to enable format warnings, and to mark our own printf-ish methods appropriately, and warnings are errors, and we use gcc, then we have to put up with gcc's silliness. The automated format/arg warnings (i.e., the warnings in this extremely picky category, not literal/empty/length) did catch one bug that Vladimir K concurrently repaired (printing int as %s, not so good) and found another where we printed a default case constant as a %f, plus it has tagged numerous actual integer width mismatches (that might or might not bite us in some future port, it has a lot to do with how parameters are passed and endianness). How do you like it otherwise? I'm itching to get reviews and get this thing out of my hair. David From vladimir.kozlov at oracle.com Mon Apr 28 17:42:23 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Apr 2014 10:42:23 -0700 Subject: [8u20] RFR (XS) 8041351: Crash in src/share/vm/opto/loopnode.cpp:3215 - assert(!had_error) failed: bad dominance In-Reply-To: References: <535819BF.2060706@oracle.com> Message-ID: <535E92FF.2000307@oracle.com> Thank you, Igor Vladimir On 4/27/14 7:28 PM, Igor Veresov wrote: > Looks fine. > > igor > > On Apr 23, 2014, at 12:51 PM, Vladimir Kozlov wrote: > >> 8u20 backport request. These changes were pushed into jdk9 yesterday and nightly testing shows no problems. >> >> Changes from jdk9 applied to 8u without conflicts. >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4bc3f8fa071f >> https://bugs.openjdk.java.net/browse/JDK-8041351 >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Mon Apr 28 18:13:46 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Apr 2014 11:13:46 -0700 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <1398685322.3241.19.camel@localhost.localdomain> References: <1398685322.3241.19.camel@localhost.localdomain> Message-ID: <535E9A5A.8060605@oracle.com> Hi Severin, Your fix looks reasonable. Sorry for breaking your build. I assigned the bug to Albert. He will sponsor your changes. Thanks, Vladimir On 4/28/14 4:42 AM, Severin Gehwolf wrote: > Hi, > > Bug: JI-9011998 (I don't seem to be able to create JDK bugs) > Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ > > The fix for JDK-8034775 introduced a start-up check requiring the number > of compiler threads to be >= 1, which does not make sense for non-JIT > VMs such as the zero JVM variant. This causes zero JVMs to fail > initialization with: > > CICompilerCount of 0 is invalid; must be at least 1 > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > This is caused by a wrong start-up check in > src/share/vm/runtime/arguments.cpp where a minimal value of 1 is > required no matter the JVM variant. > > The proposed fix uses the defined CI_COMPILER_COUNT pre-processor > constant over a static 1 to pass to verify_min_value(). Since > CI_COMPILER_COUNT is going to be defined differently for JVM variants it > will make the lower water mark check correct for all JVM variants. > > There was an error in defining CI_COMPILER_COUNT as well. On line 196 in > src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is defined to be 0 > (since COMPILER1, COMPILER2 and SHARK are not defined for a Zero build. > Then on line 201 in src/share/vm/runtime/globals.hpp the "else" branch > of ifdef COMPILER2 is entered and the earlier definition of > CI_COMPILER_COUNT (with value 0) overridden to 1. > > I've amended test/compiler/startup/NumCompilerThreadsCheck.java so as to > verify that the lower water mark for Zero JVMs is 0. > > Thoughts? > > Cheers, > Severin > From christian.thalinger at oracle.com Mon Apr 28 19:19:01 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Apr 2014 09:19:01 -1000 Subject: Undefined behaviour in hotspot In-Reply-To: <535CC7CD.5010805@redhat.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <535CC7CD.5010805@redhat.com> Message-ID: On Apr 26, 2014, at 11:03 PM, Andrew Haley wrote: > On 04/25/2014 03:10 AM, Christian Thalinger wrote: >> >> On Apr 24, 2014, at 10:33 AM, Christian Thalinger wrote: >> >>> >>> On Apr 21, 2014, at 10:41 PM, Volker Simonis wrote: >>> >>>> Hi, >>>> >>>> I think the simplest and safest fix would be to make encoding() (and >>>> all the corresponding functions) static functions which take a >>>> Register as argument like: >>>> >>>> static int encoding(const RegisterImpl* r) { assert(is_valid(r), >>>> "invalid register"); return (intptr_t)r; } >>>> >>>> This wouldn't waste any more memory and it would be fully C++ >>>> compliant at the price of a slightly more verbose usage: >>>> >>>> 2577 void Assembler::push(Register src) { >>>> 2578 int encode = prefix_and_encode(RegisterImpl::encoding(src)); >>>> 2579 >>>> >>>> And of course this would work with any compiler. >>>> >>>> What do you think? >>> >>> I?d rather make Register a real C++ class with an _encoding field. >>> There are not that many registers used or allocated that it would >>> make a big difference in memory usage. > > I don't think this is a good idea. Some ABIs pass structs in memory, > even structs with a single word field. You'd be be pessimizing such > systems, for no good reason AFAICS. There was actually a reason why someone (Tom) chose to change the Register classes: https://bugs.openjdk.java.net/browse/JDK-4642581 > > Andrew. From omajid at redhat.com Mon Apr 28 19:56:19 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 28 Apr 2014 15:56:19 -0400 Subject: Undefined behaviour in hotspot In-Reply-To: <81C5E090-E3C8-4D21-B079-AAA7D223F1EA@oracle.com> References: <20140421151956.GB2422@redhat.com> <64537750-26F6-4CF7-9633-8ECF44BF489E@oracle.com> <20140421161748.GD2422@redhat.com> <5A6E67E9-988A-4AC8-A84E-87777AB566CF@oracle.com> <20140421183055.GE2422@redhat.com> <81C5E090-E3C8-4D21-B079-AAA7D223F1EA@oracle.com> Message-ID: <20140428195619.GA18195@redhat.com> * David Chase [2014-04-22 08:20]: > I'm pretty sure that -Wstrict-overflow is the one that we want, > and that to do this study we (we?) would compile with > > -Wstrict-overflow=5 -Wno-error I compiled with gcc 4.8.2. The result is available here: http://cr.openjdk.java.net/~omajid/logs/signed-overflow/build.log Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From vladimir.kozlov at oracle.com Mon Apr 28 22:12:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Apr 2014 15:12:33 -0700 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> Message-ID: <535ED251.8000501@oracle.com> The same as John said: Use print_raw(msg) for now and file RFE to rename (I prefer puts()). Use cr() for empty strings. os_linux.cpp: you can include space into format now after you added "%s" - st->print("%s", os::Linux::glibc_version()); st->print(" "); --- + st->print("%s ", os::Linux::glibc_version()); Do the same in your changes in os_posix.cpp instead of using print_raw(). I don't like "0x%" PRIxPTR combination. Can you use PTR_FORMAT instead of "0x%" PRIxPTR ?: + case T_OBJECT: out->print("obj:0x%" PRIxPTR, p2i(as_jobject())); break; + case T_METADATA: out->print("metadata:0x%" PRIxPTR, p2i(as_metadata()));break; and INTPRT_FORMAT for: out->print("%3d:0x" UINT64_FORMAT_X, type(), (uint64_t)as_jlong()); The places with absent '0x' should be fixed IMHO. For example in c1_Runtime1.cpp: 'at pc %" PRIxPTR,' Can you fix vm_version_.cpp by casting flags values to (int)? arguments.cpp: Can you use (uint) instead of (unsigned int)? Thanks, Vladimir On 4/24/14 1:49 PM, David Chase wrote: > Revised webrev. > > Webrev: http://cr.openjdk.java.net/~drchase/8037816/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037816 > > Testing: built everywhere that JPRT builds, personally checked on Mountain Lion (gcc), > Mavericks (clang), Linux-32 (gcc), Linux-64 (gcc), Solaris-11-sparc (solstudio). > > Before you look at the webrev, four things: > > (0) I'll handle copyrights in an automated post-pass, if that's okay. In defense of its absurd size, > this patch is wide but not very deep; the most common changes were: > sprinkle in calls to p2i (277 lines) > MUTE_WARNINGS_FOR_GCC (128 lines) > white space (120 lines) > print_raw[_cr] (108) > print_cr() (68) > PRAGMA_ defines or push/pop/diagnostic macros. (90) > matching format/arg for SIZE_FORMAT (47) > ATTRIBUTE_PRINTF (26) > Other macro definitions (#endif, #else, remaining format macros) (24) > Added "%s" format strings to resolve-nonliteral-string warnings. (20) > Other instances of _FORMAT (may be format change or cast arg change) (19) > Comments (11) > Stray copyright updates (6) > "fmt_" macros (6) > "PRI.PTR" (5) > I've appended the remaining uncategorized added/changed lines at the bottom. > > (1) the revised change set leaves all the format checking enabled as much as possible for gcc > and clang compilation, and all gross format errors have been repaired. This includes our own > functions and methods with printf-like behavior. Not only with this build with clang, it should generally > tend to continue to build with clang. > > No new big format mistakes (*) will be allowed anywhere, and new little mistakes will be warned > except in those files currently marked with PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC. > The intent is that those files will get cleaned up incrementally (one by one, maybe dozen by dozen). > (*) Defined to be: mismatched format/arg lengths, empty format string, non-literal format string. > > (2) there will be additional RFEs covering code I was unsure of; it's as broken/unportable > as it ever was, but now we know it. > > (a) For two files, > src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp > the macro ATTRIBUTE_PRINTF(x,y) > is defined to be empty above the header inclusions; the format strings are wrong in peculiar ways, and they are buried in macros. This is conditional on not-clang, because clang (1) doesn?t warn about the formats in the same way and (2) has a problem with conflicting definitions before includes and within precompiled header files. > > (b) The xsl file used to generate some of the jvmti sources now generates a mute-warnings macro after the header inclusions, because gcc doesn't like some of the format/arg pairs in that generated code, and fixing it was beyond me. > > > (3) these are the parts/questions I think need opinions/resolution: > > (a) print_raw(foo) vs print(?%s?, foo)? > > (b) print_cr() vs print_raw_cr(??) vs print_cr(?%s?, ??) vs cr(). > Note that some of our format-related constructors demand a format, hence they go > with print("%s", "") when they start empty. > > (c) Parameter was passed with no format (two cases). I removed it. What do we really want here? > > --- old/src/share/vm/opto/gcm.cpp 2014-04-23 14:08:48.000000000 -0400 > +++ new/src/share/vm/opto/gcm.cpp 2014-04-23 14:08:47.000000000 -0400 > @@ -2014,7 +2014,7 @@ > tty->print("%s: %d trip_count: %6.0f freq: %6.0f\n", > _depth == 0 ? "Method" : "Loop", _id, trip_count(), _freq); > for (int i = 0; i < _depth; i++) tty->print(" "); > - tty->print(" members:", _id); > + tty->print(" members:"); > int k = 0; > for (int i = 0; i < _members.length(); i++) { > if (k++ >= 6) { > > > --- old/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 > +++ new/src/share/vm/oops/methodData.cpp 2014-04-24 11:18:22.000000000 -0400 > @@ -634,7 +636,7 @@ > } > > void ParametersTypeData::print_data_on(outputStream* st, const char* extra) const { > - st->print("parameter types", extra); > + st->print("parameter types"); // FIXME extra ignored? > _parameters.print_data_on(st); > } > > --------------------------------------------------------------------- > > Among the changes/observations: > > int64_t and jlong are NOT NOT NOT the same type on all platforms. > > I tested the various pragma/macros idioms for clang as far back as 3.1, gcc as far back as 4.2 . > > Added some formatting macros: > #define UINT64_FORMAT_X "%" PRIx64 > #define PTR_FORMAT_W(width) "%" #width PRIxPTR > #define SIZE_FORMAT_XW(width) "%" #width PRIxPTR > #define SIZE_FORMAT_X "%" PRIxPTR > > The garbage collector seems to be a little bit nutty about the uintx type. > Look at some of the command-line options parameters that are uintx, > in many cases a uint8_t would be completely adequate. > > The mute-gcc macro: > #define PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC _Pragma("GCC diagnostic ignored \"-Wformat\"") _Pragma("GCC diagnostic error \"-Wformat-nonliteral\"") _Pragma("GCC diagnostic error \"-Wformat-security\"") > > --------------------------------------------------------------------- > > + warning("Failed to reserve shared memory (errno = %d).", errno); > + warning("Failed to attach shared memory (errno = %d).", err); > + _level, (int) MaxBCEAEstimateLevel); > + tty->print_cr("code size (%d) exceeds MaxBCEAEstimateSize (%d).", > + method()->code_size(), (int) MaxBCEAEstimateSize); > + out->print(" %d %s", (int)(dp_to_di(vdata->dp() + in_bytes(vdata->receiver_offset(i))) / sizeof(intptr_t)), k->name()->as_quoted_ascii()); > + out->print(" %d %s", (int)(dp_to_di(vdata->dp() + in_bytes(vdata->receiver_offset(i))) / sizeof(intptr_t)), k->name()->as_quoted_ascii()); > +inline void assert_property(bool b, const char* msg, TRAPS) { > + tty->print_cr(" #%d %s = %dK (hdr %d%%, loc %d%%, code %d%%, stub %d%%, [oops %d%%, metadata %d%%, data %d%%, pcs %d%%])", > + (int)(total() / K), > + mark_stack_size, (uintx) 1, MarkStackSizeMax); > + MarkStackSize, (uintx) 1, MarkStackSizeMax); > + (reserved().byte_size()/K), reserved().byte_size()); > + (working_promoted/K), working_promoted); > + (used_in_bytes()/K), used_in_bytes()); > + (min_gen_size()/K), min_gen_size()); > + (max_contraction/K), max_contraction); > + (policy->promo_increment(max_contraction)/K), > + err_msg("MaxTenuringThreshold should be 0 or markOopDesc::max_age + 1, but is %d", (int) MaxTenuringThreshold)); > + (int) active_workers, (int) new_active_workers, (int) prev_active_workers, > + (int) active_workers_by_JT, (int) active_workers_by_heap_size); > + "of %d%%", (int) GCTimeLimit); > + (int) GCTimeLimit, gc_overhead_limit_count()); > + uintx age = 1; > + desired_survivor_size*oopSize, (uintx) result, MaxTenuringThreshold); > + age, sizes[age]*oopSize, total*oopSize); > + gclog_or_tty->print_cr( > + demand, old_rate, rate, new_rate, old_desired, _desired); > + st->print_cr("%d not in CP[*]?", i); > + st->print_cr("%d not in OBJ[*]?", i); > + st->print(" ", kind, i2); > + st->print("parameter types"); // FIXME extra ignored? > + tty->print(" members:"); > + (int) (hi-lo+1), nsing, _max_switch_depth, _est_switch_depth); > + (int) _verify_full_passes); > + (int) _verify_counter, (int) _verify_full_passes); > + const char * trace_mesg, TRAPS) { > + (unsigned int) (MarkStackSize / K), (unsigned int) (MarkStackSizeMax / K)); > + tty->print_cr("ConcGCThreads: %u", (unsigned int) ConcGCThreads); > + " based on pause goal of %d (ms)", (int) MaxGCPauseMillis); > + (unsigned int) (MarkStackSize / K), (unsigned int) (MarkStackSizeMax / K)); > + tty->print_cr("ConcGCThreads: %u", (unsigned int) ConcGCThreads); > +inline void Events::log(Thread* thread, const char* format, ...) { > + return (intptr_t) p; > +} > > From mikael.vidstedt at oracle.com Tue Apr 29 00:36:13 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 28 Apr 2014 17:36:13 -0700 Subject: RFR (S): 8042059: Various fixes to linux/sparc Message-ID: <535EF3FD.1030608@oracle.com> All, Please review the following set of minor changes which are needed to get the linux/sparc platform to build and run[1]. The changes are relatively straightforward so I'm not explaining them more in detail here, but please ask if there's anything in there which is unclear. Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8042059/webrev.00/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8042059 Cheers, Mikael [1] Note that a few additional minor changes are needed, but they need to be cleaned up a tad before they're ready to be pushed. From christian.thalinger at oracle.com Tue Apr 29 00:42:56 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Apr 2014 14:42:56 -1000 Subject: RFR (S): 8042059: Various fixes to linux/sparc In-Reply-To: <535EF3FD.1030608@oracle.com> References: <535EF3FD.1030608@oracle.com> Message-ID: <0D527812-ED4B-4C8E-B2E3-3E1737217385@oracle.com> Looks good. The changes to src/cpu/sparc/vm/stubGenerator_sparc.cpp also fix: https://bugs.openjdk.java.net/browse/JDK-8022070 On Apr 28, 2014, at 2:36 PM, Mikael Vidstedt wrote: > > All, > > Please review the following set of minor changes which are needed to get the linux/sparc platform to build and run[1]. The changes are relatively straightforward so I'm not explaining them more in detail here, but please ask if there's anything in there which is unclear. > > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8042059/webrev.00/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8042059 > > Cheers, > Mikael > > [1] Note that a few additional minor changes are needed, but they need to be cleaned up a tad before they're ready to be pushed. > From david.r.chase at oracle.com Tue Apr 29 02:56:12 2014 From: david.r.chase at oracle.com (David Chase) Date: Mon, 28 Apr 2014 22:56:12 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <535ED251.8000501@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <535ED251.8000501@oracle.com> Message-ID: <04E9C0ED-4F68-4796-8BE9-FF3E116D3F9C@oracle.com> On 2014-04-28, at 6:12 PM, Vladimir Kozlov wrote: > The same as John said: > > Use print_raw(msg) for now and file RFE to rename (I prefer puts()). > Use cr() for empty strings. Done, except for the pending RFE. > os_linux.cpp: you can include space into format now after you added "%s" > > - st->print("%s", os::Linux::glibc_version()); st->print(" "); > --- > + st->print("%s ", os::Linux::glibc_version()); > > Do the same in your changes in os_posix.cpp instead of using print_raw(). Done. > I don't like "0x%" PRIxPTR combination. Can you use PTR_FORMAT instead of "0x%" PRIxPTR ?: > > + case T_OBJECT: out->print("obj:0x%" PRIxPTR, p2i(as_jobject())); break; > + case T_METADATA: out->print("metadata:0x%" PRIxPTR, p2i(as_metadata()));break; Done. Note that this will change the output -- PTR_FORMAT is 8 or 16 hex digits, always. > and INTPRT_FORMAT for: > > out->print("%3d:0x" UINT64_FORMAT_X, type(), (uint64_t)as_jlong()); This gets messy, because the only reliable name I have for a 64-bit type and format is [u]int64. Pointers can be 32-bits wide on some platforms. (So no, I actually can't make this work.) > The places with absent '0x' should be fixed IMHO. For example in c1_Runtime1.cpp: 'at pc %" PRIxPTR,' Done. Replaced with PTR_FORMAT, which includes the 0x (and 8 or 16 hex digits always). > Can you fix vm_version_.cpp by casting flags values to (int)? I would prefer not to -- this could have wider effects than the format fixes I have made, and that would require a lot of testing with a lot of different flag values to be sure I didn't screw something else up unintentionally. > arguments.cpp: Can you use (uint) instead of (unsigned int)? Done All instances of "Done" passed preliminary testing, and I'll redo all the other testing tomorrow. David From albert.noll at oracle.com Tue Apr 29 08:36:00 2014 From: albert.noll at oracle.com (Albert) Date: Tue, 29 Apr 2014 10:36:00 +0200 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <535E9A5A.8060605@oracle.com> References: <1398685322.3241.19.camel@localhost.localdomain> <535E9A5A.8060605@oracle.com> Message-ID: <535F6470.1050307@oracle.com> Hi, sorry, it was my change that introduced the bug. The change looks good to me as well. However, I am not a reviewer, so I think a second review would be good. Or is the change simple enough that 1 review is fine? I am not sure. Are you a contributor? ( http://openjdk.java.net/contribute/ ) If yes, I will push your changes as soon as I have an OK. Many thanks, Albert On 04/28/2014 08:13 PM, Vladimir Kozlov wrote: > Hi Severin, > > Your fix looks reasonable. > > Sorry for breaking your build. I assigned the bug to Albert. He will > sponsor your changes. > > Thanks, > Vladimir > > On 4/28/14 4:42 AM, Severin Gehwolf wrote: >> Hi, >> >> Bug: JI-9011998 (I don't seem to be able to create JDK bugs) >> Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ >> >> The fix for JDK-8034775 introduced a start-up check requiring the number >> of compiler threads to be >= 1, which does not make sense for non-JIT >> VMs such as the zero JVM variant. This causes zero JVMs to fail >> initialization with: >> >> CICompilerCount of 0 is invalid; must be at least 1 >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> This is caused by a wrong start-up check in >> src/share/vm/runtime/arguments.cpp where a minimal value of 1 is >> required no matter the JVM variant. >> >> The proposed fix uses the defined CI_COMPILER_COUNT pre-processor >> constant over a static 1 to pass to verify_min_value(). Since >> CI_COMPILER_COUNT is going to be defined differently for JVM variants it >> will make the lower water mark check correct for all JVM variants. >> >> There was an error in defining CI_COMPILER_COUNT as well. On line 196 in >> src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is defined to be 0 >> (since COMPILER1, COMPILER2 and SHARK are not defined for a Zero build. >> Then on line 201 in src/share/vm/runtime/globals.hpp the "else" branch >> of ifdef COMPILER2 is entered and the earlier definition of >> CI_COMPILER_COUNT (with value 0) overridden to 1. >> >> I've amended test/compiler/startup/NumCompilerThreadsCheck.java so as to >> verify that the lower water mark for Zero JVMs is 0. >> >> Thoughts? >> >> Cheers, >> Severin >> From sgehwolf at redhat.com Tue Apr 29 09:30:37 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 29 Apr 2014 11:30:37 +0200 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <535F6470.1050307@oracle.com> References: <1398685322.3241.19.camel@localhost.localdomain> <535E9A5A.8060605@oracle.com> <535F6470.1050307@oracle.com> Message-ID: <1398763837.3223.9.camel@localhost.localdomain> Hi Albert, On Tue, 2014-04-29 at 10:36 +0200, Albert wrote: > Hi, > > sorry, it was my change that introduced the bug. The change looks good > to me as well. Thanks for looking at the patch! > However, I am not a reviewer, so I think a second review would be good. OK. > Or is the change > simple enough that 1 review is fine? I am not sure. > > Are you a contributor? ( http://openjdk.java.net/contribute/ ) If yes, I > will push your changes > as soon as I have an OK. I work for Red Hat and I believe it has signed the OCA as a company. Not sure if this makes me a contributor. Cheers, Severin > On 04/28/2014 08:13 PM, Vladimir Kozlov wrote: > > Hi Severin, > > > > Your fix looks reasonable. > > > > Sorry for breaking your build. I assigned the bug to Albert. He will > > sponsor your changes. > > > > Thanks, > > Vladimir > > > > On 4/28/14 4:42 AM, Severin Gehwolf wrote: > >> Hi, > >> > >> Bug: JI-9011998 (I don't seem to be able to create JDK bugs) > >> Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ > >> > >> The fix for JDK-8034775 introduced a start-up check requiring the number > >> of compiler threads to be >= 1, which does not make sense for non-JIT > >> VMs such as the zero JVM variant. This causes zero JVMs to fail > >> initialization with: > >> > >> CICompilerCount of 0 is invalid; must be at least 1 > >> Error: Could not create the Java Virtual Machine. > >> Error: A fatal exception has occurred. Program will exit. > >> > >> This is caused by a wrong start-up check in > >> src/share/vm/runtime/arguments.cpp where a minimal value of 1 is > >> required no matter the JVM variant. > >> > >> The proposed fix uses the defined CI_COMPILER_COUNT pre-processor > >> constant over a static 1 to pass to verify_min_value(). Since > >> CI_COMPILER_COUNT is going to be defined differently for JVM variants it > >> will make the lower water mark check correct for all JVM variants. > >> > >> There was an error in defining CI_COMPILER_COUNT as well. On line 196 in > >> src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is defined to be 0 > >> (since COMPILER1, COMPILER2 and SHARK are not defined for a Zero build. > >> Then on line 201 in src/share/vm/runtime/globals.hpp the "else" branch > >> of ifdef COMPILER2 is entered and the earlier definition of > >> CI_COMPILER_COUNT (with value 0) overridden to 1. > >> > >> I've amended test/compiler/startup/NumCompilerThreadsCheck.java so as to > >> verify that the lower water mark for Zero JVMs is 0. > >> > >> Thoughts? > >> > >> Cheers, > >> Severin > >> > From david.holmes at oracle.com Tue Apr 29 10:07:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Apr 2014 20:07:07 +1000 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <1398685322.3241.19.camel@localhost.localdomain> References: <1398685322.3241.19.camel@localhost.localdomain> Message-ID: <535F79CB.5090900@oracle.com> On 28/04/2014 9:42 PM, Severin Gehwolf wrote: > Hi, > > Bug: JI-9011998 (I don't seem to be able to create JDK bugs) > Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ > > The fix for JDK-8034775 introduced a start-up check requiring the number > of compiler threads to be >= 1, which does not make sense for non-JIT > VMs such as the zero JVM variant. This causes zero JVMs to fail > initialization with: > > CICompilerCount of 0 is invalid; must be at least 1 > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > This is caused by a wrong start-up check in > src/share/vm/runtime/arguments.cpp where a minimal value of 1 is > required no matter the JVM variant. > > The proposed fix uses the defined CI_COMPILER_COUNT pre-processor > constant over a static 1 to pass to verify_min_value(). Since > CI_COMPILER_COUNT is going to be defined differently for JVM variants it > will make the lower water mark check correct for all JVM variants. > > There was an error in defining CI_COMPILER_COUNT as well. On line 196 in > src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is defined to be 0 > (since COMPILER1, COMPILER2 and SHARK are not defined for a Zero build. > Then on line 201 in src/share/vm/runtime/globals.hpp the "else" branch > of ifdef COMPILER2 is entered and the earlier definition of > CI_COMPILER_COUNT (with value 0) overridden to 1. I don't see that. There are nested if-else branches: 167 #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK) ... 196 #define CI_COMPILER_COUNT 0 197 #else 198 199 #ifdef COMPILER2 200 #define CI_COMPILER_COUNT 2 201 #else 202 #define CI_COMPILER_COUNT 1 203 #endif // COMPILER2 204 205 #endif // no compilers David ----- > I've amended test/compiler/startup/NumCompilerThreadsCheck.java so as to > verify that the lower water mark for Zero JVMs is 0. > > Thoughts? > > Cheers, > Severin > From sgehwolf at redhat.com Tue Apr 29 11:09:10 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 29 Apr 2014 13:09:10 +0200 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <535F79CB.5090900@oracle.com> References: <1398685322.3241.19.camel@localhost.localdomain> <535F79CB.5090900@oracle.com> Message-ID: <1398769750.3223.17.camel@localhost.localdomain> Hi David, On Tue, 2014-04-29 at 20:07 +1000, David Holmes wrote: > On 28/04/2014 9:42 PM, Severin Gehwolf wrote: > > Hi, > > > > Bug: JI-9011998 (I don't seem to be able to create JDK bugs) > > Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ > > > > The fix for JDK-8034775 introduced a start-up check requiring the number > > of compiler threads to be >= 1, which does not make sense for non-JIT > > VMs such as the zero JVM variant. This causes zero JVMs to fail > > initialization with: > > > > CICompilerCount of 0 is invalid; must be at least 1 > > Error: Could not create the Java Virtual Machine. > > Error: A fatal exception has occurred. Program will exit. > > > > This is caused by a wrong start-up check in > > src/share/vm/runtime/arguments.cpp where a minimal value of 1 is > > required no matter the JVM variant. > > > > The proposed fix uses the defined CI_COMPILER_COUNT pre-processor > > constant over a static 1 to pass to verify_min_value(). Since > > CI_COMPILER_COUNT is going to be defined differently for JVM variants it > > will make the lower water mark check correct for all JVM variants. > > > > There was an error in defining CI_COMPILER_COUNT as well. On line 196 in > > src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is defined to be 0 > > (since COMPILER1, COMPILER2 and SHARK are not defined for a Zero build. > > Then on line 201 in src/share/vm/runtime/globals.hpp the "else" branch > > of ifdef COMPILER2 is entered and the earlier definition of > > CI_COMPILER_COUNT (with value 0) overridden to 1. > > I don't see that. There are nested if-else branches: Doh! Yes, you are right. Good catch! > 167 #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK) > ... > 196 #define CI_COMPILER_COUNT 0 > 197 #else That's the else I've missed :( > 198 > 199 #ifdef COMPILER2 > 200 #define CI_COMPILER_COUNT 2 > 201 #else > 202 #define CI_COMPILER_COUNT 1 > 203 #endif // COMPILER2 > 204 > 205 #endif // no compilers Updated webrev removing the changes to src/share/vm/runtime/globals.hpp: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v2/ As to why the if on line 167 is entered I'm still unsure. Apparently one of COMPILER1, COMPILER2, SHARK is defined for a --with-jvm-variants=zero build. It's not apparent to me which it is and why :-/ config.log has this and the build machine is F20: configure --enable-option-checking=fatal --with-boot-jdk=/usr/lib/jvm/java-1.8.0-openjdk.x86_64 --with-debug-level=slowdebug --disable-zip-debug-info --enable-unlimited-crypto --with-zlib=system --with-giflib=system --with-stdc++lib=dynamic --with-num-cores=8 --with-jvm-variants=zero More thoughts? Cheers, Severin > > I've amended test/compiler/startup/NumCompilerThreadsCheck.java so as to > > verify that the lower water mark for Zero JVMs is 0. > > > > Thoughts? > > > > Cheers, > > Severin > > From Tobias.Hartmann at oracle.com Tue Apr 29 11:11:32 2014 From: Tobias.Hartmann at oracle.com (Tobias Hartmann) Date: Tue, 29 Apr 2014 13:11:32 +0200 Subject: [8u20] RFR(S): 8029436: CICompilerCount is not updated when the number of compiler threads is adjusted to the number of CPUs In-Reply-To: <535A9284.3060701@oracle.com> References: <535A1229.9050602@oracle.com> <535A9284.3060701@oracle.com> Message-ID: <535F88E4.5020205@oracle.com> Vladimir, thanks for the review. I will use export/import for the backport patch. Do I need a second review for this? Thanks, Tobias On 04/25/2014 06:51 PM, Vladimir Kozlov wrote: > Looks good. > > Please, use 'hg export ba83e8806d8d > patch / hg import patch' without > modifying the patch so the bug id and whole description stay the same. > > Thanks, > Vladimir > > On 4/25/14 12:43 AM, Tobias Hartmann wrote: >> Hi, >> >> I would like to request a 8u20 backport of my patch for 8029436. >> >> The changes were pushed into jdk9 11 days ago and nightly testing >> showed no problems. The changes applied to 8u20 >> without conflicts. >> >> Master bug: https://bugs.openjdk.java.net/browse/JDK-8029436 >> Webrev: http://cr.openjdk.java.net/~anoll/8029436/webrev.02/ >> >> Changeset: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ba83e8806d8d >> >> Thanks, >> Tobias From sgehwolf at redhat.com Tue Apr 29 11:34:01 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 29 Apr 2014 13:34:01 +0200 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <1398769750.3223.17.camel@localhost.localdomain> References: <1398685322.3241.19.camel@localhost.localdomain> <535F79CB.5090900@oracle.com> <1398769750.3223.17.camel@localhost.localdomain> Message-ID: <1398771241.3223.21.camel@localhost.localdomain> On Tue, 2014-04-29 at 13:09 +0200, Severin Gehwolf wrote: [...] > As to why the if on line 167 is entered I'm still unsure. Apparently one > of COMPILER1, COMPILER2, SHARK is defined for a --with-jvm-variants=zero > build. It's not apparent to me which it is and why :-/ Well scratch that. It appears I've not had enough coffee today. Sorry for the noise. Cheers, Severin From volker.simonis at gmail.com Tue Apr 29 13:43:16 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Apr 2014 15:43:16 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <5347CED1.3000908@oracle.com> References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> <5347C745.2040901@oracle.com> <5347CED1.3000908@oracle.com> Message-ID: Hi everybody, I'm still looking for a sponsor for this change. Thanks, Volker On Fri, Apr 11, 2014 at 1:15 PM, David Holmes wrote: > On 11/04/2014 8:43 PM, David Holmes wrote: >> >> On 11/04/2014 8:34 PM, Volker Simonis wrote: >>> >>> On Fri, Apr 11, 2014 at 3:58 AM, David Holmes >> > wrote: >>> >>> On 11/04/2014 4:33 AM, Volker Simonis wrote: >>> >>> Hi David, >>> >>> thanks for looking at this issue. >>> >>> I agree with you and I've completely removed >>> ALLOW_OPERATOR_NEW now: >>> >>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805.v2/ >>> >>> >>> >>> I actually meant delete the whole block guarded by >>> ALLOW_OPERATOR_NEW - we don't need these error-trapping definitions >>> now we have fixed the export problem. >>> >>> >>> OK, but arguing this way, we could remove remove all asserts from the >>> code, once we fixed an error revealed by them. >> >> >> Obviously you have to draw a line somewhere. But I don't think these >> particular methods are worth the problem they are now causing. > > > Ignore that. I just realized it is not the external linkage to these methods > that is the main issue, but some internal hotspot code calling the global > operator new/delete. > > David > > >> Cheers, >> David >> >>> I think the error-trapping new/delete operators are still valuable in >>> protecting people from accidentally calling them (and they don't really >>> hurt anybody in terms of performance or space). >>> >>> Regards, >>> Volker >>> >>> FYI I'm not in the runtime group. >>> >>> David >>> ----- >>> >>> >>> I've also changed the "guarantee" into "fatal" as proposed by >>> Vladimir. >>> >>> I've thought a little while about the problem that some other >>> code may >>> unintentionally use these operators but I couldn?t really find a >>> scenario where this could happen. Because as you correctly >>> pointed >>> out, these operators aren't exported from libjvm.so - after all, >>> that's the whole reason for compiling with visibility=hidden and >>> using >>> of export maps. So if another program/library will load >>> libjvm.so, the >>> operators won't be visible. On the other hand, if the libjvm.so >>> loads >>> another shared libraries which use these operators they either >>> have >>> their own, private versions of them or they are dynamically >>> linked >>> against another library (most probably the standard library) >>> which >>> provides versions of the operators. >>> >>> So if I'm not totally wrong, we could in principle also enable >>> these >>> operators in the product build. However, I'm not proposing >>> that for >>> this change. Let's first fix the signatures and get rid of >>> ALLOW_OPERATOR_NEW with this change. If everything works fine, >>> we can >>> think about enabling these global operators in product builds as >>> well. >>> >>> By the way - are you from the runtime group? >>> I was asked to get a review from a runtime-group member - >>> anybody out >>> there willing to volunteer? >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Thu, Apr 10, 2014 at 5:19 AM, David Holmes >>> > wrote: >>> >>> I think we should just delete the whole ALLOW_OPERATOR_NEW >>> block. We fixed >>> the problem of it being called outside the VM under 8014326. >>> >>> David >>> >>> >>> On 10/04/2014 12:48 PM, David Holmes wrote: >>> >>> >>> Hi Volker, >>> >>> Need more time to consider this in full but from the >>> existing code: >>> >>> 689 // On certain platforms, such as Mac OS X >>> (Darwin), in debug >>> version, new is being called >>> 690 // from jdk source and causing data corruption. >>> Such as >>> 691 // >>> >>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >>> 692 // define ALLOW_OPERATOR_NEW_USAGE for platform >>> on which global >>> operator new allowed. >>> >>> we actually fixed that by using the mapfiles to ensure >>> the hotspot >>> operator new was not visible externally. The existence of >>> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the >>> time :( >>> >>> https://bugs.openjdk.java.net/__browse/JDK-8014326 >>> >>> >>> David >>> >>> On 10/04/2014 2:34 AM, Volker Simonis wrote: >>> >>> >>> Hi, >>> >>> could you please review and sponsor the following >>> small change: >>> >>> >>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805/ >>> >>> >>> https://bugs.openjdk.java.net/__browse/JDK-8039805 >>> >>> >>> which fixes the signature of the global new/delete >>> operators in >>> allocation.cpp >>> >>> For non-product builds allocation.cpp defines global >>> new/delete >>> operators which shut down the VM if they get called >>> at runtime. The >>> rational behind this is that the these global >>> operators should never >>> be used in HotSpot. >>> >>> Unfortunately, the signature of some of these >>> operators doesn't >>> conform to the C++ standard which confuses some C++ >>> compilers. For a >>> more detailed explanation of the C++ background of >>> this issue see the >>> new comments in allcoation.cpp and the end of this >>> mail. >>> >>> This change also replaces the asserts in the >>> operators with guarantees >>> because the code may also be active in not-product >>> (aka. 'optimized') >>> builds. >>> >>> Finally, the webrev fixes two places in the AIX-port >>> which used the >>> global new operator. After the change we can now >>> remove the definition >>> of ALLOW_OPERATOR_NEW_USAGE from >>> aix/makefiles/vm.make. >>> >>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >>> bsd/makefiles/vm.make and the corresponding comments >>> in allcoation.cpp >>> which state that on Mac OS X the global new/delete >>> operators from the >>> HotSpot cause problems together with usages of these >>> operators from >>> the class library such as the ones from >>> >>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair. >>> I couldn?t >>> observe any such problems but if anybody has some >>> concrete concerns >>> I'm ready to remove this part from the webrev. >>> >>> I've build and tested these changes on Linux/x86_64, >>> Linux/ppc64, >>> Solaris/Sparc, Windows/x86_64, MacOS X and >>> AIX/ppc64. I've especially >>> run the regression tests from sun/security/ec which >>> exercise the >>> method >>> >>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >>> which >>> was mentioned to cause problems in conjunction with >>> the globally >>> defined new/delete operators from the HotSpot but >>> couldn't see any >>> issues, neither in the slowdebug nor in the >>> optimized build. >>> >>> Following some C++ background regarding the global >>> new/delete operators: >>> >>> In C++98/03 the throwing new operators are defined >>> with the following >>> signature: >>> >>> void* operator new(std::size_tsize) >>> throw(std::bad_alloc); >>> void* operator new[](std::size_tsize) >>> throw(std::bad_alloc); >>> >>> while all the other (non-throwing) new and delete >>> operators are >>> defined with an empty throw clause (i.e. "operator >>> delete(void* p) >>> throw()") which means that they do not throw any >>> exceptions (see >>> section 18.4 of the C++ standard >>> >>> http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2005/__n1905.pdf >>> >>> ). >>> >>> In the new C++11/14 standard >>> >>> (http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2013/__n3797.pdf >>> >>> ), >>> the signature of the throwing new operators was >>> changed by completely >>> omitting the throw clause (which effectively means >>> they could throw >>> any exception) while all the other new/delete >>> operators where changed >>> to have a 'nothrow' clause instead of an empty throw >>> clause. >>> >>> Unfortunately, the support for exception >>> specifications among C++ >>> compilers is still very fragile. While some more >>> strict compilers like >>> AIX xlC or HP aCC reject to override the default >>> throwing new operator >>> with a user operator with an empty throw() clause, >>> the MS Visual C++ >>> compiler warns for every non-empty throw clause like >>> throw(std::bad_alloc) that it will ignore the >>> exception specification >>> (see >>> >>> http://msdn.microsoft.com/en-__us/library/sa28fef8.aspx >>> >>> ). >>> >>> I've therefore changed the operator definitions such >>> that they >>> correctly work with all currently supported >>> compilers and in way which >>> should be upwards compatible with C++11/14. >>> >>> Please notice that I'm aware of the discussion >>> around "8021954: VM >>> SIGSEGV during classloading on MacOS; hs_err_pid >>> file produced" >>> >>> >>> >>> (http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2013-August/thread.html#8924 >>> >>> >>> >>> , >>> >>> >>> >>> http://hg.openjdk.java.net/__hsx/hotspot-comp/hotspot/rev/__9758d9f36299 >>> >>> ) >>> which introduced empty throw() clauses on all user >>> defined new >>> operators. But I think the rational used for that >>> change doesn't apply >>> here, because these global, user user defined new >>> operators changed in >>> this webrev aren't meant to be really used. There >>> only task is to >>> override the default, global operators (and >>> therefore they need to >>> have the right signature) and to shut the VM down if >>> they get called. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> > From lois.foltan at oracle.com Tue Apr 29 13:59:55 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 29 Apr 2014 09:59:55 -0400 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> <5347C745.2040901@oracle.com> <5347CED1.3000908@oracle.com> Message-ID: <535FB05B.6030605@oracle.com> On 4/29/2014 9:43 AM, Volker Simonis wrote: > Hi everybody, > > I'm still looking for a sponsor for this change. Hi Volker, Can I ask a favor, could you send out your latest webrev. Maybe my misunderstanding, but I thought this was left off at David's last comment that ALLOW_OPERATOR_NEW should not be removed after all which you had removed in your last webrev. I can sponsor you for JDK 9 but am not a committer for JDK 8 so would not be able to backport the change. Thanks, Lois > > Thanks, > Volker > > On Fri, Apr 11, 2014 at 1:15 PM, David Holmes wrote: >> On 11/04/2014 8:43 PM, David Holmes wrote: >>> On 11/04/2014 8:34 PM, Volker Simonis wrote: >>>> On Fri, Apr 11, 2014 at 3:58 AM, David Holmes >>> > wrote: >>>> >>>> On 11/04/2014 4:33 AM, Volker Simonis wrote: >>>> >>>> Hi David, >>>> >>>> thanks for looking at this issue. >>>> >>>> I agree with you and I've completely removed >>>> ALLOW_OPERATOR_NEW now: >>>> >>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805.v2/ >>>> >>>> >>>> >>>> I actually meant delete the whole block guarded by >>>> ALLOW_OPERATOR_NEW - we don't need these error-trapping definitions >>>> now we have fixed the export problem. >>>> >>>> >>>> OK, but arguing this way, we could remove remove all asserts from the >>>> code, once we fixed an error revealed by them. >>> >>> Obviously you have to draw a line somewhere. But I don't think these >>> particular methods are worth the problem they are now causing. >> >> Ignore that. I just realized it is not the external linkage to these methods >> that is the main issue, but some internal hotspot code calling the global >> operator new/delete. >> >> David >> >> >>> Cheers, >>> David >>> >>>> I think the error-trapping new/delete operators are still valuable in >>>> protecting people from accidentally calling them (and they don't really >>>> hurt anybody in terms of performance or space). >>>> >>>> Regards, >>>> Volker >>>> >>>> FYI I'm not in the runtime group. >>>> >>>> David >>>> ----- >>>> >>>> >>>> I've also changed the "guarantee" into "fatal" as proposed by >>>> Vladimir. >>>> >>>> I've thought a little while about the problem that some other >>>> code may >>>> unintentionally use these operators but I couldn?t really find a >>>> scenario where this could happen. Because as you correctly >>>> pointed >>>> out, these operators aren't exported from libjvm.so - after all, >>>> that's the whole reason for compiling with visibility=hidden and >>>> using >>>> of export maps. So if another program/library will load >>>> libjvm.so, the >>>> operators won't be visible. On the other hand, if the libjvm.so >>>> loads >>>> another shared libraries which use these operators they either >>>> have >>>> their own, private versions of them or they are dynamically >>>> linked >>>> against another library (most probably the standard library) >>>> which >>>> provides versions of the operators. >>>> >>>> So if I'm not totally wrong, we could in principle also enable >>>> these >>>> operators in the product build. However, I'm not proposing >>>> that for >>>> this change. Let's first fix the signatures and get rid of >>>> ALLOW_OPERATOR_NEW with this change. If everything works fine, >>>> we can >>>> think about enabling these global operators in product builds as >>>> well. >>>> >>>> By the way - are you from the runtime group? >>>> I was asked to get a review from a runtime-group member - >>>> anybody out >>>> there willing to volunteer? >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> >>>> On Thu, Apr 10, 2014 at 5:19 AM, David Holmes >>>> > wrote: >>>> >>>> I think we should just delete the whole ALLOW_OPERATOR_NEW >>>> block. We fixed >>>> the problem of it being called outside the VM under 8014326. >>>> >>>> David >>>> >>>> >>>> On 10/04/2014 12:48 PM, David Holmes wrote: >>>> >>>> >>>> Hi Volker, >>>> >>>> Need more time to consider this in full but from the >>>> existing code: >>>> >>>> 689 // On certain platforms, such as Mac OS X >>>> (Darwin), in debug >>>> version, new is being called >>>> 690 // from jdk source and causing data corruption. >>>> Such as >>>> 691 // >>>> >>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >>>> 692 // define ALLOW_OPERATOR_NEW_USAGE for platform >>>> on which global >>>> operator new allowed. >>>> >>>> we actually fixed that by using the mapfiles to ensure >>>> the hotspot >>>> operator new was not visible externally. The existence of >>>> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the >>>> time :( >>>> >>>> https://bugs.openjdk.java.net/__browse/JDK-8014326 >>>> >>>> >>>> David >>>> >>>> On 10/04/2014 2:34 AM, Volker Simonis wrote: >>>> >>>> >>>> Hi, >>>> >>>> could you please review and sponsor the following >>>> small change: >>>> >>>> >>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805/ >>>> >>>> >>>> https://bugs.openjdk.java.net/__browse/JDK-8039805 >>>> >>>> >>>> which fixes the signature of the global new/delete >>>> operators in >>>> allocation.cpp >>>> >>>> For non-product builds allocation.cpp defines global >>>> new/delete >>>> operators which shut down the VM if they get called >>>> at runtime. The >>>> rational behind this is that the these global >>>> operators should never >>>> be used in HotSpot. >>>> >>>> Unfortunately, the signature of some of these >>>> operators doesn't >>>> conform to the C++ standard which confuses some C++ >>>> compilers. For a >>>> more detailed explanation of the C++ background of >>>> this issue see the >>>> new comments in allcoation.cpp and the end of this >>>> mail. >>>> >>>> This change also replaces the asserts in the >>>> operators with guarantees >>>> because the code may also be active in not-product >>>> (aka. 'optimized') >>>> builds. >>>> >>>> Finally, the webrev fixes two places in the AIX-port >>>> which used the >>>> global new operator. After the change we can now >>>> remove the definition >>>> of ALLOW_OPERATOR_NEW_USAGE from >>>> aix/makefiles/vm.make. >>>> >>>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >>>> bsd/makefiles/vm.make and the corresponding comments >>>> in allcoation.cpp >>>> which state that on Mac OS X the global new/delete >>>> operators from the >>>> HotSpot cause problems together with usages of these >>>> operators from >>>> the class library such as the ones from >>>> >>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair. >>>> I couldn?t >>>> observe any such problems but if anybody has some >>>> concrete concerns >>>> I'm ready to remove this part from the webrev. >>>> >>>> I've build and tested these changes on Linux/x86_64, >>>> Linux/ppc64, >>>> Solaris/Sparc, Windows/x86_64, MacOS X and >>>> AIX/ppc64. I've especially >>>> run the regression tests from sun/security/ec which >>>> exercise the >>>> method >>>> >>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >>>> which >>>> was mentioned to cause problems in conjunction with >>>> the globally >>>> defined new/delete operators from the HotSpot but >>>> couldn't see any >>>> issues, neither in the slowdebug nor in the >>>> optimized build. >>>> >>>> Following some C++ background regarding the global >>>> new/delete operators: >>>> >>>> In C++98/03 the throwing new operators are defined >>>> with the following >>>> signature: >>>> >>>> void* operator new(std::size_tsize) >>>> throw(std::bad_alloc); >>>> void* operator new[](std::size_tsize) >>>> throw(std::bad_alloc); >>>> >>>> while all the other (non-throwing) new and delete >>>> operators are >>>> defined with an empty throw clause (i.e. "operator >>>> delete(void* p) >>>> throw()") which means that they do not throw any >>>> exceptions (see >>>> section 18.4 of the C++ standard >>>> >>>> http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2005/__n1905.pdf >>>> >>>> ). >>>> >>>> In the new C++11/14 standard >>>> >>>> (http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2013/__n3797.pdf >>>> >>>> ), >>>> the signature of the throwing new operators was >>>> changed by completely >>>> omitting the throw clause (which effectively means >>>> they could throw >>>> any exception) while all the other new/delete >>>> operators where changed >>>> to have a 'nothrow' clause instead of an empty throw >>>> clause. >>>> >>>> Unfortunately, the support for exception >>>> specifications among C++ >>>> compilers is still very fragile. While some more >>>> strict compilers like >>>> AIX xlC or HP aCC reject to override the default >>>> throwing new operator >>>> with a user operator with an empty throw() clause, >>>> the MS Visual C++ >>>> compiler warns for every non-empty throw clause like >>>> throw(std::bad_alloc) that it will ignore the >>>> exception specification >>>> (see >>>> >>>> http://msdn.microsoft.com/en-__us/library/sa28fef8.aspx >>>> >>>> ). >>>> >>>> I've therefore changed the operator definitions such >>>> that they >>>> correctly work with all currently supported >>>> compilers and in way which >>>> should be upwards compatible with C++11/14. >>>> >>>> Please notice that I'm aware of the discussion >>>> around "8021954: VM >>>> SIGSEGV during classloading on MacOS; hs_err_pid >>>> file produced" >>>> >>>> >>>> >>>> (http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2013-August/thread.html#8924 >>>> >>>> >>>> >>>> , >>>> >>>> >>>> >>>> http://hg.openjdk.java.net/__hsx/hotspot-comp/hotspot/rev/__9758d9f36299 >>>> >>>> ) >>>> which introduced empty throw() clauses on all user >>>> defined new >>>> operators. But I think the rational used for that >>>> change doesn't apply >>>> here, because these global, user user defined new >>>> operators changed in >>>> this webrev aren't meant to be really used. There >>>> only task is to >>>> override the default, global operators (and >>>> therefore they need to >>>> have the right signature) and to shut the VM down if >>>> they get called. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> >>>> From goetz.lindenmaier at sap.com Tue Apr 29 14:08:48 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Apr 2014 14:08:48 +0000 Subject: Introduce umbrella header orderAccess.inline.hpp Message-ID: <4295855A5C1DE049A61835A1887419CC2CEB3B34@DEWDFEMB12A.global.corp.sap> Hi, I would like to contribute a change that introduces an umbrella header orderAccess.inline.hpp to avoid the long #ifdef TARGET_OS_ARCH cascades. There aren't too much of these, but that's because most files that require that include automagically include the files with the implementation. With the umbrella header the includes can be listed explicitly without having to add the #ifdef platform cascades everywhere. This follows the scheme that was applied to atomic.inline.hpp. Please tell me whether this change is acceptable, then I will open an appropriate bug and send a RFR. The webrev below isn't tested sufficiently yet. Preliminary webrev: http://cr.openjdk.java.net/~goetz/webrevs/orderAcc_proposal/ The change would introduce the new file runtime/orderAccess.inline.hpp. Further this change adds includes of orderAccess.inline.hpp in all .cpp and .inline.hpp files where a method of OrderAccess declared 'inline' is called. Finally it moves methods calling inline methods of OrderAccess from g1CollectedHeap.hpp and thread.hpp to the corresponding .inline.hpp files and adds the necessary includes in files using the moved functions. Still a lot of calls to inline methods of OrderAccess in .hpp files aren't preceded by an according include. But for these files an appropriate .inline.hpp file is missing: src/cpu/ppc/vm/javaFrameAnchor_ppc.hpp src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp src/share/vm/classfile/classLoader.hpp src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp src/share/vm/memory/cardTableModRefBS.hpp src/share/vm/oops/constantPool.hpp src/share/vm/oops/cpCache.hpp src/share/vm/oops/instanceKlass.hpp src/share/vm/oops/method.hpp src/share/vm/oops/methodData.hpp src/share/vm/oops/typeArrayOop.hpp src/share/vm/runtime/interfaceSupport.hpp src/share/vm/utilities/array.hpp src/share/vm/utilities/taskqueue.hpp Best regards, Goetz. From stefan.karlsson at oracle.com Tue Apr 29 14:54:47 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 29 Apr 2014 16:54:47 +0200 Subject: Introduce umbrella header orderAccess.inline.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEB3B34@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEB3B34@DEWDFEMB12A.global.corp.sap> Message-ID: <535FBD37.9070005@oracle.com> Hi Goetz, On 2014-04-29 16:08, Lindenmaier, Goetz wrote: > Hi, > > I would like to contribute a change that introduces an umbrella header > orderAccess.inline.hpp to avoid the long #ifdef TARGET_OS_ARCH cascades. > There aren't too much of these, but that's because most files that > require that include automagically include the files with the > implementation. > With the umbrella header the includes can be listed explicitly without > having to add the #ifdef platform cascades everywhere. > > This follows the scheme that was applied to atomic.inline.hpp. > > Please tell me whether this change is acceptable, then I will open > an appropriate bug and send a RFR. This seems like a good change to me. StefanK > The webrev below isn't tested > sufficiently yet. > > Preliminary webrev: > http://cr.openjdk.java.net/~goetz/webrevs/orderAcc_proposal/ > > The change would introduce the new file runtime/orderAccess.inline.hpp. > > Further this change adds includes of orderAccess.inline.hpp in all .cpp > and .inline.hpp files where a method of OrderAccess declared 'inline' is > called. > > Finally it moves methods calling inline methods of OrderAccess from > g1CollectedHeap.hpp and thread.hpp to the corresponding .inline.hpp > files and adds the necessary includes in files using the moved > functions. > > Still a lot of calls to inline methods of OrderAccess in .hpp > files aren't preceded by an according include. But for these > files an appropriate .inline.hpp file is missing: > > src/cpu/ppc/vm/javaFrameAnchor_ppc.hpp > src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp > src/share/vm/classfile/classLoader.hpp > src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp > src/share/vm/memory/cardTableModRefBS.hpp > src/share/vm/oops/constantPool.hpp > src/share/vm/oops/cpCache.hpp > src/share/vm/oops/instanceKlass.hpp > src/share/vm/oops/method.hpp > src/share/vm/oops/methodData.hpp > src/share/vm/oops/typeArrayOop.hpp > src/share/vm/runtime/interfaceSupport.hpp > src/share/vm/utilities/array.hpp > src/share/vm/utilities/taskqueue.hpp > > Best regards, > Goetz. From vladimir.kozlov at oracle.com Tue Apr 29 16:51:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Apr 2014 09:51:24 -0700 Subject: [8u20] RFR(S): 8029436: CICompilerCount is not updated when the number of compiler threads is adjusted to the number of CPUs In-Reply-To: <535F88E4.5020205@oracle.com> References: <535A1229.9050602@oracle.com> <535A9284.3060701@oracle.com> <535F88E4.5020205@oracle.com> Message-ID: <535FD88C.7090307@oracle.com> On 4/29/14 4:11 AM, Tobias Hartmann wrote: > Vladimir, thanks for the review. I will use export/import for the backport patch. > > Do I need a second review for this? Not always. These changes are relatively small so you can push them with one original reviewer approval. Thanks, Vladimir > > Thanks, > Tobias > > On 04/25/2014 06:51 PM, Vladimir Kozlov wrote: >> Looks good. >> >> Please, use 'hg export ba83e8806d8d > patch / hg import patch' without modifying the patch so the bug id and whole >> description stay the same. >> >> Thanks, >> Vladimir >> >> On 4/25/14 12:43 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> I would like to request a 8u20 backport of my patch for 8029436. >>> >>> The changes were pushed into jdk9 11 days ago and nightly testing showed no problems. The changes applied to 8u20 >>> without conflicts. >>> >>> Master bug: https://bugs.openjdk.java.net/browse/JDK-8029436 >>> Webrev: http://cr.openjdk.java.net/~anoll/8029436/webrev.02/ >>> Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ba83e8806d8d >>> >>> Thanks, >>> Tobias > From vladimir.kozlov at oracle.com Tue Apr 29 16:54:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Apr 2014 09:54:35 -0700 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <1398771241.3223.21.camel@localhost.localdomain> References: <1398685322.3241.19.camel@localhost.localdomain> <535F79CB.5090900@oracle.com> <1398769750.3223.17.camel@localhost.localdomain> <1398771241.3223.21.camel@localhost.localdomain> Message-ID: <535FD94B.4070901@oracle.com> Hi Severin, Is it your final webrev?: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v2/ Thanks, Vladimir On 4/29/14 4:34 AM, Severin Gehwolf wrote: > On Tue, 2014-04-29 at 13:09 +0200, Severin Gehwolf wrote: > [...] >> As to why the if on line 167 is entered I'm still unsure. Apparently one >> of COMPILER1, COMPILER2, SHARK is defined for a --with-jvm-variants=zero >> build. It's not apparent to me which it is and why :-/ > > Well scratch that. It appears I've not had enough coffee today. Sorry > for the noise. > > Cheers, > Severin > From iris.clark at oracle.com Tue Apr 29 16:59:38 2014 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 29 Apr 2014 09:59:38 -0700 (PDT) Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <1398763837.3223.9.camel@localhost.localdomain> References: <1398685322.3241.19.camel@localhost.localdomain> <535E9A5A.8060605@oracle.com> <535F6470.1050307@oracle.com> <1398763837.3223.9.camel@localhost.localdomain> Message-ID: <0e1cdacf-ebab-4f5e-9c97-1abfe638405d@default> Hi, Severin. > I work for Red Hat and I believe it has signed the OCA as a company. Not sure if this makes me a contributor. You're a Contributor. Red Hat is on the Signatories List [1]. Thanks, iris [1]: http://www.oracle.com/technetwork/community/oca-486395.html -----Original Message----- From: Severin Gehwolf [mailto:sgehwolf at redhat.com] Sent: Tuesday, April 29, 2014 2:31 AM To: hotspot-dev at openjdk.java.net Subject: Re: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs Hi Albert, On Tue, 2014-04-29 at 10:36 +0200, Albert wrote: > Hi, > > sorry, it was my change that introduced the bug. The change looks good > to me as well. Thanks for looking at the patch! > However, I am not a reviewer, so I think a second review would be good. OK. > Or is the change > simple enough that 1 review is fine? I am not sure. > > Are you a contributor? ( http://openjdk.java.net/contribute/ ) If yes, > I will push your changes as soon as I have an OK. I work for Red Hat and I believe it has signed the OCA as a company. Not sure if this makes me a contributor. Cheers, Severin > On 04/28/2014 08:13 PM, Vladimir Kozlov wrote: > > Hi Severin, > > > > Your fix looks reasonable. > > > > Sorry for breaking your build. I assigned the bug to Albert. He will > > sponsor your changes. > > > > Thanks, > > Vladimir > > > > On 4/28/14 4:42 AM, Severin Gehwolf wrote: > >> Hi, > >> > >> Bug: JI-9011998 (I don't seem to be able to create JDK bugs) > >> Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ > >> > >> The fix for JDK-8034775 introduced a start-up check requiring the > >> number of compiler threads to be >= 1, which does not make sense > >> for non-JIT VMs such as the zero JVM variant. This causes zero JVMs > >> to fail initialization with: > >> > >> CICompilerCount of 0 is invalid; must be at least 1 > >> Error: Could not create the Java Virtual Machine. > >> Error: A fatal exception has occurred. Program will exit. > >> > >> This is caused by a wrong start-up check in > >> src/share/vm/runtime/arguments.cpp where a minimal value of 1 is > >> required no matter the JVM variant. > >> > >> The proposed fix uses the defined CI_COMPILER_COUNT pre-processor > >> constant over a static 1 to pass to verify_min_value(). Since > >> CI_COMPILER_COUNT is going to be defined differently for JVM > >> variants it will make the lower water mark check correct for all JVM variants. > >> > >> There was an error in defining CI_COMPILER_COUNT as well. On line > >> 196 in src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is > >> defined to be 0 (since COMPILER1, COMPILER2 and SHARK are not defined for a Zero build. > >> Then on line 201 in src/share/vm/runtime/globals.hpp the "else" > >> branch of ifdef COMPILER2 is entered and the earlier definition of > >> CI_COMPILER_COUNT (with value 0) overridden to 1. > >> > >> I've amended test/compiler/startup/NumCompilerThreadsCheck.java so > >> as to verify that the lower water mark for Zero JVMs is 0. > >> > >> Thoughts? > >> > >> Cheers, > >> Severin > >> > From Tobias.Hartmann at oracle.com Tue Apr 29 17:11:16 2014 From: Tobias.Hartmann at oracle.com (Tobias Hartmann) Date: Tue, 29 Apr 2014 19:11:16 +0200 Subject: [8u20] RFR(S): 8029436: CICompilerCount is not updated when the number of compiler threads is adjusted to the number of CPUs In-Reply-To: <535FD88C.7090307@oracle.com> References: <535A1229.9050602@oracle.com> <535A9284.3060701@oracle.com> <535F88E4.5020205@oracle.com> <535FD88C.7090307@oracle.com> Message-ID: <535FDD34.2080108@oracle.com> Okay, thanks. Tobias On 04/29/2014 06:51 PM, Vladimir Kozlov wrote: > On 4/29/14 4:11 AM, Tobias Hartmann wrote: >> Vladimir, thanks for the review. I will use export/import for the >> backport patch. >> >> Do I need a second review for this? > > Not always. These changes are relatively small so you can push them > with one original reviewer approval. > > Thanks, > Vladimir > >> >> Thanks, >> Tobias >> >> On 04/25/2014 06:51 PM, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Please, use 'hg export ba83e8806d8d > patch / hg import patch' >>> without modifying the patch so the bug id and whole >>> description stay the same. >>> >>> Thanks, >>> Vladimir >>> >>> On 4/25/14 12:43 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> I would like to request a 8u20 backport of my patch for 8029436. >>>> >>>> The changes were pushed into jdk9 11 days ago and nightly testing >>>> showed no problems. The changes applied to 8u20 >>>> without conflicts. >>>> >>>> Master bug: https://bugs.openjdk.java.net/browse/JDK-8029436 >>>> Webrev: http://cr.openjdk.java.net/~anoll/8029436/webrev.02/ >>>> >>>> Changeset: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ba83e8806d8d >>>> >>>> Thanks, >>>> Tobias >> From volker.simonis at gmail.com Tue Apr 29 17:24:43 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Apr 2014 19:24:43 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <535FB05B.6030605@oracle.com> References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> <5347C745.2040901@oracle.com> <5347CED1.3000908@oracle.com> <535FB05B.6030605@oracle.com> Message-ID: Hi Lois, sure, the latest webrev was: http://cr.openjdk.java.net/~simonis/webrevs/8039805.v3/ As far as I understood, David recalled his concerns in his last mail ("..Ignore that. I just realized it is not the external linkage to these methods that is the main issue, but some internal hotspot code calling the global operator new/delete.." - see http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013523.html) @David: are you OK with the change now? Thanks, Volker PS: jdk9 is just fine for now - thanks for helping out! On Tue, Apr 29, 2014 at 3:59 PM, Lois Foltan wrote: > > On 4/29/2014 9:43 AM, Volker Simonis wrote: >> >> Hi everybody, >> >> I'm still looking for a sponsor for this change. > > > Hi Volker, > > Can I ask a favor, could you send out your latest webrev. Maybe my > misunderstanding, but I thought this was left off at David's last comment > that ALLOW_OPERATOR_NEW should not be removed after all which you had > removed in your last webrev. > > I can sponsor you for JDK 9 but am not a committer for JDK 8 so would not be > able to backport the change. > > Thanks, > Lois > > >> >> Thanks, >> Volker >> >> On Fri, Apr 11, 2014 at 1:15 PM, David Holmes >> wrote: >>> >>> On 11/04/2014 8:43 PM, David Holmes wrote: >>>> >>>> On 11/04/2014 8:34 PM, Volker Simonis wrote: >>>>> >>>>> On Fri, Apr 11, 2014 at 3:58 AM, David Holmes >>>> > wrote: >>>>> >>>>> On 11/04/2014 4:33 AM, Volker Simonis wrote: >>>>> >>>>> Hi David, >>>>> >>>>> thanks for looking at this issue. >>>>> >>>>> I agree with you and I've completely removed >>>>> ALLOW_OPERATOR_NEW now: >>>>> >>>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805.v2/ >>>>> >>>>> >>>>> >>>>> I actually meant delete the whole block guarded by >>>>> ALLOW_OPERATOR_NEW - we don't need these error-trapping >>>>> definitions >>>>> now we have fixed the export problem. >>>>> >>>>> >>>>> OK, but arguing this way, we could remove remove all asserts from the >>>>> code, once we fixed an error revealed by them. >>>> >>>> >>>> Obviously you have to draw a line somewhere. But I don't think these >>>> particular methods are worth the problem they are now causing. >>> >>> >>> Ignore that. I just realized it is not the external linkage to these >>> methods >>> that is the main issue, but some internal hotspot code calling the global >>> operator new/delete. >>> >>> David >>> >>> >>>> Cheers, >>>> David >>>> >>>>> I think the error-trapping new/delete operators are still valuable in >>>>> protecting people from accidentally calling them (and they don't really >>>>> hurt anybody in terms of performance or space). >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> FYI I'm not in the runtime group. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> I've also changed the "guarantee" into "fatal" as proposed by >>>>> Vladimir. >>>>> >>>>> I've thought a little while about the problem that some other >>>>> code may >>>>> unintentionally use these operators but I couldn?t really find >>>>> a >>>>> scenario where this could happen. Because as you correctly >>>>> pointed >>>>> out, these operators aren't exported from libjvm.so - after >>>>> all, >>>>> that's the whole reason for compiling with visibility=hidden >>>>> and >>>>> using >>>>> of export maps. So if another program/library will load >>>>> libjvm.so, the >>>>> operators won't be visible. On the other hand, if the >>>>> libjvm.so >>>>> loads >>>>> another shared libraries which use these operators they either >>>>> have >>>>> their own, private versions of them or they are dynamically >>>>> linked >>>>> against another library (most probably the standard library) >>>>> which >>>>> provides versions of the operators. >>>>> >>>>> So if I'm not totally wrong, we could in principle also enable >>>>> these >>>>> operators in the product build. However, I'm not proposing >>>>> that for >>>>> this change. Let's first fix the signatures and get rid of >>>>> ALLOW_OPERATOR_NEW with this change. If everything works fine, >>>>> we can >>>>> think about enabling these global operators in product builds >>>>> as >>>>> well. >>>>> >>>>> By the way - are you from the runtime group? >>>>> I was asked to get a review from a runtime-group member - >>>>> anybody out >>>>> there willing to volunteer? >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> >>>>> On Thu, Apr 10, 2014 at 5:19 AM, David Holmes >>>>> > >>>>> wrote: >>>>> >>>>> I think we should just delete the whole ALLOW_OPERATOR_NEW >>>>> block. We fixed >>>>> the problem of it being called outside the VM under >>>>> 8014326. >>>>> >>>>> David >>>>> >>>>> >>>>> On 10/04/2014 12:48 PM, David Holmes wrote: >>>>> >>>>> >>>>> Hi Volker, >>>>> >>>>> Need more time to consider this in full but from the >>>>> existing code: >>>>> >>>>> 689 // On certain platforms, such as Mac OS X >>>>> (Darwin), in debug >>>>> version, new is being called >>>>> 690 // from jdk source and causing data >>>>> corruption. >>>>> Such as >>>>> 691 // >>>>> >>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >>>>> 692 // define ALLOW_OPERATOR_NEW_USAGE for >>>>> platform >>>>> on which global >>>>> operator new allowed. >>>>> >>>>> we actually fixed that by using the mapfiles to ensure >>>>> the hotspot >>>>> operator new was not visible externally. The existence >>>>> of >>>>> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the >>>>> time :( >>>>> >>>>> https://bugs.openjdk.java.net/__browse/JDK-8014326 >>>>> >>>>> >>>>> David >>>>> >>>>> On 10/04/2014 2:34 AM, Volker Simonis wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> could you please review and sponsor the following >>>>> small change: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805/ >>>>> >>>>> >>>>> https://bugs.openjdk.java.net/__browse/JDK-8039805 >>>>> >>>>> >>>>> which fixes the signature of the global new/delete >>>>> operators in >>>>> allocation.cpp >>>>> >>>>> For non-product builds allocation.cpp defines >>>>> global >>>>> new/delete >>>>> operators which shut down the VM if they get >>>>> called >>>>> at runtime. The >>>>> rational behind this is that the these global >>>>> operators should never >>>>> be used in HotSpot. >>>>> >>>>> Unfortunately, the signature of some of these >>>>> operators doesn't >>>>> conform to the C++ standard which confuses some >>>>> C++ >>>>> compilers. For a >>>>> more detailed explanation of the C++ background of >>>>> this issue see the >>>>> new comments in allcoation.cpp and the end of this >>>>> mail. >>>>> >>>>> This change also replaces the asserts in the >>>>> operators with guarantees >>>>> because the code may also be active in not-product >>>>> (aka. 'optimized') >>>>> builds. >>>>> >>>>> Finally, the webrev fixes two places in the >>>>> AIX-port >>>>> which used the >>>>> global new operator. After the change we can now >>>>> remove the definition >>>>> of ALLOW_OPERATOR_NEW_USAGE from >>>>> aix/makefiles/vm.make. >>>>> >>>>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >>>>> bsd/makefiles/vm.make and the corresponding >>>>> comments >>>>> in allcoation.cpp >>>>> which state that on Mac OS X the global new/delete >>>>> operators from the >>>>> HotSpot cause problems together with usages of >>>>> these >>>>> operators from >>>>> the class library such as the ones from >>>>> >>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair. >>>>> I couldn?t >>>>> observe any such problems but if anybody has some >>>>> concrete concerns >>>>> I'm ready to remove this part from the webrev. >>>>> >>>>> I've build and tested these changes on >>>>> Linux/x86_64, >>>>> Linux/ppc64, >>>>> Solaris/Sparc, Windows/x86_64, MacOS X and >>>>> AIX/ppc64. I've especially >>>>> run the regression tests from sun/security/ec >>>>> which >>>>> exercise the >>>>> method >>>>> >>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >>>>> which >>>>> was mentioned to cause problems in conjunction >>>>> with >>>>> the globally >>>>> defined new/delete operators from the HotSpot but >>>>> couldn't see any >>>>> issues, neither in the slowdebug nor in the >>>>> optimized build. >>>>> >>>>> Following some C++ background regarding the global >>>>> new/delete operators: >>>>> >>>>> In C++98/03 the throwing new operators are defined >>>>> with the following >>>>> signature: >>>>> >>>>> void* operator new(std::size_tsize) >>>>> throw(std::bad_alloc); >>>>> void* operator new[](std::size_tsize) >>>>> throw(std::bad_alloc); >>>>> >>>>> while all the other (non-throwing) new and delete >>>>> operators are >>>>> defined with an empty throw clause (i.e. "operator >>>>> delete(void* p) >>>>> throw()") which means that they do not throw any >>>>> exceptions (see >>>>> section 18.4 of the C++ standard >>>>> >>>>> http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2005/__n1905.pdf >>>>> >>>>> ). >>>>> >>>>> In the new C++11/14 standard >>>>> >>>>> (http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2013/__n3797.pdf >>>>> >>>>> ), >>>>> the signature of the throwing new operators was >>>>> changed by completely >>>>> omitting the throw clause (which effectively means >>>>> they could throw >>>>> any exception) while all the other new/delete >>>>> operators where changed >>>>> to have a 'nothrow' clause instead of an empty >>>>> throw >>>>> clause. >>>>> >>>>> Unfortunately, the support for exception >>>>> specifications among C++ >>>>> compilers is still very fragile. While some more >>>>> strict compilers like >>>>> AIX xlC or HP aCC reject to override the default >>>>> throwing new operator >>>>> with a user operator with an empty throw() clause, >>>>> the MS Visual C++ >>>>> compiler warns for every non-empty throw clause >>>>> like >>>>> throw(std::bad_alloc) that it will ignore the >>>>> exception specification >>>>> (see >>>>> >>>>> http://msdn.microsoft.com/en-__us/library/sa28fef8.aspx >>>>> >>>>> ). >>>>> >>>>> I've therefore changed the operator definitions >>>>> such >>>>> that they >>>>> correctly work with all currently supported >>>>> compilers and in way which >>>>> should be upwards compatible with C++11/14. >>>>> >>>>> Please notice that I'm aware of the discussion >>>>> around "8021954: VM >>>>> SIGSEGV during classloading on MacOS; hs_err_pid >>>>> file produced" >>>>> >>>>> >>>>> >>>>> >>>>> (http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2013-August/thread.html#8924 >>>>> >>>>> >>>>> >>>>> >>>>> , >>>>> >>>>> >>>>> >>>>> >>>>> http://hg.openjdk.java.net/__hsx/hotspot-comp/hotspot/rev/__9758d9f36299 >>>>> >>>>> ) >>>>> which introduced empty throw() clauses on all user >>>>> defined new >>>>> operators. But I think the rational used for that >>>>> change doesn't apply >>>>> here, because these global, user user defined new >>>>> operators changed in >>>>> this webrev aren't meant to be really used. There >>>>> only task is to >>>>> override the default, global operators (and >>>>> therefore they need to >>>>> have the right signature) and to shut the VM down >>>>> if >>>>> they get called. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> >>>>> > From albert.noll at oracle.com Tue Apr 29 18:47:00 2014 From: albert.noll at oracle.com (Albert) Date: Tue, 29 Apr 2014 20:47:00 +0200 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <0e1cdacf-ebab-4f5e-9c97-1abfe638405d@default> References: <1398685322.3241.19.camel@localhost.localdomain> <535E9A5A.8060605@oracle.com> <535F6470.1050307@oracle.com> <1398763837.3223.9.camel@localhost.localdomain> <0e1cdacf-ebab-4f5e-9c97-1abfe638405d@default> Message-ID: <535FF3A4.6010801@oracle.com> Iris, thanks for the clarification. Severin, I will push your changes if they are reviewed. Thanks, Albert On 04/29/2014 06:59 PM, Iris Clark wrote: > Hi, Severin. > >> I work for Red Hat and I believe it has signed the OCA as a company. Not sure if this makes me a contributor. > You're a Contributor. > > Red Hat is on the Signatories List [1]. > > Thanks, > iris > > [1]: http://www.oracle.com/technetwork/community/oca-486395.html > > -----Original Message----- > From: Severin Gehwolf [mailto:sgehwolf at redhat.com] > Sent: Tuesday, April 29, 2014 2:31 AM > To: hotspot-dev at openjdk.java.net > Subject: Re: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs > > Hi Albert, > > On Tue, 2014-04-29 at 10:36 +0200, Albert wrote: >> Hi, >> >> sorry, it was my change that introduced the bug. The change looks good >> to me as well. > Thanks for looking at the patch! > >> However, I am not a reviewer, so I think a second review would be good. > OK. > >> Or is the change >> simple enough that 1 review is fine? I am not sure. >> >> Are you a contributor? ( http://openjdk.java.net/contribute/ ) If yes, >> I will push your changes as soon as I have an OK. > I work for Red Hat and I believe it has signed the OCA as a company. Not sure if this makes me a contributor. > > Cheers, > Severin > >> On 04/28/2014 08:13 PM, Vladimir Kozlov wrote: >>> Hi Severin, >>> >>> Your fix looks reasonable. >>> >>> Sorry for breaking your build. I assigned the bug to Albert. He will >>> sponsor your changes. >>> >>> Thanks, >>> Vladimir >>> >>> On 4/28/14 4:42 AM, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Bug: JI-9011998 (I don't seem to be able to create JDK bugs) >>>> Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ >>>> >>>> The fix for JDK-8034775 introduced a start-up check requiring the >>>> number of compiler threads to be >= 1, which does not make sense >>>> for non-JIT VMs such as the zero JVM variant. This causes zero JVMs >>>> to fail initialization with: >>>> >>>> CICompilerCount of 0 is invalid; must be at least 1 >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> >>>> This is caused by a wrong start-up check in >>>> src/share/vm/runtime/arguments.cpp where a minimal value of 1 is >>>> required no matter the JVM variant. >>>> >>>> The proposed fix uses the defined CI_COMPILER_COUNT pre-processor >>>> constant over a static 1 to pass to verify_min_value(). Since >>>> CI_COMPILER_COUNT is going to be defined differently for JVM >>>> variants it will make the lower water mark check correct for all JVM variants. >>>> >>>> There was an error in defining CI_COMPILER_COUNT as well. On line >>>> 196 in src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is >>>> defined to be 0 (since COMPILER1, COMPILER2 and SHARK are not defined for a Zero build. >>>> Then on line 201 in src/share/vm/runtime/globals.hpp the "else" >>>> branch of ifdef COMPILER2 is entered and the earlier definition of >>>> CI_COMPILER_COUNT (with value 0) overridden to 1. >>>> >>>> I've amended test/compiler/startup/NumCompilerThreadsCheck.java so >>>> as to verify that the lower water mark for Zero JVMs is 0. >>>> >>>> Thoughts? >>>> >>>> Cheers, >>>> Severin >>>> > > From vladimir.kozlov at oracle.com Tue Apr 29 19:23:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Apr 2014 12:23:48 -0700 Subject: RFR (S): 8042059: Various fixes to linux/sparc In-Reply-To: <535EF3FD.1030608@oracle.com> References: <535EF3FD.1030608@oracle.com> Message-ID: <535FFC44.6070106@oracle.com> Looks good. Thanks, Vladimir On 4/28/14 5:36 PM, Mikael Vidstedt wrote: > > All, > > Please review the following set of minor changes which are needed to get > the linux/sparc platform to build and run[1]. The changes are relatively > straightforward so I'm not explaining them more in detail here, but > please ask if there's anything in there which is unclear. > > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8042059/webrev.00/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8042059 > > Cheers, > Mikael > > [1] Note that a few additional minor changes are needed, but they need > to be cleaned up a tad before they're ready to be pushed. > From vladimir.kozlov at oracle.com Tue Apr 29 19:29:02 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Apr 2014 12:29:02 -0700 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <535FF3A4.6010801@oracle.com> References: <1398685322.3241.19.camel@localhost.localdomain> <535E9A5A.8060605@oracle.com> <535F6470.1050307@oracle.com> <1398763837.3223.9.camel@localhost.localdomain> <0e1cdacf-ebab-4f5e-9c97-1abfe638405d@default> <535FF3A4.6010801@oracle.com> Message-ID: <535FFD7E.8020705@oracle.com> Hi Albert, Based on resent mail from Mark we need to publish webrev on our cr. server. Severin sent v2 version and I asked if it is final. Albert if it is final, please, prepare webrev and send official RFR in format we use. Thanks, Vladimir On 4/29/14 11:47 AM, Albert wrote: > Iris, thanks for the clarification. > > Severin, I will push your changes if they are reviewed. > > Thanks, > Albert > > > On 04/29/2014 06:59 PM, Iris Clark wrote: >> Hi, Severin. >> >>> I work for Red Hat and I believe it has signed the OCA as a company. >>> Not sure if this makes me a contributor. >> You're a Contributor. >> >> Red Hat is on the Signatories List [1]. >> >> Thanks, >> iris >> >> [1]: http://www.oracle.com/technetwork/community/oca-486395.html >> >> -----Original Message----- >> From: Severin Gehwolf [mailto:sgehwolf at redhat.com] >> Sent: Tuesday, April 29, 2014 2:31 AM >> To: hotspot-dev at openjdk.java.net >> Subject: Re: Review-Request: Fix of JDK-8034775 neglects to account >> for non-JIT VMs >> >> Hi Albert, >> >> On Tue, 2014-04-29 at 10:36 +0200, Albert wrote: >>> Hi, >>> >>> sorry, it was my change that introduced the bug. The change looks good >>> to me as well. >> Thanks for looking at the patch! >> >>> However, I am not a reviewer, so I think a second review would be good. >> OK. >> >>> Or is the change >>> simple enough that 1 review is fine? I am not sure. >>> >>> Are you a contributor? ( http://openjdk.java.net/contribute/ ) If yes, >>> I will push your changes as soon as I have an OK. >> I work for Red Hat and I believe it has signed the OCA as a company. >> Not sure if this makes me a contributor. >> >> Cheers, >> Severin >> >>> On 04/28/2014 08:13 PM, Vladimir Kozlov wrote: >>>> Hi Severin, >>>> >>>> Your fix looks reasonable. >>>> >>>> Sorry for breaking your build. I assigned the bug to Albert. He will >>>> sponsor your changes. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/28/14 4:42 AM, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Bug: JI-9011998 (I don't seem to be able to create JDK bugs) >>>>> Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ >>>>> >>>>> The fix for JDK-8034775 introduced a start-up check requiring the >>>>> number of compiler threads to be >= 1, which does not make sense >>>>> for non-JIT VMs such as the zero JVM variant. This causes zero JVMs >>>>> to fail initialization with: >>>>> >>>>> CICompilerCount of 0 is invalid; must be at least 1 >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> This is caused by a wrong start-up check in >>>>> src/share/vm/runtime/arguments.cpp where a minimal value of 1 is >>>>> required no matter the JVM variant. >>>>> >>>>> The proposed fix uses the defined CI_COMPILER_COUNT pre-processor >>>>> constant over a static 1 to pass to verify_min_value(). Since >>>>> CI_COMPILER_COUNT is going to be defined differently for JVM >>>>> variants it will make the lower water mark check correct for all >>>>> JVM variants. >>>>> >>>>> There was an error in defining CI_COMPILER_COUNT as well. On line >>>>> 196 in src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is >>>>> defined to be 0 (since COMPILER1, COMPILER2 and SHARK are not >>>>> defined for a Zero build. >>>>> Then on line 201 in src/share/vm/runtime/globals.hpp the "else" >>>>> branch of ifdef COMPILER2 is entered and the earlier definition of >>>>> CI_COMPILER_COUNT (with value 0) overridden to 1. >>>>> >>>>> I've amended test/compiler/startup/NumCompilerThreadsCheck.java so >>>>> as to verify that the lower water mark for Zero JVMs is 0. >>>>> >>>>> Thoughts? >>>>> >>>>> Cheers, >>>>> Severin >>>>> >> >> > From christian.thalinger at oracle.com Tue Apr 29 19:44:24 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 Apr 2014 09:44:24 -1000 Subject: Introduce umbrella header orderAccess.inline.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEB3B34@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEB3B34@DEWDFEMB12A.global.corp.sap> Message-ID: Yes, please. Are you going to do the same for prefetch_*.inline.hpp? ;-) On Apr 29, 2014, at 4:08 AM, Lindenmaier, Goetz wrote: > Hi, > > I would like to contribute a change that introduces an umbrella header > orderAccess.inline.hpp to avoid the long #ifdef TARGET_OS_ARCH cascades. > There aren't too much of these, but that's because most files that > require that include automagically include the files with the > implementation. > With the umbrella header the includes can be listed explicitly without > having to add the #ifdef platform cascades everywhere. > > This follows the scheme that was applied to atomic.inline.hpp. > > Please tell me whether this change is acceptable, then I will open > an appropriate bug and send a RFR. The webrev below isn't tested > sufficiently yet. > > Preliminary webrev: > http://cr.openjdk.java.net/~goetz/webrevs/orderAcc_proposal/ > > The change would introduce the new file runtime/orderAccess.inline.hpp. > > Further this change adds includes of orderAccess.inline.hpp in all .cpp > and .inline.hpp files where a method of OrderAccess declared 'inline' is > called. > > Finally it moves methods calling inline methods of OrderAccess from > g1CollectedHeap.hpp and thread.hpp to the corresponding .inline.hpp > files and adds the necessary includes in files using the moved > functions. > > Still a lot of calls to inline methods of OrderAccess in .hpp > files aren't preceded by an according include. But for these > files an appropriate .inline.hpp file is missing: > > src/cpu/ppc/vm/javaFrameAnchor_ppc.hpp > src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp > src/share/vm/classfile/classLoader.hpp > src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp > src/share/vm/memory/cardTableModRefBS.hpp > src/share/vm/oops/constantPool.hpp > src/share/vm/oops/cpCache.hpp > src/share/vm/oops/instanceKlass.hpp > src/share/vm/oops/method.hpp > src/share/vm/oops/methodData.hpp > src/share/vm/oops/typeArrayOop.hpp > src/share/vm/runtime/interfaceSupport.hpp > src/share/vm/utilities/array.hpp > src/share/vm/utilities/taskqueue.hpp > > Best regards, > Goetz. From vladimir.kozlov at oracle.com Tue Apr 29 21:52:46 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Apr 2014 14:52:46 -0700 Subject: Introduce umbrella header orderAccess.inline.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEB3B34@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEB3B34@DEWDFEMB12A.global.corp.sap> Message-ID: <53601F2E.60907@oracle.com> Looks good. Do you have bug id? thanks, Vladimir On 4/29/14 7:08 AM, Lindenmaier, Goetz wrote: > Hi, > > I would like to contribute a change that introduces an umbrella header > orderAccess.inline.hpp to avoid the long #ifdef TARGET_OS_ARCH cascades. > There aren't too much of these, but that's because most files that > require that include automagically include the files with the > implementation. > With the umbrella header the includes can be listed explicitly without > having to add the #ifdef platform cascades everywhere. > > This follows the scheme that was applied to atomic.inline.hpp. > > Please tell me whether this change is acceptable, then I will open > an appropriate bug and send a RFR. The webrev below isn't tested > sufficiently yet. > > Preliminary webrev: > http://cr.openjdk.java.net/~goetz/webrevs/orderAcc_proposal/ > > The change would introduce the new file runtime/orderAccess.inline.hpp. > > Further this change adds includes of orderAccess.inline.hpp in all .cpp > and .inline.hpp files where a method of OrderAccess declared 'inline' is > called. > > Finally it moves methods calling inline methods of OrderAccess from > g1CollectedHeap.hpp and thread.hpp to the corresponding .inline.hpp > files and adds the necessary includes in files using the moved > functions. > > Still a lot of calls to inline methods of OrderAccess in .hpp > files aren't preceded by an according include. But for these > files an appropriate .inline.hpp file is missing: > > src/cpu/ppc/vm/javaFrameAnchor_ppc.hpp > src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp > src/share/vm/classfile/classLoader.hpp > src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp > src/share/vm/memory/cardTableModRefBS.hpp > src/share/vm/oops/constantPool.hpp > src/share/vm/oops/cpCache.hpp > src/share/vm/oops/instanceKlass.hpp > src/share/vm/oops/method.hpp > src/share/vm/oops/methodData.hpp > src/share/vm/oops/typeArrayOop.hpp > src/share/vm/runtime/interfaceSupport.hpp > src/share/vm/utilities/array.hpp > src/share/vm/utilities/taskqueue.hpp > > Best regards, > Goetz. > From david.holmes at oracle.com Tue Apr 29 23:13:56 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Apr 2014 09:13:56 +1000 Subject: Introduce umbrella header orderAccess.inline.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEB3B34@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEB3B34@DEWDFEMB12A.global.corp.sap> Message-ID: <53603234.3020703@oracle.com> Hi Goetz, On 30/04/2014 12:08 AM, Lindenmaier, Goetz wrote: > Hi, > > I would like to contribute a change that introduces an umbrella header > orderAccess.inline.hpp to avoid the long #ifdef TARGET_OS_ARCH cascades. I'm all for that! I've always hated those cascades. I wish there were some way to parameterise the #include with a $PLATFORM variable. > There aren't too much of these, but that's because most files that > require that include automagically include the files with the > implementation. > With the umbrella header the includes can be listed explicitly without > having to add the #ifdef platform cascades everywhere. > > This follows the scheme that was applied to atomic.inline.hpp. > > Please tell me whether this change is acceptable, then I will open > an appropriate bug and send a RFR. The webrev below isn't tested > sufficiently yet. > > Preliminary webrev: > http://cr.openjdk.java.net/~goetz/webrevs/orderAcc_proposal/ > > The change would introduce the new file runtime/orderAccess.inline.hpp. > > Further this change adds includes of orderAccess.inline.hpp in all .cpp > and .inline.hpp files where a method of OrderAccess declared 'inline' is > called. > > Finally it moves methods calling inline methods of OrderAccess from > g1CollectedHeap.hpp and thread.hpp to the corresponding .inline.hpp > files and adds the necessary includes in files using the moved > functions. > > Still a lot of calls to inline methods of OrderAccess in .hpp > files aren't preceded by an according include. But for these > files an appropriate .inline.hpp file is missing: > > src/cpu/ppc/vm/javaFrameAnchor_ppc.hpp > src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp > src/share/vm/classfile/classLoader.hpp > src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp > src/share/vm/memory/cardTableModRefBS.hpp > src/share/vm/oops/constantPool.hpp > src/share/vm/oops/cpCache.hpp > src/share/vm/oops/instanceKlass.hpp > src/share/vm/oops/method.hpp > src/share/vm/oops/methodData.hpp > src/share/vm/oops/typeArrayOop.hpp > src/share/vm/runtime/interfaceSupport.hpp > src/share/vm/utilities/array.hpp > src/share/vm/utilities/taskqueue.hpp I'm unclear what this means. Do we need to add .inline.hpp files for these? Some of our compilers are very picky about declaration and use of inline functions. David ------ > Best regards, > Goetz. > From david.r.chase at oracle.com Wed Apr 30 02:18:44 2014 From: david.r.chase at oracle.com (David Chase) Date: Tue, 29 Apr 2014 22:18:44 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <04E9C0ED-4F68-4796-8BE9-FF3E116D3F9C@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <535ED251.8000501@oracle.com> <04E9C0ED-4F68-4796-8BE9-FF3E116D3F9C@oracle.com> Message-ID: All recommended changes made except the one that was not possible: > and INTPTR_FORMAT for: > > out->print("%3d:0x" UINT64_FORMAT_X, type(), (uint64_t)as_jlong()); (INTPTR_FORMAT is not guaranteed to be 64 bits) Patch brought up to date with independent partial cleanups in gc code. Diffs scanned for spacing glitches, those found and repaired. Retested, passed. New webrev: http://cr.openjdk.java.net/~drchase/8037816/webrev.03/ One question -- src/share/vm/prims/jvmtiEnter.xsl contains both leading tabs and trailing spaces, and I think the trailing spaces may matter to the (appearance of the) generated code. Will this pass jcheck? David From mikael.vidstedt at oracle.com Wed Apr 30 04:58:05 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 29 Apr 2014 21:58:05 -0700 Subject: RFR (S): 8042059: Various fixes to linux/sparc In-Reply-To: <0D527812-ED4B-4C8E-B2E3-3E1737217385@oracle.com> References: <535EF3FD.1030608@oracle.com> <0D527812-ED4B-4C8E-B2E3-3E1737217385@oracle.com> Message-ID: <536082DD.4040501@oracle.com> Chris, Thanks for pointing that out. I'll split up the change and push the changes to stubGenerator_sparc.cpp separately under that bug number. Chris, Vladimir - thanks for the reviews! Cheers, Mikael On 2014-04-28 17:42, Christian Thalinger wrote: > Looks good. The changes to src/cpu/sparc/vm/stubGenerator_sparc.cpp also fix: > > https://bugs.openjdk.java.net/browse/JDK-8022070 > > On Apr 28, 2014, at 2:36 PM, Mikael Vidstedt wrote: > >> All, >> >> Please review the following set of minor changes which are needed to get the linux/sparc platform to build and run[1]. The changes are relatively straightforward so I'm not explaining them more in detail here, but please ask if there's anything in there which is unclear. >> >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8042059/webrev.00/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8042059 >> >> Cheers, >> Mikael >> >> [1] Note that a few additional minor changes are needed, but they need to be cleaned up a tad before they're ready to be pushed. >> From vladimir.kozlov at oracle.com Wed Apr 30 06:14:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Apr 2014 23:14:10 -0700 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <535ED251.8000501@oracle.com> <04E9C0ED-4F68-4796-8BE9-FF3E116D3F9C@oracle.com> Message-ID: <536094B2.90301@oracle.com> David, Thank you for fixing vm_version files. In c1_LIR.cpp, c1_Runtime1.cpp, ciInstanceKlass.cpp, ciMetadata.cpp, ciObject.cpp not all 0x%" PRIxPTR were replaced by PTR_FORMAT. I see you kept a lot of '0x" PRIxPTR' instead of using INTPTR_FORMAT (or PTR_FORMAT) when printing (p2i) pointers. Why? Files c1_LIR.cpp, c1_Runtime1.cpp, ciInstanceKlass.cpp, ciMetadata.cpp, ciObject.cpp, markOop.cpp. memnode.cpp - for printing intptr_t values we should use INTX_FORMAT. arguments.cpp - not all (unsigned int) were replaced. I see that you enable by default ATTRIBUTE_PRINTF for print() and print_cr(). Does it mean they are checked by clang and gcc? I am for that if it is true otherwise they will degrade. I remember in first review you commented it. So I missed when it was enabled. General question for not these changes. Do we still need PTR_FORMAT since you used p2i() for all pointer values which use INTPTR_FORMAT? Their definition are the same. Why keep both? Thanks, Vladimir On 4/29/14 7:18 PM, David Chase wrote: > All recommended changes made except the one that was not possible: > >> and INTPTR_FORMAT for: >> >> out->print("%3d:0x" UINT64_FORMAT_X, type(), (uint64_t)as_jlong()); > > (INTPTR_FORMAT is not guaranteed to be 64 bits) > > Patch brought up to date with independent partial cleanups in gc code. > > Diffs scanned for spacing glitches, those found and repaired. > > Retested, passed. > > New webrev: http://cr.openjdk.java.net/~drchase/8037816/webrev.03/ > > One question -- src/share/vm/prims/jvmtiEnter.xsl contains both leading > tabs and trailing spaces, and I think the trailing spaces may matter to the > (appearance of the) generated code. Will this pass jcheck? > > David > From sgehwolf at redhat.com Wed Apr 30 07:30:50 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Apr 2014 09:30:50 +0200 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <535FD94B.4070901@oracle.com> References: <1398685322.3241.19.camel@localhost.localdomain> <535F79CB.5090900@oracle.com> <1398769750.3223.17.camel@localhost.localdomain> <1398771241.3223.21.camel@localhost.localdomain> <535FD94B.4070901@oracle.com> Message-ID: <1398843050.3300.1.camel@localhost.localdomain> On Tue, 2014-04-29 at 09:54 -0700, Vladimir Kozlov wrote: > Hi Severin, > > Is it your final webrev?: > > http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v2/ Yes. The change in src/share/vm/runtime/globals.hpp is not needed as David pointed out. Thanks, Severin > On 4/29/14 4:34 AM, Severin Gehwolf wrote: > > On Tue, 2014-04-29 at 13:09 +0200, Severin Gehwolf wrote: > > [...] > >> As to why the if on line 167 is entered I'm still unsure. Apparently one > >> of COMPILER1, COMPILER2, SHARK is defined for a --with-jvm-variants=zero > >> build. It's not apparent to me which it is and why :-/ > > > > Well scratch that. It appears I've not had enough coffee today. Sorry > > for the noise. > > > > Cheers, > > Severin > > From sgehwolf at redhat.com Wed Apr 30 07:35:44 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Apr 2014 09:35:44 +0200 Subject: Review-Request: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <535FFD7E.8020705@oracle.com> References: <1398685322.3241.19.camel@localhost.localdomain> <535E9A5A.8060605@oracle.com> <535F6470.1050307@oracle.com> <1398763837.3223.9.camel@localhost.localdomain> <0e1cdacf-ebab-4f5e-9c97-1abfe638405d@default> <535FF3A4.6010801@oracle.com> <535FFD7E.8020705@oracle.com> Message-ID: <1398843344.3300.3.camel@localhost.localdomain> Hi, On Tue, 2014-04-29 at 12:29 -0700, Vladimir Kozlov wrote: > Hi Albert, > > Based on resent mail from Mark we need to publish webrev on our cr. > server. Severin sent v2 version and I asked if it is final. Albert if it > is final, please, prepare webrev and send official RFR in format we use. Is there anything I can do to make this easier for you next time? Thanks, Severin > On 4/29/14 11:47 AM, Albert wrote: > > Iris, thanks for the clarification. > > > > Severin, I will push your changes if they are reviewed. > > > > Thanks, > > Albert > > > > > > On 04/29/2014 06:59 PM, Iris Clark wrote: > >> Hi, Severin. > >> > >>> I work for Red Hat and I believe it has signed the OCA as a company. > >>> Not sure if this makes me a contributor. > >> You're a Contributor. > >> > >> Red Hat is on the Signatories List [1]. > >> > >> Thanks, > >> iris > >> > >> [1]: http://www.oracle.com/technetwork/community/oca-486395.html > >> > >> -----Original Message----- > >> From: Severin Gehwolf [mailto:sgehwolf at redhat.com] > >> Sent: Tuesday, April 29, 2014 2:31 AM > >> To: hotspot-dev at openjdk.java.net > >> Subject: Re: Review-Request: Fix of JDK-8034775 neglects to account > >> for non-JIT VMs > >> > >> Hi Albert, > >> > >> On Tue, 2014-04-29 at 10:36 +0200, Albert wrote: > >>> Hi, > >>> > >>> sorry, it was my change that introduced the bug. The change looks good > >>> to me as well. > >> Thanks for looking at the patch! > >> > >>> However, I am not a reviewer, so I think a second review would be good. > >> OK. > >> > >>> Or is the change > >>> simple enough that 1 review is fine? I am not sure. > >>> > >>> Are you a contributor? ( http://openjdk.java.net/contribute/ ) If yes, > >>> I will push your changes as soon as I have an OK. > >> I work for Red Hat and I believe it has signed the OCA as a company. > >> Not sure if this makes me a contributor. > >> > >> Cheers, > >> Severin > >> > >>> On 04/28/2014 08:13 PM, Vladimir Kozlov wrote: > >>>> Hi Severin, > >>>> > >>>> Your fix looks reasonable. > >>>> > >>>> Sorry for breaking your build. I assigned the bug to Albert. He will > >>>> sponsor your changes. > >>>> > >>>> Thanks, > >>>> Vladimir > >>>> > >>>> On 4/28/14 4:42 AM, Severin Gehwolf wrote: > >>>>> Hi, > >>>>> > >>>>> Bug: JI-9011998 (I don't seem to be able to create JDK bugs) > >>>>> Webrev: http://jerboaa.fedorapeople.org/bugs/openjdk/JI-9011998/v1/ > >>>>> > >>>>> The fix for JDK-8034775 introduced a start-up check requiring the > >>>>> number of compiler threads to be >= 1, which does not make sense > >>>>> for non-JIT VMs such as the zero JVM variant. This causes zero JVMs > >>>>> to fail initialization with: > >>>>> > >>>>> CICompilerCount of 0 is invalid; must be at least 1 > >>>>> Error: Could not create the Java Virtual Machine. > >>>>> Error: A fatal exception has occurred. Program will exit. > >>>>> > >>>>> This is caused by a wrong start-up check in > >>>>> src/share/vm/runtime/arguments.cpp where a minimal value of 1 is > >>>>> required no matter the JVM variant. > >>>>> > >>>>> The proposed fix uses the defined CI_COMPILER_COUNT pre-processor > >>>>> constant over a static 1 to pass to verify_min_value(). Since > >>>>> CI_COMPILER_COUNT is going to be defined differently for JVM > >>>>> variants it will make the lower water mark check correct for all > >>>>> JVM variants. > >>>>> > >>>>> There was an error in defining CI_COMPILER_COUNT as well. On line > >>>>> 196 in src/share/vm/runtime/globals.hpp CI_COMPILER_COUNT is > >>>>> defined to be 0 (since COMPILER1, COMPILER2 and SHARK are not > >>>>> defined for a Zero build. > >>>>> Then on line 201 in src/share/vm/runtime/globals.hpp the "else" > >>>>> branch of ifdef COMPILER2 is entered and the earlier definition of > >>>>> CI_COMPILER_COUNT (with value 0) overridden to 1. > >>>>> > >>>>> I've amended test/compiler/startup/NumCompilerThreadsCheck.java so > >>>>> as to verify that the lower water mark for Zero JVMs is 0. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Cheers, > >>>>> Severin > >>>>> > >> > >> > > From staffan.larsen at oracle.com Wed Apr 30 07:48:51 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Apr 2014 09:48:51 +0200 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <535ED251.8000501@oracle.com> <04E9C0ED-4F68-4796-8BE9-FF3E116D3F9C@oracle.com> Message-ID: On 30 apr 2014, at 04:18, David Chase wrote: > One question -- src/share/vm/prims/jvmtiEnter.xsl contains both leading > tabs and trailing spaces, and I think the trailing spaces may matter to the > (appearance of the) generated code. Will this pass jcheck? jcheck only looks at files with an extension matching java|c|h|cpp|hpp. /Staffan From albert.noll at oracle.com Wed Apr 30 07:51:55 2014 From: albert.noll at oracle.com (Albert) Date: Wed, 30 Apr 2014 09:51:55 +0200 Subject: [9] RFR(S): 8041992: Fix of JDK-8034775 neglects to account for non-JIT VMs Message-ID: <5360AB9B.3050109@oracle.com> Hi, could I get reviews for the following bug? The proposed fix for this bug is provided by Severin (see cc). Bug: https://bugs.openjdk.java.net/browse/JDK-8041992 Problem: JDK-8034775 restricts the number of compiler threads to be at least 1. This restriction does not make sense for a non-JIT JVM (zero). Solution: Allow 0 compiler threads if no JIT is used. Testing: Failing test case Webrev: http://cr.openjdk.java.net/~anoll/8041992/webrev.00/ Many thanks, Albert From david.holmes at oracle.com Wed Apr 30 09:09:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Apr 2014 19:09:28 +1000 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <5359F2AE.8010808@oracle.com> <2F5B7196-8CB1-4D70-92AE-E2FE76A1378D@oracle.com> <535DFE3B.60903@oracle.com> Message-ID: <5360BDC8.4050302@oracle.com> On 28/04/2014 9:57 PM, David Chase wrote: > > On 2014-04-28, at 3:07 AM, David Holmes wrote: >> On 25/04/2014 10:10 PM, David Chase wrote: >>> >>> On 2014-04-25, at 1:29 AM, Stefan Karlsson wrote: >>> >>>> Hi David, >>>>> Among the changes/observations: >>>>> >>>>> int64_t and jlong are NOT NOT NOT the same type on all platforms. >>>> >>>> Could you clarify this? To me they both look like 64 bit signed integers. What am I missing? >>> >>> On at least one 64-bit platform (I think at least XCode 4.6.3 / gcc 4.2 on Mountain Lion) one >>> of the two is defined to be "long" and the other "long long". Even though both of those are >>> 64 bits, gcc "knows" that there are platforms where long is only 32 bits, and hence this could >>> be a problem when you recompile on different platform. >> >> That doesn't make sense to me. gcc should be looking at the current definitions of those types in the current build, not considering some absolute truth as to what these types might be across different platforms. > > I am just the messenger -- if we intend to enable format warnings, and to mark our own printf-ish methods appropriately, and warnings are errors, and we use gcc, then we have to put up with gcc's silliness. The automated format/arg warnings (i.e., the warnings in this extremely picky category, not literal/empty/length) did catch one bug that Vladimir K concurrently repaired (printing int as %s, not so good) and found another where we printed a default case constant as a %f, plus it has tagged numerous actual integer width mismatches (that might or might not bite us in some future port, it has a lot to do with how parameters are passed and endianness). > > How do you like it otherwise? I'm itching to get reviews and get this thing out of my hair. I appreciate what you are doing but I dislike the details - in particular print_raw and, even worse, cr(). One thing we do need from this is some clear documentation somewhere on what format specific macros to use for which types. David H. -------- > David > From david.holmes at oracle.com Wed Apr 30 09:11:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Apr 2014 19:11:42 +1000 Subject: [9] RFR(S): 8041992: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <5360AB9B.3050109@oracle.com> References: <5360AB9B.3050109@oracle.com> Message-ID: <5360BE4E.4090300@oracle.com> Hi Albert, Looks okay to me. David On 30/04/2014 5:51 PM, Albert wrote: > Hi, > > could I get reviews for the following bug? > The proposed fix for this bug is provided by Severin (see cc). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8041992 > > Problem: > JDK-8034775 restricts the number of compiler threads to be at least 1. > This restriction does not make sense for a non-JIT JVM (zero). > > Solution: > Allow 0 compiler threads if no JIT is used. > > Testing: > Failing test case > > Webrev: > http://cr.openjdk.java.net/~anoll/8041992/webrev.00/ > > Many thanks, > Albert From albert.noll at oracle.com Wed Apr 30 09:14:00 2014 From: albert.noll at oracle.com (Albert) Date: Wed, 30 Apr 2014 11:14:00 +0200 Subject: [9] RFR(S): 8041992: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <5360BE4E.4090300@oracle.com> References: <5360AB9B.3050109@oracle.com> <5360BE4E.4090300@oracle.com> Message-ID: <5360BED8.1060400@oracle.com> Thank you, David. Best, Albert On 04/30/2014 11:11 AM, David Holmes wrote: > Hi Albert, > > Looks okay to me. > > David > > On 30/04/2014 5:51 PM, Albert wrote: >> Hi, >> >> could I get reviews for the following bug? >> The proposed fix for this bug is provided by Severin (see cc). >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8041992 >> >> Problem: >> JDK-8034775 restricts the number of compiler threads to be at least 1. >> This restriction does not make sense for a non-JIT JVM (zero). >> >> Solution: >> Allow 0 compiler threads if no JIT is used. >> >> Testing: >> Failing test case >> >> Webrev: >> http://cr.openjdk.java.net/~anoll/8041992/webrev.00/ >> >> Many thanks, >> Albert From david.holmes at oracle.com Wed Apr 30 09:58:50 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Apr 2014 19:58:50 +1000 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> <5347C745.2040901@oracle.com> <5347CED1.3000908@oracle.com> <535FB05B.6030605@oracle.com> Message-ID: <5360C95A.3050309@oracle.com> On 30/04/2014 3:24 AM, Volker Simonis wrote: > Hi Lois, > > sure, the latest webrev was: > > http://cr.openjdk.java.net/~simonis/webrevs/8039805.v3/ > > As far as I understood, David recalled his concerns in his last mail > ("..Ignore that. I just realized it is not the external linkage to > these methods that is the main issue, but some internal hotspot code > calling the global operator new/delete.." - see > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013523.html) > > @David: are you OK with the change now? Yes. To clarify for Lois my "Ignore that" retracted my comment that everything in the "#ifndef ALLOW_OPERATOR_NEW_USAGE" block could be deleted. I'm okay with getting rid of ALLOW_OPERATOR_NEW_USAGE itself. Thanks, David > Thanks, > Volker > > PS: jdk9 is just fine for now - thanks for helping out! > > > On Tue, Apr 29, 2014 at 3:59 PM, Lois Foltan wrote: >> >> On 4/29/2014 9:43 AM, Volker Simonis wrote: >>> >>> Hi everybody, >>> >>> I'm still looking for a sponsor for this change. >> >> >> Hi Volker, >> >> Can I ask a favor, could you send out your latest webrev. Maybe my >> misunderstanding, but I thought this was left off at David's last comment >> that ALLOW_OPERATOR_NEW should not be removed after all which you had >> removed in your last webrev. >> >> I can sponsor you for JDK 9 but am not a committer for JDK 8 so would not be >> able to backport the change. >> >> Thanks, >> Lois >> >> >>> >>> Thanks, >>> Volker >>> >>> On Fri, Apr 11, 2014 at 1:15 PM, David Holmes >>> wrote: >>>> >>>> On 11/04/2014 8:43 PM, David Holmes wrote: >>>>> >>>>> On 11/04/2014 8:34 PM, Volker Simonis wrote: >>>>>> >>>>>> On Fri, Apr 11, 2014 at 3:58 AM, David Holmes >>>>> > wrote: >>>>>> >>>>>> On 11/04/2014 4:33 AM, Volker Simonis wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> thanks for looking at this issue. >>>>>> >>>>>> I agree with you and I've completely removed >>>>>> ALLOW_OPERATOR_NEW now: >>>>>> >>>>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805.v2/ >>>>>> >>>>>> >>>>>> >>>>>> I actually meant delete the whole block guarded by >>>>>> ALLOW_OPERATOR_NEW - we don't need these error-trapping >>>>>> definitions >>>>>> now we have fixed the export problem. >>>>>> >>>>>> >>>>>> OK, but arguing this way, we could remove remove all asserts from the >>>>>> code, once we fixed an error revealed by them. >>>>> >>>>> >>>>> Obviously you have to draw a line somewhere. But I don't think these >>>>> particular methods are worth the problem they are now causing. >>>> >>>> >>>> Ignore that. I just realized it is not the external linkage to these >>>> methods >>>> that is the main issue, but some internal hotspot code calling the global >>>> operator new/delete. >>>> >>>> David >>>> >>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> I think the error-trapping new/delete operators are still valuable in >>>>>> protecting people from accidentally calling them (and they don't really >>>>>> hurt anybody in terms of performance or space). >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> FYI I'm not in the runtime group. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> I've also changed the "guarantee" into "fatal" as proposed by >>>>>> Vladimir. >>>>>> >>>>>> I've thought a little while about the problem that some other >>>>>> code may >>>>>> unintentionally use these operators but I couldn?t really find >>>>>> a >>>>>> scenario where this could happen. Because as you correctly >>>>>> pointed >>>>>> out, these operators aren't exported from libjvm.so - after >>>>>> all, >>>>>> that's the whole reason for compiling with visibility=hidden >>>>>> and >>>>>> using >>>>>> of export maps. So if another program/library will load >>>>>> libjvm.so, the >>>>>> operators won't be visible. On the other hand, if the >>>>>> libjvm.so >>>>>> loads >>>>>> another shared libraries which use these operators they either >>>>>> have >>>>>> their own, private versions of them or they are dynamically >>>>>> linked >>>>>> against another library (most probably the standard library) >>>>>> which >>>>>> provides versions of the operators. >>>>>> >>>>>> So if I'm not totally wrong, we could in principle also enable >>>>>> these >>>>>> operators in the product build. However, I'm not proposing >>>>>> that for >>>>>> this change. Let's first fix the signatures and get rid of >>>>>> ALLOW_OPERATOR_NEW with this change. If everything works fine, >>>>>> we can >>>>>> think about enabling these global operators in product builds >>>>>> as >>>>>> well. >>>>>> >>>>>> By the way - are you from the runtime group? >>>>>> I was asked to get a review from a runtime-group member - >>>>>> anybody out >>>>>> there willing to volunteer? >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Thu, Apr 10, 2014 at 5:19 AM, David Holmes >>>>>> > >>>>>> wrote: >>>>>> >>>>>> I think we should just delete the whole ALLOW_OPERATOR_NEW >>>>>> block. We fixed >>>>>> the problem of it being called outside the VM under >>>>>> 8014326. >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> On 10/04/2014 12:48 PM, David Holmes wrote: >>>>>> >>>>>> >>>>>> Hi Volker, >>>>>> >>>>>> Need more time to consider this in full but from the >>>>>> existing code: >>>>>> >>>>>> 689 // On certain platforms, such as Mac OS X >>>>>> (Darwin), in debug >>>>>> version, new is being called >>>>>> 690 // from jdk source and causing data >>>>>> corruption. >>>>>> Such as >>>>>> 691 // >>>>>> >>>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >>>>>> 692 // define ALLOW_OPERATOR_NEW_USAGE for >>>>>> platform >>>>>> on which global >>>>>> operator new allowed. >>>>>> >>>>>> we actually fixed that by using the mapfiles to ensure >>>>>> the hotspot >>>>>> operator new was not visible externally. The existence >>>>>> of >>>>>> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the >>>>>> time :( >>>>>> >>>>>> https://bugs.openjdk.java.net/__browse/JDK-8014326 >>>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On 10/04/2014 2:34 AM, Volker Simonis wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> could you please review and sponsor the following >>>>>> small change: >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805/ >>>>>> >>>>>> >>>>>> https://bugs.openjdk.java.net/__browse/JDK-8039805 >>>>>> >>>>>> >>>>>> which fixes the signature of the global new/delete >>>>>> operators in >>>>>> allocation.cpp >>>>>> >>>>>> For non-product builds allocation.cpp defines >>>>>> global >>>>>> new/delete >>>>>> operators which shut down the VM if they get >>>>>> called >>>>>> at runtime. The >>>>>> rational behind this is that the these global >>>>>> operators should never >>>>>> be used in HotSpot. >>>>>> >>>>>> Unfortunately, the signature of some of these >>>>>> operators doesn't >>>>>> conform to the C++ standard which confuses some >>>>>> C++ >>>>>> compilers. For a >>>>>> more detailed explanation of the C++ background of >>>>>> this issue see the >>>>>> new comments in allcoation.cpp and the end of this >>>>>> mail. >>>>>> >>>>>> This change also replaces the asserts in the >>>>>> operators with guarantees >>>>>> because the code may also be active in not-product >>>>>> (aka. 'optimized') >>>>>> builds. >>>>>> >>>>>> Finally, the webrev fixes two places in the >>>>>> AIX-port >>>>>> which used the >>>>>> global new operator. After the change we can now >>>>>> remove the definition >>>>>> of ALLOW_OPERATOR_NEW_USAGE from >>>>>> aix/makefiles/vm.make. >>>>>> >>>>>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >>>>>> bsd/makefiles/vm.make and the corresponding >>>>>> comments >>>>>> in allcoation.cpp >>>>>> which state that on Mac OS X the global new/delete >>>>>> operators from the >>>>>> HotSpot cause problems together with usages of >>>>>> these >>>>>> operators from >>>>>> the class library such as the ones from >>>>>> >>>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair. >>>>>> I couldn?t >>>>>> observe any such problems but if anybody has some >>>>>> concrete concerns >>>>>> I'm ready to remove this part from the webrev. >>>>>> >>>>>> I've build and tested these changes on >>>>>> Linux/x86_64, >>>>>> Linux/ppc64, >>>>>> Solaris/Sparc, Windows/x86_64, MacOS X and >>>>>> AIX/ppc64. I've especially >>>>>> run the regression tests from sun/security/ec >>>>>> which >>>>>> exercise the >>>>>> method >>>>>> >>>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >>>>>> which >>>>>> was mentioned to cause problems in conjunction >>>>>> with >>>>>> the globally >>>>>> defined new/delete operators from the HotSpot but >>>>>> couldn't see any >>>>>> issues, neither in the slowdebug nor in the >>>>>> optimized build. >>>>>> >>>>>> Following some C++ background regarding the global >>>>>> new/delete operators: >>>>>> >>>>>> In C++98/03 the throwing new operators are defined >>>>>> with the following >>>>>> signature: >>>>>> >>>>>> void* operator new(std::size_tsize) >>>>>> throw(std::bad_alloc); >>>>>> void* operator new[](std::size_tsize) >>>>>> throw(std::bad_alloc); >>>>>> >>>>>> while all the other (non-throwing) new and delete >>>>>> operators are >>>>>> defined with an empty throw clause (i.e. "operator >>>>>> delete(void* p) >>>>>> throw()") which means that they do not throw any >>>>>> exceptions (see >>>>>> section 18.4 of the C++ standard >>>>>> >>>>>> http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2005/__n1905.pdf >>>>>> >>>>>> ). >>>>>> >>>>>> In the new C++11/14 standard >>>>>> >>>>>> (http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2013/__n3797.pdf >>>>>> >>>>>> ), >>>>>> the signature of the throwing new operators was >>>>>> changed by completely >>>>>> omitting the throw clause (which effectively means >>>>>> they could throw >>>>>> any exception) while all the other new/delete >>>>>> operators where changed >>>>>> to have a 'nothrow' clause instead of an empty >>>>>> throw >>>>>> clause. >>>>>> >>>>>> Unfortunately, the support for exception >>>>>> specifications among C++ >>>>>> compilers is still very fragile. While some more >>>>>> strict compilers like >>>>>> AIX xlC or HP aCC reject to override the default >>>>>> throwing new operator >>>>>> with a user operator with an empty throw() clause, >>>>>> the MS Visual C++ >>>>>> compiler warns for every non-empty throw clause >>>>>> like >>>>>> throw(std::bad_alloc) that it will ignore the >>>>>> exception specification >>>>>> (see >>>>>> >>>>>> http://msdn.microsoft.com/en-__us/library/sa28fef8.aspx >>>>>> >>>>>> ). >>>>>> >>>>>> I've therefore changed the operator definitions >>>>>> such >>>>>> that they >>>>>> correctly work with all currently supported >>>>>> compilers and in way which >>>>>> should be upwards compatible with C++11/14. >>>>>> >>>>>> Please notice that I'm aware of the discussion >>>>>> around "8021954: VM >>>>>> SIGSEGV during classloading on MacOS; hs_err_pid >>>>>> file produced" >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> (http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2013-August/thread.html#8924 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> , >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://hg.openjdk.java.net/__hsx/hotspot-comp/hotspot/rev/__9758d9f36299 >>>>>> >>>>>> ) >>>>>> which introduced empty throw() clauses on all user >>>>>> defined new >>>>>> operators. But I think the rational used for that >>>>>> change doesn't apply >>>>>> here, because these global, user user defined new >>>>>> operators changed in >>>>>> this webrev aren't meant to be really used. There >>>>>> only task is to >>>>>> override the default, global operators (and >>>>>> therefore they need to >>>>>> have the right signature) and to shut the VM down >>>>>> if >>>>>> they get called. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> >> From erik.helin at oracle.com Wed Apr 30 11:18:09 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 30 Apr 2014 13:18:09 +0200 Subject: RFR: 8034852: Shrinking of Metaspace high-water-mark causes incorrect OutOfMemoryErrors or back-to-back GCs Message-ID: <5360DBF1.3050807@oracle.com> Hi all, this patch solves a rather tricky problem with the sizing of Metaspace. The issue happens when the GC threshold for Metaspace (called "capacity_until_GC" in the code) becomes less than the committed memory for Metaspace. Any calls to Metaspace::allocate that requires committing more memory will then fail in MetaspaceGC::allowed_expansion, because capacity_until_GC() < MetaspaceAux::committed_memory(). The effect will be a full GC and after the GC we try to expand and allocate. After the expansion and before the allocation, one of two things can happen: 1. capacity_until_GC is larger than the committed memory after the expansion. The allocation will now succeed, but the next allocation requiring a new chunk will *again* trigger a full GC. This pattern will repeat itself for each new allocation request requiring a new chunk. 2. capacity_until_GC is still less than the committed memory even after the expansion. We throw a Java OOME (incorrectly). How can the GC threshold for Metaspace be less than the committed memory? The problem is that MetaspaceGC::compute_new_size uses the field _allocated_capacity for describing the amount of memory in Metaspace that is "in use". _allocated_capacity does not consider the memory in the chunk free lists to be "in use", since memory in the chunk free lists are supposed to be available for new allocations. The problem is that the chunk free lists can become fragmented, and then the memory is not available for all kinds of allocations. This patch change MetaspaceGC::compute_new_size to use MetaspaceAux::committed_memory for describing how much memory that is "in use". The effect will be that memory in the chunk free lists will no longer be considered "in use" (but will of course be used for future allocations where possible). This will prevent capacity_until_GC from shrinking below the committed memory "by definiton", since capacity_until_GC can't be lower than the memory that is "in use". Based on the results from the perf testing (see below), this change has no performance impact. Webrev: http://cr.openjdk.java.net/~ehelin/8034852/webrev.00/ Testing: - JPRT - Ad-hoc testing: - Kitchensink - Dacapo - Medrec - runThese - Parallel Class Loading testlist - Metaspace testlist - GC nightly testlist - Perf testing: - SPECjbb2005 - SPECjbb2013 - Derby - Derby regression tests Thanks, Erik From erik.helin at oracle.com Wed Apr 30 11:26:00 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 30 Apr 2014 13:26:00 +0200 Subject: RFR: 8034094: SA agent can't compile when jni_x86.h is used In-Reply-To: <52F8EE89.6040808@oracle.com> References: <52F8EB7A.4080305@oracle.com> <52F8EE89.6040808@oracle.com> Message-ID: <5360DDC8.2000003@oracle.com> Anyone interested in this patch? I ran into this issue again yesterday... Thanks, Erik On 2014-02-10 16:21, Erik Helin wrote: > Sigh, I forgot the subject... > > "RFR: 8034094: SA agent can't compile when jni_x86.h is used" > > Thanks, > Erik > > On 2014-02-10 16:08, Erik Helin wrote: >> Hi all, >> >> this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and >> jni_md.h. >> >> The bug manifests itself when using an IMPORT_JDK which >> include/linux/jni_md.h has a timestamp that is older than >> hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will >> copy hotspot/src/cpu/x86/jni_x86.h to >> hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h. >> >> The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from >> jdk/include/jni.h, since it is used for all operating systems: >> >> #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) >> ... // common stuff >> #else >> ... // windows stuff >> #endif >> >> We compile the SA agent, see make/linux/makefiles/saproc.make, without >> defining LINUX (LINUX is hotspot's own define, gcc uses __linux__). >> >> In my opinion, there are two ways to solve this: >> 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding >> defines for Solaris and BSD). >> 2. Rewrite the #if check in jni_x86.h to use platform specific "native" >> defines. >> >> I've created a patch for each alternative: >> 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/ >> 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/ >> >> For the second patch, note that I've inverted the #if check so that it >> checks for _WIN32 is defined and treat all others operating systems as >> "#else". >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8034094 >> >> Testing: >> - Compiled both version locally and made sure it worked >> - JPRT >> >> Thanks, >> Erik From erik.joelsson at oracle.com Wed Apr 30 11:39:01 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Apr 2014 13:39:01 +0200 Subject: RFR: 8034094: SA agent can't compile when jni_x86.h is used In-Reply-To: <5360DDC8.2000003@oracle.com> References: <52F8EB7A.4080305@oracle.com> <52F8EE89.6040808@oracle.com> <5360DDC8.2000003@oracle.com> Message-ID: <5360E0D5.90203@oracle.com> I think option 2 seems best. /Erik On 2014-04-30 13:26, Erik Helin wrote: > Anyone interested in this patch? I ran into this issue again yesterday... > > Thanks, > Erik > > On 2014-02-10 16:21, Erik Helin wrote: >> Sigh, I forgot the subject... >> >> "RFR: 8034094: SA agent can't compile when jni_x86.h is used" >> >> Thanks, >> Erik >> >> On 2014-02-10 16:08, Erik Helin wrote: >>> Hi all, >>> >>> this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and >>> jni_md.h. >>> >>> The bug manifests itself when using an IMPORT_JDK which >>> include/linux/jni_md.h has a timestamp that is older than >>> hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will >>> copy hotspot/src/cpu/x86/jni_x86.h to >>> hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h. >>> >>> The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from >>> jdk/include/jni.h, since it is used for all operating systems: >>> >>> #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) >>> ... // common stuff >>> #else >>> ... // windows stuff >>> #endif >>> >>> We compile the SA agent, see make/linux/makefiles/saproc.make, without >>> defining LINUX (LINUX is hotspot's own define, gcc uses __linux__). >>> >>> In my opinion, there are two ways to solve this: >>> 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding >>> defines for Solaris and BSD). >>> 2. Rewrite the #if check in jni_x86.h to use platform specific "native" >>> defines. >>> >>> I've created a patch for each alternative: >>> 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/ >>> 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/ >>> >>> For the second patch, note that I've inverted the #if check so that it >>> checks for _WIN32 is defined and treat all others operating systems as >>> "#else". >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8034094 >>> >>> Testing: >>> - Compiled both version locally and made sure it worked >>> - JPRT >>> >>> Thanks, >>> Erik From david.r.chase at oracle.com Wed Apr 30 11:47:24 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 30 Apr 2014 07:47:24 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <536094B2.90301@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <535ED251.8000501@oracle.com> <04E9C0ED-4F68-4796-8BE9-FF3E116D3F9C@oracle.com> <536094B2.90301@oracle.com> Message-ID: On 2014-04-30, at 2:14 AM, Vladimir Kozlov wrote: > David, > > Thank you for fixing vm_version files. > > In c1_LIR.cpp, c1_Runtime1.cpp, ciInstanceKlass.cpp, ciMetadata.cpp, ciObject.cpp not all 0x%" PRIxPTR were replaced by PTR_FORMAT. > > I see you kept a lot of '0x" PRIxPTR' instead of using INTPTR_FORMAT (or PTR_FORMAT) when printing (p2i) pointers. Why? > Files c1_LIR.cpp, c1_Runtime1.cpp, ciInstanceKlass.cpp, ciMetadata.cpp, ciObject.cpp, markOop.cpp. I'm reluctant to do that, since it changes the output, from 0xbeef to 0x0000beef or 0x000000000000beef. Is that really acceptable? > memnode.cpp - for printing intptr_t values we should use INTX_FORMAT. got that -- this is as opposed to PRIdPTR, right? > arguments.cpp - not all (unsigned int) were replaced. got that -- two more. > I see that you enable by default ATTRIBUTE_PRINTF for print() and print_cr(). Does it mean they are checked by clang and gcc? I am for that if it is true otherwise they will degrade. I remember in first review you commented it. So I missed when it was enabled. I enabled it because of taking to Coleen; it seemed like an extremely good idea. > General question for not these changes. Do we still need PTR_FORMAT since you used p2i() for all pointer values which use INTPTR_FORMAT? Their definition are the same. Why keep both? I have no idea. Whoever provided the macros did not give much guidance. PTR_FORMAT is shorter. David From david.r.chase at oracle.com Wed Apr 30 11:59:55 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 30 Apr 2014 07:59:55 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <5360BDC8.4050302@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <5359F2AE.8010808@oracle.com> <2F5B7196-8CB1-4D70-92AE-E2FE76A1378D@oracle.com> <535DFE3B.60903@oracle.com> <5360BDC8.4050302@oracle.com> Message-ID: <22AFD948-6177-4694-B142-8C34F9F7A833@oracle.com> On 2014-04-30, at 5:09 AM, David Holmes wrote: >> How do you like it otherwise? I'm itching to get reviews and get this thing out of my hair. > > I appreciate what you are doing but I dislike the details - in particular print_raw and, even worse, cr(). > > One thing we do need from this is some clear documentation somewhere on what format specific macros to use for which types. You do understand that those are both existing public methods, and I did not add or innovate, right? It's also completely nonintuitive to me that you would dislike cr more than print_raw. Rather than document, we could make them not be public, if we really meant for them not to be called. I prefer Vladimir's proposal to rename print_raw into puts. One thing that is a little puzzling to me is why we have both INTX and INT64. I see no purpose whatsoever for INTX; it appears to be a 64-bit integer type, but we have a well-defined 64-bit integer type (INT64) and a not-well-defined 64-bit integer type (JLONG) that we own because it is Ours. We also have a pointer-sized integer type (INTPTR) and if this is actually a distinction, an "I intend to print this integer as a pointer type" (PTR). David From zhengyu.gu at oracle.com Wed Apr 30 12:47:38 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 30 Apr 2014 08:47:38 -0400 Subject: RFR(S): 6885993: Named Thread: introduce print() and print_on(outputStream* st) methods Message-ID: <5360F0EA.7010104@oracle.com> This is more of code cleanup. Instead of duplicating similar code all over subclasses of NamedThread, NamedThread should implements print_on(outputStream* str) and its subclasses should only set "name" to use default the implementation. Webrev: http://cr.openjdk.java.net/~zgu/6885993/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-6885993 Tests: - JPRT - Ran a Java program on Linux x64, do "CTRL-\" to dump Java stacks, make sure the output remains unchange. Thanks, -Zhengyu From sgehwolf at redhat.com Wed Apr 30 13:33:05 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Apr 2014 15:33:05 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <5360C95A.3050309@oracle.com> References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> <5347C745.2040901@oracle.com> <5347CED1.3000908@oracle.com> <535FB05B.6030605@oracle.com> <5360C95A.3050309@oracle.com> Message-ID: <1398864785.3300.35.camel@localhost.localdomain> Hi Volker, On Wed, 2014-04-30 at 19:58 +1000, David Holmes wrote: > On 30/04/2014 3:24 AM, Volker Simonis wrote: > > Hi Lois, > > > > sure, the latest webrev was: > > > > http://cr.openjdk.java.net/~simonis/webrevs/8039805.v3/ > > > > As far as I understood, David recalled his concerns in his last mail > > ("..Ignore that. I just realized it is not the external linkage to > > these methods that is the main issue, but some internal hotspot code > > calling the global operator new/delete.." - see > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013523.html) > > > > @David: are you OK with the change now? > > Yes. To clarify for Lois my "Ignore that" retracted my comment that > everything in the "#ifndef ALLOW_OPERATOR_NEW_USAGE" block could be > deleted. I'm okay with getting rid of ALLOW_OPERATOR_NEW_USAGE itself. I believe removing the #ifndef ALLOW_OPERATOR_NEW_USAGE will break the shark JVM variant. Currently shark will need some more work to be useful, but a slowdebug build of shark doesn't even get past "java -version" due to those assertions. Defining it for a shark build + one other small fix will make "java -version" work. Take away: Shark code uses llvm and that in turn calls those global new/delete operators in spades. How do you suggest to work around this with this ifndef removed. Thoughts? Thanks, Severin > Thanks, > David > > > > Thanks, > > Volker > > > > PS: jdk9 is just fine for now - thanks for helping out! > > > > > > On Tue, Apr 29, 2014 at 3:59 PM, Lois Foltan wrote: > >> > >> On 4/29/2014 9:43 AM, Volker Simonis wrote: > >>> > >>> Hi everybody, > >>> > >>> I'm still looking for a sponsor for this change. > >> > >> > >> Hi Volker, > >> > >> Can I ask a favor, could you send out your latest webrev. Maybe my > >> misunderstanding, but I thought this was left off at David's last comment > >> that ALLOW_OPERATOR_NEW should not be removed after all which you had > >> removed in your last webrev. > >> > >> I can sponsor you for JDK 9 but am not a committer for JDK 8 so would not be > >> able to backport the change. > >> > >> Thanks, > >> Lois > >> > >> > >>> > >>> Thanks, > >>> Volker > >>> > >>> On Fri, Apr 11, 2014 at 1:15 PM, David Holmes > >>> wrote: > >>>> > >>>> On 11/04/2014 8:43 PM, David Holmes wrote: > >>>>> > >>>>> On 11/04/2014 8:34 PM, Volker Simonis wrote: > >>>>>> > >>>>>> On Fri, Apr 11, 2014 at 3:58 AM, David Holmes >>>>>> > wrote: > >>>>>> > >>>>>> On 11/04/2014 4:33 AM, Volker Simonis wrote: > >>>>>> > >>>>>> Hi David, > >>>>>> > >>>>>> thanks for looking at this issue. > >>>>>> > >>>>>> I agree with you and I've completely removed > >>>>>> ALLOW_OPERATOR_NEW now: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805.v2/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> I actually meant delete the whole block guarded by > >>>>>> ALLOW_OPERATOR_NEW - we don't need these error-trapping > >>>>>> definitions > >>>>>> now we have fixed the export problem. > >>>>>> > >>>>>> > >>>>>> OK, but arguing this way, we could remove remove all asserts from the > >>>>>> code, once we fixed an error revealed by them. > >>>>> > >>>>> > >>>>> Obviously you have to draw a line somewhere. But I don't think these > >>>>> particular methods are worth the problem they are now causing. > >>>> > >>>> > >>>> Ignore that. I just realized it is not the external linkage to these > >>>> methods > >>>> that is the main issue, but some internal hotspot code calling the global > >>>> operator new/delete. > >>>> > >>>> David > >>>> > >>>> > >>>>> Cheers, > >>>>> David > >>>>> > >>>>>> I think the error-trapping new/delete operators are still valuable in > >>>>>> protecting people from accidentally calling them (and they don't really > >>>>>> hurt anybody in terms of performance or space). > >>>>>> > >>>>>> Regards, > >>>>>> Volker > >>>>>> > >>>>>> FYI I'm not in the runtime group. > >>>>>> > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>> > >>>>>> I've also changed the "guarantee" into "fatal" as proposed by > >>>>>> Vladimir. > >>>>>> > >>>>>> I've thought a little while about the problem that some other > >>>>>> code may > >>>>>> unintentionally use these operators but I couldn?t really find > >>>>>> a > >>>>>> scenario where this could happen. Because as you correctly > >>>>>> pointed > >>>>>> out, these operators aren't exported from libjvm.so - after > >>>>>> all, > >>>>>> that's the whole reason for compiling with visibility=hidden > >>>>>> and > >>>>>> using > >>>>>> of export maps. So if another program/library will load > >>>>>> libjvm.so, the > >>>>>> operators won't be visible. On the other hand, if the > >>>>>> libjvm.so > >>>>>> loads > >>>>>> another shared libraries which use these operators they either > >>>>>> have > >>>>>> their own, private versions of them or they are dynamically > >>>>>> linked > >>>>>> against another library (most probably the standard library) > >>>>>> which > >>>>>> provides versions of the operators. > >>>>>> > >>>>>> So if I'm not totally wrong, we could in principle also enable > >>>>>> these > >>>>>> operators in the product build. However, I'm not proposing > >>>>>> that for > >>>>>> this change. Let's first fix the signatures and get rid of > >>>>>> ALLOW_OPERATOR_NEW with this change. If everything works fine, > >>>>>> we can > >>>>>> think about enabling these global operators in product builds > >>>>>> as > >>>>>> well. > >>>>>> > >>>>>> By the way - are you from the runtime group? > >>>>>> I was asked to get a review from a runtime-group member - > >>>>>> anybody out > >>>>>> there willing to volunteer? > >>>>>> > >>>>>> Thank you and best regards, > >>>>>> Volker > >>>>>> > >>>>>> > >>>>>> On Thu, Apr 10, 2014 at 5:19 AM, David Holmes > >>>>>> > > >>>>>> wrote: > >>>>>> > >>>>>> I think we should just delete the whole ALLOW_OPERATOR_NEW > >>>>>> block. We fixed > >>>>>> the problem of it being called outside the VM under > >>>>>> 8014326. > >>>>>> > >>>>>> David > >>>>>> > >>>>>> > >>>>>> On 10/04/2014 12:48 PM, David Holmes wrote: > >>>>>> > >>>>>> > >>>>>> Hi Volker, > >>>>>> > >>>>>> Need more time to consider this in full but from the > >>>>>> existing code: > >>>>>> > >>>>>> 689 // On certain platforms, such as Mac OS X > >>>>>> (Darwin), in debug > >>>>>> version, new is being called > >>>>>> 690 // from jdk source and causing data > >>>>>> corruption. > >>>>>> Such as > >>>>>> 691 // > >>>>>> > >>>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair > >>>>>> 692 // define ALLOW_OPERATOR_NEW_USAGE for > >>>>>> platform > >>>>>> on which global > >>>>>> operator new allowed. > >>>>>> > >>>>>> we actually fixed that by using the mapfiles to ensure > >>>>>> the hotspot > >>>>>> operator new was not visible externally. The existence > >>>>>> of > >>>>>> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the > >>>>>> time :( > >>>>>> > >>>>>> https://bugs.openjdk.java.net/__browse/JDK-8014326 > >>>>>> > >>>>>> > >>>>>> David > >>>>>> > >>>>>> On 10/04/2014 2:34 AM, Volker Simonis wrote: > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> could you please review and sponsor the following > >>>>>> small change: > >>>>>> > >>>>>> > >>>>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805/ > >>>>>> > >>>>>> > >>>>>> https://bugs.openjdk.java.net/__browse/JDK-8039805 > >>>>>> > >>>>>> > >>>>>> which fixes the signature of the global new/delete > >>>>>> operators in > >>>>>> allocation.cpp > >>>>>> > >>>>>> For non-product builds allocation.cpp defines > >>>>>> global > >>>>>> new/delete > >>>>>> operators which shut down the VM if they get > >>>>>> called > >>>>>> at runtime. The > >>>>>> rational behind this is that the these global > >>>>>> operators should never > >>>>>> be used in HotSpot. > >>>>>> > >>>>>> Unfortunately, the signature of some of these > >>>>>> operators doesn't > >>>>>> conform to the C++ standard which confuses some > >>>>>> C++ > >>>>>> compilers. For a > >>>>>> more detailed explanation of the C++ background of > >>>>>> this issue see the > >>>>>> new comments in allcoation.cpp and the end of this > >>>>>> mail. > >>>>>> > >>>>>> This change also replaces the asserts in the > >>>>>> operators with guarantees > >>>>>> because the code may also be active in not-product > >>>>>> (aka. 'optimized') > >>>>>> builds. > >>>>>> > >>>>>> Finally, the webrev fixes two places in the > >>>>>> AIX-port > >>>>>> which used the > >>>>>> global new operator. After the change we can now > >>>>>> remove the definition > >>>>>> of ALLOW_OPERATOR_NEW_USAGE from > >>>>>> aix/makefiles/vm.make. > >>>>>> > >>>>>> I have also removed ALLOW_OPERATOR_NEW_USAGE from > >>>>>> bsd/makefiles/vm.make and the corresponding > >>>>>> comments > >>>>>> in allcoation.cpp > >>>>>> which state that on Mac OS X the global new/delete > >>>>>> operators from the > >>>>>> HotSpot cause problems together with usages of > >>>>>> these > >>>>>> operators from > >>>>>> the class library such as the ones from > >>>>>> > >>>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair. > >>>>>> I couldn?t > >>>>>> observe any such problems but if anybody has some > >>>>>> concrete concerns > >>>>>> I'm ready to remove this part from the webrev. > >>>>>> > >>>>>> I've build and tested these changes on > >>>>>> Linux/x86_64, > >>>>>> Linux/ppc64, > >>>>>> Solaris/Sparc, Windows/x86_64, MacOS X and > >>>>>> AIX/ppc64. I've especially > >>>>>> run the regression tests from sun/security/ec > >>>>>> which > >>>>>> exercise the > >>>>>> method > >>>>>> > >>>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair > >>>>>> which > >>>>>> was mentioned to cause problems in conjunction > >>>>>> with > >>>>>> the globally > >>>>>> defined new/delete operators from the HotSpot but > >>>>>> couldn't see any > >>>>>> issues, neither in the slowdebug nor in the > >>>>>> optimized build. > >>>>>> > >>>>>> Following some C++ background regarding the global > >>>>>> new/delete operators: > >>>>>> > >>>>>> In C++98/03 the throwing new operators are defined > >>>>>> with the following > >>>>>> signature: > >>>>>> > >>>>>> void* operator new(std::size_tsize) > >>>>>> throw(std::bad_alloc); > >>>>>> void* operator new[](std::size_tsize) > >>>>>> throw(std::bad_alloc); > >>>>>> > >>>>>> while all the other (non-throwing) new and delete > >>>>>> operators are > >>>>>> defined with an empty throw clause (i.e. "operator > >>>>>> delete(void* p) > >>>>>> throw()") which means that they do not throw any > >>>>>> exceptions (see > >>>>>> section 18.4 of the C++ standard > >>>>>> > >>>>>> http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2005/__n1905.pdf > >>>>>> > >>>>>> ). > >>>>>> > >>>>>> In the new C++11/14 standard > >>>>>> > >>>>>> (http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2013/__n3797.pdf > >>>>>> > >>>>>> ), > >>>>>> the signature of the throwing new operators was > >>>>>> changed by completely > >>>>>> omitting the throw clause (which effectively means > >>>>>> they could throw > >>>>>> any exception) while all the other new/delete > >>>>>> operators where changed > >>>>>> to have a 'nothrow' clause instead of an empty > >>>>>> throw > >>>>>> clause. > >>>>>> > >>>>>> Unfortunately, the support for exception > >>>>>> specifications among C++ > >>>>>> compilers is still very fragile. While some more > >>>>>> strict compilers like > >>>>>> AIX xlC or HP aCC reject to override the default > >>>>>> throwing new operator > >>>>>> with a user operator with an empty throw() clause, > >>>>>> the MS Visual C++ > >>>>>> compiler warns for every non-empty throw clause > >>>>>> like > >>>>>> throw(std::bad_alloc) that it will ignore the > >>>>>> exception specification > >>>>>> (see > >>>>>> > >>>>>> http://msdn.microsoft.com/en-__us/library/sa28fef8.aspx > >>>>>> > >>>>>> ). > >>>>>> > >>>>>> I've therefore changed the operator definitions > >>>>>> such > >>>>>> that they > >>>>>> correctly work with all currently supported > >>>>>> compilers and in way which > >>>>>> should be upwards compatible with C++11/14. > >>>>>> > >>>>>> Please notice that I'm aware of the discussion > >>>>>> around "8021954: VM > >>>>>> SIGSEGV during classloading on MacOS; hs_err_pid > >>>>>> file produced" > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> (http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2013-August/thread.html#8924 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> , > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> http://hg.openjdk.java.net/__hsx/hotspot-comp/hotspot/rev/__9758d9f36299 > >>>>>> > >>>>>> ) > >>>>>> which introduced empty throw() clauses on all user > >>>>>> defined new > >>>>>> operators. But I think the rational used for that > >>>>>> change doesn't apply > >>>>>> here, because these global, user user defined new > >>>>>> operators changed in > >>>>>> this webrev aren't meant to be really used. There > >>>>>> only task is to > >>>>>> override the default, global operators (and > >>>>>> therefore they need to > >>>>>> have the right signature) and to shut the VM down > >>>>>> if > >>>>>> they get called. > >>>>>> > >>>>>> Thank you and best regards, > >>>>>> Volker > >>>>>> > >>>>>> > >>>>>> > >> From volker.simonis at gmail.com Wed Apr 30 16:44:11 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 30 Apr 2014 18:44:11 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <1398864785.3300.35.camel@localhost.localdomain> References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> <5347C745.2040901@oracle.com> <5347CED1.3000908@oracle.com> <535FB05B.6030605@oracle.com> <5360C95A.3050309@oracle.com> <1398864785.3300.35.camel@localhost.localdomain> Message-ID: On Wed, Apr 30, 2014 at 3:33 PM, Severin Gehwolf wrote: > Hi Volker, > > On Wed, 2014-04-30 at 19:58 +1000, David Holmes wrote: >> On 30/04/2014 3:24 AM, Volker Simonis wrote: >> > Hi Lois, >> > >> > sure, the latest webrev was: >> > >> > http://cr.openjdk.java.net/~simonis/webrevs/8039805.v3/ >> > >> > As far as I understood, David recalled his concerns in his last mail >> > ("..Ignore that. I just realized it is not the external linkage to >> > these methods that is the main issue, but some internal hotspot code >> > calling the global operator new/delete.." - see >> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013523.html) >> > >> > @David: are you OK with the change now? >> >> Yes. To clarify for Lois my "Ignore that" retracted my comment that >> everything in the "#ifndef ALLOW_OPERATOR_NEW_USAGE" block could be >> deleted. I'm okay with getting rid of ALLOW_OPERATOR_NEW_USAGE itself. > > I believe removing the #ifndef ALLOW_OPERATOR_NEW_USAGE will break the > shark JVM variant. Currently shark will need some more work to be > useful, but a slowdebug build of shark doesn't even get past "java > -version" due to those assertions. Defining it for a shark build + one Hi Severin, could you please post the stack trace of the assertion to see where the operators are called from. > other small fix will make "java -version" work. > > Take away: Shark code uses llvm and that in turn calls those global > new/delete operators in spades. How do you suggest to work around this > with this ifndef removed. Thoughts? > I must confess that I don't know exactly how the Shark build works, but if you load llvm as a shared library the llvm code shouldn't even see the global HotSpot new/delete operators because we don't export them and we compile with -fvisibility=hidden. Looking at the created libjvm.so, this is confirmed: 00000000003d4442 t operator new[](unsigned long) 00000000003d44b4 t operator new[](unsigned long, std::nothrow_t&) 00000000003d440b t operator new(unsigned long) 000000000038a986 t operator new(unsigned long, void*) 00000000003d4479 t operator new(unsigned long, std::nothrow_t const&) My only explanation for the problems you see would be if you compile the llvm code right into the libjvm.so. If that's the case you should either consider to build the llvm into it's own library or you should flag the global operators in allocation.cpp with #ifndef SHARK". By the way, I also couldn't find a place n the current makefiles where ALLOW_OPERATOR_NEW_USAGE is defined for a SHARK build. Where do you currently set that define? Regards, Volker > Thanks, > Severin > >> Thanks, >> David >> >> >> > Thanks, >> > Volker >> > >> > PS: jdk9 is just fine for now - thanks for helping out! >> > >> > >> > On Tue, Apr 29, 2014 at 3:59 PM, Lois Foltan wrote: >> >> >> >> On 4/29/2014 9:43 AM, Volker Simonis wrote: >> >>> >> >>> Hi everybody, >> >>> >> >>> I'm still looking for a sponsor for this change. >> >> >> >> >> >> Hi Volker, >> >> >> >> Can I ask a favor, could you send out your latest webrev. Maybe my >> >> misunderstanding, but I thought this was left off at David's last comment >> >> that ALLOW_OPERATOR_NEW should not be removed after all which you had >> >> removed in your last webrev. >> >> >> >> I can sponsor you for JDK 9 but am not a committer for JDK 8 so would not be >> >> able to backport the change. >> >> >> >> Thanks, >> >> Lois >> >> >> >> >> >>> >> >>> Thanks, >> >>> Volker >> >>> >> >>> On Fri, Apr 11, 2014 at 1:15 PM, David Holmes >> >>> wrote: >> >>>> >> >>>> On 11/04/2014 8:43 PM, David Holmes wrote: >> >>>>> >> >>>>> On 11/04/2014 8:34 PM, Volker Simonis wrote: >> >>>>>> >> >>>>>> On Fri, Apr 11, 2014 at 3:58 AM, David Holmes > >>>>>> > wrote: >> >>>>>> >> >>>>>> On 11/04/2014 4:33 AM, Volker Simonis wrote: >> >>>>>> >> >>>>>> Hi David, >> >>>>>> >> >>>>>> thanks for looking at this issue. >> >>>>>> >> >>>>>> I agree with you and I've completely removed >> >>>>>> ALLOW_OPERATOR_NEW now: >> >>>>>> >> >>>>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805.v2/ >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I actually meant delete the whole block guarded by >> >>>>>> ALLOW_OPERATOR_NEW - we don't need these error-trapping >> >>>>>> definitions >> >>>>>> now we have fixed the export problem. >> >>>>>> >> >>>>>> >> >>>>>> OK, but arguing this way, we could remove remove all asserts from the >> >>>>>> code, once we fixed an error revealed by them. >> >>>>> >> >>>>> >> >>>>> Obviously you have to draw a line somewhere. But I don't think these >> >>>>> particular methods are worth the problem they are now causing. >> >>>> >> >>>> >> >>>> Ignore that. I just realized it is not the external linkage to these >> >>>> methods >> >>>> that is the main issue, but some internal hotspot code calling the global >> >>>> operator new/delete. >> >>>> >> >>>> David >> >>>> >> >>>> >> >>>>> Cheers, >> >>>>> David >> >>>>> >> >>>>>> I think the error-trapping new/delete operators are still valuable in >> >>>>>> protecting people from accidentally calling them (and they don't really >> >>>>>> hurt anybody in terms of performance or space). >> >>>>>> >> >>>>>> Regards, >> >>>>>> Volker >> >>>>>> >> >>>>>> FYI I'm not in the runtime group. >> >>>>>> >> >>>>>> David >> >>>>>> ----- >> >>>>>> >> >>>>>> >> >>>>>> I've also changed the "guarantee" into "fatal" as proposed by >> >>>>>> Vladimir. >> >>>>>> >> >>>>>> I've thought a little while about the problem that some other >> >>>>>> code may >> >>>>>> unintentionally use these operators but I couldn?t really find >> >>>>>> a >> >>>>>> scenario where this could happen. Because as you correctly >> >>>>>> pointed >> >>>>>> out, these operators aren't exported from libjvm.so - after >> >>>>>> all, >> >>>>>> that's the whole reason for compiling with visibility=hidden >> >>>>>> and >> >>>>>> using >> >>>>>> of export maps. So if another program/library will load >> >>>>>> libjvm.so, the >> >>>>>> operators won't be visible. On the other hand, if the >> >>>>>> libjvm.so >> >>>>>> loads >> >>>>>> another shared libraries which use these operators they either >> >>>>>> have >> >>>>>> their own, private versions of them or they are dynamically >> >>>>>> linked >> >>>>>> against another library (most probably the standard library) >> >>>>>> which >> >>>>>> provides versions of the operators. >> >>>>>> >> >>>>>> So if I'm not totally wrong, we could in principle also enable >> >>>>>> these >> >>>>>> operators in the product build. However, I'm not proposing >> >>>>>> that for >> >>>>>> this change. Let's first fix the signatures and get rid of >> >>>>>> ALLOW_OPERATOR_NEW with this change. If everything works fine, >> >>>>>> we can >> >>>>>> think about enabling these global operators in product builds >> >>>>>> as >> >>>>>> well. >> >>>>>> >> >>>>>> By the way - are you from the runtime group? >> >>>>>> I was asked to get a review from a runtime-group member - >> >>>>>> anybody out >> >>>>>> there willing to volunteer? >> >>>>>> >> >>>>>> Thank you and best regards, >> >>>>>> Volker >> >>>>>> >> >>>>>> >> >>>>>> On Thu, Apr 10, 2014 at 5:19 AM, David Holmes >> >>>>>> > >> >>>>>> wrote: >> >>>>>> >> >>>>>> I think we should just delete the whole ALLOW_OPERATOR_NEW >> >>>>>> block. We fixed >> >>>>>> the problem of it being called outside the VM under >> >>>>>> 8014326. >> >>>>>> >> >>>>>> David >> >>>>>> >> >>>>>> >> >>>>>> On 10/04/2014 12:48 PM, David Holmes wrote: >> >>>>>> >> >>>>>> >> >>>>>> Hi Volker, >> >>>>>> >> >>>>>> Need more time to consider this in full but from the >> >>>>>> existing code: >> >>>>>> >> >>>>>> 689 // On certain platforms, such as Mac OS X >> >>>>>> (Darwin), in debug >> >>>>>> version, new is being called >> >>>>>> 690 // from jdk source and causing data >> >>>>>> corruption. >> >>>>>> Such as >> >>>>>> 691 // >> >>>>>> >> >>>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >> >>>>>> 692 // define ALLOW_OPERATOR_NEW_USAGE for >> >>>>>> platform >> >>>>>> on which global >> >>>>>> operator new allowed. >> >>>>>> >> >>>>>> we actually fixed that by using the mapfiles to ensure >> >>>>>> the hotspot >> >>>>>> operator new was not visible externally. The existence >> >>>>>> of >> >>>>>> ALLOW_OPERATOR_NEW_USAGE wasn't even raised at the >> >>>>>> time :( >> >>>>>> >> >>>>>> https://bugs.openjdk.java.net/__browse/JDK-8014326 >> >>>>>> >> >>>>>> >> >>>>>> David >> >>>>>> >> >>>>>> On 10/04/2014 2:34 AM, Volker Simonis wrote: >> >>>>>> >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> could you please review and sponsor the following >> >>>>>> small change: >> >>>>>> >> >>>>>> >> >>>>>> http://cr.openjdk.java.net/~__simonis/webrevs/8039805/ >> >>>>>> >> >>>>>> >> >>>>>> https://bugs.openjdk.java.net/__browse/JDK-8039805 >> >>>>>> >> >>>>>> >> >>>>>> which fixes the signature of the global new/delete >> >>>>>> operators in >> >>>>>> allocation.cpp >> >>>>>> >> >>>>>> For non-product builds allocation.cpp defines >> >>>>>> global >> >>>>>> new/delete >> >>>>>> operators which shut down the VM if they get >> >>>>>> called >> >>>>>> at runtime. The >> >>>>>> rational behind this is that the these global >> >>>>>> operators should never >> >>>>>> be used in HotSpot. >> >>>>>> >> >>>>>> Unfortunately, the signature of some of these >> >>>>>> operators doesn't >> >>>>>> conform to the C++ standard which confuses some >> >>>>>> C++ >> >>>>>> compilers. For a >> >>>>>> more detailed explanation of the C++ background of >> >>>>>> this issue see the >> >>>>>> new comments in allcoation.cpp and the end of this >> >>>>>> mail. >> >>>>>> >> >>>>>> This change also replaces the asserts in the >> >>>>>> operators with guarantees >> >>>>>> because the code may also be active in not-product >> >>>>>> (aka. 'optimized') >> >>>>>> builds. >> >>>>>> >> >>>>>> Finally, the webrev fixes two places in the >> >>>>>> AIX-port >> >>>>>> which used the >> >>>>>> global new operator. After the change we can now >> >>>>>> remove the definition >> >>>>>> of ALLOW_OPERATOR_NEW_USAGE from >> >>>>>> aix/makefiles/vm.make. >> >>>>>> >> >>>>>> I have also removed ALLOW_OPERATOR_NEW_USAGE from >> >>>>>> bsd/makefiles/vm.make and the corresponding >> >>>>>> comments >> >>>>>> in allcoation.cpp >> >>>>>> which state that on Mac OS X the global new/delete >> >>>>>> operators from the >> >>>>>> HotSpot cause problems together with usages of >> >>>>>> these >> >>>>>> operators from >> >>>>>> the class library such as the ones from >> >>>>>> >> >>>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair. >> >>>>>> I couldn?t >> >>>>>> observe any such problems but if anybody has some >> >>>>>> concrete concerns >> >>>>>> I'm ready to remove this part from the webrev. >> >>>>>> >> >>>>>> I've build and tested these changes on >> >>>>>> Linux/x86_64, >> >>>>>> Linux/ppc64, >> >>>>>> Solaris/Sparc, Windows/x86_64, MacOS X and >> >>>>>> AIX/ppc64. I've especially >> >>>>>> run the regression tests from sun/security/ec >> >>>>>> which >> >>>>>> exercise the >> >>>>>> method >> >>>>>> >> >>>>>> Java_sun_security_ec___ECKeyPairGenerator___generateECKeyPair >> >>>>>> which >> >>>>>> was mentioned to cause problems in conjunction >> >>>>>> with >> >>>>>> the globally >> >>>>>> defined new/delete operators from the HotSpot but >> >>>>>> couldn't see any >> >>>>>> issues, neither in the slowdebug nor in the >> >>>>>> optimized build. >> >>>>>> >> >>>>>> Following some C++ background regarding the global >> >>>>>> new/delete operators: >> >>>>>> >> >>>>>> In C++98/03 the throwing new operators are defined >> >>>>>> with the following >> >>>>>> signature: >> >>>>>> >> >>>>>> void* operator new(std::size_tsize) >> >>>>>> throw(std::bad_alloc); >> >>>>>> void* operator new[](std::size_tsize) >> >>>>>> throw(std::bad_alloc); >> >>>>>> >> >>>>>> while all the other (non-throwing) new and delete >> >>>>>> operators are >> >>>>>> defined with an empty throw clause (i.e. "operator >> >>>>>> delete(void* p) >> >>>>>> throw()") which means that they do not throw any >> >>>>>> exceptions (see >> >>>>>> section 18.4 of the C++ standard >> >>>>>> >> >>>>>> http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2005/__n1905.pdf >> >>>>>> >> >>>>>> ). >> >>>>>> >> >>>>>> In the new C++11/14 standard >> >>>>>> >> >>>>>> (http://www.open-std.org/jtc1/__sc22/wg21/docs/papers/2013/__n3797.pdf >> >>>>>> >> >>>>>> ), >> >>>>>> the signature of the throwing new operators was >> >>>>>> changed by completely >> >>>>>> omitting the throw clause (which effectively means >> >>>>>> they could throw >> >>>>>> any exception) while all the other new/delete >> >>>>>> operators where changed >> >>>>>> to have a 'nothrow' clause instead of an empty >> >>>>>> throw >> >>>>>> clause. >> >>>>>> >> >>>>>> Unfortunately, the support for exception >> >>>>>> specifications among C++ >> >>>>>> compilers is still very fragile. While some more >> >>>>>> strict compilers like >> >>>>>> AIX xlC or HP aCC reject to override the default >> >>>>>> throwing new operator >> >>>>>> with a user operator with an empty throw() clause, >> >>>>>> the MS Visual C++ >> >>>>>> compiler warns for every non-empty throw clause >> >>>>>> like >> >>>>>> throw(std::bad_alloc) that it will ignore the >> >>>>>> exception specification >> >>>>>> (see >> >>>>>> >> >>>>>> http://msdn.microsoft.com/en-__us/library/sa28fef8.aspx >> >>>>>> >> >>>>>> ). >> >>>>>> >> >>>>>> I've therefore changed the operator definitions >> >>>>>> such >> >>>>>> that they >> >>>>>> correctly work with all currently supported >> >>>>>> compilers and in way which >> >>>>>> should be upwards compatible with C++11/14. >> >>>>>> >> >>>>>> Please notice that I'm aware of the discussion >> >>>>>> around "8021954: VM >> >>>>>> SIGSEGV during classloading on MacOS; hs_err_pid >> >>>>>> file produced" >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> (http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2013-August/thread.html#8924 >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> , >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> http://hg.openjdk.java.net/__hsx/hotspot-comp/hotspot/rev/__9758d9f36299 >> >>>>>> >> >>>>>> ) >> >>>>>> which introduced empty throw() clauses on all user >> >>>>>> defined new >> >>>>>> operators. But I think the rational used for that >> >>>>>> change doesn't apply >> >>>>>> here, because these global, user user defined new >> >>>>>> operators changed in >> >>>>>> this webrev aren't meant to be really used. There >> >>>>>> only task is to >> >>>>>> override the default, global operators (and >> >>>>>> therefore they need to >> >>>>>> have the right signature) and to shut the VM down >> >>>>>> if >> >>>>>> they get called. >> >>>>>> >> >>>>>> Thank you and best regards, >> >>>>>> Volker >> >>>>>> >> >>>>>> >> >>>>>> >> >> > > > From vladimir.kozlov at oracle.com Wed Apr 30 17:10:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Apr 2014 10:10:51 -0700 Subject: [9] RFR(S): 8041992: Fix of JDK-8034775 neglects to account for non-JIT VMs In-Reply-To: <5360AB9B.3050109@oracle.com> References: <5360AB9B.3050109@oracle.com> Message-ID: <53612E9B.3010402@oracle.com> Looks good. Albert, please, don't forget to add to changeset descriptor: Contributed-by: sgehwolf at redhat.com Thanks, Vladimir On 4/30/14 12:51 AM, Albert wrote: > Hi, > > could I get reviews for the following bug? > The proposed fix for this bug is provided by Severin (see cc). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8041992 > > Problem: > JDK-8034775 restricts the number of compiler threads to be at least 1. This restriction does not make sense for a > non-JIT JVM (zero). > > Solution: > Allow 0 compiler threads if no JIT is used. > > Testing: > Failing test case > > Webrev: > http://cr.openjdk.java.net/~anoll/8041992/webrev.00/ > > Many thanks, > Albert From vladimir.kozlov at oracle.com Wed Apr 30 17:37:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Apr 2014 10:37:29 -0700 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <535ED251.8000501@oracle.com> <04E9C0ED-4F68-4796-8BE9-FF3E116D3F9C@oracle.com> <536094B2.90301@oracle.com> Message-ID: <536134D9.6030100@oracle.com> On 4/30/14 4:47 AM, David Chase wrote: > > On 2014-04-30, at 2:14 AM, Vladimir Kozlov wrote: > >> David, >> >> Thank you for fixing vm_version files. >> >> In c1_LIR.cpp, c1_Runtime1.cpp, ciInstanceKlass.cpp, ciMetadata.cpp, ciObject.cpp not all 0x%" PRIxPTR were replaced by PTR_FORMAT. >> >> I see you kept a lot of '0x" PRIxPTR' instead of using INTPTR_FORMAT (or PTR_FORMAT) when printing (p2i) pointers. Why? >> Files c1_LIR.cpp, c1_Runtime1.cpp, ciInstanceKlass.cpp, ciMetadata.cpp, ciObject.cpp, markOop.cpp. > > I'm reluctant to do that, since it changes the output, from 0xbeef to 0x0000beef or 0x000000000000beef. > Is that really acceptable? We are printing pointers, we do and should, I think, print all their bits. It is indication that a value in an output is a pointer. When we have bad bits I prefer to have all 0s shown: 0x00100001 instead of 0x100001. And bad pattern is usually repeated: 0xbeefbeef. > >> memnode.cpp - for printing intptr_t values we should use INTX_FORMAT. > > got that -- this is as opposed to PRIdPTR, right? Yes, because INTX_FORMAT is exactly "%" PRIdPTR. Note, intx is 32 bit in 32-bit VM and 64 bit in 64-bit VM, the same as intptr_t: typedef intptr_t intx; > >> arguments.cpp - not all (unsigned int) were replaced. > > got that -- two more. > >> I see that you enable by default ATTRIBUTE_PRINTF for print() and print_cr(). Does it mean they are checked by clang and gcc? I am for that if it is true otherwise they will degrade. I remember in first review you commented it. So I missed when it was enabled. > > I enabled it because of taking to Coleen; it seemed like an extremely good idea. Yes, I agree. Thanks, Vladimir > >> General question for not these changes. Do we still need PTR_FORMAT since you used p2i() for all pointer values which use INTPTR_FORMAT? Their definition are the same. Why keep both? > > I have no idea. Whoever provided the macros did not give much guidance. PTR_FORMAT is shorter. > > David > From vladimir.kozlov at oracle.com Wed Apr 30 17:39:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Apr 2014 10:39:36 -0700 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <22AFD948-6177-4694-B142-8C34F9F7A833@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <5359F2AE.8010808@oracle.com> <2F5B7196-8CB1-4D70-92AE-E2FE76A1378D@oracle.com> <535DFE3B.60903@oracle.com> <5360BDC8.4050302@oracle.com> <22AFD948-6177-4694-B142-8C34F9F7A833@oracle.com> Message-ID: <53613558.80403@oracle.com> On 4/30/14 4:59 AM, David Chase wrote: > > On 2014-04-30, at 5:09 AM, David Holmes wrote: >>> How do you like it otherwise? I'm itching to get reviews and get this thing out of my hair. >> >> I appreciate what you are doing but I dislike the details - in particular print_raw and, even worse, cr(). >> >> One thing we do need from this is some clear documentation somewhere on what format specific macros to use for which types. > > You do understand that those are both existing public methods, and I did not add or innovate, right? > It's also completely nonintuitive to me that you would dislike cr more than print_raw. > > Rather than document, we could make them not be public, if we really meant for them not to be called. > I prefer Vladimir's proposal to rename print_raw into puts. > > One thing that is a little puzzling to me is why we have both INTX and INT64. INTX is 32 bit in 32 bit VM: // intx and uintx are the 'extended' int and 'extended' unsigned int types; // they are 32bit wide on a 32-bit platform, and 64bit wide on a 64bit platform. typedef intptr_t intx; typedef uintptr_t uintx; Vladimir > I see no purpose whatsoever for INTX; it appears to be a 64-bit integer type, > but we have a well-defined 64-bit integer type (INT64) and a not-well-defined > 64-bit integer type (JLONG) that we own because it is Ours. We also have a > pointer-sized integer type (INTPTR) and if this is actually a distinction, > an "I intend to print this integer as a pointer type" (PTR). > > David > From sgehwolf at redhat.com Wed Apr 30 17:30:14 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Apr 2014 19:30:14 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> <5347C745.2040901@oracle.com> <5347CED1.3000908@oracle.com> <535FB05B.6030605@oracle.com> <5360C95A.3050309@oracle.com> <1398864785.3300.35.camel@localhost.localdomain> Message-ID: <1398879014.3300.45.camel@localhost.localdomain> Hi Volker, Thanks for your thoughts! On Wed, 2014-04-30 at 18:44 +0200, Volker Simonis wrote: > On Wed, Apr 30, 2014 at 3:33 PM, Severin Gehwolf wrote: > > Hi Volker, > > > > On Wed, 2014-04-30 at 19:58 +1000, David Holmes wrote: > >> On 30/04/2014 3:24 AM, Volker Simonis wrote: > >> > Hi Lois, > >> > > >> > sure, the latest webrev was: > >> > > >> > http://cr.openjdk.java.net/~simonis/webrevs/8039805.v3/ > >> > > >> > As far as I understood, David recalled his concerns in his last mail > >> > ("..Ignore that. I just realized it is not the external linkage to > >> > these methods that is the main issue, but some internal hotspot code > >> > calling the global operator new/delete.." - see > >> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013523.html) > >> > > >> > @David: are you OK with the change now? > >> > >> Yes. To clarify for Lois my "Ignore that" retracted my comment that > >> everything in the "#ifndef ALLOW_OPERATOR_NEW_USAGE" block could be > >> deleted. I'm okay with getting rid of ALLOW_OPERATOR_NEW_USAGE itself. > > > > I believe removing the #ifndef ALLOW_OPERATOR_NEW_USAGE will break the > > shark JVM variant. Currently shark will need some more work to be > > useful, but a slowdebug build of shark doesn't even get past "java > > -version" due to those assertions. Defining it for a shark build + one > > Hi Severin, > > could you please post the stack trace of the assertion to see where > the operators are called from. Here is the mostly unreadable-in-email back trace: Breakpoint 1, operator new (size=16) at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/hotspot/src/share/vm/memory/allocation.cpp:696 696 assert(false, "Should not call global operator new"); (gdb) bt #0 operator new (size=16) at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/hotspot/src/share/vm/memory/allocation.cpp:696 #1 0x00007ffff6c51a3b in void* llvm::object_creator >() () from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so #2 0x00007ffff729f255 in llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const () from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so #3 0x00007ffff7299070 in llvm::sys::DynamicLibrary::AddSymbol(llvm::StringRef, void*) () from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so #4 0x00007ffff64c8584 in _GLOBAL__sub_I_JITMemoryManager.cpp () from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so #5 0x000000388560f2ea in call_init (l=, argc=argc at entry=2, argv=argv at entry=0x7fffffffdf28, env=env at entry=0x7fffffffdf40) at dl-init.c:82 #6 0x000000388560f3d3 in call_init (env=, argv=, argc=, l=) at dl-init.c:34 #7 _dl_init (main_map=main_map at entry=0x6024a0, argc=2, argv=0x7fffffffdf28, env=0x7fffffffdf40) at dl-init.c:130 #8 0x00000038856139b4 in dl_open_worker (a=a at entry=0x7fffffffaab8) at dl-open.c:566 #9 0x000000388560f174 in _dl_catch_error (objname=objname at entry=0x7fffffffaaa8, errstring=errstring at entry=0x7fffffffaab0, mallocedp=mallocedp at entry=0x7fffffffaaa0, operate=operate at entry=0x3885613620 , args=args at entry=0x7fffffffaab8) at dl-error.c:177 #10 0x000000388561309b in _dl_open ( file=0x7fffffffcd60 "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so", mode=-2147483390, caller_dlopen=0x7ffff7dd4ff1 , nsid=-2, argc=2, argv=, env=0x7fffffffdf40) at dl-open.c:650 #11 0x0000003886a0102b in dlopen_doit (a=a at entry=0x7fffffffacc0) at dlopen.c:66 #12 0x000000388560f174 in _dl_catch_error (objname=0x602100, errstring=0x602108, mallocedp=0x6020f8, operate=0x3886a00fd0 , args=0x7fffffffacc0) at dl-error.c:177 #13 0x0000003886a0162d in _dlerror_run (operate=operate at entry=0x3886a00fd0 , args=args at entry=0x7fffffffacc0) at dlerror.c:163 #14 0x0000003886a010c1 in __dlopen (file=, mode=) at dlopen.c:87 #15 0x00007ffff7dd4ff1 in LoadJavaVM ( jvmpath=0x7fffffffcd60 "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so", ifn=0x7fffffffdd60) at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/jdk/src/solaris/bin/java_md_solinux.c:697 #16 0x00007ffff7dced48 in JLI_Launch (argc=2, argv=0x6020d0, jargc=1, jargv=0x0, appclassc=1, appclassv=0x0, fullversion=0x4008c8 "1.9.0-internal-debug-sgeholf_2014_04_30_19_05-b00", dotversion=0x4008c0 "1.9", pname=0x4008ac "java", lname=0x4008b1 "openjdk", javaargs=0 '\000', cpwildcard=1 '\001', javaw=0 '\000', ergo=0) at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/jdk/src/share/bin/java.c:248 #17 0x00000000004007dc in main (argc=2, argv=0x7fffffffdf28) at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/jdk/src/share/bin/main.c:125 > > other small fix will make "java -version" work. > > > > Take away: Shark code uses llvm and that in turn calls those global > > new/delete operators in spades. How do you suggest to work around this > > with this ifndef removed. Thoughts? > > > > I must confess that I don't know exactly how the Shark build works, > but if you load llvm as a shared library the llvm code shouldn't even > see the global HotSpot new/delete operators because we don't export > them and we compile with -fvisibility=hidden. Looking at the created > libjvm.so, this is confirmed: > > 00000000003d4442 t operator new[](unsigned long) > 00000000003d44b4 t operator new[](unsigned long, std::nothrow_t&) > 00000000003d440b t operator new(unsigned long) > 000000000038a986 t operator new(unsigned long, void*) > 00000000003d4479 t operator new(unsigned long, std::nothrow_t const&) > My only explanation for the problems you see would be if you compile > the llvm code right into the libjvm.so. If that's the case you should > either consider to build the llvm into it's own library or you should > flag the global operators in allocation.cpp with #ifndef SHARK". OK, thanks. I'll look into this. > By the way, I also couldn't find a place n the current makefiles where > ALLOW_OPERATOR_NEW_USAGE is defined for a SHARK build. Where do you > currently set that define? Oh, sorry for the confusion. It's a local patch I'm using. In make/linux/makefiles/shark.make I have: CFLAGS += -DSHARK -DALLOW_OPERATOR_NEW_USAGE instead of the upstream version which has: CFLAGS += -DSHARK Cheers, Severin From volker.simonis at gmail.com Wed Apr 30 18:28:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 30 Apr 2014 20:28:13 +0200 Subject: RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp In-Reply-To: <1398879014.3300.45.camel@localhost.localdomain> References: <5346066A.3000401@oracle.com> <53460DBA.4010708@oracle.com> <53474C4B.9000006@oracle.com> <5347C745.2040901@oracle.com> <5347CED1.3000908@oracle.com> <535FB05B.6030605@oracle.com> <5360C95A.3050309@oracle.com> <1398864785.3300.35.camel@localhost.localdomain> <1398879014.3300.45.camel@localhost.localdomain> Message-ID: On Wed, Apr 30, 2014 at 7:30 PM, Severin Gehwolf wrote: > Hi Volker, > > Thanks for your thoughts! > > On Wed, 2014-04-30 at 18:44 +0200, Volker Simonis wrote: >> On Wed, Apr 30, 2014 at 3:33 PM, Severin Gehwolf wrote: >> > Hi Volker, >> > >> > On Wed, 2014-04-30 at 19:58 +1000, David Holmes wrote: >> >> On 30/04/2014 3:24 AM, Volker Simonis wrote: >> >> > Hi Lois, >> >> > >> >> > sure, the latest webrev was: >> >> > >> >> > http://cr.openjdk.java.net/~simonis/webrevs/8039805.v3/ >> >> > >> >> > As far as I understood, David recalled his concerns in his last mail >> >> > ("..Ignore that. I just realized it is not the external linkage to >> >> > these methods that is the main issue, but some internal hotspot code >> >> > calling the global operator new/delete.." - see >> >> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013523.html) >> >> > >> >> > @David: are you OK with the change now? >> >> >> >> Yes. To clarify for Lois my "Ignore that" retracted my comment that >> >> everything in the "#ifndef ALLOW_OPERATOR_NEW_USAGE" block could be >> >> deleted. I'm okay with getting rid of ALLOW_OPERATOR_NEW_USAGE itself. >> > >> > I believe removing the #ifndef ALLOW_OPERATOR_NEW_USAGE will break the >> > shark JVM variant. Currently shark will need some more work to be >> > useful, but a slowdebug build of shark doesn't even get past "java >> > -version" due to those assertions. Defining it for a shark build + one >> >> Hi Severin, >> >> could you please post the stack trace of the assertion to see where >> the operators are called from. > > Here is the mostly unreadable-in-email back trace: > > Breakpoint 1, operator new (size=16) > at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/hotspot/src/share/vm/memory/allocation.cpp:696 > 696 assert(false, "Should not call global operator new"); > (gdb) bt > #0 operator new (size=16) > at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/hotspot/src/share/vm/memory/allocation.cpp:696 > #1 0x00007ffff6c51a3b in void* > llvm::object_creator >() () > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so > #2 0x00007ffff729f255 in > llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void > (*)(void*)) const () > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so > #3 0x00007ffff7299070 in > llvm::sys::DynamicLibrary::AddSymbol(llvm::StringRef, void*) () > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so > #4 0x00007ffff64c8584 in _GLOBAL__sub_I_JITMemoryManager.cpp () > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so > #5 0x000000388560f2ea in call_init (l=, > argc=argc at entry=2, argv=argv at entry=0x7fffffffdf28, > env=env at entry=0x7fffffffdf40) at dl-init.c:82 > #6 0x000000388560f3d3 in call_init (env=, > argv=, argc=, l=) at > dl-init.c:34 > #7 _dl_init (main_map=main_map at entry=0x6024a0, argc=2, > argv=0x7fffffffdf28, env=0x7fffffffdf40) at dl-init.c:130 > #8 0x00000038856139b4 in dl_open_worker (a=a at entry=0x7fffffffaab8) at > dl-open.c:566 > #9 0x000000388560f174 in _dl_catch_error > (objname=objname at entry=0x7fffffffaaa8, > errstring=errstring at entry=0x7fffffffaab0, > mallocedp=mallocedp at entry=0x7fffffffaaa0, > operate=operate at entry=0x3885613620 , > args=args at entry=0x7fffffffaab8) at dl-error.c:177 > #10 0x000000388561309b in _dl_open ( > file=0x7fffffffcd60 > "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so", mode=-2147483390, caller_dlopen=0x7ffff7dd4ff1 , nsid=-2, argc=2, argv=, env=0x7fffffffdf40) at dl-open.c:650 > #11 0x0000003886a0102b in dlopen_doit (a=a at entry=0x7fffffffacc0) at > dlopen.c:66 > #12 0x000000388560f174 in _dl_catch_error (objname=0x602100, > errstring=0x602108, mallocedp=0x6020f8, operate=0x3886a00fd0 > , args=0x7fffffffacc0) at dl-error.c:177 > #13 0x0000003886a0162d in _dlerror_run > (operate=operate at entry=0x3886a00fd0 , > args=args at entry=0x7fffffffacc0) at dlerror.c:163 > #14 0x0000003886a010c1 in __dlopen (file=, > mode=) at dlopen.c:87 > #15 0x00007ffff7dd4ff1 in LoadJavaVM ( > jvmpath=0x7fffffffcd60 > "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so", ifn=0x7fffffffdd60) at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/jdk/src/solaris/bin/java_md_solinux.c:697 > #16 0x00007ffff7dced48 in JLI_Launch (argc=2, argv=0x6020d0, jargc=1, > jargv=0x0, appclassc=1, appclassv=0x0, > fullversion=0x4008c8 > "1.9.0-internal-debug-sgeholf_2014_04_30_19_05-b00", dotversion=0x4008c0 > "1.9", pname=0x4008ac "java", lname=0x4008b1 "openjdk", javaargs=0 > '\000', > cpwildcard=1 '\001', javaw=0 '\000', ergo=0) > at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/jdk/src/share/bin/java.c:248 > #17 0x00000000004007dc in main (argc=2, argv=0x7fffffffdf28) > at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/jdk/src/share/bin/main.c:125 > >> > other small fix will make "java -version" work. >> > >> > Take away: Shark code uses llvm and that in turn calls those global >> > new/delete operators in spades. How do you suggest to work around this >> > with this ifndef removed. Thoughts? >> > >> >> I must confess that I don't know exactly how the Shark build works, >> but if you load llvm as a shared library the llvm code shouldn't even >> see the global HotSpot new/delete operators because we don't export >> them and we compile with -fvisibility=hidden. Looking at the created >> libjvm.so, this is confirmed: >> >> 00000000003d4442 t operator new[](unsigned long) >> 00000000003d44b4 t operator new[](unsigned long, std::nothrow_t&) >> 00000000003d440b t operator new(unsigned long) >> 000000000038a986 t operator new(unsigned long, void*) >> 00000000003d4479 t operator new(unsigned long, std::nothrow_t const&) > >> My only explanation for the problems you see would be if you compile >> the llvm code right into the libjvm.so. If that's the case you should >> either consider to build the llvm into it's own library or you should >> flag the global operators in allocation.cpp with #ifndef SHARK". > OK, the stack trace shows that the llvm code is indeed compiled and linked right into libjvm.so: #1 0x00007ffff6c51a3b in void* llvm::object_creator >() () from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so That explains why it sees and uses HotSpots overloaded version of the new operator. Again, I don't now much about SHARK. But why is it necessary to compile llvm right into the libjvm.so. Can't you compile it in it's own library (i.e. llvm.so) and load that one dynamically. I think that would solve the problem (and make you SHARK-enabled HotSpot more modular at the same time). > OK, thanks. I'll look into this. > >> By the way, I also couldn't find a place n the current makefiles where >> ALLOW_OPERATOR_NEW_USAGE is defined for a SHARK build. Where do you >> currently set that define? > > Oh, sorry for the confusion. It's a local patch I'm using. In > make/linux/makefiles/shark.make I have: > > CFLAGS += -DSHARK -DALLOW_OPERATOR_NEW_USAGE > > instead of the upstream version which has: > > CFLAGS += -DSHARK > > Cheers, > Severin > From david.r.chase at oracle.com Wed Apr 30 18:31:58 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 30 Apr 2014 14:31:58 -0400 Subject: [9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang In-Reply-To: <536134D9.6030100@oracle.com> References: <160E09C5-6286-4423-8F56-96596B91E71B@oracle.com> <5355CC9D.3090609@oracle.com> <0FE8263B-A70D-48D2-8D51-EE78A70C923B@oracle.com> <535ED251.8000501@oracle.com> <04E9C0ED-4F68-4796-8BE9-FF3E116D3F9C@oracle.com> <536094B2.90301@oracle.com> <536134D9.6030100@oracle.com> Message-ID: <272B1797-F18F-4701-983F-28E07CAE650F@oracle.com> On 2014-04-30, at 1:37 PM, Vladimir Kozlov wrote: > On 4/30/14 4:47 AM, David Chase wrote: >> >> On 2014-04-30, at 2:14 AM, Vladimir Kozlov wrote: >> >>> David, >>> >>> Thank you for fixing vm_version files. >>> >>> In c1_LIR.cpp, c1_Runtime1.cpp, ciInstanceKlass.cpp, ciMetadata.cpp, ciObject.cpp not all 0x%" PRIxPTR were replaced by PTR_FORMAT. >>> >>> I see you kept a lot of '0x" PRIxPTR' instead of using INTPTR_FORMAT (or PTR_FORMAT) when printing (p2i) pointers. Why? >>> Files c1_LIR.cpp, c1_Runtime1.cpp, ciInstanceKlass.cpp, ciMetadata.cpp, ciObject.cpp, markOop.cpp. >> >> I'm reluctant to do that, since it changes the output, from 0xbeef to 0x0000beef or 0x000000000000beef. >> Is that really acceptable? > > We are printing pointers, we do and should, I think, print all their bits. It is indication that a value in an output is a pointer. When we have bad bits I prefer to have all 0s shown: 0x00100001 instead of 0x100001. And bad pattern is usually repeated: 0xbeefbeef. 0xbeef was a good pattern (and for illustration of the change), that's why it was not repeated :-). If nobody objects, I'll make those changes, then. David From dmitry.samersoff at oracle.com Wed Apr 30 19:18:40 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 30 Apr 2014 23:18:40 +0400 Subject: RFR: 8034094: SA agent can't compile when jni_x86.h is used In-Reply-To: <52F8EE89.6040808@oracle.com> References: <52F8EB7A.4080305@oracle.com> <52F8EE89.6040808@oracle.com> Message-ID: <53614C90.2080701@oracle.com> Erik, Sorry, missed the thread. Changes (option 2) looks good for me. -Dmitry On 2014-02-10 19:21, Erik Helin wrote: > Sigh, I forgot the subject... > > "RFR: 8034094: SA agent can't compile when jni_x86.h is used" > > Thanks, > Erik > > On 2014-02-10 16:08, Erik Helin wrote: >> Hi all, >> >> this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and >> jni_md.h. >> >> The bug manifests itself when using an IMPORT_JDK which >> include/linux/jni_md.h has a timestamp that is older than >> hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will >> copy hotspot/src/cpu/x86/jni_x86.h to >> hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h. >> >> The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from >> jdk/include/jni.h, since it is used for all operating systems: >> >> #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) >> ... // common stuff >> #else >> ... // windows stuff >> #endif >> >> We compile the SA agent, see make/linux/makefiles/saproc.make, without >> defining LINUX (LINUX is hotspot's own define, gcc uses __linux__). >> >> In my opinion, there are two ways to solve this: >> 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding >> defines for Solaris and BSD). >> 2. Rewrite the #if check in jni_x86.h to use platform specific "native" >> defines. >> >> I've created a patch for each alternative: >> 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/ >> 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/ >> >> For the second patch, note that I've inverted the #if check so that it >> checks for _WIN32 is defined and treat all others operating systems as >> "#else". >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8034094 >> >> Testing: >> - Compiled both version locally and made sure it worked >> - JPRT >> >> Thanks, >> Erik -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alejandro.murillo at oracle.com Wed Apr 30 21:44:48 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 30 Apr 2014 15:44:48 -0600 Subject: [7u80] RFR (S) 8042247: Make 7u60 the default jprt release for hs24.80 Message-ID: <53616ED0.4070900@oracle.com> Can I get a quick review to this change? 8042247 : Make 7u60 the default jprt release for hs24.80 webrev: http://cr.openjdk.java.net/~amurillo/7u80/8042247/ thanks -- Alejandro From vladimir.kozlov at oracle.com Wed Apr 30 21:51:25 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Apr 2014 14:51:25 -0700 Subject: [7u80] RFR (S) 8042247: Make 7u60 the default jprt release for hs24.80 In-Reply-To: <53616ED0.4070900@oracle.com> References: <53616ED0.4070900@oracle.com> Message-ID: <5361705D.6060007@oracle.com> Okay. Vladimir On 4/30/14 2:44 PM, Alejandro E Murillo wrote: > Can I get a quick review to this change? > > 8042247 : Make 7u60 > the default jprt release for hs24.80 > webrev: http://cr.openjdk.java.net/~amurillo/7u80/8042247/ > > thanks > From alejandro.murillo at oracle.com Wed Apr 30 21:57:53 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 30 Apr 2014 15:57:53 -0600 Subject: [7u80] RFR (S) 8042247: Make 7u60 the default jprt release for hs24.80 In-Reply-To: <5361705D.6060007@oracle.com> References: <53616ED0.4070900@oracle.com> <5361705D.6060007@oracle.com> Message-ID: <536171E1.8090101@oracle.com> Thanks! Alejandro On 4/30/2014 3:51 PM, Vladimir Kozlov wrote: > Okay. > > Vladimir > > On 4/30/14 2:44 PM, Alejandro E Murillo wrote: >> Can I get a quick review to this change? >> >> 8042247 : Make 7u60 >> the default jprt release for hs24.80 >> webrev: http://cr.openjdk.java.net/~amurillo/7u80/8042247/ >> >> thanks >> -- Alejandro From christian.thalinger at oracle.com Wed Apr 30 22:58:59 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Apr 2014 12:58:59 -1000 Subject: RFR(S): 6885993: Named Thread: introduce print() and print_on(outputStream* st) methods In-Reply-To: <5360F0EA.7010104@oracle.com> References: <5360F0EA.7010104@oracle.com> Message-ID: <87A5C4F6-A5A7-426E-9E90-C8BC06575360@oracle.com> I?d prefer to have the method body of: + virtual void print_on(outputStream* st) const { in the .cpp file. Otherwise this is very nice and looks good. On Apr 30, 2014, at 2:47 AM, Zhengyu Gu wrote: > This is more of code cleanup. Instead of duplicating similar code all over subclasses of NamedThread, NamedThread should implements print_on(outputStream* str) and its subclasses should only set "name" to use default the implementation. > > Webrev: http://cr.openjdk.java.net/~zgu/6885993/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-6885993 > > Tests: > - JPRT > - Ran a Java program on Linux x64, do "CTRL-\" to dump Java stacks, make sure the output remains unchange. > > Thanks, > > -Zhengyu