From volker.simonis at gmail.com Mon Jul 1 09:28:02 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 1 Jul 2013 18:28:02 +0200 Subject: RFR(XXS): 8019382 : PPC64: Fix bytecodeInterpreter to compile with '-Wunused-value' Message-ID: Hi, this is a patch from the PowerPC/AIX porting project but it only changes shared code and it fixes a build problem in the C++ interpreter which also affects the Zero-Port so I would strongly recommend to push it right into the hotspot repository. The problem is related to "8014431 : cleanup warnings indicated by the -Wunused-value compiler option on linux" which added the "-Wunused-value" option to the Linux build but did not clean up the code in the c++ interpreter. This lead to several warnings which are now treated as errors when compiling bytecodeInterpreter.cpp. The fix is easy - just cast the offending expressions to void: http://cr.openjdk.java.net/~simonis/webrevs/8019382/ Thank you and best regards, Volker From coleen.phillimore at oracle.com Mon Jul 1 13:59:17 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 01 Jul 2013 16:59:17 -0400 Subject: RFR(XXS): 8019382 : PPC64: Fix bytecodeInterpreter to compile with '-Wunused-value' In-Reply-To: References: Message-ID: <51D1EDA5.90002@oracle.com> Looks good. If you need someone to check it, I'll do it after you get another review. Coleen On 07/01/2013 12:28 PM, Volker Simonis wrote: > Hi, > > this is a patch from the PowerPC/AIX porting project but it only > changes shared code and it fixes a build problem in the C++ > interpreter which also affects the Zero-Port so I would strongly > recommend to push it right into the hotspot repository. > > The problem is related to "8014431 : cleanup warnings indicated by the > -Wunused-value compiler option on linux" which added the > "-Wunused-value" option to the Linux build but did not clean up the > code in the c++ interpreter. This lead to several warnings which are > now treated as errors when compiling bytecodeInterpreter.cpp. > > The fix is easy - just cast the offending expressions to void: > > http://cr.openjdk.java.net/~simonis/webrevs/8019382/ > > Thank you and best regards, > Volker From vladimir.kozlov at oracle.com Mon Jul 1 14:12:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Jul 2013 14:12:52 -0700 Subject: RFR(XXS): 8019382 : PPC64: Fix bytecodeInterpreter to compile with '-Wunused-value' In-Reply-To: <51D1EDA5.90002@oracle.com> References: <51D1EDA5.90002@oracle.com> Message-ID: <51D1F0D4.5060308@oracle.com> Reviewed. I am pushing this into comp repo with me and Coleen as reviewers. Thanks, Vladimir On 7/1/13 1:59 PM, Coleen Phillimore wrote: > > Looks good. If you need someone to check it, I'll do it after you get > another review. > Coleen > > On 07/01/2013 12:28 PM, Volker Simonis wrote: >> Hi, >> >> this is a patch from the PowerPC/AIX porting project but it only >> changes shared code and it fixes a build problem in the C++ >> interpreter which also affects the Zero-Port so I would strongly >> recommend to push it right into the hotspot repository. >> >> The problem is related to "8014431 : cleanup warnings indicated by the >> -Wunused-value compiler option on linux" which added the >> "-Wunused-value" option to the Linux build but did not clean up the >> code in the c++ interpreter. This lead to several warnings which are >> now treated as errors when compiling bytecodeInterpreter.cpp. >> >> The fix is easy - just cast the offending expressions to void: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8019382/ >> >> Thank you and best regards, >> Volker > From eric.mccorkle at oracle.com Mon Jul 1 14:31:08 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 01 Jul 2013 17:31:08 -0400 Subject: Review request for JDK-8014933: Remove JVM_SetProtectionDomain from hotspot Message-ID: <51D1F51C.5050607@oracle.com> Hello, Please review the following patch, which removes the deprecated JNI call JVM_SetProtectionDomain from hotspot. The corresponding patch, which removes use of JVM_SetProtectionDomain was committed a while back to jdk8/tl, and was integrated into hsx/hotspot-rt late last week. The webrev is here: http://cr.openjdk.java.net/~emc/8014933/ Thanks, Eric From coleen.phillimore at oracle.com Mon Jul 1 14:48:24 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 01 Jul 2013 17:48:24 -0400 Subject: Review request for JDK-8014933: Remove JVM_SetProtectionDomain from hotspot In-Reply-To: <51D1F51C.5050607@oracle.com> References: <51D1F51C.5050607@oracle.com> Message-ID: <51D1F928.9020103@oracle.com> Hi Eric, This looks good -except can you move java_lang_Class::set_protection_domain into the private part of java_lang_Class with set_init_lock? The only caller is from within java_lang_Class class now. thanks, Coleen On 07/01/2013 05:31 PM, Eric McCorkle wrote: > Hello, > > Please review the following patch, which removes the deprecated JNI call > JVM_SetProtectionDomain from hotspot. > > The corresponding patch, which removes use of JVM_SetProtectionDomain > was committed a while back to jdk8/tl, and was integrated into > hsx/hotspot-rt late last week. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8014933/ > > Thanks, > Eric From vladimir.kozlov at oracle.com Mon Jul 1 16:17:00 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Jul 2013 16:17:00 -0700 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEDBDE@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDBDE@DEWDFEMB12A.global.corp.sap> Message-ID: <51D20DEC.7050904@oracle.com> Goetz, Why you did not add 'nop' between load and return instructions on sparc? It was in assembler in .s file. The next comment said we need it: !! By convention with the trap handler we ensure there is a non-CTI !! instruction in the trap shadow. Also should we align code in stubs to keep it in one cache line? __ align(CodeEntryAlignment); *entry = __ pc(); Thanks, Vladimir On 6/24/13 12:31 PM, Lindenmaier, Goetz wrote: > Hi, > > you are right, the check is redundant. > I removed it and updated the webrev and also based it on the > recent staging repo: > http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ > > Best regards, > Goetz. > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Monday, June 24, 2013 7:48 PM > To: Lindenmaier, Goetz > Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > > On Jun 20, 2013, at 7:01 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> I implemented the safefetch stubs for x86 and sparc (was quiet simple). >> This way I could clean up the #define right away. >> >> I tested it thouroughly on >> x86_64: bsd, nt, linux, solaris >> x86_32: nt, linux >> by adding it into our internal VM. >> Tonight I will get build/test on >> sparc_64 solaris >> sparc_32 solaris >> x86_64 nt, linux >> with the openjdk ppc port, but I tested that before submitting in a smaller >> extend, too. >> >> Here the webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ > > I like this change. It removes a lot of duplication. One comment: > > + static bool is_safefetch_fault(address pc) { > + return pc != NULL && > + (pc == _safefetch32_fault_pc || > + pc == _safefetchN_fault_pc); > + } > > checks for pc != null. Should we remove the check here? > > + if (pc && StubRoutines::is_safefetch_fault(pc)) { > + set_cont_address(uc, address(StubRoutines::continuation_for_safefetch_fault(pc))); > return true; > } > > -- Chris > >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 18. Juni 2013 22:44 >> To: Lindenmaier, Goetz >> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >> >> >> On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" wrote: >> >>> Ok, I will implement it on x86. >>> >>> To get a single change, you can give me the sparc patch, >>> or you extend the webrev once I updated it with the >>> x86 code. >> >> Sounds good. Let me know when it's there. >> >> -- Chris >> >>> If you prefer, you can also push it to some other repository, it >>> will end up in the ppc repo in time I guess. >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Tuesday, June 18, 2013 6:59 PM >>> To: Lindenmaier, Goetz >>> Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >>> >>> >>> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" wrote: >>> >>>> Hi, >>>> >>>> We have it on these platforms: >>>> ia64 (nt, linux, hp_ux) >>>> parisc (hp_ux) >>>> zArch (linux) >>>> ppc (aix, linux) >>>> >>>> I would implement it on x86 & friends, you do it on sparc and wherever >>>> else you like it? >>> >>> That sounds reasonable. Are we pushing this to the ppc repository then? >>> >>> -- Chris >>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> Sent: Dienstag, 18. Juni 2013 07:13 >>>> To: Volker Simonis >>>> Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >>>> >>>> >>>> On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: >>>> >>>>> Hi Goetz, >>>>> >>>>> I think the change is good and if the other reviewers don't decide to >>>>> implement it for the current platforms we can push it. >>>> >>>> I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? >>>> >>>> -- Chris >>>> >>>>> >>>>> By the way, the makefile changes in ppc64.make will follow in patch 8 for >>>>> linux [1] and patch 14 for aix [2]. >>>>> The implementation of the stubs will be in patch 9 for linux [3] and patch >>>>> 15 for aix [4] (only the signal handling part). >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>>>> [2] >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>>>> [3] >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>>>> [4] >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>>>> >>>>> >>>>> >>>>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>>>> goetz.lindenmaier at sap.com> wrote: >>>>> >>>>>> Hi,**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> the PPC64 port uses stub routines to implement safefetch. We had and**** >>>>>> >>>>>> have problems with inline assembly, especially with non-gcc**** >>>>>> >>>>>> compilers. Stub routines allow to implement safefetch without**** >>>>>> >>>>>> depending on OS or compiler, as it's the case with the current**** >>>>>> >>>>>> implementation. This also allows to use a single implementation if an**** >>>>>> >>>>>> architecture is supported on several os platforms.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Currently, we guard the code with **** >>>>>> >>>>>> #ifdef SAFEFETCH_STUBS**** >>>>>> >>>>>> which is set in ppc64.make.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> I could also imagine an implementation that uses a pd_debug flag**** >>>>>> >>>>>> or a const flag set in os_.hpp that allows the C-compiler to **** >>>>>> >>>>>> optimize, and writing the code like this:**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>>>> >>>>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >>>>>> * >>>>>> >>>>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>>>> >>>>>> if (UseSafefetchStub) {**** >>>>>> >>>>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >>>>>> * >>>>>> >>>>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>>>> >>>>>> } else {**** >>>>>> >>>>>> pd_SafeFetch32(adr, errValue);**** >>>>>> >>>>>> }**** >>>>>> >>>>>> }**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Unfortunately this requires **** >>>>>> >>>>>> 1) setting the flag on all platforms**** >>>>>> >>>>>> 2) renaming the safefetch function on all platfoms.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Actually I would prefer this second solution as it avoids the >>>>>> preprocessor, **** >>>>>> >>>>>> and am happy to edit the sources accordingly if this finds acceptance.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> For the implementation of a safefetch_stub see**** >>>>>> >>>>>> >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>> **** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Could I get a review on this change, please?**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Thanks,**** >>>>>> >>>>>> Goetz.**** >>>>>> >>>> >>> >> > From volker.simonis at gmail.com Tue Jul 2 00:56:09 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Jul 2013 09:56:09 +0200 Subject: RFR(XXS): 8019382 : PPC64: Fix bytecodeInterpreter to compile with '-Wunused-value' In-Reply-To: <51D1F0D4.5060308@oracle.com> References: <51D1EDA5.90002@oracle.com> <51D1F0D4.5060308@oracle.com> Message-ID: Great! Thanks a lot, Volker On Mon, Jul 1, 2013 at 11:12 PM, Vladimir Kozlov wrote: > Reviewed. > > I am pushing this into comp repo with me and Coleen as reviewers. > > Thanks, > Vladimir > > > On 7/1/13 1:59 PM, Coleen Phillimore wrote: >> >> >> Looks good. If you need someone to check it, I'll do it after you get >> another review. >> Coleen >> >> On 07/01/2013 12:28 PM, Volker Simonis wrote: >>> >>> Hi, >>> >>> this is a patch from the PowerPC/AIX porting project but it only >>> changes shared code and it fixes a build problem in the C++ >>> interpreter which also affects the Zero-Port so I would strongly >>> recommend to push it right into the hotspot repository. >>> >>> The problem is related to "8014431 : cleanup warnings indicated by the >>> -Wunused-value compiler option on linux" which added the >>> "-Wunused-value" option to the Linux build but did not clean up the >>> code in the c++ interpreter. This lead to several warnings which are >>> now treated as errors when compiling bytecodeInterpreter.cpp. >>> >>> The fix is easy - just cast the offending expressions to void: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8019382/ >>> >>> Thank you and best regards, >>> Volker >> >> > From goetz.lindenmaier at sap.com Tue Jul 2 01:41:16 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Jul 2013 08:41:16 +0000 Subject: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking In-Reply-To: <51CCB772.4010908@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEE181@DEWDFEMB12A.global.corp.sap> <51CB7A9A.9010307@oracle.com> <51CC2DAF.4050102@oracle.com> <51CCB772.4010908@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF140B@DEWDFEMB12A.global.corp.sap> Hi David, can I push this change now? Or will the files be moved? I prepared a webrev without the shared change: http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock-2/ Best regards, Goetz. -----Original Message----- From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Freitag, 28. Juni 2013 00:07 To: David Holmes Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking David, Do you insist on moving cppInterpreter files into separate directory? If yes, we need to do that in our main sources to avoid merges nightmare. And I will do the move. Thanks, Vladimir On 6/27/13 5:18 AM, David Holmes wrote: > Vladimir, > > On 27/06/2013 9:34 AM, Vladimir Kozlov wrote: >> Hi Goetz, >> >> On 6/26/13 7:30 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> To use biased locking in our PPC64 VM,we fixed the biased locking >>> implementation >>> in the cppInterpreter. We also added BiasedLockingStatistic support. >> >> Oracle does not use cppInterpreter and no building and testing are done. >> So we trust you to do testing of these changes. >> I glanced on these changes and they look fine to me. >> >> One suggestion I heard from David H. is to move cppInterpreter related >> files (all 6 of them) from interpreter/ directory to separate directory. >> So we can see when changes does not affect our shared code. > > It is a general source of confusion to new hotspot engineers that there > are actually two interpreters in one directory and that one is not used > by the historical primary ports. It also isn't obvious that > bytecodeInterpreter.cpp pertains to the cppInterpreter. > >>> We need an additional ordering operation in revoke_bias() when writing >>> the mark. >> >> Why you need ordering only for locked objects in this code? And why here >> at all? This code is executed at safepoint. > > There is one occurrence that is not executed at a safepoint - see > BiasedLocking::Condition BiasedLocking::revoke_and_rebias. Though it > seems to be operating only on current thread in that case. > > The use of release_set_mark seems consistent with other uses in > synchronizer.cpp. > > David > ----- > >> thanks, >> Vladimir >> >>> The change enables biased locking for ppc64 per default. >>> http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock/ >>> >>> Please review and test this change. >>> >>> Best regards, >>> Goetz >>> From mikael.gerdin at oracle.com Tue Jul 2 02:06:28 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 02 Jul 2013 11:06:28 +0200 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51CE0B83.90500@oracle.com> References: <51C32D25.8050408@oracle.com> <51C885E0.3000801@oracle.com> <51C88EA0.9090208@oracle.com> <51C89367.3080708@oracle.com> <51C8B428.3090507@oracle.com> <51CCE381.9010503@oracle.com> <51CDFEA8.2060800@oracle.com> <51CE0B83.90500@oracle.com> Message-ID: <51D29814.6010107@oracle.com> Coleen, On 2013-06-29 00:17, Coleen Phillimore wrote: > > Thanks Jon! Comments inline. > > On 6/28/2013 5:22 PM, Jon Masamitsu wrote: >> Coleen, >> >> http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/memory/metaspace.cpp.frames.html >> >>> 1301 // The reason for someone using this flag is to limit reserved >>> space. So >>> 1302 // for non-class virtual space that is what we compare >>> against. For class >>> 1303 // virtual space, we only compare against the used space, not >>> reserved space, >>> 1304 // because this is a larger region prereserved for compressed >>> class pointers. >>> 1305 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>> 1306 size_t real_allocated = >>> Metaspace::space_list()->virtual_space_total() + >>> 1307 Metaspace::class_space_list()->used_words_sum() * BytesPerWord; >>> 1308 if (real_allocated >= MaxMetaspaceSize) { >>> 1309 return false; >>> 1310 } >>> 1311 } >> >> At line 1307 the function used_words_sum() iterated over the virtual >> spaces. >> There are usually not that many virtual spaces but I think the iteration >> should still be avoided. I think you should use >> >> MetaspaceAux::allocated_capacity_bytes() >> >> In a virtual space any space that has been allocated to a Metaspace is >> considered "used". >> Not all that space holds Metadata yet. I think that corresponds to >> the "allocated_capacity_bytes()" >> above. That is the running sum (i.e. fast) of bytes allocated to a >> Metaspace. The allocated capacity >> also does not necessarily hold Metadata yet. The other choice would be >> MetaspaceAux::allocated_used_bytes() which is a running sum of the >> space which >> holds Metadata. Though it is a "used" quantity, I think it is >> different than the >> way "used" is in "used_words_sum". " used_words_sum()" should probably >> be renamed "allocated_words_sum()". But that's another clean up. > > You must have sent this new code to hotspot-gc when I wasn't watching. I > didn't notice the different running counts. So > allocated_capacity_bytes(Metaspace::ClassType) is how much space has > been allocated for chunks in the class metaspace. allocated_used_bytes() > is the running count of returned for class types. > > I think for comparison purposes to MaxMetaspaceSize, we want > capacity_bytes() because that's what is committed in the class virtual > space. So we use reserved(data_space) + committed(class_space) to > determine if the MaxMetaspaceSize is reached. I updated the comment > also (and reran the tests). > > See version 3 > > http://cr.openjdk.java.net/~coleenp/8015391_3/ > This looks good to me. /Mikael > >> >> http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/runtime/vmStructs.cpp.frames.html >> >> >> Why the delete of entries and not changing perm to Metadata named >> variables? I'm not >> challenging your change, just trying to learn about such things. > > We pass these objects to the serviceability agent but it never used > them, so I decided to not pass these things. The SA doesn't need to > know which exceptions we've preallocated. > > Coleen > >> >> Jon >> >> >> >> >> On 6/27/2013 6:14 PM, Coleen Phillimore wrote: >>> >>> Hi, I have made a few changes to this changeset. I reverted the >>> special case for application class loader until we have more tuning >>> information to decide how large this metaspace should be. I also >>> fixed the check in should_expand so that if you specify >>> MaxMetaspaceSize, it compares the MaxMetaspaceSize to (reserved for >>> data space + used for class space). So the test in the bug report >>> runs with the smaller sizes for MaxMetaspaceSize and also for smaller >>> ClassMetaspaceSize without hitting OOM for either sort of space. Hope >>> the comment there is clear. >>> >>> http://cr.openjdk.java.net/~coleenp/8015391_2/ >>> >>> >>> Reran nsk quick testlist and some jtreg tests. Please (re)review. >>> >>> Thanks, >>> Coleen >>> >>> On 6/24/2013 5:03 PM, Coleen Phillimore wrote: >>>> >>>> On 06/24/2013 02:43 PM, Jon Masamitsu wrote: >>>>> >>>>> On 6/24/13 11:23 AM, Coleen Phillimore wrote: >>>>>> >>>>>> On 06/24/2013 01:46 PM, Jon Masamitsu wrote: >>>>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html >>>>>>> >>>>>>> >>>>>>>> 2673 size_t specialized_count = 0, small_count = 0, >>>>>>>> medium_count = 0, large_count = 0; >>>>>>>> 2675 size_t cls_specialized_count = 0, cls_small_count = 0, >>>>>>>> cls_medium_count = 0, cls_large_count = 0; >>>>>>> >>>>>>> Not introduced by your change but >>>>>>> >>>>>>> humongous_count instead of large_count >>>>>>> and >>>>>>> cls_humongous_count instead of cls_large_count >>>>>>> >>>>>>> would be more consistent. >>>>>> >>>>>> Yes, it is. I changed it. >>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> I'd suggest adding Metaspace::AppClassMetaspaceType >>>>>>>> 385 } else if >>>>>>>> (SystemDictionary::is_app_class_loader(class_loader())) { >>>>>>>> 386 if (TraceClassLoaderData && Verbose && >>>>>>>> class_loader() != NULL) { >>>>>>>> 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class >>>>>>>> loader"); >>>>>>>> 388 } >>>>>>>> 389 set_metaspace(new Metaspace(_metaspace_lock, >>>>>>>> Metaspace::BootMetaspaceType)); >>>>>>> and adding a flag InitialAppClassLoaderMetaspaceSize. It's not >>>>>>> obvious to me >>>>>>> that we should always be reserving the same amount of space for >>>>>>> the AppClassLoader >>>>>>> as the BootClassLoader. The same default is OK with me. >>>>>> >>>>>> Hmm. Ok. I don't like adding new flags, so can I add an >>>>>> AppMetaspaceType and give it the same initial size as >>>>>> BootMetaspaceSize until proven that it doesn't need to be the same >>>>>> size. >>>>> >>>>> With the BootClassLoader the space for the initial Metaspace is >>>>> committed >>>>> when the first system class is loaded. The same would be true for any >>>>> Java application (all have some type of AppLoader, right)? We know >>>>> we're >>>>> going to use the space committed for the BootClassLoader >>>>> Metaspace. Are >>>>> we going to get yelled at for committing 4m and not using it. >>>>>> >>>>>> I suppose adding an AppMetaspaceInitialSize flag will give me more >>>>>> to talk about at the Permgen Elimination JavaOne talk though (but >>>>>> I'd still rather not). >>>>> >>>>> When you have 100000000000000000 flags, who's going to >>>>> notice the 100000000000000001-st :-) >>>> >>>> Okay, you convinced me to revert this part of the change. It >>>> wasn't necessary to make this stress test finish and there hasn't >>>> been very much tuning for "normal" application classes, just a >>>> suspicion of mine. >>>> >>>> Committing an extra 4m might be bad for embedded platforms. >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Jon >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Rest looks good. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> >>>>>>> On 6/20/13 9:26 AM, Coleen Phillimore wrote: >>>>>>>> Summary: Allocate medium chunks for class metaspace when class >>>>>>>> loader has lots of classes >>>>>>>> >>>>>>>> I originally made class metaspace keep small chunks and not >>>>>>>> start allocating from medium chunks, because I thought with only >>>>>>>> Klass objects, small chunks is enough. This test has a large >>>>>>>> set of class loaders who have a lot of classes, so allocated >>>>>>>> thousands of small chunks each. Class loaders with that many >>>>>>>> classes should start allocating from medium chunks, for class >>>>>>>> metaspace. >>>>>>>> >>>>>>>> I also increased the ClassMediumChunk size to 4k and measured a >>>>>>>> lot less fragmentation waste than 1K or 2K for this test. >>>>>>>> Lastly, the AppClassLoader instance should have as large of an >>>>>>>> initial metaspace as the bootclass loader. >>>>>>>> >>>>>>>> Tested with vm.quick.testlist and the failing test. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ >>>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >>>>>>>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From goetz.lindenmaier at sap.com Tue Jul 2 02:47:46 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Jul 2013 09:47:46 +0000 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <51D20DEC.7050904@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDBDE@DEWDFEMB12A.global.corp.sap> <51D20DEC.7050904@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF1499@DEWDFEMB12A.global.corp.sap> Hi, Sorry for that, I didn't grok the comment. The alignment is a good idea. Fixed: http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Dienstag, 2. Juli 2013 01:17 To: Lindenmaier, Goetz Cc: 'Christian Thalinger'; 'Albert Noll (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch Goetz, Why you did not add 'nop' between load and return instructions on sparc? It was in assembler in .s file. The next comment said we need it: !! By convention with the trap handler we ensure there is a non-CTI !! instruction in the trap shadow. Also should we align code in stubs to keep it in one cache line? __ align(CodeEntryAlignment); *entry = __ pc(); Thanks, Vladimir On 6/24/13 12:31 PM, Lindenmaier, Goetz wrote: > Hi, > > you are right, the check is redundant. > I removed it and updated the webrev and also based it on the > recent staging repo: > http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ > > Best regards, > Goetz. > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Monday, June 24, 2013 7:48 PM > To: Lindenmaier, Goetz > Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > > On Jun 20, 2013, at 7:01 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> I implemented the safefetch stubs for x86 and sparc (was quiet simple). >> This way I could clean up the #define right away. >> >> I tested it thouroughly on >> x86_64: bsd, nt, linux, solaris >> x86_32: nt, linux >> by adding it into our internal VM. >> Tonight I will get build/test on >> sparc_64 solaris >> sparc_32 solaris >> x86_64 nt, linux >> with the openjdk ppc port, but I tested that before submitting in a smaller >> extend, too. >> >> Here the webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ > > I like this change. It removes a lot of duplication. One comment: > > + static bool is_safefetch_fault(address pc) { > + return pc != NULL && > + (pc == _safefetch32_fault_pc || > + pc == _safefetchN_fault_pc); > + } > > checks for pc != null. Should we remove the check here? > > + if (pc && StubRoutines::is_safefetch_fault(pc)) { > + set_cont_address(uc, address(StubRoutines::continuation_for_safefetch_fault(pc))); > return true; > } > > -- Chris > >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 18. Juni 2013 22:44 >> To: Lindenmaier, Goetz >> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >> >> >> On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" wrote: >> >>> Ok, I will implement it on x86. >>> >>> To get a single change, you can give me the sparc patch, >>> or you extend the webrev once I updated it with the >>> x86 code. >> >> Sounds good. Let me know when it's there. >> >> -- Chris >> >>> If you prefer, you can also push it to some other repository, it >>> will end up in the ppc repo in time I guess. >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Tuesday, June 18, 2013 6:59 PM >>> To: Lindenmaier, Goetz >>> Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >>> >>> >>> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" wrote: >>> >>>> Hi, >>>> >>>> We have it on these platforms: >>>> ia64 (nt, linux, hp_ux) >>>> parisc (hp_ux) >>>> zArch (linux) >>>> ppc (aix, linux) >>>> >>>> I would implement it on x86 & friends, you do it on sparc and wherever >>>> else you like it? >>> >>> That sounds reasonable. Are we pushing this to the ppc repository then? >>> >>> -- Chris >>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> Sent: Dienstag, 18. Juni 2013 07:13 >>>> To: Volker Simonis >>>> Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >>>> >>>> >>>> On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: >>>> >>>>> Hi Goetz, >>>>> >>>>> I think the change is good and if the other reviewers don't decide to >>>>> implement it for the current platforms we can push it. >>>> >>>> I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? >>>> >>>> -- Chris >>>> >>>>> >>>>> By the way, the makefile changes in ppc64.make will follow in patch 8 for >>>>> linux [1] and patch 14 for aix [2]. >>>>> The implementation of the stubs will be in patch 9 for linux [3] and patch >>>>> 15 for aix [4] (only the signal handling part). >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>>>> [2] >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>>>> [3] >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>>>> [4] >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>>>> >>>>> >>>>> >>>>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>>>> goetz.lindenmaier at sap.com> wrote: >>>>> >>>>>> Hi,**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> the PPC64 port uses stub routines to implement safefetch. We had and**** >>>>>> >>>>>> have problems with inline assembly, especially with non-gcc**** >>>>>> >>>>>> compilers. Stub routines allow to implement safefetch without**** >>>>>> >>>>>> depending on OS or compiler, as it's the case with the current**** >>>>>> >>>>>> implementation. This also allows to use a single implementation if an**** >>>>>> >>>>>> architecture is supported on several os platforms.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Currently, we guard the code with **** >>>>>> >>>>>> #ifdef SAFEFETCH_STUBS**** >>>>>> >>>>>> which is set in ppc64.make.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> I could also imagine an implementation that uses a pd_debug flag**** >>>>>> >>>>>> or a const flag set in os_.hpp that allows the C-compiler to **** >>>>>> >>>>>> optimize, and writing the code like this:**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>>>> >>>>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >>>>>> * >>>>>> >>>>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>>>> >>>>>> if (UseSafefetchStub) {**** >>>>>> >>>>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >>>>>> * >>>>>> >>>>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>>>> >>>>>> } else {**** >>>>>> >>>>>> pd_SafeFetch32(adr, errValue);**** >>>>>> >>>>>> }**** >>>>>> >>>>>> }**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Unfortunately this requires **** >>>>>> >>>>>> 1) setting the flag on all platforms**** >>>>>> >>>>>> 2) renaming the safefetch function on all platfoms.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Actually I would prefer this second solution as it avoids the >>>>>> preprocessor, **** >>>>>> >>>>>> and am happy to edit the sources accordingly if this finds acceptance.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> For the implementation of a safefetch_stub see**** >>>>>> >>>>>> >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>> **** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Could I get a review on this change, please?**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Thanks,**** >>>>>> >>>>>> Goetz.**** >>>>>> >>>> >>> >> > From david.holmes at oracle.com Tue Jul 2 04:37:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jul 2013 21:37:01 +1000 Subject: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF140B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEE181@DEWDFEMB12A.global.corp.sap> <51CB7A9A.9010307@oracle.com> <51CC2DAF.4050102@oracle.com> <51CCB772.4010908@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF140B@DEWDFEMB12A.global.corp.sap> Message-ID: <51D2BB5D.2010202@oracle.com> Sorry I've been in and out of the office this past week. I think the move should happen - but whether that is easier to do before or after I can't say. I'll leave it to Vladimir to make the call. David ----- On 2/07/2013 6:41 PM, Lindenmaier, Goetz wrote: > Hi David, > > can I push this change now? Or will the files be moved? > I prepared a webrev without the shared change: > http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock-2/ > > Best regards, > Goetz. > > > -----Original Message----- > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Freitag, 28. Juni 2013 00:07 > To: David Holmes > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking > > David, > > Do you insist on moving cppInterpreter files into separate directory? If > yes, we need to do that in our main sources to avoid merges nightmare. > And I will do the move. > > Thanks, > Vladimir > > On 6/27/13 5:18 AM, David Holmes wrote: >> Vladimir, >> >> On 27/06/2013 9:34 AM, Vladimir Kozlov wrote: >>> Hi Goetz, >>> >>> On 6/26/13 7:30 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> To use biased locking in our PPC64 VM,we fixed the biased locking >>>> implementation >>>> in the cppInterpreter. We also added BiasedLockingStatistic support. >>> >>> Oracle does not use cppInterpreter and no building and testing are done. >>> So we trust you to do testing of these changes. >>> I glanced on these changes and they look fine to me. >>> >>> One suggestion I heard from David H. is to move cppInterpreter related >>> files (all 6 of them) from interpreter/ directory to separate directory. >>> So we can see when changes does not affect our shared code. >> >> It is a general source of confusion to new hotspot engineers that there >> are actually two interpreters in one directory and that one is not used >> by the historical primary ports. It also isn't obvious that >> bytecodeInterpreter.cpp pertains to the cppInterpreter. >> >>>> We need an additional ordering operation in revoke_bias() when writing >>>> the mark. >>> >>> Why you need ordering only for locked objects in this code? And why here >>> at all? This code is executed at safepoint. >> >> There is one occurrence that is not executed at a safepoint - see >> BiasedLocking::Condition BiasedLocking::revoke_and_rebias. Though it >> seems to be operating only on current thread in that case. >> >> The use of release_set_mark seems consistent with other uses in >> synchronizer.cpp. >> >> David >> ----- >> >>> thanks, >>> Vladimir >>> >>>> The change enables biased locking for ppc64 per default. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock/ >>>> >>>> Please review and test this change. >>>> >>>> Best regards, >>>> Goetz >>>> From coleen.phillimore at oracle.com Tue Jul 2 05:39:39 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 02 Jul 2013 08:39:39 -0400 Subject: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF140B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEE181@DEWDFEMB12A.global.corp.sap> <51CB7A9A.9010307@oracle.com> <51CC2DAF.4050102@oracle.com> <51CCB772.4010908@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF140B@DEWDFEMB12A.global.corp.sap> Message-ID: <51D2CA0B.9050302@oracle.com> For the record, I don't think the bytecodeInterpreter files should be moved. They are fine where they are and it reminds us to consider the c++ interpreter when making interpreter changes. And the directory doesn't have too many files in it. Coleen On 07/02/2013 04:41 AM, Lindenmaier, Goetz wrote: > Hi David, > > can I push this change now? Or will the files be moved? > I prepared a webrev without the shared change: > http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock-2/ > > Best regards, > Goetz. > > > -----Original Message----- > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Freitag, 28. Juni 2013 00:07 > To: David Holmes > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking > > David, > > Do you insist on moving cppInterpreter files into separate directory? If > yes, we need to do that in our main sources to avoid merges nightmare. > And I will do the move. > > Thanks, > Vladimir > > On 6/27/13 5:18 AM, David Holmes wrote: >> Vladimir, >> >> On 27/06/2013 9:34 AM, Vladimir Kozlov wrote: >>> Hi Goetz, >>> >>> On 6/26/13 7:30 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> To use biased locking in our PPC64 VM,we fixed the biased locking >>>> implementation >>>> in the cppInterpreter. We also added BiasedLockingStatistic support. >>> Oracle does not use cppInterpreter and no building and testing are done. >>> So we trust you to do testing of these changes. >>> I glanced on these changes and they look fine to me. >>> >>> One suggestion I heard from David H. is to move cppInterpreter related >>> files (all 6 of them) from interpreter/ directory to separate directory. >>> So we can see when changes does not affect our shared code. >> It is a general source of confusion to new hotspot engineers that there >> are actually two interpreters in one directory and that one is not used >> by the historical primary ports. It also isn't obvious that >> bytecodeInterpreter.cpp pertains to the cppInterpreter. >> >>>> We need an additional ordering operation in revoke_bias() when writing >>>> the mark. >>> Why you need ordering only for locked objects in this code? And why here >>> at all? This code is executed at safepoint. >> There is one occurrence that is not executed at a safepoint - see >> BiasedLocking::Condition BiasedLocking::revoke_and_rebias. Though it >> seems to be operating only on current thread in that case. >> >> The use of release_set_mark seems consistent with other uses in >> synchronizer.cpp. >> >> David >> ----- >> >>> thanks, >>> Vladimir >>> >>>> The change enables biased locking for ppc64 per default. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock/ >>>> >>>> Please review and test this change. >>>> >>>> Best regards, >>>> Goetz >>>> From coleen.phillimore at oracle.com Tue Jul 2 05:40:17 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 02 Jul 2013 08:40:17 -0400 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51D29814.6010107@oracle.com> References: <51C32D25.8050408@oracle.com> <51C885E0.3000801@oracle.com> <51C88EA0.9090208@oracle.com> <51C89367.3080708@oracle.com> <51C8B428.3090507@oracle.com> <51CCE381.9010503@oracle.com> <51CDFEA8.2060800@oracle.com> <51CE0B83.90500@oracle.com> <51D29814.6010107@oracle.com> Message-ID: <51D2CA31.90808@oracle.com> Thanks Mikael for the review and all the help on this change! Coleen On 07/02/2013 05:06 AM, Mikael Gerdin wrote: > Coleen, > > On 2013-06-29 00:17, Coleen Phillimore wrote: >> >> Thanks Jon! Comments inline. >> >> On 6/28/2013 5:22 PM, Jon Masamitsu wrote: >>> Coleen, >>> >>> http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/memory/metaspace.cpp.frames.html >>> >>> >>>> 1301 // The reason for someone using this flag is to limit reserved >>>> space. So >>>> 1302 // for non-class virtual space that is what we compare >>>> against. For class >>>> 1303 // virtual space, we only compare against the used space, not >>>> reserved space, >>>> 1304 // because this is a larger region prereserved for compressed >>>> class pointers. >>>> 1305 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>>> 1306 size_t real_allocated = >>>> Metaspace::space_list()->virtual_space_total() + >>>> 1307 Metaspace::class_space_list()->used_words_sum() * BytesPerWord; >>>> 1308 if (real_allocated >= MaxMetaspaceSize) { >>>> 1309 return false; >>>> 1310 } >>>> 1311 } >>> >>> At line 1307 the function used_words_sum() iterated over the virtual >>> spaces. >>> There are usually not that many virtual spaces but I think the >>> iteration >>> should still be avoided. I think you should use >>> >>> MetaspaceAux::allocated_capacity_bytes() >>> >>> In a virtual space any space that has been allocated to a Metaspace is >>> considered "used". >>> Not all that space holds Metadata yet. I think that corresponds to >>> the "allocated_capacity_bytes()" >>> above. That is the running sum (i.e. fast) of bytes allocated to a >>> Metaspace. The allocated capacity >>> also does not necessarily hold Metadata yet. The other choice would be >>> MetaspaceAux::allocated_used_bytes() which is a running sum of the >>> space which >>> holds Metadata. Though it is a "used" quantity, I think it is >>> different than the >>> way "used" is in "used_words_sum". " used_words_sum()" should probably >>> be renamed "allocated_words_sum()". But that's another clean up. >> >> You must have sent this new code to hotspot-gc when I wasn't watching. I >> didn't notice the different running counts. So >> allocated_capacity_bytes(Metaspace::ClassType) is how much space has >> been allocated for chunks in the class metaspace. allocated_used_bytes() >> is the running count of returned for class types. >> >> I think for comparison purposes to MaxMetaspaceSize, we want >> capacity_bytes() because that's what is committed in the class virtual >> space. So we use reserved(data_space) + committed(class_space) to >> determine if the MaxMetaspaceSize is reached. I updated the comment >> also (and reran the tests). >> >> See version 3 >> >> http://cr.openjdk.java.net/~coleenp/8015391_3/ >> > > This looks good to me. > /Mikael > >> >>> >>> http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/runtime/vmStructs.cpp.frames.html >>> >>> >>> >>> Why the delete of entries and not changing perm to Metadata named >>> variables? I'm not >>> challenging your change, just trying to learn about such things. >> >> We pass these objects to the serviceability agent but it never used >> them, so I decided to not pass these things. The SA doesn't need to >> know which exceptions we've preallocated. >> >> Coleen >> >>> >>> Jon >>> >>> >>> >>> >>> On 6/27/2013 6:14 PM, Coleen Phillimore wrote: >>>> >>>> Hi, I have made a few changes to this changeset. I reverted the >>>> special case for application class loader until we have more tuning >>>> information to decide how large this metaspace should be. I also >>>> fixed the check in should_expand so that if you specify >>>> MaxMetaspaceSize, it compares the MaxMetaspaceSize to (reserved for >>>> data space + used for class space). So the test in the bug report >>>> runs with the smaller sizes for MaxMetaspaceSize and also for smaller >>>> ClassMetaspaceSize without hitting OOM for either sort of space. Hope >>>> the comment there is clear. >>>> >>>> http://cr.openjdk.java.net/~coleenp/8015391_2/ >>>> >>>> >>>> Reran nsk quick testlist and some jtreg tests. Please (re)review. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 6/24/2013 5:03 PM, Coleen Phillimore wrote: >>>>> >>>>> On 06/24/2013 02:43 PM, Jon Masamitsu wrote: >>>>>> >>>>>> On 6/24/13 11:23 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> On 06/24/2013 01:46 PM, Jon Masamitsu wrote: >>>>>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 2673 size_t specialized_count = 0, small_count = 0, >>>>>>>>> medium_count = 0, large_count = 0; >>>>>>>>> 2675 size_t cls_specialized_count = 0, cls_small_count = 0, >>>>>>>>> cls_medium_count = 0, cls_large_count = 0; >>>>>>>> >>>>>>>> Not introduced by your change but >>>>>>>> >>>>>>>> humongous_count instead of large_count >>>>>>>> and >>>>>>>> cls_humongous_count instead of cls_large_count >>>>>>>> >>>>>>>> would be more consistent. >>>>>>> >>>>>>> Yes, it is. I changed it. >>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I'd suggest adding Metaspace::AppClassMetaspaceType >>>>>>>>> 385 } else if >>>>>>>>> (SystemDictionary::is_app_class_loader(class_loader())) { >>>>>>>>> 386 if (TraceClassLoaderData && Verbose && >>>>>>>>> class_loader() != NULL) { >>>>>>>>> 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class >>>>>>>>> loader"); >>>>>>>>> 388 } >>>>>>>>> 389 set_metaspace(new Metaspace(_metaspace_lock, >>>>>>>>> Metaspace::BootMetaspaceType)); >>>>>>>> and adding a flag InitialAppClassLoaderMetaspaceSize. It's not >>>>>>>> obvious to me >>>>>>>> that we should always be reserving the same amount of space for >>>>>>>> the AppClassLoader >>>>>>>> as the BootClassLoader. The same default is OK with me. >>>>>>> >>>>>>> Hmm. Ok. I don't like adding new flags, so can I add an >>>>>>> AppMetaspaceType and give it the same initial size as >>>>>>> BootMetaspaceSize until proven that it doesn't need to be the same >>>>>>> size. >>>>>> >>>>>> With the BootClassLoader the space for the initial Metaspace is >>>>>> committed >>>>>> when the first system class is loaded. The same would be true >>>>>> for any >>>>>> Java application (all have some type of AppLoader, right)? We know >>>>>> we're >>>>>> going to use the space committed for the BootClassLoader >>>>>> Metaspace. Are >>>>>> we going to get yelled at for committing 4m and not using it. >>>>>>> >>>>>>> I suppose adding an AppMetaspaceInitialSize flag will give me more >>>>>>> to talk about at the Permgen Elimination JavaOne talk though (but >>>>>>> I'd still rather not). >>>>>> >>>>>> When you have 100000000000000000 flags, who's going to >>>>>> notice the 100000000000000001-st :-) >>>>> >>>>> Okay, you convinced me to revert this part of the change. It >>>>> wasn't necessary to make this stress test finish and there hasn't >>>>> been very much tuning for "normal" application classes, just a >>>>> suspicion of mine. >>>>> >>>>> Committing an extra 4m might be bad for embedded platforms. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Jon >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> Rest looks good. >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> >>>>>>>> On 6/20/13 9:26 AM, Coleen Phillimore wrote: >>>>>>>>> Summary: Allocate medium chunks for class metaspace when class >>>>>>>>> loader has lots of classes >>>>>>>>> >>>>>>>>> I originally made class metaspace keep small chunks and not >>>>>>>>> start allocating from medium chunks, because I thought with only >>>>>>>>> Klass objects, small chunks is enough. This test has a large >>>>>>>>> set of class loaders who have a lot of classes, so allocated >>>>>>>>> thousands of small chunks each. Class loaders with that many >>>>>>>>> classes should start allocating from medium chunks, for class >>>>>>>>> metaspace. >>>>>>>>> >>>>>>>>> I also increased the ClassMediumChunk size to 4k and measured a >>>>>>>>> lot less fragmentation waste than 1K or 2K for this test. >>>>>>>>> Lastly, the AppClassLoader instance should have as large of an >>>>>>>>> initial metaspace as the bootclass loader. >>>>>>>>> >>>>>>>>> Tested with vm.quick.testlist and the failing test. >>>>>>>>> >>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ >>>>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >>>>>>>>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From vladimir.kozlov at oracle.com Tue Jul 2 07:42:12 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Jul 2013 07:42:12 -0700 Subject: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking In-Reply-To: <51D2BB5D.2010202@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEE181@DEWDFEMB12A.global.corp.sap> <51CB7A9A.9010307@oracle.com> <51CC2DAF.4050102@oracle.com> <51CCB772.4010908@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF140B@DEWDFEMB12A.global.corp.sap> <51D2BB5D.2010202@oracle.com> Message-ID: <51D2E6C4.1020205@oracle.com> It looks like we need to discuss about the move inside hotspot team since not everyone agree. So if we do that we do it later. Goetz, you can push your changes. Thanks, Vladimir On 7/2/13 4:37 AM, David Holmes wrote: > Sorry I've been in and out of the office this past week. > > I think the move should happen - but whether that is easier to do before or after I can't say. I'll leave it to Vladimir > to make the call. > > David > ----- > > On 2/07/2013 6:41 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> can I push this change now? Or will the files be moved? >> I prepared a webrev without the shared change: >> http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock-2/ >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >> Vladimir Kozlov >> Sent: Freitag, 28. Juni 2013 00:07 >> To: David Holmes >> Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking >> >> David, >> >> Do you insist on moving cppInterpreter files into separate directory? If >> yes, we need to do that in our main sources to avoid merges nightmare. >> And I will do the move. >> >> Thanks, >> Vladimir >> >> On 6/27/13 5:18 AM, David Holmes wrote: >>> Vladimir, >>> >>> On 27/06/2013 9:34 AM, Vladimir Kozlov wrote: >>>> Hi Goetz, >>>> >>>> On 6/26/13 7:30 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> To use biased locking in our PPC64 VM,we fixed the biased locking >>>>> implementation >>>>> in the cppInterpreter. We also added BiasedLockingStatistic support. >>>> >>>> Oracle does not use cppInterpreter and no building and testing are done. >>>> So we trust you to do testing of these changes. >>>> I glanced on these changes and they look fine to me. >>>> >>>> One suggestion I heard from David H. is to move cppInterpreter related >>>> files (all 6 of them) from interpreter/ directory to separate directory. >>>> So we can see when changes does not affect our shared code. >>> >>> It is a general source of confusion to new hotspot engineers that there >>> are actually two interpreters in one directory and that one is not used >>> by the historical primary ports. It also isn't obvious that >>> bytecodeInterpreter.cpp pertains to the cppInterpreter. >>> >>>>> We need an additional ordering operation in revoke_bias() when writing >>>>> the mark. >>>> >>>> Why you need ordering only for locked objects in this code? And why here >>>> at all? This code is executed at safepoint. >>> >>> There is one occurrence that is not executed at a safepoint - see >>> BiasedLocking::Condition BiasedLocking::revoke_and_rebias. Though it >>> seems to be operating only on current thread in that case. >>> >>> The use of release_set_mark seems consistent with other uses in >>> synchronizer.cpp. >>> >>> David >>> ----- >>> >>>> thanks, >>>> Vladimir >>>> >>>>> The change enables biased locking for ppc64 per default. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock/ >>>>> >>>>> Please review and test this change. >>>>> >>>>> Best regards, >>>>> Goetz >>>>> From stefan.karlsson at oracle.com Tue Jul 2 09:57:00 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 02 Jul 2013 18:57:00 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() Message-ID: <51D3065C.6090401@oracle.com> http://cr.openjdk.java.net/~stefank/8007074/webrev.00/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007074 The default way of using Large Pages in HotSpot on Linux (UseHugeTLBFS) is broken. This is causing a number of crashes in different subsystems of the JVM. Bug Description =============== The main reason for this bug is that mmap(addr, size, ... MAP_FIXED|MAP_HUGETLB ...) will remove the previous mapping at [addr, addr+size) when we run out of large pages on Linux. This affects different parts of the JVM, but the most obvious is the allocation of the Java heap: When the JVM starts it reserves a memory area for the entire Java heap. We use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk of memory that no other subsystem of the JVM, or Java program, will be allowed to mmap into. The reservation of the memory only reflects the maximum possible heap size, but often a smaller heap size is used if the memory pressure is low. The part of the heap that is actually used is committed with mmap(...MAP_FIXED...). When the heap is growing we commit a consecutive chunk of memory after the previously committed memory. We rely on the fact that no other thread will mmap into the reserved memory area for the Java heap. The actual committing of the memory is done by first trying to allocate large pages with mmap(...MAP_FIXED|MAP_HUGETLB...), and if that fails we call mmap with the same parameters but without the large pages flag (MAP_HUGETLB). Just after we have failed to mmap large pages and before the small pages have been mmapped, there's an unmapped memory region in the middle of the Java heap, where other threads might mmap into. When that happens we get memory trashing and crashes. Large Pages in HotSpot - on Linux ================================= Currently, before the bug fix, HotSpot supports three ways of allocating large pages on Linux. 1) -XX:+UseSHM - Commits the large pages upfront when the memory is reserved. 2) -XX:+UseHugeTLBFS - This is the broken implementation. It's also the default way large pages are allocated. If the OS is correctly configured, we get these kind of large pages for three different reasons: 2.1) The user has not specified any large pages flags 2.2) The user has specified -XX:+UseLargePages 2.3) The user has specified -XX:+UseHugeTLBFS 3) Transparent Huge Pages - is supported on recent Linux Kernels. The user can choose to configure the OS to: 3.1) completely handle the allocation of large pages, or 3.2) let the JVM advise where it would be good to allocate large pages. There exist code for this today, that is guarded by the (2) -XX:+UseHugeTLBFS flag. The Proposed Patch ================== 4) Create a new flag -XX:+UseTransparentHugePages, and move the transparent huge pages advise in (3.2) out from the (2) -XX:+UseHugeTLBFS code. 5) Make -XX:+UseTransparentHugePages the default way to allocate large pages if the OS supports them. It will be the only kind of large pages we'll use if the user has not specified any large pages flags. 6) Change the order of how we choose the kind of large pages when -XX:+UseLargePages has been specified. It used to be UseHugeTLBFS then UseSHM, now it's UseTransparentHugePages, then UseHugeTLBFS, then UseSHM. 7) Implement a workaround fix for the (2) -XX:+UseHugeTLBFS implementation. With the fix the large pages are committed upfront when they are reserved. It's mostly the same way we do it for the older (1) -XX:+UseSHM large pages. This change will fix the bug, but has a couple of drawbacks: 7.1) We have to allocate the entire large pages memory area when it is reserved instead of when parts of it are committed. 7.2) We can't dynamically shrink or grow the used memory in the large pages areas. If these restrictions are not suitable for the user, then (3) -XX:+UseTransparentHugePages could be used instead. 8) Ignore -XX:LargePageSizeInBytes on Linux since the OS doesn't support multiple large page sizes and both the old code and new code is broken if the user is allowed to set it to some other value then the OS chosen value. Warn if the user specifies a value different than the OS default value. Testing ======= New unit tests have been added. These can be run in a non-product build with: java -XX:+ExecuteInternalVMTests -XX:+VerboseInternalVMTests -version unit tests: with and without large pages on Linux, Windows, Solaris, x86, x64, sparcv9. jprt: default jprt: -XX:+UseLargePages jprt: -XX:+UseLargePages -XX:-UseCompressedOops vm.quick.testlist, vm.pcl.testlist, vm.gc.testlist: multiple platforms, with large pages on all major GCs with and without compressed oops. SPECjbb2005 performance runs: on Linux x64 with -XX:+UseHugeTLBFS before and after the patch. Kitchensink: 3 days on Linux x64 thanks, StefanK From christian.thalinger at oracle.com Tue Jul 2 13:33:29 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Jul 2013 13:33:29 -0700 Subject: RFR (XS): 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs Message-ID: http://cr.openjdk.java.net/~twisti/8019184/webrev/ 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs Reviewed-by: The bug seems to be in MethodHandlesImpl.makeGuardWithCatch using ValueConversions.varargsArray: return makeCollectArguments(ginvoker, ValueConversions.varargsArray(nargs), 0, false); ValueConversions.varargsArray returns a MethodHandle which's type is: MethodHandle(Object,Object,Object,Object,Object,Object,Object,Object,Object)Object[] It doesn't preserve the trailing Object[]. The fix is to call makePairwiseConvert on the result of makeCollectArguments. src/share/classes/java/lang/invoke/MethodHandleImpl.java test/java/lang/invoke/TestCatchExceptionWithVarargs.java From john.r.rose at oracle.com Tue Jul 2 14:04:51 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Jul 2013 14:04:51 -0700 Subject: RFR (XS): 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs In-Reply-To: References: Message-ID: <0CFD47F8-4D3B-421F-A125-05A0916B35B8@oracle.com> Good fix, good test. Suggestions for the test: Change e.printStackTrace() to throw new AssertionError(e), to get earlier detection of config error. Suggest using a more specific type than Exception, maybe even a specific instance (like firstArg), to rule out interference from accidental errors. Then detect the caught exception in the handler, before returning the desired value. Suggest defining MAX_ARITY (MAX_MH_ARITY?) more categorically as 254, with a comment. Then have the loop go up to MAX_ARITY-1 with a comment, or put a break at the bottom of the loop body: if (handlerWithArgs.type().parameterCount() == MAX_MH_ARITY) break; // no more cases possible As we have seen, arity limits are hard to reason about! (Instead of dropArgs you could use something like MethodType.methodType(Object.class, Exception.class, ptypes.toArray()).) ? John On Jul 2, 2013, at 1:33 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8019184/webrev/ > > 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs > Reviewed-by: > > The bug seems to be in MethodHandlesImpl.makeGuardWithCatch using ValueConversions.varargsArray: > > return makeCollectArguments(ginvoker, ValueConversions.varargsArray(nargs), 0, false); > > ValueConversions.varargsArray returns a MethodHandle which's type is: > > MethodHandle(Object,Object,Object,Object,Object,Object,Object,Object,Object)Object[] > > It doesn't preserve the trailing Object[]. > > The fix is to call makePairwiseConvert on the result of makeCollectArguments. > > src/share/classes/java/lang/invoke/MethodHandleImpl.java > test/java/lang/invoke/TestCatchExceptionWithVarargs.java > From christian.thalinger at oracle.com Tue Jul 2 14:50:34 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Jul 2013 14:50:34 -0700 Subject: RFR (XS): 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs In-Reply-To: <0CFD47F8-4D3B-421F-A125-05A0916B35B8@oracle.com> References: <0CFD47F8-4D3B-421F-A125-05A0916B35B8@oracle.com> Message-ID: <0CE13E66-7A6D-47C4-9023-A897D541F018@oracle.com> On Jul 2, 2013, at 2:04 PM, John Rose wrote: > Good fix, good test. > > Suggestions for the test: > > Change e.printStackTrace() to throw new AssertionError(e), to get earlier detection of config error. Done. > > Suggest using a more specific type than Exception, maybe even a specific instance (like firstArg), to rule out interference from accidental errors. Then detect the caught exception in the handler, before returning the desired value. It seems to be part of the magic that the exception doesn't end up in the handler so I can't check for the exception instance. > > Suggest defining MAX_ARITY (MAX_MH_ARITY?) more categorically as 254, with a comment. Then have the loop go up to MAX_ARITY-1 with a comment, or put a break at the bottom of the loop body: > if (handlerWithArgs.type().parameterCount() == MAX_MH_ARITY) break; // no more cases possible Done. > > As we have seen, arity limits are hard to reason about! > > (Instead of dropArgs you could use something like MethodType.methodType(Object.class, Exception.class, ptypes.toArray()).) This doesn't work because ptypes.toArray() returns an Object[] and I think that the drop is also part of the magic. (I have engineered this test after the test case of the bug report.) Anyway, here is an updated webrev: http://cr.openjdk.java.net/~twisti/8019184/webrev/ -- Chris > > ? John > > On Jul 2, 2013, at 1:33 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8019184/webrev/ >> >> 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs >> Reviewed-by: >> >> The bug seems to be in MethodHandlesImpl.makeGuardWithCatch using ValueConversions.varargsArray: >> >> return makeCollectArguments(ginvoker, ValueConversions.varargsArray(nargs), 0, false); >> >> ValueConversions.varargsArray returns a MethodHandle which's type is: >> >> MethodHandle(Object,Object,Object,Object,Object,Object,Object,Object,Object)Object[] >> >> It doesn't preserve the trailing Object[]. >> >> The fix is to call makePairwiseConvert on the result of makeCollectArguments. >> >> src/share/classes/java/lang/invoke/MethodHandleImpl.java >> test/java/lang/invoke/TestCatchExceptionWithVarargs.java >> > From john.r.rose at oracle.com Tue Jul 2 15:00:00 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Jul 2013 15:00:00 -0700 Subject: RFR (XS): 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs In-Reply-To: <0CE13E66-7A6D-47C4-9023-A897D541F018@oracle.com> References: <0CFD47F8-4D3B-421F-A125-05A0916B35B8@oracle.com> <0CE13E66-7A6D-47C4-9023-A897D541F018@oracle.com> Message-ID: <4997F896-8DC6-4666-909A-BFB52A5327A9@oracle.com> Good; ship it! ? John On Jul 2, 2013, at 2:50 PM, Christian Thalinger wrote: > > On Jul 2, 2013, at 2:04 PM, John Rose wrote: > >> Good fix, good test. >> >> Suggestions for the test: >> >> Change e.printStackTrace() to throw new AssertionError(e), to get earlier detection of config error. > > Done. > >> >> Suggest using a more specific type than Exception, maybe even a specific instance (like firstArg), to rule out interference from accidental errors. Then detect the caught exception in the handler, before returning the desired value. > > It seems to be part of the magic that the exception doesn't end up in the handler so I can't check for the exception instance. > >> >> Suggest defining MAX_ARITY (MAX_MH_ARITY?) more categorically as 254, with a comment. Then have the loop go up to MAX_ARITY-1 with a comment, or put a break at the bottom of the loop body: >> if (handlerWithArgs.type().parameterCount() == MAX_MH_ARITY) break; // no more cases possible > > Done. > >> >> As we have seen, arity limits are hard to reason about! >> >> (Instead of dropArgs you could use something like MethodType.methodType(Object.class, Exception.class, ptypes.toArray()).) > > This doesn't work because ptypes.toArray() returns an Object[] and I think that the drop is also part of the magic. (I have engineered this test after the test case of the bug report.) > > Anyway, here is an updated webrev: > > http://cr.openjdk.java.net/~twisti/8019184/webrev/ > > -- Chris > >> >> ? John >> >> On Jul 2, 2013, at 1:33 PM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/8019184/webrev/ >>> >>> 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs >>> Reviewed-by: >>> >>> The bug seems to be in MethodHandlesImpl.makeGuardWithCatch using ValueConversions.varargsArray: >>> >>> return makeCollectArguments(ginvoker, ValueConversions.varargsArray(nargs), 0, false); >>> >>> ValueConversions.varargsArray returns a MethodHandle which's type is: >>> >>> MethodHandle(Object,Object,Object,Object,Object,Object,Object,Object,Object)Object[] >>> >>> It doesn't preserve the trailing Object[]. >>> >>> The fix is to call makePairwiseConvert on the result of makeCollectArguments. >>> >>> src/share/classes/java/lang/invoke/MethodHandleImpl.java >>> test/java/lang/invoke/TestCatchExceptionWithVarargs.java >>> >> > From vladimir.kozlov at oracle.com Tue Jul 2 15:17:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Jul 2013 15:17:03 -0700 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF1499@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDBDE@DEWDFEMB12A.global.corp.sap> <51D20DEC.7050904@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF1499@DEWDFEMB12A.global.corp.sap> Message-ID: <51D3515F.10402@oracle.com> Thank you, Goetz We are doing review of closed changes. When they are ready I will push. Thanks, Vladimir On 7/2/13 2:47 AM, Lindenmaier, Goetz wrote: > Hi, > > Sorry for that, I didn't grok the comment. The alignment is a good idea. > Fixed: > http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ > > Best regards, > Goetz. > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 2. Juli 2013 01:17 > To: Lindenmaier, Goetz > Cc: 'Christian Thalinger'; 'Albert Noll (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > Goetz, > > Why you did not add 'nop' between load and return instructions on sparc? > It was in assembler in .s file. The next comment said we need it: > > !! By convention with the trap handler we ensure there is a non-CTI > !! instruction in the trap shadow. > > Also should we align code in stubs to keep it in one cache line? > > __ align(CodeEntryAlignment); > *entry = __ pc(); > > Thanks, > Vladimir > > On 6/24/13 12:31 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> you are right, the check is redundant. >> I removed it and updated the webrev and also based it on the >> recent staging repo: >> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Monday, June 24, 2013 7:48 PM >> To: Lindenmaier, Goetz >> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >> >> >> On Jun 20, 2013, at 7:01 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi, >>> >>> I implemented the safefetch stubs for x86 and sparc (was quiet simple). >>> This way I could clean up the #define right away. >>> >>> I tested it thouroughly on >>> x86_64: bsd, nt, linux, solaris >>> x86_32: nt, linux >>> by adding it into our internal VM. >>> Tonight I will get build/test on >>> sparc_64 solaris >>> sparc_32 solaris >>> x86_64 nt, linux >>> with the openjdk ppc port, but I tested that before submitting in a smaller >>> extend, too. >>> >>> Here the webrev: >>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >> >> I like this change. It removes a lot of duplication. One comment: >> >> + static bool is_safefetch_fault(address pc) { >> + return pc != NULL && >> + (pc == _safefetch32_fault_pc || >> + pc == _safefetchN_fault_pc); >> + } >> >> checks for pc != null. Should we remove the check here? >> >> + if (pc && StubRoutines::is_safefetch_fault(pc)) { >> + set_cont_address(uc, address(StubRoutines::continuation_for_safefetch_fault(pc))); >> return true; >> } >> >> -- Chris >> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Dienstag, 18. Juni 2013 22:44 >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >>> >>> >>> On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" wrote: >>> >>>> Ok, I will implement it on x86. >>>> >>>> To get a single change, you can give me the sparc patch, >>>> or you extend the webrev once I updated it with the >>>> x86 code. >>> >>> Sounds good. Let me know when it's there. >>> >>> -- Chris >>> >>>> If you prefer, you can also push it to some other repository, it >>>> will end up in the ppc repo in time I guess. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> Sent: Tuesday, June 18, 2013 6:59 PM >>>> To: Lindenmaier, Goetz >>>> Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >>>> >>>> >>>> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" wrote: >>>> >>>>> Hi, >>>>> >>>>> We have it on these platforms: >>>>> ia64 (nt, linux, hp_ux) >>>>> parisc (hp_ux) >>>>> zArch (linux) >>>>> ppc (aix, linux) >>>>> >>>>> I would implement it on x86 & friends, you do it on sparc and wherever >>>>> else you like it? >>>> >>>> That sounds reasonable. Are we pushing this to the ppc repository then? >>>> >>>> -- Chris >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> Sent: Dienstag, 18. Juni 2013 07:13 >>>>> To: Volker Simonis >>>>> Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >>>>> >>>>> >>>>> On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: >>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> I think the change is good and if the other reviewers don't decide to >>>>>> implement it for the current platforms we can push it. >>>>> >>>>> I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> By the way, the makefile changes in ppc64.make will follow in patch 8 for >>>>>> linux [1] and patch 14 for aix [2]. >>>>>> The implementation of the stubs will be in patch 9 for linux [3] and patch >>>>>> 15 for aix [4] (only the signal handling part). >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>>>>> [2] >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>>>>> [3] >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>>>>> [4] >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>>>>> goetz.lindenmaier at sap.com> wrote: >>>>>> >>>>>>> Hi,**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> the PPC64 port uses stub routines to implement safefetch. We had and**** >>>>>>> >>>>>>> have problems with inline assembly, especially with non-gcc**** >>>>>>> >>>>>>> compilers. Stub routines allow to implement safefetch without**** >>>>>>> >>>>>>> depending on OS or compiler, as it's the case with the current**** >>>>>>> >>>>>>> implementation. This also allows to use a single implementation if an**** >>>>>>> >>>>>>> architecture is supported on several os platforms.**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Currently, we guard the code with **** >>>>>>> >>>>>>> #ifdef SAFEFETCH_STUBS**** >>>>>>> >>>>>>> which is set in ppc64.make.**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> I could also imagine an implementation that uses a pd_debug flag**** >>>>>>> >>>>>>> or a const flag set in os_.hpp that allows the C-compiler to **** >>>>>>> >>>>>>> optimize, and writing the code like this:**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>>>>> >>>>>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >>>>>>> * >>>>>>> >>>>>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>>>>> >>>>>>> if (UseSafefetchStub) {**** >>>>>>> >>>>>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >>>>>>> * >>>>>>> >>>>>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>>>>> >>>>>>> } else {**** >>>>>>> >>>>>>> pd_SafeFetch32(adr, errValue);**** >>>>>>> >>>>>>> }**** >>>>>>> >>>>>>> }**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Unfortunately this requires **** >>>>>>> >>>>>>> 1) setting the flag on all platforms**** >>>>>>> >>>>>>> 2) renaming the safefetch function on all platfoms.**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Actually I would prefer this second solution as it avoids the >>>>>>> preprocessor, **** >>>>>>> >>>>>>> and am happy to edit the sources accordingly if this finds acceptance.**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> For the implementation of a safefetch_stub see**** >>>>>>> >>>>>>> >>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>>> **** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Could I get a review on this change, please?**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Thanks,**** >>>>>>> >>>>>>> Goetz.**** >>>>>>> >>>>> >>>> >>> >> From christian.thalinger at oracle.com Tue Jul 2 15:23:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Jul 2013 15:23:59 -0700 Subject: RFR (XS): 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs In-Reply-To: <4997F896-8DC6-4666-909A-BFB52A5327A9@oracle.com> References: <0CFD47F8-4D3B-421F-A125-05A0916B35B8@oracle.com> <0CE13E66-7A6D-47C4-9023-A897D541F018@oracle.com> <4997F896-8DC6-4666-909A-BFB52A5327A9@oracle.com> Message-ID: Thank you, John. -- Chris On Jul 2, 2013, at 3:00 PM, John Rose wrote: > Good; ship it! ? John > > On Jul 2, 2013, at 2:50 PM, Christian Thalinger wrote: > >> >> On Jul 2, 2013, at 2:04 PM, John Rose wrote: >> >>> Good fix, good test. >>> >>> Suggestions for the test: >>> >>> Change e.printStackTrace() to throw new AssertionError(e), to get earlier detection of config error. >> >> Done. >> >>> >>> Suggest using a more specific type than Exception, maybe even a specific instance (like firstArg), to rule out interference from accidental errors. Then detect the caught exception in the handler, before returning the desired value. >> >> It seems to be part of the magic that the exception doesn't end up in the handler so I can't check for the exception instance. >> >>> >>> Suggest defining MAX_ARITY (MAX_MH_ARITY?) more categorically as 254, with a comment. Then have the loop go up to MAX_ARITY-1 with a comment, or put a break at the bottom of the loop body: >>> if (handlerWithArgs.type().parameterCount() == MAX_MH_ARITY) break; // no more cases possible >> >> Done. >> >>> >>> As we have seen, arity limits are hard to reason about! >>> >>> (Instead of dropArgs you could use something like MethodType.methodType(Object.class, Exception.class, ptypes.toArray()).) >> >> This doesn't work because ptypes.toArray() returns an Object[] and I think that the drop is also part of the magic. (I have engineered this test after the test case of the bug report.) >> >> Anyway, here is an updated webrev: >> >> http://cr.openjdk.java.net/~twisti/8019184/webrev/ >> >> -- Chris >> >>> >>> ? John >>> >>> On Jul 2, 2013, at 1:33 PM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/8019184/webrev/ >>>> >>>> 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs >>>> Reviewed-by: >>>> >>>> The bug seems to be in MethodHandlesImpl.makeGuardWithCatch using ValueConversions.varargsArray: >>>> >>>> return makeCollectArguments(ginvoker, ValueConversions.varargsArray(nargs), 0, false); >>>> >>>> ValueConversions.varargsArray returns a MethodHandle which's type is: >>>> >>>> MethodHandle(Object,Object,Object,Object,Object,Object,Object,Object,Object)Object[] >>>> >>>> It doesn't preserve the trailing Object[]. >>>> >>>> The fix is to call makePairwiseConvert on the result of makeCollectArguments. >>>> >>>> src/share/classes/java/lang/invoke/MethodHandleImpl.java >>>> test/java/lang/invoke/TestCatchExceptionWithVarargs.java >>>> >>> >> > From goetz.lindenmaier at sap.com Tue Jul 2 16:40:27 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Jul 2013 23:40:27 +0000 Subject: RFR (S): 8019517: PPC64 (part 102): cppInterpreter: implement G1 support Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF1B9B@DEWDFEMB12A.global.corp.sap> Hi, we implemented support for G1 in the cppInterpreter. This is basically all done in the accessor routines, they just have to be called properly. http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInter_g1/ I would be happy if I could get a review on this change. Thanks and best regards, Goetz. From goetz.lindenmaier at sap.com Tue Jul 2 16:46:51 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Jul 2013 23:46:51 +0000 Subject: RFR (S): 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF1BB3@DEWDFEMB12A.global.corp.sap> Hi, we implemented the missing decode in aaload so that the cppInterpreter now works with compressed Oops. http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInterp_cOops/ Please review this change. Thanks and best regards, Goetz. From vladimir.kozlov at oracle.com Tue Jul 2 16:54:12 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Jul 2013 16:54:12 -0700 Subject: RFR (S): 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF1BB3@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF1BB3@DEWDFEMB12A.global.corp.sap> Message-ID: <51D36824.2060100@oracle.com> What about stores to array and instance's oop fields access? Vladimir On 7/2/13 4:46 PM, Lindenmaier, Goetz wrote: > Hi, > > we implemented the missing decode in aaload so that the > > cppInterpreter now works with compressed Oops. > > http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInterp_cOops/ > > Please review this change. > > Thanks and best regards, > > Goetz. > From vladimir.kozlov at oracle.com Tue Jul 2 17:06:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Jul 2013 17:06:08 -0700 Subject: RFR (S): 8019517: PPC64 (part 102): cppInterpreter: implement G1 support In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF1B9B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF1B9B@DEWDFEMB12A.global.corp.sap> Message-ID: <51D36AF0.3020302@oracle.com> Goetz, Do you still need next include?: #include "memory/cardTableModRefBS.hpp" Vladimir On 7/2/13 4:40 PM, Lindenmaier, Goetz wrote: > Hi, > > we implemented support for G1 in the cppInterpreter. > > This is basically all done in the accessor routines, they > > just have to be called properly. > > http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInter_g1/ > > I would be happy if I could get a review on this change. > > Thanks and best regards, > > Goetz. > From john.cuthbertson at oracle.com Tue Jul 2 20:22:15 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Wed, 03 Jul 2013 03:22:15 +0000 Subject: hg: hsx/hsx24/hotspot: 7122222: GC log is limited to 2G for 32-bit Message-ID: <20130703032220.531C548742@hg.openjdk.java.net> Changeset: 9a72ee84e61b Author: tamao Date: 2013-07-02 15:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9a72ee84e61b 7122222: GC log is limited to 2G for 32-bit Summary: Manual backport to hsx24 from hsx25: Enable large file support for generated 32-bit ostream.o on Linux and Solaris (as only the two need this) by setting -D_FILE_OFFSET_BITS=64 in compilation Reviewed-by: dcubed, jcoomes ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/os/solaris/vm/os_solaris.inline.hpp From christian.thalinger at oracle.com Tue Jul 2 21:36:29 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Jul 2013 21:36:29 -0700 Subject: RFR (S): 8019517: PPC64 (part 102): cppInterpreter: implement G1 support In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF1B9B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF1B9B@DEWDFEMB12A.global.corp.sap> Message-ID: <0BE19811-50A4-4954-A9C1-8BAF4B395470@oracle.com> + // G1GC port. Use accessor instead of storing manually. + // Takes care of write barriers internally and replaces the code above. + ((objArrayOopDesc *) arrObj)->obj_at_put(index, rhsObject); The comment "replaces the code above" seems odd. Should it be removed? -- Chris On Jul 2, 2013, at 4:40 PM, "Lindenmaier, Goetz" wrote: > Hi, > > we implemented support for G1 in the cppInterpreter. > This is basically all done in the accessor routines, they > just have to be called properly. > http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInter_g1/ > > I would be happy if I could get a review on this change. > > Thanks and best regards, > Goetz. From goetz.lindenmaier at sap.com Wed Jul 3 01:48:50 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 3 Jul 2013 08:48:50 +0000 Subject: RFR (S): 8019517: PPC64 (part 102): cppInterpreter: implement G1 support In-Reply-To: <0BE19811-50A4-4954-A9C1-8BAF4B395470@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF1B9B@DEWDFEMB12A.global.corp.sap> <0BE19811-50A4-4954-A9C1-8BAF4B395470@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF1CC7@DEWDFEMB12A.global.corp.sap> Hi Chris, I removed the comment altogether. The first line is nonsense, too. And the statement that the accessor does the memory ordering is not necessary, either, especially as it's not documented with all the other calls. I updated the webrev. http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInter_g1 Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Mittwoch, 3. Juli 2013 06:36 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' Subject: Re: RFR (S): 8019517: PPC64 (part 102): cppInterpreter: implement G1 support + // G1GC port. Use accessor instead of storing manually. + // Takes care of write barriers internally and replaces the code above. + ((objArrayOopDesc *) arrObj)->obj_at_put(index, rhsObject); The comment "replaces the code above" seems odd. Should it be removed? -- Chris On Jul 2, 2013, at 4:40 PM, "Lindenmaier, Goetz" wrote: > Hi, > > we implemented support for G1 in the cppInterpreter. > This is basically all done in the accessor routines, they > just have to be called properly. > http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInter_g1/ > > I would be happy if I could get a review on this change. > > Thanks and best regards, > Goetz. From goetz.lindenmaier at sap.com Wed Jul 3 02:49:04 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 3 Jul 2013 09:49:04 +0000 Subject: RFR (S): 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops In-Reply-To: <51D36824.2060100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF1BB3@DEWDFEMB12A.global.corp.sap> <51D36824.2060100@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF1D0B@DEWDFEMB12A.global.corp.sap> Hi, the other oop decode/encodes are all done in the access routines that are called there. The g1 change fixes the other array store. Maybe it reads better like this: http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInterp_cOops-2/ Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Mittwoch, 3. Juli 2013 01:54 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR (S): 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops What about stores to array and instance's oop fields access? Vladimir On 7/2/13 4:46 PM, Lindenmaier, Goetz wrote: > Hi, > > we implemented the missing decode in aaload so that the > > cppInterpreter now works with compressed Oops. > > http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInterp_cOops/ > > Please review this change. > > Thanks and best regards, > > Goetz. > From goetz.lindenmaier at sap.com Wed Jul 3 02:51:35 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 3 Jul 2013 09:51:35 +0000 Subject: RFR (S): 8019517: PPC64 (part 102): cppInterpreter: implement G1 support In-Reply-To: <51D36AF0.3020302@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF1B9B@DEWDFEMB12A.global.corp.sap> <51D36AF0.3020302@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF1D46@DEWDFEMB12A.global.corp.sap> Yes, I removed it. Thanks, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Mittwoch, 3. Juli 2013 02:06 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR (S): 8019517: PPC64 (part 102): cppInterpreter: implement G1 support Goetz, Do you still need next include?: #include "memory/cardTableModRefBS.hpp" Vladimir On 7/2/13 4:40 PM, Lindenmaier, Goetz wrote: > Hi, > > we implemented support for G1 in the cppInterpreter. > > This is basically all done in the accessor routines, they > > just have to be called properly. > > http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInter_g1/ > > I would be happy if I could get a review on this change. > > Thanks and best regards, > > Goetz. > From goetz.lindenmaier at sap.com Wed Jul 3 03:24:05 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 3 Jul 2013 10:24:05 +0000 Subject: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF1D63@DEWDFEMB12A.global.corp.sap> Hi, This change implements jvmti early return and pop frame support in the cppInterpreter. To work properly, the corresponding properties in JvmtiManageCapabilities::init_onload_capabilities() must be enabled. We will add this in a later change. I would be happy about a review of this change: http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet/ Best regards, Goetz. From joseph.provino at oracle.com Wed Jul 3 09:53:25 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 03 Jul 2013 12:53:25 -0400 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8011064 Message-ID: <51D45705.1010400@oracle.com> This is a backport to 7 and it integrates cleanly from 8 so it should be an easy review. Bug report:https://jbs.oracle.com/bugs/browse/JDK-8011064 Webrev is here: http://cr.openjdk.java.net/~jprovino/8011064/webrev.7u.00/ Thanks. joe From vladimir.kozlov at oracle.com Wed Jul 3 10:23:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Jul 2013 10:23:03 -0700 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8011064 In-Reply-To: <51D45705.1010400@oracle.com> References: <51D45705.1010400@oracle.com> Message-ID: <51D45DF7.3010701@oracle.com> Looks good. Vladimir On 7/3/13 9:53 AM, Joseph Provino wrote: > This is a backport to 7 and it integrates cleanly from 8 so it should be > an easy review. > > Bug report:https://jbs.oracle.com/bugs/browse/JDK-8011064 > > Webrev is here: > http://cr.openjdk.java.net/~jprovino/8011064/webrev.7u.00/ > > > Thanks. > > joe From vladimir.kozlov at oracle.com Wed Jul 3 11:16:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Jul 2013 11:16:09 -0700 Subject: RFR (S): 8019517: PPC64 (part 102): cppInterpreter: implement G1 support In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF1D46@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF1B9B@DEWDFEMB12A.global.corp.sap> <51D36AF0.3020302@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF1D46@DEWDFEMB12A.global.corp.sap> Message-ID: <51D46A69.1040202@oracle.com> Good. thanks, Vladimir On 7/3/13 2:51 AM, Lindenmaier, Goetz wrote: > Yes, I removed it. > Thanks, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 3. Juli 2013 02:06 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR (S): 8019517: PPC64 (part 102): cppInterpreter: implement G1 support > > Goetz, > > Do you still need next include?: > > #include "memory/cardTableModRefBS.hpp" > > Vladimir > > On 7/2/13 4:40 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> we implemented support for G1 in the cppInterpreter. >> >> This is basically all done in the accessor routines, they >> >> just have to be called properly. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInter_g1/ >> >> I would be happy if I could get a review on this change. >> >> Thanks and best regards, >> >> Goetz. >> From vladimir.kozlov at oracle.com Wed Jul 3 11:18:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Jul 2013 11:18:16 -0700 Subject: RFR (S): 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF1D0B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF1BB3@DEWDFEMB12A.global.corp.sap> <51D36824.2060100@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF1D0B@DEWDFEMB12A.global.corp.sap> Message-ID: <51D46AE8.6000308@oracle.com> Yes, it is better. Good. Thanks, Vladimir On 7/3/13 2:49 AM, Lindenmaier, Goetz wrote: > Hi, > > the other oop decode/encodes are all done in the access routines > that are called there. The g1 change fixes the other array store. > Maybe it reads better like this: > http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInterp_cOops-2/ > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 3. Juli 2013 01:54 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR (S): 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops > > What about stores to array and instance's oop fields access? > > Vladimir > > On 7/2/13 4:46 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> we implemented the missing decode in aaload so that the >> >> cppInterpreter now works with compressed Oops. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInterp_cOops/ >> >> Please review this change. >> >> Thanks and best regards, >> >> Goetz. >> From coleen.phillimore at oracle.com Wed Jul 3 11:33:27 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 03 Jul 2013 14:33:27 -0400 Subject: RFR (S): 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops In-Reply-To: <51D46AE8.6000308@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF1BB3@DEWDFEMB12A.global.corp.sap> <51D36824.2060100@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF1D0B@DEWDFEMB12A.global.corp.sap> <51D46AE8.6000308@oracle.com> Message-ID: <51D46E77.2070008@oracle.com> On 7/3/2013 2:18 PM, Vladimir Kozlov wrote: > Yes, it is better. Good. Agree - that's a lot better. Thanks, Coleen > > Thanks, > Vladimir > > On 7/3/13 2:49 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> the other oop decode/encodes are all done in the access routines >> that are called there. The g1 change fixes the other array store. >> Maybe it reads better like this: >> http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInterp_cOops-2/ >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Mittwoch, 3. Juli 2013 01:54 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR (S): 8019518: PPC64 (part 103): cppInterpreter: >> implement support for compressed Oops >> >> What about stores to array and instance's oop fields access? >> >> Vladimir >> >> On 7/2/13 4:46 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> we implemented the missing decode in aaload so that the >>> >>> cppInterpreter now works with compressed Oops. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019518-cInterp_cOops/ >>> >>> Please review this change. >>> >>> Thanks and best regards, >>> >>> Goetz. >>> From vladimir.kozlov at oracle.com Wed Jul 3 11:36:58 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Jul 2013 11:36:58 -0700 Subject: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF1D63@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF1D63@DEWDFEMB12A.global.corp.sap> Message-ID: <51D46F4A.2020905@oracle.com> Goetz, Just styling notes. Could you add {} for bodies of handle_Pop_Frame: and handle_Early_Return: cases? Also can you store THREAD->jvmti_thread_state() in local before the switch and use it in all those places? Could you explain why you removed from common code 'handle_return:' ? - istate->set_return_kind((Bytecodes::Code)opcode); Thanks, Vladimir On 7/3/13 3:24 AM, Lindenmaier, Goetz wrote: > Hi, > > This change implements jvmti early return and pop frame support > > in the cppInterpreter. To work properly, the corresponding properties in > > JvmtiManageCapabilities::init_onload_capabilities() must be enabled. > > We will add this in a later change. > > I would be happy about a review of this change: > > http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet/ > > Best regards, > > Goetz. > From joseph.provino at oracle.com Wed Jul 3 12:10:40 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 03 Jul 2013 15:10:40 -0400 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8017473 Message-ID: <51D47730.4020303@oracle.com> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 This is for SE_8 but will be backported to 7u. Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ I changed PLATFORM_NMT_DETAIL_SUPPORTED to PLATFORM_NATIVE_STACK_WALKING_SUPPORTED to make the name more general. Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make because with the low optimization for debug builds, -fno-omit-frame-pointer is set and stack walking is always permissible. Changed vm.make to optionally include an architecture specific makefile in case some files need to be compiled with special options such as -fno-omit-frame-pointer. Thanks. joe From vladimir.kozlov at oracle.com Wed Jul 3 12:27:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Jul 2013 12:27:54 -0700 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8017473 In-Reply-To: <51D47730.4020303@oracle.com> References: <51D47730.4020303@oracle.com> Message-ID: <51D47B3A.4090003@oracle.com> I don't like to have renaming done together with the fix. Is renaming required? Thanks, Vladimir On 7/3/13 12:10 PM, Joseph Provino wrote: > Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 > > This is for SE_8 but will be backported to 7u. > > Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ > > > I changed PLATFORM_NMT_DETAIL_SUPPORTED to > PLATFORM_NATIVE_STACK_WALKING_SUPPORTED > to make the name more general. > > Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make > because > with the low optimization for debug builds, -fno-omit-frame-pointer is > set and stack walking > is always permissible. > > Changed vm.make to optionally include an architecture specific makefile > in case some files > need to be compiled with special options such as -fno-omit-frame-pointer. > > Thanks. > > joe From joseph.provino at oracle.com Wed Jul 3 12:53:17 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 03 Jul 2013 15:53:17 -0400 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8017473 In-Reply-To: <51D47B3A.4090003@oracle.com> References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> Message-ID: <51D4812D.4000504@oracle.com> On 07/03/2013 03:27 PM, Vladimir Kozlov wrote: > I don't like to have renaming done together with the fix. Is renaming > required? > > Thanks, > Vladimir Renaming isn't required but if I keep PLATFORM_NMT_DETAIL_SUPPORTED I would need to add the new flag PLATFORM_NATIVE_STACK_WALKING_SUPPORTED. I could use PLATFORM_NMT_DETAIL_SUPPORTED but NMT doesn't have anything to do with this bug 8017473. What happened is that 8011064 got reported and fixed first. The fix was to disallow NMT_detail in some cases so PLATFORM_NMT_DETAIL_SUPPORTED made sense. Bug 8017473 makes it clear that there are times when native stack walking can't be done. PLATFORM_NATIVE_STACK_WALKING_SUPPORTED is more general and makes sense for 8011064 and 8017473. Do you think it would be better to use a new name and then file another bug to change PLATFORM_NMT_DETAIL_SUPPORTED to PLATFORM_NATIVE_STACK_WALKING_SUPPORTED? joe > > On 7/3/13 12:10 PM, Joseph Provino wrote: >> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 >> >> This is for SE_8 but will be backported to 7u. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ >> >> >> I changed PLATFORM_NMT_DETAIL_SUPPORTED to >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED >> to make the name more general. >> >> Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make >> because >> with the low optimization for debug builds, -fno-omit-frame-pointer is >> set and stack walking >> is always permissible. >> >> Changed vm.make to optionally include an architecture specific makefile >> in case some files >> need to be compiled with special options such as >> -fno-omit-frame-pointer. >> >> Thanks. >> >> joe From serguei.spitsyn at oracle.com Wed Jul 3 12:58:44 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 03 Jul 2013 12:58:44 -0700 Subject: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF1D63@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF1D63@DEWDFEMB12A.global.corp.sap> Message-ID: <51D48274.9090707@oracle.com> Hi Goetz, The fix looks good in general. Thank you for doing this! A couple of comments: src/share/vm/interpreter/bytecodeInterpreter.cpp: It looks like you have accidentally dropped the line: 2981 THREAD->clr_pop_frame_in_process(); What is the reason that the following lines are deleted? (the same as Vladimir already asked): 2962 istate->set_return_kind((Bytecodes::Code)opcode); 2987 istate->set_return_kind((Bytecodes::Code)opcode); Thanks, Serguei On 7/3/13 3:24 AM, Lindenmaier, Goetz wrote: > Hi, > > This change implements jvmti early return and pop frame support > in the cppInterpreter. To work properly, the corresponding properties in > JvmtiManageCapabilities::init_onload_capabilities() must be enabled. > We will add this in a later change. > > I would be happy about a review of this change: > http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet/ > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Wed Jul 3 13:15:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Jul 2013 13:15:09 -0700 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8017473 In-Reply-To: <51D4812D.4000504@oracle.com> References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> <51D4812D.4000504@oracle.com> Message-ID: <51D4864D.6030200@oracle.com> Thank you for explaining situation, it was confusing. Since you are going to backport it into 7u40 the fix should be simple and targeted. For me the suggestion to use new PLATFORM_NATIVE_STACK_WALKING_SUPPORTED to fix this 8017473. As you said NMT is nothing to do with this. So using PLATFORM_NATIVE_STACK_WALKING_SUPPORTED instead of PLATFORM_NMT_DETAIL_SUPPORTED is also questionable. Why you use "PLATFORM_" prefix in names? Thanks, Vladimir On 7/3/13 12:53 PM, Joseph Provino wrote: > On 07/03/2013 03:27 PM, Vladimir Kozlov wrote: >> I don't like to have renaming done together with the fix. Is renaming >> required? >> >> Thanks, >> Vladimir > > Renaming isn't required but if I keep PLATFORM_NMT_DETAIL_SUPPORTED > I would need to add the new flag PLATFORM_NATIVE_STACK_WALKING_SUPPORTED. > > I could use PLATFORM_NMT_DETAIL_SUPPORTED but NMT doesn't have anything > to do > with this bug 8017473. > > What happened is that 8011064 got reported and fixed first. The fix was > to disallow > NMT_detail in some cases so PLATFORM_NMT_DETAIL_SUPPORTED made sense. > > Bug 8017473 makes it clear that there are times when native stack > walking can't be done. > PLATFORM_NATIVE_STACK_WALKING_SUPPORTED is more general and makes sense for > 8011064 and 8017473. > > Do you think it would be better to use a new name and then file another > bug to change > PLATFORM_NMT_DETAIL_SUPPORTED to PLATFORM_NATIVE_STACK_WALKING_SUPPORTED? > > joe > >> >> On 7/3/13 12:10 PM, Joseph Provino wrote: >>> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 >>> >>> This is for SE_8 but will be backported to 7u. >>> >>> Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ >>> >>> >>> I changed PLATFORM_NMT_DETAIL_SUPPORTED to >>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED >>> to make the name more general. >>> >>> Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make >>> because >>> with the low optimization for debug builds, -fno-omit-frame-pointer is >>> set and stack walking >>> is always permissible. >>> >>> Changed vm.make to optionally include an architecture specific makefile >>> in case some files >>> need to be compiled with special options such as >>> -fno-omit-frame-pointer. >>> >>> Thanks. >>> >>> joe > From joseph.provino at oracle.com Wed Jul 3 13:52:50 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 03 Jul 2013 16:52:50 -0400 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8017473 In-Reply-To: <51D4864D.6030200@oracle.com> References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> <51D4812D.4000504@oracle.com> <51D4864D.6030200@oracle.com> Message-ID: <51D48F22.3030600@oracle.com> It's even more confusing now! ;-) https://jbs.oracle.com/bugs/browse/JDK-8017473 turns out to be a duplicate of https://jbs.oracle.com/bugs/browse/JDK-8011569 I closed 8017473 as a duplicate and will make a webrev for 8011569 then backport to 7u. More comments below as to what to do. On 7/3/2013 4:15 PM, Vladimir Kozlov wrote: > Thank you for explaining situation, it was confusing. > > Since you are going to backport it into 7u40 the fix should be simple > and targeted. For me the suggestion to use new > PLATFORM_NATIVE_STACK_WALKING_SUPPORTED to fix this 8017473. > > As you said NMT is nothing to do with this. So using > PLATFORM_NATIVE_STACK_WALKING_SUPPORTED instead of > PLATFORM_NMT_DETAIL_SUPPORTED is also questionable. I'm not sure what you would like. It is okay to change PLATFORM_NMT_DETAIL_SUPPORTED to PLATFORM_NATIVE_STACK_WALKING_SUPPORTED for this bug fix? I think this would be the easiest way to clean it up. If you have another way you'd rather see it done, let me know. > Why you use "PLATFORM_" prefix in names? That's a good question. I thought there were other names like that but I don't see any now. NATIVE_STACK_WALKING_SUPPORTED seems better but perhaps because it's platform specific maybe it's okay as is? I don't feel strongly either way... thanks. joe > > Thanks, > Vladimir > > On 7/3/13 12:53 PM, Joseph Provino wrote: >> On 07/03/2013 03:27 PM, Vladimir Kozlov wrote: >>> I don't like to have renaming done together with the fix. Is renaming >>> required? >>> >>> Thanks, >>> Vladimir >> >> Renaming isn't required but if I keep PLATFORM_NMT_DETAIL_SUPPORTED >> I would need to add the new flag >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED. >> >> I could use PLATFORM_NMT_DETAIL_SUPPORTED but NMT doesn't have anything >> to do >> with this bug 8017473. >> >> What happened is that 8011064 got reported and fixed first. The fix was >> to disallow >> NMT_detail in some cases so PLATFORM_NMT_DETAIL_SUPPORTED made sense. >> >> Bug 8017473 makes it clear that there are times when native stack >> walking can't be done. >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED is more general and makes >> sense for >> 8011064 and 8017473. >> >> Do you think it would be better to use a new name and then file another >> bug to change >> PLATFORM_NMT_DETAIL_SUPPORTED to >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED? >> >> joe >> >>> >>> On 7/3/13 12:10 PM, Joseph Provino wrote: >>>> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 >>>> >>>> This is for SE_8 but will be backported to 7u. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ >>>> >>>> >>>> I changed PLATFORM_NMT_DETAIL_SUPPORTED to >>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED >>>> to make the name more general. >>>> >>>> Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make >>>> because >>>> with the low optimization for debug builds, -fno-omit-frame-pointer is >>>> set and stack walking >>>> is always permissible. >>>> >>>> Changed vm.make to optionally include an architecture specific >>>> makefile >>>> in case some files >>>> need to be compiled with special options such as >>>> -fno-omit-frame-pointer. >>>> >>>> Thanks. >>>> >>>> joe >> From bill.pittore at oracle.com Wed Jul 3 14:17:29 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 03 Jul 2013 17:17:29 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents Message-ID: <51D494E9.2020200@oracle.com> These changes address bug 8014135 which adds support for statically linked agents in the VM. This is a followup to the recent JNI spec changes that addressed statically linked JNI libraries( 8005716). The JEP for this change is the same JEP as the JNI changes: http://openjdk.java.net/jeps/178 Webrevs are here: http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ The changes to jvmti.xml can also be seen in the output file that I placed here: http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html Thanks, bill From frederic.parain at oracle.com Wed Jul 3 14:35:54 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 03 Jul 2013 21:35:54 +0000 Subject: hg: hsx/hotspot-main/hotspot: 14 new changesets Message-ID: <20130703213622.7B47B48790@hg.openjdk.java.net> Changeset: 8cff1de240de Author: zgu Date: 2013-06-25 17:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8cff1de240de 8017478: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites Summary: Fixed possible NULL pointer that caused SIGSEGV Reviewed-by: coleenp, acorn, ctornqvi ! src/share/vm/services/memReporter.cpp Changeset: c14867f95c60 Author: zgu Date: 2013-06-25 14:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c14867f95c60 Merge Changeset: 38ea2efa32a7 Author: kevinw Date: 2013-06-26 00:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/38ea2efa32a7 8010278: SA: provide mechanism for using an alternative SA debugger back-end. Reviewed-by: sla, dsamersoff ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxOopHandle.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java Changeset: 8eb40545e209 Author: kevinw Date: 2013-06-26 11:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8eb40545e209 Merge Changeset: 221df7e37535 Author: iklam Date: 2013-06-27 10:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/221df7e37535 8016075: Win32 crash with CDS enabled and small heap size Summary: Fixed MetaspaceShared::is_in_shared_space Reviewed-by: coleenp, hseigel ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: e0fe0c9a88da Author: nloodin Date: 2013-06-28 14:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e0fe0c9a88da Merge Changeset: bb4f2b27e824 Author: dcubed Date: 2013-06-29 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bb4f2b27e824 Merge Changeset: 97c5acae48be Author: hseigel Date: 2013-06-30 09:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/97c5acae48be 7007040: Check of capacity paramenters in JNI_PushLocalFrame is wrong Summary: changed AND to OR Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/jni.cpp Changeset: 068b406e307f Author: fparain Date: 2013-07-01 09:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/068b406e307f 7060111: race condition in VMError::report_and_die() Reviewed-by: zgu, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: acfa2cc19146 Author: rbackman Date: 2013-06-12 09:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/acfa2cc19146 8016444: Duplicate zombie check in safe_for_sender Reviewed-by: dholmes, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/share/vm/memory/referenceProcessorStats.hpp Changeset: 993dfb57c575 Author: egahlin Date: 2013-06-26 17:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/993dfb57c575 8016331: Minor issues in event tracing metadata Reviewed-by: stefank, brutisso, mgronlun ! src/share/vm/trace/trace.xml Changeset: 7f11c12d7a90 Author: sspitsyn Date: 2013-07-01 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7f11c12d7a90 8009204: [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris Summary: The fix is basically a backport of JDK-7019165 (pstack issue) to jhelper.d. Reviewed-by: coleenp, sspitsyn Contributed-by: tomas.hurka at oracle.com ! src/os/solaris/dtrace/jhelper.d Changeset: de2d15ce3d4a Author: coleenp Date: 2013-07-02 08:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/de2d15ce3d4a 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadata space could occur when metaspace is almost empty Summary: Allocate medium chunks for class metaspace when class loader has lots of classes Reviewed-by: mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: cedf20e2a655 Author: coleenp Date: 2013-07-02 16:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cedf20e2a655 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp From david.holmes at oracle.com Wed Jul 3 16:17:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Jul 2013 09:17:13 +1000 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8011064 In-Reply-To: <51D45705.1010400@oracle.com> References: <51D45705.1010400@oracle.com> Message-ID: <51D4B0F9.4000605@oracle.com> Hi Joe, Please don't use URLs in the subject line. The form "RFR " is far more informative. On 4/07/2013 2:53 AM, Joseph Provino wrote: > This is a backport to 7 and it integrates cleanly from 8 so it should be > an easy review. A link to JDK8 changeset would be useful for reference. > Bug report:https://jbs.oracle.com/bugs/browse/JDK-8011064 This is not available to anyone outside Oracle and in this case is a Confidential bug anyway. So please recap what the issue is and the solution. > Webrev is here: > http://cr.openjdk.java.net/~jprovino/8011064/webrev.7u.00/ > Seems exactly the same as hs25 version. Reviewed. David > Thanks. > > joe From david.holmes at oracle.com Wed Jul 3 16:19:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Jul 2013 09:19:43 +1000 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8017473 In-Reply-To: <51D47730.4020303@oracle.com> References: <51D47730.4020303@oracle.com> Message-ID: <51D4B18F.4080907@oracle.com> Joe, On 4/07/2013 5:10 AM, Joseph Provino wrote: > Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 You have closed this as a duplicate of 8011569 ??? David ----- > This is for SE_8 but will be backported to 7u. > > Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ > > > I changed PLATFORM_NMT_DETAIL_SUPPORTED to > PLATFORM_NATIVE_STACK_WALKING_SUPPORTED > to make the name more general. > > Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make > because > with the low optimization for debug builds, -fno-omit-frame-pointer is > set and stack walking > is always permissible. > > Changed vm.make to optionally include an architecture specific makefile > in case some files > need to be compiled with special options such as -fno-omit-frame-pointer. > > Thanks. > > joe From joseph.provino at oracle.com Wed Jul 3 16:54:39 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 03 Jul 2013 19:54:39 -0400 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8017473 In-Reply-To: <51D4B18F.4080907@oracle.com> References: <51D47730.4020303@oracle.com> <51D4B18F.4080907@oracle.com> Message-ID: <51D4B9BF.9020407@oracle.com> On 07/03/2013 07:19 PM, David Holmes wrote: > Joe, > > On 4/07/2013 5:10 AM, Joseph Provino wrote: >> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 > > You have closed this as a duplicate of 8011569 ??? Yes, was that the wrong thing to do? joe > > David > ----- > >> This is for SE_8 but will be backported to 7u. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ >> >> >> I changed PLATFORM_NMT_DETAIL_SUPPORTED to >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED >> to make the name more general. >> >> Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make >> because >> with the low optimization for debug builds, -fno-omit-frame-pointer is >> set and stack walking >> is always permissible. >> >> Changed vm.make to optionally include an architecture specific makefile >> in case some files >> need to be compiled with special options such as >> -fno-omit-frame-pointer. >> >> Thanks. >> >> joe From john.cuthbertson at oracle.com Wed Jul 3 17:42:04 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Thu, 04 Jul 2013 00:42:04 +0000 Subject: hg: hsx/hsx24/hotspot: 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed Message-ID: <20130704004213.C5426487A7@hg.openjdk.java.net> Changeset: b68a2c45f554 Author: johnc Date: 2013-07-01 09:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b68a2c45f554 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed Summary: The assert is invalid when a card is being refined by two different threads and its count crosses the hot threshold - the refinement count will be updated once by each thread triggering the assert. Remove the assert and update the count using a bounded expression. Reviewed-by: jmasa, tamao, brutisso ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp From tao.mao at oracle.com Wed Jul 3 21:56:51 2013 From: tao.mao at oracle.com (tao.mao at oracle.com) Date: Thu, 04 Jul 2013 04:56:51 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130704045708.786B6487AE@hg.openjdk.java.net> Changeset: c92b74c62d97 Author: brutisso Date: 2013-06-27 09:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c92b74c62d97 8017483: G1 tests fail with native OOME on Solaris x86 after HeapBaseMinAddress has been increased Summary: Set HeapBaseMinAddress as default rather than ergo Reviewed-by: stefank, jmasa, kvn ! src/share/vm/runtime/arguments.cpp Changeset: 3ea89789ba39 Author: ehelin Date: 2013-06-28 18:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3ea89789ba39 Merge Changeset: b30744960351 Author: brutisso Date: 2013-06-30 21:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b30744960351 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks. Reviewed-by: tschatzl, brutisso, jmasa, ysr Contributed-by: per.liden at oracle.com ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: 5ea20b3bd249 Author: johnc Date: 2013-07-01 09:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ea20b3bd249 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed Summary: The assert is invalid when a card is being refined by two different threads and its count crosses the hot threshold - the refinement count will be updated once by each thread triggering the assert. Remove the assert and update the count using a bounded expression. Reviewed-by: jmasa, tamao, brutisso ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp Changeset: 6e3634222155 Author: tamao Date: 2013-06-28 20:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6e3634222155 8017611: Auto corrector for mistyped vm options Summary: The auto corrector for mistyped vm options fuzzy-matches existing flags based on string similarity (Dice's coefficient). Reviewed-by: kvn, dsamersoff, hseigel, johnc ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp + test/gc/arguments/TestUnrecognizedVMOptionsHandling.java Changeset: 536976a22f5f Author: tamao Date: 2013-07-03 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/536976a22f5f Merge Changeset: 70bea4a43c6d Author: tamao Date: 2013-07-03 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/70bea4a43c6d Merge From serguei.spitsyn at oracle.com Thu Jul 4 03:25:29 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 04 Jul 2013 03:25:29 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D494E9.2020200@oracle.com> References: <51D494E9.2020200@oracle.com> Message-ID: <51D54D99.8090103@oracle.com> Hi Bill, I've already had a chance to read your webrev several weeks ago, but need more time. Thanks, Serguei On 7/3/13 2:17 PM, BILL PITTORE wrote: > These changes address bug 8014135 which adds support for statically > linked agents in the VM. This is a followup to the recent JNI spec > changes that addressed statically linked JNI libraries( 8005716). > The JEP for this change is the same JEP as the JNI changes: > http://openjdk.java.net/jeps/178 > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ > > The changes to jvmti.xml can also be seen in the output file that I > placed here: > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html > > Thanks, > bill > > From bertrand.delsart at oracle.com Thu Jul 4 03:35:24 2013 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Thu, 04 Jul 2013 10:35:24 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20130704103533.0D2F7487C5@hg.openjdk.java.net> Changeset: ac7193063af8 Author: jiangli Date: 2013-07-01 19:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ac7193063af8 8006023: Embedded Builds fail management test because of requirement for UsePerfData being enabled. Summary: Added -XX:+UsePerfData to Test7196045.java. Reviewed-by: dholmes, collins ! test/runtime/7196045/Test7196045.java Changeset: 94aa8de029c5 Author: clucasius Date: 2013-07-03 22:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/94aa8de029c5 Merge Changeset: fea6a49c2762 Author: bdelsart Date: 2013-07-04 01:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fea6a49c2762 Merge From david.holmes at oracle.com Thu Jul 4 04:07:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Jul 2013 21:07:07 +1000 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8017473 In-Reply-To: <51D4B9BF.9020407@oracle.com> References: <51D47730.4020303@oracle.com> <51D4B18F.4080907@oracle.com> <51D4B9BF.9020407@oracle.com> Message-ID: <51D5575B.8060705@oracle.com> On 4/07/2013 9:54 AM, Joseph Provino wrote: > On 07/03/2013 07:19 PM, David Holmes wrote: >> Joe, >> >> On 4/07/2013 5:10 AM, Joseph Provino wrote: >>> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 >> >> You have closed this as a duplicate of 8011569 ??? > > Yes, was that the wrong thing to do? I had missed your subsequent email regarding the duplication issue. I'm left rather confused by the whole issue and will await your updated webrev for 8011569. David > joe > >> >> David >> ----- >> >>> This is for SE_8 but will be backported to 7u. >>> >>> Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ >>> >>> >>> I changed PLATFORM_NMT_DETAIL_SUPPORTED to >>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED >>> to make the name more general. >>> >>> Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make >>> because >>> with the low optimization for debug builds, -fno-omit-frame-pointer is >>> set and stack walking >>> is always permissible. >>> >>> Changed vm.make to optionally include an architecture specific makefile >>> in case some files >>> need to be compiled with special options such as >>> -fno-omit-frame-pointer. >>> >>> Thanks. >>> >>> joe > From goetz.lindenmaier at sap.com Thu Jul 4 05:39:42 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Jul 2013 12:39:42 +0000 Subject: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. In-Reply-To: <51D48274.9090707@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF1D63@DEWDFEMB12A.global.corp.sap> <51D48274.9090707@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF2160@DEWDFEMB12A.global.corp.sap> Hi, pop_frame_in_process will be cleared when the frame manager calls the interpreter loop again with the message popping_frame. 6953477 broke our pop_frame tests. I don't see though how pop_frame could be tested with 6953477, as the capability is not set if CC_INTERP is defined. (I removed a ShouldNotReachHere in the updated change, that was in the wrong patch of the port but belongs here.) _return_kind is unused. In the updated webrev I also removed the definition of the field. I also fixed the syntax stuff. This is the new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet-2/ Best regards, Goetz. From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Mittwoch, 3. Juli 2013 21:59 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov Subject: Re: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. Hi Goetz, The fix looks good in general. Thank you for doing this! A couple of comments: src/share/vm/interpreter/bytecodeInterpreter.cpp: It looks like you have accidentally dropped the line: 2981 THREAD->clr_pop_frame_in_process(); What is the reason that the following lines are deleted? (the same as Vladimir already asked): 2962 istate->set_return_kind((Bytecodes::Code)opcode); 2987 istate->set_return_kind((Bytecodes::Code)opcode); Thanks, Serguei On 7/3/13 3:24 AM, Lindenmaier, Goetz wrote: Hi, This change implements jvmti early return and pop frame support in the cppInterpreter. To work properly, the corresponding properties in JvmtiManageCapabilities::init_onload_capabilities() must be enabled. We will add this in a later change. I would be happy about a review of this change: http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet/ Best regards, Goetz. From alejandro.murillo at oracle.com Thu Jul 4 06:58:24 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 04 Jul 2013 13:58:24 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130704135833.0D2DC487CC@hg.openjdk.java.net> Changeset: 67131c21181a Author: katleman Date: 2013-07-03 16:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/67131c21181a Added tag jdk7u40-b32 for changeset 9658c969b7cf ! .hgtags Changeset: 15706a73a506 Author: amurillo Date: 2013-07-04 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/15706a73a506 Merge Changeset: 0b9149d22ee0 Author: amurillo Date: 2013-07-04 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0b9149d22ee0 Added tag hs24-b52 for changeset 15706a73a506 ! .hgtags From volker.simonis at gmail.com Thu Jul 4 09:07:32 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Jul 2013 18:07:32 +0200 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles Message-ID: Hi, can sombody please review this change. It implements the relevant HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't touch any existing platforms (but of course testing it on your closed platforms - especially ppc - is probably necessary and much appreciated). It also contains two small fixes for the CORE build (one is a type and the other is necessary to accomodate to the changes in "8008772: remove gamma launcher") in 'make/Makefile' for which I didn't wanted to open an extra bug for. Notice that this patch determines the name and location of the platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with 0009_linux_ppc_files.patch. http://cr.openjdk.java.net/~simonis/webrevs/8019922/ Thank you and best regards, Volker From Alan.Bateman at oracle.com Thu Jul 4 09:41:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Jul 2013 17:41:49 +0100 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D494E9.2020200@oracle.com> References: <51D494E9.2020200@oracle.com> Message-ID: <51D5A5CD.2070805@oracle.com> On 03/07/2013 22:17, BILL PITTORE wrote: > These changes address bug 8014135 which adds support for statically > linked agents in the VM. This is a followup to the recent JNI spec > changes that addressed statically linked JNI libraries( 8005716). > The JEP for this change is the same JEP as the JNI changes: > http://openjdk.java.net/jeps/178 > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ I looked at the javadoc updates to the attach API. One thing that doesn't come across very clearly is the mapping from the agentLibrary parameter to "agent-lib-name". I think that needs a few words so that it's clear that it is not literally looking for "Agent_OnAttach_agent-lib-name" but rather "Agent_OnAttach" + where is the library name in the agentLibrary parameter. As I recall, the JVM Tool Interface is supposed to be referred so as "JVM TI" rather than "JVMTI". Otherwise it looks okay to me. -Alan From roland.westrelin at oracle.com Thu Jul 4 09:41:07 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 04 Jul 2013 16:41:07 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20130704164132.8FAC2487DA@hg.openjdk.java.net> Changeset: f765bfec8f07 Author: kvn Date: 2013-07-01 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f765bfec8f07 8006629: NEED_TEST: need test for JDK-8001071 Summary: added regression test Reviewed-by: kvn, coleenp Contributed-by: Filipp Zhinkin + test/runtime/8001071/Test8001071.java + test/runtime/8001071/Test8001071.sh Changeset: a023ec3452c7 Author: simonis Date: 2013-07-01 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a023ec3452c7 8019382: PPC64: Fix bytecodeInterpreter to compile with '-Wunused-value' Summary: cast the offending expressions to (void) Reviewed-by: kvn, coleenp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 2b3fe74309b6 Author: kvn Date: 2013-07-02 10:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2b3fe74309b6 8019247: SIGSEGV in compiled method c8e.e.t_.getArray(Ljava/lang/Class;)[Ljava/lang/Object Summary: Undo recent changes (and add more comments) in Ideal_allocation(). Reviewed-by: roland ! src/share/vm/opto/graphKit.cpp Changeset: 738e04fb1232 Author: anoll Date: 2013-07-02 07:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/738e04fb1232 8014972: Crash with specific values for -XX:InitialCodeCacheSize=500K -XX:ReservedCodeCacheSize=500k Summary: Introduce a minimum code cache size that guarantees that the VM can startup. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b800986664f4 Author: drchase Date: 2013-07-02 20:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b800986664f4 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 Summary: add intrinsics using new instruction to interpreter, C1, C2, for suitable x86; add test Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp + src/cpu/x86/vm/stubRoutines_x86.cpp + src/cpu/x86/vm/stubRoutines_x86.hpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7088419/CRCTest.java Changeset: c1bd7b5bdc70 Author: twisti Date: 2013-07-02 20:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c1bd7b5bdc70 8017571: JSR292: JVM crashing on assert "cast to instanceKlass" while producing MethodHandle for array methods with MethodHandle.findVirtual Reviewed-by: kvn ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflection.cpp Changeset: bed0eddd82cd Author: twisti Date: 2013-07-02 22:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bed0eddd82cd Merge Changeset: 8b789ce47503 Author: roland Date: 2013-07-04 01:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8b789ce47503 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: fece0ee013fc Author: roland Date: 2013-07-04 03:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fece0ee013fc Merge From alejandro.murillo at oracle.com Thu Jul 4 11:55:01 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 04 Jul 2013 18:55:01 +0000 Subject: hg: hsx/hsx24/hotspot: 8019933: new hotspot build - hs24-b53 Message-ID: <20130704185506.96481487DC@hg.openjdk.java.net> Changeset: b29fc5f70d65 Author: amurillo Date: 2013-07-04 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b29fc5f70d65 8019933: new hotspot build - hs24-b53 Reviewed-by: jcoomes ! make/hotspot_version From alejandro.murillo at oracle.com Thu Jul 4 17:44:00 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 05 Jul 2013 00:44:00 +0000 Subject: hg: hsx/hsx25/hotspot: 37 new changesets Message-ID: <20130705004607.73EB8487E1@hg.openjdk.java.net> Changeset: 2bfa00fac03f Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2bfa00fac03f Added tag jdk8-b97 for changeset d197d377ab2e ! .hgtags Changeset: 8c4424890028 Author: amurillo Date: 2013-06-28 02:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8c4424890028 8019302: new hotspot build - hs25-b40 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8cff1de240de Author: zgu Date: 2013-06-25 17:22 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8cff1de240de 8017478: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites Summary: Fixed possible NULL pointer that caused SIGSEGV Reviewed-by: coleenp, acorn, ctornqvi ! src/share/vm/services/memReporter.cpp Changeset: c14867f95c60 Author: zgu Date: 2013-06-25 14:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c14867f95c60 Merge Changeset: 38ea2efa32a7 Author: kevinw Date: 2013-06-26 00:01 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/38ea2efa32a7 8010278: SA: provide mechanism for using an alternative SA debugger back-end. Reviewed-by: sla, dsamersoff ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxOopHandle.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java Changeset: 8eb40545e209 Author: kevinw Date: 2013-06-26 11:00 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8eb40545e209 Merge Changeset: 221df7e37535 Author: iklam Date: 2013-06-27 10:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/221df7e37535 8016075: Win32 crash with CDS enabled and small heap size Summary: Fixed MetaspaceShared::is_in_shared_space Reviewed-by: coleenp, hseigel ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: e0fe0c9a88da Author: nloodin Date: 2013-06-28 14:05 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e0fe0c9a88da Merge Changeset: bb4f2b27e824 Author: dcubed Date: 2013-06-29 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bb4f2b27e824 Merge Changeset: 97c5acae48be Author: hseigel Date: 2013-06-30 09:59 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/97c5acae48be 7007040: Check of capacity paramenters in JNI_PushLocalFrame is wrong Summary: changed AND to OR Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/jni.cpp Changeset: 068b406e307f Author: fparain Date: 2013-07-01 09:13 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/068b406e307f 7060111: race condition in VMError::report_and_die() Reviewed-by: zgu, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: acfa2cc19146 Author: rbackman Date: 2013-06-12 09:49 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/acfa2cc19146 8016444: Duplicate zombie check in safe_for_sender Reviewed-by: dholmes, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/share/vm/memory/referenceProcessorStats.hpp Changeset: 993dfb57c575 Author: egahlin Date: 2013-06-26 17:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/993dfb57c575 8016331: Minor issues in event tracing metadata Reviewed-by: stefank, brutisso, mgronlun ! src/share/vm/trace/trace.xml Changeset: 7f11c12d7a90 Author: sspitsyn Date: 2013-07-01 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7f11c12d7a90 8009204: [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris Summary: The fix is basically a backport of JDK-7019165 (pstack issue) to jhelper.d. Reviewed-by: coleenp, sspitsyn Contributed-by: tomas.hurka at oracle.com ! src/os/solaris/dtrace/jhelper.d Changeset: de2d15ce3d4a Author: coleenp Date: 2013-07-02 08:42 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/de2d15ce3d4a 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadata space could occur when metaspace is almost empty Summary: Allocate medium chunks for class metaspace when class loader has lots of classes Reviewed-by: mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: cedf20e2a655 Author: coleenp Date: 2013-07-02 16:54 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cedf20e2a655 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c92b74c62d97 Author: brutisso Date: 2013-06-27 09:59 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c92b74c62d97 8017483: G1 tests fail with native OOME on Solaris x86 after HeapBaseMinAddress has been increased Summary: Set HeapBaseMinAddress as default rather than ergo Reviewed-by: stefank, jmasa, kvn ! src/share/vm/runtime/arguments.cpp Changeset: 3ea89789ba39 Author: ehelin Date: 2013-06-28 18:28 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3ea89789ba39 Merge Changeset: b30744960351 Author: brutisso Date: 2013-06-30 21:42 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b30744960351 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks. Reviewed-by: tschatzl, brutisso, jmasa, ysr Contributed-by: per.liden at oracle.com ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: 5ea20b3bd249 Author: johnc Date: 2013-07-01 09:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5ea20b3bd249 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed Summary: The assert is invalid when a card is being refined by two different threads and its count crosses the hot threshold - the refinement count will be updated once by each thread triggering the assert. Remove the assert and update the count using a bounded expression. Reviewed-by: jmasa, tamao, brutisso ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp Changeset: 6e3634222155 Author: tamao Date: 2013-06-28 20:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6e3634222155 8017611: Auto corrector for mistyped vm options Summary: The auto corrector for mistyped vm options fuzzy-matches existing flags based on string similarity (Dice's coefficient). Reviewed-by: kvn, dsamersoff, hseigel, johnc ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp + test/gc/arguments/TestUnrecognizedVMOptionsHandling.java Changeset: 536976a22f5f Author: tamao Date: 2013-07-03 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/536976a22f5f Merge Changeset: 70bea4a43c6d Author: tamao Date: 2013-07-03 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/70bea4a43c6d Merge Changeset: ac7193063af8 Author: jiangli Date: 2013-07-01 19:44 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ac7193063af8 8006023: Embedded Builds fail management test because of requirement for UsePerfData being enabled. Summary: Added -XX:+UsePerfData to Test7196045.java. Reviewed-by: dholmes, collins ! test/runtime/7196045/Test7196045.java Changeset: 94aa8de029c5 Author: clucasius Date: 2013-07-03 22:36 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/94aa8de029c5 Merge Changeset: fea6a49c2762 Author: bdelsart Date: 2013-07-04 01:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fea6a49c2762 Merge Changeset: f765bfec8f07 Author: kvn Date: 2013-07-01 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f765bfec8f07 8006629: NEED_TEST: need test for JDK-8001071 Summary: added regression test Reviewed-by: kvn, coleenp Contributed-by: Filipp Zhinkin + test/runtime/8001071/Test8001071.java + test/runtime/8001071/Test8001071.sh Changeset: a023ec3452c7 Author: simonis Date: 2013-07-01 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a023ec3452c7 8019382: PPC64: Fix bytecodeInterpreter to compile with '-Wunused-value' Summary: cast the offending expressions to (void) Reviewed-by: kvn, coleenp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 2b3fe74309b6 Author: kvn Date: 2013-07-02 10:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2b3fe74309b6 8019247: SIGSEGV in compiled method c8e.e.t_.getArray(Ljava/lang/Class;)[Ljava/lang/Object Summary: Undo recent changes (and add more comments) in Ideal_allocation(). Reviewed-by: roland ! src/share/vm/opto/graphKit.cpp Changeset: 738e04fb1232 Author: anoll Date: 2013-07-02 07:51 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/738e04fb1232 8014972: Crash with specific values for -XX:InitialCodeCacheSize=500K -XX:ReservedCodeCacheSize=500k Summary: Introduce a minimum code cache size that guarantees that the VM can startup. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b800986664f4 Author: drchase Date: 2013-07-02 20:42 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b800986664f4 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 Summary: add intrinsics using new instruction to interpreter, C1, C2, for suitable x86; add test Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp + src/cpu/x86/vm/stubRoutines_x86.cpp + src/cpu/x86/vm/stubRoutines_x86.hpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7088419/CRCTest.java Changeset: c1bd7b5bdc70 Author: twisti Date: 2013-07-02 20:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c1bd7b5bdc70 8017571: JSR292: JVM crashing on assert "cast to instanceKlass" while producing MethodHandle for array methods with MethodHandle.findVirtual Reviewed-by: kvn ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflection.cpp Changeset: bed0eddd82cd Author: twisti Date: 2013-07-02 22:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bed0eddd82cd Merge Changeset: 8b789ce47503 Author: roland Date: 2013-07-04 01:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8b789ce47503 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: fece0ee013fc Author: roland Date: 2013-07-04 03:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fece0ee013fc Merge Changeset: c9dd82da51ed Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c9dd82da51ed Merge Changeset: 30b5b75c42ac Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/30b5b75c42ac Added tag hs25-b40 for changeset c9dd82da51ed ! .hgtags From alejandro.murillo at oracle.com Thu Jul 4 19:40:46 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 05 Jul 2013 02:40:46 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130705024057.79537487E4@hg.openjdk.java.net> Changeset: 2bfa00fac03f Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2bfa00fac03f Added tag jdk8-b97 for changeset d197d377ab2e ! .hgtags Changeset: c9dd82da51ed Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c9dd82da51ed Merge Changeset: 30b5b75c42ac Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/30b5b75c42ac Added tag hs25-b40 for changeset c9dd82da51ed ! .hgtags Changeset: ea4d24c1e0c6 Author: amurillo Date: 2013-07-04 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ea4d24c1e0c6 8019934: new hotspot build - hs25-b41 Reviewed-by: jcoomes ! make/hotspot_version From john.coomes at oracle.com Thu Jul 4 20:32:05 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 03:32:05 +0000 Subject: hg: hsx/hotspot-main: 9 new changesets Message-ID: <20130705033206.AA327487E8@hg.openjdk.java.net> Changeset: f5eb23490e6a Author: erikj Date: 2013-06-27 09:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f5eb23490e6a 8017047: Can't use --with-java-devtools and --with-devkit at the same time Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: e5cf1735638c Author: erikj Date: 2013-06-28 11:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e5cf1735638c 8016605: New files dont apear in src.zip Reviewed-by: tbell ! common/makefiles/JavaCompilation.gmk Changeset: 0871b5799149 Author: erikj Date: 2013-06-28 11:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0871b5799149 8019229: Build Configuration Fail in Windows Platform Reviewed-by: chegar, tbell, dxu ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 0e533ceee717 Author: erikj Date: 2013-06-28 12:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0e533ceee717 8016303: make CONF= isn't working Reviewed-by: tbell ! NewMakefile.gmk Changeset: 78aaf5d3314d Author: erikj Date: 2013-06-28 12:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/78aaf5d3314d 8010385: build with LOG=trace broken on mac Reviewed-by: dholmes, tbell, prr ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/MakeBase.gmk Changeset: dd3b314f4471 Author: erikj Date: 2013-07-01 15:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/dd3b314f4471 8009744: build-infra: REGRESSION: Publisher was NOT set for some JDK files Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: b2b87e9e8683 Author: erikj Date: 2013-07-02 15:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b2b87e9e8683 8019537: jdk8-build prebuild fails in source bundle generation, The path of TOOLS_DIR ... is not found Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: a1c1e8bf71f3 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a1c1e8bf71f3 Merge Changeset: 99ad803f8c4e Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/99ad803f8c4e Added tag jdk8-b97 for changeset a1c1e8bf71f3 ! .hgtags From john.coomes at oracle.com Thu Jul 4 20:32:19 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 03:32:19 +0000 Subject: hg: hsx/hotspot-main/jaxp: 3 new changesets Message-ID: <20130705033233.F3D9B487EA@hg.openjdk.java.net> Changeset: c96691d84a7c Author: katleman Date: 2013-06-28 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/c96691d84a7c 8019347: JDK8 b96 source with GPL header errors Reviewed-by: iris, alanb, lancea ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_de.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_es.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_it.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_TW.properties Changeset: 6c830db28d21 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/6c830db28d21 Merge Changeset: 15e5bb51bc0c Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/15e5bb51bc0c Added tag jdk8-b97 for changeset 6c830db28d21 ! .hgtags From john.coomes at oracle.com Thu Jul 4 20:32:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 03:32:10 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b97 for changeset 469995a8e974 Message-ID: <20130705033213.B097F487E9@hg.openjdk.java.net> Changeset: 3370fb6146e4 Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/3370fb6146e4 Added tag jdk8-b97 for changeset 469995a8e974 ! .hgtags From john.coomes at oracle.com Thu Jul 4 20:32:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 03:32:38 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b97 for changeset dcde7f049111 Message-ID: <20130705033244.85163487EB@hg.openjdk.java.net> Changeset: b1fb4612a2ca Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b1fb4612a2ca Added tag jdk8-b97 for changeset dcde7f049111 ! .hgtags From john.coomes at oracle.com Thu Jul 4 20:36:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 03:36:32 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b97 for changeset 1bf1d6ce3042 Message-ID: <20130705033635.B97E1487EF@hg.openjdk.java.net> Changeset: da63a99481da Author: cl Date: 2013-07-04 01:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/da63a99481da Added tag jdk8-b97 for changeset 1bf1d6ce3042 ! .hgtags From john.coomes at oracle.com Thu Jul 4 20:32:55 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 03:32:55 +0000 Subject: hg: hsx/hotspot-main/jdk: 4 new changesets Message-ID: <20130705033446.4CED8487EC@hg.openjdk.java.net> Changeset: 8339c83b16c6 Author: ehelin Date: 2013-07-02 13:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8339c83b16c6 8019500: Exclude MemoryTest.java and MemoryTestAllGC.sh to enable integration Reviewed-by: erikj, alanb ! test/ProblemList.txt Changeset: 87cab043cb5e Author: katleman Date: 2013-06-28 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/87cab043cb5e 8019347: JDK8 b96 source with GPL header errors Reviewed-by: iris, alanb, lancea ! makefiles/sun/awt/ToBin.java ! src/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java ! test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java ! test/java/lang/ThreadGroup/Suspend.java Changeset: 978a95239044 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/978a95239044 Merge Changeset: 4b21dcfdcc3b Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4b21dcfdcc3b Added tag jdk8-b97 for changeset 978a95239044 ! .hgtags From john.coomes at oracle.com Thu Jul 4 20:36:14 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 03:36:14 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b97 for changeset 6a11a81a8824 Message-ID: <20130705033627.36FD4487ED@hg.openjdk.java.net> Changeset: 2364e94ae67b Author: cl Date: 2013-07-04 01:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2364e94ae67b Added tag jdk8-b97 for changeset 6a11a81a8824 ! .hgtags From david.holmes at oracle.com Thu Jul 4 22:21:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Jul 2013 15:21:42 +1000 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: References: Message-ID: <51D657E6.2060606@oracle.com> Hi Volker, This all looks fine to me. A couple of minor comments below. I will also test it but I don't expect to see any conflicts with our other ports. Thanks, David ----- make/defs.make Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the sparcv9 code and reduce this: 288 ifeq ($(BUILDARCH), ppc) 289 ifdef LP64 290 BUILDARCH = ppc64 291 else 292 BUILDARCH = ppc 293 endif 294 endif to 288 ifeq ($(BUILDARCH), ppc) 289 ifdef LP64 290 BUILDARCH = ppc64 291 endif 292 endif --- make/linux/makefiles/defs.make I note you have: HS_ARCH = ppc and this is only used with the SA for which we presently have: ADD_SA_BINARIES/ppc = but you also added: ADD_SA_BINARIES/ppc64 = so was the HS_ARCH setting a typo? --- make/linux/makefiles/gcc.make You added: ARCHFLAG/ppc64 = -m64 which is fine, but then in ppc64.make you also have: CFLAGS += -m64 LFLAGS_VM += -m64 AOUT_FLAGS += -m64 which seems redundant given gcc.make has: 186 CFLAGS += $(ARCHFLAG) 187 AOUT_FLAGS += $(ARCHFLAG) 188 LFLAGS += $(ARCHFLAG) 189 ASFLAGS += $(ARCHFLAG) Also the initial copyright line seems suspect: 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved. Not sure how a new file can have a 2004-2011 copyright year range ?? On 5/07/2013 2:07 AM, Volker Simonis wrote: > Hi, > > can sombody please review this change. It implements the relevant > HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't > touch any existing platforms (but of course testing it on your closed > platforms - especially ppc - is probably necessary and much > appreciated). > > It also contains two small fixes for the CORE build (one is a type and > the other is necessary to accomodate to the changes in "8008772: > remove gamma launcher") in 'make/Makefile' for which I didn't wanted > to open an extra bug for. > > Notice that this patch determines the name and location of the > platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or > src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with > 0009_linux_ppc_files.patch. > > http://cr.openjdk.java.net/~simonis/webrevs/8019922/ > > Thank you and best regards, > Volker > From zhengyu.gu at oracle.com Fri Jul 5 05:18:05 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 05 Jul 2013 08:18:05 -0400 Subject: Request for review: https://jbs.oracle.com/bugs/browse/JDK-8011064 In-Reply-To: <51D45705.1010400@oracle.com> References: <51D45705.1010400@oracle.com> Message-ID: <51D6B97D.8010709@oracle.com> Good to me. Thanks, -Zhengyu On 7/3/2013 12:53 PM, Joseph Provino wrote: > This is a backport to 7 and it integrates cleanly from 8 so it should > be an easy review. > > Bug report:https://jbs.oracle.com/bugs/browse/JDK-8011064 > > Webrev is here: > http://cr.openjdk.java.net/~jprovino/8011064/webrev.7u.00/ > > > Thanks. > > joe From iris.clark at oracle.com Fri Jul 5 12:36:38 2013 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 5 Jul 2013 12:36:38 -0700 (PDT) Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: <51D657E6.2060606@oracle.com> References: <51D657E6.2060606@oracle.com> Message-ID: <262b3e97-c118-403b-851b-f475f31e7625@default> For the copyright, please change "2011" to "2013". This problem would be caught by various scripts later, but since it's been spotted in a pre-commit, it may as well be handled now. Thanks, iris -----Original Message----- From: David Holmes Sent: Thursday, July 04, 2013 10:22 PM To: Volker Simonis Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers Subject: Re: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles Hi Volker, This all looks fine to me. A couple of minor comments below. I will also test it but I don't expect to see any conflicts with our other ports. Thanks, David ----- make/defs.make Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the sparcv9 code and reduce this: 288 ifeq ($(BUILDARCH), ppc) 289 ifdef LP64 290 BUILDARCH = ppc64 291 else 292 BUILDARCH = ppc 293 endif 294 endif to 288 ifeq ($(BUILDARCH), ppc) 289 ifdef LP64 290 BUILDARCH = ppc64 291 endif 292 endif --- make/linux/makefiles/defs.make I note you have: HS_ARCH = ppc and this is only used with the SA for which we presently have: ADD_SA_BINARIES/ppc = but you also added: ADD_SA_BINARIES/ppc64 = so was the HS_ARCH setting a typo? --- make/linux/makefiles/gcc.make You added: ARCHFLAG/ppc64 = -m64 which is fine, but then in ppc64.make you also have: CFLAGS += -m64 LFLAGS_VM += -m64 AOUT_FLAGS += -m64 which seems redundant given gcc.make has: 186 CFLAGS += $(ARCHFLAG) 187 AOUT_FLAGS += $(ARCHFLAG) 188 LFLAGS += $(ARCHFLAG) 189 ASFLAGS += $(ARCHFLAG) Also the initial copyright line seems suspect: 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved. Not sure how a new file can have a 2004-2011 copyright year range ?? On 5/07/2013 2:07 AM, Volker Simonis wrote: > Hi, > > can sombody please review this change. It implements the relevant > HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't > touch any existing platforms (but of course testing it on your closed > platforms - especially ppc - is probably necessary and much > appreciated). > > It also contains two small fixes for the CORE build (one is a type and > the other is necessary to accomodate to the changes in "8008772: > remove gamma launcher") in 'make/Makefile' for which I didn't wanted > to open an extra bug for. > > Notice that this patch determines the name and location of the > platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or > src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with > 0009_linux_ppc_files.patch. > > http://cr.openjdk.java.net/~simonis/webrevs/8019922/ > > Thank you and best regards, > Volker > From serguei.spitsyn at oracle.com Fri Jul 5 18:10:23 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 05 Jul 2013 18:10:23 -0700 Subject: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF2160@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF1D63@DEWDFEMB12A.global.corp.sap> <51D48274.9090707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF2160@DEWDFEMB12A.global.corp.sap> Message-ID: <51D76E7F.60809@oracle.com> Hi Goetz, As before it looks good in general. I'm not sure the following change is correct: - THREAD->clr_pop_frame_in_process(); + } else { + istate->set_msg(return_from_method); } The above will reset the *msg* to the *return_from_method* when it was already set to the *early_return* which is inconsistent with the *popping_frame* case. Could you explain why did you make it for non-popping_frame cases only? It would not surprise me if it does not matter though. :) Also, one more case needs to be added to the BytecodeInterpreter::C_msg(): 322? case BytecodeInterpreter::early_return: return("early_return"); One more comment below... On 7/4/13 5:39 AM, Lindenmaier, Goetz wrote: > > Hi, > > pop_frame_in_process will be cleared when the frame manager calls > > the interpreter loop again with the message popping_frame. > > 6953477 broke our pop_frame tests. I don't see though how pop_frame > > could be tested with 6953477, as the capability is not set > > if CC_INTERP is defined. > It is explicitly disabled in the jvmtiManageCapabilities.cpp: #ifndef CC_INTERP jc.can_pop_frame = 1; jc.can_force_early_return = 1; #endif // !CC_INTERP It is because it was not fully implemented yet for CC_INTERP. You can take the can_force_early_return out of the ifdef. Thanks, Serguei > (I removed a ShouldNotReachHere in the updated change, that was > > in the wrong patch of the port but belongs here.) > > _/return/_kind is unused. In the updated webrev I also removed the > > definition of the field. > > I also fixed the syntax stuff. > > This is the new webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet-2/ > > > Best regards, > > Goetz. > > *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] > *Sent:* Mittwoch, 3. Juli 2013 21:59 > *To:* Lindenmaier, Goetz > *Cc:* 'hotspot-dev at openjdk.java.net'; > 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov > *Subject:* Re: RFR (M): 8019519: PPC64 (part 105): C interpreter: > implement support for jvmti early return. > > Hi Goetz, > > The fix looks good in general. > Thank you for doing this! > > A couple of comments: > > src/share/vm/interpreter/bytecodeInterpreter.cpp: > > It looks like you have accidentally dropped the line: > > 2981 THREAD->clr_pop_frame_in_process(); > > > What is the reason that the following lines are deleted? (the same as > Vladimir already asked): > > 2962 istate->set_return_kind((Bytecodes::Code)opcode); > 2987 istate->set_return_kind((Bytecodes::Code)opcode); > > > Thanks, > Serguei > > On 7/3/13 3:24 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > This change implements jvmti early return and pop frame support > > in the cppInterpreter. To work properly, the corresponding properties in > > JvmtiManageCapabilities::init_onload_capabilities() must be enabled. > > We will add this in a later change. > > > > I would be happy about a review of this change: > > http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet/ > > > > Best regards, > > Goetz. > > > From goetz.lindenmaier at sap.com Sat Jul 6 12:35:06 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 6 Jul 2013 19:35:06 +0000 Subject: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. In-Reply-To: <51D76E7F.60809@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF1D63@DEWDFEMB12A.global.corp.sap> <51D48274.9090707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF2160@DEWDFEMB12A.global.corp.sap> <51D76E7F.60809@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF2C32@DEWDFEMB12A.global.corp.sap> Hi Serguei, >The above will reset the msg to the return_from_method >when it was already set to the early_return which is >inconsistent with the popping_frame case. That's because the frame manager tests for popping_frame. The early_return case is handled as a normal return, we faked the return result in the cppInterpreter code that's in this change. See also http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/874e94d3b21d/src/cpu/ppc/vm/cppInterpreter_ppc.cpp line 1922 > jc.can_force_early_return = 1; We will enable the capabilities in a change later on. Best regards & thanks for your review, Goetz. From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Saturday, July 06, 2013 3:10 AM To: Lindenmaier, Goetz Cc: Vladimir Kozlov; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. Hi Goetz, As before it looks good in general. I'm not sure the following change is correct: - THREAD->clr_pop_frame_in_process(); + } else { + istate->set_msg(return_from_method); } The above will reset the msg to the return_from_method when it was already set to the early_return which is inconsistent with the popping_frame case. Could you explain why did you make it for non-popping_frame cases only? It would not surprise me if it does not matter though. :) Also, one more case needs to be added to the BytecodeInterpreter::C_msg(): 322? case BytecodeInterpreter::early_return: return("early_return"); One more comment below... On 7/4/13 5:39 AM, Lindenmaier, Goetz wrote: Hi, pop_frame_in_process will be cleared when the frame manager calls the interpreter loop again with the message popping_frame. 6953477 broke our pop_frame tests. I don't see though how pop_frame could be tested with 6953477, as the capability is not set if CC_INTERP is defined. It is explicitly disabled in the jvmtiManageCapabilities.cpp: #ifndef CC_INTERP jc.can_pop_frame = 1; jc.can_force_early_return = 1; #endif // !CC_INTERP It is because it was not fully implemented yet for CC_INTERP. You can take the can_force_early_return out of the ifdef. Thanks, Serguei (I removed a ShouldNotReachHere in the updated change, that was in the wrong patch of the port but belongs here.) _return_kind is unused. In the updated webrev I also removed the definition of the field. I also fixed the syntax stuff. This is the new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet-2/ Best regards, Goetz. From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Mittwoch, 3. Juli 2013 21:59 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov Subject: Re: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. Hi Goetz, The fix looks good in general. Thank you for doing this! A couple of comments: src/share/vm/interpreter/bytecodeInterpreter.cpp: It looks like you have accidentally dropped the line: 2981 THREAD->clr_pop_frame_in_process(); What is the reason that the following lines are deleted? (the same as Vladimir already asked): 2962 istate->set_return_kind((Bytecodes::Code)opcode); 2987 istate->set_return_kind((Bytecodes::Code)opcode); Thanks, Serguei On 7/3/13 3:24 AM, Lindenmaier, Goetz wrote: Hi, This change implements jvmti early return and pop frame support in the cppInterpreter. To work properly, the corresponding properties in JvmtiManageCapabilities::init_onload_capabilities() must be enabled. We will add this in a later change. I would be happy about a review of this change: http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet/ Best regards, Goetz. From david.holmes at oracle.com Sun Jul 7 18:19:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Jul 2013 11:19:46 +1000 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: <262b3e97-c118-403b-851b-f475f31e7625@default> References: <51D657E6.2060606@oracle.com> <262b3e97-c118-403b-851b-f475f31e7625@default> Message-ID: <51DA13B2.5020402@oracle.com> Iris, On 6/07/2013 5:36 AM, Iris Clark wrote: > For the copyright, please change "2011" to "2013". What about the 2004 initial year? That doesn't seem right for new files. Seems to be due to copying existing files and renaming. David > This problem would be caught by various scripts later, but since it's been spotted in a pre-commit, it may as well be handled now. > > Thanks, > iris > > -----Original Message----- > From: David Holmes > Sent: Thursday, July 04, 2013 10:22 PM > To: Volker Simonis > Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers > Subject: Re: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles > > Hi Volker, > > This all looks fine to me. A couple of minor comments below. > > I will also test it but I don't expect to see any conflicts with our other ports. > > Thanks, > David > ----- > > make/defs.make > > Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the > sparcv9 code and reduce this: > > 288 ifeq ($(BUILDARCH), ppc) > 289 ifdef LP64 > 290 BUILDARCH = ppc64 > 291 else > 292 BUILDARCH = ppc > 293 endif > 294 endif > > to > > 288 ifeq ($(BUILDARCH), ppc) > 289 ifdef LP64 > 290 BUILDARCH = ppc64 > 291 endif > 292 endif > > --- > > make/linux/makefiles/defs.make > > I note you have: > > HS_ARCH = ppc > > and this is only used with the SA for which we presently have: > > ADD_SA_BINARIES/ppc = > > but you also added: > > ADD_SA_BINARIES/ppc64 = > > so was the HS_ARCH setting a typo? > > --- > > make/linux/makefiles/gcc.make > > You added: > > ARCHFLAG/ppc64 = -m64 > > which is fine, but then in ppc64.make you also have: > > CFLAGS += -m64 > LFLAGS_VM += -m64 > AOUT_FLAGS += -m64 > > which seems redundant given gcc.make has: > > 186 CFLAGS += $(ARCHFLAG) > 187 AOUT_FLAGS += $(ARCHFLAG) > 188 LFLAGS += $(ARCHFLAG) > 189 ASFLAGS += $(ARCHFLAG) > > Also the initial copyright line seems suspect: > > 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved. > > Not sure how a new file can have a 2004-2011 copyright year range ?? > > > On 5/07/2013 2:07 AM, Volker Simonis wrote: >> Hi, >> >> can sombody please review this change. It implements the relevant >> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >> touch any existing platforms (but of course testing it on your closed >> platforms - especially ppc - is probably necessary and much >> appreciated). >> >> It also contains two small fixes for the CORE build (one is a type and >> the other is necessary to accomodate to the changes in "8008772: >> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >> to open an extra bug for. >> >> Notice that this patch determines the name and location of the >> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >> 0009_linux_ppc_files.patch. >> >> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >> >> Thank you and best regards, >> Volker >> From dean.long at oracle.com Sun Jul 7 23:34:30 2013 From: dean.long at oracle.com (Dean Long) Date: Sun, 07 Jul 2013 23:34:30 -0700 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: <51DA13B2.5020402@oracle.com> References: <51D657E6.2060606@oracle.com> <262b3e97-c118-403b-851b-f475f31e7625@default> <51DA13B2.5020402@oracle.com> Message-ID: <51DA5D76.2050108@oracle.com> I had a similar question. Do the copyright dates follow the file or the content of the file? I assume they follow the content, and renaming a file wouldn't mean resetting the initial year. So copying a file and then modifying it would mean keeping the initial year because of the copied (old) content? dl On 7/7/2013 6:19 PM, David Holmes wrote: > Iris, > > On 6/07/2013 5:36 AM, Iris Clark wrote: >> For the copyright, please change "2011" to "2013". > > What about the 2004 initial year? That doesn't seem right for new > files. Seems to be due to copying existing files and renaming. > > David > >> This problem would be caught by various scripts later, but since it's >> been spotted in a pre-commit, it may as well be handled now. >> >> Thanks, >> iris >> >> -----Original Message----- >> From: David Holmes >> Sent: Thursday, July 04, 2013 10:22 PM >> To: Volker Simonis >> Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers >> Subject: Re: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 >> support in HotSpot makefiles >> >> Hi Volker, >> >> This all looks fine to me. A couple of minor comments below. >> >> I will also test it but I don't expect to see any conflicts with our >> other ports. >> >> Thanks, >> David >> ----- >> >> make/defs.make >> >> Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the >> sparcv9 code and reduce this: >> >> 288 ifeq ($(BUILDARCH), ppc) >> 289 ifdef LP64 >> 290 BUILDARCH = ppc64 >> 291 else >> 292 BUILDARCH = ppc >> 293 endif >> 294 endif >> >> to >> >> 288 ifeq ($(BUILDARCH), ppc) >> 289 ifdef LP64 >> 290 BUILDARCH = ppc64 >> 291 endif >> 292 endif >> >> --- >> >> make/linux/makefiles/defs.make >> >> I note you have: >> >> HS_ARCH = ppc >> >> and this is only used with the SA for which we presently have: >> >> ADD_SA_BINARIES/ppc = >> >> but you also added: >> >> ADD_SA_BINARIES/ppc64 = >> >> so was the HS_ARCH setting a typo? >> >> --- >> >> make/linux/makefiles/gcc.make >> >> You added: >> >> ARCHFLAG/ppc64 = -m64 >> >> which is fine, but then in ppc64.make you also have: >> >> CFLAGS += -m64 >> LFLAGS_VM += -m64 >> AOUT_FLAGS += -m64 >> >> which seems redundant given gcc.make has: >> >> 186 CFLAGS += $(ARCHFLAG) >> 187 AOUT_FLAGS += $(ARCHFLAG) >> 188 LFLAGS += $(ARCHFLAG) >> 189 ASFLAGS += $(ARCHFLAG) >> >> Also the initial copyright line seems suspect: >> >> 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All >> rights reserved. >> >> Not sure how a new file can have a 2004-2011 copyright year range ?? >> >> >> On 5/07/2013 2:07 AM, Volker Simonis wrote: >>> Hi, >>> >>> can sombody please review this change. It implements the relevant >>> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >>> touch any existing platforms (but of course testing it on your closed >>> platforms - especially ppc - is probably necessary and much >>> appreciated). >>> >>> It also contains two small fixes for the CORE build (one is a type and >>> the other is necessary to accomodate to the changes in "8008772: >>> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >>> to open an extra bug for. >>> >>> Notice that this patch determines the name and location of the >>> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >>> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >>> 0009_linux_ppc_files.patch. >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >>> >>> Thank you and best regards, >>> Volker >>> From david.holmes at oracle.com Sun Jul 7 23:47:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Jul 2013 16:47:48 +1000 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: <51DA5D76.2050108@oracle.com> References: <51D657E6.2060606@oracle.com> <262b3e97-c118-403b-851b-f475f31e7625@default> <51DA13B2.5020402@oracle.com> <51DA5D76.2050108@oracle.com> Message-ID: <51DA6094.8070004@oracle.com> On 8/07/2013 4:34 PM, Dean Long wrote: > I had a similar question. Do the copyright dates follow the file or the > content of the file? I assume they follow the content, > and renaming a file wouldn't mean resetting the initial year. So > copying a file and then modifying it would mean > keeping the initial year because of the copied (old) content? Yes Joe Darcy also suggested that in separate email. But as I posited to him it seems odd that if you copy the file and edit it you get one copyright notice, but if you created a new file with content based on what you read in the existing file, then it gets a different copyright notice. Seems somewhat arbitrary. I think I'll just let this drop and henceforth pay no attention to copyright notices during code reviews. It just isn't worth the pain. :) Cheers, David > dl > > On 7/7/2013 6:19 PM, David Holmes wrote: >> Iris, >> >> On 6/07/2013 5:36 AM, Iris Clark wrote: >>> For the copyright, please change "2011" to "2013". >> >> What about the 2004 initial year? That doesn't seem right for new >> files. Seems to be due to copying existing files and renaming. >> >> David >> >>> This problem would be caught by various scripts later, but since it's >>> been spotted in a pre-commit, it may as well be handled now. >>> >>> Thanks, >>> iris >>> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Thursday, July 04, 2013 10:22 PM >>> To: Volker Simonis >>> Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers >>> Subject: Re: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 >>> support in HotSpot makefiles >>> >>> Hi Volker, >>> >>> This all looks fine to me. A couple of minor comments below. >>> >>> I will also test it but I don't expect to see any conflicts with our >>> other ports. >>> >>> Thanks, >>> David >>> ----- >>> >>> make/defs.make >>> >>> Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the >>> sparcv9 code and reduce this: >>> >>> 288 ifeq ($(BUILDARCH), ppc) >>> 289 ifdef LP64 >>> 290 BUILDARCH = ppc64 >>> 291 else >>> 292 BUILDARCH = ppc >>> 293 endif >>> 294 endif >>> >>> to >>> >>> 288 ifeq ($(BUILDARCH), ppc) >>> 289 ifdef LP64 >>> 290 BUILDARCH = ppc64 >>> 291 endif >>> 292 endif >>> >>> --- >>> >>> make/linux/makefiles/defs.make >>> >>> I note you have: >>> >>> HS_ARCH = ppc >>> >>> and this is only used with the SA for which we presently have: >>> >>> ADD_SA_BINARIES/ppc = >>> >>> but you also added: >>> >>> ADD_SA_BINARIES/ppc64 = >>> >>> so was the HS_ARCH setting a typo? >>> >>> --- >>> >>> make/linux/makefiles/gcc.make >>> >>> You added: >>> >>> ARCHFLAG/ppc64 = -m64 >>> >>> which is fine, but then in ppc64.make you also have: >>> >>> CFLAGS += -m64 >>> LFLAGS_VM += -m64 >>> AOUT_FLAGS += -m64 >>> >>> which seems redundant given gcc.make has: >>> >>> 186 CFLAGS += $(ARCHFLAG) >>> 187 AOUT_FLAGS += $(ARCHFLAG) >>> 188 LFLAGS += $(ARCHFLAG) >>> 189 ASFLAGS += $(ARCHFLAG) >>> >>> Also the initial copyright line seems suspect: >>> >>> 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All >>> rights reserved. >>> >>> Not sure how a new file can have a 2004-2011 copyright year range ?? >>> >>> >>> On 5/07/2013 2:07 AM, Volker Simonis wrote: >>>> Hi, >>>> >>>> can sombody please review this change. It implements the relevant >>>> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >>>> touch any existing platforms (but of course testing it on your closed >>>> platforms - especially ppc - is probably necessary and much >>>> appreciated). >>>> >>>> It also contains two small fixes for the CORE build (one is a type and >>>> the other is necessary to accomodate to the changes in "8008772: >>>> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >>>> to open an extra bug for. >>>> >>>> Notice that this patch determines the name and location of the >>>> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >>>> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >>>> 0009_linux_ppc_files.patch. >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >>>> >>>> Thank you and best regards, >>>> Volker >>>> > From serguei.spitsyn at oracle.com Mon Jul 8 01:33:28 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 08 Jul 2013 01:33:28 -0700 Subject: RFR (M): 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF2C32@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF1D63@DEWDFEMB12A.global.corp.sap> <51D48274.9090707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF2160@DEWDFEMB12A.global.corp.sap> <51D76E7F.60809@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF2C32@DEWDFEMB12A.global.corp.sap> Message-ID: <51DA7958.2090406@oracle.com> Hi Goetz, Thank you for the explanations. A thumbs up from me. Thanks, Serguei On 7/6/13 12:35 PM, Lindenmaier, Goetz wrote: > > Hi Serguei, > > > >The above will reset the *msg* to the *return_from_method* > >when it was already set to the *early_return* which is > >inconsistent with the *popping_frame* case. > > That's because the frame manager tests for popping_frame. > > The early_return case is handled as a normal return, we faked the > > return result in the cppInterpreter code that's in this change. > > See also > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/874e94d3b21d/src/cpu/ppc/vm/cppInterpreter_ppc.cpp > > line 1922 > > > > jc.can_force_early_return = 1; > > We will enable the capabilities in a change later on. > > Best regards & thanks for your review, > > Goetz. > > *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] > *Sent:* Saturday, July 06, 2013 3:10 AM > *To:* Lindenmaier, Goetz > *Cc:* Vladimir Kozlov; 'hotspot-dev at openjdk.java.net'; > 'ppc-aix-port-dev at openjdk.java.net' > *Subject:* Re: RFR (M): 8019519: PPC64 (part 105): C interpreter: > implement support for jvmti early return. > > > Hi Goetz, > > As before it looks good in general. > > I'm not sure the following change is correct: > > > - THREAD->clr_pop_frame_in_process(); > + } else { > + istate->set_msg(return_from_method); > } > > > The above will reset the *msg* to the *return_from_method* > when it was already set to the *early_return* which is > inconsistent with the *popping_frame* case. > > Could you explain why did you make it for non-popping_frame cases only? > It would not surprise me if it does not matter though. :) > > > Also, one more case needs to be added to the BytecodeInterpreter::C_msg(): > > 322? case BytecodeInterpreter::early_return: return("early_return"); > > > > One more comment below... > > > On 7/4/13 5:39 AM, Lindenmaier, Goetz wrote: > > Hi, > > pop_frame_in_process will be cleared when the frame manager calls > > the interpreter loop again with the message popping_frame. > > 6953477 broke our pop_frame tests. I don't see though how pop_frame > > could be tested with 6953477, as the capability is not set > > if CC_INTERP is defined. > > > It is explicitly disabled in the jvmtiManageCapabilities.cpp: > #ifndef CC_INTERP > jc.can_pop_frame = 1; > jc.can_force_early_return = 1; > #endif // !CC_INTERP > > It is because it was not fully implemented yet for CC_INTERP. > You can take the can_force_early_return out of the ifdef. > > > Thanks, > Serguei > > > (I removed a ShouldNotReachHere in the updated change, that was > > in the wrong patch of the port but belongs here.) > > _/return/_kind is unused. In the updated webrev I also removed the > > definition of the field. > > I also fixed the syntax stuff. > > This is the new webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet-2/ > > > Best regards, > > Goetz. > > *From:*serguei.spitsyn at oracle.com > [mailto:serguei.spitsyn at oracle.com] > *Sent:* Mittwoch, 3. Juli 2013 21:59 > *To:* Lindenmaier, Goetz > *Cc:* 'hotspot-dev at openjdk.java.net > '; > 'ppc-aix-port-dev at openjdk.java.net > '; Vladimir Kozlov > *Subject:* Re: RFR (M): 8019519: PPC64 (part 105): C interpreter: > implement support for jvmti early return. > > Hi Goetz, > > The fix looks good in general. > Thank you for doing this! > > A couple of comments: > > src/share/vm/interpreter/bytecodeInterpreter.cpp: > > It looks like you have accidentally dropped the line: > > 2981 THREAD->clr_pop_frame_in_process(); > > > What is the reason that the following lines are deleted? (the same as > Vladimir already asked): > > 2962 istate->set_return_kind((Bytecodes::Code)opcode); > 2987 istate->set_return_kind((Bytecodes::Code)opcode); > > > Thanks, > Serguei > > On 7/3/13 3:24 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > This change implements jvmti early return and pop frame support > > in the cppInterpreter. To work properly, the corresponding properties in > > JvmtiManageCapabilities::init_onload_capabilities() must be enabled. > > We will add this in a later change. > > > > I would be happy about a review of this change: > > http://cr.openjdk.java.net/~goetz/webrevs/8019519-cInter_earlyRet/ > > > > Best regards, > > Goetz. > > > From goetz.lindenmaier at sap.com Mon Jul 8 05:45:13 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Jul 2013 12:45:13 +0000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> Hi, This is in preparation of the PPC AIX port. A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. This leads to wrong configurations of shared files on Aix where IA64 is used. This change replaces uses of "IA64" by "IA64 && !AIX". To reduce the complexity we propose to simplify two matters: Since the initial checkin objectMonitor.cpp and synchronizer.cpp define #define ATTR __attribute__((noinline)) claiming this is needed to avoid a gcc build time error with - at that time - old gcc versions. This define depends on IA64. We remove it altogether. prims/forte.cpp uses a lot of different mechanisms all disabling forte support on windows, apple and ia64. We would have to add Aix. Instead, we propose to use a check for the supported platforms (see webrev). We could also add a macro SUPPORTS_FORTE that is defined in the corresponding makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 directories. Are there other platforms that need to be supported? I derived the platforms from the comment in forte.cpp. Please review this change. I'm happy to incorporate your comments. http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset Best regards, Goetz. From aph at redhat.com Mon Jul 8 07:25:05 2013 From: aph at redhat.com (Andrew Haley) Date: Mon, 08 Jul 2013 15:25:05 +0100 Subject: AArch64 port first release Message-ID: <51DACBC1.7050601@redhat.com> I'm pleased to announce our first release of Java for the ARMv8 64-bit architecture. This is a whole new port, completely unrelated to to the 32-bit ARM JDK. http://en.wikipedia.org/wiki/AArch64#ARMv8_and_64-bit Project status: This port is still very much a work in progress, but it passes its tests and it's good enough to run most Java programs. It is not complete. We're missing support for optional features such as biased locking and JVMTI. Also, it's rather scrappy in some places and the code could be more efficient and more idiomatic in many other places. Patches welcome! The template interpreter and the C1 compiler are done. The C2 compiler is still at a rather early stage. You don't need an ARMv8 to test and run the port. We've written a small simulator that links into the JVM, so you can run this port just like native Java on any 64-bit x86 GNU/Linux system. We also provide advanced debugging capabilities via a set of GDB extensions. This provides the best interactive debugging environment that I have ever seen for a Java VM. You also can run on ARM's Fast Model if you prefer. We've provided full build instructions, but we'll help you if you get stuck. We want people to try it out. I feel that I have to end with an apology. When I started this port I wanted it to be an exemplary free software project: open discussion, open development, and the free exchange of ideas. It hasn't worked out that way. We needed very detailed technical information about the ARMv8 architecture long before it was made public, and ARM were kind enough to give us what we needed. However, there was a caveat: we couldn't make it public. So, we've been in stealth mode until a few weeks ago. My thanks go out to the legal teams who worked hard to make this release possible. Also, a big shout to Mark Reinhold for sorting out all the crazy problems we had with OpenJDK's source code repository. http://hg.openjdk.java.net/aarch64-port/jdk8/raw-file/tip/README.aarch64 Web: http://openjdk.java.net/projects/aarch64-port/ Mailing list: http://mail.openjdk.java.net/mailman/listinfo/aarch64-port-dev Andrew. From goetz.lindenmaier at sap.com Mon Jul 8 07:31:53 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Jul 2013 14:31:53 +0000 Subject: RFR (XS): Fix after 8014972 Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF3731@DEWDFEMB12A.global.corp.sap> Hi, The flag introduced by 8014972 is not defined if Hotspot is built without a compiler (zero, ppc64 core build). Please open a bug for this and review the fix. http://cr.openjdk.java.net/~goetz/webrevs/fix_after_8014972/ Best regards, Goetz. From aleksey.shipilev at oracle.com Mon Jul 8 07:58:57 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 08 Jul 2013 18:58:57 +0400 Subject: AArch64 port first release In-Reply-To: <51DACBC1.7050601@redhat.com> References: <51DACBC1.7050601@redhat.com> Message-ID: <51DAD3B1.5080709@oracle.com> Great news! On 07/08/2013 06:25 PM, Andrew Haley wrote: > We've provided full build instructions, but we'll help you if you get > stuck. We want people to try it out. Do you happen to have the ARMv8 in silica for this work? If so, I'm anxious to see the results for jcstress run on that port: http://openjdk.java.net/projects/code-tools/jcstress/ (I don't think it makes sense to run on simulator. Although it can showcase the simulator bugs?) -Aleksey. From aph at redhat.com Mon Jul 8 08:02:19 2013 From: aph at redhat.com (Andrew Haley) Date: Mon, 08 Jul 2013 16:02:19 +0100 Subject: AArch64 port first release In-Reply-To: <51DAD3B1.5080709@oracle.com> References: <51DACBC1.7050601@redhat.com> <51DAD3B1.5080709@oracle.com> Message-ID: <51DAD47B.1010103@redhat.com> On 07/08/2013 03:58 PM, Aleksey Shipilev wrote: > Great news! > > On 07/08/2013 06:25 PM, Andrew Haley wrote: >> We've provided full build instructions, but we'll help you if you get >> stuck. We want people to try it out. > > Do you happen to have the ARMv8 in silica for this work? If I told you that I'd have to kill myself. ;-) > If so, I'm > anxious to see the results for jcstress run on that port: > http://openjdk.java.net/projects/code-tools/jcstress/ > > (I don't think it makes sense to run on simulator. Although it can > showcase the simulator bugs?) OK, thanks. We can simulate buffered memory, so it might be worth trying even on a simulator. Andrew. From volker.simonis at gmail.com Mon Jul 8 08:42:32 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Jul 2013 17:42:32 +0200 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: <51D657E6.2060606@oracle.com> References: <51D657E6.2060606@oracle.com> Message-ID: Hi David, thank you for the review. I prepared a new webrev according to your suggestions: http://cr.openjdk.java.net/~simonis/webrevs/8019922.v2/ Please find my comments inline: Thank you and best regards, Volker On Fri, Jul 5, 2013 at 7:21 AM, David Holmes wrote: > Hi Volker, > > This all looks fine to me. A couple of minor comments below. > > I will also test it but I don't expect to see any conflicts with our other > ports. > > Thanks, > David > ----- > > make/defs.make > > Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the > sparcv9 code and reduce this: > > 288 ifeq ($(BUILDARCH), ppc) > 289 ifdef LP64 > 290 BUILDARCH = ppc64 > 291 else > 292 BUILDARCH = ppc > 293 endif > 294 endif > > to > > 288 ifeq ($(BUILDARCH), ppc) > 289 ifdef LP64 > 290 BUILDARCH = ppc64 > 291 endif > 292 endif > > --- fixed as suggested. > > make/linux/makefiles/defs.make > > I note you have: > > HS_ARCH = ppc > > and this is only used with the SA for which we presently have: > > ADD_SA_BINARIES/ppc = > > but you also added: > > ADD_SA_BINARIES/ppc64 = > > so was the HS_ARCH setting a typo? > > --- Well, I did it in the same way as the other architectures did it:) Moreover, HS_ARCH is also used in make/Makefile. > > make/linux/makefiles/gcc.make > > You added: > > ARCHFLAG/ppc64 = -m64 > > which is fine, but then in ppc64.make you also have: > > CFLAGS += -m64 > LFLAGS_VM += -m64 > AOUT_FLAGS += -m64 > > which seems redundant given gcc.make has: > > 186 CFLAGS += $(ARCHFLAG) > 187 AOUT_FLAGS += $(ARCHFLAG) > 188 LFLAGS += $(ARCHFLAG) > 189 ASFLAGS += $(ARCHFLAG) > You're right. I removed the '-m64' settings from ppc64.make Also, 'LAUNCHERFLAGS' isn't used anymore so I removed it from pp464.make as well. The same applies to 'AOUT_FLAGS' which isn't necessary for our build. > Also the initial copyright line seems suspect: > > 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights > reserved. > > Not sure how a new file can have a 2004-2011 copyright year range ?? > That was a copy-paste issue. After the lengthy discussions below I changed it to "2004, 2013" to keep things simple:) > > > On 5/07/2013 2:07 AM, Volker Simonis wrote: >> >> Hi, >> >> can sombody please review this change. It implements the relevant >> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >> touch any existing platforms (but of course testing it on your closed >> platforms - especially ppc - is probably necessary and much >> appreciated). >> >> It also contains two small fixes for the CORE build (one is a type and >> the other is necessary to accomodate to the changes in "8008772: >> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >> to open an extra bug for. >> >> Notice that this patch determines the name and location of the >> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >> 0009_linux_ppc_files.patch. >> >> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >> >> Thank you and best regards, >> Volker >> > From iris.clark at oracle.com Mon Jul 8 09:30:52 2013 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 8 Jul 2013 09:30:52 -0700 (PDT) Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: <51DA13B2.5020402@oracle.com> References: <51D657E6.2060606@oracle.com> <262b3e97-c118-403b-851b-f475f31e7625@default> <51DA13B2.5020402@oracle.com> Message-ID: Hi, David. The copyright follows the content, so the initial year should not be changed. iris -----Original Message----- From: David Holmes Sent: Sunday, July 07, 2013 6:20 PM To: Iris Clark Cc: Volker Simonis; ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers Subject: Re: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles Iris, On 6/07/2013 5:36 AM, Iris Clark wrote: > For the copyright, please change "2011" to "2013". What about the 2004 initial year? That doesn't seem right for new files. Seems to be due to copying existing files and renaming. David > This problem would be caught by various scripts later, but since it's been spotted in a pre-commit, it may as well be handled now. > > Thanks, > iris > > -----Original Message----- > From: David Holmes > Sent: Thursday, July 04, 2013 10:22 PM > To: Volker Simonis > Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers > Subject: Re: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 > support in HotSpot makefiles > > Hi Volker, > > This all looks fine to me. A couple of minor comments below. > > I will also test it but I don't expect to see any conflicts with our other ports. > > Thanks, > David > ----- > > make/defs.make > > Minor observation: As BUILDARCH defaults to SRCARCH you can emulate > the > sparcv9 code and reduce this: > > 288 ifeq ($(BUILDARCH), ppc) > 289 ifdef LP64 > 290 BUILDARCH = ppc64 > 291 else > 292 BUILDARCH = ppc > 293 endif > 294 endif > > to > > 288 ifeq ($(BUILDARCH), ppc) > 289 ifdef LP64 > 290 BUILDARCH = ppc64 > 291 endif > 292 endif > > --- > > make/linux/makefiles/defs.make > > I note you have: > > HS_ARCH = ppc > > and this is only used with the SA for which we presently have: > > ADD_SA_BINARIES/ppc = > > but you also added: > > ADD_SA_BINARIES/ppc64 = > > so was the HS_ARCH setting a typo? > > --- > > make/linux/makefiles/gcc.make > > You added: > > ARCHFLAG/ppc64 = -m64 > > which is fine, but then in ppc64.make you also have: > > CFLAGS += -m64 > LFLAGS_VM += -m64 > AOUT_FLAGS += -m64 > > which seems redundant given gcc.make has: > > 186 CFLAGS += $(ARCHFLAG) > 187 AOUT_FLAGS += $(ARCHFLAG) > 188 LFLAGS += $(ARCHFLAG) > 189 ASFLAGS += $(ARCHFLAG) > > Also the initial copyright line seems suspect: > > 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved. > > Not sure how a new file can have a 2004-2011 copyright year range ?? > > > On 5/07/2013 2:07 AM, Volker Simonis wrote: >> Hi, >> >> can sombody please review this change. It implements the relevant >> HotSpot make changes to build the HotSpot on Linux/PPC64 and >> shouldn't touch any existing platforms (but of course testing it on >> your closed platforms - especially ppc - is probably necessary and >> much appreciated). >> >> It also contains two small fixes for the CORE build (one is a type >> and the other is necessary to accomodate to the changes in "8008772: >> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >> to open an extra bug for. >> >> Notice that this patch determines the name and location of the >> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >> 0009_linux_ppc_files.patch. >> >> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >> >> Thank you and best regards, >> Volker >> From bill.pittore at oracle.com Mon Jul 8 09:56:06 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Mon, 08 Jul 2013 12:56:06 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D5A5CD.2070805@oracle.com> References: <51D494E9.2020200@oracle.com> <51D5A5CD.2070805@oracle.com> Message-ID: <51DAEF26.5030204@oracle.com> On 7/4/2013 12:41 PM, Alan Bateman wrote: > On 03/07/2013 22:17, BILL PITTORE wrote: >> These changes address bug 8014135 which adds support for statically >> linked agents in the VM. This is a followup to the recent JNI spec >> changes that addressed statically linked JNI libraries( 8005716). >> The JEP for this change is the same JEP as the JNI changes: >> http://openjdk.java.net/jeps/178 >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > > I looked at the javadoc updates to the attach API. > > One thing that doesn't come across very clearly is the mapping from > the agentLibrary parameter to "agent-lib-name". I think that needs a > few words so that it's clear that it is not literally looking for > "Agent_OnAttach_agent-lib-name" but rather "Agent_OnAttach" + > where is the library name in the > agentLibrary parameter. > > As I recall, the JVM Tool Interface is supposed to be referred so as > "JVM TI" rather than "JVMTI". Ok, I'll try to re-word it and send it out again. bill > > Otherwise it looks okay to me. > > -Alan > > > > From eric.mccorkle at oracle.com Mon Jul 8 10:59:18 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 08 Jul 2013 13:59:18 -0400 Subject: Review request for JDK-8014933: Remove JVM_SetProtectionDomain from hotspot In-Reply-To: <51D1F928.9020103@oracle.com> References: <51D1F51C.5050607@oracle.com> <51D1F928.9020103@oracle.com> Message-ID: <51DAFDF6.7080306@oracle.com> Changes have been incorporated. New webrev: http://cr.openjdk.java.net/~emc/8014933/ I still need a second reviewer for this. On 07/01/13 17:48, Coleen Phillimore wrote: > > Hi Eric, > > This looks good -except can you move > java_lang_Class::set_protection_domain into the private part of > java_lang_Class with set_init_lock? The only caller is from within > java_lang_Class class now. > > thanks, > Coleen > > On 07/01/2013 05:31 PM, Eric McCorkle wrote: >> Hello, >> >> Please review the following patch, which removes the deprecated JNI call >> JVM_SetProtectionDomain from hotspot. >> >> The corresponding patch, which removes use of JVM_SetProtectionDomain >> was committed a while back to jdk8/tl, and was integrated into >> hsx/hotspot-rt late last week. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8014933/ >> >> Thanks, >> Eric > From harold.seigel at oracle.com Mon Jul 8 11:12:45 2013 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 08 Jul 2013 14:12:45 -0400 Subject: Review request for JDK-8014933: Remove JVM_SetProtectionDomain from hotspot In-Reply-To: <51DAFDF6.7080306@oracle.com> References: <51D1F51C.5050607@oracle.com> <51D1F928.9020103@oracle.com> <51DAFDF6.7080306@oracle.com> Message-ID: <51DB011D.6090506@oracle.com> Hi Eric, The changes look good. Harold On 7/8/2013 1:59 PM, Eric McCorkle wrote: > Changes have been incorporated. New webrev: > http://cr.openjdk.java.net/~emc/8014933/ > > I still need a second reviewer for this. > > On 07/01/13 17:48, Coleen Phillimore wrote: >> Hi Eric, >> >> This looks good -except can you move >> java_lang_Class::set_protection_domain into the private part of >> java_lang_Class with set_init_lock? The only caller is from within >> java_lang_Class class now. >> >> thanks, >> Coleen >> >> On 07/01/2013 05:31 PM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review the following patch, which removes the deprecated JNI call >>> JVM_SetProtectionDomain from hotspot. >>> >>> The corresponding patch, which removes use of JVM_SetProtectionDomain >>> was committed a while back to jdk8/tl, and was integrated into >>> hsx/hotspot-rt late last week. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8014933/ >>> >>> Thanks, >>> Eric From vladimir.kozlov at oracle.com Mon Jul 8 14:17:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Jul 2013 14:17:32 -0700 Subject: RFR (XS): Fix after 8014972 In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF3731@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF3731@DEWDFEMB12A.global.corp.sap> Message-ID: <51DB2C6C.9040400@oracle.com> Reviewed. I am pushing the fix (8020059) into hotspot-comp/hotspot thanks, Vladimir On 7/8/13 7:31 AM, Lindenmaier, Goetz wrote: > Hi, > > The flag introduced by 8014972 is not defined if Hotspot is built > > without a compiler (zero, ppc64 core build). > > Please open a bug for this and review the fix. > > http://cr.openjdk.java.net/~goetz/webrevs/fix_after_8014972/ > > Best regards, > > Goetz. > From vladimir.kozlov at oracle.com Mon Jul 8 16:37:34 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Jul 2013 16:37:34 -0700 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: References: <51D657E6.2060606@oracle.com> Message-ID: <51DB4D3E.40808@oracle.com> Looks good. I started JPRT testing. Hopefully will get result tonight. Thanks, Vladimir On 7/8/13 8:42 AM, Volker Simonis wrote: > Hi David, > > thank you for the review. I prepared a new webrev according to your suggestions: > > http://cr.openjdk.java.net/~simonis/webrevs/8019922.v2/ > > Please find my comments inline: > > Thank you and best regards, > Volker > > On Fri, Jul 5, 2013 at 7:21 AM, David Holmes wrote: >> Hi Volker, >> >> This all looks fine to me. A couple of minor comments below. >> >> I will also test it but I don't expect to see any conflicts with our other >> ports. >> >> Thanks, >> David >> ----- >> >> make/defs.make >> >> Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the >> sparcv9 code and reduce this: >> >> 288 ifeq ($(BUILDARCH), ppc) >> 289 ifdef LP64 >> 290 BUILDARCH = ppc64 >> 291 else >> 292 BUILDARCH = ppc >> 293 endif >> 294 endif >> >> to >> >> 288 ifeq ($(BUILDARCH), ppc) >> 289 ifdef LP64 >> 290 BUILDARCH = ppc64 >> 291 endif >> 292 endif >> >> --- > > fixed as suggested. > >> >> make/linux/makefiles/defs.make >> >> I note you have: >> >> HS_ARCH = ppc >> >> and this is only used with the SA for which we presently have: >> >> ADD_SA_BINARIES/ppc = >> >> but you also added: >> >> ADD_SA_BINARIES/ppc64 = >> >> so was the HS_ARCH setting a typo? >> >> --- > > Well, I did it in the same way as the other architectures did it:) > > Moreover, HS_ARCH is also used in make/Makefile. > >> >> make/linux/makefiles/gcc.make >> >> You added: >> >> ARCHFLAG/ppc64 = -m64 >> >> which is fine, but then in ppc64.make you also have: >> >> CFLAGS += -m64 >> LFLAGS_VM += -m64 >> AOUT_FLAGS += -m64 >> >> which seems redundant given gcc.make has: >> >> 186 CFLAGS += $(ARCHFLAG) >> 187 AOUT_FLAGS += $(ARCHFLAG) >> 188 LFLAGS += $(ARCHFLAG) >> 189 ASFLAGS += $(ARCHFLAG) >> > > You're right. I removed the '-m64' settings from ppc64.make > Also, 'LAUNCHERFLAGS' isn't used anymore so I removed it from > pp464.make as well. > The same applies to 'AOUT_FLAGS' which isn't necessary for our build. > >> Also the initial copyright line seems suspect: >> >> 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights >> reserved. >> >> Not sure how a new file can have a 2004-2011 copyright year range ?? >> > > That was a copy-paste issue. After the lengthy discussions below I > changed it to "2004, 2013" to keep things simple:) > >> >> >> On 5/07/2013 2:07 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> can sombody please review this change. It implements the relevant >>> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >>> touch any existing platforms (but of course testing it on your closed >>> platforms - especially ppc - is probably necessary and much >>> appreciated). >>> >>> It also contains two small fixes for the CORE build (one is a type and >>> the other is necessary to accomodate to the changes in "8008772: >>> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >>> to open an extra bug for. >>> >>> Notice that this patch determines the name and location of the >>> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >>> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >>> 0009_linux_ppc_files.patch. >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >>> >>> Thank you and best regards, >>> Volker >>> >> From david.holmes at oracle.com Mon Jul 8 17:43:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Jul 2013 10:43:14 +1000 Subject: 7u40 RFR: 8012144 - Missing memory barriers Message-ID: <51DB5CA2.9040202@oracle.com> The issue of missing memory barriers in the GC taskqueue code was first flagged here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html and bug 8006971 was opened for it. There were some further background discussions that I wasn't party to and this all somewhat fell between the cracks for a while. A trimmed version of the original proposed patch was tested internally (and I believe by SAP) and that simplified patch is what is being proposed now, under 8012144, solely for the 7u40 update. I/we intend to revise the original patch for 8006971 and get that resolved properly for JDK 8. Meanwhile we have a critical urgency on getting this fixed in 7u40. The webrev is here: http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ Primarily it adds a fence for platforms that require it - with platforms that don't opting out via the conditional compilation. In this way there is no performance impact on those mainline SE platforms. (A correctly expressed lock-free algorithm will not have platform specific fences, hence the intent to rework this for JDK 8.) Note this is a very low risk fix regardless because adding memory barriers will not introduce incorrect behaviour. This patch was not supplied by me, but as a follow on from the original work, via John Cuthbertson. So John is one of the contributors (I believe Axel Siebenborn is the original contributor - I need an email address for the attribution!) and I will actually be a Reviewer. If anyone has any concerns please raise them quickly as time is very much against us here. Thanks, David From vladimir.kozlov at oracle.com Mon Jul 8 18:29:25 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Jul 2013 18:29:25 -0700 Subject: 7u40 RFR: 8012144 - Missing memory barriers In-Reply-To: <51DB5CA2.9040202@oracle.com> References: <51DB5CA2.9040202@oracle.com> Message-ID: <51DB6775.2070208@oracle.com> Looks fine to me. _bottom is int so OrderAccess::load_acquire() is normal load on our main platforms. Thanks, Vladimir On 7/8/13 5:43 PM, David Holmes wrote: > The issue of missing memory barriers in the GC taskqueue code was first > flagged here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html > > and bug 8006971 was opened for it. > > There were some further background discussions that I wasn't party to > and this all somewhat fell between the cracks for a while. > > A trimmed version of the original proposed patch was tested internally > (and I believe by SAP) and that simplified patch is what is being > proposed now, under 8012144, solely for the 7u40 update. I/we intend to > revise the original patch for 8006971 and get that resolved properly for > JDK 8. Meanwhile we have a critical urgency on getting this fixed in 7u40. > > The webrev is here: > > http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ > > Primarily it adds a fence for platforms that require it - with platforms > that don't opting out via the conditional compilation. In this way there > is no performance impact on those mainline SE platforms. (A correctly > expressed lock-free algorithm will not have platform specific fences, > hence the intent to rework this for JDK 8.) Note this is a very low risk > fix regardless because adding memory barriers will not introduce > incorrect behaviour. > > This patch was not supplied by me, but as a follow on from the original > work, via John Cuthbertson. So John is one of the contributors (I > believe Axel Siebenborn is the original contributor - I need an email > address for the attribution!) and I will actually be a Reviewer. > > If anyone has any concerns please raise them quickly as time is very > much against us here. > > Thanks, > David From david.holmes at oracle.com Mon Jul 8 18:30:24 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Jul 2013 11:30:24 +1000 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: References: <51D657E6.2060606@oracle.com> Message-ID: <51DB67B0.8080902@oracle.com> Hi Volker, I'll trim to the remaining issue: On 9/07/2013 1:42 AM, Volker Simonis wrote: > On Fri, Jul 5, 2013 at 7:21 AM, David Holmes wrote: >> make/linux/makefiles/defs.make >> >> I note you have: >> >> HS_ARCH = ppc >> >> and this is only used with the SA for which we presently have: >> >> ADD_SA_BINARIES/ppc = >> >> but you also added: >> >> ADD_SA_BINARIES/ppc64 = >> >> so was the HS_ARCH setting a typo? >> >> --- > > Well, I did it in the same way as the other architectures did it:) > > Moreover, HS_ARCH is also used in make/Makefile. So this is broken. If you use HS_ARCH=ppc then you will never use the ADD_SA_BINARIES/ppc64 definition because it is selected based on HS_ARCH. This suggests you want HS_ARCH=ppc64. However, as you pointed out HS_ARCH is also used in the top-level Makefile: HS_JNI_ARCH_SRC=$(call altsrc-replace,$(HS_COMMON_SRC)/cpu/$(HS_ARCH)/vm/jni_$(HS_ARCH).h) and I'm assuming that your cpu directory, and arch naming is using ppc here not ppc64. In which case you do want HS_ARCH=ppc. So there is a conflict. Simple solution is to delete ADD_SA_BINARIES/ppc64 but if you/we were ever to add the 32-bit PPC port and they differed in whether SA was supported, then we would have to resolve that somehow. As you know we have far too many "arch" variables in the hotspot build system, but in this case it isn't clear to me that HS_ARCH should be being used for the two situations it presently is. Thanks, David ----- >> >> make/linux/makefiles/gcc.make >> >> You added: >> >> ARCHFLAG/ppc64 = -m64 >> >> which is fine, but then in ppc64.make you also have: >> >> CFLAGS += -m64 >> LFLAGS_VM += -m64 >> AOUT_FLAGS += -m64 >> >> which seems redundant given gcc.make has: >> >> 186 CFLAGS += $(ARCHFLAG) >> 187 AOUT_FLAGS += $(ARCHFLAG) >> 188 LFLAGS += $(ARCHFLAG) >> 189 ASFLAGS += $(ARCHFLAG) >> > > You're right. I removed the '-m64' settings from ppc64.make > Also, 'LAUNCHERFLAGS' isn't used anymore so I removed it from > pp464.make as well. > The same applies to 'AOUT_FLAGS' which isn't necessary for our build. > >> Also the initial copyright line seems suspect: >> >> 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights >> reserved. >> >> Not sure how a new file can have a 2004-2011 copyright year range ?? >> > > That was a copy-paste issue. After the lengthy discussions below I > changed it to "2004, 2013" to keep things simple:) > >> >> >> On 5/07/2013 2:07 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> can sombody please review this change. It implements the relevant >>> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >>> touch any existing platforms (but of course testing it on your closed >>> platforms - especially ppc - is probably necessary and much >>> appreciated). >>> >>> It also contains two small fixes for the CORE build (one is a type and >>> the other is necessary to accomodate to the changes in "8008772: >>> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >>> to open an extra bug for. >>> >>> Notice that this patch determines the name and location of the >>> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >>> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >>> 0009_linux_ppc_files.patch. >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >>> >>> Thank you and best regards, >>> Volker >>> >> From david.holmes at oracle.com Mon Jul 8 18:56:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Jul 2013 11:56:23 +1000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> Message-ID: <51DB6DC7.1020900@oracle.com> Hi Goetz, On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: > Hi, > > This is in preparation of the PPC AIX port. > > A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. A curious thing to do ;-) Aside: presumably this is included in turn by other standard headers, not directly included - otherwise we could just undef IA64 after the include. > This leads to wrong configurations of shared files on Aix where IA64 is used. > This change replaces uses of "IA64" by "IA64 && !AIX". Might be simpler if we just eradicate the IA64 remnants in the code. I think we may even have a RFE for this. AFAIK there are no remaining users of the IA64 code in the hotspot codebase. > To reduce the complexity we propose to simplify two matters: > > Since the initial checkin objectMonitor.cpp and synchronizer.cpp > define #define ATTR __attribute__((noinline)) claiming this is needed > to avoid a gcc build time error with - at that time - old gcc versions. > This define depends on IA64. We remove it altogether. Well it doesn't "depend" on IA64: #if defined(__GNUC__) && !defined(IA64) // Need to inhibit inlining for older versions of GCC to avoid build-time failures #define ATTR __attribute__((noinline)) #else #define ATTR #endif it becomes empty on IA64 (and non gcc systems). So removing it altogether is changing things for all the other gcc using platforms. Now it may be that we don't need to preclude inlining of these methods any more to avoid build-failures, but we may still want to avoid inlining them for other reasons! So this aspect needs further investigation. Or you can just leave it as-is - if you have IA64 always defined then you will get the empty #else part. Or if we go with the "eradicate IA64" path then you can change IA64 to AIX (though it is odd to exchange an architecture check with an OS check). > prims/forte.cpp uses a lot of different mechanisms all disabling forte > support on windows, apple and ia64. We would have to add Aix. > Instead, we propose to use a check for the supported platforms (see webrev). > We could also add a macro SUPPORTS_FORTE that is defined in the corresponding > makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 > directories. Again if we just get rid of IA64 this will be a non-issue right? Thanks, David > Are there other platforms that need to be supported? I derived the platforms > from the comment in forte.cpp. > > Please review this change. I'm happy to incorporate your comments. > http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Mon Jul 8 21:24:26 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Jul 2013 21:24:26 -0700 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: <51DB4D3E.40808@oracle.com> References: <51D657E6.2060606@oracle.com> <51DB4D3E.40808@oracle.com> Message-ID: <51DB907A.2080208@oracle.com> Tests passed (included our ppc builds and testing). Vladimir On 7/8/13 4:37 PM, Vladimir Kozlov wrote: > Looks good. > > I started JPRT testing. Hopefully will get result tonight. > > Thanks, > Vladimir > > On 7/8/13 8:42 AM, Volker Simonis wrote: >> Hi David, >> >> thank you for the review. I prepared a new webrev according to your suggestions: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8019922.v2/ >> >> Please find my comments inline: >> >> Thank you and best regards, >> Volker >> >> On Fri, Jul 5, 2013 at 7:21 AM, David Holmes wrote: >>> Hi Volker, >>> >>> This all looks fine to me. A couple of minor comments below. >>> >>> I will also test it but I don't expect to see any conflicts with our other >>> ports. >>> >>> Thanks, >>> David >>> ----- >>> >>> make/defs.make >>> >>> Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the >>> sparcv9 code and reduce this: >>> >>> 288 ifeq ($(BUILDARCH), ppc) >>> 289 ifdef LP64 >>> 290 BUILDARCH = ppc64 >>> 291 else >>> 292 BUILDARCH = ppc >>> 293 endif >>> 294 endif >>> >>> to >>> >>> 288 ifeq ($(BUILDARCH), ppc) >>> 289 ifdef LP64 >>> 290 BUILDARCH = ppc64 >>> 291 endif >>> 292 endif >>> >>> --- >> >> fixed as suggested. >> >>> >>> make/linux/makefiles/defs.make >>> >>> I note you have: >>> >>> HS_ARCH = ppc >>> >>> and this is only used with the SA for which we presently have: >>> >>> ADD_SA_BINARIES/ppc = >>> >>> but you also added: >>> >>> ADD_SA_BINARIES/ppc64 = >>> >>> so was the HS_ARCH setting a typo? >>> >>> --- >> >> Well, I did it in the same way as the other architectures did it:) >> >> Moreover, HS_ARCH is also used in make/Makefile. >> >>> >>> make/linux/makefiles/gcc.make >>> >>> You added: >>> >>> ARCHFLAG/ppc64 = -m64 >>> >>> which is fine, but then in ppc64.make you also have: >>> >>> CFLAGS += -m64 >>> LFLAGS_VM += -m64 >>> AOUT_FLAGS += -m64 >>> >>> which seems redundant given gcc.make has: >>> >>> 186 CFLAGS += $(ARCHFLAG) >>> 187 AOUT_FLAGS += $(ARCHFLAG) >>> 188 LFLAGS += $(ARCHFLAG) >>> 189 ASFLAGS += $(ARCHFLAG) >>> >> >> You're right. I removed the '-m64' settings from ppc64.make >> Also, 'LAUNCHERFLAGS' isn't used anymore so I removed it from >> pp464.make as well. >> The same applies to 'AOUT_FLAGS' which isn't necessary for our build. >> >>> Also the initial copyright line seems suspect: >>> >>> 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights >>> reserved. >>> >>> Not sure how a new file can have a 2004-2011 copyright year range ?? >>> >> >> That was a copy-paste issue. After the lengthy discussions below I >> changed it to "2004, 2013" to keep things simple:) >> >>> >>> >>> On 5/07/2013 2:07 AM, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> can sombody please review this change. It implements the relevant >>>> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >>>> touch any existing platforms (but of course testing it on your closed >>>> platforms - especially ppc - is probably necessary and much >>>> appreciated). >>>> >>>> It also contains two small fixes for the CORE build (one is a type and >>>> the other is necessary to accomodate to the changes in "8008772: >>>> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >>>> to open an extra bug for. >>>> >>>> Notice that this patch determines the name and location of the >>>> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >>>> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >>>> 0009_linux_ppc_files.patch. >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>> From goetz.lindenmaier at sap.com Tue Jul 9 02:01:07 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jul 2013 09:01:07 +0000 Subject: 7u40 RFR: 8012144 - Missing memory barriers In-Reply-To: <51DB5CA2.9040202@oracle.com> References: <51DB5CA2.9040202@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF3DB7@DEWDFEMB12A.global.corp.sap> Hi David, I'm very happy to see this change go in now. As proposed here for 7u40, it would also work for our ppc64 port in jdk8. Yes, Axel tracked down the problem and proposed to add this barrier. His email is axel.siebenborn at sap.com. Actually, I would use X86 instead of IA32 || AMD64. (maybe add #include utilities/macros.hpp, but X86 is defined before all uses of taskqueue.hpp. I tested this on linux.) Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 9. Juli 2013 02:43 To: hotspot-dev developers Cc: Lindenmaier, Goetz; John Cuthbertson Subject: 7u40 RFR: 8012144 - Missing memory barriers The issue of missing memory barriers in the GC taskqueue code was first flagged here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html and bug 8006971 was opened for it. There were some further background discussions that I wasn't party to and this all somewhat fell between the cracks for a while. A trimmed version of the original proposed patch was tested internally (and I believe by SAP) and that simplified patch is what is being proposed now, under 8012144, solely for the 7u40 update. I/we intend to revise the original patch for 8006971 and get that resolved properly for JDK 8. Meanwhile we have a critical urgency on getting this fixed in 7u40. The webrev is here: http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ Primarily it adds a fence for platforms that require it - with platforms that don't opting out via the conditional compilation. In this way there is no performance impact on those mainline SE platforms. (A correctly expressed lock-free algorithm will not have platform specific fences, hence the intent to rework this for JDK 8.) Note this is a very low risk fix regardless because adding memory barriers will not introduce incorrect behaviour. This patch was not supplied by me, but as a follow on from the original work, via John Cuthbertson. So John is one of the contributors (I believe Axel Siebenborn is the original contributor - I need an email address for the attribution!) and I will actually be a Reviewer. If anyone has any concerns please raise them quickly as time is very much against us here. Thanks, David From aleksey.shipilev at oracle.com Tue Jul 9 02:35:59 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 09 Jul 2013 13:35:59 +0400 Subject: 7u40 RFR: 8012144 - Missing memory barriers In-Reply-To: <51DB5CA2.9040202@oracle.com> References: <51DB5CA2.9040202@oracle.com> Message-ID: <51DBD97F.6060402@oracle.com> On 07/09/2013 04:43 AM, David Holmes wrote: > The webrev is here: > http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ My understanding of the issue tells me this is a correct patch. (AFAIU, it would help to "just" load age with load_acquire, if only load_acquire was correctly implemented on PPC, doing the full-blown fence to ensure sequential consistency. The same effect is gained with the explicit barrier in this patch). -Aleksey. From goetz.lindenmaier at sap.com Tue Jul 9 02:56:27 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jul 2013 09:56:27 +0000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <51DB6DC7.1020900@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> Hi David, > A curious thing to do ;-) Yes, I agree. > Aside: presumably this is included in turn by other standard headers, > not directly included - otherwise we could just undef IA64 after the > include. Yes, that's the case. > Might be simpler if we just eradicate the IA64 remnants in the code. I > think we may even have a RFE for this. AFAIK there are no remaining > users of the IA64 code in the hotspot codebase. Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win Ia64. 8 in development, all soon based on hs25. We also contributed to the change cleaning up the IA64 defines. There are only such left we need in our code. http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 > #if defined(__GNUC__) && !defined(IA64) You are right, I could just leave it as is, except if __GNUC__ is define on AIX, who knows ;). If we don't remove it, I need to add !PPC64 so that it's inlined in our port on linux. > more to avoid build-failures, but we may still want to avoid inlining > them for other reasons! So this aspect needs further investigation. Or I think it's a good idea to clean it up. The build problem is documented. There may be 'other reasons', but unexpected issues can be there with any change. > > prims/forte.cpp uses a lot of different mechanisms all disabling forte > Again if we just get rid of IA64 this will be a non-issue right? Here I would add !AIX. But have a look at the file, there are also several other platforms where this is excluded, and the exclusion is implemented differently on each platform. Not that nice ... Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing functional. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 9. Juli 2013 03:56 To: Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. Hi Goetz, On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: > Hi, > > This is in preparation of the PPC AIX port. > > A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. A curious thing to do ;-) Aside: presumably this is included in turn by other standard headers, not directly included - otherwise we could just undef IA64 after the include. > This leads to wrong configurations of shared files on Aix where IA64 is used. > This change replaces uses of "IA64" by "IA64 && !AIX". Might be simpler if we just eradicate the IA64 remnants in the code. I think we may even have a RFE for this. AFAIK there are no remaining users of the IA64 code in the hotspot codebase. > To reduce the complexity we propose to simplify two matters: > > Since the initial checkin objectMonitor.cpp and synchronizer.cpp > define #define ATTR __attribute__((noinline)) claiming this is needed > to avoid a gcc build time error with - at that time - old gcc versions. > This define depends on IA64. We remove it altogether. Well it doesn't "depend" on IA64: #if defined(__GNUC__) && !defined(IA64) // Need to inhibit inlining for older versions of GCC to avoid build-time failures #define ATTR __attribute__((noinline)) #else #define ATTR #endif it becomes empty on IA64 (and non gcc systems). So removing it altogether is changing things for all the other gcc using platforms. Now it may be that we don't need to preclude inlining of these methods any more to avoid build-failures, but we may still want to avoid inlining them for other reasons! So this aspect needs further investigation. Or you can just leave it as-is - if you have IA64 always defined then you will get the empty #else part. Or if we go with the "eradicate IA64" path then you can change IA64 to AIX (though it is odd to exchange an architecture check with an OS check). > prims/forte.cpp uses a lot of different mechanisms all disabling forte > support on windows, apple and ia64. We would have to add Aix. > Instead, we propose to use a check for the supported platforms (see webrev). > We could also add a macro SUPPORTS_FORTE that is defined in the corresponding > makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 > directories. Again if we just get rid of IA64 this will be a non-issue right? Thanks, David > Are there other platforms that need to be supported? I derived the platforms > from the comment in forte.cpp. > > Please review this change. I'm happy to incorporate your comments. > http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset > > Best regards, > Goetz. > From erik.helin at oracle.com Tue Jul 9 04:01:08 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Tue, 09 Jul 2013 11:01:08 +0000 Subject: hg: hsx/hsx24/hotspot: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC Message-ID: <20130709110113.89FAA488E8@hg.openjdk.java.net> Changeset: dd7d57bcd749 Author: ehelin Date: 2013-07-09 10:03 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dd7d57bcd749 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC Reviewed-by: allwin, jiangli, tschatzl, dholmes ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp From fweimer at redhat.com Tue Jul 9 04:06:14 2013 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 09 Jul 2013 13:06:14 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <51D3065C.6090401@oracle.com> References: <51D3065C.6090401@oracle.com> Message-ID: <51DBEEA6.6090904@redhat.com> On 07/02/2013 06:57 PM, Stefan Karlsson wrote: > When the JVM starts it reserves a memory area for the entire Java heap. > We use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk of memory > that no other > subsystem of the JVM, or Java program, will be allowed to mmap into. > > The reservation of the memory only reflects the maximum possible heap > size, but often a smaller heap size is used if the memory pressure is > low. The part of > the heap that is actually used is committed with mmap(...MAP_FIXED...). Since you mention this, here's a really old pet peeve of mine. This does not work as intended. mmap(...MAP_NORESERVE...) actually commits the memory. The correct way to reserve address space on Linux is to drop MAP_NORESERVE and map the memory with PROT_NONE. Subsequently, you can commit the memory using mprotect() and suitable protection flags. This way, the default heap size will no longer cause failures with vm.overcommit_memory=2. Would you be interested in a patch that improves matters in this area? (Note that this only applies to Linux, not necessarily other systems.) -- Florian Weimer / Red Hat Product Security Team From david.holmes at oracle.com Tue Jul 9 05:08:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Jul 2013 22:08:03 +1000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> Message-ID: <51DBFD23.90407@oracle.com> On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: > Hi David, > >> A curious thing to do ;-) > Yes, I agree. > >> Aside: presumably this is included in turn by other standard headers, >> not directly included - otherwise we could just undef IA64 after the >> include. > Yes, that's the case. > >> Might be simpler if we just eradicate the IA64 remnants in the code. I >> think we may even have a RFE for this. AFAIK there are no remaining >> users of the IA64 code in the hotspot codebase. > Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win > Ia64. 8 in development, all soon based on hs25. We also contributed to > the change cleaning up the IA64 defines. There are only such left > we need in our code. > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 I'm somewhat perplexed. The IA64 uses you still see in the hotspot sources are ancient remnants of the IA64 support. Most of it has been stripped out completely. So how anyone could be using any of this is, as I said, perplexing ??? >> #if defined(__GNUC__) && !defined(IA64) > You are right, I could just leave it as is, except if __GNUC__ is define on AIX, > who knows ;). If we don't remove it, I need to add !PPC64 so that it's > inlined in our port on linux. >> more to avoid build-failures, but we may still want to avoid inlining >> them for other reasons! So this aspect needs further investigation. Or > I think it's a good idea to clean it up. The build problem > is documented. There may be 'other reasons', but unexpected issues > can be there with any change. But the aim is to avoid making gratuitous changes to code that is not part of the ppc64/AIX port. If you start inlining these functions you don't know what the impact will be. So why change them when it is not necessary. David ----- >>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >> Again if we just get rid of IA64 this will be a non-issue right? > Here I would add !AIX. > But have a look at the file, there are also several other platforms > where this is excluded, and the exclusion is implemented differently > on each platform. Not that nice ... > > Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing > functional. > > Best regards, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 9. Juli 2013 03:56 > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov > Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > > Hi Goetz, > > On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> This is in preparation of the PPC AIX port. >> >> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. > > A curious thing to do ;-) > > Aside: presumably this is included in turn by other standard headers, > not directly included - otherwise we could just undef IA64 after the > include. > >> This leads to wrong configurations of shared files on Aix where IA64 is used. >> This change replaces uses of "IA64" by "IA64 && !AIX". > > Might be simpler if we just eradicate the IA64 remnants in the code. I > think we may even have a RFE for this. AFAIK there are no remaining > users of the IA64 code in the hotspot codebase. > >> To reduce the complexity we propose to simplify two matters: >> >> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >> define #define ATTR __attribute__((noinline)) claiming this is needed >> to avoid a gcc build time error with - at that time - old gcc versions. >> This define depends on IA64. We remove it altogether. > > Well it doesn't "depend" on IA64: > > #if defined(__GNUC__) && !defined(IA64) > // Need to inhibit inlining for older versions of GCC to avoid > build-time failures > #define ATTR __attribute__((noinline)) > #else > #define ATTR > #endif > > it becomes empty on IA64 (and non gcc systems). So removing it > altogether is changing things for all the other gcc using platforms. Now > it may be that we don't need to preclude inlining of these methods any > more to avoid build-failures, but we may still want to avoid inlining > them for other reasons! So this aspect needs further investigation. Or > you can just leave it as-is - if you have IA64 always defined then you > will get the empty #else part. Or if we go with the "eradicate IA64" > path then you can change IA64 to AIX (though it is odd to exchange an > architecture check with an OS check). > >> prims/forte.cpp uses a lot of different mechanisms all disabling forte >> support on windows, apple and ia64. We would have to add Aix. >> Instead, we propose to use a check for the supported platforms (see webrev). >> We could also add a macro SUPPORTS_FORTE that is defined in the corresponding >> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >> directories. > > Again if we just get rid of IA64 this will be a non-issue right? > > Thanks, > David > >> Are there other platforms that need to be supported? I derived the platforms >> from the comment in forte.cpp. >> >> Please review this change. I'm happy to incorporate your comments. >> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >> >> Best regards, >> Goetz. >> From volker.simonis at gmail.com Tue Jul 9 05:15:57 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Jul 2013 14:15:57 +0200 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <51DBFD23.90407@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> Message-ID: On Tue, Jul 9, 2013 at 2:08 PM, David Holmes wrote: > On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: >> >> Hi David, >> >>> A curious thing to do ;-) >> >> Yes, I agree. >> >>> Aside: presumably this is included in turn by other standard headers, >>> not directly included - otherwise we could just undef IA64 after the >>> include. >> >> Yes, that's the case. >> >>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>> think we may even have a RFE for this. AFAIK there are no remaining >>> users of the IA64 code in the hotspot codebase. >> >> Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win >> Ia64. 8 in development, all soon based on hs25. We also contributed to >> the change cleaning up the IA64 defines. There are only such left >> we need in our code. >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 > > > I'm somewhat perplexed. The IA64 uses you still see in the hotspot sources > are ancient remnants of the IA64 support. Most of it has been stripped out > completely. So how anyone could be using any of this is, as I said, > perplexing ??? > You're too Oracle-centric, but it's not only Oracle who has closed HotSpot ports:) > >>> #if defined(__GNUC__) && !defined(IA64) >> >> You are right, I could just leave it as is, except if __GNUC__ is define >> on AIX, >> who knows ;). If we don't remove it, I need to add !PPC64 so that it's >> inlined in our port on linux. >>> >>> more to avoid build-failures, but we may still want to avoid inlining >>> them for other reasons! So this aspect needs further investigation. Or >> >> I think it's a good idea to clean it up. The build problem >> is documented. There may be 'other reasons', but unexpected issues >> can be there with any change. > > > But the aim is to avoid making gratuitous changes to code that is not part > of the ppc64/AIX port. If you start inlining these functions you don't know > what the impact will be. So why change them when it is not necessary. > > David > ----- > > >>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>> >>> Again if we just get rid of IA64 this will be a non-issue right? >> >> Here I would add !AIX. >> But have a look at the file, there are also several other platforms >> where this is excluded, and the exclusion is implemented differently >> on each platform. Not that nice ... >> >> Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing >> functional. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 9. Juli 2013 03:56 >> To: Lindenmaier, Goetz >> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; >> Vladimir Kozlov >> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor >> conditionals on AIX. >> >> Hi Goetz, >> >> On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> This is in preparation of the PPC AIX port. >>> >>> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" >>> unconditionally. >> >> >> A curious thing to do ;-) >> >> Aside: presumably this is included in turn by other standard headers, >> not directly included - otherwise we could just undef IA64 after the >> include. >> >>> This leads to wrong configurations of shared files on Aix where IA64 is >>> used. >>> This change replaces uses of "IA64" by "IA64 && !AIX". >> >> >> Might be simpler if we just eradicate the IA64 remnants in the code. I >> think we may even have a RFE for this. AFAIK there are no remaining >> users of the IA64 code in the hotspot codebase. >> >>> To reduce the complexity we propose to simplify two matters: >>> >>> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >>> define #define ATTR __attribute__((noinline)) claiming this is needed >>> to avoid a gcc build time error with - at that time - old gcc versions. >>> This define depends on IA64. We remove it altogether. >> >> >> Well it doesn't "depend" on IA64: >> >> #if defined(__GNUC__) && !defined(IA64) >> // Need to inhibit inlining for older versions of GCC to avoid >> build-time failures >> #define ATTR __attribute__((noinline)) >> #else >> #define ATTR >> #endif >> >> it becomes empty on IA64 (and non gcc systems). So removing it >> altogether is changing things for all the other gcc using platforms. Now >> it may be that we don't need to preclude inlining of these methods any >> more to avoid build-failures, but we may still want to avoid inlining >> them for other reasons! So this aspect needs further investigation. Or >> you can just leave it as-is - if you have IA64 always defined then you >> will get the empty #else part. Or if we go with the "eradicate IA64" >> path then you can change IA64 to AIX (though it is odd to exchange an >> architecture check with an OS check). >> >>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>> support on windows, apple and ia64. We would have to add Aix. >>> Instead, we propose to use a check for the supported platforms (see >>> webrev). >>> We could also add a macro SUPPORTS_FORTE that is defined in the >>> corresponding >>> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >>> directories. >> >> >> Again if we just get rid of IA64 this will be a non-issue right? >> >> Thanks, >> David >> >>> Are there other platforms that need to be supported? I derived the >>> platforms >>> from the comment in forte.cpp. >>> >>> Please review this change. I'm happy to incorporate your comments. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >>> >>> Best regards, >>> Goetz. >>> > From volker.simonis at gmail.com Tue Jul 9 06:09:31 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Jul 2013 15:09:31 +0200 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: <51DB67B0.8080902@oracle.com> References: <51D657E6.2060606@oracle.com> <51DB67B0.8080902@oracle.com> Message-ID: On Tue, Jul 9, 2013 at 3:30 AM, David Holmes wrote: > Hi Volker, > > I'll trim to the remaining issue: > > > On 9/07/2013 1:42 AM, Volker Simonis wrote: >> >> On Fri, Jul 5, 2013 at 7:21 AM, David Holmes >> wrote: >>> >>> make/linux/makefiles/defs.make >>> >>> I note you have: >>> >>> HS_ARCH = ppc >>> >>> and this is only used with the SA for which we presently have: >>> >>> ADD_SA_BINARIES/ppc = >>> >>> but you also added: >>> >>> ADD_SA_BINARIES/ppc64 = >>> >>> so was the HS_ARCH setting a typo? >>> >>> --- >> >> >> Well, I did it in the same way as the other architectures did it:) >> >> Moreover, HS_ARCH is also used in make/Makefile. > > > So this is broken. If you use HS_ARCH=ppc then you will never use the > > ADD_SA_BINARIES/ppc64 > > definition because it is selected based on HS_ARCH. This suggests you want > HS_ARCH=ppc64. > > However, as you pointed out HS_ARCH is also used in the top-level Makefile: > > HS_JNI_ARCH_SRC=$(call > altsrc-replace,$(HS_COMMON_SRC)/cpu/$(HS_ARCH)/vm/jni_$(HS_ARCH).h) > > and I'm assuming that your cpu directory, and arch naming is using ppc here > not ppc64. In which case you do want HS_ARCH=ppc. > > So there is a conflict. Simple solution is to delete > > ADD_SA_BINARIES/ppc64 > > but if you/we were ever to add the 32-bit PPC port and they differed in > whether SA was supported, then we would have to resolve that somehow. As you > know we have far too many "arch" variables in the hotspot build system, but > in this case it isn't clear to me that HS_ARCH should be being used for the > two situations it presently is. > OK, I'll remove ADD_SA_BINARIES/ppc64 and wait with the general fix until you add the 32-bit PPC port AND only one of the two ports will exclusivley support SA (whenever that will happen:) Ready to push now? Thank you and best regards, Volker > Thanks, > David > ----- > > >>> >>> make/linux/makefiles/gcc.make >>> >>> You added: >>> >>> ARCHFLAG/ppc64 = -m64 >>> >>> which is fine, but then in ppc64.make you also have: >>> >>> CFLAGS += -m64 >>> LFLAGS_VM += -m64 >>> AOUT_FLAGS += -m64 >>> >>> which seems redundant given gcc.make has: >>> >>> 186 CFLAGS += $(ARCHFLAG) >>> 187 AOUT_FLAGS += $(ARCHFLAG) >>> 188 LFLAGS += $(ARCHFLAG) >>> 189 ASFLAGS += $(ARCHFLAG) >>> >> >> You're right. I removed the '-m64' settings from ppc64.make >> Also, 'LAUNCHERFLAGS' isn't used anymore so I removed it from >> pp464.make as well. >> The same applies to 'AOUT_FLAGS' which isn't necessary for our build. >> >>> Also the initial copyright line seems suspect: >>> >>> 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All >>> rights >>> reserved. >>> >>> Not sure how a new file can have a 2004-2011 copyright year range ?? >>> >> >> That was a copy-paste issue. After the lengthy discussions below I >> changed it to "2004, 2013" to keep things simple:) >> >>> >>> >>> On 5/07/2013 2:07 AM, Volker Simonis wrote: >>>> >>>> >>>> Hi, >>>> >>>> can sombody please review this change. It implements the relevant >>>> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >>>> touch any existing platforms (but of course testing it on your closed >>>> platforms - especially ppc - is probably necessary and much >>>> appreciated). >>>> >>>> It also contains two small fixes for the CORE build (one is a type and >>>> the other is necessary to accomodate to the changes in "8008772: >>>> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >>>> to open an extra bug for. >>>> >>>> Notice that this patch determines the name and location of the >>>> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >>>> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >>>> 0009_linux_ppc_files.patch. >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>> > From goetz.lindenmaier at sap.com Tue Jul 9 06:12:51 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jul 2013 13:12:51 +0000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <51DBFD23.90407@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> Hi, Here a webrev without the cleanups: http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 9. Juli 2013 14:08 To: Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: > Hi David, > >> A curious thing to do ;-) > Yes, I agree. > >> Aside: presumably this is included in turn by other standard headers, >> not directly included - otherwise we could just undef IA64 after the >> include. > Yes, that's the case. > >> Might be simpler if we just eradicate the IA64 remnants in the code. I >> think we may even have a RFE for this. AFAIK there are no remaining >> users of the IA64 code in the hotspot codebase. > Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win > Ia64. 8 in development, all soon based on hs25. We also contributed to > the change cleaning up the IA64 defines. There are only such left > we need in our code. > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 I'm somewhat perplexed. The IA64 uses you still see in the hotspot sources are ancient remnants of the IA64 support. Most of it has been stripped out completely. So how anyone could be using any of this is, as I said, perplexing ??? >> #if defined(__GNUC__) && !defined(IA64) > You are right, I could just leave it as is, except if __GNUC__ is define on AIX, > who knows ;). If we don't remove it, I need to add !PPC64 so that it's > inlined in our port on linux. >> more to avoid build-failures, but we may still want to avoid inlining >> them for other reasons! So this aspect needs further investigation. Or > I think it's a good idea to clean it up. The build problem > is documented. There may be 'other reasons', but unexpected issues > can be there with any change. But the aim is to avoid making gratuitous changes to code that is not part of the ppc64/AIX port. If you start inlining these functions you don't know what the impact will be. So why change them when it is not necessary. David ----- >>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >> Again if we just get rid of IA64 this will be a non-issue right? > Here I would add !AIX. > But have a look at the file, there are also several other platforms > where this is excluded, and the exclusion is implemented differently > on each platform. Not that nice ... > > Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing > functional. > > Best regards, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 9. Juli 2013 03:56 > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov > Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > > Hi Goetz, > > On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> This is in preparation of the PPC AIX port. >> >> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. > > A curious thing to do ;-) > > Aside: presumably this is included in turn by other standard headers, > not directly included - otherwise we could just undef IA64 after the > include. > >> This leads to wrong configurations of shared files on Aix where IA64 is used. >> This change replaces uses of "IA64" by "IA64 && !AIX". > > Might be simpler if we just eradicate the IA64 remnants in the code. I > think we may even have a RFE for this. AFAIK there are no remaining > users of the IA64 code in the hotspot codebase. > >> To reduce the complexity we propose to simplify two matters: >> >> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >> define #define ATTR __attribute__((noinline)) claiming this is needed >> to avoid a gcc build time error with - at that time - old gcc versions. >> This define depends on IA64. We remove it altogether. > > Well it doesn't "depend" on IA64: > > #if defined(__GNUC__) && !defined(IA64) > // Need to inhibit inlining for older versions of GCC to avoid > build-time failures > #define ATTR __attribute__((noinline)) > #else > #define ATTR > #endif > > it becomes empty on IA64 (and non gcc systems). So removing it > altogether is changing things for all the other gcc using platforms. Now > it may be that we don't need to preclude inlining of these methods any > more to avoid build-failures, but we may still want to avoid inlining > them for other reasons! So this aspect needs further investigation. Or > you can just leave it as-is - if you have IA64 always defined then you > will get the empty #else part. Or if we go with the "eradicate IA64" > path then you can change IA64 to AIX (though it is odd to exchange an > architecture check with an OS check). > >> prims/forte.cpp uses a lot of different mechanisms all disabling forte >> support on windows, apple and ia64. We would have to add Aix. >> Instead, we propose to use a check for the supported platforms (see webrev). >> We could also add a macro SUPPORTS_FORTE that is defined in the corresponding >> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >> directories. > > Again if we just get rid of IA64 this will be a non-issue right? > > Thanks, > David > >> Are there other platforms that need to be supported? I derived the platforms >> from the comment in forte.cpp. >> >> Please review this change. I'm happy to incorporate your comments. >> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >> >> Best regards, >> Goetz. >> From goetz.lindenmaier at sap.com Tue Jul 9 06:24:54 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jul 2013 13:24:54 +0000 Subject: RFR (XS): 8020121: PPC64: fix build in cppInterpreter after 8019519 Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF4221@DEWDFEMB12A.global.corp.sap> Hi, I please need a review for this small change: http://cr.openjdk.java.net/~goetz/webrevs/8020121-fix_ts/ I broke the build of the cppInterpreter only in the ppc staging repository by 8019519. This fixes it again. Thanks & best regards, Goetz. From stefan.karlsson at oracle.com Tue Jul 9 07:21:22 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Jul 2013 16:21:22 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <51DBEEA6.6090904@redhat.com> References: <51D3065C.6090401@oracle.com> <51DBEEA6.6090904@redhat.com> Message-ID: <51DC1C62.6050908@oracle.com> On 07/09/2013 01:06 PM, Florian Weimer wrote: > On 07/02/2013 06:57 PM, Stefan Karlsson wrote: >> When the JVM starts it reserves a memory area for the entire Java heap. >> We use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk of memory >> that no other >> subsystem of the JVM, or Java program, will be allowed to mmap into. >> >> The reservation of the memory only reflects the maximum possible heap >> size, but often a smaller heap size is used if the memory pressure is >> low. The part of >> the heap that is actually used is committed with mmap(...MAP_FIXED...). > > Since you mention this, here's a really old pet peeve of mine. > > This does not work as intended. mmap(...MAP_NORESERVE...) actually > commits the memory. The correct way to reserve address space on Linux > is to drop MAP_NORESERVE and map the memory with PROT_NONE. > Subsequently, you can commit the memory using mprotect() and suitable > protection flags. This way, the default heap size will no longer > cause failures with vm.overcommit_memory=2. I wrote a small test program that tries to mmap 2TB on my 8GB machine. This the outcome from the experiment: overcommit_memory = 0 | MAP_NORESERVE | no MAP_NORESERVE | +---------------+------------------+ PROT_WRITE | succeeded | failed | PROT_NONE | succeeded | succeeded | +---------------+------------------+ overcommit_memory = 1 | MAP_NORESERVE | no MAP_NORESERVE | +---------------+------------------+ PROT_WRITE | succeeded | succeeded | PROT_NONE | succeeded | succeeded | +---------------+------------------+ overcommit_memory = 2 | MAP_NORESERVE | no MAP_NORESERVE | +---------------+------------------+ PROT_WRITE | failed | failed | PROT_NONE | succeeded | succeeded | +---------------+------------------+ With PROT_NONE we don't commit memory, independent of the usage of MAP_NORESERVE. Note that we recently changed from using PROT_READ|PROT_WRITE to PROT_NONE when reserving memory in JDK8: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012015 Me and Per Lid?n discussed your suggestion to use mprotect to commit memory instead of re-mmapping. We think that doing that might actually solve the problem in: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a837fa3d3f86 where we today shutdown when mmap(...MAP_FIXED...) removes the previous mapping when mmap fails for small pages. We could probably also change this fix for the large pages bug (8007074) to use the same mprotect strategy. However, we would still need most of the alignment changes from the 8007074 fix. > > Would you be interested in a patch that improves matters in this area? I think so, but I'll defer the question to the hotspot-runtime-dev team. If we want to use the mprotect strategy for small we should probably try to use it for large pages as well. thanks, StefanK > > (Note that this only applies to Linux, not necessarily other systems.) > From vladimir.kozlov at oracle.com Tue Jul 9 07:44:37 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Jul 2013 07:44:37 -0700 Subject: RFR (XS): 8020121: PPC64: fix build in cppInterpreter after 8019519 In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF4221@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF4221@DEWDFEMB12A.global.corp.sap> Message-ID: <51DC21D5.1060206@oracle.com> Good. Vladimir On 7/9/13 6:24 AM, Lindenmaier, Goetz wrote: > Hi, > > I please need a review for this small change: > > http://cr.openjdk.java.net/~goetz/webrevs/8020121-fix_ts/ > > I broke the build of the cppInterpreter only in the ppc staging > > repository by 8019519. This fixes it again. > > Thanks & best regards, > > Goetz. > From eric.mccorkle at oracle.com Tue Jul 9 07:55:29 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 09 Jul 2013 10:55:29 -0400 Subject: Wrong BugID (whoops!) Message-ID: <51DC2461.7050008@oracle.com> I put the wrong bug id in a recent changeset. I had 8014399, when the actual id was 8014933. Can this be changed, or should I just close the ticket manually? From fweimer at redhat.com Tue Jul 9 08:01:23 2013 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 09 Jul 2013 17:01:23 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <51DC1C62.6050908@oracle.com> References: <51D3065C.6090401@oracle.com> <51DBEEA6.6090904@redhat.com> <51DC1C62.6050908@oracle.com> Message-ID: <51DC25C3.9090501@redhat.com> On 07/09/2013 04:21 PM, Stefan Karlsson wrote: > Note that we recently changed from using PROT_READ|PROT_WRITE to > PROT_NONE when reserving memory in JDK8: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012015 Very cool. I can confirm that this change resolves the long-standing issue with the standard heap size (a quarter of RAM) and vm.overcommit_memory=2 mode. Previously, you could not start more than 3 VMs in parallel, and with the change, that limitation is lifted. Any chance we can backport this change to hs24 and jdk7u? -- Florian Weimer / Red Hat Product Security Team From serguei.spitsyn at oracle.com Tue Jul 9 10:38:02 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 09 Jul 2013 10:38:02 -0700 Subject: RFR (XS): 8020121: PPC64: fix build in cppInterpreter after 8019519 In-Reply-To: <51DC21D5.1060206@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF4221@DEWDFEMB12A.global.corp.sap> <51DC21D5.1060206@oracle.com> Message-ID: <51DC4A7A.60702@oracle.com> The fix is good. Thanks, Serguei On 7/9/13 7:44 AM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 7/9/13 6:24 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I please need a review for this small change: >> >> http://cr.openjdk.java.net/~goetz/webrevs/8020121-fix_ts/ >> >> I broke the build of the cppInterpreter only in the ppc staging >> >> repository by 8019519. This fixes it again. >> >> Thanks & best regards, >> >> Goetz. >> From joe.darcy at oracle.com Tue Jul 9 10:44:23 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 09 Jul 2013 10:44:23 -0700 Subject: Wrong BugID (whoops!) In-Reply-To: <51DC2461.7050008@oracle.com> References: <51DC2461.7050008@oracle.com> Message-ID: <51DC4BF7.9040800@oracle.com> On 07/09/2013 07:55 AM, Eric McCorkle wrote: > I put the wrong bug id in a recent changeset. I had 8014399, when the > actual id was 8014933. Can this be changed, or should I just close the > ticket manually? To is impractical to change the bug id used in a changeset that has already been pushed. -Joe From eric.mccorkle at oracle.com Tue Jul 9 11:57:29 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 09 Jul 2013 14:57:29 -0400 Subject: Wrong BugID (whoops!) In-Reply-To: <51DC4BF7.9040800@oracle.com> References: <51DC2461.7050008@oracle.com> <51DC4BF7.9040800@oracle.com> Message-ID: <51DC5D19.2000208@oracle.com> Alright, I'll just mark the issue as fixed and reference the mistake. On 07/09/13 13:44, Joe Darcy wrote: > On 07/09/2013 07:55 AM, Eric McCorkle wrote: >> I put the wrong bug id in a recent changeset. I had 8014399, when the >> actual id was 8014933. Can this be changed, or should I just close the >> ticket manually? > > To is impractical to change the bug id used in a changeset that has > already been pushed. > > -Joe From mark.reinhold at oracle.com Tue Jul 9 12:17:10 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 09 Jul 2013 12:17:10 -0700 Subject: Wrong BugID (whoops!) In-Reply-To: <51DC4BF7.9040800@oracle.com> References: <51DC2461.7050008@oracle.com>,<51DC4BF7.9040800@oracle.com> Message-ID: <20130709121710.358232@eggemoggin.niobe.net> 2013/7/9 3:44 -0700, joe.darcy at oracle.com: > On 07/09/2013 07:55 AM, Eric McCorkle wrote: >> I put the wrong bug id in a recent changeset. I had 8014399, when the >> actual id was 8014933. Can this be changed, or should I just close the >> ticket manually? > > To is impractical to change the bug id used in a changeset that has > already been pushed. Well, it depends. If the changeset has only been pushed to one or two non-master repositories then it can be rolled back and blacklisted, but anyone who's already pulled it will have to strip that changeset and any of its children from their working repos. When did you push it, and to where? What's the changeset hash? - Mark From eric.mccorkle at oracle.com Tue Jul 9 12:45:15 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 09 Jul 2013 15:45:15 -0400 Subject: Wrong BugID (whoops!) In-Reply-To: <20130709121710.358232@eggemoggin.niobe.net> References: <51DC2461.7050008@oracle.com>, <51DC4BF7.9040800@oracle.com> <20130709121710.358232@eggemoggin.niobe.net> Message-ID: <51DC684B.409@oracle.com> Harold pushed it to hsx/hotspot-rt this morning. On 07/09/13 15:17, mark.reinhold at oracle.com wrote: > 2013/7/9 3:44 -0700, joe.darcy at oracle.com: >> On 07/09/2013 07:55 AM, Eric McCorkle wrote: >>> I put the wrong bug id in a recent changeset. I had 8014399, when the >>> actual id was 8014933. Can this be changed, or should I just close the >>> ticket manually? >> >> To is impractical to change the bug id used in a changeset that has >> already been pushed. > > Well, it depends. If the changeset has only been pushed to one or two > non-master repositories then it can be rolled back and blacklisted, but > anyone who's already pulled it will have to strip that changeset and any > of its children from their working repos. > > When did you push it, and to where? What's the changeset hash? > > - Mark > From dmitry.samersoff at oracle.com Tue Jul 9 12:50:58 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 09 Jul 2013 23:50:58 +0400 Subject: Wrong BugID (whoops!) In-Reply-To: <20130709121710.358232@eggemoggin.niobe.net> References: <51DC2461.7050008@oracle.com>, <51DC4BF7.9040800@oracle.com> <20130709121710.358232@eggemoggin.niobe.net> Message-ID: <51DC69A2.3050600@oracle.com> Mark, 1. For cases like this I would like to have a file counting problematic changesets e.g. ProblemChangesetList.txt, otherwise it's hard to restore the history after couple of years. 2. Starting from Mercurial 2.2 hg has --amend command that allows to perform limited but safe editing of the history. Never tried it so not sure it helps in this case. -Dmitry On 2013-07-09 23:17, mark.reinhold at oracle.com wrote: > 2013/7/9 3:44 -0700, joe.darcy at oracle.com: >> On 07/09/2013 07:55 AM, Eric McCorkle wrote: >>> I put the wrong bug id in a recent changeset. I had 8014399, when the >>> actual id was 8014933. Can this be changed, or should I just close the >>> ticket manually? >> >> To is impractical to change the bug id used in a changeset that has >> already been pushed. > > Well, it depends. If the changeset has only been pushed to one or two > non-master repositories then it can be rolled back and blacklisted, but > anyone who's already pulled it will have to strip that changeset and any > of its children from their working repos. > > When did you push it, and to where? What's the changeset hash? > > - Mark > -- 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 daniel.daugherty at oracle.com Tue Jul 9 13:01:05 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 09 Jul 2013 20:01:05 +0000 Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets Message-ID: <20130709200128.03D564890D@hg.openjdk.java.net> Changeset: f323bbb0e6c1 Author: coleenp Date: 2013-07-03 13:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f323bbb0e6c1 8019833: Wrong JNI error code for preexisting JVM Summary: Return the appropriate JNI error message (instead of the generic one) when the JVM is already started Reviewed-by: coleenp, hseigel Contributed-by: sylvestre at debian.org ! src/share/vm/prims/jni.cpp Changeset: 5f7a4367c787 Author: zgu Date: 2013-07-04 06:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5f7a4367c787 8016074: NMT: assertion failed: assert(thread->thread_state() == from) failed: coming from wrong thread state Summary: Uses os::NakedYield() on Solaris instead of os::yield_all() Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/memTracker.hpp Changeset: a55aa67bce1a Author: zgu Date: 2013-07-04 04:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a55aa67bce1a Merge Changeset: 59b052799158 Author: dcubed Date: 2013-07-04 21:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/59b052799158 8015884: runThese crashed with SIGSEGV, hs_err has an error instead of stacktrace Summary: Dl_info struct should only be used if dladdr() has returned non-zero (no errors) and always check the dladdr() return value; Dl_info.dli_sname and Dl_info.dli_saddr fields should only be used if non-NULL; update/improve runtime/6888954/vmerrors.sh test Reviewed-by: dsamersoff, zgu, hseigel, coleenp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! test/runtime/6888954/vmerrors.sh Changeset: 93e6dce53ba7 Author: fparain Date: 2013-07-05 08:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/93e6dce53ba7 8016465: The hs_err file gets wrong name Reviewed-by: dcubed, dholmes, rdurbin ! src/share/vm/utilities/vmError.cpp Changeset: cc5b7915104e Author: fparain Date: 2013-07-05 08:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cc5b7915104e Merge Changeset: cf9d71d3e474 Author: iklam Date: 2013-07-08 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cf9d71d3e474 8016903: Thread::_handle_area initial size too big Summary: Changed initial size to Chunk::tiny_size (216 bytes) Reviewed-by: coleenp, dholmes, sspitsyn ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/handles.hpp Changeset: 71180a6e5080 Author: jiangli Date: 2013-07-03 17:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/71180a6e5080 7133260: AllocationProfiler uses space in metadata and doesn't seem to do anything useful. Summary: Remove -Xaprof and Klass::_alloc_count & ArrayKlass::_alloc_size. Reviewed-by: stefank, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fa6929d0b0a9 Author: jiangli Date: 2013-07-08 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fa6929d0b0a9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3c7b4b7b2625 Author: jiangli Date: 2013-07-08 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c7b4b7b2625 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp From zhengyu.gu at oracle.com Tue Jul 9 13:45:43 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Tue, 09 Jul 2013 20:45:43 +0000 Subject: hg: hsx/hsx24/hotspot: 8016074: NMT: assertion failed: assert(thread->thread_state() == from) failed: coming from wrong thread state Message-ID: <20130709204548.C9AF248911@hg.openjdk.java.net> Changeset: 1478a623482d Author: zgu Date: 2013-07-04 06:24 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1478a623482d 8016074: NMT: assertion failed: assert(thread->thread_state() == from) failed: coming from wrong thread state Summary: Uses os::NakedYield() on Solaris instead of os::yield_all() Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/memTracker.hpp From mark.reinhold at oracle.com Tue Jul 9 13:56:38 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 09 Jul 2013 13:56:38 -0700 Subject: Wrong BugID (whoops!) In-Reply-To: <51DC69A2.3050600@oracle.com> References: <51DC2461.7050008@oracle.com>, <20130709121710.358232@eggemoggin.niobe.net>, <51DC69A2.3050600@oracle.com> Message-ID: <20130709135638.184901@eggemoggin.niobe.net> 2013/7/9 5:50 -0700, dmitry.samersoff at oracle.com: > 1. > > For cases like this I would like to have a file counting problematic > changesets e.g. ProblemChangesetList.txt, otherwise it's hard to > restore the history after couple of years. I don't understand. The whole point of removing problematic changesets is so that they're never part of the long-term history. Why do you need a list of them? In any case, if you do need a list then the hashes of all blacklisted changesets in OpenJDK repositories are in jcheck.py itself. (There's a separate server-side list for Oracle-internal repositories.) > 2. > > Starting from Mercurial 2.2 > > hg has --amend command that allows to perform limited but safe editing > of the history. Never tried it so not sure it helps in this case. It doesn't help in this case. That option only works in a local repository, on changesets that haven't yet been pushed anywhere else. - Mark From dmitry.samersoff at oracle.com Tue Jul 9 14:37:51 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 10 Jul 2013 01:37:51 +0400 Subject: Wrong BugID (whoops!) In-Reply-To: <20130709135638.184901@eggemoggin.niobe.net> References: <51DC2461.7050008@oracle.com>, <20130709121710.358232@eggemoggin.niobe.net>, <51DC69A2.3050600@oracle.com> <20130709135638.184901@eggemoggin.niobe.net> Message-ID: <51DC82AF.9020308@oracle.com> Mark, On 2013-07-10 00:56, mark.reinhold at oracle.com wrote: > 2013/7/9 5:50 -0700, dmitry.samersoff at oracle.com: >> 1. >> >> For cases like this I would like to have a file counting problematic >> changesets e.g. ProblemChangesetList.txt, otherwise it's hard to >> restore the history after couple of years. Sorry! "Problematic" is not the best word here. > > I don't understand. The whole point of removing problematic changesets > is so that they're never part of the long-term history. Why do you need > a list of them? > > In any case, if you do need a list then the hashes of all blacklisted > changesets in OpenJDK repositories are in jcheck.py itself. (There's > a separate server-side list for Oracle-internal repositories.) As far as I understand, we don't plan to remove changeset - just manually close bug in JBS. In this case we keep a wrong bug id in history so attempt to understand what caused the changes couple of years later become an adventure. I would like to have something not very formal that looks like: (wrong bug id) 4896:97c5acae48be s/7007040/7007044/ (hotspot and corresponding jdk changes has different bug id) 4896:97c5acae48be see also jdk 7007044 etc -Dmitry > >> 2. >> >> Starting from Mercurial 2.2 >> >> hg has --amend command that allows to perform limited but safe editing >> of the history. Never tried it so not sure it helps in this case. > > It doesn't help in this case. That option only works in a local > repository, on changesets that haven't yet been pushed anywhere else. > > - Mark > -- 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 eric.mccorkle at oracle.com Tue Jul 9 14:49:14 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 09 Jul 2013 17:49:14 -0400 Subject: Update JDK8 to b96 Message-ID: <51DC855A.5030003@oracle.com> This email is to alert everyone to make sure they are using jdk8-b96 or later. I submitted a changeset last night which depends on another changeset present in b96. Any hotspot built with sources later than last night and a JDK earlier than b96 won't work. From mark.reinhold at oracle.com Tue Jul 9 15:07:28 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 09 Jul 2013 15:07:28 -0700 Subject: Wrong BugID (whoops!) In-Reply-To: <51DC82AF.9020308@oracle.com> References: <51DC2461.7050008@oracle.com>, <20130709135638.184901@eggemoggin.niobe.net>, <51DC82AF.9020308@oracle.com> Message-ID: <20130709150728.44381@eggemoggin.niobe.net> 2013/7/9 7:37 -0700, dmitry.samersoff at oracle.com: > As far as I understand, we don't plan to remove changeset - just > manually close bug in JBS. Yes, that's how we're handling this case, per Harold's related message. > In this case we keep a wrong bug id in history so attempt to understand > what caused the changes couple of years later become an adventure. > > I would like to have something not very formal that looks like: > > (wrong bug id) > 4896:97c5acae48be s/7007040/7007044/ > > (hotspot and corresponding jdk changes has different bug id) > 4896:97c5acae48be see also jdk 7007044 I think the right place for that information is in the bug reports themselves, and my understanding is that that's what we're going to do for this case. - Mark From eric.mccorkle at oracle.com Tue Jul 9 15:20:13 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 09 Jul 2013 18:20:13 -0400 Subject: Wrong BugID (whoops!) In-Reply-To: <20130709150728.44381@eggemoggin.niobe.net> References: <51DC2461.7050008@oracle.com>, <20130709135638.184901@eggemoggin.niobe.net>, <51DC82AF.9020308@oracle.com> <20130709150728.44381@eggemoggin.niobe.net> Message-ID: <51DC8C9D.4040204@oracle.com> On 07/09/13 18:07, mark.reinhold at oracle.com wrote: > 2013/7/9 7:37 -0700, dmitry.samersoff at oracle.com: >> As far as I understand, we don't plan to remove changeset - just >> manually close bug in JBS. > > Yes, that's how we're handling this case, per Harold's related message. > Already done. Sorry for all the confusion... From daniel.daugherty at oracle.com Tue Jul 9 15:33:28 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 09 Jul 2013 16:33:28 -0600 Subject: Update JDK8 to b96 In-Reply-To: <51DC855A.5030003@oracle.com> References: <51DC855A.5030003@oracle.com> Message-ID: <51DC8FB8.1070108@oracle.com> Just to make this a little bit easier... If you like to copy a freshly built JVM into a local JDK and you see this message: Error occurred during initialization of VM Unable to load native library: /jre/lib/amd64/libjava.so: symbol JVM_SetProtectionDomain, version SUNWprivate_1.1 not defined in file libjvm.so with link time reference then your JDK is likely older than JDK8-B96 and needs to be updated. Dan On 7/9/13 3:49 PM, Eric McCorkle wrote: > This email is to alert everyone to make sure they are using jdk8-b96 or > later. I submitted a changeset last night which depends on another > changeset present in b96. > > Any hotspot built with sources later than last night and a JDK earlier > than b96 won't work. From david.holmes at oracle.com Tue Jul 9 18:07:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Jul 2013 11:07:26 +1000 Subject: 7u40 RFR: 8012144 - Missing memory barriers In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF3DB7@DEWDFEMB12A.global.corp.sap> References: <51DB5CA2.9040202@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DB7@DEWDFEMB12A.global.corp.sap> Message-ID: <51DCB3CE.1090406@oracle.com> On 9/07/2013 7:01 PM, Lindenmaier, Goetz wrote: > Hi David, > > I'm very happy to see this change go in now. As proposed here > for 7u40, it would also work for our ppc64 port in jdk8. > Yes, Axel tracked down the problem and proposed to add this > barrier. His email is axel.siebenborn at sap.com. Thanks for the info. > Actually, I would use X86 instead of IA32 || AMD64. > (maybe add #include utilities/macros.hpp, but X86 is > defined before all uses of taskqueue.hpp. I tested this > on linux.) Unfortunately I don't have time to make this change and re-do the testing that has already been done. Thanks, David > Best regards, > Goetz. > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 9. Juli 2013 02:43 > To: hotspot-dev developers > Cc: Lindenmaier, Goetz; John Cuthbertson > Subject: 7u40 RFR: 8012144 - Missing memory barriers > > The issue of missing memory barriers in the GC taskqueue code was first > flagged here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html > > and bug 8006971 was opened for it. > > There were some further background discussions that I wasn't party to > and this all somewhat fell between the cracks for a while. > > A trimmed version of the original proposed patch was tested internally > (and I believe by SAP) and that simplified patch is what is being > proposed now, under 8012144, solely for the 7u40 update. I/we intend to > revise the original patch for 8006971 and get that resolved properly for > JDK 8. Meanwhile we have a critical urgency on getting this fixed in 7u40. > > The webrev is here: > > http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ > > Primarily it adds a fence for platforms that require it - with platforms > that don't opting out via the conditional compilation. In this way there > is no performance impact on those mainline SE platforms. (A correctly > expressed lock-free algorithm will not have platform specific fences, > hence the intent to rework this for JDK 8.) Note this is a very low risk > fix regardless because adding memory barriers will not introduce > incorrect behaviour. > > This patch was not supplied by me, but as a follow on from the original > work, via John Cuthbertson. So John is one of the contributors (I > believe Axel Siebenborn is the original contributor - I need an email > address for the attribution!) and I will actually be a Reviewer. > > If anyone has any concerns please raise them quickly as time is very > much against us here. > > Thanks, > David > From daniel.daugherty at oracle.com Tue Jul 9 20:46:41 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 09 Jul 2013 21:46:41 -0600 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <51DC1C62.6050908@oracle.com> References: <51D3065C.6090401@oracle.com> <51DBEEA6.6090904@redhat.com> <51DC1C62.6050908@oracle.com> Message-ID: <51DCD921.7020801@oracle.com> On 7/9/13 8:21 AM, Stefan Karlsson wrote: > On 07/09/2013 01:06 PM, Florian Weimer wrote: >> On 07/02/2013 06:57 PM, Stefan Karlsson wrote: >>> When the JVM starts it reserves a memory area for the entire Java heap. >>> We use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk of >>> memory >>> that no other >>> subsystem of the JVM, or Java program, will be allowed to mmap into. >>> >>> The reservation of the memory only reflects the maximum possible heap >>> size, but often a smaller heap size is used if the memory pressure is >>> low. The part of >>> the heap that is actually used is committed with mmap(...MAP_FIXED...). >> >> Since you mention this, here's a really old pet peeve of mine. >> >> This does not work as intended. mmap(...MAP_NORESERVE...) actually >> commits the memory. The correct way to reserve address space on >> Linux is to drop MAP_NORESERVE and map the memory with PROT_NONE. >> Subsequently, you can commit the memory using mprotect() and suitable >> protection flags. This way, the default heap size will no longer >> cause failures with vm.overcommit_memory=2. > > I wrote a small test program that tries to mmap 2TB on my 8GB machine. > This the outcome from the experiment: > > overcommit_memory = 0 > | MAP_NORESERVE | no MAP_NORESERVE | > +---------------+------------------+ > PROT_WRITE | succeeded | failed | > PROT_NONE | succeeded | succeeded | > +---------------+------------------+ > > overcommit_memory = 1 > | MAP_NORESERVE | no MAP_NORESERVE | > +---------------+------------------+ > PROT_WRITE | succeeded | succeeded | > PROT_NONE | succeeded | succeeded | > +---------------+------------------+ > > overcommit_memory = 2 > | MAP_NORESERVE | no MAP_NORESERVE | > +---------------+------------------+ > PROT_WRITE | failed | failed | > PROT_NONE | succeeded | succeeded | > +---------------+------------------+ > > With PROT_NONE we don't commit memory, independent of the usage of > MAP_NORESERVE. It definitely looks like PROT_NONE has clearer/more consistent semantics than does MAP_NORESERVE when it comes to making a reservation. So what does mprotect() do when you change a PROT_NONE mapping to something else and there is no swap space available? Do you lose your original PROT_NONE mapping entry? Dan > > Note that we recently changed from using PROT_READ|PROT_WRITE to > PROT_NONE when reserving memory in JDK8: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012015 > > > Me and Per Lid?n discussed your suggestion to use mprotect to commit > memory instead of re-mmapping. We think that doing that might actually > solve the problem in: > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a837fa3d3f86 > > where we today shutdown when mmap(...MAP_FIXED...) removes the > previous mapping when mmap fails for small pages. > > We could probably also change this fix for the large pages bug > (8007074) to use the same mprotect strategy. However, we would still > need most of the alignment changes from the 8007074 fix. > >> >> Would you be interested in a patch that improves matters in this area? > > I think so, but I'll defer the question to the hotspot-runtime-dev team. > > If we want to use the mprotect strategy for small we should probably > try to use it for large pages as well. > > thanks, > StefanK > >> >> (Note that this only applies to Linux, not necessarily other systems.) >> > > From vladimir.kozlov at oracle.com Tue Jul 9 21:13:10 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 10 Jul 2013 04:13:10 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130710041316.7B7D748929@hg.openjdk.java.net> Changeset: 1331bffeb46e Author: adlertz Date: 2013-07-09 17:20 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1331bffeb46e 8019625: Test compiler/8005956/PolynomialRoot.java timeouts on Solaris SPARCs Summary: Disable the test for SPARC and reduce the number of test iterations Reviewed-by: kvn ! test/compiler/8005956/PolynomialRoot.java Changeset: 25a649574b3b Author: kvn Date: 2013-07-09 17:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/25a649574b3b Merge From joseph.provino at oracle.com Tue Jul 9 21:38:03 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 10 Jul 2013 00:38:03 -0400 Subject: Review request: avoid native stack walking when compiled without frame pointer In-Reply-To: <51DCA574.1020101@oracle.com> References: <51DAE51C.6070804@oracle.com> <51DB9616.4060107@oracle.com> <51DC6D7E.4090308@oracle.com> <51DCA280.4070009@oracle.com> <51DCA483.40006@oracle.com> <51DCA574.1020101@oracle.com> Message-ID: <51DCE52B.4060209@oracle.com> Hooks are in place to make it easier to change parameters. Webrev is here: http://cr.openjdk.java.net/~jprovino/8017473/webrev.02/ From stefan.karlsson at oracle.com Tue Jul 9 22:27:28 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 10 Jul 2013 07:27:28 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <51DCD921.7020801@oracle.com> References: <51D3065C.6090401@oracle.com> <51DBEEA6.6090904@redhat.com> <51DC1C62.6050908@oracle.com> <51DCD921.7020801@oracle.com> Message-ID: <51DCF0C0.1060509@oracle.com> On 7/10/13 5:46 AM, Daniel D. Daugherty wrote: > > On 7/9/13 8:21 AM, Stefan Karlsson wrote: >> On 07/09/2013 01:06 PM, Florian Weimer wrote: >>> On 07/02/2013 06:57 PM, Stefan Karlsson wrote: >>>> When the JVM starts it reserves a memory area for the entire Java >>>> heap. >>>> We use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk of >>>> memory >>>> that no other >>>> subsystem of the JVM, or Java program, will be allowed to mmap into. >>>> >>>> The reservation of the memory only reflects the maximum possible heap >>>> size, but often a smaller heap size is used if the memory pressure is >>>> low. The part of >>>> the heap that is actually used is committed with >>>> mmap(...MAP_FIXED...). >>> >>> Since you mention this, here's a really old pet peeve of mine. >>> >>> This does not work as intended. mmap(...MAP_NORESERVE...) actually >>> commits the memory. The correct way to reserve address space on >>> Linux is to drop MAP_NORESERVE and map the memory with PROT_NONE. >>> Subsequently, you can commit the memory using mprotect() and >>> suitable protection flags. This way, the default heap size will no >>> longer cause failures with vm.overcommit_memory=2. >> >> I wrote a small test program that tries to mmap 2TB on my 8GB >> machine. This the outcome from the experiment: >> >> overcommit_memory = 0 >> | MAP_NORESERVE | no MAP_NORESERVE | >> +---------------+------------------+ >> PROT_WRITE | succeeded | failed | >> PROT_NONE | succeeded | succeeded | >> +---------------+------------------+ >> >> overcommit_memory = 1 >> | MAP_NORESERVE | no MAP_NORESERVE | >> +---------------+------------------+ >> PROT_WRITE | succeeded | succeeded | >> PROT_NONE | succeeded | succeeded | >> +---------------+------------------+ >> >> overcommit_memory = 2 >> | MAP_NORESERVE | no MAP_NORESERVE | >> +---------------+------------------+ >> PROT_WRITE | failed | failed | >> PROT_NONE | succeeded | succeeded | >> +---------------+------------------+ >> >> With PROT_NONE we don't commit memory, independent of the usage of >> MAP_NORESERVE. > > It definitely looks like PROT_NONE has clearer/more consistent > semantics than does MAP_NORESERVE when it comes to making a > reservation. > > So what does mprotect() do when you change a PROT_NONE mapping > to something else and there is no swap space available? Do you lose > your original PROT_NONE mapping entry? The mapping entry was left intact when I tried that. StefanK > > Dan > > > > > > > >> >> Note that we recently changed from using PROT_READ|PROT_WRITE to >> PROT_NONE when reserving memory in JDK8: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012015 >> >> >> Me and Per Lid?n discussed your suggestion to use mprotect to commit >> memory instead of re-mmapping. We think that doing that might >> actually solve the problem in: >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a837fa3d3f86 >> >> where we today shutdown when mmap(...MAP_FIXED...) removes the >> previous mapping when mmap fails for small pages. >> >> We could probably also change this fix for the large pages bug >> (8007074) to use the same mprotect strategy. However, we would still >> need most of the alignment changes from the 8007074 fix. >> >>> >>> Would you be interested in a patch that improves matters in this area? >> >> I think so, but I'll defer the question to the hotspot-runtime-dev team. >> >> If we want to use the mprotect strategy for small we should probably >> try to use it for large pages as well. >> >> thanks, >> StefanK >> >>> >>> (Note that this only applies to Linux, not necessarily other systems.) >>> >> >> > From david.holmes at oracle.com Tue Jul 9 23:37:55 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 10 Jul 2013 06:37:55 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130710063804.E69804892D@hg.openjdk.java.net> Changeset: c4a8806c0302 Author: dholmes Date: 2013-07-09 21:05 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c4a8806c0302 8012144: multiple SIGSEGVs fails on staxf Summary: Missing fence in taskQueue lock-free code on some platforms Reviewed-by: dholmes, kvn, shade, johnc, goetz Contributed-by: Axel Siebenborn ! src/share/vm/utilities/taskqueue.hpp Changeset: 0d7106aa7e08 Author: dholmes Date: 2013-07-09 21:16 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0d7106aa7e08 Merge Changeset: fc4858327ae8 Author: dholmes Date: 2013-07-10 00:15 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fc4858327ae8 Merge From fweimer at redhat.com Wed Jul 10 00:37:45 2013 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 10 Jul 2013 09:37:45 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <51DCF0C0.1060509@oracle.com> References: <51D3065C.6090401@oracle.com> <51DBEEA6.6090904@redhat.com> <51DC1C62.6050908@oracle.com> <51DCD921.7020801@oracle.com> <51DCF0C0.1060509@oracle.com> Message-ID: <51DD0F49.3070707@redhat.com> On 07/10/2013 07:27 AM, Stefan Karlsson wrote: >> So what does mprotect() do when you change a PROT_NONE mapping >> to something else and there is no swap space available? Do you lose >> your original PROT_NONE mapping entry? > > The mapping entry was left intact when I tried that. And mprotect() is supposed to return ENOMEM in this case. -- Florian Weimer / Red Hat Product Security Team From aleksey.shipilev at oracle.com Wed Jul 10 05:36:15 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 10 Jul 2013 16:36:15 +0400 Subject: 7u40 RFR: 8012144 - Missing memory barriers In-Reply-To: <51DCB3CE.1090406@oracle.com> References: <51DB5CA2.9040202@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DB7@DEWDFEMB12A.global.corp.sap> <51DCB3CE.1090406@oracle.com> Message-ID: <51DD553F.8000409@oracle.com> On 07/10/2013 05:07 AM, David Holmes wrote: > On 9/07/2013 7:01 PM, Lindenmaier, Goetz wrote: >> Actually, I would use X86 instead of IA32 || AMD64. >> (maybe add #include utilities/macros.hpp, but X86 is >> defined before all uses of taskqueue.hpp. I tested this >> on linux.) > > Unfortunately I don't have time to make this change and re-do the > testing that has already been done. Actually, there is a few uses like that already. Hence, it makes little sense to fix this nit in current patch, but rather, do the rehash of IA32||AMD64 -> X86 macro separately. $ ack-grep -Q "defined(IA32) || defined(AMD64)" hotspot/src/ hotspot/src/share/vm/adlc/output_c.cpp 2294:#if defined(IA32) || defined(AMD64) hotspot/src/share/vm/opto/machnode.hpp 97:#if defined(IA32) || defined(AMD64) hotspot/src/share/vm/utilities/macros.hpp 305:#if defined(IA32) || defined(AMD64) hotspot/src/share/vm/interpreter/interpreterRuntime.hpp 139:#if defined(IA32) || defined(AMD64) || defined(ARM) hotspot/src/share/vm/interpreter/interpreterRuntime.cpp 1193:#if defined(IA32) || defined(AMD64) || defined(ARM) hotspot/src/os/windows/vm/os_windows.cpp 2989:#if defined(IA32) || defined(AMD64) 3000:#if defined(IA32) || defined(AMD64) hotspot/src/os/linux/vm/os_linux.cpp 1412:#if defined(IA32) || defined(AMD64) -Aleksey. From stefan.karlsson at oracle.com Wed Jul 10 08:09:14 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 10 Jul 2013 17:09:14 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <51DC25C3.9090501@redhat.com> References: <51D3065C.6090401@oracle.com> <51DBEEA6.6090904@redhat.com> <51DC1C62.6050908@oracle.com> <51DC25C3.9090501@redhat.com> Message-ID: <51DD791A.4080309@oracle.com> On 07/09/2013 05:01 PM, Florian Weimer wrote: > On 07/09/2013 04:21 PM, Stefan Karlsson wrote: >> Note that we recently changed from using PROT_READ|PROT_WRITE to >> PROT_NONE when reserving memory in JDK8: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012015 > > Very cool. I can confirm that this change resolves the long-standing > issue with the standard heap size (a quarter of RAM) and > vm.overcommit_memory=2 mode. Previously, you could not start more > than 3 VMs in parallel, and with the change, that limitation is lifted. > > Any chance we can backport this change to hs24 and jdk7u? Unfortunately, it's not likely that we'll get this into the hs24 release. StefanK From volker.simonis at gmail.com Wed Jul 10 08:28:13 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Jul 2013 17:28:13 +0200 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: <51DB907A.2080208@oracle.com> References: <51D657E6.2060606@oracle.com> <51DB4D3E.40808@oracle.com> <51DB907A.2080208@oracle.com> Message-ID: Hi Vladimir, do you want to push this change or should I do it? Here's the last version with (including David's suggestion of removing ''ADD_SA_BINARIES/ppc64"): http://cr.openjdk.java.net/~simonis/webrevs/8019922.v3/ Thank you and best regards, Volker On Tue, Jul 9, 2013 at 6:24 AM, Vladimir Kozlov wrote: > Tests passed (included our ppc builds and testing). > > Vladimir > > > On 7/8/13 4:37 PM, Vladimir Kozlov wrote: >> >> Looks good. >> >> I started JPRT testing. Hopefully will get result tonight. >> >> Thanks, >> Vladimir >> >> On 7/8/13 8:42 AM, Volker Simonis wrote: >>> >>> Hi David, >>> >>> thank you for the review. I prepared a new webrev according to your >>> suggestions: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8019922.v2/ >>> >>> Please find my comments inline: >>> >>> Thank you and best regards, >>> Volker >>> >>> On Fri, Jul 5, 2013 at 7:21 AM, David Holmes >>> wrote: >>>> >>>> Hi Volker, >>>> >>>> This all looks fine to me. A couple of minor comments below. >>>> >>>> I will also test it but I don't expect to see any conflicts with our >>>> other >>>> ports. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> make/defs.make >>>> >>>> Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the >>>> sparcv9 code and reduce this: >>>> >>>> 288 ifeq ($(BUILDARCH), ppc) >>>> 289 ifdef LP64 >>>> 290 BUILDARCH = ppc64 >>>> 291 else >>>> 292 BUILDARCH = ppc >>>> 293 endif >>>> 294 endif >>>> >>>> to >>>> >>>> 288 ifeq ($(BUILDARCH), ppc) >>>> 289 ifdef LP64 >>>> 290 BUILDARCH = ppc64 >>>> 291 endif >>>> 292 endif >>>> >>>> --- >>> >>> >>> fixed as suggested. >>> >>>> >>>> make/linux/makefiles/defs.make >>>> >>>> I note you have: >>>> >>>> HS_ARCH = ppc >>>> >>>> and this is only used with the SA for which we presently have: >>>> >>>> ADD_SA_BINARIES/ppc = >>>> >>>> but you also added: >>>> >>>> ADD_SA_BINARIES/ppc64 = >>>> >>>> so was the HS_ARCH setting a typo? >>>> >>>> --- >>> >>> >>> Well, I did it in the same way as the other architectures did it:) >>> >>> Moreover, HS_ARCH is also used in make/Makefile. >>> >>>> >>>> make/linux/makefiles/gcc.make >>>> >>>> You added: >>>> >>>> ARCHFLAG/ppc64 = -m64 >>>> >>>> which is fine, but then in ppc64.make you also have: >>>> >>>> CFLAGS += -m64 >>>> LFLAGS_VM += -m64 >>>> AOUT_FLAGS += -m64 >>>> >>>> which seems redundant given gcc.make has: >>>> >>>> 186 CFLAGS += $(ARCHFLAG) >>>> 187 AOUT_FLAGS += $(ARCHFLAG) >>>> 188 LFLAGS += $(ARCHFLAG) >>>> 189 ASFLAGS += $(ARCHFLAG) >>>> >>> >>> You're right. I removed the '-m64' settings from ppc64.make >>> Also, 'LAUNCHERFLAGS' isn't used anymore so I removed it from >>> pp464.make as well. >>> The same applies to 'AOUT_FLAGS' which isn't necessary for our build. >>> >>>> Also the initial copyright line seems suspect: >>>> >>>> 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All >>>> rights >>>> reserved. >>>> >>>> Not sure how a new file can have a 2004-2011 copyright year range ?? >>>> >>> >>> That was a copy-paste issue. After the lengthy discussions below I >>> changed it to "2004, 2013" to keep things simple:) >>> >>>> >>>> >>>> On 5/07/2013 2:07 AM, Volker Simonis wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> can sombody please review this change. It implements the relevant >>>>> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >>>>> touch any existing platforms (but of course testing it on your closed >>>>> platforms - especially ppc - is probably necessary and much >>>>> appreciated). >>>>> >>>>> It also contains two small fixes for the CORE build (one is a type and >>>>> the other is necessary to accomodate to the changes in "8008772: >>>>> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >>>>> to open an extra bug for. >>>>> >>>>> Notice that this patch determines the name and location of the >>>>> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >>>>> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >>>>> 0009_linux_ppc_files.patch. >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>> > From volker.simonis at gmail.com Wed Jul 10 08:29:26 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Jul 2013 17:29:26 +0200 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <51D3515F.10402@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDBDE@DEWDFEMB12A.global.corp.sap> <51D20DEC.7050904@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF1499@DEWDFEMB12A.global.corp.sap> <51D3515F.10402@oracle.com> Message-ID: Hi Vladimir, what's the status of this patch? Are you still evaluate the required closed source changes? Regards, Volker On Wed, Jul 3, 2013 at 12:17 AM, Vladimir Kozlov wrote: > Thank you, Goetz > > We are doing review of closed changes. When they are ready I will push. > > Thanks, > Vladimir > > > On 7/2/13 2:47 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> Sorry for that, I didn't grok the comment. The alignment is a good idea. >> Fixed: >> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Dienstag, 2. Juli 2013 01:17 >> To: Lindenmaier, Goetz >> Cc: 'Christian Thalinger'; 'Albert Noll (albert.noll at oracle.com)'; >> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >> safefetch >> >> Goetz, >> >> Why you did not add 'nop' between load and return instructions on sparc? >> It was in assembler in .s file. The next comment said we need it: >> >> !! By convention with the trap handler we ensure there is a non-CTI >> !! instruction in the trap shadow. >> >> Also should we align code in stubs to keep it in one cache line? >> >> __ align(CodeEntryAlignment); >> *entry = __ pc(); >> >> Thanks, >> Vladimir >> >> On 6/24/13 12:31 PM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> you are right, the check is redundant. >>> I removed it and updated the webrev and also based it on the >>> recent staging repo: >>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Monday, June 24, 2013 7:48 PM >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>> 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>> safefetch >>> >>> >>> On Jun 20, 2013, at 7:01 AM, "Lindenmaier, Goetz" >>> wrote: >>> >>>> Hi, >>>> >>>> I implemented the safefetch stubs for x86 and sparc (was quiet simple). >>>> This way I could clean up the #define right away. >>>> >>>> I tested it thouroughly on >>>> x86_64: bsd, nt, linux, solaris >>>> x86_32: nt, linux >>>> by adding it into our internal VM. >>>> Tonight I will get build/test on >>>> sparc_64 solaris >>>> sparc_32 solaris >>>> x86_64 nt, linux >>>> with the openjdk ppc port, but I tested that before submitting in a >>>> smaller >>>> extend, too. >>>> >>>> Here the webrev: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>> >>> >>> I like this change. It removes a lot of duplication. One comment: >>> >>> + static bool is_safefetch_fault(address pc) { >>> + return pc != NULL && >>> + (pc == _safefetch32_fault_pc || >>> + pc == _safefetchN_fault_pc); >>> + } >>> >>> checks for pc != null. Should we remove the check here? >>> >>> + if (pc && StubRoutines::is_safefetch_fault(pc)) { >>> + set_cont_address(uc, >>> address(StubRoutines::continuation_for_safefetch_fault(pc))); >>> return true; >>> } >>> >>> -- Chris >>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> Sent: Dienstag, 18. Juni 2013 22:44 >>>> To: Lindenmaier, Goetz >>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>> 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>> safefetch >>>> >>>> >>>> On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" >>>> wrote: >>>> >>>>> Ok, I will implement it on x86. >>>>> >>>>> To get a single change, you can give me the sparc patch, >>>>> or you extend the webrev once I updated it with the >>>>> x86 code. >>>> >>>> >>>> Sounds good. Let me know when it's there. >>>> >>>> -- Chris >>>> >>>>> If you prefer, you can also push it to some other repository, it >>>>> will end up in the ppc repo in time I guess. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> Sent: Tuesday, June 18, 2013 6:59 PM >>>>> To: Lindenmaier, Goetz >>>>> Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>> hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>> safefetch >>>>> >>>>> >>>>> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> We have it on these platforms: >>>>>> ia64 (nt, linux, hp_ux) >>>>>> parisc (hp_ux) >>>>>> zArch (linux) >>>>>> ppc (aix, linux) >>>>>> >>>>>> I would implement it on x86 & friends, you do it on sparc and wherever >>>>>> else you like it? >>>>> >>>>> >>>>> That sounds reasonable. Are we pushing this to the ppc repository >>>>> then? >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>> Sent: Dienstag, 18. Juni 2013 07:13 >>>>>> To: Volker Simonis >>>>>> Cc: Lindenmaier, Goetz; Vladimir Kozlov; >>>>>> ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>>> safefetch >>>>>> >>>>>> >>>>>> On Jun 17, 2013, at 10:08 AM, Volker Simonis >>>>>> wrote: >>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> I think the change is good and if the other reviewers don't decide to >>>>>>> implement it for the current platforms we can push it. >>>>>> >>>>>> >>>>>> I talked with Vladimir about this today and I my opinion we should use >>>>>> this stub on all platforms. On which other platforms are you guys having >>>>>> this? >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> By the way, the makefile changes in ppc64.make will follow in patch 8 >>>>>>> for >>>>>>> linux [1] and patch 14 for aix [2]. >>>>>>> The implementation of the stubs will be in patch 9 for linux [3] and >>>>>>> patch >>>>>>> 15 for aix [4] (only the signal handling part). >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>>>>>> [2] >>>>>>> >>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>>>>>> [3] >>>>>>> >>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>>>>>> [4] >>>>>>> >>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>>>>>> goetz.lindenmaier at sap.com> wrote: >>>>>>> >>>>>>>> Hi,**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> the PPC64 port uses stub routines to implement safefetch. We had >>>>>>>> and**** >>>>>>>> >>>>>>>> have problems with inline assembly, especially with non-gcc**** >>>>>>>> >>>>>>>> compilers. Stub routines allow to implement safefetch without**** >>>>>>>> >>>>>>>> depending on OS or compiler, as it's the case with the current**** >>>>>>>> >>>>>>>> implementation. This also allows to use a single implementation if >>>>>>>> an**** >>>>>>>> >>>>>>>> architecture is supported on several os platforms.**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Currently, we guard the code with **** >>>>>>>> >>>>>>>> #ifdef SAFEFETCH_STUBS**** >>>>>>>> >>>>>>>> which is set in ppc64.make.**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> I could also imagine an implementation that uses a pd_debug flag**** >>>>>>>> >>>>>>>> or a const flag set in os_.hpp that allows the C-compiler to >>>>>>>> **** >>>>>>>> >>>>>>>> optimize, and writing the code like this:**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>>>>>> >>>>>>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t >>>>>>>> errValue) ;*** >>>>>>>> * >>>>>>>> >>>>>>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>>>>>> >>>>>>>> if (UseSafefetchStub) {**** >>>>>>>> >>>>>>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet >>>>>>>> generated");*** >>>>>>>> * >>>>>>>> >>>>>>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>>>>>> >>>>>>>> } else {**** >>>>>>>> >>>>>>>> pd_SafeFetch32(adr, errValue);**** >>>>>>>> >>>>>>>> }**** >>>>>>>> >>>>>>>> }**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Unfortunately this requires **** >>>>>>>> >>>>>>>> 1) setting the flag on all platforms**** >>>>>>>> >>>>>>>> 2) renaming the safefetch function on all platfoms.**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Actually I would prefer this second solution as it avoids the >>>>>>>> preprocessor, **** >>>>>>>> >>>>>>>> and am happy to edit the sources accordingly if this finds >>>>>>>> acceptance.**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> For the implementation of a safefetch_stub see**** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>>>> **** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Could I get a review on this change, please?**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Thanks,**** >>>>>>>> >>>>>>>> Goetz.**** >>>>>>>> >>>>>> >>>>> >>>> >>> > From vladimir.kozlov at oracle.com Wed Jul 10 08:31:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Jul 2013 08:31:40 -0700 Subject: RFR (S): 8019922 : PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles In-Reply-To: References: <51D657E6.2060606@oracle.com> <51DB4D3E.40808@oracle.com> <51DB907A.2080208@oracle.com> Message-ID: <51DD7E5C.9040607@oracle.com> I will push it today through JPRT. thanks, Vladimir On 7/10/13 8:28 AM, Volker Simonis wrote: > Hi Vladimir, > > do you want to push this change or should I do it? > > Here's the last version with (including David's suggestion of removing > ''ADD_SA_BINARIES/ppc64"): > > http://cr.openjdk.java.net/~simonis/webrevs/8019922.v3/ > > Thank you and best regards, > Volker > > > On Tue, Jul 9, 2013 at 6:24 AM, Vladimir Kozlov > wrote: >> Tests passed (included our ppc builds and testing). >> >> Vladimir >> >> >> On 7/8/13 4:37 PM, Vladimir Kozlov wrote: >>> >>> Looks good. >>> >>> I started JPRT testing. Hopefully will get result tonight. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/8/13 8:42 AM, Volker Simonis wrote: >>>> >>>> Hi David, >>>> >>>> thank you for the review. I prepared a new webrev according to your >>>> suggestions: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8019922.v2/ >>>> >>>> Please find my comments inline: >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> On Fri, Jul 5, 2013 at 7:21 AM, David Holmes >>>> wrote: >>>>> >>>>> Hi Volker, >>>>> >>>>> This all looks fine to me. A couple of minor comments below. >>>>> >>>>> I will also test it but I don't expect to see any conflicts with our >>>>> other >>>>> ports. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> make/defs.make >>>>> >>>>> Minor observation: As BUILDARCH defaults to SRCARCH you can emulate the >>>>> sparcv9 code and reduce this: >>>>> >>>>> 288 ifeq ($(BUILDARCH), ppc) >>>>> 289 ifdef LP64 >>>>> 290 BUILDARCH = ppc64 >>>>> 291 else >>>>> 292 BUILDARCH = ppc >>>>> 293 endif >>>>> 294 endif >>>>> >>>>> to >>>>> >>>>> 288 ifeq ($(BUILDARCH), ppc) >>>>> 289 ifdef LP64 >>>>> 290 BUILDARCH = ppc64 >>>>> 291 endif >>>>> 292 endif >>>>> >>>>> --- >>>> >>>> >>>> fixed as suggested. >>>> >>>>> >>>>> make/linux/makefiles/defs.make >>>>> >>>>> I note you have: >>>>> >>>>> HS_ARCH = ppc >>>>> >>>>> and this is only used with the SA for which we presently have: >>>>> >>>>> ADD_SA_BINARIES/ppc = >>>>> >>>>> but you also added: >>>>> >>>>> ADD_SA_BINARIES/ppc64 = >>>>> >>>>> so was the HS_ARCH setting a typo? >>>>> >>>>> --- >>>> >>>> >>>> Well, I did it in the same way as the other architectures did it:) >>>> >>>> Moreover, HS_ARCH is also used in make/Makefile. >>>> >>>>> >>>>> make/linux/makefiles/gcc.make >>>>> >>>>> You added: >>>>> >>>>> ARCHFLAG/ppc64 = -m64 >>>>> >>>>> which is fine, but then in ppc64.make you also have: >>>>> >>>>> CFLAGS += -m64 >>>>> LFLAGS_VM += -m64 >>>>> AOUT_FLAGS += -m64 >>>>> >>>>> which seems redundant given gcc.make has: >>>>> >>>>> 186 CFLAGS += $(ARCHFLAG) >>>>> 187 AOUT_FLAGS += $(ARCHFLAG) >>>>> 188 LFLAGS += $(ARCHFLAG) >>>>> 189 ASFLAGS += $(ARCHFLAG) >>>>> >>>> >>>> You're right. I removed the '-m64' settings from ppc64.make >>>> Also, 'LAUNCHERFLAGS' isn't used anymore so I removed it from >>>> pp464.make as well. >>>> The same applies to 'AOUT_FLAGS' which isn't necessary for our build. >>>> >>>>> Also the initial copyright line seems suspect: >>>>> >>>>> 2 # Copyright (c) 2004, 2011, Oracle and/or its affiliates. All >>>>> rights >>>>> reserved. >>>>> >>>>> Not sure how a new file can have a 2004-2011 copyright year range ?? >>>>> >>>> >>>> That was a copy-paste issue. After the lengthy discussions below I >>>> changed it to "2004, 2013" to keep things simple:) >>>> >>>>> >>>>> >>>>> On 5/07/2013 2:07 AM, Volker Simonis wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> can sombody please review this change. It implements the relevant >>>>>> HotSpot make changes to build the HotSpot on Linux/PPC64 and shouldn't >>>>>> touch any existing platforms (but of course testing it on your closed >>>>>> platforms - especially ppc - is probably necessary and much >>>>>> appreciated). >>>>>> >>>>>> It also contains two small fixes for the CORE build (one is a type and >>>>>> the other is necessary to accomodate to the changes in "8008772: >>>>>> remove gamma launcher") in 'make/Makefile' for which I didn't wanted >>>>>> to open an extra bug for. >>>>>> >>>>>> Notice that this patch determines the name and location of the >>>>>> platform relevant files (e.g. src/cpu/ppc/vm/assembler_ppc.cpp or >>>>>> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp) which will come with >>>>>> 0009_linux_ppc_files.patch. >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8019922/ >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>> >> From vladimir.kozlov at oracle.com Wed Jul 10 08:38:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Jul 2013 08:38:16 -0700 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDBDE@DEWDFEMB12A.global.corp.sap> <51D20DEC.7050904@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF1499@DEWDFEMB12A.global.corp.sap> <51D3515F.10402@oracle.com> Message-ID: <51DD7FE8.9070207@oracle.com> Albert is working on other urgent issues so the work on safefetch is delayed. Regards, Vladimir On 7/10/13 8:29 AM, Volker Simonis wrote: > Hi Vladimir, > > what's the status of this patch? > Are you still evaluate the required closed source changes? > > Regards, > Volker > > > On Wed, Jul 3, 2013 at 12:17 AM, Vladimir Kozlov > wrote: >> Thank you, Goetz >> >> We are doing review of closed changes. When they are ready I will push. >> >> Thanks, >> Vladimir >> >> >> On 7/2/13 2:47 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> Sorry for that, I didn't grok the comment. The alignment is a good idea. >>> Fixed: >>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Dienstag, 2. Juli 2013 01:17 >>> To: Lindenmaier, Goetz >>> Cc: 'Christian Thalinger'; 'Albert Noll (albert.noll at oracle.com)'; >>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>> safefetch >>> >>> Goetz, >>> >>> Why you did not add 'nop' between load and return instructions on sparc? >>> It was in assembler in .s file. The next comment said we need it: >>> >>> !! By convention with the trap handler we ensure there is a non-CTI >>> !! instruction in the trap shadow. >>> >>> Also should we align code in stubs to keep it in one cache line? >>> >>> __ align(CodeEntryAlignment); >>> *entry = __ pc(); >>> >>> Thanks, >>> Vladimir >>> >>> On 6/24/13 12:31 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> you are right, the check is redundant. >>>> I removed it and updated the webrev and also based it on the >>>> recent staging repo: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> Sent: Monday, June 24, 2013 7:48 PM >>>> To: Lindenmaier, Goetz >>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>> 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>> safefetch >>>> >>>> >>>> On Jun 20, 2013, at 7:01 AM, "Lindenmaier, Goetz" >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I implemented the safefetch stubs for x86 and sparc (was quiet simple). >>>>> This way I could clean up the #define right away. >>>>> >>>>> I tested it thouroughly on >>>>> x86_64: bsd, nt, linux, solaris >>>>> x86_32: nt, linux >>>>> by adding it into our internal VM. >>>>> Tonight I will get build/test on >>>>> sparc_64 solaris >>>>> sparc_32 solaris >>>>> x86_64 nt, linux >>>>> with the openjdk ppc port, but I tested that before submitting in a >>>>> smaller >>>>> extend, too. >>>>> >>>>> Here the webrev: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>>> >>>> >>>> I like this change. It removes a lot of duplication. One comment: >>>> >>>> + static bool is_safefetch_fault(address pc) { >>>> + return pc != NULL && >>>> + (pc == _safefetch32_fault_pc || >>>> + pc == _safefetchN_fault_pc); >>>> + } >>>> >>>> checks for pc != null. Should we remove the check here? >>>> >>>> + if (pc && StubRoutines::is_safefetch_fault(pc)) { >>>> + set_cont_address(uc, >>>> address(StubRoutines::continuation_for_safefetch_fault(pc))); >>>> return true; >>>> } >>>> >>>> -- Chris >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> Sent: Dienstag, 18. Juni 2013 22:44 >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>>> 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>> safefetch >>>>> >>>>> >>>>> On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" >>>>> wrote: >>>>> >>>>>> Ok, I will implement it on x86. >>>>>> >>>>>> To get a single change, you can give me the sparc patch, >>>>>> or you extend the webrev once I updated it with the >>>>>> x86 code. >>>>> >>>>> >>>>> Sounds good. Let me know when it's there. >>>>> >>>>> -- Chris >>>>> >>>>>> If you prefer, you can also push it to some other repository, it >>>>>> will end up in the ppc repo in time I guess. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>> Sent: Tuesday, June 18, 2013 6:59 PM >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>>> hotspot-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>>> safefetch >>>>>> >>>>>> >>>>>> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We have it on these platforms: >>>>>>> ia64 (nt, linux, hp_ux) >>>>>>> parisc (hp_ux) >>>>>>> zArch (linux) >>>>>>> ppc (aix, linux) >>>>>>> >>>>>>> I would implement it on x86 & friends, you do it on sparc and wherever >>>>>>> else you like it? >>>>>> >>>>>> >>>>>> That sounds reasonable. Are we pushing this to the ppc repository >>>>>> then? >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>>> Sent: Dienstag, 18. Juni 2013 07:13 >>>>>>> To: Volker Simonis >>>>>>> Cc: Lindenmaier, Goetz; Vladimir Kozlov; >>>>>>> ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>>>> safefetch >>>>>>> >>>>>>> >>>>>>> On Jun 17, 2013, at 10:08 AM, Volker Simonis >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> I think the change is good and if the other reviewers don't decide to >>>>>>>> implement it for the current platforms we can push it. >>>>>>> >>>>>>> >>>>>>> I talked with Vladimir about this today and I my opinion we should use >>>>>>> this stub on all platforms. On which other platforms are you guys having >>>>>>> this? >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> By the way, the makefile changes in ppc64.make will follow in patch 8 >>>>>>>> for >>>>>>>> linux [1] and patch 14 for aix [2]. >>>>>>>> The implementation of the stubs will be in patch 9 for linux [3] and >>>>>>>> patch >>>>>>>> 15 for aix [4] (only the signal handling part). >>>>>>>> >>>>>>>> Regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>>>>>>> [2] >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>>>>>>> [3] >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>>>>>>> [4] >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>>>>>>> goetz.lindenmaier at sap.com> wrote: >>>>>>>> >>>>>>>>> Hi,**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> the PPC64 port uses stub routines to implement safefetch. We had >>>>>>>>> and**** >>>>>>>>> >>>>>>>>> have problems with inline assembly, especially with non-gcc**** >>>>>>>>> >>>>>>>>> compilers. Stub routines allow to implement safefetch without**** >>>>>>>>> >>>>>>>>> depending on OS or compiler, as it's the case with the current**** >>>>>>>>> >>>>>>>>> implementation. This also allows to use a single implementation if >>>>>>>>> an**** >>>>>>>>> >>>>>>>>> architecture is supported on several os platforms.**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Currently, we guard the code with **** >>>>>>>>> >>>>>>>>> #ifdef SAFEFETCH_STUBS**** >>>>>>>>> >>>>>>>>> which is set in ppc64.make.**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> I could also imagine an implementation that uses a pd_debug flag**** >>>>>>>>> >>>>>>>>> or a const flag set in os_.hpp that allows the C-compiler to >>>>>>>>> **** >>>>>>>>> >>>>>>>>> optimize, and writing the code like this:**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>>>>>>> >>>>>>>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t >>>>>>>>> errValue) ;*** >>>>>>>>> * >>>>>>>>> >>>>>>>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>>>>>>> >>>>>>>>> if (UseSafefetchStub) {**** >>>>>>>>> >>>>>>>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet >>>>>>>>> generated");*** >>>>>>>>> * >>>>>>>>> >>>>>>>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>>>>>>> >>>>>>>>> } else {**** >>>>>>>>> >>>>>>>>> pd_SafeFetch32(adr, errValue);**** >>>>>>>>> >>>>>>>>> }**** >>>>>>>>> >>>>>>>>> }**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Unfortunately this requires **** >>>>>>>>> >>>>>>>>> 1) setting the flag on all platforms**** >>>>>>>>> >>>>>>>>> 2) renaming the safefetch function on all platfoms.**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Actually I would prefer this second solution as it avoids the >>>>>>>>> preprocessor, **** >>>>>>>>> >>>>>>>>> and am happy to edit the sources accordingly if this finds >>>>>>>>> acceptance.**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> For the implementation of a safefetch_stub see**** >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>>>>> **** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Could I get a review on this change, please?**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Thanks,**** >>>>>>>>> >>>>>>>>> Goetz.**** >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From goetz.lindenmaier at sap.com Wed Jul 10 08:39:11 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 10 Jul 2013 15:39:11 +0000 Subject: 7u40 RFR: 8012144 - Missing memory barriers In-Reply-To: <51DD553F.8000409@oracle.com> References: <51DB5CA2.9040202@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DB7@DEWDFEMB12A.global.corp.sap> <51DCB3CE.1090406@oracle.com> <51DD553F.8000409@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF4CE1@DEWDFEMB12A.global.corp.sap> Hi, that's fine, Best regards, Goetz. -----Original Message----- From: Aleksey Shipilev [mailto:aleksey.shipilev at oracle.com] Sent: Mittwoch, 10. Juli 2013 14:36 To: David Holmes Cc: Lindenmaier, Goetz; hotspot-dev developers Subject: Re: 7u40 RFR: 8012144 - Missing memory barriers On 07/10/2013 05:07 AM, David Holmes wrote: > On 9/07/2013 7:01 PM, Lindenmaier, Goetz wrote: >> Actually, I would use X86 instead of IA32 || AMD64. >> (maybe add #include utilities/macros.hpp, but X86 is >> defined before all uses of taskqueue.hpp. I tested this >> on linux.) > > Unfortunately I don't have time to make this change and re-do the > testing that has already been done. Actually, there is a few uses like that already. Hence, it makes little sense to fix this nit in current patch, but rather, do the rehash of IA32||AMD64 -> X86 macro separately. $ ack-grep -Q "defined(IA32) || defined(AMD64)" hotspot/src/ hotspot/src/share/vm/adlc/output_c.cpp 2294:#if defined(IA32) || defined(AMD64) hotspot/src/share/vm/opto/machnode.hpp 97:#if defined(IA32) || defined(AMD64) hotspot/src/share/vm/utilities/macros.hpp 305:#if defined(IA32) || defined(AMD64) hotspot/src/share/vm/interpreter/interpreterRuntime.hpp 139:#if defined(IA32) || defined(AMD64) || defined(ARM) hotspot/src/share/vm/interpreter/interpreterRuntime.cpp 1193:#if defined(IA32) || defined(AMD64) || defined(ARM) hotspot/src/os/windows/vm/os_windows.cpp 2989:#if defined(IA32) || defined(AMD64) 3000:#if defined(IA32) || defined(AMD64) hotspot/src/os/linux/vm/os_linux.cpp 1412:#if defined(IA32) || defined(AMD64) -Aleksey. From vladimir.danushevsky at oracle.com Wed Jul 10 09:03:42 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Wed, 10 Jul 2013 16:03:42 +0000 Subject: hg: hsx/hsx24/hotspot: 4 new changesets Message-ID: <20130710160354.DB03848957@hg.openjdk.java.net> Changeset: 7bfdc3edfe1a Author: jprovino Date: 2013-07-05 10:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7bfdc3edfe1a 8011064: Some tests have failed with SIGSEGV on arm-hflt on build b82 Summary: NMT_detail doesn't work on ARM because of missing frame pointers. Reviewed-by: dholmes, zgu ! src/share/vm/services/memTracker.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 3a41a31ecbd7 Author: vladidan Date: 2013-07-09 14:10 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3a41a31ecbd7 Merge Changeset: f4d7fb7ba02e Author: vladidan Date: 2013-07-09 16:49 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f4d7fb7ba02e Merge Changeset: c30107a847a3 Author: vladidan Date: 2013-07-10 10:24 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c30107a847a3 Merge From frederic.parain at oracle.com Wed Jul 10 11:21:46 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 10 Jul 2013 18:21:46 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130710182212.45F7348966@hg.openjdk.java.net> Changeset: ba9dacff9c9d Author: hseigel Date: 2013-07-08 19:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ba9dacff9c9d 8014399: Remove JVM_SetProtectionDomain from hotspot Summary: JVM_SetProtectionDomain has been deprecated since 1.5 and is being removed Reviewed-by: coleenp, hseigel Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 26037663c2a6 Author: hseigel Date: 2013-07-08 16:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/26037663c2a6 Merge Changeset: e79a9f26ba2e Author: hseigel Date: 2013-07-08 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e79a9f26ba2e Merge Changeset: 72fce0b2d341 Author: zgu Date: 2013-07-09 13:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/72fce0b2d341 8011760: assert(delta != 0) failed: dup pointer in MemBaseline::malloc_sort_by_addr Summary: Some of qsort implementation on Linux x86 compares element to itself, which is mistakenly treated as duplicate pointer Reviewed-by: dcubed, acorn ! src/share/vm/services/memBaseline.cpp Changeset: 2839ce15e450 Author: zgu Date: 2013-07-09 19:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2839ce15e450 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: 50257d6f5aaa Author: acorn Date: 2013-07-09 14:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/50257d6f5aaa 8013635: VM should no longer create bridges for generic signatures. Summary: Requires: 8013789: Compiler bridges, 8015402: metafactory Reviewed-by: sspitsyn, coleenp, bharadwaj ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/runtime/globals.hpp Changeset: 22baec423e2f Author: acorn Date: 2013-07-09 22:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/22baec423e2f Merge From vladimir.kozlov at oracle.com Wed Jul 10 12:17:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Jul 2013 12:17:54 -0700 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> Message-ID: <51DDB362.1020007@oracle.com> Goetz, macros.hpp is included in all other files. Can we just undef IA64 there?: // This is a REALLY BIG HACK, but on AIX unconditionally defines IA64. // At least on AIX 7.1 this is a real problem because 'systemcfg.h' is indirectly included // by 'pthread.h' and other common system headers. #ifdef AIX #undef IA64 #endif thanks, Vladimir On 7/9/13 6:12 AM, Lindenmaier, Goetz wrote: > Hi, > > Here a webrev without the cleanups: > http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ > > Best regards, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 9. Juli 2013 14:08 > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov > Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > > On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >>> A curious thing to do ;-) >> Yes, I agree. >> >>> Aside: presumably this is included in turn by other standard headers, >>> not directly included - otherwise we could just undef IA64 after the >>> include. >> Yes, that's the case. >> >>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>> think we may even have a RFE for this. AFAIK there are no remaining >>> users of the IA64 code in the hotspot codebase. >> Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win >> Ia64. 8 in development, all soon based on hs25. We also contributed to >> the change cleaning up the IA64 defines. There are only such left >> we need in our code. >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 > > I'm somewhat perplexed. The IA64 uses you still see in the hotspot > sources are ancient remnants of the IA64 support. Most of it has been > stripped out completely. So how anyone could be using any of this is, as > I said, perplexing ??? > >>> #if defined(__GNUC__) && !defined(IA64) >> You are right, I could just leave it as is, except if __GNUC__ is define on AIX, >> who knows ;). If we don't remove it, I need to add !PPC64 so that it's >> inlined in our port on linux. >>> more to avoid build-failures, but we may still want to avoid inlining >>> them for other reasons! So this aspect needs further investigation. Or >> I think it's a good idea to clean it up. The build problem >> is documented. There may be 'other reasons', but unexpected issues >> can be there with any change. > > But the aim is to avoid making gratuitous changes to code that is not > part of the ppc64/AIX port. If you start inlining these functions you > don't know what the impact will be. So why change them when it is not > necessary. > > David > ----- > >>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>> Again if we just get rid of IA64 this will be a non-issue right? >> Here I would add !AIX. >> But have a look at the file, there are also several other platforms >> where this is excluded, and the exclusion is implemented differently >> on each platform. Not that nice ... >> >> Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing >> functional. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 9. Juli 2013 03:56 >> To: Lindenmaier, Goetz >> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >> >> Hi Goetz, >> >> On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> This is in preparation of the PPC AIX port. >>> >>> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. >> >> A curious thing to do ;-) >> >> Aside: presumably this is included in turn by other standard headers, >> not directly included - otherwise we could just undef IA64 after the >> include. >> >>> This leads to wrong configurations of shared files on Aix where IA64 is used. >>> This change replaces uses of "IA64" by "IA64 && !AIX". >> >> Might be simpler if we just eradicate the IA64 remnants in the code. I >> think we may even have a RFE for this. AFAIK there are no remaining >> users of the IA64 code in the hotspot codebase. >> >>> To reduce the complexity we propose to simplify two matters: >>> >>> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >>> define #define ATTR __attribute__((noinline)) claiming this is needed >>> to avoid a gcc build time error with - at that time - old gcc versions. >>> This define depends on IA64. We remove it altogether. >> >> Well it doesn't "depend" on IA64: >> >> #if defined(__GNUC__) && !defined(IA64) >> // Need to inhibit inlining for older versions of GCC to avoid >> build-time failures >> #define ATTR __attribute__((noinline)) >> #else >> #define ATTR >> #endif >> >> it becomes empty on IA64 (and non gcc systems). So removing it >> altogether is changing things for all the other gcc using platforms. Now >> it may be that we don't need to preclude inlining of these methods any >> more to avoid build-failures, but we may still want to avoid inlining >> them for other reasons! So this aspect needs further investigation. Or >> you can just leave it as-is - if you have IA64 always defined then you >> will get the empty #else part. Or if we go with the "eradicate IA64" >> path then you can change IA64 to AIX (though it is odd to exchange an >> architecture check with an OS check). >> >>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>> support on windows, apple and ia64. We would have to add Aix. >>> Instead, we propose to use a check for the supported platforms (see webrev). >>> We could also add a macro SUPPORTS_FORTE that is defined in the corresponding >>> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >>> directories. >> >> Again if we just get rid of IA64 this will be a non-issue right? >> >> Thanks, >> David >> >>> Are there other platforms that need to be supported? I derived the platforms >>> from the comment in forte.cpp. >>> >>> Please review this change. I'm happy to incorporate your comments. >>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >>> >>> Best regards, >>> Goetz. >>> From bill.pittore at oracle.com Wed Jul 10 12:29:54 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 10 Jul 2013 15:29:54 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: References: <51D494E9.2020200@oracle.com> Message-ID: <51DDB632.4050805@oracle.com> On 7/3/2013 6:32 PM, Jeremy Manson wrote: > I know that this is mentioned in the JEP, but does it really make > sense to have -agentpath work here, rather than just -agentlib? I > would think that specifying a full pathname and getting the library > loaded out of the launcher would be a little surprising to people who > are basically saying "please load this agent from the given path". > > Also, in practice, we do something very similar at Google, and, when > testing, I find it occasionally useful to be able to say "please load > this agent on the command line via the agentpath I gave you, rather > than loading the one with the same name I baked into the launcher". > > (FWIW, when we did this internally at Google, we added a special -XX > flag for when the agent is in the launcher. I know that you don't > want to go that way, though.) > Thanks for the comments. I would say the thinking here is that we want this to be as transparent as possible to the end user. In our view of the end user is someone perhaps using an IDE and the actual execution of the VM with agent arguments is hidden. In your case it sounds like you are actually developing agents which is a whole different ball game. I could certainly see adding a -XX argument that forces agentpath to load the external library which would be good for agent development and debugging. No need to relink the entire VM with the new agent. Our tech lead is out on vacation this week so I'll bring this up when he's back. bill > > On Wed, Jul 3, 2013 at 2:17 PM, BILL PITTORE > wrote: > > These changes address bug 8014135 which adds support for > statically linked agents in the VM. This is a followup to the > recent JNI spec changes that addressed statically linked JNI > libraries( 8005716). > The JEP for this change is the same JEP as the JNI changes: > http://openjdk.java.net/jeps/178 > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ > > > The changes to jvmti.xml can also be seen in the output file that > I placed here: > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html > > > Thanks, > bill > > > From goetz.lindenmaier at sap.com Wed Jul 10 14:00:30 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 10 Jul 2013 21:00:30 +0000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <51DDB362.1020007@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> <51DDB362.1020007@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF4D9B@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I thought about that, too. But it seems quiet risky to me, as it depends on the final order of inclusion whether it works. Usually, macro.hpp will be included early, because it's basics that should be seen everywhere. Also, it will end up early in the preprocessed file as it has no other includes itself. If the system headers are included later, they will overrule the undef in macro.hpp. I think it's even some kind of pattern in the hotspot files to include the system headers after the hotspot headers. So even if it works now, it easily might break. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, July 10, 2013 9:18 PM To: Lindenmaier, Goetz Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. Goetz, macros.hpp is included in all other files. Can we just undef IA64 there?: // This is a REALLY BIG HACK, but on AIX unconditionally defines IA64. // At least on AIX 7.1 this is a real problem because 'systemcfg.h' is indirectly included // by 'pthread.h' and other common system headers. #ifdef AIX #undef IA64 #endif thanks, Vladimir On 7/9/13 6:12 AM, Lindenmaier, Goetz wrote: > Hi, > > Here a webrev without the cleanups: > http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ > > Best regards, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 9. Juli 2013 14:08 > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov > Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > > On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >>> A curious thing to do ;-) >> Yes, I agree. >> >>> Aside: presumably this is included in turn by other standard headers, >>> not directly included - otherwise we could just undef IA64 after the >>> include. >> Yes, that's the case. >> >>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>> think we may even have a RFE for this. AFAIK there are no remaining >>> users of the IA64 code in the hotspot codebase. >> Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win >> Ia64. 8 in development, all soon based on hs25. We also contributed to >> the change cleaning up the IA64 defines. There are only such left >> we need in our code. >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 > > I'm somewhat perplexed. The IA64 uses you still see in the hotspot > sources are ancient remnants of the IA64 support. Most of it has been > stripped out completely. So how anyone could be using any of this is, as > I said, perplexing ??? > >>> #if defined(__GNUC__) && !defined(IA64) >> You are right, I could just leave it as is, except if __GNUC__ is define on AIX, >> who knows ;). If we don't remove it, I need to add !PPC64 so that it's >> inlined in our port on linux. >>> more to avoid build-failures, but we may still want to avoid inlining >>> them for other reasons! So this aspect needs further investigation. Or >> I think it's a good idea to clean it up. The build problem >> is documented. There may be 'other reasons', but unexpected issues >> can be there with any change. > > But the aim is to avoid making gratuitous changes to code that is not > part of the ppc64/AIX port. If you start inlining these functions you > don't know what the impact will be. So why change them when it is not > necessary. > > David > ----- > >>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>> Again if we just get rid of IA64 this will be a non-issue right? >> Here I would add !AIX. >> But have a look at the file, there are also several other platforms >> where this is excluded, and the exclusion is implemented differently >> on each platform. Not that nice ... >> >> Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing >> functional. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 9. Juli 2013 03:56 >> To: Lindenmaier, Goetz >> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >> >> Hi Goetz, >> >> On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> This is in preparation of the PPC AIX port. >>> >>> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. >> >> A curious thing to do ;-) >> >> Aside: presumably this is included in turn by other standard headers, >> not directly included - otherwise we could just undef IA64 after the >> include. >> >>> This leads to wrong configurations of shared files on Aix where IA64 is used. >>> This change replaces uses of "IA64" by "IA64 && !AIX". >> >> Might be simpler if we just eradicate the IA64 remnants in the code. I >> think we may even have a RFE for this. AFAIK there are no remaining >> users of the IA64 code in the hotspot codebase. >> >>> To reduce the complexity we propose to simplify two matters: >>> >>> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >>> define #define ATTR __attribute__((noinline)) claiming this is needed >>> to avoid a gcc build time error with - at that time - old gcc versions. >>> This define depends on IA64. We remove it altogether. >> >> Well it doesn't "depend" on IA64: >> >> #if defined(__GNUC__) && !defined(IA64) >> // Need to inhibit inlining for older versions of GCC to avoid >> build-time failures >> #define ATTR __attribute__((noinline)) >> #else >> #define ATTR >> #endif >> >> it becomes empty on IA64 (and non gcc systems). So removing it >> altogether is changing things for all the other gcc using platforms. Now >> it may be that we don't need to preclude inlining of these methods any >> more to avoid build-failures, but we may still want to avoid inlining >> them for other reasons! So this aspect needs further investigation. Or >> you can just leave it as-is - if you have IA64 always defined then you >> will get the empty #else part. Or if we go with the "eradicate IA64" >> path then you can change IA64 to AIX (though it is odd to exchange an >> architecture check with an OS check). >> >>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>> support on windows, apple and ia64. We would have to add Aix. >>> Instead, we propose to use a check for the supported platforms (see webrev). >>> We could also add a macro SUPPORTS_FORTE that is defined in the corresponding >>> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >>> directories. >> >> Again if we just get rid of IA64 this will be a non-issue right? >> >> Thanks, >> David >> >>> Are there other platforms that need to be supported? I derived the platforms >>> from the comment in forte.cpp. >>> >>> Please review this change. I'm happy to incorporate your comments. >>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >>> >>> Best regards, >>> Goetz. >>> From vladimir.kozlov at oracle.com Wed Jul 10 14:41:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Jul 2013 14:41:49 -0700 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF4D9B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> <51DDB362.1020007@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF4D9B@DEWDFEMB12A.global.corp.sap> Message-ID: <51DDD51D.4090505@oracle.com> On 7/10/13 2:00 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I thought about that, too. But it seems quiet risky to me, > as it depends on the final order of inclusion whether it works. > Usually, macro.hpp will be included early, because it's basics that should > be seen everywhere. Also, it will end up early in the preprocessed > file as it has no other includes itself. > > If the system headers are included later, they will overrule the undef in > macro.hpp. > I think it's even some kind of pattern in the hotspot files to include the > system headers after the hotspot headers. > > So even if it works now, it easily might break. Agree. Your changes are good then. thanks, Vladimir > > Best regards, > Goetz. > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, July 10, 2013 9:18 PM > To: Lindenmaier, Goetz > Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > > Goetz, > > macros.hpp is included in all other files. Can we just undef IA64 there?: > > // This is a REALLY BIG HACK, but on AIX > unconditionally defines IA64. > // At least on AIX 7.1 this is a real problem because 'systemcfg.h' is > indirectly included > // by 'pthread.h' and other common system headers. > #ifdef AIX > #undef IA64 > #endif > > thanks, > Vladimir > > On 7/9/13 6:12 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> Here a webrev without the cleanups: >> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 9. Juli 2013 14:08 >> To: Lindenmaier, Goetz >> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >> >> On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>>> A curious thing to do ;-) >>> Yes, I agree. >>> >>>> Aside: presumably this is included in turn by other standard headers, >>>> not directly included - otherwise we could just undef IA64 after the >>>> include. >>> Yes, that's the case. >>> >>>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>>> think we may even have a RFE for this. AFAIK there are no remaining >>>> users of the IA64 code in the hotspot codebase. >>> Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win >>> Ia64. 8 in development, all soon based on hs25. We also contributed to >>> the change cleaning up the IA64 defines. There are only such left >>> we need in our code. >>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 >> >> I'm somewhat perplexed. The IA64 uses you still see in the hotspot >> sources are ancient remnants of the IA64 support. Most of it has been >> stripped out completely. So how anyone could be using any of this is, as >> I said, perplexing ??? >> >>>> #if defined(__GNUC__) && !defined(IA64) >>> You are right, I could just leave it as is, except if __GNUC__ is define on AIX, >>> who knows ;). If we don't remove it, I need to add !PPC64 so that it's >>> inlined in our port on linux. >>>> more to avoid build-failures, but we may still want to avoid inlining >>>> them for other reasons! So this aspect needs further investigation. Or >>> I think it's a good idea to clean it up. The build problem >>> is documented. There may be 'other reasons', but unexpected issues >>> can be there with any change. >> >> But the aim is to avoid making gratuitous changes to code that is not >> part of the ppc64/AIX port. If you start inlining these functions you >> don't know what the impact will be. So why change them when it is not >> necessary. >> >> David >> ----- >> >>>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>> Again if we just get rid of IA64 this will be a non-issue right? >>> Here I would add !AIX. >>> But have a look at the file, there are also several other platforms >>> where this is excluded, and the exclusion is implemented differently >>> on each platform. Not that nice ... >>> >>> Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing >>> functional. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 9. Juli 2013 03:56 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >>> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >>> >>> Hi Goetz, >>> >>> On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> This is in preparation of the PPC AIX port. >>>> >>>> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. >>> >>> A curious thing to do ;-) >>> >>> Aside: presumably this is included in turn by other standard headers, >>> not directly included - otherwise we could just undef IA64 after the >>> include. >>> >>>> This leads to wrong configurations of shared files on Aix where IA64 is used. >>>> This change replaces uses of "IA64" by "IA64 && !AIX". >>> >>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>> think we may even have a RFE for this. AFAIK there are no remaining >>> users of the IA64 code in the hotspot codebase. >>> >>>> To reduce the complexity we propose to simplify two matters: >>>> >>>> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >>>> define #define ATTR __attribute__((noinline)) claiming this is needed >>>> to avoid a gcc build time error with - at that time - old gcc versions. >>>> This define depends on IA64. We remove it altogether. >>> >>> Well it doesn't "depend" on IA64: >>> >>> #if defined(__GNUC__) && !defined(IA64) >>> // Need to inhibit inlining for older versions of GCC to avoid >>> build-time failures >>> #define ATTR __attribute__((noinline)) >>> #else >>> #define ATTR >>> #endif >>> >>> it becomes empty on IA64 (and non gcc systems). So removing it >>> altogether is changing things for all the other gcc using platforms. Now >>> it may be that we don't need to preclude inlining of these methods any >>> more to avoid build-failures, but we may still want to avoid inlining >>> them for other reasons! So this aspect needs further investigation. Or >>> you can just leave it as-is - if you have IA64 always defined then you >>> will get the empty #else part. Or if we go with the "eradicate IA64" >>> path then you can change IA64 to AIX (though it is odd to exchange an >>> architecture check with an OS check). >>> >>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>> support on windows, apple and ia64. We would have to add Aix. >>>> Instead, we propose to use a check for the supported platforms (see webrev). >>>> We could also add a macro SUPPORTS_FORTE that is defined in the corresponding >>>> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >>>> directories. >>> >>> Again if we just get rid of IA64 this will be a non-issue right? >>> >>> Thanks, >>> David >>> >>>> Are there other platforms that need to be supported? I derived the platforms >>>> from the comment in forte.cpp. >>>> >>>> Please review this change. I'm happy to incorporate your comments. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >>>> >>>> Best regards, >>>> Goetz. >>>> From daniel.daugherty at oracle.com Wed Jul 10 19:43:09 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 11 Jul 2013 02:43:09 +0000 Subject: hg: hsx/hsx24/hotspot: 8015884: runThese crashed with SIGSEGV, hs_err has an error instead of stacktrace Message-ID: <20130711024314.9486A48984@hg.openjdk.java.net> Changeset: 6fa8cb2866c0 Author: dcubed Date: 2013-07-10 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6fa8cb2866c0 8015884: runThese crashed with SIGSEGV, hs_err has an error instead of stacktrace Summary: Dl_info struct should only be used if dladdr() has returned non-zero (no errors) and always check the dladdr() return value; Dl_info.dli_sname and Dl_info.dli_saddr fields should only be used if non-NULL; update/improve runtime/6888954/vmerrors.sh test Reviewed-by: dsamersoff, zgu, hseigel, coleenp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! test/runtime/6888954/vmerrors.sh From david.holmes at oracle.com Wed Jul 10 20:26:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jul 2013 13:26:38 +1000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> Message-ID: <51DE25EE.8000805@oracle.com> On 9/07/2013 10:15 PM, Volker Simonis wrote: > On Tue, Jul 9, 2013 at 2:08 PM, David Holmes wrote: >> On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: >>> >>> Hi David, >>> >>>> A curious thing to do ;-) >>> >>> Yes, I agree. >>> >>>> Aside: presumably this is included in turn by other standard headers, >>>> not directly included - otherwise we could just undef IA64 after the >>>> include. >>> >>> Yes, that's the case. >>> >>>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>>> think we may even have a RFE for this. AFAIK there are no remaining >>>> users of the IA64 code in the hotspot codebase. >>> >>> Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win >>> Ia64. 8 in development, all soon based on hs25. We also contributed to >>> the change cleaning up the IA64 defines. There are only such left >>> we need in our code. >>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 >> >> >> I'm somewhat perplexed. The IA64 uses you still see in the hotspot sources >> are ancient remnants of the IA64 support. Most of it has been stripped out >> completely. So how anyone could be using any of this is, as I said, >> perplexing ??? >> > > You're too Oracle-centric, but it's not only Oracle who has closed > HotSpot ports:) I understand that, but as I said we have been gradually removing IA64 support from all over the shared codebase. So I'm still surprised that anyone with an IA64 port could possibly be relying on the remaining fragments. But so be it. David ----- >> >>>> #if defined(__GNUC__) && !defined(IA64) >>> >>> You are right, I could just leave it as is, except if __GNUC__ is define >>> on AIX, >>> who knows ;). If we don't remove it, I need to add !PPC64 so that it's >>> inlined in our port on linux. >>>> >>>> more to avoid build-failures, but we may still want to avoid inlining >>>> them for other reasons! So this aspect needs further investigation. Or >>> >>> I think it's a good idea to clean it up. The build problem >>> is documented. There may be 'other reasons', but unexpected issues >>> can be there with any change. >> >> >> But the aim is to avoid making gratuitous changes to code that is not part >> of the ppc64/AIX port. If you start inlining these functions you don't know >> what the impact will be. So why change them when it is not necessary. >> >> David >> ----- >> >> >>>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>> >>>> Again if we just get rid of IA64 this will be a non-issue right? >>> >>> Here I would add !AIX. >>> But have a look at the file, there are also several other platforms >>> where this is excluded, and the exclusion is implemented differently >>> on each platform. Not that nice ... >>> >>> Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing >>> functional. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 9. Juli 2013 03:56 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; >>> Vladimir Kozlov >>> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor >>> conditionals on AIX. >>> >>> Hi Goetz, >>> >>> On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> This is in preparation of the PPC AIX port. >>>> >>>> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" >>>> unconditionally. >>> >>> >>> A curious thing to do ;-) >>> >>> Aside: presumably this is included in turn by other standard headers, >>> not directly included - otherwise we could just undef IA64 after the >>> include. >>> >>>> This leads to wrong configurations of shared files on Aix where IA64 is >>>> used. >>>> This change replaces uses of "IA64" by "IA64 && !AIX". >>> >>> >>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>> think we may even have a RFE for this. AFAIK there are no remaining >>> users of the IA64 code in the hotspot codebase. >>> >>>> To reduce the complexity we propose to simplify two matters: >>>> >>>> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >>>> define #define ATTR __attribute__((noinline)) claiming this is needed >>>> to avoid a gcc build time error with - at that time - old gcc versions. >>>> This define depends on IA64. We remove it altogether. >>> >>> >>> Well it doesn't "depend" on IA64: >>> >>> #if defined(__GNUC__) && !defined(IA64) >>> // Need to inhibit inlining for older versions of GCC to avoid >>> build-time failures >>> #define ATTR __attribute__((noinline)) >>> #else >>> #define ATTR >>> #endif >>> >>> it becomes empty on IA64 (and non gcc systems). So removing it >>> altogether is changing things for all the other gcc using platforms. Now >>> it may be that we don't need to preclude inlining of these methods any >>> more to avoid build-failures, but we may still want to avoid inlining >>> them for other reasons! So this aspect needs further investigation. Or >>> you can just leave it as-is - if you have IA64 always defined then you >>> will get the empty #else part. Or if we go with the "eradicate IA64" >>> path then you can change IA64 to AIX (though it is odd to exchange an >>> architecture check with an OS check). >>> >>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>> support on windows, apple and ia64. We would have to add Aix. >>>> Instead, we propose to use a check for the supported platforms (see >>>> webrev). >>>> We could also add a macro SUPPORTS_FORTE that is defined in the >>>> corresponding >>>> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >>>> directories. >>> >>> >>> Again if we just get rid of IA64 this will be a non-issue right? >>> >>> Thanks, >>> David >>> >>>> Are there other platforms that need to be supported? I derived the >>>> platforms >>>> from the comment in forte.cpp. >>>> >>>> Please review this change. I'm happy to incorporate your comments. >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >>>> >>>> Best regards, >>>> Goetz. >>>> >> From david.holmes at oracle.com Wed Jul 10 20:29:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jul 2013 13:29:43 +1000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> Message-ID: <51DE26A7.7030106@oracle.com> On 9/07/2013 11:12 PM, Lindenmaier, Goetz wrote: > Hi, > > Here a webrev without the cleanups: > http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ Thanks. Looks good. David ----- > Best regards, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 9. Juli 2013 14:08 > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov > Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > > On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >>> A curious thing to do ;-) >> Yes, I agree. >> >>> Aside: presumably this is included in turn by other standard headers, >>> not directly included - otherwise we could just undef IA64 after the >>> include. >> Yes, that's the case. >> >>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>> think we may even have a RFE for this. AFAIK there are no remaining >>> users of the IA64 code in the hotspot codebase. >> Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win >> Ia64. 8 in development, all soon based on hs25. We also contributed to >> the change cleaning up the IA64 defines. There are only such left >> we need in our code. >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 > > I'm somewhat perplexed. The IA64 uses you still see in the hotspot > sources are ancient remnants of the IA64 support. Most of it has been > stripped out completely. So how anyone could be using any of this is, as > I said, perplexing ??? > >>> #if defined(__GNUC__) && !defined(IA64) >> You are right, I could just leave it as is, except if __GNUC__ is define on AIX, >> who knows ;). If we don't remove it, I need to add !PPC64 so that it's >> inlined in our port on linux. >>> more to avoid build-failures, but we may still want to avoid inlining >>> them for other reasons! So this aspect needs further investigation. Or >> I think it's a good idea to clean it up. The build problem >> is documented. There may be 'other reasons', but unexpected issues >> can be there with any change. > > But the aim is to avoid making gratuitous changes to code that is not > part of the ppc64/AIX port. If you start inlining these functions you > don't know what the impact will be. So why change them when it is not > necessary. > > David > ----- > >>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>> Again if we just get rid of IA64 this will be a non-issue right? >> Here I would add !AIX. >> But have a look at the file, there are also several other platforms >> where this is excluded, and the exclusion is implemented differently >> on each platform. Not that nice ... >> >> Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing >> functional. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 9. Juli 2013 03:56 >> To: Lindenmaier, Goetz >> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >> >> Hi Goetz, >> >> On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> This is in preparation of the PPC AIX port. >>> >>> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. >> >> A curious thing to do ;-) >> >> Aside: presumably this is included in turn by other standard headers, >> not directly included - otherwise we could just undef IA64 after the >> include. >> >>> This leads to wrong configurations of shared files on Aix where IA64 is used. >>> This change replaces uses of "IA64" by "IA64 && !AIX". >> >> Might be simpler if we just eradicate the IA64 remnants in the code. I >> think we may even have a RFE for this. AFAIK there are no remaining >> users of the IA64 code in the hotspot codebase. >> >>> To reduce the complexity we propose to simplify two matters: >>> >>> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >>> define #define ATTR __attribute__((noinline)) claiming this is needed >>> to avoid a gcc build time error with - at that time - old gcc versions. >>> This define depends on IA64. We remove it altogether. >> >> Well it doesn't "depend" on IA64: >> >> #if defined(__GNUC__) && !defined(IA64) >> // Need to inhibit inlining for older versions of GCC to avoid >> build-time failures >> #define ATTR __attribute__((noinline)) >> #else >> #define ATTR >> #endif >> >> it becomes empty on IA64 (and non gcc systems). So removing it >> altogether is changing things for all the other gcc using platforms. Now >> it may be that we don't need to preclude inlining of these methods any >> more to avoid build-failures, but we may still want to avoid inlining >> them for other reasons! So this aspect needs further investigation. Or >> you can just leave it as-is - if you have IA64 always defined then you >> will get the empty #else part. Or if we go with the "eradicate IA64" >> path then you can change IA64 to AIX (though it is odd to exchange an >> architecture check with an OS check). >> >>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>> support on windows, apple and ia64. We would have to add Aix. >>> Instead, we propose to use a check for the supported platforms (see webrev). >>> We could also add a macro SUPPORTS_FORTE that is defined in the corresponding >>> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >>> directories. >> >> Again if we just get rid of IA64 this will be a non-issue right? >> >> Thanks, >> David >> >>> Are there other platforms that need to be supported? I derived the platforms >>> from the comment in forte.cpp. >>> >>> Please review this change. I'm happy to incorporate your comments. >>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >>> >>> Best regards, >>> Goetz. >>> From zhengyu.gu at oracle.com Wed Jul 10 21:53:20 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Thu, 11 Jul 2013 04:53:20 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130711045327.9B68D48987@hg.openjdk.java.net> Changeset: c0b13febbf45 Author: zgu Date: 2013-07-09 13:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c0b13febbf45 8011760: assert(delta != 0) failed: dup pointer in MemBaseline::malloc_sort_by_addr Summary: Some of qsort implementation on Linux x86 compares element to itself, which is mistakenly treated as duplicate pointer Reviewed-by: dcubed, acorn ! src/share/vm/services/memBaseline.cpp Changeset: cd8439e6d2d6 Author: zgu Date: 2013-07-11 04:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cd8439e6d2d6 Merge From goetz.lindenmaier at sap.com Thu Jul 11 03:27:17 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 11 Jul 2013 10:27:17 +0000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <51DDD51D.4090505@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> <51DDB362.1020007@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF4D9B@DEWDFEMB12A.global.corp.sap> <51DDD51D.4090505@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF5148@DEWDFEMB12A.global.corp.sap> David, Vladimir, thanks for the reviews! Vladimir, will you push it, or should I do it? I added the Reviewed-by line to the webrev. http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Mittwoch, 10. Juli 2013 23:42 To: Lindenmaier, Goetz Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. On 7/10/13 2:00 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I thought about that, too. But it seems quiet risky to me, > as it depends on the final order of inclusion whether it works. > Usually, macro.hpp will be included early, because it's basics that should > be seen everywhere. Also, it will end up early in the preprocessed > file as it has no other includes itself. > > If the system headers are included later, they will overrule the undef in > macro.hpp. > I think it's even some kind of pattern in the hotspot files to include the > system headers after the hotspot headers. > > So even if it works now, it easily might break. Agree. Your changes are good then. thanks, Vladimir > > Best regards, > Goetz. > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, July 10, 2013 9:18 PM > To: Lindenmaier, Goetz > Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > > Goetz, > > macros.hpp is included in all other files. Can we just undef IA64 there?: > > // This is a REALLY BIG HACK, but on AIX > unconditionally defines IA64. > // At least on AIX 7.1 this is a real problem because 'systemcfg.h' is > indirectly included > // by 'pthread.h' and other common system headers. > #ifdef AIX > #undef IA64 > #endif > > thanks, > Vladimir > > On 7/9/13 6:12 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> Here a webrev without the cleanups: >> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 9. Juli 2013 14:08 >> To: Lindenmaier, Goetz >> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >> >> On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>>> A curious thing to do ;-) >>> Yes, I agree. >>> >>>> Aside: presumably this is included in turn by other standard headers, >>>> not directly included - otherwise we could just undef IA64 after the >>>> include. >>> Yes, that's the case. >>> >>>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>>> think we may even have a RFE for this. AFAIK there are no remaining >>>> users of the IA64 code in the hotspot codebase. >>> Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win >>> Ia64. 8 in development, all soon based on hs25. We also contributed to >>> the change cleaning up the IA64 defines. There are only such left >>> we need in our code. >>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 >> >> I'm somewhat perplexed. The IA64 uses you still see in the hotspot >> sources are ancient remnants of the IA64 support. Most of it has been >> stripped out completely. So how anyone could be using any of this is, as >> I said, perplexing ??? >> >>>> #if defined(__GNUC__) && !defined(IA64) >>> You are right, I could just leave it as is, except if __GNUC__ is define on AIX, >>> who knows ;). If we don't remove it, I need to add !PPC64 so that it's >>> inlined in our port on linux. >>>> more to avoid build-failures, but we may still want to avoid inlining >>>> them for other reasons! So this aspect needs further investigation. Or >>> I think it's a good idea to clean it up. The build problem >>> is documented. There may be 'other reasons', but unexpected issues >>> can be there with any change. >> >> But the aim is to avoid making gratuitous changes to code that is not >> part of the ppc64/AIX port. If you start inlining these functions you >> don't know what the impact will be. So why change them when it is not >> necessary. >> >> David >> ----- >> >>>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>> Again if we just get rid of IA64 this will be a non-issue right? >>> Here I would add !AIX. >>> But have a look at the file, there are also several other platforms >>> where this is excluded, and the exclusion is implemented differently >>> on each platform. Not that nice ... >>> >>> Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing >>> functional. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 9. Juli 2013 03:56 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >>> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >>> >>> Hi Goetz, >>> >>> On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> This is in preparation of the PPC AIX port. >>>> >>>> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. >>> >>> A curious thing to do ;-) >>> >>> Aside: presumably this is included in turn by other standard headers, >>> not directly included - otherwise we could just undef IA64 after the >>> include. >>> >>>> This leads to wrong configurations of shared files on Aix where IA64 is used. >>>> This change replaces uses of "IA64" by "IA64 && !AIX". >>> >>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>> think we may even have a RFE for this. AFAIK there are no remaining >>> users of the IA64 code in the hotspot codebase. >>> >>>> To reduce the complexity we propose to simplify two matters: >>>> >>>> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >>>> define #define ATTR __attribute__((noinline)) claiming this is needed >>>> to avoid a gcc build time error with - at that time - old gcc versions. >>>> This define depends on IA64. We remove it altogether. >>> >>> Well it doesn't "depend" on IA64: >>> >>> #if defined(__GNUC__) && !defined(IA64) >>> // Need to inhibit inlining for older versions of GCC to avoid >>> build-time failures >>> #define ATTR __attribute__((noinline)) >>> #else >>> #define ATTR >>> #endif >>> >>> it becomes empty on IA64 (and non gcc systems). So removing it >>> altogether is changing things for all the other gcc using platforms. Now >>> it may be that we don't need to preclude inlining of these methods any >>> more to avoid build-failures, but we may still want to avoid inlining >>> them for other reasons! So this aspect needs further investigation. Or >>> you can just leave it as-is - if you have IA64 always defined then you >>> will get the empty #else part. Or if we go with the "eradicate IA64" >>> path then you can change IA64 to AIX (though it is odd to exchange an >>> architecture check with an OS check). >>> >>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>> support on windows, apple and ia64. We would have to add Aix. >>>> Instead, we propose to use a check for the supported platforms (see webrev). >>>> We could also add a macro SUPPORTS_FORTE that is defined in the corresponding >>>> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >>>> directories. >>> >>> Again if we just get rid of IA64 this will be a non-issue right? >>> >>> Thanks, >>> David >>> >>>> Are there other platforms that need to be supported? I derived the platforms >>>> from the comment in forte.cpp. >>>> >>>> Please review this change. I'm happy to incorporate your comments. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >>>> >>>> Best regards, >>>> Goetz. >>>> From alejandro.murillo at oracle.com Thu Jul 11 09:32:15 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 11 Jul 2013 16:32:15 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130711163228.6D8E5489B0@hg.openjdk.java.net> Changeset: 23eed087177a Author: katleman Date: 2013-07-10 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/23eed087177a Added tag jdk7u40-b33 for changeset 0b9149d22ee0 ! .hgtags Changeset: 1118c5d38ac0 Author: amurillo Date: 2013-07-11 06:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1118c5d38ac0 Merge Changeset: 1274c4750118 Author: amurillo Date: 2013-07-11 06:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1274c4750118 Added tag hs24-b53 for changeset 1118c5d38ac0 ! .hgtags From roland.westrelin at oracle.com Thu Jul 11 10:06:12 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 11 Jul 2013 17:06:12 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130711170638.E7D82489B2@hg.openjdk.java.net> Changeset: e50be1620201 Author: goetz Date: 2013-07-08 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e50be1620201 8020059: The flag introduced by 8014972 is not defined if Hotspot is built without a compiler (zero, ppc64 core build). Summary: define CodeCacheMinimumUseSpace flag for cppInterpeter build. Reviewed-by: kvn ! src/share/vm/runtime/globals.hpp Changeset: e554162ab094 Author: adlertz Date: 2013-07-09 17:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e554162ab094 8019625: Test compiler/8005956/PolynomialRoot.java timeouts on Solaris SPARCs Summary: Disable the test for SPARC and reduce the number of test iterations Reviewed-by: kvn ! test/compiler/8005956/PolynomialRoot.java Changeset: b42fe1a8e180 Author: drchase Date: 2013-07-09 08:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b42fe1a8e180 8017578: Hotspot compilation error with latest Studio compiler Summary: Make the destructor virtual (note more non-compiler hotspot errors occur downstream) Reviewed-by: kvn, twisti ! src/share/vm/adlc/forms.hpp Changeset: 7ac80525ece9 Author: anoll Date: 2013-07-09 11:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7ac80525ece9 8015635: Crash when specifying very large code cache size Summary: Limit the size of the code cache to at most 2G when arguments are checked; added regression test Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp + test/compiler/codecache/CheckUpperLimit.java Changeset: 5f533e38e7d5 Author: twisti Date: 2013-07-09 22:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5f533e38e7d5 Merge Changeset: dec841e0c9aa Author: anoll Date: 2013-07-10 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dec841e0c9aa 8016749: -XX:+UseISM fails an assert(obj->is_oop()) when running SPECjbb2005 Summary: Remove obsolete code that relates to ISM which was used only on Solaris 8. Reviewed-by: kvn, twisti ! src/os/solaris/vm/globals_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/share/vm/runtime/arguments.cpp Changeset: ec173c8f3739 Author: roland Date: 2013-07-11 01:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ec173c8f3739 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Thu Jul 11 10:23:30 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Jul 2013 10:23:30 -0700 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF5148@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> <51DDB362.1020007@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF4D9B@DEWDFEMB12A.global.corp.sap> <51DDD51D.4090505@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF5148@DEWDFEMB12A.global.corp.sap> Message-ID: <51DEEA12.9010906@oracle.com> I will push it and will do sync of whole jdk forest from jdk8. Thanks, Vladimir On 7/11/13 3:27 AM, Lindenmaier, Goetz wrote: > David, Vladimir, thanks for the reviews! > > Vladimir, will you push it, or should I do it? > I added the Reviewed-by line to the webrev. > http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 10. Juli 2013 23:42 > To: Lindenmaier, Goetz > Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > > On 7/10/13 2:00 PM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> I thought about that, too. But it seems quiet risky to me, >> as it depends on the final order of inclusion whether it works. >> Usually, macro.hpp will be included early, because it's basics that should >> be seen everywhere. Also, it will end up early in the preprocessed >> file as it has no other includes itself. >> >> If the system headers are included later, they will overrule the undef in >> macro.hpp. >> I think it's even some kind of pattern in the hotspot files to include the >> system headers after the hotspot headers. >> >> So even if it works now, it easily might break. > > Agree. Your changes are good then. > > thanks, > Vladimir > >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, July 10, 2013 9:18 PM >> To: Lindenmaier, Goetz >> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >> >> Goetz, >> >> macros.hpp is included in all other files. Can we just undef IA64 there?: >> >> // This is a REALLY BIG HACK, but on AIX >> unconditionally defines IA64. >> // At least on AIX 7.1 this is a real problem because 'systemcfg.h' is >> indirectly included >> // by 'pthread.h' and other common system headers. >> #ifdef AIX >> #undef IA64 >> #endif >> >> thanks, >> Vladimir >> >> On 7/9/13 6:12 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> Here a webrev without the cleanups: >>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 9. Juli 2013 14:08 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >>> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >>> >>> On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>>> A curious thing to do ;-) >>>> Yes, I agree. >>>> >>>>> Aside: presumably this is included in turn by other standard headers, >>>>> not directly included - otherwise we could just undef IA64 after the >>>>> include. >>>> Yes, that's the case. >>>> >>>>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>>>> think we may even have a RFE for this. AFAIK there are no remaining >>>>> users of the IA64 code in the hotspot codebase. >>>> Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win >>>> Ia64. 8 in development, all soon based on hs25. We also contributed to >>>> the change cleaning up the IA64 defines. There are only such left >>>> we need in our code. >>>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 >>> >>> I'm somewhat perplexed. The IA64 uses you still see in the hotspot >>> sources are ancient remnants of the IA64 support. Most of it has been >>> stripped out completely. So how anyone could be using any of this is, as >>> I said, perplexing ??? >>> >>>>> #if defined(__GNUC__) && !defined(IA64) >>>> You are right, I could just leave it as is, except if __GNUC__ is define on AIX, >>>> who knows ;). If we don't remove it, I need to add !PPC64 so that it's >>>> inlined in our port on linux. >>>>> more to avoid build-failures, but we may still want to avoid inlining >>>>> them for other reasons! So this aspect needs further investigation. Or >>>> I think it's a good idea to clean it up. The build problem >>>> is documented. There may be 'other reasons', but unexpected issues >>>> can be there with any change. >>> >>> But the aim is to avoid making gratuitous changes to code that is not >>> part of the ppc64/AIX port. If you start inlining these functions you >>> don't know what the impact will be. So why change them when it is not >>> necessary. >>> >>> David >>> ----- >>> >>>>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>>> Again if we just get rid of IA64 this will be a non-issue right? >>>> Here I would add !AIX. >>>> But have a look at the file, there are also several other platforms >>>> where this is excluded, and the exclusion is implemented differently >>>> on each platform. Not that nice ... >>>> >>>> Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing >>>> functional. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 9. Juli 2013 03:56 >>>> To: Lindenmaier, Goetz >>>> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >>>> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >>>> >>>> Hi Goetz, >>>> >>>> On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> This is in preparation of the PPC AIX port. >>>>> >>>>> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. >>>> >>>> A curious thing to do ;-) >>>> >>>> Aside: presumably this is included in turn by other standard headers, >>>> not directly included - otherwise we could just undef IA64 after the >>>> include. >>>> >>>>> This leads to wrong configurations of shared files on Aix where IA64 is used. >>>>> This change replaces uses of "IA64" by "IA64 && !AIX". >>>> >>>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>>> think we may even have a RFE for this. AFAIK there are no remaining >>>> users of the IA64 code in the hotspot codebase. >>>> >>>>> To reduce the complexity we propose to simplify two matters: >>>>> >>>>> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >>>>> define #define ATTR __attribute__((noinline)) claiming this is needed >>>>> to avoid a gcc build time error with - at that time - old gcc versions. >>>>> This define depends on IA64. We remove it altogether. >>>> >>>> Well it doesn't "depend" on IA64: >>>> >>>> #if defined(__GNUC__) && !defined(IA64) >>>> // Need to inhibit inlining for older versions of GCC to avoid >>>> build-time failures >>>> #define ATTR __attribute__((noinline)) >>>> #else >>>> #define ATTR >>>> #endif >>>> >>>> it becomes empty on IA64 (and non gcc systems). So removing it >>>> altogether is changing things for all the other gcc using platforms. Now >>>> it may be that we don't need to preclude inlining of these methods any >>>> more to avoid build-failures, but we may still want to avoid inlining >>>> them for other reasons! So this aspect needs further investigation. Or >>>> you can just leave it as-is - if you have IA64 always defined then you >>>> will get the empty #else part. Or if we go with the "eradicate IA64" >>>> path then you can change IA64 to AIX (though it is odd to exchange an >>>> architecture check with an OS check). >>>> >>>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>>> support on windows, apple and ia64. We would have to add Aix. >>>>> Instead, we propose to use a check for the supported platforms (see webrev). >>>>> We could also add a macro SUPPORTS_FORTE that is defined in the corresponding >>>>> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >>>>> directories. >>>> >>>> Again if we just get rid of IA64 this will be a non-issue right? >>>> >>>> Thanks, >>>> David >>>> >>>>> Are there other platforms that need to be supported? I derived the platforms >>>>> from the comment in forte.cpp. >>>>> >>>>> Please review this change. I'm happy to incorporate your comments. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> From john.coomes at oracle.com Thu Jul 11 11:08:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 18:08:34 +0000 Subject: hg: hsx/hotspot-main: 2 new changesets Message-ID: <20130711180834.886D6489C5@hg.openjdk.java.net> Changeset: 0d0c983a817b Author: tbell Date: 2013-07-09 08:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0d0c983a817b 8009315: F# on PATH breaks Cygwin tools (mkdir, echo, mktemp ...) Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 59dc9da81379 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/59dc9da81379 Added tag jdk8-b98 for changeset 0d0c983a817b ! .hgtags From john.coomes at oracle.com Thu Jul 11 11:08:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 18:08:38 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b98 for changeset 3370fb6146e4 Message-ID: <20130711180841.D42C9489C6@hg.openjdk.java.net> Changeset: 3f67804ab613 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/3f67804ab613 Added tag jdk8-b98 for changeset 3370fb6146e4 ! .hgtags From john.coomes at oracle.com Thu Jul 11 11:08:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 18:08:46 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b98 for changeset 15e5bb51bc0c Message-ID: <20130711180854.478E9489C7@hg.openjdk.java.net> Changeset: adf49c3ef83c Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/adf49c3ef83c Added tag jdk8-b98 for changeset 15e5bb51bc0c ! .hgtags From john.coomes at oracle.com Thu Jul 11 11:08:59 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 18:08:59 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b98 for changeset b1fb4612a2ca Message-ID: <20130711180905.14AD2489C8@hg.openjdk.java.net> Changeset: 8ef83d4b23c9 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/8ef83d4b23c9 Added tag jdk8-b98 for changeset b1fb4612a2ca ! .hgtags From john.coomes at oracle.com Thu Jul 11 11:12:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 18:12:51 +0000 Subject: hg: hsx/hotspot-main/jdk: 86 new changesets Message-ID: <20130711183045.230EF489C9@hg.openjdk.java.net> Changeset: 5cfcd545ce4a Author: vadim Date: 2013-06-26 13:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5cfcd545ce4a 8016254: several sun/java2d/OpenGL tests failed with SIGFPE Reviewed-by: prr, bae ! src/share/native/sun/java2d/opengl/OGLContext.c Changeset: 3ffa38871143 Author: lana Date: 2013-06-28 19:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3ffa38871143 Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java - src/share/classes/sun/misc/FDBigInt.java - src/share/classes/sun/misc/Hashing.java - src/solaris/classes/sun/awt/X11/XIconInfo.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png - test/java/lang/invoke/7196190/MHProxyTest.java - test/sun/misc/Hashing.java Changeset: 6dda4a069a83 Author: prr Date: 2013-07-01 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6dda4a069a83 8015144: Performance regression in ICU OpenType Layout library Reviewed-by: srl, jgodinez ! make/sun/font/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp Changeset: 6d2b5ec2ec79 Author: prr Date: 2013-07-02 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6d2b5ec2ec79 8019692: JDK build CC_OPT_HIGHEST setting isn't valid for Sun C++ compiler Reviewed-by: jgodinez ! make/sun/font/Makefile ! makefiles/CompileNativeLibraries.gmk Changeset: 1c607ebfc180 Author: leonidr Date: 2013-06-20 18:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1c607ebfc180 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-down check box. Reviewed-by: art, anthony, serb ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java Changeset: b7b95b7ab2cb Author: malenkov Date: 2013-06-21 17:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b7b95b7ab2cb 8016545: java.beans.XMLEncoder.writeObject output is wrong Reviewed-by: alexsch ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test8016545.java Changeset: eed321190272 Author: alitvinov Date: 2013-06-21 21:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eed321190272 8007642: Media Names on Java Print Do Not Match the Printer???s and Confuse Users Reviewed-by: prr, jgodinez ! src/windows/classes/sun/print/Win32PrintService.java Changeset: e5bac76282f7 Author: pchelko Date: 2013-06-27 13:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e5bac76282f7 8019236: [macosx] Add javadoc to the handleWindowFocusEvent in CEmbeddedFrame Reviewed-by: serb, ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: 72f167edf630 Author: dmarkov Date: 2013-06-28 18:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/72f167edf630 8016534: javax/swing/text/View/8014863/bug8014863.java failed Reviewed-by: alexp, alexsch ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: 228ec4b9111a Author: lana Date: 2013-06-28 18:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/228ec4b9111a Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java - src/share/classes/sun/misc/FDBigInt.java - src/share/classes/sun/misc/Hashing.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java - src/solaris/classes/sun/awt/X11/XIconInfo.java ! src/solaris/classes/sun/awt/X11/XListPeer.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png ! src/windows/classes/sun/print/Win32PrintService.java - test/java/lang/invoke/7196190/MHProxyTest.java - test/sun/misc/Hashing.java Changeset: 6fc558b41d8e Author: lana Date: 2013-07-02 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6fc558b41d8e Merge Changeset: 656ea2349aa5 Author: psandoz Date: 2013-06-20 10:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/656ea2349aa5 8016308: Updates to j.u.stream.Node/Nodes Reviewed-by: mduigou Contributed-by: Brian Goetz , Paul Sandoz ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/SliceOps.java ! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java Changeset: 85524d9839dc Author: psandoz Date: 2013-06-20 11:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/85524d9839dc 8016324: filter/flatMap pipeline sinks should pass size information to downstream sink Reviewed-by: chegar, mduigou Contributed-by: Brian Goetz ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java Changeset: f758d7c24396 Author: psandoz Date: 2013-06-20 11:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f758d7c24396 8016455: Sync stream tests from lambda to tl Reviewed-by: mduigou Contributed-by: Brian Goetz , Paul Sandoz ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java ! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/bootlib/java/util/stream/LoggingTestCase.java ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java ! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java ! test/java/util/stream/boottest/java/util/stream/NodeTest.java ! test/java/util/stream/boottest/java/util/stream/UnorderedTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceByOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java Changeset: 562f5cf13a9c Author: psandoz Date: 2013-06-20 11:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/562f5cf13a9c 8016139: PrimitiveIterator.forEachRemaining Reviewed-by: alanb ! src/share/classes/java/util/PrimitiveIterator.java Changeset: a44bd993ce93 Author: xuelei Date: 2013-06-20 07:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a44bd993ce93 8017157: catch more exception in test RejectClientRenego Reviewed-by: vinnie ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java Changeset: 49b78ec058fb Author: mduigou Date: 2013-06-20 07:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/49b78ec058fb 8017088: Map/HashMap.compute() incorrect with key mapping to null value Reviewed-by: dl, dholmes, plevart ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! test/java/util/Map/Defaults.java Changeset: 9fa37bd38d4b Author: mduigou Date: 2013-06-20 08:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9fa37bd38d4b Merge Changeset: bf2bacf934d1 Author: chegar Date: 2013-06-20 18:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf2bacf934d1 8014499: MulticastSocket should enable IP_MULTICAST_ALL (lnx) Reviewed-by: alanb, chegar Contributed-by: John Zavgren , Chris Hegarty ! src/solaris/native/java/net/PlainDatagramSocketImpl.c + test/java/net/MulticastSocket/Promiscuous.java Changeset: cd06fc069152 Author: alanb Date: 2013-06-20 19:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd06fc069152 8014377: (dc) DatagramChannel should set IP_MULTICAST_ALL=0 (lnx) Reviewed-by: chegar, jzavgren ! src/solaris/native/sun/nio/ch/Net.c + test/java/nio/channels/DatagramChannel/Promiscuous.java Changeset: 4503e04141f7 Author: weijun Date: 2013-06-21 18:26 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4503e04141f7 8001326: Improve Kerberos caching Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbApRep.java ! src/share/classes/sun/security/krb5/KrbApReq.java + src/share/classes/sun/security/krb5/internal/ReplayCache.java + src/share/classes/sun/security/krb5/internal/rcache/AuthList.java ! src/share/classes/sun/security/krb5/internal/rcache/AuthTime.java + src/share/classes/sun/security/krb5/internal/rcache/AuthTimeWithHash.java - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java + src/share/classes/sun/security/krb5/internal/rcache/DflCache.java + src/share/classes/sun/security/krb5/internal/rcache/MemoryCache.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java + test/java/security/testlibrary/Proc.java ! test/sun/security/krb5/auto/AcceptorSubKey.java + test/sun/security/krb5/auto/BasicProc.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/NoneReplayCacheTest.java - test/sun/security/krb5/auto/ReplayCache.java + test/sun/security/krb5/auto/ReplayCacheExpunge.java + test/sun/security/krb5/auto/ReplayCachePrecise.java + test/sun/security/krb5/auto/ReplayCacheTest.java + test/sun/security/krb5/auto/ReplayCacheTestProc.java ! test/sun/security/krb5/ccache/EmptyCC.java Changeset: a88f6f4d279f Author: bpb Date: 2013-06-21 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a88f6f4d279f 7192954: Fix Float.parseFloat to round correctly and preserve monotonicity. 4396272: Parsing doubles fails to follow IEEE for largest decimal that should yield 0 7039391: Use Math.ulp in FloatingDecimal Summary: Correct rounding and monotonicity problems in floats and doubles Reviewed-by: bpb, martin Contributed-by: Dmitry Nadezhin , Louis Wasserman ! src/share/classes/sun/misc/FDBigInteger.java ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/lang/Double/ParseDouble.java ! test/java/lang/Float/ParseFloat.java ! test/sun/misc/FloatingDecimal/TestFDBigInteger.java Changeset: 814759462705 Author: bpb Date: 2013-06-21 11:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/814759462705 7131192: BigInteger.doubleValue() is depressingly slow Summary: In doubleValue() and floatValue() replace converting to String and parsing to Double or Float with direct conversion into IEEE 754 bits. Reviewed-by: bpb, drchase, martin Contributed-by: Louis Wasserman ! src/share/classes/java/math/BigInteger.java + test/java/math/BigInteger/PrimitiveConversionTests.java Changeset: 8b84d557570c Author: naoto Date: 2013-06-21 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b84d557570c 6863624: java/util/Currency/PropertiesTest.sh writable check is incorrect Reviewed-by: alanb ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: cb3f3a05eee3 Author: chegar Date: 2013-06-22 08:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cb3f3a05eee3 8017271: Crash may occur in java.net.DualStackPlainSocketImpl::initIDs due to unchecked values returned from JNI functions Reviewed-by: alanb, khazra ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/DualStackPlainSocketImpl.c Changeset: fd050ba1cf72 Author: arieber Date: 2013-06-22 08:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fd050ba1cf72 7157360: HttpURLConnection: HTTP method DELETE doesn't support output Reviewed-by: chegar ! src/share/classes/sun/net/www/http/PosterOutputStream.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/http/HttpURLConnection/PostOnDelete.java Changeset: 1bf060029a5d Author: weijun Date: 2013-06-24 16:25 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1bf060029a5d 8017453: ReplayCache tests fail on multiple platforms Reviewed-by: xuelei ! test/sun/security/krb5/auto/ReplayCacheExpunge.java ! test/sun/security/krb5/auto/ReplayCacheTestProc.java Changeset: 5f80b8cee601 Author: alanb Date: 2013-06-24 11:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5f80b8cee601 8017477: Remove TimeZone.DisplayNames, no longer used Reviewed-by: okutsu ! src/share/classes/java/util/TimeZone.java Changeset: bb2e67628dc0 Author: naoto Date: 2013-06-24 16:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb2e67628dc0 8017468: typo in javadoc: " ResourceBunlde " Reviewed-by: okutsu ! src/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: eabcb85fcabc Author: bpb Date: 2013-06-24 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eabcb85fcabc 6469160: (fmt) general (%g) formatting of zero (0.0) with precision 0 or 1 throws ArrayOutOfBoundsException Summary: For zero value ensure than an unpadded zero character is passed to Formatter.addZeros() Reviewed-by: iris, darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java Changeset: 82e7682c17e2 Author: darcy Date: 2013-06-24 23:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/82e7682c17e2 8017550: Fix doclint issues in java.lang and subpackages Reviewed-by: alanb, chegar ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/annotation/Repeatable.java ! src/share/classes/java/lang/annotation/Retention.java ! src/share/classes/java/lang/annotation/Target.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/java/lang/reflect/TypeVariable.java Changeset: 4a4d910e1504 Author: alanb Date: 2013-06-25 13:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4a4d910e1504 8017570: jfr.jar should not be in compact3 (for now) Reviewed-by: erikj ! makefiles/profile-includes.txt Changeset: 01fcca3d2b8c Author: bpb Date: 2013-06-20 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01fcca3d2b8c 4641897: Faster string conversion of large integers Summary: Accelerate conversion to string by means of Schoenhage recursive base conversion. Reviewed-by: bpb, alanb Contributed-by: Alan Eliasen ! src/share/classes/java/math/BigInteger.java ! test/java/math/BigInteger/BigIntegerTest.java Changeset: 89631a384ee6 Author: weijun Date: 2013-06-25 21:51 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89631a384ee6 8016051: Possible ClassCastException in KdcComm Reviewed-by: weijun Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/krb5/KdcComm.java Changeset: ac61efd8c593 Author: shade Date: 2013-06-25 20:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac61efd8c593 8014233: java.lang.Thread should have @Contended on TLR fields Summary: add the @Contended over three TLR fields. Reviewed-by: psandoz, chegar, dholmes, dl ! src/share/classes/java/lang/Thread.java Changeset: 757290440a2f Author: juh Date: 2013-06-25 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/757290440a2f 8017325: Cleanup of the javadoc tag in java.security.cert Summary: Convert javadoc ... and ... tags to {@code ...} Reviewed-by: darcy ! src/share/classes/java/security/cert/CRLException.java ! src/share/classes/java/security/cert/CRLSelector.java ! src/share/classes/java/security/cert/CertPath.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathBuilderException.java ! src/share/classes/java/security/cert/CertPathBuilderResult.java ! src/share/classes/java/security/cert/CertPathBuilderSpi.java ! src/share/classes/java/security/cert/CertPathParameters.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertPathValidatorException.java ! src/share/classes/java/security/cert/CertPathValidatorResult.java ! src/share/classes/java/security/cert/CertPathValidatorSpi.java ! src/share/classes/java/security/cert/CertSelector.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/java/security/cert/CertStoreException.java ! src/share/classes/java/security/cert/CertStoreParameters.java ! src/share/classes/java/security/cert/CertStoreSpi.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CertificateEncodingException.java ! src/share/classes/java/security/cert/CertificateException.java ! src/share/classes/java/security/cert/CertificateExpiredException.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/CertificateFactorySpi.java ! src/share/classes/java/security/cert/CertificateNotYetValidException.java ! src/share/classes/java/security/cert/CertificateParsingException.java ! src/share/classes/java/security/cert/CertificateRevokedException.java ! src/share/classes/java/security/cert/CollectionCertStoreParameters.java ! src/share/classes/java/security/cert/Extension.java ! src/share/classes/java/security/cert/LDAPCertStoreParameters.java ! src/share/classes/java/security/cert/PKIXBuilderParameters.java ! src/share/classes/java/security/cert/PKIXCertPathBuilderResult.java ! src/share/classes/java/security/cert/PKIXCertPathChecker.java ! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/security/cert/PKIXReason.java ! src/share/classes/java/security/cert/PolicyNode.java ! src/share/classes/java/security/cert/PolicyQualifierInfo.java ! src/share/classes/java/security/cert/TrustAnchor.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509CRLEntry.java ! src/share/classes/java/security/cert/X509CRLSelector.java ! src/share/classes/java/security/cert/X509CertSelector.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/java/security/cert/X509Extension.java Changeset: 3700bb58c9a2 Author: juh Date: 2013-06-25 14:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3700bb58c9a2 8017326: Cleanup of the javadoc tag in java.security.spec Summary: Convert javadoc and tags to {@code ...} Reviewed-by: darcy ! src/share/classes/java/security/spec/DSAGenParameterSpec.java ! src/share/classes/java/security/spec/DSAParameterSpec.java ! src/share/classes/java/security/spec/DSAPrivateKeySpec.java ! src/share/classes/java/security/spec/DSAPublicKeySpec.java ! src/share/classes/java/security/spec/ECFieldF2m.java ! src/share/classes/java/security/spec/ECFieldFp.java ! src/share/classes/java/security/spec/ECGenParameterSpec.java ! src/share/classes/java/security/spec/ECParameterSpec.java ! src/share/classes/java/security/spec/ECPoint.java ! src/share/classes/java/security/spec/ECPrivateKeySpec.java ! src/share/classes/java/security/spec/ECPublicKeySpec.java ! src/share/classes/java/security/spec/EllipticCurve.java ! src/share/classes/java/security/spec/EncodedKeySpec.java ! src/share/classes/java/security/spec/InvalidKeySpecException.java ! src/share/classes/java/security/spec/KeySpec.java ! src/share/classes/java/security/spec/MGF1ParameterSpec.java ! src/share/classes/java/security/spec/PKCS8EncodedKeySpec.java ! src/share/classes/java/security/spec/PSSParameterSpec.java ! src/share/classes/java/security/spec/RSAKeyGenParameterSpec.java ! src/share/classes/java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java ! src/share/classes/java/security/spec/RSAOtherPrimeInfo.java ! src/share/classes/java/security/spec/RSAPrivateCrtKeySpec.java ! src/share/classes/java/security/spec/X509EncodedKeySpec.java Changeset: 510035b7bbbb Author: yhuang Date: 2013-06-25 21:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/510035b7bbbb 8013836: getFirstDayOfWeek reports wrong day for pt-BR locale Reviewed-by: naoto + src/share/classes/sun/util/resources/pt/CalendarData_pt_BR.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0822bcddbd4f Author: xuelei Date: 2013-06-26 06:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0822bcddbd4f 8017049: rename property jdk.tls.rejectClientInitializedRenego Reviewed-by: vinnie, wetmore, mullan ! src/share/classes/sun/security/ssl/Handshaker.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java Changeset: e83cdd58f1cf Author: chegar Date: 2013-06-26 15:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e83cdd58f1cf 8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum) Reviewed-by: chegar, alanb, psandoz Contributed-by: Doug Lea
, Tristan Yan , Chris Hegarty + src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Arrays.java + test/java/util/Arrays/ParallelPrefix.java Changeset: 71059bca036a Author: rfield Date: 2013-06-26 07:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/71059bca036a 8016761: Lambda metafactory - incorrect type conversion of constructor method handle Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/LambdaConstructorMethodHandleUnbox.java Changeset: 336e5a862013 Author: naoto Date: 2013-06-26 11:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/336e5a862013 8017322: java/util/Currency/PropertiesTest.sh should run exclusively Reviewed-by: alanb ! test/TEST.ROOT Changeset: 1fda8fa7ae97 Author: darcy Date: 2013-06-26 13:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1fda8fa7ae97 7018139: Fix HTML accessibility and doclint issues in java.math Reviewed-by: lancea, bpb ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java Changeset: a5aa57eb85b6 Author: darcy Date: 2013-06-26 19:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a5aa57eb85b6 8019223: Fix doclint warnings in java.rmi.server Reviewed-by: smarks ! src/share/classes/java/rmi/server/RMIClassLoader.java Changeset: ac65905883a7 Author: darcy Date: 2013-06-26 22:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac65905883a7 8019228: Fix doclint issues in java.util.zip Reviewed-by: sherman, mchung ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java Changeset: 370e7beff8a0 Author: wetmore Date: 2013-06-27 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/370e7beff8a0 8019227: JDK-8010325 broke the old build Reviewed-by: alanb, chegar ! make/java/java/FILES_java.gmk Changeset: 4e69a7dfbeac Author: chegar Date: 2013-06-27 10:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4e69a7dfbeac Merge Changeset: 1c31082f0a51 Author: darcy Date: 2013-06-27 11:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1c31082f0a51 8019304: Fix doclint issues in java.util.prefs Reviewed-by: lancea ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/prefs/PreferencesFactory.java Changeset: b9ba04dc210f Author: lancea Date: 2013-06-27 15:07 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b9ba04dc210f 8017471: Fix JDBC -Xdoclint public errors Reviewed-by: darcy ! src/share/classes/java/sql/Blob.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Clob.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/Driver.java ! src/share/classes/java/sql/DriverAction.java ! src/share/classes/java/sql/NClob.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLInput.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Wrapper.java ! src/share/classes/javax/sql/CommonDataSource.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/XADataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/FilteredRowSet.java ! src/share/classes/javax/sql/rowset/JdbcRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/RowSetWarning.java ! src/share/classes/javax/sql/rowset/WebRowSet.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java Changeset: b8f16cb2d95b Author: darcy Date: 2013-06-27 12:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b8f16cb2d95b 8019315: Fix doclint issues in java.util.logging Reviewed-by: lancea ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java Changeset: 6729f7ef94cd Author: smarks Date: 2013-06-27 13:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6729f7ef94cd 8019224: add exception chaining to RMI CGIHandler Reviewed-by: darcy ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Changeset: 1099fe14fb65 Author: darcy Date: 2013-06-27 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1099fe14fb65 8019320: Fix doclint issues in javax.script Reviewed-by: lancea ! src/share/classes/javax/script/Invocable.java ! src/share/classes/javax/script/ScriptContext.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/script/SimpleScriptContext.java Changeset: e34e3ddb3cd8 Author: naoto Date: 2013-06-27 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e34e3ddb3cd8 6609431: (rb) ResourceBundle.getString() returns incorrect value Reviewed-by: okutsu, sherman ! src/share/classes/java/util/Properties.java + test/java/util/Properties/Bug6609431.java + test/java/util/Properties/Bug6609431.properties Changeset: 29bbbb136bc5 Author: darcy Date: 2013-06-27 19:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/29bbbb136bc5 8019357: Fix doclint warnings in java.lang.invoke Reviewed-by: jrose ! src/share/classes/java/lang/invoke/LambdaConversionException.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/lang/invoke/package-info.java Changeset: 60d1994f63f7 Author: xuelei Date: 2013-06-27 19:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60d1994f63f7 8019359: To comment why not use no_renegotiation to reject client initiated renegotiation Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: c1df54fd19b2 Author: henryjen Date: 2013-06-11 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1df54fd19b2 8009736: Comparator API cleanup Reviewed-by: psandoz, briangoetz, mduigou, plevart ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/SortedOps.java ! test/java/nio/file/Files/StreamTest.java ! test/java/util/Collection/ListDefaults.java + test/java/util/Comparator/BasicTest.java + test/java/util/Comparator/TypeTest.java - test/java/util/Comparators/BasicTest.java + test/java/util/Map/EntryComparators.java + test/java/util/function/BinaryOperator/BasicTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java ! test/sun/misc/JavaLangAccess/NewUnsafeString.java Changeset: 28b71c97a72d Author: psandoz Date: 2013-06-28 10:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/28b71c97a72d 8012987: Optimizations for Stream.limit/substream Reviewed-by: mduigou Contributed-by: Brian Goetz , Paul Sandoz ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/AbstractTask.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/ForEachOps.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/SliceOps.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java + test/java/util/stream/boottest/java/util/stream/SliceSpliteratorTest.java ! test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java Changeset: 19a6d2d701d9 Author: sla Date: 2013-06-26 19:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/19a6d2d701d9 8019155: Update makefiles with correct jfr packages Reviewed-by: mgronlun, erikj ! make/common/Release.gmk ! makefiles/CreateJars.gmk Changeset: 04378a645944 Author: alanb Date: 2013-06-28 16:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04378a645944 8019380: doclint warnings in java.nio, java.nio.file.**, java.nio.channels.** Reviewed-by: chegar ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousByteChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/Pipe.java ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/SelectionKey.java ! src/share/classes/java/nio/channels/Selector.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/CoderResult.java ! src/share/classes/java/nio/charset/spi/CharsetProvider.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/AttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileAttribute.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/sql/SQLInput.java Changeset: 1919c226b427 Author: dl Date: 2013-06-28 12:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1919c226b427 8017739: ReentrantReadWriteLock is confused by the Threads with reused IDs Reviewed-by: chegar ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java Changeset: 0e24065a75db Author: dl Date: 2013-06-28 12:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0e24065a75db 8019377: Sync j.u.c locks and atomic from 166 to tl Reviewed-by: chegar ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/share/classes/java/util/concurrent/atomic/DoubleAdder.java ! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java ! src/share/classes/java/util/concurrent/atomic/package-info.java ! src/share/classes/java/util/concurrent/locks/AbstractOwnableSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! src/share/classes/java/util/concurrent/locks/Lock.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReadWriteLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/StampedLock.java Changeset: ff0242ed08db Author: jzavgren Date: 2013-06-28 16:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff0242ed08db 8015799: HttpURLConnection.getHeaderFields() throws IllegalArgumentException Reviewed-by: chegar, dsamersoff, khazra ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/CookieHandler/EmptyCookieHeader.java Changeset: 52b4527d3fc7 Author: chegar Date: 2013-06-28 16:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/52b4527d3fc7 Merge Changeset: 389f59e6288f Author: juh Date: 2013-06-28 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/389f59e6288f 8019360: Cleanup of the javadoc tag in java.security.* Summary: Convert to {@code ...} tags. convert package.html to package-info.java. Reviewed-by: darcy ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessControlException.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/AlgorithmParameterGeneratorSpi.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/AlgorithmParametersSpi.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/AuthProvider.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/Certificate.java ! src/share/classes/java/security/CodeSigner.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/DigestException.java ! src/share/classes/java/security/DigestInputStream.java ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/java/security/DomainCombiner.java ! src/share/classes/java/security/GeneralSecurityException.java ! src/share/classes/java/security/Guard.java ! src/share/classes/java/security/GuardedObject.java ! src/share/classes/java/security/Identity.java ! src/share/classes/java/security/IdentityScope.java ! src/share/classes/java/security/InvalidAlgorithmParameterException.java ! src/share/classes/java/security/InvalidKeyException.java ! src/share/classes/java/security/Key.java ! src/share/classes/java/security/KeyException.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyFactorySpi.java ! src/share/classes/java/security/KeyManagementException.java ! src/share/classes/java/security/KeyPair.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyPairGeneratorSpi.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/KeyStoreException.java ! src/share/classes/java/security/KeyStoreSpi.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/MessageDigestSpi.java ! src/share/classes/java/security/NoSuchAlgorithmException.java ! src/share/classes/java/security/Permission.java ! src/share/classes/java/security/PermissionCollection.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/PolicySpi.java ! src/share/classes/java/security/PrivilegedAction.java ! src/share/classes/java/security/PrivilegedActionException.java ! src/share/classes/java/security/PrivilegedExceptionAction.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/ProviderException.java ! src/share/classes/java/security/PublicKey.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/SecureRandomSpi.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/SecurityPermission.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/SignatureException.java ! src/share/classes/java/security/SignatureSpi.java ! src/share/classes/java/security/SignedObject.java ! src/share/classes/java/security/Signer.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/acl/Acl.java ! src/share/classes/java/security/acl/AclEntry.java ! src/share/classes/java/security/acl/Group.java ! src/share/classes/java/security/acl/Owner.java + src/share/classes/java/security/acl/package-info.java - src/share/classes/java/security/acl/package.html + src/share/classes/java/security/cert/package-info.java - src/share/classes/java/security/cert/package.html ! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java ! src/share/classes/java/security/interfaces/DSAParams.java ! src/share/classes/java/security/interfaces/DSAPrivateKey.java ! src/share/classes/java/security/interfaces/DSAPublicKey.java + src/share/classes/java/security/interfaces/package-info.java - src/share/classes/java/security/interfaces/package.html + src/share/classes/java/security/package-info.java - src/share/classes/java/security/package.html + src/share/classes/java/security/spec/package-info.java - src/share/classes/java/security/spec/package.html Changeset: 9d175c6cb527 Author: darcy Date: 2013-06-28 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d175c6cb527 8019407: Fix doclint issues in javax.naming.* Reviewed-by: lancea ! src/share/classes/javax/naming/CompositeName.java ! src/share/classes/javax/naming/CompoundName.java ! src/share/classes/javax/naming/Context.java ! src/share/classes/javax/naming/InitialContext.java ! src/share/classes/javax/naming/RefAddr.java ! src/share/classes/javax/naming/ReferralException.java ! src/share/classes/javax/naming/directory/DirContext.java ! src/share/classes/javax/naming/event/EventContext.java ! src/share/classes/javax/naming/ldap/ControlFactory.java ! src/share/classes/javax/naming/ldap/InitialLdapContext.java ! src/share/classes/javax/naming/ldap/LdapContext.java Changeset: 389b8739a74e Author: alanb Date: 2013-06-28 19:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/389b8739a74e 8019384: jps and jcmd tests fail when there is a process started with a .war file Reviewed-by: dcubed, sla, mchung ! test/sun/tools/jcmd/jcmd_Output1.awk ! test/sun/tools/jps/jps-l_Output1.awk ! test/sun/tools/jps/jps_Output1.awk Changeset: b4d36f3717b8 Author: lana Date: 2013-06-28 19:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b4d36f3717b8 Merge Changeset: a4eb59bffb60 Author: lancea Date: 2013-06-29 06:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a4eb59bffb60 8019286: Fix javadoc typo in ResultSet.next Reviewed-by: darcy, mchung ! src/share/classes/java/sql/ResultSet.java Changeset: bf650fee4983 Author: darcy Date: 2013-06-30 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf650fee4983 8019466: Fix doclint issues in java.util.function Reviewed-by: briangoetz ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/UnaryOperator.java Changeset: 9eaeb1a0aa46 Author: darcy Date: 2013-06-30 17:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9eaeb1a0aa46 8019467: Fix doclint issues in java.util.jar.Pack200 Reviewed-by: lancea, ksrini ! src/share/classes/java/util/jar/Pack200.java Changeset: 3aa541b50a64 Author: dfuchs Date: 2013-07-01 11:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3aa541b50a64 8014045: test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Summary: this test was failing because it didn't take into account the fact that Loggers could be garbage collected. Reviewed-by: mchung ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java Changeset: dfb37cc30a67 Author: vinnie Date: 2013-07-01 14:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dfb37cc30a67 8019259: Failover to CRL checking does not happen if wrong OCSP responder URL is set Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java Changeset: c8cf01de8fa8 Author: bpb Date: 2013-07-01 11:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c8cf01de8fa8 8017540: Improve multi-threaded contention behavior of radix conversion cache Summary: Replace array of ArrayList of BigIntegers with a volatile two-dimensional BigInteger array eliminate the synchronization of getRadixConversionCache() Reviewed-by: plevart, shade, bpb, alanb Contributed-by: Peter Levart , Dmitry Nadezhin , Aleksey Shipilev ! src/share/classes/java/math/BigInteger.java Changeset: 3736ad2636aa Author: darcy Date: 2013-07-01 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3736ad2636aa 8019527: Fix doclint issues in java.lang.instrument Reviewed-by: lancea, alanb ! src/share/classes/java/lang/instrument/Instrumentation.java Changeset: 8e5376324e4b Author: darcy Date: 2013-07-01 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8e5376324e4b 8019529: Fix doclint issues in java.util.spi Reviewed-by: lancea ! src/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: 5427f7316633 Author: darcy Date: 2013-07-01 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5427f7316633 8019535: Fix doclint issues in java.time.format Reviewed-by: lancea, rriggs ! src/share/classes/java/time/format/DateTimeFormatter.java Changeset: 17f44b2dde41 Author: juh Date: 2013-07-01 17:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/17f44b2dde41 8019539: Fix doclint errors in java.security and its subpackages Reviewed-by: darcy ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509CRLEntry.java ! src/share/classes/java/security/cert/X509Certificate.java Changeset: 020f023f87d1 Author: dfuchs Date: 2013-07-02 11:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/020f023f87d1 8017174: NPE when using Logger.getAnonymousLogger or LogManager.getLogManager().getLogger Summary: This patch makes sure that LoggerContext instances created for applets have a root and global logger. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java ! test/java/util/logging/LogManagerInstanceTest.java + test/java/util/logging/TestAppletLoggerContext.java Changeset: b1fffbbdf58c Author: ksrini Date: 2013-07-02 05:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b1fffbbdf58c 8017463: [TEST_BUG] 2 tests from tools/pack200/ remain about 1 GB of data in work directory after execution Reviewed-by: mchung ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/BandIntegrity.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Pack200Props.java ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/RepackTest.java ! test/tools/pack200/T7007157.java ! test/tools/pack200/TestExceptions.java ! test/tools/pack200/TimeStamp.java ! test/tools/pack200/UnpackerMemoryTest.java ! test/tools/pack200/Utils.java ! test/tools/pack200/typeannos/TestTypeAnnotations.java Changeset: 70bff2d12af0 Author: dfuchs Date: 2013-07-02 19:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/70bff2d12af0 7184195: java.util.logging.Logger.getGlobal().info() doesn't log without configuration Summary: Due to subtle synchronization issues between LogManager & Logger class initialization the global logger doesn't have its 'manager' field initialized until the LogManager is initialized. This fix will ensure that the global logger has its 'manager' field set when getGlobal() is called. Reviewed-by: mchung, plevart ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/getGlobal/TestGetGlobal.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java + test/java/util/logging/Logger/getGlobal/logging.properties + test/java/util/logging/Logger/getGlobal/policy + test/java/util/logging/Logger/getGlobal/testgetglobal/BadLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/DummyLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/HandlerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl1.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl2.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl3.java Changeset: 11c074904fce Author: lana Date: 2013-07-02 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11c074904fce Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: 974b94f944ce Author: lana Date: 2013-07-03 19:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/974b94f944ce Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: f2342dedf04a Author: lana Date: 2013-07-05 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f2342dedf04a Merge Changeset: 2c26ccf0a85b Author: tbell Date: 2013-07-08 07:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2c26ccf0a85b 8012925: [parfait] Missing return value in jdk/src/macosx/native/sun/awt/AWTEvent.m Reviewed-by: katleman, leonidr Contributed-by: petr.pchelko at oracle.com ! src/macosx/native/sun/awt/AWTEvent.m Changeset: c4908732fef5 Author: katleman Date: 2013-07-08 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c4908732fef5 Merge Changeset: 758c21301545 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/758c21301545 Added tag jdk8-b98 for changeset c4908732fef5 ! .hgtags From john.coomes at oracle.com Thu Jul 11 11:37:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 18:37:00 +0000 Subject: hg: hsx/hotspot-main/nashorn: 33 new changesets Message-ID: <20130711183728.052F4489CC@hg.openjdk.java.net> Changeset: 6a75a505301f Author: sundar Date: 2013-06-18 18:43 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6a75a505301f 8012698: [nashorn] tests fail to run with agentvm or samevm Reviewed-by: hannesw, jlaskey ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java Changeset: 7276d66b7118 Author: jlaskey Date: 2013-06-19 09:10 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7276d66b7118 8010697: DeletedArrayFilter seems to leak memory Reviewed-by: hannesw, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java + test/script/basic/JDK-8010697.js + test/script/basic/JDK-8010697.js.EXPECTED Changeset: c7c9222cfe69 Author: sundar Date: 2013-06-19 21:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c7c9222cfe69 8015347: Parsing issue with decodeURIComponent Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/URIUtils.java + test/script/basic/JDK-8015347.js Changeset: ac404bf3f8c8 Author: sundar Date: 2013-06-20 13:45 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ac404bf3f8c8 8017046: Cannot assign undefined to a function argument if the function uses arguments object Reviewed-by: hannesw ! src/jdk/nashorn/internal/objects/NativeArguments.java + test/script/basic/JDK-8017046.js Changeset: c7672e621b14 Author: sundar Date: 2013-06-20 17:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c7672e621b14 Merge Changeset: 8e03121cc286 Author: sundar Date: 2013-06-21 16:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8e03121cc286 8017260: adjust lookup code in objects.* classes Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java Changeset: b4e2bccf9598 Author: sundar Date: 2013-06-21 17:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b4e2bccf9598 Merge Changeset: c30beaf3c42a Author: jlaskey Date: 2013-06-21 14:34 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c30beaf3c42a 8010732: BigDecimal, BigInteger and Long handling in nashorn Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/JDK-8010732.js + test/script/basic/JDK-8010732.js.EXPECTED Changeset: 2ded2fc08c94 Author: jlaskey Date: 2013-06-22 10:12 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2ded2fc08c94 8017448: JDK-8010732.js.EXPECTED truncated Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! test/script/basic/JDK-8010732.js.EXPECTED Changeset: 51a5ee93d6bc Author: sundar Date: 2013-06-24 19:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/51a5ee93d6bc 8015959: Can't call foreign constructor Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/script/basic/JDK-8015959.js + test/script/basic/JDK-8015959.js.EXPECTED Changeset: 26a345c26e62 Author: sundar Date: 2013-06-25 17:31 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/26a345c26e62 8015969: Needs to enforce and document that global "context" and "engine" can't be modified when running via jsr223 Reviewed-by: hannesw, jlaskey ! docs/JavaScriptingProgrammersGuide.html ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java + test/script/basic/JDK-8015969.js Changeset: 39e17373d8df Author: sundar Date: 2013-06-26 16:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/39e17373d8df 8017950: error.stack should be a string rather than an array Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! test/script/basic/JDK-8012164.js ! test/script/basic/JDK-8012164.js.EXPECTED + test/script/basic/JDK-8017950.js + test/script/basic/JDK-8017950.js.EXPECTED ! test/script/basic/NASHORN-109.js ! test/script/basic/NASHORN-296.js ! test/script/basic/errorstack.js Changeset: 682889823712 Author: jlaskey Date: 2013-06-26 08:36 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/682889823712 8008458: Strict functions dont share property map Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java Changeset: 80c66d3fd872 Author: hannesw Date: 2013-06-26 15:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/80c66d3fd872 8019157: Avoid calling ScriptObject.setProto() if possible Reviewed-by: jlaskey, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/scripts/JO.java Changeset: 635098f9f45e Author: sundar Date: 2013-06-26 19:42 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/635098f9f45e 8014781: support Error.captureStackTrace Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/objects/NativeError.java + test/script/basic/JDK-8014781.js + test/script/basic/JDK-8014781.js.EXPECTED Changeset: d1886ad46f0c Author: jlaskey Date: 2013-06-26 12:38 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d1886ad46f0c 8019175: Simplify ScriptObject.modifyOwnProperty Reviewed-by: hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java Changeset: f9c855b828fe Author: sundar Date: 2013-06-27 13:24 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f9c855b828fe 8019226: line number not generated for first statement if it is on the same function declaration line Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8019226.js + test/script/basic/JDK-8019226.js.EXPECTED Changeset: 5ec4762d9df0 Author: sundar Date: 2013-06-27 13:47 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5ec4762d9df0 Merge Changeset: 90864d892593 Author: lana Date: 2013-06-28 19:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/90864d892593 Merge Changeset: 218c2833c344 Author: sundar Date: 2013-06-28 19:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/218c2833c344 8019365: Error stack format Reviewed-by: hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/objects/NativeError.java ! test/script/basic/JDK-8014781.js.EXPECTED ! test/script/basic/JDK-8017950.js.EXPECTED ! test/script/basic/JDK-8019226.js ! test/script/basic/JDK-8019226.js.EXPECTED Changeset: 02588d68399d Author: sundar Date: 2013-07-01 12:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/02588d68399d 8019473: Parser issues related to functions and blocks Reviewed-by: lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8019473.js Changeset: 10c7a1e9e24f Author: sundar Date: 2013-07-01 14:15 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/10c7a1e9e24f 8019478: Object.prototype.toString.call(/a/.exec("a")) === "[object Array]" should be true Reviewed-by: hannesw ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java + test/script/basic/JDK-8019478.js Changeset: 47099609a48b Author: sundar Date: 2013-07-01 17:21 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/47099609a48b 8019482: Number("0x0.0p0") should evaluate to NaN Reviewed-by: lagergren ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/JSType.java + test/script/basic/JDK-8019482.js Changeset: ab3ea5b3e507 Author: sundar Date: 2013-07-01 19:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ab3ea5b3e507 8019488: switch on literals result in NoSuchMethodError or VerifyError Reviewed-by: hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019488.js Changeset: 9165138b427c Author: sundar Date: 2013-07-01 23:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9165138b427c 8019508: Comma handling in object literal parsing is wrong Reviewed-by: hannesw ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019508.js + test/script/basic/JDK-8019508.js.EXPECTED Changeset: 5f9abeb0bb50 Author: jlaskey Date: 2013-07-02 07:45 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5f9abeb0bb50 8019580: Build Script Change for Nashorn promotion testing Reviewed-by: jlaskey Contributed-by: eugene.drobitko at oracle.com ! make/build.xml Changeset: a7b82e333c31 Author: lagergren Date: 2013-07-02 13:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a7b82e333c31 8016667: Wrong bytecode when testing/setting due to null check shortcut checking against primitive too Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8016667.js Changeset: 74049fe3ba46 Author: sundar Date: 2013-07-02 18:00 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/74049fe3ba46 8019553: NPE on illegal l-value for increment and decrement Reviewed-by: jlaskey, attila, lagergren ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019553.js + test/script/basic/JDK-8019553.js.EXPECTED ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-51.js.EXPECTED ! test/script/error/NASHORN-57.js.EXPECTED Changeset: 9396e42bae4f Author: lagergren Date: 2013-07-02 14:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9396e42bae4f 8017082: Long array literals were slightly broken Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + test/script/basic/JDK-8017082.js Changeset: 69ec02d12a31 Author: lagergren Date: 2013-07-02 15:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/69ec02d12a31 Merge Changeset: 16c4535abcf8 Author: sundar Date: 2013-07-02 18:39 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/16c4535abcf8 Merge Changeset: 542b7803f038 Author: lana Date: 2013-07-05 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/542b7803f038 Merge Changeset: 10a1ab9e20a4 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/10a1ab9e20a4 Added tag jdk8-b98 for changeset 542b7803f038 ! .hgtags From john.coomes at oracle.com Thu Jul 11 11:35:16 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 18:35:16 +0000 Subject: hg: hsx/hotspot-main/langtools: 32 new changesets Message-ID: <20130711183650.67C94489CA@hg.openjdk.java.net> Changeset: 6debfa63a4a1 Author: vromero Date: 2013-06-20 08:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6debfa63a4a1 8016613: javac should avoid source 8 only analysis when compiling for source 7 Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java Changeset: e9ebff1840e5 Author: emc Date: 2013-06-20 19:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e9ebff1840e5 8007546: ClassCastException on JSR308 tests 8015993: jck-compiler tests are failed with java.lang.ClassCastException Summary: Fix ClassCastExceptions arising from addition of AnnotatedType. Reviewed-by: jjg, abuckley ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java Changeset: bf020de5a6db Author: emc Date: 2013-06-24 22:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bf020de5a6db 8012722: Single comma in array initializer should parse Summary: Annotations of the form @Foo({,}) should parse Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/SingleCommaAnnotationValue.java + test/tools/javac/parser/SingleCommaAnnotationValueFail.java + test/tools/javac/parser/SingleCommaAnnotationValueFail.out Changeset: 831467c4c6a7 Author: vromero Date: 2013-06-25 16:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/831467c4c6a7 8017104: javac should have a class for primitive types that inherits from Type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java Changeset: aceae9ceebbe Author: kizune Date: 2013-06-25 20:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/aceae9ceebbe 8006973: jtreg test fails: test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Reviewed-by: ksrini ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Changeset: c2d9303c3477 Author: ksrini Date: 2013-06-26 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c2d9303c3477 8016908: TEST_BUG: removing non-ascii characters causes tests to fail Reviewed-by: jjg, vromero ! test/tools/javac/api/6437999/T6437999.java - test/tools/javac/api/6437999/Utf8.java ! test/tools/javac/api/T6306137.java Changeset: 3b2e10524627 Author: jjg Date: 2013-06-26 18:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3b2e10524627 8014137: Update test/tools/javac/literals/UnderscoreLiterals to add testcases with min/max values Reviewed-by: jjg, darcy Contributed-by: matherey.nunez at oracle.com ! test/tools/javac/literals/UnderscoreLiterals.java Changeset: 4fe5aab73bb2 Author: bpatel Date: 2013-06-26 20:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4fe5aab73bb2 8007338: Method grouping tab line-folding Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: 27bd6a2302f6 Author: bpatel Date: 2013-06-26 20:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/27bd6a2302f6 8014017: extra space in javadoc class heading Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java Changeset: 36e8bc1907a2 Author: bpatel Date: 2013-06-26 20:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/36e8bc1907a2 8013738: Two javadoc tests have bug 0000000 Reviewed-by: jjg ! test/com/sun/javadoc/testNestedInlineTag/TestNestedInlineTag.java ! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java Changeset: c674b396827c Author: emc Date: 2013-06-27 00:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c674b396827c 8014230: Compilation incorrectly succeeds with inner class constructor with 254 parameters Summary: The compiler does not account fr extra parameters due to inner this parameters Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javac/limits/NestedClassConstructorArgs.java + test/tools/javac/limits/NestedClassMethodArgs.java - test/tools/javac/limits/NumArgs1.java - test/tools/javac/limits/NumArgs2.java - test/tools/javac/limits/NumArgs3.java - test/tools/javac/limits/NumArgs4.java + test/tools/javac/limits/NumArgsTest.java + test/tools/javac/limits/StaticNestedClassConstructorArgs.java + test/tools/javac/limits/TopLevelClassConstructorArgs.java + test/tools/javac/limits/TopLevelClassMethodArgs.java + test/tools/javac/limits/TopLevelClassStaticMethodArgs.java Changeset: dcc6a52bf363 Author: erikj Date: 2013-06-27 10:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dcc6a52bf363 8014513: Sjavac doesn't detect 32-bit jvm properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java Changeset: a47e28759666 Author: vromero Date: 2013-06-27 09:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a47e28759666 7066788: javah again accepts -old option (ineffectively) which was removed in 1.5. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javah/JavahTask.java Changeset: 8e3d391c88c6 Author: vromero Date: 2013-06-27 09:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8e3d391c88c6 8017609: javac, ClassFile.read(Path) should be ClassFile.read(Path, Attribute.Factory) Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/ClassFile.java Changeset: e42c27026290 Author: vromero Date: 2013-06-27 16:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e42c27026290 8016099: Some @SuppressWarnings annotations ignored ( unchecked, rawtypes ) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T8016099/UncheckedWarningRegressionTest.java + test/tools/javac/T8016099/UncheckedWarningRegressionTest.out Changeset: d137ce373c4c Author: vromero Date: 2013-06-27 16:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d137ce373c4c 7008643: inlined finally clauses confuse debuggers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java Changeset: 26437287529d Author: janvalenta Date: 2013-06-27 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/26437287529d 8015720: since tag isn't copied while generating JavaFX documentation Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! test/com/sun/javadoc/testJavaFX/C.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java Changeset: 065f8cb7bd89 Author: darcy Date: 2013-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/065f8cb7bd89 8019308: Add descriptions of Java SE 7 and 8 language changes to SourceVersion Reviewed-by: jjg ! src/share/classes/javax/lang/model/SourceVersion.java Changeset: 97e798c06804 Author: ksrini Date: 2013-06-27 12:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/97e798c06804 7080001: Need to bump version numbers in build.properties for 8 Reviewed-by: jjg ! make/build.properties Changeset: 5c548a8542b8 Author: emc Date: 2013-06-27 17:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5c548a8542b8 8013357: javac accepts erroneous binary comparison operations Summary: javac does not report type errors on illegal Object == primitive comparisons Reviewed-by: abuckley, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! test/tools/javac/lambda/LambdaConv01.java ! test/tools/javac/lambda/LambdaExpr15.java ! test/tools/javac/lambda/typeInference/InferenceTest2b.java + test/tools/javac/types/TestComparisons.java Changeset: 6101e52ce9e3 Author: emc Date: 2013-06-28 06:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6101e52ce9e3 8016760: Failure of regression test langtools/tools/javac/T6725036.java Summary: Marking the failing test @ignore; the proposed change for 8015666 addresses the underlying issue Reviewed-by: jjg ! test/tools/javac/T6725036.java Changeset: bb06c412d079 Author: vromero Date: 2013-06-28 13:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bb06c412d079 6473148: TreePath.iterator() should document the iteration order Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/TreePath.java Changeset: bdd699d7378d Author: vromero Date: 2013-06-28 14:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bdd699d7378d 8005552: c.s.t.javap.AttributeWriter.visitLocalVariableTable() uses incorrect format string Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 66147d50d8d6 Author: lana Date: 2013-06-28 19:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/66147d50d8d6 Merge Changeset: 891c5ecb8306 Author: vromero Date: 2013-06-29 20:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/891c5ecb8306 6983646: javap should identify why a DefaultAttribute is being used Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/DefaultAttribute.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: f559ef7568ce Author: mcimadamore Date: 2013-07-01 14:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f559ef7568ce 7034798: Ambiguity error for abstract method call is too eager Summary: Javac should wait and see if ambiguous methods can be reconciled at the end of an overload resolution round Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/tests/AbstractMerge.java ! test/tools/javac/resolve/tests/InnerOverOuter.java Changeset: 1908e86ee49a Author: darcy Date: 2013-07-01 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1908e86ee49a 7162089: Add support for repeating annotations to javax.annotation.processing Reviewed-by: abuckley, jjg, jfranck ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/javax/annotation/processing/AbstractProcessor.java ! src/share/classes/javax/annotation/processing/Processor.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java + test/tools/javac/processing/environment/round/TpAnno.java + test/tools/javac/processing/environment/round/TypeParameterAnnotations.java Changeset: 27a2e8c78bd0 Author: vromero Date: 2013-07-02 10:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/27a2e8c78bd0 8019397: javap does not show SourceDebugExtension properly Reviewed-by: jjg Contributed-by: dmytro_sheyko at hotmail.com ! src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 565341d436e2 Author: ksrini Date: 2013-07-01 16:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/565341d436e2 8019460: tests in changeset do not have @bug tag Reviewed-by: darcy ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Changeset: 3b4f92a3797f Author: vromero Date: 2013-07-02 22:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3b4f92a3797f 6326693: variable x might already have been assigned, when assignment is in catch block Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.out Changeset: ce5a90df517b Author: lana Date: 2013-07-05 11:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ce5a90df517b Merge Changeset: bdeef606be8e Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bdeef606be8e Added tag jdk8-b98 for changeset ce5a90df517b ! .hgtags From alejandro.murillo at oracle.com Thu Jul 11 12:52:03 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 11 Jul 2013 19:52:03 +0000 Subject: hg: hsx/hsx24/hotspot: 8020381: new hotspot build - hs24-b54 Message-ID: <20130711195207.D9227489DE@hg.openjdk.java.net> Changeset: df77331d0dcb Author: amurillo Date: 2013-07-11 06:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/df77331d0dcb 8020381: new hotspot build - hs24-b54 Reviewed-by: jcoomes ! make/hotspot_version From goetz.lindenmaier at sap.com Thu Jul 11 14:38:43 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 11 Jul 2013 21:38:43 +0000 Subject: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. In-Reply-To: <51DEEA12.9010906@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF3680@DEWDFEMB12A.global.corp.sap> <51DB6DC7.1020900@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF3DF7@DEWDFEMB12A.global.corp.sap> <51DBFD23.90407@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF41F4@DEWDFEMB12A.global.corp.sap> <51DDB362.1020007@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF4D9B@DEWDFEMB12A.global.corp.sap> <51DDD51D.4090505@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF5148@DEWDFEMB12A.global.corp.sap> <51DEEA12.9010906@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF53E3@DEWDFEMB12A.global.corp.sap> Hi, that`s good, especially if we get 8014399: Remove JVM_SetProtectionDomain from hotspot into the staging repo so that all can be combined again. Thanks a lot, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, July 11, 2013 7:24 PM To: Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. I will push it and will do sync of whole jdk forest from jdk8. Thanks, Vladimir On 7/11/13 3:27 AM, Lindenmaier, Goetz wrote: > David, Vladimir, thanks for the reviews! > > Vladimir, will you push it, or should I do it? > I added the Reviewed-by line to the webrev. > http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 10. Juli 2013 23:42 > To: Lindenmaier, Goetz > Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > > On 7/10/13 2:00 PM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> I thought about that, too. But it seems quiet risky to me, >> as it depends on the final order of inclusion whether it works. >> Usually, macro.hpp will be included early, because it's basics that should >> be seen everywhere. Also, it will end up early in the preprocessed >> file as it has no other includes itself. >> >> If the system headers are included later, they will overrule the undef in >> macro.hpp. >> I think it's even some kind of pattern in the hotspot files to include the >> system headers after the hotspot headers. >> >> So even if it works now, it easily might break. > > Agree. Your changes are good then. > > thanks, > Vladimir > >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, July 10, 2013 9:18 PM >> To: Lindenmaier, Goetz >> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >> >> Goetz, >> >> macros.hpp is included in all other files. Can we just undef IA64 there?: >> >> // This is a REALLY BIG HACK, but on AIX >> unconditionally defines IA64. >> // At least on AIX 7.1 this is a real problem because 'systemcfg.h' is >> indirectly included >> // by 'pthread.h' and other common system headers. >> #ifdef AIX >> #undef IA64 >> #endif >> >> thanks, >> Vladimir >> >> On 7/9/13 6:12 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> Here a webrev without the cleanups: >>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def-2/ >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 9. Juli 2013 14:08 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >>> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >>> >>> On 9/07/2013 7:56 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>>> A curious thing to do ;-) >>>> Yes, I agree. >>>> >>>>> Aside: presumably this is included in turn by other standard headers, >>>>> not directly included - otherwise we could just undef IA64 after the >>>>> include. >>>> Yes, that's the case. >>>> >>>>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>>>> think we may even have a RFE for this. AFAIK there are no remaining >>>>> users of the IA64 code in the hotspot codebase. >>>> Yes, there is a remaining user. We have Java 4-7 VMs on linux, hp & win >>>> Ia64. 8 in development, all soon based on hs25. We also contributed to >>>> the change cleaning up the IA64 defines. There are only such left >>>> we need in our code. >>>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 >>> >>> I'm somewhat perplexed. The IA64 uses you still see in the hotspot >>> sources are ancient remnants of the IA64 support. Most of it has been >>> stripped out completely. So how anyone could be using any of this is, as >>> I said, perplexing ??? >>> >>>>> #if defined(__GNUC__) && !defined(IA64) >>>> You are right, I could just leave it as is, except if __GNUC__ is define on AIX, >>>> who knows ;). If we don't remove it, I need to add !PPC64 so that it's >>>> inlined in our port on linux. >>>>> more to avoid build-failures, but we may still want to avoid inlining >>>>> them for other reasons! So this aspect needs further investigation. Or >>>> I think it's a good idea to clean it up. The build problem >>>> is documented. There may be 'other reasons', but unexpected issues >>>> can be there with any change. >>> >>> But the aim is to avoid making gratuitous changes to code that is not >>> part of the ppc64/AIX port. If you start inlining these functions you >>> don't know what the impact will be. So why change them when it is not >>> necessary. >>> >>> David >>> ----- >>> >>>>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>>> Again if we just get rid of IA64 this will be a non-issue right? >>>> Here I would add !AIX. >>>> But have a look at the file, there are also several other platforms >>>> where this is excluded, and the exclusion is implemented differently >>>> on each platform. Not that nice ... >>>> >>>> Anyways, I'm fine with adding !AIX/!PPC64 everywhere -- it's nothing >>>> functional. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 9. Juli 2013 03:56 >>>> To: Lindenmaier, Goetz >>>> Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'; Vladimir Kozlov >>>> Subject: Re: RFR(M): 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. >>>> >>>> Hi Goetz, >>>> >>>> On 8/07/2013 10:45 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> This is in preparation of the PPC AIX port. >>>>> >>>>> A header file (systemcfg.h) on Aix 7.1 defines the macro "IA64" unconditionally. >>>> >>>> A curious thing to do ;-) >>>> >>>> Aside: presumably this is included in turn by other standard headers, >>>> not directly included - otherwise we could just undef IA64 after the >>>> include. >>>> >>>>> This leads to wrong configurations of shared files on Aix where IA64 is used. >>>>> This change replaces uses of "IA64" by "IA64 && !AIX". >>>> >>>> Might be simpler if we just eradicate the IA64 remnants in the code. I >>>> think we may even have a RFE for this. AFAIK there are no remaining >>>> users of the IA64 code in the hotspot codebase. >>>> >>>>> To reduce the complexity we propose to simplify two matters: >>>>> >>>>> Since the initial checkin objectMonitor.cpp and synchronizer.cpp >>>>> define #define ATTR __attribute__((noinline)) claiming this is needed >>>>> to avoid a gcc build time error with - at that time - old gcc versions. >>>>> This define depends on IA64. We remove it altogether. >>>> >>>> Well it doesn't "depend" on IA64: >>>> >>>> #if defined(__GNUC__) && !defined(IA64) >>>> // Need to inhibit inlining for older versions of GCC to avoid >>>> build-time failures >>>> #define ATTR __attribute__((noinline)) >>>> #else >>>> #define ATTR >>>> #endif >>>> >>>> it becomes empty on IA64 (and non gcc systems). So removing it >>>> altogether is changing things for all the other gcc using platforms. Now >>>> it may be that we don't need to preclude inlining of these methods any >>>> more to avoid build-failures, but we may still want to avoid inlining >>>> them for other reasons! So this aspect needs further investigation. Or >>>> you can just leave it as-is - if you have IA64 always defined then you >>>> will get the empty #else part. Or if we go with the "eradicate IA64" >>>> path then you can change IA64 to AIX (though it is odd to exchange an >>>> architecture check with an OS check). >>>> >>>>> prims/forte.cpp uses a lot of different mechanisms all disabling forte >>>>> support on windows, apple and ia64. We would have to add Aix. >>>>> Instead, we propose to use a check for the supported platforms (see webrev). >>>>> We could also add a macro SUPPORTS_FORTE that is defined in the corresponding >>>>> makefiles, and/or move forte.cpp into the os/solaris and os_cpu/linux_x86 >>>>> directories. >>>> >>>> Again if we just get rid of IA64 this will be a non-issue right? >>>> >>>> Thanks, >>>> David >>>> >>>>> Are there other platforms that need to be supported? I derived the platforms >>>>> from the comment in forte.cpp. >>>>> >>>>> Please review this change. I'm happy to incorporate your comments. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8019973-ia64_def/aixia64-hotspot.changeset >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> From tao.mao at oracle.com Thu Jul 11 15:38:00 2013 From: tao.mao at oracle.com (tao.mao at oracle.com) Date: Thu, 11 Jul 2013 22:38:00 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130711223812.E973748A05@hg.openjdk.java.net> Changeset: 2cbc8f3011a0 Author: ehelin Date: 2013-06-05 09:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2cbc8f3011a0 8015972: Refactor the sending of the object count after GC event Reviewed-by: brutisso, pliden ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.hpp ! src/share/vm/memory/heapInspection.hpp - src/share/vm/memory/klassInfoClosure.hpp Changeset: 63cffb381adc Author: ehelin Date: 2013-06-12 15:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/63cffb381adc 8016170: GC id variable in gcTrace.cpp should use typedef GCId Reviewed-by: johnc, jwilhelm, jmasa ! src/share/vm/gc_implementation/shared/gcTrace.cpp Changeset: 6aa440bc1125 Author: ehelin Date: 2013-06-12 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6aa440bc1125 8015683: object_count_after_gc should have the same timestamp for all events Reviewed-by: mgerdin, stefank ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp Changeset: 27c53c9f3a7e Author: ehelin Date: 2013-07-10 15:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/27c53c9f3a7e 8013939: Metaspace capacity not available Reviewed-by: tschatzl, mgerdin, stefank ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 0f631140d13b Author: tamao Date: 2013-07-11 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0f631140d13b Merge - src/share/vm/memory/klassInfoClosure.hpp From zhengyu.gu at oracle.com Fri Jul 12 16:31:17 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 12 Jul 2013 23:31:17 +0000 Subject: hg: hsx/hsx24/hotspot: 8012241: NMT huge memory footprint, it usually leads to OOME Message-ID: <20130712233121.1030D48A51@hg.openjdk.java.net> Changeset: 79c6a69a317e Author: zgu Date: 2013-07-12 16:51 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/79c6a69a317e 8012241: NMT huge memory footprint, it usually leads to OOME Summary: Enforce memory limitation on NMT to prevent JVM OOM Reviewed-by: acorn, dcubed, minqi ! src/share/vm/services/memTracker.cpp From alejandro.murillo at oracle.com Fri Jul 12 16:30:28 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 12 Jul 2013 23:30:28 +0000 Subject: hg: hsx/hotspot-main/langtools: 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle; ... Message-ID: <20130712233038.B4BC948A50@hg.openjdk.java.net> Changeset: 39ec5d8a691b Author: mcimadamore Date: 2013-07-11 14:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/39ec5d8a691b 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle 8020010: Move lambda bridge creation from metafactory and VM to compiler Summary: langtools/javac component of the bridge support and MethodType vs. MethodHandle changes. Reviewed-by: jjg, vromero, briangoetz, forax Contributed-by: robert.field at oracle.com ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/generics/bridges/Bridge.java + test/tools/javac/generics/bridges/BridgeHarness.java + test/tools/javac/generics/bridges/Bridges.java + test/tools/javac/generics/bridges/tests/TestBridgeWithDefault.java + test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical01.java + test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical02.java + test/tools/javac/generics/bridges/tests/TestNoBridgeInSiblingsSuper.java + test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges01.java + test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges02.java + test/tools/javac/lambda/bridge/TestMetafactoryBridges.java ! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java ! test/tools/javac/lambda/methodReference/BridgeMethod.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java From alejandro.murillo at oracle.com Fri Jul 12 16:28:17 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 12 Jul 2013 23:28:17 +0000 Subject: hg: hsx/hotspot-main/jdk: 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle; ... Message-ID: <20130712232931.58DD648A4F@hg.openjdk.java.net> Changeset: f83794805201 Author: mcimadamore Date: 2013-07-11 14:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f83794805201 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle 8020010: Move lambda bridge creation from metafactory and VM to compiler Summary: JDK/metafactory component of the bridge fix and and MethodType vs. MethodHandle changes. Reviewed-by: twisti, briangoetz, forax Contributed-by: robert.field at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java From vladimir.kozlov at oracle.com Fri Jul 12 16:36:38 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Jul 2013 16:36:38 -0700 Subject: RFR (S): 8020425: Product options incorrectly removed in minor version In-Reply-To: <51E06088.3000105@oracle.com> References: <51E06088.3000105@oracle.com> Message-ID: <51E09306.8030002@oracle.com> http://cr.openjdk.java.net/~kvn/8020425/webrev/ When run jdk7u40 with flags we removed (6677625) give warning and ignore flags: java -XX:+UseSpinning -version Java HotSpot(TM) 64-Bit Server VM warning: ignoring option UseSpinning; support was removed in 7.0_40 Thanks, Vladimir From alejandro.murillo at oracle.com Fri Jul 12 20:42:31 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 13 Jul 2013 03:42:31 +0000 Subject: hg: hsx/hsx25/hotspot: 33 new changesets Message-ID: <20130713034356.6E9D848A57@hg.openjdk.java.net> Changeset: 1a3390aa8326 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1a3390aa8326 Added tag jdk8-b98 for changeset 30b5b75c42ac ! .hgtags Changeset: ea4d24c1e0c6 Author: amurillo Date: 2013-07-04 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ea4d24c1e0c6 8019934: new hotspot build - hs25-b41 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f323bbb0e6c1 Author: coleenp Date: 2013-07-03 13:45 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f323bbb0e6c1 8019833: Wrong JNI error code for preexisting JVM Summary: Return the appropriate JNI error message (instead of the generic one) when the JVM is already started Reviewed-by: coleenp, hseigel Contributed-by: sylvestre at debian.org ! src/share/vm/prims/jni.cpp Changeset: 5f7a4367c787 Author: zgu Date: 2013-07-04 06:24 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5f7a4367c787 8016074: NMT: assertion failed: assert(thread->thread_state() == from) failed: coming from wrong thread state Summary: Uses os::NakedYield() on Solaris instead of os::yield_all() Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/memTracker.hpp Changeset: a55aa67bce1a Author: zgu Date: 2013-07-04 04:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a55aa67bce1a Merge Changeset: 59b052799158 Author: dcubed Date: 2013-07-04 21:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/59b052799158 8015884: runThese crashed with SIGSEGV, hs_err has an error instead of stacktrace Summary: Dl_info struct should only be used if dladdr() has returned non-zero (no errors) and always check the dladdr() return value; Dl_info.dli_sname and Dl_info.dli_saddr fields should only be used if non-NULL; update/improve runtime/6888954/vmerrors.sh test Reviewed-by: dsamersoff, zgu, hseigel, coleenp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! test/runtime/6888954/vmerrors.sh Changeset: 93e6dce53ba7 Author: fparain Date: 2013-07-05 08:26 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/93e6dce53ba7 8016465: The hs_err file gets wrong name Reviewed-by: dcubed, dholmes, rdurbin ! src/share/vm/utilities/vmError.cpp Changeset: cc5b7915104e Author: fparain Date: 2013-07-05 08:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cc5b7915104e Merge Changeset: cf9d71d3e474 Author: iklam Date: 2013-07-08 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cf9d71d3e474 8016903: Thread::_handle_area initial size too big Summary: Changed initial size to Chunk::tiny_size (216 bytes) Reviewed-by: coleenp, dholmes, sspitsyn ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/handles.hpp Changeset: 71180a6e5080 Author: jiangli Date: 2013-07-03 17:26 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/71180a6e5080 7133260: AllocationProfiler uses space in metadata and doesn't seem to do anything useful. Summary: Remove -Xaprof and Klass::_alloc_count & ArrayKlass::_alloc_size. Reviewed-by: stefank, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fa6929d0b0a9 Author: jiangli Date: 2013-07-08 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fa6929d0b0a9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3c7b4b7b2625 Author: jiangli Date: 2013-07-08 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3c7b4b7b2625 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ba9dacff9c9d Author: hseigel Date: 2013-07-08 19:36 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ba9dacff9c9d 8014399: Remove JVM_SetProtectionDomain from hotspot Summary: JVM_SetProtectionDomain has been deprecated since 1.5 and is being removed Reviewed-by: coleenp, hseigel Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 26037663c2a6 Author: hseigel Date: 2013-07-08 16:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/26037663c2a6 Merge Changeset: e79a9f26ba2e Author: hseigel Date: 2013-07-08 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e79a9f26ba2e Merge Changeset: 72fce0b2d341 Author: zgu Date: 2013-07-09 13:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/72fce0b2d341 8011760: assert(delta != 0) failed: dup pointer in MemBaseline::malloc_sort_by_addr Summary: Some of qsort implementation on Linux x86 compares element to itself, which is mistakenly treated as duplicate pointer Reviewed-by: dcubed, acorn ! src/share/vm/services/memBaseline.cpp Changeset: 2839ce15e450 Author: zgu Date: 2013-07-09 19:56 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2839ce15e450 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: 50257d6f5aaa Author: acorn Date: 2013-07-09 14:02 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/50257d6f5aaa 8013635: VM should no longer create bridges for generic signatures. Summary: Requires: 8013789: Compiler bridges, 8015402: metafactory Reviewed-by: sspitsyn, coleenp, bharadwaj ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/runtime/globals.hpp Changeset: 22baec423e2f Author: acorn Date: 2013-07-09 22:48 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/22baec423e2f Merge Changeset: e50be1620201 Author: goetz Date: 2013-07-08 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e50be1620201 8020059: The flag introduced by 8014972 is not defined if Hotspot is built without a compiler (zero, ppc64 core build). Summary: define CodeCacheMinimumUseSpace flag for cppInterpeter build. Reviewed-by: kvn ! src/share/vm/runtime/globals.hpp Changeset: e554162ab094 Author: adlertz Date: 2013-07-09 17:20 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e554162ab094 8019625: Test compiler/8005956/PolynomialRoot.java timeouts on Solaris SPARCs Summary: Disable the test for SPARC and reduce the number of test iterations Reviewed-by: kvn ! test/compiler/8005956/PolynomialRoot.java Changeset: b42fe1a8e180 Author: drchase Date: 2013-07-09 08:56 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b42fe1a8e180 8017578: Hotspot compilation error with latest Studio compiler Summary: Make the destructor virtual (note more non-compiler hotspot errors occur downstream) Reviewed-by: kvn, twisti ! src/share/vm/adlc/forms.hpp Changeset: 7ac80525ece9 Author: anoll Date: 2013-07-09 11:48 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7ac80525ece9 8015635: Crash when specifying very large code cache size Summary: Limit the size of the code cache to at most 2G when arguments are checked; added regression test Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp + test/compiler/codecache/CheckUpperLimit.java Changeset: 5f533e38e7d5 Author: twisti Date: 2013-07-09 22:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5f533e38e7d5 Merge Changeset: dec841e0c9aa Author: anoll Date: 2013-07-10 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dec841e0c9aa 8016749: -XX:+UseISM fails an assert(obj->is_oop()) when running SPECjbb2005 Summary: Remove obsolete code that relates to ISM which was used only on Solaris 8. Reviewed-by: kvn, twisti ! src/os/solaris/vm/globals_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/share/vm/runtime/arguments.cpp Changeset: ec173c8f3739 Author: roland Date: 2013-07-11 01:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ec173c8f3739 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2cbc8f3011a0 Author: ehelin Date: 2013-06-05 09:44 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2cbc8f3011a0 8015972: Refactor the sending of the object count after GC event Reviewed-by: brutisso, pliden ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.hpp ! src/share/vm/memory/heapInspection.hpp - src/share/vm/memory/klassInfoClosure.hpp Changeset: 63cffb381adc Author: ehelin Date: 2013-06-12 15:50 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/63cffb381adc 8016170: GC id variable in gcTrace.cpp should use typedef GCId Reviewed-by: johnc, jwilhelm, jmasa ! src/share/vm/gc_implementation/shared/gcTrace.cpp Changeset: 6aa440bc1125 Author: ehelin Date: 2013-06-12 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6aa440bc1125 8015683: object_count_after_gc should have the same timestamp for all events Reviewed-by: mgerdin, stefank ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp Changeset: 27c53c9f3a7e Author: ehelin Date: 2013-07-10 15:28 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/27c53c9f3a7e 8013939: Metaspace capacity not available Reviewed-by: tschatzl, mgerdin, stefank ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 0f631140d13b Author: tamao Date: 2013-07-11 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0f631140d13b Merge - src/share/vm/memory/klassInfoClosure.hpp Changeset: 2b9946e10587 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2b9946e10587 Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ea979302bb70 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ea979302bb70 Added tag hs25-b41 for changeset 2b9946e10587 ! .hgtags From alejandro.murillo at oracle.com Sat Jul 13 00:46:49 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 13 Jul 2013 07:46:49 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130713074702.6EECE48A5E@hg.openjdk.java.net> Changeset: 1a3390aa8326 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a3390aa8326 Added tag jdk8-b98 for changeset 30b5b75c42ac ! .hgtags Changeset: 2b9946e10587 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2b9946e10587 Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ea979302bb70 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ea979302bb70 Added tag hs25-b41 for changeset 2b9946e10587 ! .hgtags Changeset: bd1dc81da579 Author: amurillo Date: 2013-07-12 17:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bd1dc81da579 8020382: new hotspot build - hs25-b42 Reviewed-by: jcoomes ! make/hotspot_version From bengt.rutisson at oracle.com Sun Jul 14 17:02:13 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 15 Jul 2013 00:02:13 +0000 Subject: hg: hsx/hsx24/hotspot: 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer Message-ID: <20130715000215.991544809F@hg.openjdk.java.net> Changeset: 9cc209978fc0 Author: brutisso Date: 2013-07-11 11:33 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9cc209978fc0 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer Summary: Take _last_young_gc into account when deciding on starting a concurrent mark. Also reviewed-by: per.liden at oracle.com. Reviewed-by: tschatzl, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp From goetz.lindenmaier at sap.com Mon Jul 15 00:41:36 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 15 Jul 2013 07:41:36 +0000 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <51DD7FE8.9070207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDBDE@DEWDFEMB12A.global.corp.sap> <51D20DEC.7050904@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF1499@DEWDFEMB12A.global.corp.sap> <51D3515F.10402@oracle.com> <51DD7FE8.9070207@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF5882@DEWDFEMB12A.global.corp.sap> Hi, I saw you pushed 5 to hotspot-emb, that's great, thanks a lot. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Mittwoch, 10. Juli 2013 17:38 To: Volker Simonis Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch Albert is working on other urgent issues so the work on safefetch is delayed. Regards, Vladimir On 7/10/13 8:29 AM, Volker Simonis wrote: > Hi Vladimir, > > what's the status of this patch? > Are you still evaluate the required closed source changes? > > Regards, > Volker > > > On Wed, Jul 3, 2013 at 12:17 AM, Vladimir Kozlov > wrote: >> Thank you, Goetz >> >> We are doing review of closed changes. When they are ready I will push. >> >> Thanks, >> Vladimir >> >> >> On 7/2/13 2:47 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> Sorry for that, I didn't grok the comment. The alignment is a good idea. >>> Fixed: >>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Dienstag, 2. Juli 2013 01:17 >>> To: Lindenmaier, Goetz >>> Cc: 'Christian Thalinger'; 'Albert Noll (albert.noll at oracle.com)'; >>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>> safefetch >>> >>> Goetz, >>> >>> Why you did not add 'nop' between load and return instructions on sparc? >>> It was in assembler in .s file. The next comment said we need it: >>> >>> !! By convention with the trap handler we ensure there is a non-CTI >>> !! instruction in the trap shadow. >>> >>> Also should we align code in stubs to keep it in one cache line? >>> >>> __ align(CodeEntryAlignment); >>> *entry = __ pc(); >>> >>> Thanks, >>> Vladimir >>> >>> On 6/24/13 12:31 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> you are right, the check is redundant. >>>> I removed it and updated the webrev and also based it on the >>>> recent staging repo: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> Sent: Monday, June 24, 2013 7:48 PM >>>> To: Lindenmaier, Goetz >>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>> 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>> safefetch >>>> >>>> >>>> On Jun 20, 2013, at 7:01 AM, "Lindenmaier, Goetz" >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I implemented the safefetch stubs for x86 and sparc (was quiet simple). >>>>> This way I could clean up the #define right away. >>>>> >>>>> I tested it thouroughly on >>>>> x86_64: bsd, nt, linux, solaris >>>>> x86_32: nt, linux >>>>> by adding it into our internal VM. >>>>> Tonight I will get build/test on >>>>> sparc_64 solaris >>>>> sparc_32 solaris >>>>> x86_64 nt, linux >>>>> with the openjdk ppc port, but I tested that before submitting in a >>>>> smaller >>>>> extend, too. >>>>> >>>>> Here the webrev: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>>> >>>> >>>> I like this change. It removes a lot of duplication. One comment: >>>> >>>> + static bool is_safefetch_fault(address pc) { >>>> + return pc != NULL && >>>> + (pc == _safefetch32_fault_pc || >>>> + pc == _safefetchN_fault_pc); >>>> + } >>>> >>>> checks for pc != null. Should we remove the check here? >>>> >>>> + if (pc && StubRoutines::is_safefetch_fault(pc)) { >>>> + set_cont_address(uc, >>>> address(StubRoutines::continuation_for_safefetch_fault(pc))); >>>> return true; >>>> } >>>> >>>> -- Chris >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> Sent: Dienstag, 18. Juni 2013 22:44 >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>>> 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>> safefetch >>>>> >>>>> >>>>> On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" >>>>> wrote: >>>>> >>>>>> Ok, I will implement it on x86. >>>>>> >>>>>> To get a single change, you can give me the sparc patch, >>>>>> or you extend the webrev once I updated it with the >>>>>> x86 code. >>>>> >>>>> >>>>> Sounds good. Let me know when it's there. >>>>> >>>>> -- Chris >>>>> >>>>>> If you prefer, you can also push it to some other repository, it >>>>>> will end up in the ppc repo in time I guess. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>> Sent: Tuesday, June 18, 2013 6:59 PM >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>>> hotspot-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>>> safefetch >>>>>> >>>>>> >>>>>> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We have it on these platforms: >>>>>>> ia64 (nt, linux, hp_ux) >>>>>>> parisc (hp_ux) >>>>>>> zArch (linux) >>>>>>> ppc (aix, linux) >>>>>>> >>>>>>> I would implement it on x86 & friends, you do it on sparc and wherever >>>>>>> else you like it? >>>>>> >>>>>> >>>>>> That sounds reasonable. Are we pushing this to the ppc repository >>>>>> then? >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>>> Sent: Dienstag, 18. Juni 2013 07:13 >>>>>>> To: Volker Simonis >>>>>>> Cc: Lindenmaier, Goetz; Vladimir Kozlov; >>>>>>> ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>>>> safefetch >>>>>>> >>>>>>> >>>>>>> On Jun 17, 2013, at 10:08 AM, Volker Simonis >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> I think the change is good and if the other reviewers don't decide to >>>>>>>> implement it for the current platforms we can push it. >>>>>>> >>>>>>> >>>>>>> I talked with Vladimir about this today and I my opinion we should use >>>>>>> this stub on all platforms. On which other platforms are you guys having >>>>>>> this? >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> By the way, the makefile changes in ppc64.make will follow in patch 8 >>>>>>>> for >>>>>>>> linux [1] and patch 14 for aix [2]. >>>>>>>> The implementation of the stubs will be in patch 9 for linux [3] and >>>>>>>> patch >>>>>>>> 15 for aix [4] (only the signal handling part). >>>>>>>> >>>>>>>> Regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>>>>>>> [2] >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>>>>>>> [3] >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>>>>>>> [4] >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>>>>>>> goetz.lindenmaier at sap.com> wrote: >>>>>>>> >>>>>>>>> Hi,**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> the PPC64 port uses stub routines to implement safefetch. We had >>>>>>>>> and**** >>>>>>>>> >>>>>>>>> have problems with inline assembly, especially with non-gcc**** >>>>>>>>> >>>>>>>>> compilers. Stub routines allow to implement safefetch without**** >>>>>>>>> >>>>>>>>> depending on OS or compiler, as it's the case with the current**** >>>>>>>>> >>>>>>>>> implementation. This also allows to use a single implementation if >>>>>>>>> an**** >>>>>>>>> >>>>>>>>> architecture is supported on several os platforms.**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Currently, we guard the code with **** >>>>>>>>> >>>>>>>>> #ifdef SAFEFETCH_STUBS**** >>>>>>>>> >>>>>>>>> which is set in ppc64.make.**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> I could also imagine an implementation that uses a pd_debug flag**** >>>>>>>>> >>>>>>>>> or a const flag set in os_.hpp that allows the C-compiler to >>>>>>>>> **** >>>>>>>>> >>>>>>>>> optimize, and writing the code like this:**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>>>>>>> >>>>>>>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t >>>>>>>>> errValue) ;*** >>>>>>>>> * >>>>>>>>> >>>>>>>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>>>>>>> >>>>>>>>> if (UseSafefetchStub) {**** >>>>>>>>> >>>>>>>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet >>>>>>>>> generated");*** >>>>>>>>> * >>>>>>>>> >>>>>>>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>>>>>>> >>>>>>>>> } else {**** >>>>>>>>> >>>>>>>>> pd_SafeFetch32(adr, errValue);**** >>>>>>>>> >>>>>>>>> }**** >>>>>>>>> >>>>>>>>> }**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Unfortunately this requires **** >>>>>>>>> >>>>>>>>> 1) setting the flag on all platforms**** >>>>>>>>> >>>>>>>>> 2) renaming the safefetch function on all platfoms.**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Actually I would prefer this second solution as it avoids the >>>>>>>>> preprocessor, **** >>>>>>>>> >>>>>>>>> and am happy to edit the sources accordingly if this finds >>>>>>>>> acceptance.**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> For the implementation of a safefetch_stub see**** >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>>>>> **** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Could I get a review on this change, please?**** >>>>>>>>> >>>>>>>>> ** ** >>>>>>>>> >>>>>>>>> Thanks,**** >>>>>>>>> >>>>>>>>> Goetz.**** >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From kim1144 at naver.com Mon Jul 15 01:12:54 2013 From: kim1144 at naver.com (Min Seong Kim) Date: Mon, 15 Jul 2013 17:12:54 +0900 (KST) Subject: =?UTF-8?B?TExWTSAyLjkgLyBPcGVuSkRLIDcgLyBaRVJP?= =?UTF-8?B?IGFuZCBTSEFSSyBhdmFpbGFibGUgYnVpbGQu?= Message-ID: <2b51dc9393a1b0f2dbc217f2484a987b@tweb02.nm.nhnsystem.com> Using LLVM 2.9 and OpenJDK7 with ZERO and SHARK compiler. I tried OpenJDK7 (http://hg.openjdk.java.net/jdk7/jdk7 and jdk7u/jdk7u) with LLVM 2.9, but it failed. with ZERO_BUILD=true / SHARK_BUILD=true. I think I choose wrong hg path and wrong build option. anyone who knows build ZERO and SHARK compiler with OpenJDK7?? From christian.thalinger at oracle.com Mon Jul 15 09:47:35 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 15 Jul 2013 09:47:35 -0700 Subject: RFR (S): 8020425: Product options incorrectly removed in minor version In-Reply-To: <51E09306.8030002@oracle.com> References: <51E06088.3000105@oracle.com> <51E09306.8030002@oracle.com> Message-ID: Looks good. -- Chris On Jul 12, 2013, at 4:36 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8020425/webrev/ > > When run jdk7u40 with flags we removed (6677625) give warning and ignore flags: > > java -XX:+UseSpinning -version > > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option UseSpinning; support was removed in 7.0_40 > > > Thanks, > Vladimir > > > > > > > > > > > > > > > From vladimir.kozlov at oracle.com Mon Jul 15 10:02:33 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jul 2013 10:02:33 -0700 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF5882@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDBDE@DEWDFEMB12A.global.corp.sap> <51D20DEC.7050904@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF1499@DEWDFEMB12A.global.corp.sap> <51D3515F.10402@oracle.com> <51DD7FE8.9070207@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF5882@DEWDFEMB12A.global.corp.sap> Message-ID: <51E42B29.9070505@oracle.com> Hi Goetz, We decided to push it into main sources to get full testing since it affects our code significantly. You will need to wait the promotion into stage repo a little more than one week. Regards, Vladimir On 7/15/13 12:41 AM, Lindenmaier, Goetz wrote: > Hi, > > I saw you pushed 5 to hotspot-emb, that's great, thanks a lot. > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 10. Juli 2013 17:38 > To: Volker Simonis > Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > Albert is working on other urgent issues so the work on safefetch is delayed. > > Regards, > Vladimir > > On 7/10/13 8:29 AM, Volker Simonis wrote: >> Hi Vladimir, >> >> what's the status of this patch? >> Are you still evaluate the required closed source changes? >> >> Regards, >> Volker >> >> >> On Wed, Jul 3, 2013 at 12:17 AM, Vladimir Kozlov >> wrote: >>> Thank you, Goetz >>> >>> We are doing review of closed changes. When they are ready I will push. >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 7/2/13 2:47 AM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> Sorry for that, I didn't grok the comment. The alignment is a good idea. >>>> Fixed: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Dienstag, 2. Juli 2013 01:17 >>>> To: Lindenmaier, Goetz >>>> Cc: 'Christian Thalinger'; 'Albert Noll (albert.noll at oracle.com)'; >>>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>> safefetch >>>> >>>> Goetz, >>>> >>>> Why you did not add 'nop' between load and return instructions on sparc? >>>> It was in assembler in .s file. The next comment said we need it: >>>> >>>> !! By convention with the trap handler we ensure there is a non-CTI >>>> !! instruction in the trap shadow. >>>> >>>> Also should we align code in stubs to keep it in one cache line? >>>> >>>> __ align(CodeEntryAlignment); >>>> *entry = __ pc(); >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/24/13 12:31 PM, Lindenmaier, Goetz wrote: >>>>> >>>>> Hi, >>>>> >>>>> you are right, the check is redundant. >>>>> I removed it and updated the webrev and also based it on the >>>>> recent staging repo: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> Sent: Monday, June 24, 2013 7:48 PM >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>>> 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>> safefetch >>>>> >>>>> >>>>> On Jun 20, 2013, at 7:01 AM, "Lindenmaier, Goetz" >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I implemented the safefetch stubs for x86 and sparc (was quiet simple). >>>>>> This way I could clean up the #define right away. >>>>>> >>>>>> I tested it thouroughly on >>>>>> x86_64: bsd, nt, linux, solaris >>>>>> x86_32: nt, linux >>>>>> by adding it into our internal VM. >>>>>> Tonight I will get build/test on >>>>>> sparc_64 solaris >>>>>> sparc_32 solaris >>>>>> x86_64 nt, linux >>>>>> with the openjdk ppc port, but I tested that before submitting in a >>>>>> smaller >>>>>> extend, too. >>>>>> >>>>>> Here the webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ >>>>> >>>>> >>>>> I like this change. It removes a lot of duplication. One comment: >>>>> >>>>> + static bool is_safefetch_fault(address pc) { >>>>> + return pc != NULL && >>>>> + (pc == _safefetch32_fault_pc || >>>>> + pc == _safefetchN_fault_pc); >>>>> + } >>>>> >>>>> checks for pc != null. Should we remove the check here? >>>>> >>>>> + if (pc && StubRoutines::is_safefetch_fault(pc)) { >>>>> + set_cont_address(uc, >>>>> address(StubRoutines::continuation_for_safefetch_fault(pc))); >>>>> return true; >>>>> } >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>> Sent: Dienstag, 18. Juni 2013 22:44 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>>>> 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>>> safefetch >>>>>> >>>>>> >>>>>> On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" >>>>>> wrote: >>>>>> >>>>>>> Ok, I will implement it on x86. >>>>>>> >>>>>>> To get a single change, you can give me the sparc patch, >>>>>>> or you extend the webrev once I updated it with the >>>>>>> x86 code. >>>>>> >>>>>> >>>>>> Sounds good. Let me know when it's there. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> If you prefer, you can also push it to some other repository, it >>>>>>> will end up in the ppc repo in time I guess. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>>> Sent: Tuesday, June 18, 2013 6:59 PM >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>>>> hotspot-dev at openjdk.java.net >>>>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>>>> safefetch >>>>>>> >>>>>>> >>>>>>> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We have it on these platforms: >>>>>>>> ia64 (nt, linux, hp_ux) >>>>>>>> parisc (hp_ux) >>>>>>>> zArch (linux) >>>>>>>> ppc (aix, linux) >>>>>>>> >>>>>>>> I would implement it on x86 & friends, you do it on sparc and wherever >>>>>>>> else you like it? >>>>>>> >>>>>>> >>>>>>> That sounds reasonable. Are we pushing this to the ppc repository >>>>>>> then? >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>>>> Sent: Dienstag, 18. Juni 2013 07:13 >>>>>>>> To: Volker Simonis >>>>>>>> Cc: Lindenmaier, Goetz; Vladimir Kozlov; >>>>>>>> ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement >>>>>>>> safefetch >>>>>>>> >>>>>>>> >>>>>>>> On Jun 17, 2013, at 10:08 AM, Volker Simonis >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> I think the change is good and if the other reviewers don't decide to >>>>>>>>> implement it for the current platforms we can push it. >>>>>>>> >>>>>>>> >>>>>>>> I talked with Vladimir about this today and I my opinion we should use >>>>>>>> this stub on all platforms. On which other platforms are you guys having >>>>>>>> this? >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>>> >>>>>>>>> By the way, the makefile changes in ppc64.make will follow in patch 8 >>>>>>>>> for >>>>>>>>> linux [1] and patch 14 for aix [2]. >>>>>>>>> The implementation of the stubs will be in patch 9 for linux [3] and >>>>>>>>> patch >>>>>>>>> 15 for aix [4] (only the signal handling part). >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>>>>>>>> [2] >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>>>>>>>> [3] >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>>>>>>>> [4] >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>>>>>>>> goetz.lindenmaier at sap.com> wrote: >>>>>>>>> >>>>>>>>>> Hi,**** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> the PPC64 port uses stub routines to implement safefetch. We had >>>>>>>>>> and**** >>>>>>>>>> >>>>>>>>>> have problems with inline assembly, especially with non-gcc**** >>>>>>>>>> >>>>>>>>>> compilers. Stub routines allow to implement safefetch without**** >>>>>>>>>> >>>>>>>>>> depending on OS or compiler, as it's the case with the current**** >>>>>>>>>> >>>>>>>>>> implementation. This also allows to use a single implementation if >>>>>>>>>> an**** >>>>>>>>>> >>>>>>>>>> architecture is supported on several os platforms.**** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> Currently, we guard the code with **** >>>>>>>>>> >>>>>>>>>> #ifdef SAFEFETCH_STUBS**** >>>>>>>>>> >>>>>>>>>> which is set in ppc64.make.**** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> I could also imagine an implementation that uses a pd_debug flag**** >>>>>>>>>> >>>>>>>>>> or a const flag set in os_.hpp that allows the C-compiler to >>>>>>>>>> **** >>>>>>>>>> >>>>>>>>>> optimize, and writing the code like this:**** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>>>>>>>> >>>>>>>>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t >>>>>>>>>> errValue) ;*** >>>>>>>>>> * >>>>>>>>>> >>>>>>>>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>>>>>>>> >>>>>>>>>> if (UseSafefetchStub) {**** >>>>>>>>>> >>>>>>>>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet >>>>>>>>>> generated");*** >>>>>>>>>> * >>>>>>>>>> >>>>>>>>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>>>>>>>> >>>>>>>>>> } else {**** >>>>>>>>>> >>>>>>>>>> pd_SafeFetch32(adr, errValue);**** >>>>>>>>>> >>>>>>>>>> }**** >>>>>>>>>> >>>>>>>>>> }**** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> Unfortunately this requires **** >>>>>>>>>> >>>>>>>>>> 1) setting the flag on all platforms**** >>>>>>>>>> >>>>>>>>>> 2) renaming the safefetch function on all platfoms.**** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> Actually I would prefer this second solution as it avoids the >>>>>>>>>> preprocessor, **** >>>>>>>>>> >>>>>>>>>> and am happy to edit the sources accordingly if this finds >>>>>>>>>> acceptance.**** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> For the implementation of a safefetch_stub see**** >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>>>>>> **** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> Could I get a review on this change, please?**** >>>>>>>>>> >>>>>>>>>> ** ** >>>>>>>>>> >>>>>>>>>> Thanks,**** >>>>>>>>>> >>>>>>>>>> Goetz.**** >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> From vladimir.kozlov at oracle.com Mon Jul 15 10:19:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jul 2013 10:19:39 -0700 Subject: RFR (S): 8020425: Product options incorrectly removed in minor version In-Reply-To: References: <51E06088.3000105@oracle.com> <51E09306.8030002@oracle.com> Message-ID: <51E42F2B.6080508@oracle.com> Thank you, Christian Vladimir On 7/15/13 9:47 AM, Christian Thalinger wrote: > Looks good. -- Chris > > On Jul 12, 2013, at 4:36 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8020425/webrev/ >> >> When run jdk7u40 with flags we removed (6677625) give warning and ignore flags: >> >> java -XX:+UseSpinning -version >> >> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option UseSpinning; support was removed in 7.0_40 >> >> >> Thanks, >> Vladimir >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > From vladimir.kozlov at oracle.com Mon Jul 15 20:21:13 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 16 Jul 2013 03:21:13 +0000 Subject: hg: hsx/hsx24/hotspot: 4 new changesets Message-ID: <20130716032124.2CCBB480D7@hg.openjdk.java.net> Changeset: f82d5b2e8342 Author: kvn Date: 2013-07-12 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f82d5b2e8342 8020215: Different execution plan when using JIT vs interpreter Summary: fix bytecode analyzer Reviewed-by: twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp + test/compiler/EscapeAnalysis/Test8020215.java Changeset: 389886a6de6d Author: kvn Date: 2013-07-12 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/389886a6de6d 8007898: Incorrect optimization of Memory Barriers in Matcher::post_store_load_barrier() Summary: generate one "fat" membar instead of set of barriers for volitile store Reviewed-by: roland ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/membars/DekkerTest.java Changeset: 02b3bea9d79c Author: kvn Date: 2013-07-15 10:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/02b3bea9d79c 8020433: Crash when using -XX:+RestoreMXCSROnJNICalls Summary: remove StubRoutines::x86::_mxcsr_std and use StubRoutines::_mxcsr_std Reviewed-by: jrose ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp + test/compiler/cpuflags/RestoreMXCSR.java Changeset: 097c49f39521 Author: kvn Date: 2013-07-15 15:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/097c49f39521 8020425: Product options incorrectly removed in minor version Summary: give warning and ignore product flags which were removed in hs24 Reviewed-by: twisti ! src/share/vm/runtime/arguments.cpp From joseph.provino at oracle.com Tue Jul 16 07:00:47 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 16 Jul 2013 10:00:47 -0400 Subject: Request for review: JDK-8011569 ARM: avoid native stack walking In-Reply-To: <51D48F22.3030600@oracle.com> References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> <51D4812D.4000504@oracle.com> <51D4864D.6030200@oracle.com> <51D48F22.3030600@oracle.com> Message-ID: <51E5520F.4060905@oracle.com> The latest webrev is here: http://cr.openjdk.java.net/~jprovino/8011569/webrev.00/ David Holmes already approved these changes when the review request was for 8017473. thanks. joe On 7/3/2013 4:52 PM, Joseph Provino wrote: > It's even more confusing now! ;-) > > https://jbs.oracle.com/bugs/browse/JDK-8017473 turns out to be a > duplicate of > > https://jbs.oracle.com/bugs/browse/JDK-8011569 > > I closed 8017473 as a duplicate and will make a webrev for 8011569 > then backport to 7u. > > More comments below as to what to do. > > On 7/3/2013 4:15 PM, Vladimir Kozlov wrote: >> Thank you for explaining situation, it was confusing. >> >> Since you are going to backport it into 7u40 the fix should be simple >> and targeted. For me the suggestion to use new >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED to fix this 8017473. >> >> As you said NMT is nothing to do with this. So using >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED instead of >> PLATFORM_NMT_DETAIL_SUPPORTED is also questionable. > > I'm not sure what you would like. It is okay to change > PLATFORM_NMT_DETAIL_SUPPORTED to > PLATFORM_NATIVE_STACK_WALKING_SUPPORTED for this bug fix? I think > this would be the easiest > way to clean it up. If you have another way you'd rather see it done, > let me know. > >> Why you use "PLATFORM_" prefix in names? > > That's a good question. I thought there were other names like that > but I don't see any now. > NATIVE_STACK_WALKING_SUPPORTED seems better but perhaps because it's > platform specific > maybe it's okay as is? I don't feel strongly either way... > > thanks. > > joe > >> >> Thanks, >> Vladimir >> >> On 7/3/13 12:53 PM, Joseph Provino wrote: >>> On 07/03/2013 03:27 PM, Vladimir Kozlov wrote: >>>> I don't like to have renaming done together with the fix. Is renaming >>>> required? >>>> >>>> Thanks, >>>> Vladimir >>> >>> Renaming isn't required but if I keep PLATFORM_NMT_DETAIL_SUPPORTED >>> I would need to add the new flag >>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED. >>> >>> I could use PLATFORM_NMT_DETAIL_SUPPORTED but NMT doesn't have anything >>> to do >>> with this bug 8017473. >>> >>> What happened is that 8011064 got reported and fixed first. The fix was >>> to disallow >>> NMT_detail in some cases so PLATFORM_NMT_DETAIL_SUPPORTED made sense. >>> >>> Bug 8017473 makes it clear that there are times when native stack >>> walking can't be done. >>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED is more general and makes >>> sense for >>> 8011064 and 8017473. >>> >>> Do you think it would be better to use a new name and then file another >>> bug to change >>> PLATFORM_NMT_DETAIL_SUPPORTED to >>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED? >>> >>> joe >>> >>>> >>>> On 7/3/13 12:10 PM, Joseph Provino wrote: >>>>> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 >>>>> >>>>> This is for SE_8 but will be backported to 7u. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ >>>>> >>>>> >>>>> I changed PLATFORM_NMT_DETAIL_SUPPORTED to >>>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED >>>>> to make the name more general. >>>>> >>>>> Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make >>>>> because >>>>> with the low optimization for debug builds, >>>>> -fno-omit-frame-pointer is >>>>> set and stack walking >>>>> is always permissible. >>>>> >>>>> Changed vm.make to optionally include an architecture specific >>>>> makefile >>>>> in case some files >>>>> need to be compiled with special options such as >>>>> -fno-omit-frame-pointer. >>>>> >>>>> Thanks. >>>>> >>>>> joe >>> > From zhengyu.gu at oracle.com Tue Jul 16 07:24:19 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 16 Jul 2013 10:24:19 -0400 Subject: Request for review: JDK-8011569 ARM: avoid native stack walking In-Reply-To: <51E5520F.4060905@oracle.com> References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> <51D4812D.4000504@oracle.com> <51D4864D.6030200@oracle.com> <51D48F22.3030600@oracle.com> <51E5520F.4060905@oracle.com> Message-ID: Good to me. -Zhengyu On Jul 16, 2013, at 10:00 AM, Joseph Provino wrote: > The latest webrev is here: http://cr.openjdk.java.net/~jprovino/8011569/webrev.00/ > > David Holmes already approved these changes when the review request was for 8017473. > > thanks. > > joe > > > On 7/3/2013 4:52 PM, Joseph Provino wrote: >> It's even more confusing now! ;-) >> >> https://jbs.oracle.com/bugs/browse/JDK-8017473 turns out to be a duplicate of >> >> https://jbs.oracle.com/bugs/browse/JDK-8011569 >> >> I closed 8017473 as a duplicate and will make a webrev for 8011569 >> then backport to 7u. >> >> More comments below as to what to do. >> >> On 7/3/2013 4:15 PM, Vladimir Kozlov wrote: >>> Thank you for explaining situation, it was confusing. >>> >>> Since you are going to backport it into 7u40 the fix should be simple and targeted. For me the suggestion to use new PLATFORM_NATIVE_STACK_WALKING_SUPPORTED to fix this 8017473. >>> >>> As you said NMT is nothing to do with this. So using PLATFORM_NATIVE_STACK_WALKING_SUPPORTED instead of PLATFORM_NMT_DETAIL_SUPPORTED is also questionable. >> >> I'm not sure what you would like. It is okay to change PLATFORM_NMT_DETAIL_SUPPORTED to >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED for this bug fix? I think this would be the easiest >> way to clean it up. If you have another way you'd rather see it done, let me know. >> >>> Why you use "PLATFORM_" prefix in names? >> >> That's a good question. I thought there were other names like that but I don't see any now. >> NATIVE_STACK_WALKING_SUPPORTED seems better but perhaps because it's platform specific >> maybe it's okay as is? I don't feel strongly either way... >> >> thanks. >> >> joe >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/3/13 12:53 PM, Joseph Provino wrote: >>>> On 07/03/2013 03:27 PM, Vladimir Kozlov wrote: >>>>> I don't like to have renaming done together with the fix. Is renaming >>>>> required? >>>>> >>>>> Thanks, >>>>> Vladimir >>>> >>>> Renaming isn't required but if I keep PLATFORM_NMT_DETAIL_SUPPORTED >>>> I would need to add the new flag PLATFORM_NATIVE_STACK_WALKING_SUPPORTED. >>>> >>>> I could use PLATFORM_NMT_DETAIL_SUPPORTED but NMT doesn't have anything >>>> to do >>>> with this bug 8017473. >>>> >>>> What happened is that 8011064 got reported and fixed first. The fix was >>>> to disallow >>>> NMT_detail in some cases so PLATFORM_NMT_DETAIL_SUPPORTED made sense. >>>> >>>> Bug 8017473 makes it clear that there are times when native stack >>>> walking can't be done. >>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED is more general and makes sense for >>>> 8011064 and 8017473. >>>> >>>> Do you think it would be better to use a new name and then file another >>>> bug to change >>>> PLATFORM_NMT_DETAIL_SUPPORTED to PLATFORM_NATIVE_STACK_WALKING_SUPPORTED? >>>> >>>> joe >>>> >>>>> >>>>> On 7/3/13 12:10 PM, Joseph Provino wrote: >>>>>> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 >>>>>> >>>>>> This is for SE_8 but will be backported to 7u. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ >>>>>> >>>>>> >>>>>> I changed PLATFORM_NMT_DETAIL_SUPPORTED to >>>>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED >>>>>> to make the name more general. >>>>>> >>>>>> Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make >>>>>> because >>>>>> with the low optimization for debug builds, -fno-omit-frame-pointer is >>>>>> set and stack walking >>>>>> is always permissible. >>>>>> >>>>>> Changed vm.make to optionally include an architecture specific makefile >>>>>> in case some files >>>>>> need to be compiled with special options such as >>>>>> -fno-omit-frame-pointer. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> joe >>>> >> > From joseph.provino at oracle.com Tue Jul 16 08:24:47 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 16 Jul 2013 11:24:47 -0400 Subject: 7u40 Request for review: JDK-8011569 ARM: avoid native stack walking In-Reply-To: References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> <51D4812D.4000504@oracle.com> <51D4864D.6030200@oracle.com> <51D48F22.3030600@oracle.com> <51E5520F.4060905@oracle.com> Message-ID: <51E565BF.9070904@oracle.com> These are the same changes to 8 that need to be backported to 7u. webrev is here:http://cr.openjdk.java.net/~jprovino/8011569/webrev.7u40.00/ Thanks. joe From bill.pittore at oracle.com Tue Jul 16 09:01:44 2013 From: bill.pittore at oracle.com (bill.pittore at oracle.com) Date: Tue, 16 Jul 2013 12:01:44 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D5A5CD.2070805@oracle.com> References: <51D494E9.2020200@oracle.com> <51D5A5CD.2070805@oracle.com> Message-ID: <51E56E68.8010305@oracle.com> I updated the text in VirtualMachine.java. The new webrev is here: http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ I ran it through javadoc and you can see the result here: http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html Let me know if you have any comments. thanks, bill On 7/4/2013 12:41 PM, Alan Bateman wrote: > On 03/07/2013 22:17, BILL PITTORE wrote: >> These changes address bug 8014135 which adds support for statically >> linked agents in the VM. This is a followup to the recent JNI spec >> changes that addressed statically linked JNI libraries( 8005716). >> The JEP for this change is the same JEP as the JNI changes: >> http://openjdk.java.net/jeps/178 >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > > I looked at the javadoc updates to the attach API. > > One thing that doesn't come across very clearly is the mapping from > the agentLibrary parameter to "agent-lib-name". I think that needs a > few words so that it's clear that it is not literally looking for > "Agent_OnAttach_agent-lib-name" but rather "Agent_OnAttach" + > where is the library name in the > agentLibrary parameter. > > As I recall, the JVM Tool Interface is supposed to be referred so as > "JVM TI" rather than "JVMTI". > > Otherwise it looks okay to me. > > -Alan > > > > From vladimir.kozlov at oracle.com Tue Jul 16 09:16:22 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Jul 2013 09:16:22 -0700 Subject: Request for review: JDK-8011569 ARM: avoid native stack walking In-Reply-To: <51E5520F.4060905@oracle.com> References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> <51D4812D.4000504@oracle.com> <51D4864D.6030200@oracle.com> <51D48F22.3030600@oracle.com> <51E5520F.4060905@oracle.com> Message-ID: <51E571D6.9040905@oracle.com> I still have reservation about having PLATFORM_ prefix which, I think, don't provide any additional information. But I leave it up to you. In general changes are good. Thanks, Vladimir On 7/16/13 7:00 AM, Joseph Provino wrote: > The latest webrev is here: http://cr.openjdk.java.net/~jprovino/8011569/webrev.00/ > > > David Holmes already approved these changes when the review request was for 8017473. > > thanks. > > joe > > > On 7/3/2013 4:52 PM, Joseph Provino wrote: >> It's even more confusing now! ;-) >> >> https://jbs.oracle.com/bugs/browse/JDK-8017473 turns out to be a duplicate of >> >> https://jbs.oracle.com/bugs/browse/JDK-8011569 >> >> I closed 8017473 as a duplicate and will make a webrev for 8011569 >> then backport to 7u. >> >> More comments below as to what to do. >> >> On 7/3/2013 4:15 PM, Vladimir Kozlov wrote: >>> Thank you for explaining situation, it was confusing. >>> >>> Since you are going to backport it into 7u40 the fix should be simple and targeted. For me the suggestion to use new >>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED to fix this 8017473. >>> >>> As you said NMT is nothing to do with this. So using PLATFORM_NATIVE_STACK_WALKING_SUPPORTED instead of >>> PLATFORM_NMT_DETAIL_SUPPORTED is also questionable. >> >> I'm not sure what you would like. It is okay to change PLATFORM_NMT_DETAIL_SUPPORTED to >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED for this bug fix? I think this would be the easiest >> way to clean it up. If you have another way you'd rather see it done, let me know. >> >>> Why you use "PLATFORM_" prefix in names? >> >> That's a good question. I thought there were other names like that but I don't see any now. >> NATIVE_STACK_WALKING_SUPPORTED seems better but perhaps because it's platform specific >> maybe it's okay as is? I don't feel strongly either way... >> >> thanks. >> >> joe >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/3/13 12:53 PM, Joseph Provino wrote: >>>> On 07/03/2013 03:27 PM, Vladimir Kozlov wrote: >>>>> I don't like to have renaming done together with the fix. Is renaming >>>>> required? >>>>> >>>>> Thanks, >>>>> Vladimir >>>> >>>> Renaming isn't required but if I keep PLATFORM_NMT_DETAIL_SUPPORTED >>>> I would need to add the new flag PLATFORM_NATIVE_STACK_WALKING_SUPPORTED. >>>> >>>> I could use PLATFORM_NMT_DETAIL_SUPPORTED but NMT doesn't have anything >>>> to do >>>> with this bug 8017473. >>>> >>>> What happened is that 8011064 got reported and fixed first. The fix was >>>> to disallow >>>> NMT_detail in some cases so PLATFORM_NMT_DETAIL_SUPPORTED made sense. >>>> >>>> Bug 8017473 makes it clear that there are times when native stack >>>> walking can't be done. >>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED is more general and makes sense for >>>> 8011064 and 8017473. >>>> >>>> Do you think it would be better to use a new name and then file another >>>> bug to change >>>> PLATFORM_NMT_DETAIL_SUPPORTED to PLATFORM_NATIVE_STACK_WALKING_SUPPORTED? >>>> >>>> joe >>>> >>>>> >>>>> On 7/3/13 12:10 PM, Joseph Provino wrote: >>>>>> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 >>>>>> >>>>>> This is for SE_8 but will be backported to 7u. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ >>>>>> >>>>>> >>>>>> I changed PLATFORM_NMT_DETAIL_SUPPORTED to >>>>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED >>>>>> to make the name more general. >>>>>> >>>>>> Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make >>>>>> because >>>>>> with the low optimization for debug builds, -fno-omit-frame-pointer is >>>>>> set and stack walking >>>>>> is always permissible. >>>>>> >>>>>> Changed vm.make to optionally include an architecture specific makefile >>>>>> in case some files >>>>>> need to be compiled with special options such as >>>>>> -fno-omit-frame-pointer. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> joe >>>> >> > From vladimir.kozlov at oracle.com Tue Jul 16 09:17:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Jul 2013 09:17:40 -0700 Subject: 7u40 Request for review: JDK-8011569 ARM: avoid native stack walking In-Reply-To: <51E565BF.9070904@oracle.com> References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> <51D4812D.4000504@oracle.com> <51D4864D.6030200@oracle.com> <51D48F22.3030600@oracle.com> <51E5520F.4060905@oracle.com> <51E565BF.9070904@oracle.com> Message-ID: <51E57224.3020900@oracle.com> Good (with the same comment as for hs25). Thanks, Vladimir On 7/16/13 8:24 AM, Joseph Provino wrote: > These are the same changes to 8 that need to be backported to 7u. > > webrev is here:http://cr.openjdk.java.net/~jprovino/8011569/webrev.7u40.00/ > > > Thanks. > > joe From dalibor.topic at oracle.com Tue Jul 16 09:52:28 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 16 Jul 2013 18:52:28 +0200 Subject: LLVM 2.9 / OpenJDK 7 / ZERO and SHARK available build. In-Reply-To: <2b51dc9393a1b0f2dbc217f2484a987b@tweb02.nm.nhnsystem.com> References: <2b51dc9393a1b0f2dbc217f2484a987b@tweb02.nm.nhnsystem.com> Message-ID: <51E57A4C.3040503@oracle.com> On 7/15/13 10:12 AM, Min Seong Kim wrote: > anyone who knows build ZERO and SHARK compiler with OpenJDK7?? Please subscribe to the zero-dev mailing list and ask again there. cheers, dalibor topic -- 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 volker.simonis at gmail.com Tue Jul 16 10:21:58 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 16 Jul 2013 19:21:58 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <51D3065C.6090401@oracle.com> References: <51D3065C.6090401@oracle.com> Message-ID: Hi Stefan, this is a very interesting change! Although I haven?t had a chance to dig trough the whole change and test it, I want to make a few comments beforehand: I think this change will help to make 'UseHugeTLBFS' work on Linux/PPC64. The problem with the current strategy on PPC64 is that on PPC64 we have different memory slices (256M slices below 4G, then 4G slices below 1TB and finally 1TB slices above that) and each slice supports only one page size (I got this information from Tiago St?rmer Daitx from the IBM Linux Technology Center: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-April/000445.html). So with the old strategy, the first mmap(MAP_NORESERVE) ends up in a memory slice with small pages and the subsequent mmap(MAP_FIXED,MAP_HUGETLB) will fail because the reserved memory is already located in a slice with small pages only. So I think your change where the large pages are committed upfront will solve this problem (though I haven?t tired until now). Currently, Linux/PPC64 doesn't support transparent huge pages, but there seems to be a new implementation in the upcoming Linux Kernel 3.11 (see: http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/01916.html). I'm wondering how this can work with the 'memory slicing' mentioned before but that's another question which I'll try to find out from the IBM colleagues. I've also collected all kinds of information regarding LargePages/mmap/etc on Linux which I'd like to put in the HotSpot Wiki. I'd also like to add the explanations from your mail. Would it be OK for you if I'd create a new page (i.e. under HotSpot->Runtime->LargePageSupport) where we could collect this information? How did you test transparent huge page support and did you compare it with the old UseHugeTLBFS? I wonder how transparent huge page support works in the real world, because madvise is after all only an advise. The result depends on the kernel settings (/sys/kernel/mm/transparent_hugepage/) as well as on the fact how well the 'khugepaged' works. If I read the transparent huge page documentation (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/vm/transhuge.txt) it seems to me that there are still a lot of tuning paramters. I agree that the general usage is easier compared to 'UseHugeTLBFS' but on the other hand, once UseHugeTLBFS succeeds we have the huge pages forever. And finally, are these changes really intended for hs24 as denoted in the subject? Then I don't understand your comment that "Unfortunately, it's not likely that we'll get this into the hs24 release." Thank you and best regards, Volker PS: by the way, where did you get the information from that a failing "mmap(addr, size, ... MAP_FIXED|MAP_HUGETLB ...)" will remove the previous mapping? I couldn't find t hat anywhere. (I think this may also be one of the reasons why we sometimes loose the guard page protection for a thread. We thought we fixed that problem ("7107135 : Stack guard pages are no more protected after loading a shared library with executable stack", http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107135) but maybe we only fixed one reason? What if a thread places it's stack into the area of the removed mapping and afterwards, when the memory is mmaped with small pages, the guard pages of the thread will become read/write permissions.) On Tue, Jul 2, 2013 at 6:57 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8007074/webrev.00/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007074 > > The default way of using Large Pages in HotSpot on Linux (UseHugeTLBFS) is > broken. This is causing a number of crashes in different subsystems of the > JVM. > > > Bug Description > =============== > > The main reason for this bug is that mmap(addr, size, ... > MAP_FIXED|MAP_HUGETLB ...) will remove the previous mapping at [addr, > addr+size) when we run out of large pages on Linux. > > This affects different parts of the JVM, but the most obvious is the > allocation of the Java heap: > > When the JVM starts it reserves a memory area for the entire Java heap. We > use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk of memory that > no other > subsystem of the JVM, or Java program, will be allowed to mmap into. > > The reservation of the memory only reflects the maximum possible heap size, > but often a smaller heap size is used if the memory pressure is low. The > part of > the heap that is actually used is committed with mmap(...MAP_FIXED...). When > the heap is growing we commit a consecutive chunk of memory after the > previously committed memory. We rely on the fact that no other thread will > mmap into the reserved memory area for the Java heap. > > The actual committing of the memory is done by first trying to allocate > large pages with mmap(...MAP_FIXED|MAP_HUGETLB...), and if that fails we > call mmap with the same parameters but without the large pages flag > (MAP_HUGETLB). > > Just after we have failed to mmap large pages and before the small pages > have been mmapped, there's an unmapped memory region in the middle of the > Java heap, where other threads might mmap into. When that happens we get > memory trashing and crashes. > > > Large Pages in HotSpot - on Linux > ================================= > > Currently, before the bug fix, HotSpot supports three ways of allocating > large pages on Linux. > 1) -XX:+UseSHM - Commits the large pages upfront when the memory is > reserved. > > 2) -XX:+UseHugeTLBFS - This is the broken implementation. It's also the > default way large pages are allocated. If the OS is correctly configured, we > get these kind of large pages for three different reasons: > 2.1) The user has not specified any large pages flags > 2.2) The user has specified -XX:+UseLargePages > 2.3) The user has specified -XX:+UseHugeTLBFS > > 3) Transparent Huge Pages - is supported on recent Linux Kernels. The user > can choose to configure the OS to: > 3.1) completely handle the allocation of large pages, or > 3.2) let the JVM advise where it would be good to allocate large pages. > There exist code for this today, that is guarded by the (2) > -XX:+UseHugeTLBFS flag. > > > The Proposed Patch > ================== > > 4) Create a new flag -XX:+UseTransparentHugePages, and move the transparent > huge pages advise in (3.2) out from the (2) -XX:+UseHugeTLBFS code. > > 5) Make -XX:+UseTransparentHugePages the default way to allocate large pages > if the OS supports them. It will be the only kind of large pages we'll use > if the user has not specified any large pages flags. > > 6) Change the order of how we choose the kind of large pages when > -XX:+UseLargePages has been specified. It used to be UseHugeTLBFS then > UseSHM, now it's UseTransparentHugePages, then UseHugeTLBFS, then UseSHM. > > 7) Implement a workaround fix for the (2) -XX:+UseHugeTLBFS implementation. > With the fix the large pages are committed upfront when they are reserved. > It's mostly the same way we do it for the older (1) -XX:+UseSHM large pages. > This change will fix the bug, but has a couple of drawbacks: > 7.1) We have to allocate the entire large pages memory area when it is > reserved instead of when parts of it are committed. > 7.2) We can't dynamically shrink or grow the used memory in the large pages > areas. > If these restrictions are not suitable for the user, then (3) > -XX:+UseTransparentHugePages could be used instead. > > 8) Ignore -XX:LargePageSizeInBytes on Linux since the OS doesn't support > multiple large page sizes and both the old code and new code is broken if > the user is allowed to set it to some other value then the OS chosen value. > Warn if the user specifies a value different than the OS default value. > > > Testing > ======= > > New unit tests have been added. These can be run in a non-product build > with: > java -XX:+ExecuteInternalVMTests -XX:+VerboseInternalVMTests flags> -version > > unit tests: with and without large pages on Linux, Windows, Solaris, x86, > x64, sparcv9. > jprt: default > jprt: -XX:+UseLargePages > jprt: -XX:+UseLargePages -XX:-UseCompressedOops > vm.quick.testlist, vm.pcl.testlist, vm.gc.testlist: multiple platforms, with > large pages on all major GCs with and without compressed oops. > SPECjbb2005 performance runs: on Linux x64 with -XX:+UseHugeTLBFS before and > after the patch. > Kitchensink: 3 days on Linux x64 > > > thanks, > StefanK From bob.vandette at oracle.com Tue Jul 16 14:44:31 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 16 Jul 2013 17:44:31 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51DDB632.4050805@oracle.com> References: <51D494E9.2020200@oracle.com> <51DDB632.4050805@oracle.com> Message-ID: <0F64EB55-B38C-416E-93D1-92BA8F5D43C7@oracle.com> Thanks for the suggestion Jeremy but the JVMTI agent change is being implemented as part of the original JNI static library implementation where we explicitly prohibited dynamic libraries to be loaded if a static library of the same name is baked into the launcher. "If a library L is statically linked then it will be prohibited to link a library of the same name dynamically." The primary motivation for requiring this for the -agentpath as well as the java.lang.System.load API is to minimize changes to java source code. You can statically or dynamically link a library without changing any of the code that attempts to use the library. The only thing that changes is the OnLoad name in the library and the link options. If you'd like to optionally use different implementations, you can end up with the same behavior by using a System property which alters the String of the name of the library. Bob. On Jul 10, 2013, at 3:29 PM, BILL PITTORE wrote: > On 7/3/2013 6:32 PM, Jeremy Manson wrote: >> I know that this is mentioned in the JEP, but does it really make sense to have -agentpath work here, rather than just -agentlib? I would think that specifying a full pathname and getting the library loaded out of the launcher would be a little surprising to people who are basically saying "please load this agent from the given path". >> >> Also, in practice, we do something very similar at Google, and, when testing, I find it occasionally useful to be able to say "please load this agent on the command line via the agentpath I gave you, rather than loading the one with the same name I baked into the launcher". >> >> (FWIW, when we did this internally at Google, we added a special -XX flag for when the agent is in the launcher. I know that you don't want to go that way, though.) >> > Thanks for the comments. I would say the thinking here is that we want this to be as transparent as possible to the end user. In our view of the end user is someone perhaps using an IDE and the actual execution of the VM with agent arguments is hidden. In your case it sounds like you are actually developing agents which is a whole different ball game. I could certainly see adding a -XX argument that forces agentpath to load the external library which would be good for agent development and debugging. No need to relink the entire VM with the new agent. Our tech lead is out on vacation this week so I'll bring this up when he's back. > > bill > >> >> On Wed, Jul 3, 2013 at 2:17 PM, BILL PITTORE > wrote: >> >> These changes address bug 8014135 which adds support for >> statically linked agents in the VM. This is a followup to the >> recent JNI spec changes that addressed statically linked JNI >> libraries( 8005716). >> The JEP for this change is the same JEP as the JNI changes: >> http://openjdk.java.net/jeps/178 >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >> >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >> >> >> The changes to jvmti.xml can also be seen in the output file that >> I placed here: >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >> >> >> Thanks, >> bill >> >> >> > From david.holmes at oracle.com Tue Jul 16 17:10:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jul 2013 10:10:04 +1000 Subject: Request for review: JDK-8011569 ARM: avoid native stack walking In-Reply-To: <51E5520F.4060905@oracle.com> References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> <51D4812D.4000504@oracle.com> <51D4864D.6030200@oracle.com> <51D48F22.3030600@oracle.com> <51E5520F.4060905@oracle.com> Message-ID: <51E5E0DC.8010200@oracle.com> For the record - looks good to me. David On 17/07/2013 12:00 AM, Joseph Provino wrote: > The latest webrev is here: > http://cr.openjdk.java.net/~jprovino/8011569/webrev.00/ > > > David Holmes already approved these changes when the review request was > for 8017473. > > thanks. > > joe > > > On 7/3/2013 4:52 PM, Joseph Provino wrote: >> It's even more confusing now! ;-) >> >> https://jbs.oracle.com/bugs/browse/JDK-8017473 turns out to be a >> duplicate of >> >> https://jbs.oracle.com/bugs/browse/JDK-8011569 >> >> I closed 8017473 as a duplicate and will make a webrev for 8011569 >> then backport to 7u. >> >> More comments below as to what to do. >> >> On 7/3/2013 4:15 PM, Vladimir Kozlov wrote: >>> Thank you for explaining situation, it was confusing. >>> >>> Since you are going to backport it into 7u40 the fix should be simple >>> and targeted. For me the suggestion to use new >>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED to fix this 8017473. >>> >>> As you said NMT is nothing to do with this. So using >>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED instead of >>> PLATFORM_NMT_DETAIL_SUPPORTED is also questionable. >> >> I'm not sure what you would like. It is okay to change >> PLATFORM_NMT_DETAIL_SUPPORTED to >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED for this bug fix? I think >> this would be the easiest >> way to clean it up. If you have another way you'd rather see it done, >> let me know. >> >>> Why you use "PLATFORM_" prefix in names? >> >> That's a good question. I thought there were other names like that >> but I don't see any now. >> NATIVE_STACK_WALKING_SUPPORTED seems better but perhaps because it's >> platform specific >> maybe it's okay as is? I don't feel strongly either way... >> >> thanks. >> >> joe >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/3/13 12:53 PM, Joseph Provino wrote: >>>> On 07/03/2013 03:27 PM, Vladimir Kozlov wrote: >>>>> I don't like to have renaming done together with the fix. Is renaming >>>>> required? >>>>> >>>>> Thanks, >>>>> Vladimir >>>> >>>> Renaming isn't required but if I keep PLATFORM_NMT_DETAIL_SUPPORTED >>>> I would need to add the new flag >>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED. >>>> >>>> I could use PLATFORM_NMT_DETAIL_SUPPORTED but NMT doesn't have anything >>>> to do >>>> with this bug 8017473. >>>> >>>> What happened is that 8011064 got reported and fixed first. The fix was >>>> to disallow >>>> NMT_detail in some cases so PLATFORM_NMT_DETAIL_SUPPORTED made sense. >>>> >>>> Bug 8017473 makes it clear that there are times when native stack >>>> walking can't be done. >>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED is more general and makes >>>> sense for >>>> 8011064 and 8017473. >>>> >>>> Do you think it would be better to use a new name and then file another >>>> bug to change >>>> PLATFORM_NMT_DETAIL_SUPPORTED to >>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED? >>>> >>>> joe >>>> >>>>> >>>>> On 7/3/13 12:10 PM, Joseph Provino wrote: >>>>>> Bug report: https://jbs.oracle.com/bugs/browse/JDK-8017473 >>>>>> >>>>>> This is for SE_8 but will be backported to 7u. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jprovino/8017473/webrev.00/ >>>>>> >>>>>> >>>>>> I changed PLATFORM_NMT_DETAIL_SUPPORTED to >>>>>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED >>>>>> to make the name more general. >>>>>> >>>>>> Added -DPLATFORM_NMT_DETAIL_SUPPORTED=1 to linux/makefiles/debug.make >>>>>> because >>>>>> with the low optimization for debug builds, >>>>>> -fno-omit-frame-pointer is >>>>>> set and stack walking >>>>>> is always permissible. >>>>>> >>>>>> Changed vm.make to optionally include an architecture specific >>>>>> makefile >>>>>> in case some files >>>>>> need to be compiled with special options such as >>>>>> -fno-omit-frame-pointer. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> joe >>>> >> > From david.holmes at oracle.com Tue Jul 16 17:13:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jul 2013 10:13:05 +1000 Subject: 7u40 Request for review: JDK-8011569 ARM: avoid native stack walking In-Reply-To: <51E565BF.9070904@oracle.com> References: <51D47730.4020303@oracle.com> <51D47B3A.4090003@oracle.com> <51D4812D.4000504@oracle.com> <51D4864D.6030200@oracle.com> <51D48F22.3030600@oracle.com> <51E5520F.4060905@oracle.com> <51E565BF.9070904@oracle.com> Message-ID: <51E5E191.2050602@oracle.com> Good. David On 17/07/2013 1:24 AM, Joseph Provino wrote: > These are the same changes to 8 that need to be backported to 7u. > > webrev is > here:http://cr.openjdk.java.net/~jprovino/8011569/webrev.7u40.00/ > > > Thanks. > > joe From mikael.gerdin at oracle.com Wed Jul 17 03:50:13 2013 From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com) Date: Wed, 17 Jul 2013 10:50:13 +0000 Subject: hg: hsx/hsx24/hotspot: 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Message-ID: <20130717105018.251EB4813F@hg.openjdk.java.net> Changeset: 370cbb35dbca Author: allwin Date: 2013-07-17 10:52 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/370cbb35dbca 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Reviewed-by: dcubed, dholmes, sspitsyn, mgerdin, ctornqvi, dsamersoff ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/windows/vm/attachListener_windows.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.hpp + test/serviceability/attach/AttachWithStalePidFile.java + test/serviceability/attach/AttachWithStalePidFileTarget.java + test/testlibrary/com/oracle/java/testlibrary/Platform.java From gnu.andrew at redhat.com Wed Jul 17 07:20:39 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 17 Jul 2013 10:20:39 -0400 (EDT) Subject: Use of CC_COMPILE and CXX_COMPILE In-Reply-To: <1973993517.1917219.1374070600918.JavaMail.root@redhat.com> Message-ID: <1153575394.1920424.1374070839653.JavaMail.root@redhat.com> In the Solaris, *BSD and GNU/Linux makefiles, it states: "# $(CC) is the c compiler (cc/gcc), $(CXX) is the c++ compiler (CC/g++)." (make/{solaris,bsd,linux}/makefiles/rules.make) However, both CC_COMPILE and CXX_COMPILE are then defined in the same way. CC_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) CXX_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) Shouldn't CXXFLAGS only be added to CXX_COMPILE and not CC_COMPILE? It also appears that C++ flags are being added to $(CFLAGS): make/solaris/makefiles/gcc.make:CFLAGS += -fcheck-new make/bsd/makefiles/gcc.make:CFLAGS += -fcheck-new make/linux/makefiles/gcc.make:CFLAGS += -fcheck-new We hit this when trying to build some C code (mkbc.c for our ARM32 port) using $(CC_COMPILE). Has $(CC_COMPILE) ever been used with C code? Is there any in HotSpot itself? 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 mikael.gerdin at oracle.com Wed Jul 17 07:33:43 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 17 Jul 2013 16:33:43 +0200 Subject: Use of CC_COMPILE and CXX_COMPILE In-Reply-To: <1153575394.1920424.1374070839653.JavaMail.root@redhat.com> References: <1153575394.1920424.1374070839653.JavaMail.root@redhat.com> Message-ID: <51E6AB47.5060000@oracle.com> On 2013-07-17 16:20, Andrew Hughes wrote: > In the Solaris, *BSD and GNU/Linux makefiles, it states: > > "# $(CC) is the c compiler (cc/gcc), $(CXX) is the c++ compiler (CC/g++)." > > (make/{solaris,bsd,linux}/makefiles/rules.make) > > However, both CC_COMPILE and CXX_COMPILE are then defined in the same way. > > CC_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) > CXX_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) > > Shouldn't CXXFLAGS only be added to CXX_COMPILE and not CC_COMPILE? > > It also appears that C++ flags are being added to $(CFLAGS): > > make/solaris/makefiles/gcc.make:CFLAGS += -fcheck-new > make/bsd/makefiles/gcc.make:CFLAGS += -fcheck-new > make/linux/makefiles/gcc.make:CFLAGS += -fcheck-new > > We hit this when trying to build some C code (mkbc.c for our ARM32 port) > using $(CC_COMPILE). Has $(CC_COMPILE) ever been used with C code? > Is there any in HotSpot itself? There is jsig.c, see make//makefiles/jsig.make It seems like jsig.make avoids using $(CC_COMPILE) and selects its own set of compiler flags, possibly because it's compiled and linked into its own .so all at once. I can't find any references to CC_COMPILE or its derived COMPILE.CC, GENASM.CC and PREPROCESS.CC in the sources so changing it seems safe enough. /Mikael > > Thanks, > From goetz.lindenmaier at sap.com Wed Jul 17 08:13:34 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 17 Jul 2013 15:13:34 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF5F1E@DEWDFEMB12A.global.corp.sap> Hi, This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for the PPC64 interpreter port on linux. With this change you can do a core build on ppc64 and run the VM interpreter only. It executes simple programs as jvm98. The change requires * 8016697: Use stubs to implement safefetch * 8020059: The flag introduced by 8014972 is not defined ... which will arrive soon in the staging repository. I marked the change as XL as it contains a lot of code. Nevertheless the code has no impact on the existing Oracle platforms. The change touches a single shared file, globals.hpp, removing a special case introduced for the port. This is because we integrated some changes earlier than originally intended. Please review the change. Does it need testing on Oracle side? Best regards, Goetz. From goetz.lindenmaier at sap.com Wed Jul 17 08:34:49 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 17 Jul 2013 15:34:49 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> Hi, This time with webrev. Sorry for the double mails. This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for the PPC64 interpreter port on linux. With this change you can do a core build on ppc64 and run the VM interpreter only. It executes simple programs as jvm98. The change requires * 8016697: Use stubs to implement safefetch * 8020059: The flag introduced by 8014972 is not defined ... which will arrive soon in the staging repository. I marked the change as XL as it contains a lot of code. Nevertheless the code has no impact on the existing Oracle platforms. The change touches a single shared file, globals.hpp, removing a special case introduced for the port. This is because we integrated some changes earlier than originally intended. Please review the change. Does it need testing on Oracle side? http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ Best regards, Goetz. From rickard.backman at oracle.com Wed Jul 17 09:03:48 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Wed, 17 Jul 2013 16:03:48 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130717160355.8554A48157@hg.openjdk.java.net> Changeset: fc4660f7922c Author: rbackman Date: 2013-06-12 11:17 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fc4660f7922c 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Reviewed-by: jrose, kvn, mgronlun ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a189e8cd4811 Author: rbackman Date: 2013-07-17 12:54 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a189e8cd4811 Merge ! src/share/vm/runtime/thread.cpp From gnu.andrew at redhat.com Wed Jul 17 09:27:39 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 17 Jul 2013 12:27:39 -0400 (EDT) Subject: Use of CC_COMPILE and CXX_COMPILE In-Reply-To: <51E6AB47.5060000@oracle.com> References: <1153575394.1920424.1374070839653.JavaMail.root@redhat.com> <51E6AB47.5060000@oracle.com> Message-ID: <1995578140.2038433.1374078459935.JavaMail.root@redhat.com> ----- Original Message ----- > > > On 2013-07-17 16:20, Andrew Hughes wrote: > > In the Solaris, *BSD and GNU/Linux makefiles, it states: > > > > "# $(CC) is the c compiler (cc/gcc), $(CXX) is the c++ compiler (CC/g++)." > > > > (make/{solaris,bsd,linux}/makefiles/rules.make) > > > > However, both CC_COMPILE and CXX_COMPILE are then defined in the same way. > > > > CC_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) > > CXX_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) > > > > Shouldn't CXXFLAGS only be added to CXX_COMPILE and not CC_COMPILE? > > > > It also appears that C++ flags are being added to $(CFLAGS): > > > > make/solaris/makefiles/gcc.make:CFLAGS += -fcheck-new > > make/bsd/makefiles/gcc.make:CFLAGS += -fcheck-new > > make/linux/makefiles/gcc.make:CFLAGS += -fcheck-new > > > > We hit this when trying to build some C code (mkbc.c for our ARM32 port) > > using $(CC_COMPILE). Has $(CC_COMPILE) ever been used with C code? > > Is there any in HotSpot itself? > > There is jsig.c, see make//makefiles/jsig.make > And saproc.make. > It seems like jsig.make avoids using $(CC_COMPILE) and selects its own > set of compiler flags, possibly because it's compiled and linked into > its own .so all at once. > > I can't find any references to CC_COMPILE or its derived COMPILE.CC, > GENASM.CC and PREPROCESS.CC in the sources so changing it seems safe enough. Yes, it seems the only place using them locally is the additions for this port, which are misusing them in some cases. The names of the flags are rather confusing; CFLAGS includes both C and C++ flags, while CXXFLAGS is actually C preprocessor flags, as far as I can tell (I would have thought this would be CPPFLAGS). > > /Mikael > > > > > > 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 christian.thalinger at oracle.com Wed Jul 17 10:18:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Jul 2013 10:18:52 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> Message-ID: <209753E8-8645-4847-825E-8632749DD780@oracle.com> One question: why did you choose to prefix all assembler instructions with ppc_? -- Chris On Jul 17, 2013, at 8:34 AM, "Lindenmaier, Goetz" wrote: > Hi, > > This time with webrev. Sorry for the double mails. > > This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for > the PPC64 interpreter port on linux. > > With this change you can do a core build on ppc64 and run the VM interpreter only. > It executes simple programs as jvm98. > The change requires > > * 8016697: Use stubs to implement safefetch > > * 8020059: The flag introduced by 8014972 is not defined ... > which will arrive soon in the staging repository. > > I marked the change as XL as it contains a lot of code. Nevertheless the > code has no impact on the existing Oracle platforms. > > The change touches a single shared file, globals.hpp, removing a > special case introduced for the port. This is because we > integrated some changes earlier than originally intended. > > Please review the change. Does it need testing on Oracle side? > http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Wed Jul 17 11:38:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Jul 2013 11:38:17 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <209753E8-8645-4847-825E-8632749DD780@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <209753E8-8645-4847-825E-8632749DD780@oracle.com> Message-ID: <51E6E499.4000204@oracle.com> On 7/17/13 10:18 AM, Christian Thalinger wrote: > One question: why did you choose to prefix all assembler instructions with ppc_? +1 and PPC_ prefix in registers names. Goetz, it is different from our naming style so we would really appreciate if you change this. Regards, Vladimir > > -- Chris > > On Jul 17, 2013, at 8:34 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> This time with webrev. Sorry for the double mails. >> >> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for >> the PPC64 interpreter port on linux. >> >> With this change you can do a core build on ppc64 and run the VM interpreter only. >> It executes simple programs as jvm98. >> The change requires >> >> * 8016697: Use stubs to implement safefetch >> >> * 8020059: The flag introduced by 8014972 is not defined ... >> which will arrive soon in the staging repository. >> >> I marked the change as XL as it contains a lot of code. Nevertheless the >> code has no impact on the existing Oracle platforms. >> >> The change touches a single shared file, globals.hpp, removing a >> special case introduced for the port. This is because we >> integrated some changes earlier than originally intended. >> >> Please review the change. Does it need testing on Oracle side? >> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >> >> Best regards, >> Goetz. >> > From vladimir.danushevsky at oracle.com Wed Jul 17 11:57:04 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Wed, 17 Jul 2013 18:57:04 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130717185712.B877148161@hg.openjdk.java.net> Changeset: f9b44439e294 Author: jprovino Date: 2013-07-17 11:12 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f9b44439e294 8011569: ARM -- avoid native stack walking Summary: ARM compilers do not emit FramePointer on each native frame by default Reviewed-by: dholmes, kvn ! make/linux/makefiles/vm.make ! src/share/vm/services/memTracker.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4cc0a758a4dc Author: jprovino Date: 2013-07-17 11:16 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4cc0a758a4dc Merge ! src/share/vm/services/memTracker.cpp Changeset: a9e7513d1e09 Author: vladidan Date: 2013-07-17 12:07 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a9e7513d1e09 Merge From vladimir.kozlov at oracle.com Wed Jul 17 13:28:04 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Jul 2013 13:28:04 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51E6E499.4000204@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <209753E8-8645-4847-825E-8632749DD780@oracle.com> <51E6E499.4000204@oracle.com> Message-ID: <51E6FE54.9040501@oracle.com> We have build conflict with Oracle closed sources. The closed build picks files from open ppc64: s/src/cpu/ppc/vm/interp_masm_ppc_64.cpp:297:50: error: 'ppc_li' was not declared in this scope s/src/cpu/ppc/vm/interp_masm_ppc_64.cpp:298:46: error: 'ppc_and' was not declared in this scope We will discuss this internally and will see what we or you should do. Thanks, Vladimir On 7/17/13 11:38 AM, Vladimir Kozlov wrote: > On 7/17/13 10:18 AM, Christian Thalinger wrote: >> One question: why did you choose to prefix all assembler instructions >> with ppc_? > > +1 > > and PPC_ prefix in registers names. > > Goetz, it is different from our naming style so we would really > appreciate if you change this. > > Regards, > Vladimir > >> >> -- Chris >> >> On Jul 17, 2013, at 8:34 AM, "Lindenmaier, Goetz" >> wrote: >> >>> Hi, >>> >>> This time with webrev. Sorry for the double mails. >>> >>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc >>> needed for >>> the PPC64 interpreter port on linux. >>> >>> With this change you can do a core build on ppc64 and run the VM >>> interpreter only. >>> It executes simple programs as jvm98. >>> The change requires >>> >>> * 8016697: Use stubs to implement safefetch >>> >>> * 8020059: The flag introduced by 8014972 is not defined ... >>> which will arrive soon in the staging repository. >>> >>> I marked the change as XL as it contains a lot of code. Nevertheless >>> the >>> code has no impact on the existing Oracle platforms. >>> >>> The change touches a single shared file, globals.hpp, removing a >>> special case introduced for the port. This is because we >>> integrated some changes earlier than originally intended. >>> >>> Please review the change. Does it need testing on Oracle side? >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>> >>> Best regards, >>> Goetz. >>> >> From tao.mao at oracle.com Wed Jul 17 13:52:52 2013 From: tao.mao at oracle.com (tao.mao at oracle.com) Date: Wed, 17 Jul 2013 20:52:52 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20130717205300.1CCC14817B@hg.openjdk.java.net> Changeset: f4311079200c Author: brutisso Date: 2013-07-11 11:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f4311079200c 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer Summary: Take _last_young_gc into account when deciding on starting a concurrent mark. Also reviewed-by: per.liden at oracle.com. Reviewed-by: tschatzl, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: e7a47f226600 Author: tamao Date: 2013-07-15 15:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e7a47f226600 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp From markus.gronlund at oracle.com Wed Jul 17 18:05:50 2013 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Thu, 18 Jul 2013 01:05:50 +0000 Subject: hg: hsx/hsx24/hotspot: 8020547: Event based tracing needs a UNICODE string type Message-ID: <20130718010556.0948C48182@hg.openjdk.java.net> Changeset: aeca24b2a9e5 Author: mgronlun Date: 2013-07-17 23:43 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aeca24b2a9e5 8020547: Event based tracing needs a UNICODE string type Reviewed-by: egahlin, rbackman, dcubed, brutisso, acorn ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/xinclude.mod From eric.mccorkle at oracle.com Wed Jul 17 20:06:50 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 17 Jul 2013 23:06:50 -0400 Subject: Review request for JDK-8019632: Method parameters are not copied in clone_with_new_data Message-ID: <51E75BCA.5030604@oracle.com> Hello, Please review this patch, which updates clone_with_new_data to copy method parameter data. This was missed in the initial implementation. I've gotten a JPRT run that failed only due to running out of memory on some tests, and I'll be doing my usual complete testlist run soon. The webrev is here: http://cr.openjdk.java.net/~emc/8019632/ The bug report is here: http://bugs.sun.com/view_bug.do?bug_id=8019632 Thanks, Eric From david.holmes at oracle.com Thu Jul 18 01:27:58 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 18 Jul 2013 08:27:58 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130718082811.1F43548193@hg.openjdk.java.net> Changeset: 980532a806a5 Author: goetz Date: 2013-06-20 15:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/980532a806a5 8016697: Use stubs to implement safefetch Summary: Implement Safefetch as stub routines. This reduces compiler and os dependencies. Reviewed-by: twisti, kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/bsd_x86_64.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/linux_sparc.s ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/linux_x86_64.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.s ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: a74ec8831c7b Author: clucasius Date: 2013-07-15 12:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a74ec8831c7b Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 16b10327b00d Author: jprovino Date: 2013-07-16 10:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/16b10327b00d 8011569: ARM -- avoid native stack walking Summary: ARM compilers do not emit FramePointer on each native frame by default Reviewed-by: dholmes, zgu ! make/linux/makefiles/vm.make ! src/share/vm/services/memTracker.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 90d6c221d4e5 Author: jprovino Date: 2013-07-16 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/90d6c221d4e5 Merge ! make/linux/makefiles/vm.make - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/services/memTracker.cpp - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9d18d92e54b5 Author: clucasius Date: 2013-07-18 00:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9d18d92e54b5 Merge From david.holmes at oracle.com Thu Jul 18 04:08:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jul 2013 21:08:59 +1000 Subject: Use of CC_COMPILE and CXX_COMPILE In-Reply-To: <1153575394.1920424.1374070839653.JavaMail.root@redhat.com> References: <1153575394.1920424.1374070839653.JavaMail.root@redhat.com> Message-ID: <51E7CCCB.2040502@oracle.com> On 18/07/2013 12:20 AM, Andrew Hughes wrote: > In the Solaris, *BSD and GNU/Linux makefiles, it states: > > "# $(CC) is the c compiler (cc/gcc), $(CXX) is the c++ compiler (CC/g++)." > > (make/{solaris,bsd,linux}/makefiles/rules.make) > > However, both CC_COMPILE and CXX_COMPILE are then defined in the same way. > > CC_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) > CXX_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) > > Shouldn't CXXFLAGS only be added to CXX_COMPILE and not CC_COMPILE? > > It also appears that C++ flags are being added to $(CFLAGS): It is a mess and the mess was compounded by a variable renaming that, it seems, confused CPP with C++ when it looks like it meant the C preprocessor. There are very few actual C compiles, as opposed to C++, and those tend to redefine the compile command as has been noted by others. David ----- > make/solaris/makefiles/gcc.make:CFLAGS += -fcheck-new > make/bsd/makefiles/gcc.make:CFLAGS += -fcheck-new > make/linux/makefiles/gcc.make:CFLAGS += -fcheck-new > > We hit this when trying to build some C code (mkbc.c for our ARM32 port) > using $(CC_COMPILE). Has $(CC_COMPILE) ever been used with C code? > Is there any in HotSpot itself? > > Thanks, > From eric.mccorkle at oracle.com Thu Jul 18 06:38:24 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 18 Jul 2013 09:38:24 -0400 Subject: Review request for JDK-8019632: Method parameters are not copied in clone_with_new_data In-Reply-To: <51E75BCA.5030604@oracle.com> References: <51E75BCA.5030604@oracle.com> Message-ID: <51E7EFD0.906@oracle.com> Realized I'd duplicated a comment. It's been corrected. On 07/17/13 23:06, Eric McCorkle wrote: > Hello, > > Please review this patch, which updates clone_with_new_data to copy > method parameter data. This was missed in the initial implementation. > > I've gotten a JPRT run that failed only due to running out of memory on > some tests, and I'll be doing my usual complete testlist run soon. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8019632/ > > The bug report is here: > http://bugs.sun.com/view_bug.do?bug_id=8019632 > > Thanks, > Eric > From coleen.phillimore at oracle.com Thu Jul 18 08:22:10 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 18 Jul 2013 11:22:10 -0400 Subject: Review request for JDK-8019632: Method parameters are not copied in clone_with_new_data In-Reply-To: <51E7EFD0.906@oracle.com> References: <51E75BCA.5030604@oracle.com> <51E7EFD0.906@oracle.com> Message-ID: <51E80822.3040307@oracle.com> Eric, This code change looks good. For the related bug that didn't copy method annotations, I added test: jdk/test/java/lang/instrument/RedefineMethodWithAnnotations.sh. Can you use this test to write a new one to the JDK that demonstrates this bug? We've been adding these tests to the JDK because it has the support there and all the other tests are there. Thanks, Coleen On 7/18/2013 9:38 AM, Eric McCorkle wrote: > Realized I'd duplicated a comment. It's been corrected. > > On 07/17/13 23:06, Eric McCorkle wrote: >> Hello, >> >> Please review this patch, which updates clone_with_new_data to copy >> method parameter data. This was missed in the initial implementation. >> >> I've gotten a JPRT run that failed only due to running out of memory on >> some tests, and I'll be doing my usual complete testlist run soon. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8019632/ >> >> The bug report is here: >> http://bugs.sun.com/view_bug.do?bug_id=8019632 >> >> Thanks, >> Eric >> From john.coomes at oracle.com Thu Jul 18 10:32:19 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 17:32:19 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b99 for changeset 3f67804ab613 Message-ID: <20130718173224.18BC8481B8@hg.openjdk.java.net> Changeset: 8d492f1dfd1b Author: cl Date: 2013-07-18 03:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/8d492f1dfd1b Added tag jdk8-b99 for changeset 3f67804ab613 ! .hgtags From john.coomes at oracle.com Thu Jul 18 10:32:15 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 17:32:15 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b99 for changeset 59dc9da81379 Message-ID: <20130718173215.9E36A481B7@hg.openjdk.java.net> Changeset: d2dcb110e9db Author: cl Date: 2013-07-18 03:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d2dcb110e9db Added tag jdk8-b99 for changeset 59dc9da81379 ! .hgtags From john.coomes at oracle.com Thu Jul 18 10:32:29 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 17:32:29 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b99 for changeset adf49c3ef83c Message-ID: <20130718173240.B60B3481B9@hg.openjdk.java.net> Changeset: 043da456d316 Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/043da456d316 Added tag jdk8-b99 for changeset adf49c3ef83c ! .hgtags From john.coomes at oracle.com Thu Jul 18 10:32:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 17:32:47 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b99 for changeset 8ef83d4b23c9 Message-ID: <20130718173255.01AC1481BA@hg.openjdk.java.net> Changeset: 4fd722afae5c Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/4fd722afae5c Added tag jdk8-b99 for changeset 8ef83d4b23c9 ! .hgtags From john.coomes at oracle.com Thu Jul 18 10:33:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 17:33:10 +0000 Subject: hg: hsx/hotspot-main/jdk: 4 new changesets Message-ID: <20130718173509.523DF481BB@hg.openjdk.java.net> Changeset: 56bc019a0525 Author: katleman Date: 2013-07-11 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/56bc019a0525 8020414: JDK8 b98 source with GPL header errors Reviewed-by: darcy, lancea, iris ! test/sun/security/krb5/auto/NoneReplayCacheTest.java Changeset: 030d1ca7432f Author: katleman Date: 2013-07-11 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/030d1ca7432f Merge Changeset: 6a099a36589b Author: katleman Date: 2013-07-16 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6a099a36589b Merge Changeset: 9b6070690e50 Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9b6070690e50 Added tag jdk8-b99 for changeset 6a099a36589b ! .hgtags From john.coomes at oracle.com Thu Jul 18 10:37:01 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 17:37:01 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b99 for changeset 10a1ab9e20a4 Message-ID: <20130718173704.D8120481BE@hg.openjdk.java.net> Changeset: 10503ced6cc2 Author: cl Date: 2013-07-18 03:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/10503ced6cc2 Added tag jdk8-b99 for changeset 10a1ab9e20a4 ! .hgtags From john.coomes at oracle.com Thu Jul 18 10:36:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 17:36:37 +0000 Subject: hg: hsx/hotspot-main/langtools: 2 new changesets Message-ID: <20130718173655.ACA48481BC@hg.openjdk.java.net> Changeset: 6d85acab769e Author: mcimadamore Date: 2013-07-17 19:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6d85acab769e 8013638: Few policy tests are failing in Lambda nightly Summary: BridgeHarness test is leaving files open Reviewed-by: ksrini ! test/tools/javac/generics/bridges/BridgeHarness.java Changeset: e73f00139fb5 Author: cl Date: 2013-07-18 03:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e73f00139fb5 Added tag jdk8-b99 for changeset 6d85acab769e ! .hgtags From rickard.backman at oracle.com Thu Jul 18 11:10:44 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Thu, 18 Jul 2013 18:10:44 +0000 Subject: hg: hsx/hsx24/hotspot: 8020701: Avoid crashes in WatcherThread Message-ID: <20130718181050.A6378481D6@hg.openjdk.java.net> Changeset: c233f56b2e00 Author: rbackman Date: 2013-07-17 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c233f56b2e00 8020701: Avoid crashes in WatcherThread Reviewed-by: acorn, dcubed, dsimms ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From alejandro.murillo at oracle.com Thu Jul 18 12:33:25 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 18 Jul 2013 19:33:25 +0000 Subject: hg: hsx/hsx25/hotspot: 14 new changesets Message-ID: <20130718193404.A65C8481E5@hg.openjdk.java.net> Changeset: dc8afa03e5c9 Author: katleman Date: 2013-07-11 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dc8afa03e5c9 8020414: JDK8 b98 source with GPL header errors Reviewed-by: darcy, lancea, iris ! test/runtime/8001071/Test8001071.sh Changeset: 1c474723a324 Author: katleman Date: 2013-07-11 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1c474723a324 Merge Changeset: 81b6cb70717c Author: katleman Date: 2013-07-16 15:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/81b6cb70717c Merge Changeset: bb416ee2a79b Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bb416ee2a79b Added tag jdk8-b99 for changeset 81b6cb70717c ! .hgtags Changeset: bd1dc81da579 Author: amurillo Date: 2013-07-12 17:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bd1dc81da579 8020382: new hotspot build - hs25-b42 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f4311079200c Author: brutisso Date: 2013-07-11 11:33 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f4311079200c 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer Summary: Take _last_young_gc into account when deciding on starting a concurrent mark. Also reviewed-by: per.liden at oracle.com. Reviewed-by: tschatzl, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: e7a47f226600 Author: tamao Date: 2013-07-15 15:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e7a47f226600 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: 980532a806a5 Author: goetz Date: 2013-06-20 15:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/980532a806a5 8016697: Use stubs to implement safefetch Summary: Implement Safefetch as stub routines. This reduces compiler and os dependencies. Reviewed-by: twisti, kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/bsd_x86_64.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/linux_sparc.s ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/linux_x86_64.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.s ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: a74ec8831c7b Author: clucasius Date: 2013-07-15 12:24 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a74ec8831c7b Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 16b10327b00d Author: jprovino Date: 2013-07-16 10:55 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/16b10327b00d 8011569: ARM -- avoid native stack walking Summary: ARM compilers do not emit FramePointer on each native frame by default Reviewed-by: dholmes, zgu ! make/linux/makefiles/vm.make ! src/share/vm/services/memTracker.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 90d6c221d4e5 Author: jprovino Date: 2013-07-16 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/90d6c221d4e5 Merge ! make/linux/makefiles/vm.make - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/services/memTracker.cpp - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9d18d92e54b5 Author: clucasius Date: 2013-07-18 00:52 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9d18d92e54b5 Merge Changeset: 9f71e36a471a Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9f71e36a471a Merge Changeset: 5787fac72e76 Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5787fac72e76 Added tag hs25-b42 for changeset 9f71e36a471a ! .hgtags From alejandro.murillo at oracle.com Thu Jul 18 14:37:36 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 18 Jul 2013 21:37:36 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130718213743.9E849481F5@hg.openjdk.java.net> Changeset: 2afa14dcd667 Author: vkempik Date: 2013-07-18 19:26 +0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2afa14dcd667 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database Summary: Need to rename some variables in svc code after fix JDK-7131629. Reviewed-by: poonam, dholmes ! agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Changeset: 7abbb274df31 Author: amurillo Date: 2013-07-18 14:14 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7abbb274df31 Merge From alejandro.murillo at oracle.com Thu Jul 18 15:10:01 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 18 Jul 2013 22:10:01 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130718221019.6B29A481F6@hg.openjdk.java.net> Changeset: dc8afa03e5c9 Author: katleman Date: 2013-07-11 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dc8afa03e5c9 8020414: JDK8 b98 source with GPL header errors Reviewed-by: darcy, lancea, iris ! test/runtime/8001071/Test8001071.sh Changeset: 1c474723a324 Author: katleman Date: 2013-07-11 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1c474723a324 Merge Changeset: 81b6cb70717c Author: katleman Date: 2013-07-16 15:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/81b6cb70717c Merge Changeset: bb416ee2a79b Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bb416ee2a79b Added tag jdk8-b99 for changeset 81b6cb70717c ! .hgtags Changeset: 9f71e36a471a Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9f71e36a471a Merge Changeset: 5787fac72e76 Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5787fac72e76 Added tag hs25-b42 for changeset 9f71e36a471a ! .hgtags Changeset: 2285b4a0a4e6 Author: amurillo Date: 2013-07-18 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2285b4a0a4e6 8020797: new hotspot build - hs25-b43 Reviewed-by: jcoomes ! make/hotspot_version From vladimir.kozlov at oracle.com Thu Jul 18 19:21:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Jul 2013 19:21:31 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51E6FE54.9040501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <209753E8-8645-4847-825E-8632749DD780@oracle.com> <51E6E499.4000204@oracle.com> <51E6FE54.9040501@oracle.com> Message-ID: <51E8A2AB.9060202@oracle.com> For your information. We filed new bug 8020799 to fix our makefiles to avoid this build conflict. David Holmes is working on it and it will be pushed into main sources first. So you have to wait until the fix is promoted into stage repo. Meanwhile, please, address Christian and my concerns about ppc_ prefix in names. Regards, Vladimir On 7/17/13 1:28 PM, Vladimir Kozlov wrote: > We have build conflict with Oracle closed sources. The closed build > picks files from open ppc64: > > s/src/cpu/ppc/vm/interp_masm_ppc_64.cpp:297:50: error: 'ppc_li' was not > declared in this scope > s/src/cpu/ppc/vm/interp_masm_ppc_64.cpp:298:46: error: 'ppc_and' was not > declared in this scope > > We will discuss this internally and will see what we or you should do. > > Thanks, > Vladimir > > On 7/17/13 11:38 AM, Vladimir Kozlov wrote: >> On 7/17/13 10:18 AM, Christian Thalinger wrote: >>> One question: why did you choose to prefix all assembler instructions >>> with ppc_? >> >> +1 >> >> and PPC_ prefix in registers names. >> >> Goetz, it is different from our naming style so we would really >> appreciate if you change this. >> >> Regards, >> Vladimir >> >>> >>> -- Chris >>> >>> On Jul 17, 2013, at 8:34 AM, "Lindenmaier, Goetz" >>> wrote: >>> >>>> Hi, >>>> >>>> This time with webrev. Sorry for the double mails. >>>> >>>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc >>>> needed for >>>> the PPC64 interpreter port on linux. >>>> >>>> With this change you can do a core build on ppc64 and run the VM >>>> interpreter only. >>>> It executes simple programs as jvm98. >>>> The change requires >>>> >>>> * 8016697: Use stubs to implement safefetch >>>> >>>> * 8020059: The flag introduced by 8014972 is not defined ... >>>> which will arrive soon in the staging repository. >>>> >>>> I marked the change as XL as it contains a lot of code. Nevertheless >>>> the >>>> code has no impact on the existing Oracle platforms. >>>> >>>> The change touches a single shared file, globals.hpp, removing a >>>> special case introduced for the port. This is because we >>>> integrated some changes earlier than originally intended. >>>> >>>> Please review the change. Does it need testing on Oracle side? >>>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>> From david.holmes at oracle.com Thu Jul 18 22:28:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Jul 2013 15:28:40 +1000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> Message-ID: <51E8CE88.2060801@oracle.com> Hi Goetz, Only a brief glance through ... I think orderAccess_linux_ppc.inline.hpp should have: 34 #ifndef _LP64 35 #error "Atomic currently only impleneted for PPC64" 36 #endif the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only be atomic on ppc64). BTW typo: 35 #error "Atomic currently only impleneted for PPC64" I also find the ppc_ prefix used in the assembly code somewhat redundant. David ----- On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: > Hi, > > This time with webrev. Sorry for the double mails. > > This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for > the PPC64 interpreter port on linux. > > With this change you can do a core build on ppc64 and run the VM interpreter only. > It executes simple programs as jvm98. > The change requires > > * 8016697: Use stubs to implement safefetch > > * 8020059: The flag introduced by 8014972 is not defined ... > which will arrive soon in the staging repository. > > I marked the change as XL as it contains a lot of code. Nevertheless the > code has no impact on the existing Oracle platforms. > > The change touches a single shared file, globals.hpp, removing a > special case introduced for the port. This is because we > integrated some changes earlier than originally intended. > > Please review the change. Does it need testing on Oracle side? > http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ > > Best regards, > Goetz. > From volker.simonis at gmail.com Fri Jul 19 05:30:12 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 19 Jul 2013 14:30:12 +0200 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51E6E499.4000204@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <209753E8-8645-4847-825E-8632749DD780@oracle.com> <51E6E499.4000204@oracle.com> Message-ID: On Wed, Jul 17, 2013 at 8:38 PM, Vladimir Kozlov wrote: > On 7/17/13 10:18 AM, Christian Thalinger wrote: >> >> One question: why did you choose to prefix all assembler instructions >> with ppc_? > I agree that the 'ppc_' prefix is somewhat redundant but it has always always been like this:) and it really helps if you are using cscope (or plain grep). Also IDEs like Eclipse and NetBeans don't handle several functions with the same name (and signature) very well (actually, the navigation isn't working at all in such circumstances). Is this really a show-stopper? Changing this would mean that we would have to change all our internal sources which is quite an effort. Thank you and best regards, Volker > > +1 > > and PPC_ prefix in registers names. > > Goetz, it is different from our naming style so we would really appreciate > if you change this. > > Regards, > Vladimir > > >> >> -- Chris >> >> On Jul 17, 2013, at 8:34 AM, "Lindenmaier, Goetz" >> wrote: >> >>> Hi, >>> >>> This time with webrev. Sorry for the double mails. >>> >>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed >>> for >>> the PPC64 interpreter port on linux. >>> >>> With this change you can do a core build on ppc64 and run the VM >>> interpreter only. >>> It executes simple programs as jvm98. >>> The change requires >>> >>> * 8016697: Use stubs to implement safefetch >>> >>> * 8020059: The flag introduced by 8014972 is not defined ... >>> which will arrive soon in the staging repository. >>> >>> I marked the change as XL as it contains a lot of code. Nevertheless the >>> code has no impact on the existing Oracle platforms. >>> >>> The change touches a single shared file, globals.hpp, removing a >>> special case introduced for the port. This is because we >>> integrated some changes earlier than originally intended. >>> >>> Please review the change. Does it need testing on Oracle side? >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>> >>> Best regards, >>> Goetz. >>> >> > From goetz.lindenmaier at sap.com Fri Jul 19 12:47:01 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 19 Jul 2013 19:47:01 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51E8CE88.2060801@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> Hi David, > I think orderAccess_linux_ppc.inline.hpp should have: > 34 #ifndef _LP64 > 35 #error "Atomic currently only impleneted for PPC64" > 36 #endif You're right, I'll fix this. If you don't object I'll guard it by PPC64 as it depends on the processor architecture and not the memory model. If I will change the ppc_ prefixes that'll take a bit, especially as I will have to adapt all the alignments :(. But that does not matter, as we need to wait for your build change anyways. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Friday, July 19, 2013 7:29 AM To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. Hi Goetz, Only a brief glance through ... I think orderAccess_linux_ppc.inline.hpp should have: 34 #ifndef _LP64 35 #error "Atomic currently only impleneted for PPC64" 36 #endif the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only be atomic on ppc64). BTW typo: 35 #error "Atomic currently only impleneted for PPC64" I also find the ppc_ prefix used in the assembly code somewhat redundant. David ----- On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: > Hi, > > This time with webrev. Sorry for the double mails. > > This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for > the PPC64 interpreter port on linux. > > With this change you can do a core build on ppc64 and run the VM interpreter only. > It executes simple programs as jvm98. > The change requires > > * 8016697: Use stubs to implement safefetch > > * 8020059: The flag introduced by 8014972 is not defined ... > which will arrive soon in the staging repository. > > I marked the change as XL as it contains a lot of code. Nevertheless the > code has no impact on the existing Oracle platforms. > > The change touches a single shared file, globals.hpp, removing a > special case introduced for the port. This is because we > integrated some changes earlier than originally intended. > > Please review the change. Does it need testing on Oracle side? > http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ > > Best regards, > Goetz. > From alejandro.murillo at oracle.com Fri Jul 19 13:42:00 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 19 Jul 2013 20:42:00 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130719204212.D0C704822A@hg.openjdk.java.net> Changeset: c6efe89c3b38 Author: katleman Date: 2013-07-17 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c6efe89c3b38 Added tag jdk7u40-b34 for changeset 1274c4750118 ! .hgtags Changeset: f969880098fd Author: amurillo Date: 2013-07-19 05:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f969880098fd Merge Changeset: 0af6bc95c1cb Author: amurillo Date: 2013-07-19 05:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0af6bc95c1cb Added tag hs24-b54 for changeset f969880098fd ! .hgtags From vladimir.kozlov at oracle.com Fri Jul 19 19:19:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Jul 2013 19:19:31 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <209753E8-8645-4847-825E-8632749DD780@oracle.com> <51E6E499.4000204@oracle.com> Message-ID: <51E9F3B3.7020902@oracle.com> On 7/19/13 5:30 AM, Volker Simonis wrote: > On Wed, Jul 17, 2013 at 8:38 PM, Vladimir Kozlov > wrote: >> On 7/17/13 10:18 AM, Christian Thalinger wrote: >>> >>> One question: why did you choose to prefix all assembler instructions >>> with ppc_? >> > > I agree that the 'ppc_' prefix is somewhat redundant but it has always > always been like this:) and it really helps if you are using cscope > (or plain grep). You can grep only src/cpu/ppc/vm/* :) > > Also IDEs like Eclipse and NetBeans don't handle several functions > with the same name (and signature) very well (actually, the navigation > isn't working at all in such circumstances). Agree, I also hit such problems. But at least Eclipse is trying sometimes to show list of files where it finds such functions. So you are not totally lost :) > > Is this really a show-stopper? Changing this would mean that we would > have to change all our internal sources which is quite an effort. It is a big deal for us in Hotspot. We follow our coding style and we are trying to avoid any exceptions. Regards, Vladimir > > Thank you and best regards, > Volker > >> >> +1 >> >> and PPC_ prefix in registers names. >> >> Goetz, it is different from our naming style so we would really appreciate >> if you change this. >> >> Regards, >> Vladimir >> >> >>> >>> -- Chris >>> >>> On Jul 17, 2013, at 8:34 AM, "Lindenmaier, Goetz" >>> wrote: >>> >>>> Hi, >>>> >>>> This time with webrev. Sorry for the double mails. >>>> >>>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed >>>> for >>>> the PPC64 interpreter port on linux. >>>> >>>> With this change you can do a core build on ppc64 and run the VM >>>> interpreter only. >>>> It executes simple programs as jvm98. >>>> The change requires >>>> >>>> * 8016697: Use stubs to implement safefetch >>>> >>>> * 8020059: The flag introduced by 8014972 is not defined ... >>>> which will arrive soon in the staging repository. >>>> >>>> I marked the change as XL as it contains a lot of code. Nevertheless the >>>> code has no impact on the existing Oracle platforms. >>>> >>>> The change touches a single shared file, globals.hpp, removing a >>>> special case introduced for the port. This is because we >>>> integrated some changes earlier than originally intended. >>>> >>>> Please review the change. Does it need testing on Oracle side? >>>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>> >> From alejandro.murillo at oracle.com Fri Jul 19 22:14:06 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 20 Jul 2013 05:14:06 +0000 Subject: hg: hsx/hsx24/hotspot: 8020796: new hotspot build - hs24-b55 Message-ID: <20130720051410.74DEF4823C@hg.openjdk.java.net> Changeset: 3743512d8d4c Author: amurillo Date: 2013-07-19 05:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3743512d8d4c 8020796: new hotspot build - hs24-b55 Reviewed-by: jcoomes ! make/hotspot_version From eric.mccorkle at oracle.com Sun Jul 21 19:05:33 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Sun, 21 Jul 2013 22:05:33 -0400 Subject: Review request for JDK-8019632: Method parameters are not copied in clone_with_new_data In-Reply-To: <51E80822.3040307@oracle.com> References: <51E75BCA.5030604@oracle.com> <51E7EFD0.906@oracle.com> <51E80822.3040307@oracle.com> Message-ID: <51EC936D.3030000@oracle.com> I've written a test based on that one. However, as it is in jdk/, it will need to go into TL, which means it will need to wait until propagation from hsx. In any case, it succeeds, and I now have a clean ute (testlist aka. everything) and jprt run. Do I have a second for this change? On 07/18/13 11:22, Coleen Phillmore wrote: > > Eric, > This code change looks good. For the related bug that didn't copy > method annotations, I added test: > jdk/test/java/lang/instrument/RedefineMethodWithAnnotations.sh. Can you > use this test to write a new one to the JDK that demonstrates this bug? > We've been adding these tests to the JDK because it has the support > there and all the other tests are there. > > Thanks, > Coleen > > On 7/18/2013 9:38 AM, Eric McCorkle wrote: >> Realized I'd duplicated a comment. It's been corrected. >> >> On 07/17/13 23:06, Eric McCorkle wrote: >>> Hello, >>> >>> Please review this patch, which updates clone_with_new_data to copy >>> method parameter data. This was missed in the initial implementation. >>> >>> I've gotten a JPRT run that failed only due to running out of memory on >>> some tests, and I'll be doing my usual complete testlist run soon. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8019632/ >>> >>> The bug report is here: >>> http://bugs.sun.com/view_bug.do?bug_id=8019632 >>> >>> Thanks, >>> Eric >>> > From david.holmes at oracle.com Sun Jul 21 20:26:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Jul 2013 13:26:49 +1000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> Message-ID: <51ECA679.9030707@oracle.com> On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: > Hi David, > >> I think orderAccess_linux_ppc.inline.hpp should have: >> 34 #ifndef _LP64 >> 35 #error "Atomic currently only impleneted for PPC64" >> 36 #endif > You're right, I'll fix this. > If you don't object I'll guard it by PPC64 as it depends on the > processor architecture and not the memory model. Is there some case where _LP64 would be true but PPC64 would not be ??? They seem effectively interchangeable but I don't know why you would use one in one file and the other in another file ?? Thanks, David > If I will change the ppc_ prefixes that'll take a bit, especially > as I will have to adapt all the alignments :(. > But that does not matter, as we need to wait for your build > change anyways. > > Best regards, > Goetz. > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Friday, July 19, 2013 7:29 AM > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > Hi Goetz, > > Only a brief glance through ... > > I think orderAccess_linux_ppc.inline.hpp should have: > > 34 #ifndef _LP64 > 35 #error "Atomic currently only impleneted for PPC64" > 36 #endif > > the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only > be atomic on ppc64). > > BTW typo: 35 #error "Atomic currently only impleneted for PPC64" > > I also find the ppc_ prefix used in the assembly code somewhat redundant. > > David > ----- > > On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> This time with webrev. Sorry for the double mails. >> >> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for >> the PPC64 interpreter port on linux. >> >> With this change you can do a core build on ppc64 and run the VM interpreter only. >> It executes simple programs as jvm98. >> The change requires >> >> * 8016697: Use stubs to implement safefetch >> >> * 8020059: The flag introduced by 8014972 is not defined ... >> which will arrive soon in the staging repository. >> >> I marked the change as XL as it contains a lot of code. Nevertheless the >> code has no impact on the existing Oracle platforms. >> >> The change touches a single shared file, globals.hpp, removing a >> special case introduced for the port. This is because we >> integrated some changes earlier than originally intended. >> >> Please review the change. Does it need testing on Oracle side? >> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >> >> Best regards, >> Goetz. >> From goetz.lindenmaier at sap.com Mon Jul 22 00:14:56 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jul 2013 07:14:56 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51ECA679.9030707@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> Hi David, PPC64: describes an instruction set / machine with all it's specialities. And the instruction set we implemented the port for has an atomic 64-bit instruction. LP64 describes a memory model. I.E, long == 64bit, int == 32bit , pointer == 64 bit. In contraditction to ILP64 (int == 64bit) etc, which you could as well implement with the PPC64 instruction set. You could also implement a system with ILP32 on PPC64, and then you would have an atomic 64-bit instruction. Compressed oops make sense to protect with LP64, because they are only helpful with 64 bit pointers. While usage of LP64 is not exactly correct here, ILP64, SLP64 etc would also use compressed oops. But it's close enough I guess. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 22. Juli 2013 05:27 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: > Hi David, > >> I think orderAccess_linux_ppc.inline.hpp should have: >> 34 #ifndef _LP64 >> 35 #error "Atomic currently only impleneted for PPC64" >> 36 #endif > You're right, I'll fix this. > If you don't object I'll guard it by PPC64 as it depends on the > processor architecture and not the memory model. Is there some case where _LP64 would be true but PPC64 would not be ??? They seem effectively interchangeable but I don't know why you would use one in one file and the other in another file ?? Thanks, David > If I will change the ppc_ prefixes that'll take a bit, especially > as I will have to adapt all the alignments :(. > But that does not matter, as we need to wait for your build > change anyways. > > Best regards, > Goetz. > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Friday, July 19, 2013 7:29 AM > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > Hi Goetz, > > Only a brief glance through ... > > I think orderAccess_linux_ppc.inline.hpp should have: > > 34 #ifndef _LP64 > 35 #error "Atomic currently only impleneted for PPC64" > 36 #endif > > the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only > be atomic on ppc64). > > BTW typo: 35 #error "Atomic currently only impleneted for PPC64" > > I also find the ppc_ prefix used in the assembly code somewhat redundant. > > David > ----- > > On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> This time with webrev. Sorry for the double mails. >> >> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for >> the PPC64 interpreter port on linux. >> >> With this change you can do a core build on ppc64 and run the VM interpreter only. >> It executes simple programs as jvm98. >> The change requires >> >> * 8016697: Use stubs to implement safefetch >> >> * 8020059: The flag introduced by 8014972 is not defined ... >> which will arrive soon in the staging repository. >> >> I marked the change as XL as it contains a lot of code. Nevertheless the >> code has no impact on the existing Oracle platforms. >> >> The change touches a single shared file, globals.hpp, removing a >> special case introduced for the port. This is because we >> integrated some changes earlier than originally intended. >> >> Please review the change. Does it need testing on Oracle side? >> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >> >> Best regards, >> Goetz. >> From david.holmes at oracle.com Mon Jul 22 04:37:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Jul 2013 21:37:57 +1000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> Message-ID: <51ED1995.3090003@oracle.com> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: > Hi David, > > PPC64: describes an instruction set / machine with all it's specialities. And the instruction set > we implemented the port for has an atomic 64-bit instruction. > LP64 describes a memory model. I.E, long == 64bit, int == 32bit , pointer == 64 bit. > In contraditction to ILP64 (int == 64bit) etc, which you could as well implement with the > PPC64 instruction set. You could also implement a system with ILP32 on PPC64, and then > you would have an atomic 64-bit instruction. That still doesn't explain why you think LP64 is okay for the atomic file but you want PPC64 for the orderAccess file. ??? Or do you propose to change both of them to PPC64? All of the existing 64-bit ports have a direct correspondence between the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 is the only 64-bit data model that the OpenJDK sources support. > Compressed oops make sense to protect with LP64, because they are only helpful > with 64 bit pointers. While usage of LP64 is not exactly correct here, ILP64, SLP64 > etc would also use compressed oops. But it's close enough I guess. I'm not concerned about compressed oops. No idea where that came from ;-) David ------ > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 22. Juli 2013 05:27 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>> 34 #ifndef _LP64 >>> 35 #error "Atomic currently only impleneted for PPC64" >>> 36 #endif >> You're right, I'll fix this. >> If you don't object I'll guard it by PPC64 as it depends on the >> processor architecture and not the memory model. > > Is there some case where _LP64 would be true but PPC64 would not be ??? > They seem effectively interchangeable but I don't know why you would use > one in one file and the other in another file ?? > > Thanks, > David > >> If I will change the ppc_ prefixes that'll take a bit, especially >> as I will have to adapt all the alignments :(. >> But that does not matter, as we need to wait for your build >> change anyways. >> >> Best regards, >> Goetz. >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Friday, July 19, 2013 7:29 AM >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. >> >> Hi Goetz, >> >> Only a brief glance through ... >> >> I think orderAccess_linux_ppc.inline.hpp should have: >> >> 34 #ifndef _LP64 >> 35 #error "Atomic currently only impleneted for PPC64" >> 36 #endif >> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only >> be atomic on ppc64). >> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >> >> I also find the ppc_ prefix used in the assembly code somewhat redundant. >> >> David >> ----- >> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> This time with webrev. Sorry for the double mails. >>> >>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for >>> the PPC64 interpreter port on linux. >>> >>> With this change you can do a core build on ppc64 and run the VM interpreter only. >>> It executes simple programs as jvm98. >>> The change requires >>> >>> * 8016697: Use stubs to implement safefetch >>> >>> * 8020059: The flag introduced by 8014972 is not defined ... >>> which will arrive soon in the staging repository. >>> >>> I marked the change as XL as it contains a lot of code. Nevertheless the >>> code has no impact on the existing Oracle platforms. >>> >>> The change touches a single shared file, globals.hpp, removing a >>> special case introduced for the port. This is because we >>> integrated some changes earlier than originally intended. >>> >>> Please review the change. Does it need testing on Oracle side? >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>> >>> Best regards, >>> Goetz. >>> From goetz.lindenmaier at sap.com Mon Jul 22 05:40:48 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jul 2013 12:40:48 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51ED1995.3090003@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> > ??? Or do you propose to change both of them to PPC64? Yes, sure, I want to change both. > All of the existing 64-bit ports have a direct correspondence between > the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. I know. And obviously there is a correspondence, as no one will Implement an LG64 memoyf model on a 32 bit machine. But the usage intermingles different memory model and architecture: E.g., the register declaration in register_x86_hpp is fine: #ifdef AMD64 CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); But I think this makes no sense (assembler_x86.hpp): #ifdef _LP64 void movsbq(Register dst, Address src); void movsbq(Register dst, Register src); // Move signed 32bit immediate to 64bit extending sign void movslq(Address dst, int32_t imm64); void movslq(Register dst, int32_t imm64); and should be guarded by AMD64. And I want to get the PPC port right in such matters. I'm currently removing the ppc_ prefixes ... big fun:) Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 22. Juli 2013 13:38 To: Lindenmaier, Goetz Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: > Hi David, > > PPC64: describes an instruction set / machine with all it's specialities. And the instruction set > we implemented the port for has an atomic 64-bit instruction. > LP64 describes a memory model. I.E, long == 64bit, int == 32bit , pointer == 64 bit. > In contraditction to ILP64 (int == 64bit) etc, which you could as well implement with the > PPC64 instruction set. You could also implement a system with ILP32 on PPC64, and then > you would have an atomic 64-bit instruction. That still doesn't explain why you think LP64 is okay for the atomic file but you want PPC64 for the orderAccess file. ??? Or do you propose to change both of them to PPC64? All of the existing 64-bit ports have a direct correspondence between the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 is the only 64-bit data model that the OpenJDK sources support. > Compressed oops make sense to protect with LP64, because they are only helpful > with 64 bit pointers. While usage of LP64 is not exactly correct here, ILP64, SLP64 > etc would also use compressed oops. But it's close enough I guess. I'm not concerned about compressed oops. No idea where that came from ;-) David ------ > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 22. Juli 2013 05:27 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>> 34 #ifndef _LP64 >>> 35 #error "Atomic currently only impleneted for PPC64" >>> 36 #endif >> You're right, I'll fix this. >> If you don't object I'll guard it by PPC64 as it depends on the >> processor architecture and not the memory model. > > Is there some case where _LP64 would be true but PPC64 would not be ??? > They seem effectively interchangeable but I don't know why you would use > one in one file and the other in another file ?? > > Thanks, > David > >> If I will change the ppc_ prefixes that'll take a bit, especially >> as I will have to adapt all the alignments :(. >> But that does not matter, as we need to wait for your build >> change anyways. >> >> Best regards, >> Goetz. >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Friday, July 19, 2013 7:29 AM >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. >> >> Hi Goetz, >> >> Only a brief glance through ... >> >> I think orderAccess_linux_ppc.inline.hpp should have: >> >> 34 #ifndef _LP64 >> 35 #error "Atomic currently only impleneted for PPC64" >> 36 #endif >> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only >> be atomic on ppc64). >> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >> >> I also find the ppc_ prefix used in the assembly code somewhat redundant. >> >> David >> ----- >> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> This time with webrev. Sorry for the double mails. >>> >>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for >>> the PPC64 interpreter port on linux. >>> >>> With this change you can do a core build on ppc64 and run the VM interpreter only. >>> It executes simple programs as jvm98. >>> The change requires >>> >>> * 8016697: Use stubs to implement safefetch >>> >>> * 8020059: The flag introduced by 8014972 is not defined ... >>> which will arrive soon in the staging repository. >>> >>> I marked the change as XL as it contains a lot of code. Nevertheless the >>> code has no impact on the existing Oracle platforms. >>> >>> The change touches a single shared file, globals.hpp, removing a >>> special case introduced for the port. This is because we >>> integrated some changes earlier than originally intended. >>> >>> Please review the change. Does it need testing on Oracle side? >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>> >>> Best regards, >>> Goetz. >>> From vladimir.kozlov at oracle.com Mon Jul 22 09:48:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Jul 2013 09:48:09 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> Message-ID: <51ED6249.5060701@oracle.com> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >> ??? Or do you propose to change both of them to PPC64? > Yes, sure, I want to change both. Why do we need this error if this code is only for PPC64 port? We will have other compilation errors if we try to use these sources for something else as we found already. Do you have an other usage so you need this guard? >> All of the existing 64-bit ports have a direct correspondence between >> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. > > I know. And obviously there is a correspondence, as no one will > Implement an LG64 memory model on a 32 bit machine. > But the usage intermingles different memory model and architecture: > > E.g., the register declaration in register_x86_hpp is fine: > > #ifdef AMD64 > CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); > > But I think this makes no sense (assembler_x86.hpp): > > #ifdef _LP64 > void movsbq(Register dst, Address src); > void movsbq(Register dst, Register src); > // Move signed 32bit immediate to 64bit extending sign > void movslq(Address dst, int32_t imm64); > void movslq(Register dst, int32_t imm64); > > and should be guarded by AMD64. Strictly speaking you are right. But we will never do ilp32 for AMD64 so using _LP64 works for us. Also using AMD64 sometimes rise questions about Intel x64. So using _LP64 is more neutral. > And I want to get the PPC port right in such matters. I agree with this since ppc is more flexible than x86, it seems. > I'm currently removing the ppc_ prefixes ... big fun:) Sorry about that. Regards, Vladimir > Best regards, > > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 22. Juli 2013 13:38 > To: Lindenmaier, Goetz > Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: > > > Hi David, > > > > > > PPC64: describes an instruction set / machine with all it's specialities. And the instruction set > > > we implemented the port for has an atomic 64-bit instruction. > > > LP64 describes a memory model. I.E, long == 64bit, int == 32bit , pointer == 64 bit. > > > In contraditction to ILP64 (int == 64bit) etc, which you could as well implement with the > > > PPC64 instruction set. You could also implement a system with ILP32 on PPC64, and then > > > you would have an atomic 64-bit instruction. > > That still doesn't explain why you think LP64 is okay for the atomic > > file but you want PPC64 for the orderAccess file. ??? Or do you propose > > to change both of them to PPC64? > > All of the existing 64-bit ports have a direct correspondence between > > the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 > > is the only 64-bit data model that the OpenJDK sources support. > > > Compressed oops make sense to protect with LP64, because they are only helpful > > > with 64 bit pointers. While usage of LP64 is not exactly correct here, ILP64, SLP64 > > > etc would also use compressed oops. But it's close enough I guess. > > I'm not concerned about compressed oops. No idea where that came from ;-) > > David > > ------ > > > Best regards, > > > Goetz. > > > > > > -----Original Message----- > > > From: David Holmes [mailto:david.holmes at oracle.com] > > > Sent: Montag, 22. Juli 2013 05:27 > > > To: Lindenmaier, Goetz > > > Cc: hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net > ; Vladimir Kozlov > > > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > > > > > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: > > >> Hi David, > > >> > > >>> I think orderAccess_linux_ppc.inline.hpp should have: > > >>> 34 #ifndef _LP64 > > >>> 35 #error "Atomic currently only impleneted for PPC64" > > >>> 36 #endif > > >> You're right, I'll fix this. > > >> If you don't object I'll guard it by PPC64 as it depends on the > > >> processor architecture and not the memory model. > > > > > > Is there some case where _LP64 would be true but PPC64 would not be ??? > > > They seem effectively interchangeable but I don't know why you would use > > > one in one file and the other in another file ?? > > > > > > Thanks, > > > David > > > > > >> If I will change the ppc_ prefixes that'll take a bit, especially > > >> as I will have to adapt all the alignments :(. > > >> But that does not matter, as we need to wait for your build > > >> change anyways. > > >> > > >> Best regards, > > >> Goetz. > > >> > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: David Holmes [mailto:david.holmes at oracle.com] > > >> Sent: Friday, July 19, 2013 7:29 AM > > >> To: Lindenmaier, Goetz > > >> Cc: hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net > ; Vladimir Kozlov > > >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > >> > > >> Hi Goetz, > > >> > > >> Only a brief glance through ... > > >> > > >> I think orderAccess_linux_ppc.inline.hpp should have: > > >> > > >> 34 #ifndef _LP64 > > >> 35 #error "Atomic currently only impleneted for PPC64" > > >> 36 #endif > > >> > > >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only > > >> be atomic on ppc64). > > >> > > >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" > > >> > > >> I also find the ppc_ prefix used in the assembly code somewhat redundant. > > >> > > >> David > > >> ----- > > >> > > >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: > > >>> Hi, > > >>> > > >>> This time with webrev. Sorry for the double mails. > > >>> > > >>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for > > >>> the PPC64 interpreter port on linux. > > >>> > > >>> With this change you can do a core build on ppc64 and run the VM interpreter only. > > >>> It executes simple programs as jvm98. > > >>> The change requires > > >>> > > >>> * 8016697: Use stubs to implement safefetch > > >>> > > >>> * 8020059: The flag introduced by 8014972 is not defined ... > > >>> which will arrive soon in the staging repository. > > >>> > > >>> I marked the change as XL as it contains a lot of code. Nevertheless the > > >>> code has no impact on the existing Oracle platforms. > > >>> > > >>> The change touches a single shared file, globals.hpp, removing a > > >>> special case introduced for the port. This is because we > > >>> integrated some changes earlier than originally intended. > > >>> > > >>> Please review the change. Does it need testing on Oracle side? > > >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ > > >>> > > >>> Best regards, > > >>> Goetz. > > >>> > From goetz.lindenmaier at sap.com Mon Jul 22 11:03:43 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jul 2013 18:03:43 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51ED6249.5060701@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> Hi, I updated the webrev. The code is not without ppc_ and PPC_ prefixes. http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ You can have a look at it, and if you have further comments regarding the style it would be nice to get them early. I still have to adapt all the remaining changes in the patch queue, and then test it with the compiler. With that I obviously can run more tests. I don't really care about the guard. Just tell me what to do... Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Monday, July 22, 2013 6:48 PM To: Lindenmaier, Goetz Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >> ??? Or do you propose to change both of them to PPC64? > Yes, sure, I want to change both. Why do we need this error if this code is only for PPC64 port? We will have other compilation errors if we try to use these sources for something else as we found already. Do you have an other usage so you need this guard? >> All of the existing 64-bit ports have a direct correspondence between >> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. > > I know. And obviously there is a correspondence, as no one will > Implement an LG64 memory model on a 32 bit machine. > But the usage intermingles different memory model and architecture: > > E.g., the register declaration in register_x86_hpp is fine: > > #ifdef AMD64 > CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); > > But I think this makes no sense (assembler_x86.hpp): > > #ifdef _LP64 > void movsbq(Register dst, Address src); > void movsbq(Register dst, Register src); > // Move signed 32bit immediate to 64bit extending sign > void movslq(Address dst, int32_t imm64); > void movslq(Register dst, int32_t imm64); > > and should be guarded by AMD64. Strictly speaking you are right. But we will never do ilp32 for AMD64 so using _LP64 works for us. Also using AMD64 sometimes rise questions about Intel x64. So using _LP64 is more neutral. > And I want to get the PPC port right in such matters. I agree with this since ppc is more flexible than x86, it seems. > I'm currently removing the ppc_ prefixes ... big fun:) Sorry about that. Regards, Vladimir > Best regards, > > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 22. Juli 2013 13:38 > To: Lindenmaier, Goetz > Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: > > > Hi David, > > > > > > PPC64: describes an instruction set / machine with all it's specialities. And the instruction set > > > we implemented the port for has an atomic 64-bit instruction. > > > LP64 describes a memory model. I.E, long == 64bit, int == 32bit , pointer == 64 bit. > > > In contraditction to ILP64 (int == 64bit) etc, which you could as well implement with the > > > PPC64 instruction set. You could also implement a system with ILP32 on PPC64, and then > > > you would have an atomic 64-bit instruction. > > That still doesn't explain why you think LP64 is okay for the atomic > > file but you want PPC64 for the orderAccess file. ??? Or do you propose > > to change both of them to PPC64? > > All of the existing 64-bit ports have a direct correspondence between > > the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 > > is the only 64-bit data model that the OpenJDK sources support. > > > Compressed oops make sense to protect with LP64, because they are only helpful > > > with 64 bit pointers. While usage of LP64 is not exactly correct here, ILP64, SLP64 > > > etc would also use compressed oops. But it's close enough I guess. > > I'm not concerned about compressed oops. No idea where that came from ;-) > > David > > ------ > > > Best regards, > > > Goetz. > > > > > > -----Original Message----- > > > From: David Holmes [mailto:david.holmes at oracle.com] > > > Sent: Montag, 22. Juli 2013 05:27 > > > To: Lindenmaier, Goetz > > > Cc: hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net > ; Vladimir Kozlov > > > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > > > > > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: > > >> Hi David, > > >> > > >>> I think orderAccess_linux_ppc.inline.hpp should have: > > >>> 34 #ifndef _LP64 > > >>> 35 #error "Atomic currently only impleneted for PPC64" > > >>> 36 #endif > > >> You're right, I'll fix this. > > >> If you don't object I'll guard it by PPC64 as it depends on the > > >> processor architecture and not the memory model. > > > > > > Is there some case where _LP64 would be true but PPC64 would not be ??? > > > They seem effectively interchangeable but I don't know why you would use > > > one in one file and the other in another file ?? > > > > > > Thanks, > > > David > > > > > >> If I will change the ppc_ prefixes that'll take a bit, especially > > >> as I will have to adapt all the alignments :(. > > >> But that does not matter, as we need to wait for your build > > >> change anyways. > > >> > > >> Best regards, > > >> Goetz. > > >> > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: David Holmes [mailto:david.holmes at oracle.com] > > >> Sent: Friday, July 19, 2013 7:29 AM > > >> To: Lindenmaier, Goetz > > >> Cc: hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net > ; Vladimir Kozlov > > >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > >> > > >> Hi Goetz, > > >> > > >> Only a brief glance through ... > > >> > > >> I think orderAccess_linux_ppc.inline.hpp should have: > > >> > > >> 34 #ifndef _LP64 > > >> 35 #error "Atomic currently only impleneted for PPC64" > > >> 36 #endif > > >> > > >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only > > >> be atomic on ppc64). > > >> > > >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" > > >> > > >> I also find the ppc_ prefix used in the assembly code somewhat redundant. > > >> > > >> David > > >> ----- > > >> > > >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: > > >>> Hi, > > >>> > > >>> This time with webrev. Sorry for the double mails. > > >>> > > >>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for > > >>> the PPC64 interpreter port on linux. > > >>> > > >>> With this change you can do a core build on ppc64 and run the VM interpreter only. > > >>> It executes simple programs as jvm98. > > >>> The change requires > > >>> > > >>> * 8016697: Use stubs to implement safefetch > > >>> > > >>> * 8020059: The flag introduced by 8014972 is not defined ... > > >>> which will arrive soon in the staging repository. > > >>> > > >>> I marked the change as XL as it contains a lot of code. Nevertheless the > > >>> code has no impact on the existing Oracle platforms. > > >>> > > >>> The change touches a single shared file, globals.hpp, removing a > > >>> special case introduced for the port. This is because we > > >>> integrated some changes earlier than originally intended. > > >>> > > >>> Please review the change. Does it need testing on Oracle side? > > >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ > > >>> > > >>> Best regards, > > >>> Goetz. > > >>> > From vladimir.kozlov at oracle.com Mon Jul 22 13:03:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Jul 2013 13:03:48 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> Message-ID: <51ED9024.3060208@oracle.com> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated the webrev. The code is not without ppc_ and PPC_ > prefixes. > http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ > You can have a look at it, and if you have further comments regarding > the style it would be nice to get them early. I still have to adapt all > the remaining changes in the patch queue, and then test it with the > compiler. With that I obviously can run more tests. In general it is good. Few notes. MacroAssembler::encode_klass_not_null() is wrong. LogKlassAlignmentInBytes should be used or Universe::narrow_klass_shift() in hs25 since klasses were moved to metaspace. Try to run tests with LogMinObjAlignmentInBytes=16 (=32). BTW, the new implementation is coming which will have separate base for compressed classes: 8003424. There was review sent last week. So using r30 unconditionally will be incorrect. > > I don't really care about the guard. Just tell me what to do... To be safe leave guards with PPC64 check instead of _lp64 as you suggested. Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? : jniTypes_ppc.hpp: 48 #ifndef PPC64 49 #error "ppc32 support currently not implemented!!!" 50 #endif // PPC64 Our reviews are based on assumption that this port only supports PPC64+LP64 combination. Is this correct assumption? Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc based macbook pro. But do we need it in this port? Regards, Vladimir > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Monday, July 22, 2013 6:48 PM > To: Lindenmaier, Goetz > Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>> ??? Or do you propose to change both of them to PPC64? >> Yes, sure, I want to change both. > > Why do we need this error if this code is only for PPC64 port? We will have other compilation errors if we try to use > these sources for something else as we found already. Do you have an other usage so you need this guard? > >>> All of the existing 64-bit ports have a direct correspondence between >>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >> >> I know. And obviously there is a correspondence, as no one will >> Implement an LG64 memory model on a 32 bit machine. >> But the usage intermingles different memory model and architecture: >> >> E.g., the register declaration in register_x86_hpp is fine: >> >> #ifdef AMD64 >> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >> >> But I think this makes no sense (assembler_x86.hpp): >> >> #ifdef _LP64 >> void movsbq(Register dst, Address src); >> void movsbq(Register dst, Register src); >> // Move signed 32bit immediate to 64bit extending sign >> void movslq(Address dst, int32_t imm64); >> void movslq(Register dst, int32_t imm64); >> >> and should be guarded by AMD64. > > Strictly speaking you are right. But we will never do ilp32 for AMD64 so using _LP64 works for us. Also using AMD64 > sometimes rise questions about Intel x64. So using _LP64 is more neutral. > >> And I want to get the PPC port right in such matters. > > I agree with this since ppc is more flexible than x86, it seems. > >> I'm currently removing the ppc_ prefixes ... big fun:) > > Sorry about that. > > Regards, > Vladimir > >> Best regards, >> >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Montag, 22. Juli 2013 13:38 >> To: Lindenmaier, Goetz >> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. >> >> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >> >> > Hi David, >> >> > >> >> > PPC64: describes an instruction set / machine with all it's specialities. And the instruction set >> >> > we implemented the port for has an atomic 64-bit instruction. >> >> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit , pointer == 64 bit. >> >> > In contraditction to ILP64 (int == 64bit) etc, which you could as well implement with the >> >> > PPC64 instruction set. You could also implement a system with ILP32 on PPC64, and then >> >> > you would have an atomic 64-bit instruction. >> >> That still doesn't explain why you think LP64 is okay for the atomic >> >> file but you want PPC64 for the orderAccess file. ??? Or do you propose >> >> to change both of them to PPC64? >> >> All of the existing 64-bit ports have a direct correspondence between >> >> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 >> >> is the only 64-bit data model that the OpenJDK sources support. >> >> > Compressed oops make sense to protect with LP64, because they are only helpful >> >> > with 64 bit pointers. While usage of LP64 is not exactly correct here, ILP64, SLP64 >> >> > etc would also use compressed oops. But it's close enough I guess. >> >> I'm not concerned about compressed oops. No idea where that came from ;-) >> >> David >> >> ------ >> >> > Best regards, >> >> > Goetz. >> >> > >> >> > -----Original Message----- >> >> > From: David Holmes [mailto:david.holmes at oracle.com] >> >> > Sent: Montag, 22. Juli 2013 05:27 >> >> > To: Lindenmaier, Goetz >> >> > Cc: hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net >> ; Vladimir Kozlov >> >> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. >> >> > >> >> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >> >> >> Hi David, >> >> >> >> >> >>> I think orderAccess_linux_ppc.inline.hpp should have: >> >> >>> 34 #ifndef _LP64 >> >> >>> 35 #error "Atomic currently only impleneted for PPC64" >> >> >>> 36 #endif >> >> >> You're right, I'll fix this. >> >> >> If you don't object I'll guard it by PPC64 as it depends on the >> >> >> processor architecture and not the memory model. >> >> > >> >> > Is there some case where _LP64 would be true but PPC64 would not be ??? >> >> > They seem effectively interchangeable but I don't know why you would use >> >> > one in one file and the other in another file ?? >> >> > >> >> > Thanks, >> >> > David >> >> > >> >> >> If I will change the ppc_ prefixes that'll take a bit, especially >> >> >> as I will have to adapt all the alignments :(. >> >> >> But that does not matter, as we need to wait for your build >> >> >> change anyways. >> >> >> >> >> >> Best regards, >> >> >> Goetz. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: David Holmes [mailto:david.holmes at oracle.com] >> >> >> Sent: Friday, July 19, 2013 7:29 AM >> >> >> To: Lindenmaier, Goetz >> >> >> Cc: hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net >> ; Vladimir Kozlov >> >> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. >> >> >> >> >> >> Hi Goetz, >> >> >> >> >> >> Only a brief glance through ... >> >> >> >> >> >> I think orderAccess_linux_ppc.inline.hpp should have: >> >> >> >> >> >> 34 #ifndef _LP64 >> >> >> 35 #error "Atomic currently only impleneted for PPC64" >> >> >> 36 #endif >> >> >> >> >> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only >> >> >> be atomic on ppc64). >> >> >> >> >> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >> >> >> >> >> >> I also find the ppc_ prefix used in the assembly code somewhat redundant. >> >> >> >> >> >> David >> >> >> ----- >> >> >> >> >> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >> >> >>> Hi, >> >> >>> >> >> >>> This time with webrev. Sorry for the double mails. >> >> >>> >> >> >>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for >> >> >>> the PPC64 interpreter port on linux. >> >> >>> >> >> >>> With this change you can do a core build on ppc64 and run the VM interpreter only. >> >> >>> It executes simple programs as jvm98. >> >> >>> The change requires >> >> >>> >> >> >>> * 8016697: Use stubs to implement safefetch >> >> >>> >> >> >>> * 8020059: The flag introduced by 8014972 is not defined ... >> >> >>> which will arrive soon in the staging repository. >> >> >>> >> >> >>> I marked the change as XL as it contains a lot of code. Nevertheless the >> >> >>> code has no impact on the existing Oracle platforms. >> >> >>> >> >> >>> The change touches a single shared file, globals.hpp, removing a >> >> >>> special case introduced for the port. This is because we >> >> >>> integrated some changes earlier than originally intended. >> >> >>> >> >> >>> Please review the change. Does it need testing on Oracle side? >> >> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >> >> >>> >> >> >>> Best regards, >> >> >>> Goetz. >> >> >>> >> From serguei.spitsyn at oracle.com Mon Jul 22 13:54:40 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Jul 2013 13:54:40 -0700 Subject: Review request for JDK-8019632: Method parameters are not copied in clone_with_new_data In-Reply-To: <51EC936D.3030000@oracle.com> References: <51E75BCA.5030604@oracle.com> <51E7EFD0.906@oracle.com> <51E80822.3040307@oracle.com> <51EC936D.3030000@oracle.com> Message-ID: <51ED9C10.1050906@oracle.com> Hi Eric, The change looks good. Thanks, Serguei On 7/21/13 7:05 PM, Eric McCorkle wrote: > I've written a test based on that one. However, as it is in jdk/, it > will need to go into TL, which means it will need to wait until > propagation from hsx. > > In any case, it succeeds, and I now have a clean ute (testlist aka. > everything) and jprt run. > > Do I have a second for this change? > > On 07/18/13 11:22, Coleen Phillmore wrote: >> Eric, >> This code change looks good. For the related bug that didn't copy >> method annotations, I added test: >> jdk/test/java/lang/instrument/RedefineMethodWithAnnotations.sh. Can you >> use this test to write a new one to the JDK that demonstrates this bug? >> We've been adding these tests to the JDK because it has the support >> there and all the other tests are there. >> >> Thanks, >> Coleen >> >> On 7/18/2013 9:38 AM, Eric McCorkle wrote: >>> Realized I'd duplicated a comment. It's been corrected. >>> >>> On 07/17/13 23:06, Eric McCorkle wrote: >>>> Hello, >>>> >>>> Please review this patch, which updates clone_with_new_data to copy >>>> method parameter data. This was missed in the initial implementation. >>>> >>>> I've gotten a JPRT run that failed only due to running out of memory on >>>> some tests, and I'll be doing my usual complete testlist run soon. >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~emc/8019632/ >>>> >>>> The bug report is here: >>>> http://bugs.sun.com/view_bug.do?bug_id=8019632 >>>> >>>> Thanks, >>>> Eric >>>> From goetz.lindenmaier at sap.com Mon Jul 22 14:14:40 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jul 2013 21:14:40 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51ED9024.3060208@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF6AA0@DEWDFEMB12A.global.corp.sap> Hi, > MacroAssembler::encode_klass_not_null() is wrong. Thanks for the tip, I'll fix it. > BTW, the new implementation is coming which will have separate base for compressed classes: 8003424. There was review > sent last week. So using r30 unconditionally will be incorrect. Ah, I wondered why you cut the space for the klasses out of the heap. I'll have a look tomorrow how you handle the two bases. On other architectures we load the base always as constant, as the need to run with base is rather small. But sometimes this leads to rematerialization chaos. I'll talk to Volker about the APPLE in ppc_jni.h. I can't see right now why we did that. Our internal file is much cleaner. Usually I keep them as similar as possible. We will NOT do a 32-bit port. If there is somebody in the community to do that we'll support that, but we will not do it. Best regards, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Montag, 22. Juli 2013 22:04 To: Lindenmaier, Goetz Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated the webrev. The code is not without ppc_ and PPC_ > prefixes. > http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ > You can have a look at it, and if you have further comments regarding > the style it would be nice to get them early. I still have to adapt all > the remaining changes in the patch queue, and then test it with the > compiler. With that I obviously can run more tests. In general it is good. Few notes. MacroAssembler::encode_klass_not_null() is wrong. LogKlassAlignmentInBytes should be used or Universe::narrow_klass_shift() in hs25 since klasses were moved to metaspace. Try to run tests with LogMinObjAlignmentInBytes=16 (=32). BTW, the new implementation is coming which will have separate base for compressed classes: 8003424. There was review sent last week. So using r30 unconditionally will be incorrect. > > I don't really care about the guard. Just tell me what to do... To be safe leave guards with PPC64 check instead of _lp64 as you suggested. Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? : jniTypes_ppc.hpp: 48 #ifndef PPC64 49 #error "ppc32 support currently not implemented!!!" 50 #endif // PPC64 Our reviews are based on assumption that this port only supports PPC64+LP64 combination. Is this correct assumption? Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc based macbook pro. But do we need it in this port? Regards, Vladimir > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Monday, July 22, 2013 6:48 PM > To: Lindenmaier, Goetz > Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>> ??? Or do you propose to change both of them to PPC64? >> Yes, sure, I want to change both. > > Why do we need this error if this code is only for PPC64 port? We will have other compilation errors if we try to use > these sources for something else as we found already. Do you have an other usage so you need this guard? > >>> All of the existing 64-bit ports have a direct correspondence between >>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >> >> I know. And obviously there is a correspondence, as no one will >> Implement an LG64 memory model on a 32 bit machine. >> But the usage intermingles different memory model and architecture: >> >> E.g., the register declaration in register_x86_hpp is fine: >> >> #ifdef AMD64 >> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >> >> But I think this makes no sense (assembler_x86.hpp): >> >> #ifdef _LP64 >> void movsbq(Register dst, Address src); >> void movsbq(Register dst, Register src); >> // Move signed 32bit immediate to 64bit extending sign >> void movslq(Address dst, int32_t imm64); >> void movslq(Register dst, int32_t imm64); >> >> and should be guarded by AMD64. > > Strictly speaking you are right. But we will never do ilp32 for AMD64 so using _LP64 works for us. Also using AMD64 > sometimes rise questions about Intel x64. So using _LP64 is more neutral. > >> And I want to get the PPC port right in such matters. > > I agree with this since ppc is more flexible than x86, it seems. > >> I'm currently removing the ppc_ prefixes ... big fun:) > > Sorry about that. > > Regards, > Vladimir > >> Best regards, >> >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Montag, 22. Juli 2013 13:38 >> To: Lindenmaier, Goetz >> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. >> >> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >> >> > Hi David, >> >> > >> >> > PPC64: describes an instruction set / machine with all it's specialities. And the instruction set >> >> > we implemented the port for has an atomic 64-bit instruction. >> >> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit , pointer == 64 bit. >> >> > In contraditction to ILP64 (int == 64bit) etc, which you could as well implement with the >> >> > PPC64 instruction set. You could also implement a system with ILP32 on PPC64, and then >> >> > you would have an atomic 64-bit instruction. >> >> That still doesn't explain why you think LP64 is okay for the atomic >> >> file but you want PPC64 for the orderAccess file. ??? Or do you propose >> >> to change both of them to PPC64? >> >> All of the existing 64-bit ports have a direct correspondence between >> >> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 >> >> is the only 64-bit data model that the OpenJDK sources support. >> >> > Compressed oops make sense to protect with LP64, because they are only helpful >> >> > with 64 bit pointers. While usage of LP64 is not exactly correct here, ILP64, SLP64 >> >> > etc would also use compressed oops. But it's close enough I guess. >> >> I'm not concerned about compressed oops. No idea where that came from ;-) >> >> David >> >> ------ >> >> > Best regards, >> >> > Goetz. >> >> > >> >> > -----Original Message----- >> >> > From: David Holmes [mailto:david.holmes at oracle.com] >> >> > Sent: Montag, 22. Juli 2013 05:27 >> >> > To: Lindenmaier, Goetz >> >> > Cc: hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net >> ; Vladimir Kozlov >> >> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. >> >> > >> >> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >> >> >> Hi David, >> >> >> >> >> >>> I think orderAccess_linux_ppc.inline.hpp should have: >> >> >>> 34 #ifndef _LP64 >> >> >>> 35 #error "Atomic currently only impleneted for PPC64" >> >> >>> 36 #endif >> >> >> You're right, I'll fix this. >> >> >> If you don't object I'll guard it by PPC64 as it depends on the >> >> >> processor architecture and not the memory model. >> >> > >> >> > Is there some case where _LP64 would be true but PPC64 would not be ??? >> >> > They seem effectively interchangeable but I don't know why you would use >> >> > one in one file and the other in another file ?? >> >> > >> >> > Thanks, >> >> > David >> >> > >> >> >> If I will change the ppc_ prefixes that'll take a bit, especially >> >> >> as I will have to adapt all the alignments :(. >> >> >> But that does not matter, as we need to wait for your build >> >> >> change anyways. >> >> >> >> >> >> Best regards, >> >> >> Goetz. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: David Holmes [mailto:david.holmes at oracle.com] >> >> >> Sent: Friday, July 19, 2013 7:29 AM >> >> >> To: Lindenmaier, Goetz >> >> >> Cc: hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net >> ; Vladimir Kozlov >> >> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. >> >> >> >> >> >> Hi Goetz, >> >> >> >> >> >> Only a brief glance through ... >> >> >> >> >> >> I think orderAccess_linux_ppc.inline.hpp should have: >> >> >> >> >> >> 34 #ifndef _LP64 >> >> >> 35 #error "Atomic currently only impleneted for PPC64" >> >> >> 36 #endif >> >> >> >> >> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only >> >> >> be atomic on ppc64). >> >> >> >> >> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >> >> >> >> >> >> I also find the ppc_ prefix used in the assembly code somewhat redundant. >> >> >> >> >> >> David >> >> >> ----- >> >> >> >> >> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >> >> >>> Hi, >> >> >>> >> >> >>> This time with webrev. Sorry for the double mails. >> >> >>> >> >> >>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for >> >> >>> the PPC64 interpreter port on linux. >> >> >>> >> >> >>> With this change you can do a core build on ppc64 and run the VM interpreter only. >> >> >>> It executes simple programs as jvm98. >> >> >>> The change requires >> >> >>> >> >> >>> * 8016697: Use stubs to implement safefetch >> >> >>> >> >> >>> * 8020059: The flag introduced by 8014972 is not defined ... >> >> >>> which will arrive soon in the staging repository. >> >> >>> >> >> >>> I marked the change as XL as it contains a lot of code. Nevertheless the >> >> >>> code has no impact on the existing Oracle platforms. >> >> >>> >> >> >>> The change touches a single shared file, globals.hpp, removing a >> >> >>> special case introduced for the port. This is because we >> >> >>> integrated some changes earlier than originally intended. >> >> >>> >> >> >>> Please review the change. Does it need testing on Oracle side? >> >> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >> >> >>> >> >> >>> Best regards, >> >> >>> Goetz. >> >> >>> >> From eric.mccorkle at oracle.com Mon Jul 22 14:33:12 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 22 Jul 2013 17:33:12 -0400 Subject: Review request for JDK-8019632: Method parameters are not copied in clone_with_new_data In-Reply-To: <51ED9C10.1050906@oracle.com> References: <51E75BCA.5030604@oracle.com> <51E7EFD0.906@oracle.com> <51E80822.3040307@oracle.com> <51EC936D.3030000@oracle.com> <51ED9C10.1050906@oracle.com> Message-ID: <51EDA518.6030205@oracle.com> Thanks. On 07/22/13 16:54, serguei.spitsyn at oracle.com wrote: > Hi Eric, > > The change looks good. > > Thanks, > Serguei > > On 7/21/13 7:05 PM, Eric McCorkle wrote: >> I've written a test based on that one. However, as it is in jdk/, it >> will need to go into TL, which means it will need to wait until >> propagation from hsx. >> >> In any case, it succeeds, and I now have a clean ute (testlist aka. >> everything) and jprt run. >> >> Do I have a second for this change? >> >> On 07/18/13 11:22, Coleen Phillmore wrote: >>> Eric, >>> This code change looks good. For the related bug that didn't copy >>> method annotations, I added test: >>> jdk/test/java/lang/instrument/RedefineMethodWithAnnotations.sh. Can you >>> use this test to write a new one to the JDK that demonstrates this bug? >>> We've been adding these tests to the JDK because it has the support >>> there and all the other tests are there. >>> >>> Thanks, >>> Coleen >>> >>> On 7/18/2013 9:38 AM, Eric McCorkle wrote: >>>> Realized I'd duplicated a comment. It's been corrected. >>>> >>>> On 07/17/13 23:06, Eric McCorkle wrote: >>>>> Hello, >>>>> >>>>> Please review this patch, which updates clone_with_new_data to copy >>>>> method parameter data. This was missed in the initial implementation. >>>>> >>>>> I've gotten a JPRT run that failed only due to running out of >>>>> memory on >>>>> some tests, and I'll be doing my usual complete testlist run soon. >>>>> >>>>> The webrev is here: >>>>> http://cr.openjdk.java.net/~emc/8019632/ >>>>> >>>>> The bug report is here: >>>>> http://bugs.sun.com/view_bug.do?bug_id=8019632 >>>>> >>>>> Thanks, >>>>> Eric >>>>> > From david.holmes at oracle.com Tue Jul 23 00:29:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 17:29:39 +1000 Subject: (XS) RFR: 8020799 Allow customization of hotspot source directories and files In-Reply-To: <51E8C5CD.6020306@oracle.com> References: <51E8C5CD.6020306@oracle.com> Message-ID: <51EE30E3.70202@oracle.com> Expanding the net ... please :) David On 19/07/2013 2:51 PM, David Holmes wrote: > This is an enabler for the co-existence of our closed ppc sources and > the incoming ppc64 port. We need to be able to customize the source > directories and the excluded sources lists. > > We use the usual mechanism of -including the same named makefile from > the HS_ALT_MAKE directory. This one is a little unusual in that the > place where we do the -include is very, very specific. We have to do it > after the default setup of the sources/excludes and before that > information is used to generate the set of source files to compile. > > webrev: http://cr.openjdk.java.net/~dholmes/8020799/webrev.v3/ > > Pushing to hotspot-emb > > Thanks, > David > From vladimir.kozlov at oracle.com Tue Jul 23 00:48:15 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Jul 2013 00:48:15 -0700 Subject: (XS) RFR: 8020799 Allow customization of hotspot source directories and files In-Reply-To: <51EE30E3.70202@oracle.com> References: <51E8C5CD.6020306@oracle.com> <51EE30E3.70202@oracle.com> Message-ID: <51EE353F.4050207@oracle.com> Looks good. Vladimir On 7/23/13 12:29 AM, David Holmes wrote: > Expanding the net ... please :) > > David > > On 19/07/2013 2:51 PM, David Holmes wrote: >> This is an enabler for the co-existence of our closed ppc sources and >> the incoming ppc64 port. We need to be able to customize the source >> directories and the excluded sources lists. >> >> We use the usual mechanism of -including the same named makefile from >> the HS_ALT_MAKE directory. This one is a little unusual in that the >> place where we do the -include is very, very specific. We have to do it >> after the default setup of the sources/excludes and before that >> information is used to generate the set of source files to compile. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8020799/webrev.v3/ >> >> Pushing to hotspot-emb >> >> Thanks, >> David >> From david.holmes at oracle.com Tue Jul 23 00:54:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 17:54:01 +1000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51ED9024.3060208@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> Message-ID: <51EE3699.6000200@oracle.com> On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: > On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >> >> I don't really care about the guard. Just tell me what to do... > > To be safe leave guards with PPC64 check instead of _lp64 as you suggested. Yes please do that. I think the guard is important as this is a bit-neutral file. If/when someone creates a 32-bit PPC port we don't want them to have to re-discover the atomicity bugs with jlong/jdouble that were found on the existing platforms. Thanks, David > Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? : > > jniTypes_ppc.hpp: > > 48 #ifndef PPC64 > 49 #error "ppc32 support currently not implemented!!!" > 50 #endif // PPC64 > > Our reviews are based on assumption that this port only supports > PPC64+LP64 combination. Is this correct assumption? > > Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc > based macbook pro. But do we need it in this port? > > Regards, > Vladimir > >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Monday, July 22, 2013 6:48 PM >> To: Lindenmaier, Goetz >> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >> hotspot-dev at openjdk.java.net >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >> interpreter only VM. >> >> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>> ??? Or do you propose to change both of them to PPC64? >>> Yes, sure, I want to change both. >> >> Why do we need this error if this code is only for PPC64 port? We will >> have other compilation errors if we try to use >> these sources for something else as we found already. Do you have an >> other usage so you need this guard? >> >>>> All of the existing 64-bit ports have a direct correspondence between >>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>> >>> I know. And obviously there is a correspondence, as no one will >>> Implement an LG64 memory model on a 32 bit machine. >>> But the usage intermingles different memory model and architecture: >>> >>> E.g., the register declaration in register_x86_hpp is fine: >>> >>> #ifdef AMD64 >>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>> >>> But I think this makes no sense (assembler_x86.hpp): >>> >>> #ifdef _LP64 >>> void movsbq(Register dst, Address src); >>> void movsbq(Register dst, Register src); >>> // Move signed 32bit immediate to 64bit extending sign >>> void movslq(Address dst, int32_t imm64); >>> void movslq(Register dst, int32_t imm64); >>> >>> and should be guarded by AMD64. >> >> Strictly speaking you are right. But we will never do ilp32 for AMD64 >> so using _LP64 works for us. Also using AMD64 >> sometimes rise questions about Intel x64. So using _LP64 is more neutral. >> >>> And I want to get the PPC port right in such matters. >> >> I agree with this since ppc is more flexible than x86, it seems. >> >>> I'm currently removing the ppc_ prefixes ... big fun:) >> >> Sorry about that. >> >> Regards, >> Vladimir >> >>> Best regards, >>> >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Montag, 22. Juli 2013 13:38 >>> To: Lindenmaier, Goetz >>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>> >>> > Hi David, >>> >>> > >>> >>> > PPC64: describes an instruction set / machine with all it's >>> specialities. And the instruction set >>> >>> > we implemented the port for has an atomic 64-bit >>> instruction. >>> >>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>> , pointer == 64 bit. >>> >>> > In contraditction to ILP64 (int == 64bit) etc, which you could as >>> well implement with the >>> >>> > PPC64 instruction set. You could also implement a system with >>> ILP32 on PPC64, and then >>> >>> > you would have an atomic 64-bit instruction. >>> >>> That still doesn't explain why you think LP64 is okay for the atomic >>> >>> file but you want PPC64 for the orderAccess file. ??? Or do you propose >>> >>> to change both of them to PPC64? >>> >>> All of the existing 64-bit ports have a direct correspondence between >>> >>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 >>> >>> is the only 64-bit data model that the OpenJDK sources support. >>> >>> > Compressed oops make sense to protect with LP64, because they are >>> only helpful >>> >>> > with 64 bit pointers. While usage of LP64 is not exactly correct >>> here, ILP64, SLP64 >>> >>> > etc would also use compressed oops. But it's close enough I guess. >>> >>> I'm not concerned about compressed oops. No idea where that came from >>> ;-) >>> >>> David >>> >>> ------ >>> >>> > Best regards, >>> >>> > Goetz. >>> >>> > >>> >>> > -----Original Message----- >>> >>> > From: David Holmes [mailto:david.holmes at oracle.com] >>> >>> > Sent: Montag, 22. Juli 2013 05:27 >>> >>> > To: Lindenmaier, Goetz >>> >>> > Cc: hotspot-dev at openjdk.java.net >>> ; ppc-aix-port-dev at openjdk.java.net >>> ; Vladimir Kozlov >>> >>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>> for interpreter only VM. >>> >>> > >>> >>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>> >>> >> Hi David, >>> >>> >> >>> >>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>> >>> >>> 34 #ifndef _LP64 >>> >>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>> >>> >>> 36 #endif >>> >>> >> You're right, I'll fix this. >>> >>> >> If you don't object I'll guard it by PPC64 as it depends on the >>> >>> >> processor architecture and not the memory model. >>> >>> > >>> >>> > Is there some case where _LP64 would be true but PPC64 would not >>> be ??? >>> >>> > They seem effectively interchangeable but I don't know why you >>> would use >>> >>> > one in one file and the other in another file ?? >>> >>> > >>> >>> > Thanks, >>> >>> > David >>> >>> > >>> >>> >> If I will change the ppc_ prefixes that'll take a bit, especially >>> >>> >> as I will have to adapt all the alignments :(. >>> >>> >> But that does not matter, as we need to wait for your build >>> >>> >> change anyways. >>> >>> >> >>> >>> >> Best regards, >>> >>> >> Goetz. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> -----Original Message----- >>> >>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>> >>> >> Sent: Friday, July 19, 2013 7:29 AM >>> >>> >> To: Lindenmaier, Goetz >>> >>> >> Cc: hotspot-dev at openjdk.java.net >>> ; ppc-aix-port-dev at openjdk.java.net >>> ; Vladimir Kozlov >>> >>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>> for interpreter only VM. >>> >>> >> >>> >>> >> Hi Goetz, >>> >>> >> >>> >>> >> Only a brief glance through ... >>> >>> >> >>> >>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>> >>> >> >>> >>> >> 34 #ifndef _LP64 >>> >>> >> 35 #error "Atomic currently only impleneted for PPC64" >>> >>> >> 36 #endif >>> >>> >> >>> >>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>> will only >>> >>> >> be atomic on ppc64). >>> >>> >> >>> >>> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >>> >>> >> >>> >>> >> I also find the ppc_ prefix used in the assembly code somewhat >>> redundant. >>> >>> >> >>> >>> >> David >>> >>> >> ----- >>> >>> >> >>> >>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>> >>> >>> Hi, >>> >>> >>> >>> >>> >>> This time with webrev. Sorry for the double mails. >>> >>> >>> >>> >>> >>> This change contains all the files in cpu/ppc and >>> os_cpu/linux_ppc needed for >>> >>> >>> the PPC64 interpreter port on linux. >>> >>> >>> >>> >>> >>> With this change you can do a core build on ppc64 and run the >>> VM interpreter only. >>> >>> >>> It executes simple programs as jvm98. >>> >>> >>> The change requires >>> >>> >>> >>> >>> >>> * 8016697: Use stubs to implement safefetch >>> >>> >>> >>> >>> >>> * 8020059: The flag introduced by 8014972 is not >>> defined ... >>> >>> >>> which will arrive soon in the staging repository. >>> >>> >>> >>> >>> >>> I marked the change as XL as it contains a lot of code. >>> Nevertheless the >>> >>> >>> code has no impact on the existing Oracle platforms. >>> >>> >>> >>> >>> >>> The change touches a single shared file, globals.hpp, removing a >>> >>> >>> special case introduced for the port. This is because we >>> >>> >>> integrated some changes earlier than originally intended. >>> >>> >>> >>> >>> >>> Please review the change. Does it need testing on Oracle side? >>> >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>> >>> >>> >>> >>> >>> Best regards, >>> >>> >>> Goetz. >>> >>> >>> >>> From david.holmes at oracle.com Tue Jul 23 00:58:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 17:58:43 +1000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51EE3699.6000200@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> Message-ID: <51EE37B3.7090507@oracle.com> PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic copies for jlong are only correct on 64-bit. Is there other code in "bit-neutral" ppc files that is really only correct on 64-bit? David ----- On 23/07/2013 5:54 PM, David Holmes wrote: > On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>> >>> I don't really care about the guard. Just tell me what to do... >> >> To be safe leave guards with PPC64 check instead of _lp64 as you >> suggested. > > Yes please do that. I think the guard is important as this is a > bit-neutral file. If/when someone creates a 32-bit PPC port we don't > want them to have to re-discover the atomicity bugs with jlong/jdouble > that were found on the existing platforms. > > Thanks, > David > >> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? : >> >> jniTypes_ppc.hpp: >> >> 48 #ifndef PPC64 >> 49 #error "ppc32 support currently not implemented!!!" >> 50 #endif // PPC64 >> >> Our reviews are based on assumption that this port only supports >> PPC64+LP64 combination. Is this correct assumption? >> >> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >> based macbook pro. But do we need it in this port? >> >> Regards, >> Vladimir >> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Monday, July 22, 2013 6:48 PM >>> To: Lindenmaier, Goetz >>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>> ??? Or do you propose to change both of them to PPC64? >>>> Yes, sure, I want to change both. >>> >>> Why do we need this error if this code is only for PPC64 port? We will >>> have other compilation errors if we try to use >>> these sources for something else as we found already. Do you have an >>> other usage so you need this guard? >>> >>>>> All of the existing 64-bit ports have a direct correspondence between >>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>> >>>> I know. And obviously there is a correspondence, as no one will >>>> Implement an LG64 memory model on a 32 bit machine. >>>> But the usage intermingles different memory model and architecture: >>>> >>>> E.g., the register declaration in register_x86_hpp is fine: >>>> >>>> #ifdef AMD64 >>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>> >>>> But I think this makes no sense (assembler_x86.hpp): >>>> >>>> #ifdef _LP64 >>>> void movsbq(Register dst, Address src); >>>> void movsbq(Register dst, Register src); >>>> // Move signed 32bit immediate to 64bit extending sign >>>> void movslq(Address dst, int32_t imm64); >>>> void movslq(Register dst, int32_t imm64); >>>> >>>> and should be guarded by AMD64. >>> >>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>> so using _LP64 works for us. Also using AMD64 >>> sometimes rise questions about Intel x64. So using _LP64 is more >>> neutral. >>> >>>> And I want to get the PPC port right in such matters. >>> >>> I agree with this since ppc is more flexible than x86, it seems. >>> >>>> I'm currently removing the ppc_ prefixes ... big fun:) >>> >>> Sorry about that. >>> >>> Regards, >>> Vladimir >>> >>>> Best regards, >>>> >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Montag, 22. Juli 2013 13:38 >>>> To: Lindenmaier, Goetz >>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>> interpreter only VM. >>>> >>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>> >>>> > Hi David, >>>> >>>> > >>>> >>>> > PPC64: describes an instruction set / machine with all it's >>>> specialities. And the instruction set >>>> >>>> > we implemented the port for has an atomic 64-bit >>>> instruction. >>>> >>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>> , pointer == 64 bit. >>>> >>>> > In contraditction to ILP64 (int == 64bit) etc, which you could as >>>> well implement with the >>>> >>>> > PPC64 instruction set. You could also implement a system with >>>> ILP32 on PPC64, and then >>>> >>>> > you would have an atomic 64-bit instruction. >>>> >>>> That still doesn't explain why you think LP64 is okay for the atomic >>>> >>>> file but you want PPC64 for the orderAccess file. ??? Or do you propose >>>> >>>> to change both of them to PPC64? >>>> >>>> All of the existing 64-bit ports have a direct correspondence between >>>> >>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 >>>> >>>> is the only 64-bit data model that the OpenJDK sources support. >>>> >>>> > Compressed oops make sense to protect with LP64, because they are >>>> only helpful >>>> >>>> > with 64 bit pointers. While usage of LP64 is not exactly correct >>>> here, ILP64, SLP64 >>>> >>>> > etc would also use compressed oops. But it's close enough I guess. >>>> >>>> I'm not concerned about compressed oops. No idea where that came from >>>> ;-) >>>> >>>> David >>>> >>>> ------ >>>> >>>> > Best regards, >>>> >>>> > Goetz. >>>> >>>> > >>>> >>>> > -----Original Message----- >>>> >>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>> >>>> > Sent: Montag, 22. Juli 2013 05:27 >>>> >>>> > To: Lindenmaier, Goetz >>>> >>>> > Cc: hotspot-dev at openjdk.java.net >>>> ; >>>> ppc-aix-port-dev at openjdk.java.net >>>> ; Vladimir Kozlov >>>> >>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>> for interpreter only VM. >>>> >>>> > >>>> >>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>> >>>> >> Hi David, >>>> >>>> >> >>>> >>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>> >>>> >>> 34 #ifndef _LP64 >>>> >>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>> >>>> >>> 36 #endif >>>> >>>> >> You're right, I'll fix this. >>>> >>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>> >>>> >> processor architecture and not the memory model. >>>> >>>> > >>>> >>>> > Is there some case where _LP64 would be true but PPC64 would not >>>> be ??? >>>> >>>> > They seem effectively interchangeable but I don't know why you >>>> would use >>>> >>>> > one in one file and the other in another file ?? >>>> >>>> > >>>> >>>> > Thanks, >>>> >>>> > David >>>> >>>> > >>>> >>>> >> If I will change the ppc_ prefixes that'll take a bit, especially >>>> >>>> >> as I will have to adapt all the alignments :(. >>>> >>>> >> But that does not matter, as we need to wait for your build >>>> >>>> >> change anyways. >>>> >>>> >> >>>> >>>> >> Best regards, >>>> >>>> >> Goetz. >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> -----Original Message----- >>>> >>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>> >>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>> >>>> >> To: Lindenmaier, Goetz >>>> >>>> >> Cc: hotspot-dev at openjdk.java.net >>>> ; >>>> ppc-aix-port-dev at openjdk.java.net >>>> ; Vladimir Kozlov >>>> >>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>> for interpreter only VM. >>>> >>>> >> >>>> >>>> >> Hi Goetz, >>>> >>>> >> >>>> >>>> >> Only a brief glance through ... >>>> >>>> >> >>>> >>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>> >>>> >> >>>> >>>> >> 34 #ifndef _LP64 >>>> >>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>> >>>> >> 36 #endif >>>> >>>> >> >>>> >>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>> will only >>>> >>>> >> be atomic on ppc64). >>>> >>>> >> >>>> >>>> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >>>> >>>> >> >>>> >>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>> redundant. >>>> >>>> >> >>>> >>>> >> David >>>> >>>> >> ----- >>>> >>>> >> >>>> >>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>> >>>> >>> Hi, >>>> >>>> >>> >>>> >>>> >>> This time with webrev. Sorry for the double mails. >>>> >>>> >>> >>>> >>>> >>> This change contains all the files in cpu/ppc and >>>> os_cpu/linux_ppc needed for >>>> >>>> >>> the PPC64 interpreter port on linux. >>>> >>>> >>> >>>> >>>> >>> With this change you can do a core build on ppc64 and run the >>>> VM interpreter only. >>>> >>>> >>> It executes simple programs as jvm98. >>>> >>>> >>> The change requires >>>> >>>> >>> >>>> >>>> >>> * 8016697: Use stubs to implement safefetch >>>> >>>> >>> >>>> >>>> >>> * 8020059: The flag introduced by 8014972 is not >>>> defined ... >>>> >>>> >>> which will arrive soon in the staging repository. >>>> >>>> >>> >>>> >>>> >>> I marked the change as XL as it contains a lot of code. >>>> Nevertheless the >>>> >>>> >>> code has no impact on the existing Oracle platforms. >>>> >>>> >>> >>>> >>>> >>> The change touches a single shared file, globals.hpp, removing a >>>> >>>> >>> special case introduced for the port. This is because we >>>> >>>> >>> integrated some changes earlier than originally intended. >>>> >>>> >>> >>>> >>>> >>> Please review the change. Does it need testing on Oracle side? >>>> >>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>> >>>> >>> >>>> >>>> >>> Best regards, >>>> >>>> >>> Goetz. >>>> >>>> >>> >>>> From goetz.lindenmaier at sap.com Tue Jul 23 01:33:22 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 23 Jul 2013 08:33:22 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51EE37B3.7090507@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF6D42@DEWDFEMB12A.global.corp.sap> Hi, I'd assume there are many, but with others it will be more obvious. I think atomic is important, as the bugs are hard to catch. On x86, the files below contain either LP64, AMD64 or IA32 (even files with bit extension!). I don't think it's helpful if we add the define in all these files. Best regards, Goetz. assembler_x86.cpp assembler_x86.hpp assembler_x86.inline.hpp bytecodeInterpreter_x86.inline.hpp bytes_x86.hpp c1_CodeStubs_x86.cpp c1_Defs_x86.hpp c1_FrameMap_x86.cpp c1_FrameMap_x86.hpp c1_LinearScan_x86.hpp c1_LIRAssembler_x86.cpp c1_LIRAssembler_x86.hpp c1_LIRGenerator_x86.cpp c1_MacroAssembler_x86.cpp c1_Runtime1_x86.cpp c2_globals_x86.hpp c2_init_x86.cpp copy_x86.hpp compiledIC_x86.cpp cppInterpreter_x86.cpp frame_x86.cpp frame_x86.hpp globals_x86.hpp icache_x86.cpp icache_x86.hpp interp_masm_x86_32.cpp interpreter_x86.hpp interpreterRT_x86.hpp jniFastGetField_x86_32.cpp jniTypes_x86.hpp jni_x86.h macroAssembler_x86.cpp macroAssembler_x86.hpp methodHandles_x86.cpp methodHandles_x86.hpp nativeInst_x86.cpp nativeInst_x86.hpp register_definitions_x86.cpp register_x86.cpp register_x86.hpp relocInfo_x86.cpp relocInfo_x86.hpp sharedRuntime_x86_32.cpp sharedRuntime_x86_64.cpp templateInterpreter_x86.hpp templateTable_x86_32.cpp vmreg_x86.cpp vmreg_x86.inline.hpp vm_version_x86.cpp x86_32.ad -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 23. Juli 2013 09:59 To: Lindenmaier, Goetz Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic copies for jlong are only correct on 64-bit. Is there other code in "bit-neutral" ppc files that is really only correct on 64-bit? David ----- On 23/07/2013 5:54 PM, David Holmes wrote: > On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>> >>> I don't really care about the guard. Just tell me what to do... >> >> To be safe leave guards with PPC64 check instead of _lp64 as you >> suggested. > > Yes please do that. I think the guard is important as this is a > bit-neutral file. If/when someone creates a 32-bit PPC port we don't > want them to have to re-discover the atomicity bugs with jlong/jdouble > that were found on the existing platforms. > > Thanks, > David > >> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? : >> >> jniTypes_ppc.hpp: >> >> 48 #ifndef PPC64 >> 49 #error "ppc32 support currently not implemented!!!" >> 50 #endif // PPC64 >> >> Our reviews are based on assumption that this port only supports >> PPC64+LP64 combination. Is this correct assumption? >> >> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >> based macbook pro. But do we need it in this port? >> >> Regards, >> Vladimir >> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Monday, July 22, 2013 6:48 PM >>> To: Lindenmaier, Goetz >>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>> ??? Or do you propose to change both of them to PPC64? >>>> Yes, sure, I want to change both. >>> >>> Why do we need this error if this code is only for PPC64 port? We will >>> have other compilation errors if we try to use >>> these sources for something else as we found already. Do you have an >>> other usage so you need this guard? >>> >>>>> All of the existing 64-bit ports have a direct correspondence between >>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>> >>>> I know. And obviously there is a correspondence, as no one will >>>> Implement an LG64 memory model on a 32 bit machine. >>>> But the usage intermingles different memory model and architecture: >>>> >>>> E.g., the register declaration in register_x86_hpp is fine: >>>> >>>> #ifdef AMD64 >>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>> >>>> But I think this makes no sense (assembler_x86.hpp): >>>> >>>> #ifdef _LP64 >>>> void movsbq(Register dst, Address src); >>>> void movsbq(Register dst, Register src); >>>> // Move signed 32bit immediate to 64bit extending sign >>>> void movslq(Address dst, int32_t imm64); >>>> void movslq(Register dst, int32_t imm64); >>>> >>>> and should be guarded by AMD64. >>> >>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>> so using _LP64 works for us. Also using AMD64 >>> sometimes rise questions about Intel x64. So using _LP64 is more >>> neutral. >>> >>>> And I want to get the PPC port right in such matters. >>> >>> I agree with this since ppc is more flexible than x86, it seems. >>> >>>> I'm currently removing the ppc_ prefixes ... big fun:) >>> >>> Sorry about that. >>> >>> Regards, >>> Vladimir >>> >>>> Best regards, >>>> >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Montag, 22. Juli 2013 13:38 >>>> To: Lindenmaier, Goetz >>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>> interpreter only VM. >>>> >>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>> >>>> > Hi David, >>>> >>>> > >>>> >>>> > PPC64: describes an instruction set / machine with all it's >>>> specialities. And the instruction set >>>> >>>> > we implemented the port for has an atomic 64-bit >>>> instruction. >>>> >>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>> , pointer == 64 bit. >>>> >>>> > In contraditction to ILP64 (int == 64bit) etc, which you could as >>>> well implement with the >>>> >>>> > PPC64 instruction set. You could also implement a system with >>>> ILP32 on PPC64, and then >>>> >>>> > you would have an atomic 64-bit instruction. >>>> >>>> That still doesn't explain why you think LP64 is okay for the atomic >>>> >>>> file but you want PPC64 for the orderAccess file. ??? Or do you propose >>>> >>>> to change both of them to PPC64? >>>> >>>> All of the existing 64-bit ports have a direct correspondence between >>>> >>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 >>>> >>>> is the only 64-bit data model that the OpenJDK sources support. >>>> >>>> > Compressed oops make sense to protect with LP64, because they are >>>> only helpful >>>> >>>> > with 64 bit pointers. While usage of LP64 is not exactly correct >>>> here, ILP64, SLP64 >>>> >>>> > etc would also use compressed oops. But it's close enough I guess. >>>> >>>> I'm not concerned about compressed oops. No idea where that came from >>>> ;-) >>>> >>>> David >>>> >>>> ------ >>>> >>>> > Best regards, >>>> >>>> > Goetz. >>>> >>>> > >>>> >>>> > -----Original Message----- >>>> >>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>> >>>> > Sent: Montag, 22. Juli 2013 05:27 >>>> >>>> > To: Lindenmaier, Goetz >>>> >>>> > Cc: hotspot-dev at openjdk.java.net >>>> ; >>>> ppc-aix-port-dev at openjdk.java.net >>>> ; Vladimir Kozlov >>>> >>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>> for interpreter only VM. >>>> >>>> > >>>> >>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>> >>>> >> Hi David, >>>> >>>> >> >>>> >>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>> >>>> >>> 34 #ifndef _LP64 >>>> >>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>> >>>> >>> 36 #endif >>>> >>>> >> You're right, I'll fix this. >>>> >>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>> >>>> >> processor architecture and not the memory model. >>>> >>>> > >>>> >>>> > Is there some case where _LP64 would be true but PPC64 would not >>>> be ??? >>>> >>>> > They seem effectively interchangeable but I don't know why you >>>> would use >>>> >>>> > one in one file and the other in another file ?? >>>> >>>> > >>>> >>>> > Thanks, >>>> >>>> > David >>>> >>>> > >>>> >>>> >> If I will change the ppc_ prefixes that'll take a bit, especially >>>> >>>> >> as I will have to adapt all the alignments :(. >>>> >>>> >> But that does not matter, as we need to wait for your build >>>> >>>> >> change anyways. >>>> >>>> >> >>>> >>>> >> Best regards, >>>> >>>> >> Goetz. >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> -----Original Message----- >>>> >>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>> >>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>> >>>> >> To: Lindenmaier, Goetz >>>> >>>> >> Cc: hotspot-dev at openjdk.java.net >>>> ; >>>> ppc-aix-port-dev at openjdk.java.net >>>> ; Vladimir Kozlov >>>> >>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>> for interpreter only VM. >>>> >>>> >> >>>> >>>> >> Hi Goetz, >>>> >>>> >> >>>> >>>> >> Only a brief glance through ... >>>> >>>> >> >>>> >>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>> >>>> >> >>>> >>>> >> 34 #ifndef _LP64 >>>> >>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>> >>>> >> 36 #endif >>>> >>>> >> >>>> >>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>> will only >>>> >>>> >> be atomic on ppc64). >>>> >>>> >> >>>> >>>> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >>>> >>>> >> >>>> >>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>> redundant. >>>> >>>> >> >>>> >>>> >> David >>>> >>>> >> ----- >>>> >>>> >> >>>> >>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>> >>>> >>> Hi, >>>> >>>> >>> >>>> >>>> >>> This time with webrev. Sorry for the double mails. >>>> >>>> >>> >>>> >>>> >>> This change contains all the files in cpu/ppc and >>>> os_cpu/linux_ppc needed for >>>> >>>> >>> the PPC64 interpreter port on linux. >>>> >>>> >>> >>>> >>>> >>> With this change you can do a core build on ppc64 and run the >>>> VM interpreter only. >>>> >>>> >>> It executes simple programs as jvm98. >>>> >>>> >>> The change requires >>>> >>>> >>> >>>> >>>> >>> * 8016697: Use stubs to implement safefetch >>>> >>>> >>> >>>> >>>> >>> * 8020059: The flag introduced by 8014972 is not >>>> defined ... >>>> >>>> >>> which will arrive soon in the staging repository. >>>> >>>> >>> >>>> >>>> >>> I marked the change as XL as it contains a lot of code. >>>> Nevertheless the >>>> >>>> >>> code has no impact on the existing Oracle platforms. >>>> >>>> >>> >>>> >>>> >>> The change touches a single shared file, globals.hpp, removing a >>>> >>>> >>> special case introduced for the port. This is because we >>>> >>>> >>> integrated some changes earlier than originally intended. >>>> >>>> >>> >>>> >>>> >>> Please review the change. Does it need testing on Oracle side? >>>> >>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>> >>>> >>> >>>> >>>> >>> Best regards, >>>> >>>> >>> Goetz. >>>> >>>> >>> >>>> From volker.simonis at gmail.com Tue Jul 23 01:46:51 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Jul 2013 10:46:51 +0200 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51ED9024.3060208@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> Message-ID: On Mon, Jul 22, 2013 at 10:03 PM, Vladimir Kozlov wrote: > On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> I updated the webrev. The code is not without ppc_ and PPC_ >> prefixes. >> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >> You can have a look at it, and if you have further comments regarding >> the style it would be nice to get them early. I still have to adapt all >> the remaining changes in the patch queue, and then test it with the >> compiler. With that I obviously can run more tests. > > > In general it is good. Few notes. > > MacroAssembler::encode_klass_not_null() is wrong. LogKlassAlignmentInBytes > should be used or Universe::narrow_klass_shift() in hs25 since klasses were > moved to metaspace. > Try to run tests with LogMinObjAlignmentInBytes=16 (=32). > > BTW, the new implementation is coming which will have separate base for > compressed classes: 8003424. There was review sent last week. So using r30 > unconditionally will be incorrect. > > >> >> I don't really care about the guard. Just tell me what to do... > > > To be safe leave guards with PPC64 check instead of _lp64 as you suggested. > > Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? : > > jniTypes_ppc.hpp: > > 48 #ifndef PPC64 > 49 #error "ppc32 support currently not implemented!!!" > 50 #endif // PPC64 > > Our reviews are based on assumption that this port only supports PPC64+LP64 > combination. Is this correct assumption? > > Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc > based macbook pro. But do we need it in this port? > It's a leftover from x86/vm/jni_x86.h in jdk7u ("7098194: integrate macosx-port changes") which we used as a boilerplate. We will remove it. > > Regards, > Vladimir > >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Monday, July 22, 2013 6:48 PM >> To: Lindenmaier, Goetz >> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >> hotspot-dev at openjdk.java.net >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >> interpreter only VM. >> >> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>> >>>> ??? Or do you propose to change both of them to PPC64? >>> >>> Yes, sure, I want to change both. >> >> >> Why do we need this error if this code is only for PPC64 port? We will >> have other compilation errors if we try to use >> these sources for something else as we found already. Do you have an other >> usage so you need this guard? >> >>>> All of the existing 64-bit ports have a direct correspondence between >>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>> >>> >>> I know. And obviously there is a correspondence, as no one will >>> Implement an LG64 memory model on a 32 bit machine. >>> But the usage intermingles different memory model and architecture: >>> >>> E.g., the register declaration in register_x86_hpp is fine: >>> >>> #ifdef AMD64 >>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>> >>> But I think this makes no sense (assembler_x86.hpp): >>> >>> #ifdef _LP64 >>> void movsbq(Register dst, Address src); >>> void movsbq(Register dst, Register src); >>> // Move signed 32bit immediate to 64bit extending sign >>> void movslq(Address dst, int32_t imm64); >>> void movslq(Register dst, int32_t imm64); >>> >>> and should be guarded by AMD64. >> >> >> Strictly speaking you are right. But we will never do ilp32 for AMD64 so >> using _LP64 works for us. Also using AMD64 >> sometimes rise questions about Intel x64. So using _LP64 is more neutral. >> >>> And I want to get the PPC port right in such matters. >> >> >> I agree with this since ppc is more flexible than x86, it seems. >> >>> I'm currently removing the ppc_ prefixes ... big fun:) >> >> >> Sorry about that. >> >> Regards, >> Vladimir >> >>> Best regards, >>> >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Montag, 22. Juli 2013 13:38 >>> To: Lindenmaier, Goetz >>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>> >>> > Hi David, >>> >>> > >>> >>> > PPC64: describes an instruction set / machine with all it's >>> specialities. And the instruction set >>> >>> > we implemented the port for has an atomic 64-bit >>> instruction. >>> >>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit , >>> pointer == 64 bit. >>> >>> > In contraditction to ILP64 (int == 64bit) etc, which you could as >>> well implement with the >>> >>> > PPC64 instruction set. You could also implement a system with ILP32 >>> on PPC64, and then >>> >>> > you would have an atomic 64-bit instruction. >>> >>> That still doesn't explain why you think LP64 is okay for the atomic >>> >>> file but you want PPC64 for the orderAccess file. ??? Or do you propose >>> >>> to change both of them to PPC64? >>> >>> All of the existing 64-bit ports have a direct correspondence between >>> >>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 >>> >>> is the only 64-bit data model that the OpenJDK sources support. >>> >>> > Compressed oops make sense to protect with LP64, because they are >>> only helpful >>> >>> > with 64 bit pointers. While usage of LP64 is not exactly correct >>> here, ILP64, SLP64 >>> >>> > etc would also use compressed oops. But it's close enough I guess. >>> >>> I'm not concerned about compressed oops. No idea where that came from ;-) >>> >>> David >>> >>> ------ >>> >>> > Best regards, >>> >>> > Goetz. >>> >>> > >>> >>> > -----Original Message----- >>> >>> > From: David Holmes [mailto:david.holmes at oracle.com] >>> >>> > Sent: Montag, 22. Juli 2013 05:27 >>> >>> > To: Lindenmaier, Goetz >>> >>> > Cc: hotspot-dev at openjdk.java.net >>> ; ppc-aix-port-dev at openjdk.java.net >>> ; Vladimir Kozlov >>> >>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> > >>> >>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>> >>> >> Hi David, >>> >>> >> >>> >>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>> >>> >>> 34 #ifndef _LP64 >>> >>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>> >>> >>> 36 #endif >>> >>> >> You're right, I'll fix this. >>> >>> >> If you don't object I'll guard it by PPC64 as it depends on the >>> >>> >> processor architecture and not the memory model. >>> >>> > >>> >>> > Is there some case where _LP64 would be true but PPC64 would not be >>> ??? >>> >>> > They seem effectively interchangeable but I don't know why you would >>> use >>> >>> > one in one file and the other in another file ?? >>> >>> > >>> >>> > Thanks, >>> >>> > David >>> >>> > >>> >>> >> If I will change the ppc_ prefixes that'll take a bit, especially >>> >>> >> as I will have to adapt all the alignments :(. >>> >>> >> But that does not matter, as we need to wait for your build >>> >>> >> change anyways. >>> >>> >> >>> >>> >> Best regards, >>> >>> >> Goetz. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> -----Original Message----- >>> >>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>> >>> >> Sent: Friday, July 19, 2013 7:29 AM >>> >>> >> To: Lindenmaier, Goetz >>> >>> >> Cc: hotspot-dev at openjdk.java.net >>> ; ppc-aix-port-dev at openjdk.java.net >>> ; Vladimir Kozlov >>> >>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> >> >>> >>> >> Hi Goetz, >>> >>> >> >>> >>> >> Only a brief glance through ... >>> >>> >> >>> >>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>> >>> >> >>> >>> >> 34 #ifndef _LP64 >>> >>> >> 35 #error "Atomic currently only impleneted for PPC64" >>> >>> >> 36 #endif >>> >>> >> >>> >>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants will >>> only >>> >>> >> be atomic on ppc64). >>> >>> >> >>> >>> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >>> >>> >> >>> >>> >> I also find the ppc_ prefix used in the assembly code somewhat >>> redundant. >>> >>> >> >>> >>> >> David >>> >>> >> ----- >>> >>> >> >>> >>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>> >>> >>> Hi, >>> >>> >>> >>> >>> >>> This time with webrev. Sorry for the double mails. >>> >>> >>> >>> >>> >>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc >>> needed for >>> >>> >>> the PPC64 interpreter port on linux. >>> >>> >>> >>> >>> >>> With this change you can do a core build on ppc64 and run the VM >>> interpreter only. >>> >>> >>> It executes simple programs as jvm98. >>> >>> >>> The change requires >>> >>> >>> >>> >>> >>> * 8016697: Use stubs to implement safefetch >>> >>> >>> >>> >>> >>> * 8020059: The flag introduced by 8014972 is not defined >>> ... >>> >>> >>> which will arrive soon in the staging repository. >>> >>> >>> >>> >>> >>> I marked the change as XL as it contains a lot of code. >>> Nevertheless the >>> >>> >>> code has no impact on the existing Oracle platforms. >>> >>> >>> >>> >>> >>> The change touches a single shared file, globals.hpp, removing a >>> >>> >>> special case introduced for the port. This is because we >>> >>> >>> integrated some changes earlier than originally intended. >>> >>> >>> >>> >>> >>> Please review the change. Does it need testing on Oracle side? >>> >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>> >>> >>> >>> >>> >>> Best regards, >>> >>> >>> Goetz. >>> >>> >>> >>> > From daniel.daugherty at oracle.com Tue Jul 23 08:09:54 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 23 Jul 2013 09:09:54 -0600 Subject: Review request for JDK-8019632: Method parameters are not copied in clone_with_new_data In-Reply-To: <51EC936D.3030000@oracle.com> References: <51E75BCA.5030604@oracle.com> <51E7EFD0.906@oracle.com> <51E80822.3040307@oracle.com> <51EC936D.3030000@oracle.com> Message-ID: <51EE9CC2.70303@oracle.com> > http://cr.openjdk.java.net/~emc/8019632/webrev.01/ src/share/vm/oops/method.cpp No comments. Thumbs up! Dan On 7/21/13 8:05 PM, Eric McCorkle wrote: > I've written a test based on that one. However, as it is in jdk/, it > will need to go into TL, which means it will need to wait until > propagation from hsx. > > In any case, it succeeds, and I now have a clean ute (testlist aka. > everything) and jprt run. > > Do I have a second for this change? > > On 07/18/13 11:22, Coleen Phillmore wrote: >> Eric, >> This code change looks good. For the related bug that didn't copy >> method annotations, I added test: >> jdk/test/java/lang/instrument/RedefineMethodWithAnnotations.sh. Can you >> use this test to write a new one to the JDK that demonstrates this bug? >> We've been adding these tests to the JDK because it has the support >> there and all the other tests are there. >> >> Thanks, >> Coleen >> >> On 7/18/2013 9:38 AM, Eric McCorkle wrote: >>> Realized I'd duplicated a comment. It's been corrected. >>> >>> On 07/17/13 23:06, Eric McCorkle wrote: >>>> Hello, >>>> >>>> Please review this patch, which updates clone_with_new_data to copy >>>> method parameter data. This was missed in the initial implementation. >>>> >>>> I've gotten a JPRT run that failed only due to running out of memory on >>>> some tests, and I'll be doing my usual complete testlist run soon. >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~emc/8019632/ >>>> >>>> The bug report is here: >>>> http://bugs.sun.com/view_bug.do?bug_id=8019632 >>>> >>>> Thanks, >>>> Eric >>>> From volker.simonis at gmail.com Tue Jul 23 09:30:53 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Jul 2013 18:30:53 +0200 Subject: AArch64 port first release In-Reply-To: <51DACBC1.7050601@redhat.com> References: <51DACBC1.7050601@redhat.com> Message-ID: Hi Andrew, Henrik, congratulations! This is really good news. I just got really puzzeled when I read the recent Oracle/ARM announcement: "ARM AND ORACLE ANNOUNCE PLANS TO OPTIMIZE JAVA SE FOR ENTERPRISE AND EMBEDDED MARKETS" (http://www.arm.com/about/newsroom/arm-and-oracle-announce-plans-to-optimize-java-se-for-enterprise-and-embedded-markets.php) They announced that "ARM ... has entered into a multi-year agreement with Oracle to further optimize the existing Java Platform, Standard Edition (Java SE) for ARM? 32-bit platforms and to add Java SE support for ARMv8 64-bit platforms." How does this agreement affects the AArch64 OpenJDK port? Henrik, I think it would be really sad if Oracle would start a competing, closed ARMv8 64-bit port on their own. Or are there any plans to merge the porting efforts in the OpenJDK? At least in the ARM announcement the word OpenJDK (or even 'open' :) isn't mentioned with a single word! Thank you and best regards, Volker On Mon, Jul 8, 2013 at 4:25 PM, Andrew Haley wrote: > I'm pleased to announce our first release of Java for the ARMv8 > 64-bit architecture. This is a whole new port, completely > unrelated to to the 32-bit ARM JDK. > http://en.wikipedia.org/wiki/AArch64#ARMv8_and_64-bit > > > Project status: > > This port is still very much a work in progress, but it passes > its tests and it's good enough to run most Java programs. > > It is not complete. We're missing support for optional features > such as biased locking and JVMTI. Also, it's rather scrappy in > some places and the code could be more efficient and more > idiomatic in many other places. Patches welcome! > > The template interpreter and the C1 compiler are done. The C2 > compiler is still at a rather early stage. > > You don't need an ARMv8 to test and run the port. We've written a > small simulator that links into the JVM, so you can run this port just > like native Java on any 64-bit x86 GNU/Linux system. We also provide > advanced debugging capabilities via a set of GDB extensions. This > provides the best interactive debugging environment that I have ever > seen for a Java VM. You also can run on ARM's Fast Model if you > prefer. > > We've provided full build instructions, but we'll help you if you get > stuck. We want people to try it out. > > I feel that I have to end with an apology. When I started this port I > wanted it to be an exemplary free software project: open discussion, > open development, and the free exchange of ideas. It hasn't worked > out that way. We needed very detailed technical information about the > ARMv8 architecture long before it was made public, and ARM were kind > enough to give us what we needed. However, there was a caveat: we > couldn't make it public. So, we've been in stealth mode until a few > weeks ago. My thanks go out to the legal teams who worked hard to > make this release possible. > > Also, a big shout to Mark Reinhold for sorting out all the crazy > problems we had with OpenJDK's source code repository. > > > http://hg.openjdk.java.net/aarch64-port/jdk8/raw-file/tip/README.aarch64 > > Web: http://openjdk.java.net/projects/aarch64-port/ > > Mailing list: http://mail.openjdk.java.net/mailman/listinfo/aarch64-port-dev > > > Andrew. From aph at redhat.com Tue Jul 23 09:35:56 2013 From: aph at redhat.com (Andrew Haley) Date: Tue, 23 Jul 2013 17:35:56 +0100 Subject: AArch64 port first release In-Reply-To: References: <51DACBC1.7050601@redhat.com> Message-ID: <51EEB0EC.3080902@redhat.com> On 07/23/2013 05:30 PM, Volker Simonis wrote: > Hi Andrew, Henrik, > > congratulations! This is really good news. > > I just got really puzzeled when I read the recent Oracle/ARM announcement: > > "ARM AND ORACLE ANNOUNCE PLANS TO OPTIMIZE JAVA SE FOR ENTERPRISE AND > EMBEDDED MARKETS" > (http://www.arm.com/about/newsroom/arm-and-oracle-announce-plans-to-optimize-java-se-for-enterprise-and-embedded-markets.php) > > They announced that "ARM ... has entered into a multi-year agreement > with Oracle to further optimize the existing Java Platform, Standard > Edition (Java SE) for ARM? 32-bit platforms and to add Java SE support > for ARMv8 64-bit platforms." > > How does this agreement affects the AArch64 OpenJDK port? I don't think it affects it at all. Even if there is to be a proprietary port, we'll still need a free one. And we'll still need the free one to be of the highest quality. So, whatever happens, we must press ahead. Andrew. From dean.long at oracle.com Tue Jul 23 10:49:33 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 23 Jul 2013 10:49:33 -0700 Subject: (XS) RFR: 8020799 Allow customization of hotspot source directories and files In-Reply-To: <51EE30E3.70202@oracle.com> References: <51E8C5CD.6020306@oracle.com> <51EE30E3.70202@oracle.com> Message-ID: <51EEC22D.1020400@oracle.com> It's good. Reviewed. dl On 7/23/2013 12:29 AM, David Holmes wrote: > Expanding the net ... please :) > > David > > On 19/07/2013 2:51 PM, David Holmes wrote: >> This is an enabler for the co-existence of our closed ppc sources and >> the incoming ppc64 port. We need to be able to customize the source >> directories and the excluded sources lists. >> >> We use the usual mechanism of -including the same named makefile from >> the HS_ALT_MAKE directory. This one is a little unusual in that the >> place where we do the -include is very, very specific. We have to do it >> after the default setup of the sources/excludes and before that >> information is used to generate the set of source files to compile. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8020799/webrev.v3/ >> >> Pushing to hotspot-emb >> >> Thanks, >> David >> From jeremymanson at google.com Tue Jul 23 11:37:32 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 23 Jul 2013 11:37:32 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <0F64EB55-B38C-416E-93D1-92BA8F5D43C7@oracle.com> References: <51D494E9.2020200@oracle.com> <51DDB632.4050805@oracle.com> <0F64EB55-B38C-416E-93D1-92BA8F5D43C7@oracle.com> Message-ID: Okay, Bob, thanks for the explanation. I may not agree with it, but I can certainly see where you're coming from. Jeremy On Tue, Jul 16, 2013 at 2:44 PM, Bob Vandette wrote: > Thanks for the suggestion Jeremy but the JVMTI agent change is being > implemented as part of the > original JNI static library implementation where we explicitly prohibited > dynamic libraries to be loaded > if a static library of the same name is baked into the launcher. > > "If a library L is statically linked then it will be prohibited to link a > library of the same name dynamically." > > The primary motivation for requiring this for the -agentpath as well as > the java.lang.System.load API is to > minimize changes to java source code. You can statically or dynamically > link a library without changing > any of the code that attempts to use the library. The only thing that > changes is the OnLoad name in the library > and the link options. > > If you'd like to optionally use different implementations, you can end up > with the same behavior by using a > System property which alters the String of the name of the library. > > Bob. > > > On Jul 10, 2013, at 3:29 PM, BILL PITTORE wrote: > > On 7/3/2013 6:32 PM, Jeremy Manson wrote: > > I know that this is mentioned in the JEP, but does it really make sense to > have -agentpath work here, rather than just -agentlib? I would think that > specifying a full pathname and getting the library loaded out of the > launcher would be a little surprising to people who are basically saying > "please load this agent from the given path". > > > Also, in practice, we do something very similar at Google, and, when > testing, I find it occasionally useful to be able to say "please load this > agent on the command line via the agentpath I gave you, rather than loading > the one with the same name I baked into the launcher". > > > (FWIW, when we did this internally at Google, we added a special -XX flag > for when the agent is in the launcher. I know that you don't want to go > that way, though.) > > > Thanks for the comments. I would say the thinking here is that we want > this to be as transparent as possible to the end user. In our view of the > end user is someone perhaps using an IDE and the actual execution of the VM > with agent arguments is hidden. In your case it sounds like you are > actually developing agents which is a whole different ball game. I could > certainly see adding a -XX argument that forces agentpath to load the > external library which would be good for agent development and debugging. > No need to relink the entire VM with the new agent. Our tech lead is out on > vacation this week so I'll bring this up when he's back. > > bill > > > On Wed, Jul 3, 2013 at 2:17 PM, BILL PITTORE mailto:bill.pittore at oracle.com >> wrote: > > > These changes address bug 8014135 which adds support for > > statically linked agents in the VM. This is a followup to the > > recent JNI spec changes that addressed statically linked JNI > > libraries( 8005716). > > The JEP for this change is the same JEP as the JNI changes: > > http://openjdk.java.net/jeps/178 > > > Webrevs are here: > > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > > > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ > > > > > The changes to jvmti.xml can also be seen in the output file that > > I placed here: > > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html > > < > http://cr.openjdk.java.net/%7Ebpittore/8014135/hotspot/webrev.00/jvmti.html > > > > > Thanks, > > bill > > > > > > > From goetz.lindenmaier at sap.com Wed Jul 24 07:46:11 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Jul 2013 14:46:11 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51EE37B3.7090507@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> Hi, I updated the webrev once more. http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ - I fixed encode_klass_not_null() - I cleaned up jni_ppc.h - added the guard in copy_ppc.hpp. Further there were problems on aix. I had to rename the condition code registers from CR0-7 to CCR0-7, as CR0-3 is defined in an AIX system header. David, can I mark the change as reviewed by you? Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 23. Juli 2013 09:59 To: Lindenmaier, Goetz Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic copies for jlong are only correct on 64-bit. Is there other code in "bit-neutral" ppc files that is really only correct on 64-bit? David ----- On 23/07/2013 5:54 PM, David Holmes wrote: > On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>> >>> I don't really care about the guard. Just tell me what to do... >> >> To be safe leave guards with PPC64 check instead of _lp64 as you >> suggested. > > Yes please do that. I think the guard is important as this is a > bit-neutral file. If/when someone creates a 32-bit PPC port we don't > want them to have to re-discover the atomicity bugs with jlong/jdouble > that were found on the existing platforms. > > Thanks, > David > >> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? : >> >> jniTypes_ppc.hpp: >> >> 48 #ifndef PPC64 >> 49 #error "ppc32 support currently not implemented!!!" >> 50 #endif // PPC64 >> >> Our reviews are based on assumption that this port only supports >> PPC64+LP64 combination. Is this correct assumption? >> >> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >> based macbook pro. But do we need it in this port? >> >> Regards, >> Vladimir >> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Monday, July 22, 2013 6:48 PM >>> To: Lindenmaier, Goetz >>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>> ??? Or do you propose to change both of them to PPC64? >>>> Yes, sure, I want to change both. >>> >>> Why do we need this error if this code is only for PPC64 port? We will >>> have other compilation errors if we try to use >>> these sources for something else as we found already. Do you have an >>> other usage so you need this guard? >>> >>>>> All of the existing 64-bit ports have a direct correspondence between >>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>> >>>> I know. And obviously there is a correspondence, as no one will >>>> Implement an LG64 memory model on a 32 bit machine. >>>> But the usage intermingles different memory model and architecture: >>>> >>>> E.g., the register declaration in register_x86_hpp is fine: >>>> >>>> #ifdef AMD64 >>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>> >>>> But I think this makes no sense (assembler_x86.hpp): >>>> >>>> #ifdef _LP64 >>>> void movsbq(Register dst, Address src); >>>> void movsbq(Register dst, Register src); >>>> // Move signed 32bit immediate to 64bit extending sign >>>> void movslq(Address dst, int32_t imm64); >>>> void movslq(Register dst, int32_t imm64); >>>> >>>> and should be guarded by AMD64. >>> >>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>> so using _LP64 works for us. Also using AMD64 >>> sometimes rise questions about Intel x64. So using _LP64 is more >>> neutral. >>> >>>> And I want to get the PPC port right in such matters. >>> >>> I agree with this since ppc is more flexible than x86, it seems. >>> >>>> I'm currently removing the ppc_ prefixes ... big fun:) >>> >>> Sorry about that. >>> >>> Regards, >>> Vladimir >>> >>>> Best regards, >>>> >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Montag, 22. Juli 2013 13:38 >>>> To: Lindenmaier, Goetz >>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>> interpreter only VM. >>>> >>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>> >>>> > Hi David, >>>> >>>> > >>>> >>>> > PPC64: describes an instruction set / machine with all it's >>>> specialities. And the instruction set >>>> >>>> > we implemented the port for has an atomic 64-bit >>>> instruction. >>>> >>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>> , pointer == 64 bit. >>>> >>>> > In contraditction to ILP64 (int == 64bit) etc, which you could as >>>> well implement with the >>>> >>>> > PPC64 instruction set. You could also implement a system with >>>> ILP32 on PPC64, and then >>>> >>>> > you would have an atomic 64-bit instruction. >>>> >>>> That still doesn't explain why you think LP64 is okay for the atomic >>>> >>>> file but you want PPC64 for the orderAccess file. ??? Or do you propose >>>> >>>> to change both of them to PPC64? >>>> >>>> All of the existing 64-bit ports have a direct correspondence between >>>> >>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 >>>> >>>> is the only 64-bit data model that the OpenJDK sources support. >>>> >>>> > Compressed oops make sense to protect with LP64, because they are >>>> only helpful >>>> >>>> > with 64 bit pointers. While usage of LP64 is not exactly correct >>>> here, ILP64, SLP64 >>>> >>>> > etc would also use compressed oops. But it's close enough I guess. >>>> >>>> I'm not concerned about compressed oops. No idea where that came from >>>> ;-) >>>> >>>> David >>>> >>>> ------ >>>> >>>> > Best regards, >>>> >>>> > Goetz. >>>> >>>> > >>>> >>>> > -----Original Message----- >>>> >>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>> >>>> > Sent: Montag, 22. Juli 2013 05:27 >>>> >>>> > To: Lindenmaier, Goetz >>>> >>>> > Cc: hotspot-dev at openjdk.java.net >>>> ; >>>> ppc-aix-port-dev at openjdk.java.net >>>> ; Vladimir Kozlov >>>> >>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>> for interpreter only VM. >>>> >>>> > >>>> >>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>> >>>> >> Hi David, >>>> >>>> >> >>>> >>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>> >>>> >>> 34 #ifndef _LP64 >>>> >>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>> >>>> >>> 36 #endif >>>> >>>> >> You're right, I'll fix this. >>>> >>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>> >>>> >> processor architecture and not the memory model. >>>> >>>> > >>>> >>>> > Is there some case where _LP64 would be true but PPC64 would not >>>> be ??? >>>> >>>> > They seem effectively interchangeable but I don't know why you >>>> would use >>>> >>>> > one in one file and the other in another file ?? >>>> >>>> > >>>> >>>> > Thanks, >>>> >>>> > David >>>> >>>> > >>>> >>>> >> If I will change the ppc_ prefixes that'll take a bit, especially >>>> >>>> >> as I will have to adapt all the alignments :(. >>>> >>>> >> But that does not matter, as we need to wait for your build >>>> >>>> >> change anyways. >>>> >>>> >> >>>> >>>> >> Best regards, >>>> >>>> >> Goetz. >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> -----Original Message----- >>>> >>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>> >>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>> >>>> >> To: Lindenmaier, Goetz >>>> >>>> >> Cc: hotspot-dev at openjdk.java.net >>>> ; >>>> ppc-aix-port-dev at openjdk.java.net >>>> ; Vladimir Kozlov >>>> >>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>> for interpreter only VM. >>>> >>>> >> >>>> >>>> >> Hi Goetz, >>>> >>>> >> >>>> >>>> >> Only a brief glance through ... >>>> >>>> >> >>>> >>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>> >>>> >> >>>> >>>> >> 34 #ifndef _LP64 >>>> >>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>> >>>> >> 36 #endif >>>> >>>> >> >>>> >>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>> will only >>>> >>>> >> be atomic on ppc64). >>>> >>>> >> >>>> >>>> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >>>> >>>> >> >>>> >>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>> redundant. >>>> >>>> >> >>>> >>>> >> David >>>> >>>> >> ----- >>>> >>>> >> >>>> >>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>> >>>> >>> Hi, >>>> >>>> >>> >>>> >>>> >>> This time with webrev. Sorry for the double mails. >>>> >>>> >>> >>>> >>>> >>> This change contains all the files in cpu/ppc and >>>> os_cpu/linux_ppc needed for >>>> >>>> >>> the PPC64 interpreter port on linux. >>>> >>>> >>> >>>> >>>> >>> With this change you can do a core build on ppc64 and run the >>>> VM interpreter only. >>>> >>>> >>> It executes simple programs as jvm98. >>>> >>>> >>> The change requires >>>> >>>> >>> >>>> >>>> >>> * 8016697: Use stubs to implement safefetch >>>> >>>> >>> >>>> >>>> >>> * 8020059: The flag introduced by 8014972 is not >>>> defined ... >>>> >>>> >>> which will arrive soon in the staging repository. >>>> >>>> >>> >>>> >>>> >>> I marked the change as XL as it contains a lot of code. >>>> Nevertheless the >>>> >>>> >>> code has no impact on the existing Oracle platforms. >>>> >>>> >>> >>>> >>>> >>> The change touches a single shared file, globals.hpp, removing a >>>> >>>> >>> special case introduced for the port. This is because we >>>> >>>> >>> integrated some changes earlier than originally intended. >>>> >>>> >>> >>>> >>>> >>> Please review the change. Does it need testing on Oracle side? >>>> >>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>> >>>> >>> >>>> >>>> >>> Best regards, >>>> >>>> >>> Goetz. >>>> >>>> >>> >>>> From volker.simonis at gmail.com Wed Jul 24 10:39:28 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 24 Jul 2013 19:39:28 +0200 Subject: RFR(S): 8019926 : PPC64 (part 106): Make hsdis build and work on Linux/PPC64 Message-ID: Hi, could you please review the following small patch which enables building the hsdis library on Linux/PPC64 and AIX/PPC64: http://cr.openjdk.java.net/~simonis/webrevs/8019926/ I've tested that this change will not break the Linux/x86/x86_64 and Solaris/sparc/sparcv9 platforms. Notice that building the hs-dis library against a recent source version of binutils may stop because of a dependency bug in the binutils configure/make system with an error like: WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[4]: *** [bfd.info] Error 1 The easiest way to work around this problem is by doing a "touch $BINUTILS/bfd/doc/bfd.info". I've documented this in the HotSpot Wiki at: https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly Thank you and best regards, Volker From vladimir.kozlov at oracle.com Wed Jul 24 11:47:44 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 24 Jul 2013 11:47:44 -0700 Subject: RFR(S): 8019926 : PPC64 (part 106): Make hsdis build and work on Linux/PPC64 In-Reply-To: References: Message-ID: <51F02150.3030205@oracle.com> Looks good. Please, fix indention in hsdis.c. Could you add workaround info to the src/share/tools/hsdis/README? thanks, Vladimir On 7/24/13 10:39 AM, Volker Simonis wrote: > Hi, > > could you please review the following small patch which enables > building the hsdis library on Linux/PPC64 and AIX/PPC64: > > http://cr.openjdk.java.net/~simonis/webrevs/8019926/ > > I've tested that this change will not break the Linux/x86/x86_64 and > Solaris/sparc/sparcv9 platforms. > > Notice that building the hs-dis library against a recent source > version of binutils may stop because of a dependency bug in the > binutils configure/make system with an error like: > > WARNING: `makeinfo' is missing on your system. You should only need it if > you modified a `.texi' or `.texinfo' file, or any other file > indirectly affecting the aspect of the manual. The spurious > call might also be the consequence of using a buggy `make' (AIX, > DU, IRIX). You might want to install the `Texinfo' package or > the `GNU make' package. Grab either from any GNU archive site. > make[4]: *** [bfd.info] Error 1 > > The easiest way to work around this problem is by doing a "touch > $BINUTILS/bfd/doc/bfd.info". I've documented this in the HotSpot Wiki > at: > > https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly > > Thank you and best regards, > Volker > From frederic.parain at oracle.com Wed Jul 24 12:14:17 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 24 Jul 2013 19:14:17 +0000 Subject: hg: hsx/hotspot-main/hotspot: 27 new changesets Message-ID: <20130724191527.BEFDE4831B@hg.openjdk.java.net> Changeset: dbc0b5dc08f5 Author: fparain Date: 2013-07-10 15:49 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dbc0b5dc08f5 7143807: ResourceMark nesting problem in stringStream Reviewed-by: kvn, dcubed ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: c9a5fab39234 Author: zgu Date: 2013-07-11 13:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c9a5fab39234 8012241: NMT huge memory footprint, it usually leads to OOME Summary: Enforce memory limitation on NMT to prevent JVM OOM Reviewed-by: acorn, dcubed, minqi ! src/share/vm/services/memTracker.cpp Changeset: 5f056abe17c6 Author: zgu Date: 2013-07-12 04:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5f056abe17c6 Merge Changeset: 2e8f19c2feef Author: allwin Date: 2013-07-12 18:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2e8f19c2feef 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Summary: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Reviewed-by: dcubed, dholmes, sspitsyn, mgerdin, ctornqvi, dsamersoff ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/windows/vm/attachListener_windows.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.hpp + test/serviceability/attach/AttachWithStalePidFile.java + test/serviceability/attach/AttachWithStalePidFileTarget.java Changeset: c0cb474be37e Author: ctornqvi Date: 2013-07-12 20:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c0cb474be37e Merge Changeset: 862625d214fa Author: fparain Date: 2013-07-15 00:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/862625d214fa Merge Changeset: 23123fc6968a Author: rbackman Date: 2013-07-15 11:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/23123fc6968a 8019324: assert(_f2 == 0 || _f2 == f2) failed: illegal field change Reviewed-by: dholmes, rbackman Contributed-by: David Simms ! src/share/vm/oops/cpCache.hpp Changeset: ee9e76adced3 Author: rbackman Date: 2013-07-15 12:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ee9e76adced3 Merge Changeset: 33c52908bcdb Author: dholmes Date: 2013-07-15 23:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/33c52908bcdb 8015759: hotspot changes needed to compile with Visual Studio 2012 Reviewed-by: anthony, dholmes, dcubed Contributed-by: Tim Bell ! make/windows/makefiles/compile.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/vm.make ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp Changeset: 39deebbc90b3 Author: mgerdin Date: 2013-07-16 07:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/39deebbc90b3 6671508: JNI GetPrimitiveArrayCritical should not be callable on object arrays Summary: Checked JNI now reports error for Get/ReleasePrimitiveArrayCritical on object arrays Reviewed-by: dholmes, acorn Contributed-by: david.simms at oracle.com ! src/share/vm/prims/jniCheck.cpp Changeset: e619a2766bcc Author: rbackman Date: 2013-06-12 11:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e619a2766bcc 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Reviewed-by: jrose, kvn, mgronlun ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 732af649bc3a Author: ccheung Date: 2013-07-17 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/732af649bc3a 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 Summary: Added (sig < MAXSIGNUM) check in jsig.c Reviewed-by: dholmes, acorn ! src/os/linux/vm/jsig.c + test/runtime/jsig/Test8017498.sh + test/runtime/jsig/TestJNI.c + test/runtime/jsig/TestJNI.java Changeset: 825e6cb66923 Author: jiangli Date: 2013-07-17 18:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/825e6cb66923 8020309: Eliminate InstanceKlass::_cached_class_file_len. Summary: Use JvmtiCachedClassFileData. Reviewed-by: iklam, sspitsyn, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6388dbc4b7ca Author: jiangli Date: 2013-07-17 17:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6388dbc4b7ca Merge Changeset: c29568b733d2 Author: dholmes Date: 2013-07-18 06:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c29568b733d2 8020697: jniCheck.cpp:check_is_obj_array asserts on TypeArrayKlass::cast(aOop->klass()) Reviewed-by: dcubed, fparain, dholmes Contributed-by: David Simms ! src/share/vm/prims/jniCheck.cpp Changeset: 5e3b6f79d280 Author: rbackman Date: 2013-07-17 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5e3b6f79d280 8020701: Avoid crashes in WatcherThread Reviewed-by: acorn, dcubed, dsimms ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 248c459b2b75 Author: dcubed Date: 2013-07-18 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/248c459b2b75 Merge ! src/share/vm/services/memTracker.cpp Changeset: af21010d1062 Author: dcubed Date: 2013-07-18 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/af21010d1062 Merge ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/os.hpp Changeset: 02d7aa1456c9 Author: ccheung Date: 2013-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/02d7aa1456c9 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed Summary: this fix also removes the -XX:+UseStringCache option Reviewed-by: dholmes, acorn, iklam ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: 383a5e21cc2d Author: minqi Date: 2013-07-18 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/383a5e21cc2d Merge Changeset: 060ae9b7ffea Author: mgronlun Date: 2013-07-19 17:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/060ae9b7ffea 8020547: Event based tracing needs a UNICODE string type Reviewed-by: egahlin, rbackman, dcubed, brutisso, acorn ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/xinclude.mod Changeset: 4614a598dae1 Author: minqi Date: 2013-07-19 08:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4614a598dae1 8016538: volatile double access via Unsafe.cpp is not atomic Summary: volatile jdouble load/store is not atomic, fix by using of existing volatile jlong operations which are atomic for jdouble. Reviewed-by: kvn, vladidan, jrose Contributed-by: david.holmes at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp Changeset: 55a61ceb2fe7 Author: minqi Date: 2013-07-19 11:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/55a61ceb2fe7 Merge Changeset: 16511b7e3d35 Author: emc Date: 2013-07-22 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/16511b7e3d35 8019632: Method parameters are not copied in clone_with_new_data Summary: Add code to copy method parameters data in clone_with_new_data Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.cpp Changeset: 72727c4b6dec Author: ccheung Date: 2013-07-19 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/72727c4b6dec 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code Summary: Added -DLINUX to the gcc command and improved the .sh script Reviewed-by: dcubed, dholmes, minqi ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 5165d659cebd Author: minqi Date: 2013-07-22 22:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5165d659cebd Merge Changeset: c0f353803b47 Author: minqi Date: 2013-07-23 12:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c0f353803b47 Merge From karen.kinnear at oracle.com Wed Jul 24 14:33:49 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 24 Jul 2013 17:33:49 -0400 Subject: RFR: 8009130 JCK lambda test fails with IllegalAccessException Message-ID: <2C527CC3-375B-4C10-AB04-5CDA1BF687B0@oracle.com> Please review fix for access checking and loader constraint checking for default methods: http://cr.openjdk.java.net/~acorn/8009130/webrev/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009130 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013085 Summary: Now that javac is generating bridges for generic signatures in interfaces, and the JVM does not need to handle generic signatures and covariant returns in handling default methods, it is possible to simplify the handling of default methods. Default methods are concrete methods in interfaces. Their inheritance rules simplified are: 1. class method or superclass method wins 2. if there is a unique nonshadowed default method in superinterfaces it is chosen (this logic was not changed, and many thanks to Keith McGuigan for writing that code so well) 3. otherwise we get an AbstractMethodError on invocation Before this change, we created overpass (VM created bridge methods) added them to the methods array and updated the constant pool. This allowed us to add checkcasts for input and return arguments. We don't need those anymore so we don't need overpass methods for default handling. The overpass methods added invokespecial invocation instructions which ran into issues with access checking, i.e. not being able to access the constantpool of the invokespecial linktime resolved method, since they did not always have permission to access the interface class. With this change default methods are added as an array to instanceKlass and to the instanceKlass vtable. Invocation method search order: 1. local methods 2. superclass methods 3. default methods 4. abstract interface methods The default methods retain their superinterface method_holder, i.e. owning klass, so the access checking and loader constraint checking all works as expected with no special logic needed. We continue to use overpasses for default exception handling, e.g. to create a custom AbstractMethodError for the conflict case above. Tests run - all on linux64: jck vm expect a new failure mode for resolveMethod00602m1 and resolveMethod00602m2 in fastdebug - they will get an assertion. They will be in the jck exclude list next week due to an existing bug: 8011311, support for private instance methods in interfaces not working. jck lang jtreg jdk (concurrency=1) : java.util, java.lang, jdk.lambda nsk vm.quick.testlist, vm.mlvm, vm.quick-jvmti.testlist 8009130 package private example specifically fixes: lang/CLSS/clss475/clss47501m21 and clss47501m211 lang/INTF/intf024/intf02402m01 and intf02402m11 8013085 loader constraint example nsk defmeth tests - with and without redefineclasses - passes all tests that passed before this change, other existing bugs prevent complete passing Reflect2 - reflection modeling reflect.invoke - DefaultStaticTest.java intfbug test jcmd GC:class_stats thanks, Karen From morris.meyer at oracle.com Wed Jul 24 16:43:06 2013 From: morris.meyer at oracle.com (morris.meyer at oracle.com) Date: Wed, 24 Jul 2013 23:43:06 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20130724234321.45A3748334@hg.openjdk.java.net> Changeset: c90c698831d7 Author: kvn Date: 2013-07-12 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c90c698831d7 8020215: Different execution plan when using JIT vs interpreter Summary: fix bytecode analyzer Reviewed-by: twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp + test/compiler/EscapeAnalysis/Test8020215.java Changeset: fcf521c3fbc6 Author: kvn Date: 2013-07-12 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fcf521c3fbc6 8007898: Incorrect optimization of Memory Barriers in Matcher::post_store_load_barrier() Summary: generate one "fat" membar instead of set of barriers for volitile store Reviewed-by: roland ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/membars/DekkerTest.java Changeset: 34ce0b5acb81 Author: morris Date: 2013-07-15 06:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/34ce0b5acb81 Merge Changeset: 0f57ccdb9084 Author: kvn Date: 2013-07-15 10:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0f57ccdb9084 8020433: Crash when using -XX:+RestoreMXCSROnJNICalls Summary: remove StubRoutines::x86::_mxcsr_std and use StubRoutines::_mxcsr_std Reviewed-by: jrose ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp + test/compiler/cpuflags/RestoreMXCSR.java Changeset: 46a90f83df31 Author: morris Date: 2013-07-19 13:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/46a90f83df31 Merge ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 6efedc114807 Author: morris Date: 2013-07-24 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6efedc114807 Merge From david.holmes at oracle.com Wed Jul 24 22:22:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jul 2013 15:22:46 +1000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> Message-ID: <51F0B626.9060200@oracle.com> On 25/07/2013 12:46 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated the webrev once more. > http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ > > - I fixed encode_klass_not_null() > - I cleaned up jni_ppc.h > - added the guard in copy_ppc.hpp. > > Further there were problems on aix. > I had to rename the condition code registers from CR0-7 to CCR0-7, > as CR0-3 is defined in an AIX system header. > > David, can I mark the change as reviewed by you? I only looked at handful of files. David > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 23. Juli 2013 09:59 > To: Lindenmaier, Goetz > Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic > copies for jlong are only correct on 64-bit. > > Is there other code in "bit-neutral" ppc files that is really only > correct on 64-bit? > > David > ----- > > On 23/07/2013 5:54 PM, David Holmes wrote: >> On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >>> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>>> >>>> I don't really care about the guard. Just tell me what to do... >>> >>> To be safe leave guards with PPC64 check instead of _lp64 as you >>> suggested. >> >> Yes please do that. I think the guard is important as this is a >> bit-neutral file. If/when someone creates a 32-bit PPC port we don't >> want them to have to re-discover the atomicity bugs with jlong/jdouble >> that were found on the existing platforms. >> >> Thanks, >> David >> >>> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? : >>> >>> jniTypes_ppc.hpp: >>> >>> 48 #ifndef PPC64 >>> 49 #error "ppc32 support currently not implemented!!!" >>> 50 #endif // PPC64 >>> >>> Our reviews are based on assumption that this port only supports >>> PPC64+LP64 combination. Is this correct assumption? >>> >>> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >>> based macbook pro. But do we need it in this port? >>> >>> Regards, >>> Vladimir >>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Monday, July 22, 2013 6:48 PM >>>> To: Lindenmaier, Goetz >>>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>> interpreter only VM. >>>> >>>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>>> ??? Or do you propose to change both of them to PPC64? >>>>> Yes, sure, I want to change both. >>>> >>>> Why do we need this error if this code is only for PPC64 port? We will >>>> have other compilation errors if we try to use >>>> these sources for something else as we found already. Do you have an >>>> other usage so you need this guard? >>>> >>>>>> All of the existing 64-bit ports have a direct correspondence between >>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>> >>>>> I know. And obviously there is a correspondence, as no one will >>>>> Implement an LG64 memory model on a 32 bit machine. >>>>> But the usage intermingles different memory model and architecture: >>>>> >>>>> E.g., the register declaration in register_x86_hpp is fine: >>>>> >>>>> #ifdef AMD64 >>>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>>> >>>>> But I think this makes no sense (assembler_x86.hpp): >>>>> >>>>> #ifdef _LP64 >>>>> void movsbq(Register dst, Address src); >>>>> void movsbq(Register dst, Register src); >>>>> // Move signed 32bit immediate to 64bit extending sign >>>>> void movslq(Address dst, int32_t imm64); >>>>> void movslq(Register dst, int32_t imm64); >>>>> >>>>> and should be guarded by AMD64. >>>> >>>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>>> so using _LP64 works for us. Also using AMD64 >>>> sometimes rise questions about Intel x64. So using _LP64 is more >>>> neutral. >>>> >>>>> And I want to get the PPC port right in such matters. >>>> >>>> I agree with this since ppc is more flexible than x86, it seems. >>>> >>>>> I'm currently removing the ppc_ prefixes ... big fun:) >>>> >>>> Sorry about that. >>>> >>>> Regards, >>>> Vladimir >>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Montag, 22. Juli 2013 13:38 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>> hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>> interpreter only VM. >>>>> >>>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>>> >>>>> > Hi David, >>>>> >>>>> > >>>>> >>>>> > PPC64: describes an instruction set / machine with all it's >>>>> specialities. And the instruction set >>>>> >>>>> > we implemented the port for has an atomic 64-bit >>>>> instruction. >>>>> >>>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>>> , pointer == 64 bit. >>>>> >>>>> > In contraditction to ILP64 (int == 64bit) etc, which you could as >>>>> well implement with the >>>>> >>>>> > PPC64 instruction set. You could also implement a system with >>>>> ILP32 on PPC64, and then >>>>> >>>>> > you would have an atomic 64-bit instruction. >>>>> >>>>> That still doesn't explain why you think LP64 is okay for the atomic >>>>> >>>>> file but you want PPC64 for the orderAccess file. ??? Or do you propose >>>>> >>>>> to change both of them to PPC64? >>>>> >>>>> All of the existing 64-bit ports have a direct correspondence between >>>>> >>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 >>>>> >>>>> is the only 64-bit data model that the OpenJDK sources support. >>>>> >>>>> > Compressed oops make sense to protect with LP64, because they are >>>>> only helpful >>>>> >>>>> > with 64 bit pointers. While usage of LP64 is not exactly correct >>>>> here, ILP64, SLP64 >>>>> >>>>> > etc would also use compressed oops. But it's close enough I guess. >>>>> >>>>> I'm not concerned about compressed oops. No idea where that came from >>>>> ;-) >>>>> >>>>> David >>>>> >>>>> ------ >>>>> >>>>> > Best regards, >>>>> >>>>> > Goetz. >>>>> >>>>> > >>>>> >>>>> > -----Original Message----- >>>>> >>>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>>> >>>>> > Sent: Montag, 22. Juli 2013 05:27 >>>>> >>>>> > To: Lindenmaier, Goetz >>>>> >>>>> > Cc: hotspot-dev at openjdk.java.net >>>>> ; >>>>> ppc-aix-port-dev at openjdk.java.net >>>>> ; Vladimir Kozlov >>>>> >>>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>> for interpreter only VM. >>>>> >>>>> > >>>>> >>>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>>> >>>>> >> Hi David, >>>>> >>>>> >> >>>>> >>>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>>> >>>>> >>> 34 #ifndef _LP64 >>>>> >>>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>>> >>>>> >>> 36 #endif >>>>> >>>>> >> You're right, I'll fix this. >>>>> >>>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>>> >>>>> >> processor architecture and not the memory model. >>>>> >>>>> > >>>>> >>>>> > Is there some case where _LP64 would be true but PPC64 would not >>>>> be ??? >>>>> >>>>> > They seem effectively interchangeable but I don't know why you >>>>> would use >>>>> >>>>> > one in one file and the other in another file ?? >>>>> >>>>> > >>>>> >>>>> > Thanks, >>>>> >>>>> > David >>>>> >>>>> > >>>>> >>>>> >> If I will change the ppc_ prefixes that'll take a bit, especially >>>>> >>>>> >> as I will have to adapt all the alignments :(. >>>>> >>>>> >> But that does not matter, as we need to wait for your build >>>>> >>>>> >> change anyways. >>>>> >>>>> >> >>>>> >>>>> >> Best regards, >>>>> >>>>> >> Goetz. >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> -----Original Message----- >>>>> >>>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> >>>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>>> >>>>> >> To: Lindenmaier, Goetz >>>>> >>>>> >> Cc: hotspot-dev at openjdk.java.net >>>>> ; >>>>> ppc-aix-port-dev at openjdk.java.net >>>>> ; Vladimir Kozlov >>>>> >>>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>> for interpreter only VM. >>>>> >>>>> >> >>>>> >>>>> >> Hi Goetz, >>>>> >>>>> >> >>>>> >>>>> >> Only a brief glance through ... >>>>> >>>>> >> >>>>> >>>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>>> >>>>> >> >>>>> >>>>> >> 34 #ifndef _LP64 >>>>> >>>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>>> >>>>> >> 36 #endif >>>>> >>>>> >> >>>>> >>>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>>> will only >>>>> >>>>> >> be atomic on ppc64). >>>>> >>>>> >> >>>>> >>>>> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >>>>> >>>>> >> >>>>> >>>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>>> redundant. >>>>> >>>>> >> >>>>> >>>>> >> David >>>>> >>>>> >> ----- >>>>> >>>>> >> >>>>> >>>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>>> >>>>> >>> Hi, >>>>> >>>>> >>> >>>>> >>>>> >>> This time with webrev. Sorry for the double mails. >>>>> >>>>> >>> >>>>> >>>>> >>> This change contains all the files in cpu/ppc and >>>>> os_cpu/linux_ppc needed for >>>>> >>>>> >>> the PPC64 interpreter port on linux. >>>>> >>>>> >>> >>>>> >>>>> >>> With this change you can do a core build on ppc64 and run the >>>>> VM interpreter only. >>>>> >>>>> >>> It executes simple programs as jvm98. >>>>> >>>>> >>> The change requires >>>>> >>>>> >>> >>>>> >>>>> >>> * 8016697: Use stubs to implement safefetch >>>>> >>>>> >>> >>>>> >>>>> >>> * 8020059: The flag introduced by 8014972 is not >>>>> defined ... >>>>> >>>>> >>> which will arrive soon in the staging repository. >>>>> >>>>> >>> >>>>> >>>>> >>> I marked the change as XL as it contains a lot of code. >>>>> Nevertheless the >>>>> >>>>> >>> code has no impact on the existing Oracle platforms. >>>>> >>>>> >>> >>>>> >>>>> >>> The change touches a single shared file, globals.hpp, removing a >>>>> >>>>> >>> special case introduced for the port. This is because we >>>>> >>>>> >>> integrated some changes earlier than originally intended. >>>>> >>>>> >>> >>>>> >>>>> >>> Please review the change. Does it need testing on Oracle side? >>>>> >>>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>>> >>>>> >>> >>>>> >>>>> >>> Best regards, >>>>> >>>>> >>> Goetz. >>>>> >>>>> >>> >>>>> From vladimir.kozlov at oracle.com Wed Jul 24 22:43:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 24 Jul 2013 22:43:13 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> Message-ID: <51F0BAF1.1090000@oracle.com> Thank you, Goetz, This looks good. David pushed makefile changes (8020799) in group's repo. I will try to combine all these changes with staged sources and run JPRT test builds tomorrow. Thanks, Vladimir On 7/24/13 7:46 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated the webrev once more. > http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ > > - I fixed encode_klass_not_null() > - I cleaned up jni_ppc.h > - added the guard in copy_ppc.hpp. > > Further there were problems on aix. > I had to rename the condition code registers from CR0-7 to CCR0-7, > as CR0-3 is defined in an AIX system header. > > David, can I mark the change as reviewed by you? > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 23. Juli 2013 09:59 > To: Lindenmaier, Goetz > Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic > copies for jlong are only correct on 64-bit. > > Is there other code in "bit-neutral" ppc files that is really only > correct on 64-bit? > > David > ----- > > On 23/07/2013 5:54 PM, David Holmes wrote: >> On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >>> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>>> >>>> I don't really care about the guard. Just tell me what to do... >>> >>> To be safe leave guards with PPC64 check instead of _lp64 as you >>> suggested. >> >> Yes please do that. I think the guard is important as this is a >> bit-neutral file. If/when someone creates a 32-bit PPC port we don't >> want them to have to re-discover the atomicity bugs with jlong/jdouble >> that were found on the existing platforms. >> >> Thanks, >> David >> >>> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? : >>> >>> jniTypes_ppc.hpp: >>> >>> 48 #ifndef PPC64 >>> 49 #error "ppc32 support currently not implemented!!!" >>> 50 #endif // PPC64 >>> >>> Our reviews are based on assumption that this port only supports >>> PPC64+LP64 combination. Is this correct assumption? >>> >>> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >>> based macbook pro. But do we need it in this port? >>> >>> Regards, >>> Vladimir >>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Monday, July 22, 2013 6:48 PM >>>> To: Lindenmaier, Goetz >>>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>> interpreter only VM. >>>> >>>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>>> ??? Or do you propose to change both of them to PPC64? >>>>> Yes, sure, I want to change both. >>>> >>>> Why do we need this error if this code is only for PPC64 port? We will >>>> have other compilation errors if we try to use >>>> these sources for something else as we found already. Do you have an >>>> other usage so you need this guard? >>>> >>>>>> All of the existing 64-bit ports have a direct correspondence between >>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>> >>>>> I know. And obviously there is a correspondence, as no one will >>>>> Implement an LG64 memory model on a 32 bit machine. >>>>> But the usage intermingles different memory model and architecture: >>>>> >>>>> E.g., the register declaration in register_x86_hpp is fine: >>>>> >>>>> #ifdef AMD64 >>>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>>> >>>>> But I think this makes no sense (assembler_x86.hpp): >>>>> >>>>> #ifdef _LP64 >>>>> void movsbq(Register dst, Address src); >>>>> void movsbq(Register dst, Register src); >>>>> // Move signed 32bit immediate to 64bit extending sign >>>>> void movslq(Address dst, int32_t imm64); >>>>> void movslq(Register dst, int32_t imm64); >>>>> >>>>> and should be guarded by AMD64. >>>> >>>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>>> so using _LP64 works for us. Also using AMD64 >>>> sometimes rise questions about Intel x64. So using _LP64 is more >>>> neutral. >>>> >>>>> And I want to get the PPC port right in such matters. >>>> >>>> I agree with this since ppc is more flexible than x86, it seems. >>>> >>>>> I'm currently removing the ppc_ prefixes ... big fun:) >>>> >>>> Sorry about that. >>>> >>>> Regards, >>>> Vladimir >>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Montag, 22. Juli 2013 13:38 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>> hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>> interpreter only VM. >>>>> >>>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>>> >>>>> > Hi David, >>>>> >>>>> > >>>>> >>>>> > PPC64: describes an instruction set / machine with all it's >>>>> specialities. And the instruction set >>>>> >>>>> > we implemented the port for has an atomic 64-bit >>>>> instruction. >>>>> >>>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>>> , pointer == 64 bit. >>>>> >>>>> > In contraditction to ILP64 (int == 64bit) etc, which you could as >>>>> well implement with the >>>>> >>>>> > PPC64 instruction set. You could also implement a system with >>>>> ILP32 on PPC64, and then >>>>> >>>>> > you would have an atomic 64-bit instruction. >>>>> >>>>> That still doesn't explain why you think LP64 is okay for the atomic >>>>> >>>>> file but you want PPC64 for the orderAccess file. ??? Or do you propose >>>>> >>>>> to change both of them to PPC64? >>>>> >>>>> All of the existing 64-bit ports have a direct correspondence between >>>>> >>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 >>>>> >>>>> is the only 64-bit data model that the OpenJDK sources support. >>>>> >>>>> > Compressed oops make sense to protect with LP64, because they are >>>>> only helpful >>>>> >>>>> > with 64 bit pointers. While usage of LP64 is not exactly correct >>>>> here, ILP64, SLP64 >>>>> >>>>> > etc would also use compressed oops. But it's close enough I guess. >>>>> >>>>> I'm not concerned about compressed oops. No idea where that came from >>>>> ;-) >>>>> >>>>> David >>>>> >>>>> ------ >>>>> >>>>> > Best regards, >>>>> >>>>> > Goetz. >>>>> >>>>> > >>>>> >>>>> > -----Original Message----- >>>>> >>>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>>> >>>>> > Sent: Montag, 22. Juli 2013 05:27 >>>>> >>>>> > To: Lindenmaier, Goetz >>>>> >>>>> > Cc: hotspot-dev at openjdk.java.net >>>>> ; >>>>> ppc-aix-port-dev at openjdk.java.net >>>>> ; Vladimir Kozlov >>>>> >>>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>> for interpreter only VM. >>>>> >>>>> > >>>>> >>>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>>> >>>>> >> Hi David, >>>>> >>>>> >> >>>>> >>>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>>> >>>>> >>> 34 #ifndef _LP64 >>>>> >>>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>>> >>>>> >>> 36 #endif >>>>> >>>>> >> You're right, I'll fix this. >>>>> >>>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>>> >>>>> >> processor architecture and not the memory model. >>>>> >>>>> > >>>>> >>>>> > Is there some case where _LP64 would be true but PPC64 would not >>>>> be ??? >>>>> >>>>> > They seem effectively interchangeable but I don't know why you >>>>> would use >>>>> >>>>> > one in one file and the other in another file ?? >>>>> >>>>> > >>>>> >>>>> > Thanks, >>>>> >>>>> > David >>>>> >>>>> > >>>>> >>>>> >> If I will change the ppc_ prefixes that'll take a bit, especially >>>>> >>>>> >> as I will have to adapt all the alignments :(. >>>>> >>>>> >> But that does not matter, as we need to wait for your build >>>>> >>>>> >> change anyways. >>>>> >>>>> >> >>>>> >>>>> >> Best regards, >>>>> >>>>> >> Goetz. >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> -----Original Message----- >>>>> >>>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> >>>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>>> >>>>> >> To: Lindenmaier, Goetz >>>>> >>>>> >> Cc: hotspot-dev at openjdk.java.net >>>>> ; >>>>> ppc-aix-port-dev at openjdk.java.net >>>>> ; Vladimir Kozlov >>>>> >>>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>> for interpreter only VM. >>>>> >>>>> >> >>>>> >>>>> >> Hi Goetz, >>>>> >>>>> >> >>>>> >>>>> >> Only a brief glance through ... >>>>> >>>>> >> >>>>> >>>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>>> >>>>> >> >>>>> >>>>> >> 34 #ifndef _LP64 >>>>> >>>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>>> >>>>> >> 36 #endif >>>>> >>>>> >> >>>>> >>>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>>> will only >>>>> >>>>> >> be atomic on ppc64). >>>>> >>>>> >> >>>>> >>>>> >> BTW typo: 35 #error "Atomic currently only impleneted for PPC64" >>>>> >>>>> >> >>>>> >>>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>>> redundant. >>>>> >>>>> >> >>>>> >>>>> >> David >>>>> >>>>> >> ----- >>>>> >>>>> >> >>>>> >>>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>>> >>>>> >>> Hi, >>>>> >>>>> >>> >>>>> >>>>> >>> This time with webrev. Sorry for the double mails. >>>>> >>>>> >>> >>>>> >>>>> >>> This change contains all the files in cpu/ppc and >>>>> os_cpu/linux_ppc needed for >>>>> >>>>> >>> the PPC64 interpreter port on linux. >>>>> >>>>> >>> >>>>> >>>>> >>> With this change you can do a core build on ppc64 and run the >>>>> VM interpreter only. >>>>> >>>>> >>> It executes simple programs as jvm98. >>>>> >>>>> >>> The change requires >>>>> >>>>> >>> >>>>> >>>>> >>> * 8016697: Use stubs to implement safefetch >>>>> >>>>> >>> >>>>> >>>>> >>> * 8020059: The flag introduced by 8014972 is not >>>>> defined ... >>>>> >>>>> >>> which will arrive soon in the staging repository. >>>>> >>>>> >>> >>>>> >>>>> >>> I marked the change as XL as it contains a lot of code. >>>>> Nevertheless the >>>>> >>>>> >>> code has no impact on the existing Oracle platforms. >>>>> >>>>> >>> >>>>> >>>>> >>> The change touches a single shared file, globals.hpp, removing a >>>>> >>>>> >>> special case introduced for the port. This is because we >>>>> >>>>> >>> integrated some changes earlier than originally intended. >>>>> >>>>> >>> >>>>> >>>>> >>> Please review the change. Does it need testing on Oracle side? >>>>> >>>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>>> >>>>> >>> >>>>> >>>>> >>> Best regards, >>>>> >>>>> >>> Goetz. >>>>> >>>>> >>> >>>>> From david.holmes at oracle.com Thu Jul 25 00:02:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jul 2013 17:02:19 +1000 Subject: RFR: 8021314 minimal1.make needs to force off components not supported by the minimal VM Message-ID: <51F0CD7B.1020405@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8021314/webrev/ A simple fix. Where we used ?= to only set an INCLUDE_* variable to false if not already set, we really want to set it to false regardless. You can still pass the variable as make arg to bypass this logic if you know what you are doing, but we don't want to other parts of the build to enable variables that the minimal VM doesn't support. Thanks, David From bill.pittore at oracle.com Thu Jul 25 07:33:05 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 25 Jul 2013 10:33:05 -0400 Subject: RFR: 8021314 minimal1.make needs to force off components not supported by the minimal VM In-Reply-To: <51F0CD7B.1020405@oracle.com> References: <51F0CD7B.1020405@oracle.com> Message-ID: <51F13721.60306@oracle.com> Not an official reviewer but I like it. bill On 7/25/2013 3:02 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8021314/webrev/ > > A simple fix. Where we used ?= to only set an INCLUDE_* variable to > false if not already set, we really want to set it to false > regardless. You can still pass the variable as make arg to bypass this > logic if you know what you are doing, but we don't want to other parts > of the build to enable variables that the minimal VM doesn't support. > > Thanks, > David > From volker.simonis at gmail.com Thu Jul 25 09:32:47 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 25 Jul 2013 18:32:47 +0200 Subject: RFR(S): 8019926 : PPC64 (part 106): Make hsdis build and work on Linux/PPC64 In-Reply-To: <51F02150.3030205@oracle.com> References: <51F02150.3030205@oracle.com> Message-ID: On Wed, Jul 24, 2013 at 8:47 PM, Vladimir Kozlov wrote: > Looks good. > Thanks. > Please, fix indention in hsdis.c. > Done. > Could you add workaround info to the src/share/tools/hsdis/README? > See: http://cr.openjdk.java.net/~simonis/webrevs/8019926.v3/ I've also added a link to the Wiki page and updated the copyright years appropriately. Can I push this right into 'stage' (I don't think it will have any impact on JPRT:) Regards, Volker > thanks, > Vladimir > > > On 7/24/13 10:39 AM, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following small patch which enables >> building the hsdis library on Linux/PPC64 and AIX/PPC64: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8019926/ >> >> I've tested that this change will not break the Linux/x86/x86_64 and >> Solaris/sparc/sparcv9 platforms. >> >> Notice that building the hs-dis library against a recent source >> version of binutils may stop because of a dependency bug in the >> binutils configure/make system with an error like: >> >> WARNING: `makeinfo' is missing on your system. You should only need it if >> you modified a `.texi' or `.texinfo' file, or any other file >> indirectly affecting the aspect of the manual. The spurious >> call might also be the consequence of using a buggy `make' (AIX, >> DU, IRIX). You might want to install the `Texinfo' package or >> the `GNU make' package. Grab either from any GNU archive site. >> make[4]: *** [bfd.info] Error 1 >> >> The easiest way to work around this problem is by doing a "touch >> $BINUTILS/bfd/doc/bfd.info". I've documented this in the HotSpot Wiki >> at: >> >> https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly >> >> Thank you and best regards, >> Volker >> > From john.coomes at oracle.com Thu Jul 25 10:32:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 17:32:38 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b100 for changeset d2dcb110e9db Message-ID: <20130725173238.C225048376@hg.openjdk.java.net> Changeset: 9f74a220677d Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9f74a220677d Added tag jdk8-b100 for changeset d2dcb110e9db ! .hgtags From john.coomes at oracle.com Thu Jul 25 10:32:44 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 17:32:44 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b100 for changeset 8d492f1dfd1b Message-ID: <20130725173248.7F43B48377@hg.openjdk.java.net> Changeset: a013024b0747 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/a013024b0747 Added tag jdk8-b100 for changeset 8d492f1dfd1b ! .hgtags From john.coomes at oracle.com Thu Jul 25 10:33:01 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 17:33:01 +0000 Subject: hg: hsx/hotspot-main/jaxp: 5 new changesets Message-ID: <20130725173329.494FC48378@hg.openjdk.java.net> Changeset: 3b071f506ab9 Author: joehw Date: 2013-07-09 16:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/3b071f506ab9 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown Summary: jaxp 1.5 feature update Reviewed-by: alanb, dfuchs, lancea ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: aabe15fc346f Author: joehw Date: 2013-07-12 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/aabe15fc346f 8020430: NullPointerException in xml sqe nightly result on 2013-07-12 Reviewed-by: chegar, lancea ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java Changeset: 74ec7b48e3be Author: lana Date: 2013-07-17 00:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/74ec7b48e3be Merge Changeset: 5d1974c1d7b9 Author: lana Date: 2013-07-22 17:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/5d1974c1d7b9 Merge Changeset: 0a7432f898e5 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/0a7432f898e5 Added tag jdk8-b100 for changeset 5d1974c1d7b9 ! .hgtags From john.coomes at oracle.com Thu Jul 25 10:33:33 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 17:33:33 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b100 for changeset 4fd722afae5c Message-ID: <20130725173340.8202548379@hg.openjdk.java.net> Changeset: 60b623a36164 Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/60b623a36164 Added tag jdk8-b100 for changeset 4fd722afae5c ! .hgtags From bill.pittore at oracle.com Thu Jul 25 10:47:59 2013 From: bill.pittore at oracle.com (bill.pittore at oracle.com) Date: Thu, 25 Jul 2013 13:47:59 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D494E9.2020200@oracle.com> References: <51D494E9.2020200@oracle.com> Message-ID: <51F164CF.50307@oracle.com> Still need an official reviewer for the hotspot changes for statically linked agents. thanks, bill > These changes address bug 8014135 which adds support for statically > linked agents in the VM. This is a followup to the recent JNI spec > changes that addressed statically linked JNI libraries( 8005716). > The JEP for this change is the same JEP as the JNI changes: > http://openjdk.java.net/jeps/178 > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ > > The changes to jvmti.xml can also be seen in the output file that I > placed here: > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html > > Thanks, > bill > From vladimir.kozlov at oracle.com Thu Jul 25 11:04:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Jul 2013 11:04:47 -0700 Subject: RFR(S): 8019926 : PPC64 (part 106): Make hsdis build and work on Linux/PPC64 In-Reply-To: References: <51F02150.3030205@oracle.com> Message-ID: <51F168BF.4010708@oracle.com> Very good. Yes, you can push it into stage. Thanks, Vladimir On 7/25/13 9:32 AM, Volker Simonis wrote: > On Wed, Jul 24, 2013 at 8:47 PM, Vladimir Kozlov > wrote: >> Looks good. >> > > Thanks. > >> Please, fix indention in hsdis.c. >> > > Done. > >> Could you add workaround info to the src/share/tools/hsdis/README? >> > > See: http://cr.openjdk.java.net/~simonis/webrevs/8019926.v3/ > > I've also added a link to the Wiki page and updated the copyright > years appropriately. > > Can I push this right into 'stage' (I don't think it will have any > impact on JPRT:) > > Regards, > Volker > >> thanks, >> Vladimir >> >> >> On 7/24/13 10:39 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following small patch which enables >>> building the hsdis library on Linux/PPC64 and AIX/PPC64: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8019926/ >>> >>> I've tested that this change will not break the Linux/x86/x86_64 and >>> Solaris/sparc/sparcv9 platforms. >>> >>> Notice that building the hs-dis library against a recent source >>> version of binutils may stop because of a dependency bug in the >>> binutils configure/make system with an error like: >>> >>> WARNING: `makeinfo' is missing on your system. You should only need it if >>> you modified a `.texi' or `.texinfo' file, or any other file >>> indirectly affecting the aspect of the manual. The spurious >>> call might also be the consequence of using a buggy `make' (AIX, >>> DU, IRIX). You might want to install the `Texinfo' package or >>> the `GNU make' package. Grab either from any GNU archive site. >>> make[4]: *** [bfd.info] Error 1 >>> >>> The easiest way to work around this problem is by doing a "touch >>> $BINUTILS/bfd/doc/bfd.info". I've documented this in the HotSpot Wiki >>> at: >>> >>> https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly >>> >>> Thank you and best regards, >>> Volker >>> >> From john.coomes at oracle.com Thu Jul 25 10:38:19 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 17:38:19 +0000 Subject: hg: hsx/hotspot-main/jdk: 86 new changesets Message-ID: <20130725180904.6BEC54837B@hg.openjdk.java.net> Changeset: cacfc77655c8 Author: serb Date: 2013-07-03 19:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cacfc77655c8 8004859: Graphics.getClipBounds/getClip return difference nonequivalent bounds, depending from transform Reviewed-by: prr, flar ! src/share/classes/sun/java2d/SunGraphics2D.java + test/java/awt/Graphics2D/Test8004859/Test8004859.java Changeset: 75844b444879 Author: jchen Date: 2013-07-03 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/75844b444879 8014497: [parfait] Potential null pointer dereference in jdk/src/share/native/sun/java2d/cmm/lcms/cmsgamma.c Reviewed-by: bae, prr ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c Changeset: d32757b7060c Author: lana Date: 2013-07-05 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d32757b7060c Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: dead66347eca Author: jgodinez Date: 2013-07-10 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dead66347eca 8016737: After clicking on "Print UNCOLLATED" button, the print out come in order 'Page 1', 'Page 2', 'Page 1' Reviewed-by: jchen, prr ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: fabcccc003d2 Author: lana Date: 2013-07-17 12:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fabcccc003d2 Merge Changeset: f41758d12409 Author: alitvinov Date: 2013-07-04 16:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f41758d12409 8015730: PIT: On Linux, OGL=true and fbobject=false leads to deadlock or infinite loop Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java ! src/solaris/native/sun/awt/awt_util.h ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c Changeset: 523815540788 Author: lana Date: 2013-07-05 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/523815540788 Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: b7cbad879d63 Author: leonidr Date: 2013-07-08 19:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b7cbad879d63 8019265: [macosx] apple.laf.useScreenMenuBar regression comparing with jdk6 Reviewed-by: anthony ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 7e291fc61cad Author: malenkov Date: 2013-07-09 18:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7e291fc61cad 6707231: Wrong read Method returned for boolen properties Reviewed-by: alexsch ! src/share/classes/java/beans/Introspector.java + test/java/beans/Introspector/Test6707231.java Changeset: e7ca6e259dc2 Author: serb Date: 2013-07-09 21:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e7ca6e259dc2 8019587: [macosx] Possibility to set the same frame for the different screens Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/GraphicsDevice/IncorrectDisplayModeExitFullscreen.java Changeset: 46826d248616 Author: pchelko Date: 2013-07-11 16:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/46826d248616 8020210: [macosx] JVM crashes in CWrapper$NSWindow.screen(long) Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/Window/MaximizeOffscreen/MaximizeOffscreenTest.java Changeset: c566daef4877 Author: leonidr Date: 2013-07-11 18:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c566daef4877 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread Reviewed-by: art, anthony ! src/macosx/classes/com/apple/eawt/FullScreenHandler.java ! src/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/macosx/classes/com/apple/eawt/event/GestureHandler.java ! src/macosx/classes/com/apple/laf/ScreenMenu.java ! src/macosx/classes/sun/lwawt/macosx/CCheckboxMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java Changeset: c3268a602a50 Author: raginip Date: 2013-07-12 14:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c3268a602a50 8009168: accessibility.properties syntax issue Reviewed-by: ptbrunet, mfang, alexsch ! src/share/classes/com/sun/accessibility/internal/resources/accessibility.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_TW.properties ! src/share/classes/javax/accessibility/AccessibleAction.java Changeset: f7ea38893138 Author: serb Date: 2013-07-12 21:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f7ea38893138 8020298: [macosx] Incorrect merge in the lwawt code Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: d52fc9384765 Author: pchelko Date: 2013-07-15 12:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d52fc9384765 8020371: [macosx] applets with Drag and Drop fail with IllegalArgumentException Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 0967103c1b65 Author: malenkov Date: 2013-07-15 17:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0967103c1b65 8017492: Static field in HTML parser affects all applications Reviewed-by: art ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/Element.java + test/javax/swing/text/html/parser/Test8017492.java Changeset: 15ea601e707a Author: lana Date: 2013-07-17 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/15ea601e707a Merge Changeset: cf7202b32a34 Author: mchung Date: 2013-07-02 15:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cf7202b32a34 8007035: deprecate public void SecurityManager.checkMemberAccess(Class clazz, int which) Reviewed-by: jrose, alanb, dfuchs ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Member.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java + test/java/lang/invoke/TestPrivateMember.java Changeset: dfd7fb0ce54b Author: psandoz Date: 2013-07-03 11:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dfd7fb0ce54b 8011427: java.util.concurrent collection Spliterator implementations Reviewed-by: martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/BlockingDeque.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/Delayed.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java Changeset: bb4ae17c98cf Author: psandoz Date: 2013-07-03 11:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb4ae17c98cf 8019481: Sync misc j.u.c classes from 166 to tl Reviewed-by: martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/BrokenBarrierException.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/CyclicBarrier.java ! src/share/classes/java/util/concurrent/Exchanger.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/TimeoutException.java ! src/share/classes/java/util/concurrent/package-info.java Changeset: bd6949f9dbb2 Author: twisti Date: 2013-07-03 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bd6949f9dbb2 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + test/java/lang/invoke/TestCatchExceptionWithVarargs.java Changeset: 7532bb2d6476 Author: psandoz Date: 2013-07-03 21:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7532bb2d6476 8017329: 8b92-lambda regression: TreeSet("a", "b").stream().substream(1).parallel().iterator() is empty Reviewed-by: alanb ! src/share/classes/java/util/stream/SliceOps.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java Changeset: d5de500c99a3 Author: juh Date: 2013-07-03 12:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d5de500c99a3 8019772: Fix doclint issues in javax.crypto and javax.security subpackages Reviewed-by: darcy ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherInputStream.java ! src/share/classes/javax/crypto/ExemptionMechanism.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/NullCipher.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/cert/X509Certificate.java Changeset: e594ee7a7c2f Author: vinnie Date: 2013-07-02 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e594ee7a7c2f 7165807: Non optimized initialization of NSS crypto library leads to scalability issues Reviewed-by: mullan, valeriep ! make/sun/security/pkcs11/mapfile-vers ! makefiles/mapfiles/libj2pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/native/sun/security/pkcs11/j2secmod.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.h ! src/windows/native/sun/security/pkcs11/j2secmod_md.h Changeset: cbee2e595600 Author: vinnie Date: 2013-07-03 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cbee2e595600 Merge Changeset: a49208237599 Author: bpb Date: 2013-07-03 13:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a49208237599 8019857: Fix doclint errors in java.util.Format* Summary: Fix doclint errors in java.util.Format*. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formattable.java ! src/share/classes/java/util/Formatter.java Changeset: a8f51c3341a5 Author: emc Date: 2013-07-03 19:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a8f51c3341a5 8016285: Add java.lang.reflect.Parameter.isNamePresent() Summary: Add isNamePresent method to parameter reflection library, which indicates whether or real parameter data is available Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Parameter.java ! test/java/lang/reflect/Parameter/WithParameters.java ! test/java/lang/reflect/Parameter/WithoutParameters.java Changeset: 043b2eb76b0e Author: bpb Date: 2013-07-03 17:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/043b2eb76b0e 8019862: Fix doclint errors in java.lang.*. Summary: Fix doclint errors in java.lang.* Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadLocal.java Changeset: dd69273a0240 Author: alanb Date: 2013-07-04 14:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dd69273a0240 8019622: (sl) ServiceLoader.next incorrect when creation and usages are in different contexts Reviewed-by: mchung, ahgross, forax, psandoz ! src/share/classes/java/util/ServiceLoader.java Changeset: aa9fefb5d9c4 Author: alanb Date: 2013-07-04 20:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aa9fefb5d9c4 8017231: Add StringJoiner.merge Reviewed-by: psandoz, alanb Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/StringJoiner.java + test/java/util/StringJoiner/MergeTest.java ! test/java/util/StringJoiner/StringJoinerTest.java Changeset: ed111451b77a Author: zhangshj Date: 2013-07-05 10:51 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ed111451b77a 8019381: HashMap.isEmpty is non-final, potential issues for get/remove Reviewed-by: chegar, mduigou ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/OverrideIsEmpty.java Changeset: 028ef97797c1 Author: mullan Date: 2013-07-05 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/028ef97797c1 8011547: Update XML Signature implementation to Apache Santuario 1.5.4 Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/Algorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithmSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/InvalidCanonicalizerException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/C14nHelper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_OmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclOmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315OmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java + src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerPhysical.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java + src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AbstractSerializer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherReference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherValue.java + src/share/classes/com/sun/org/apache/xml/internal/security/encryption/DocumentSerializer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedKey.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedType.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java + src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Serializer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Transforms.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherParameters.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLEncryptionException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/AlgorithmAlreadyRegisteredException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/Base64DecodingException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityRuntimeException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/ContentHandlerAlreadyRegisteredException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyUtils.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoContent.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoReference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyName.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/MgmtData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/PGPData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/RetrievalMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/SPKIData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/X509Data.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/DSAKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/KeyValueContent.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/RSAKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509CRL.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Certificate.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509DataContent.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Digest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509IssuerSerial.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SubjectName.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/InvalidKeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DEREncodedKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/EncryptedKeyResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/KeyInfoReferenceResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/PrivateKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SecretKeyResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SingleKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509CertificateResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509DigestResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509IssuerSerialResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SKIResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SubjectNameResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/KeyStoreResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/SingleCertificateResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidDigestValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidSignatureValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/MissingResourceFailureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/NodeFilter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ObjectContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ReferenceNotInitializedException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignedInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInputDebugger.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceData.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceNodeSetData.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceOctetStreamData.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceSubTreeData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/InvalidTransformException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformParam.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transforms.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere.java - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusive.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusiveWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformEnvelopedSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPointer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer04.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathFilterCHGPContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Constants.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/DOMNamespaceContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/DigesterOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementChecker.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionConstants.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/HelperNodeList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IgnoreAllErrorHandler.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/JDKXPathAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/JDKXPathFactory.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/Signature11ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignatureElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignerOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncBufferedOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFactory.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XalanXPathAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XalanXPathFactory.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverAnonymous.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverFragment.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverLocalFilesystem.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverXPointer.java ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/MacOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java + src/share/classes/org/jcp/xml/dsig/internal/dom/AbstractDOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java Changeset: e3208dbf6926 Author: mullan Date: 2013-07-05 16:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e3208dbf6926 Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: 49c5547d9e8e Author: lana Date: 2013-07-05 13:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/49c5547d9e8e Merge Changeset: 4fcabe8e22ce Author: lana Date: 2013-07-05 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4fcabe8e22ce Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java Changeset: 11c15607e43f Author: wetmore Date: 2013-07-05 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11c15607e43f 8019341: Update CookieHttpsClientTest to use the newer framework. Reviewed-by: xuelei, smarks, michaelm ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java ! test/sun/security/ssl/templates/SSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java Changeset: 715d00c95fb2 Author: ehelin Date: 2013-07-08 11:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/715d00c95fb2 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace Reviewed-by: alanb ! test/ProblemList.txt ! test/java/lang/management/MemoryMXBean/MemoryTest.java Changeset: 52454985425d Author: juh Date: 2013-07-08 19:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/52454985425d 8020091: Fix HTML doclint issues in java.io Reviewed-by: darcy ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/InputStreamReader.java ! src/share/classes/java/io/OutputStreamWriter.java ! src/share/classes/java/io/PipedInputStream.java ! src/share/classes/java/io/RandomAccessFile.java Changeset: eab8f4e29f5e Author: darcy Date: 2013-07-08 22:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eab8f4e29f5e 8020095: Fix doclint warnings in java.util.regex Reviewed-by: mchung ! src/share/classes/java/util/regex/MatchResult.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java Changeset: 628432ee4d68 Author: henryjen Date: 2013-07-09 09:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/628432ee4d68 8017141: java.util/stream Spliterators from sequential sources should not catch OOME Reviewed-by: mchung Contributed-by: paul.sandoz at oracle.com ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Spliterators.java Changeset: 44a634c1edc4 Author: psandoz Date: 2013-07-09 10:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44a634c1edc4 8019551: Make BaseStream public Reviewed-by: chegar, psandoz Contributed-by: brian goetz ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/BaseStream.java Changeset: 43134e79c0bb Author: psandoz Date: 2013-07-09 16:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/43134e79c0bb 8019370: Sync j.u.c Fork/Join from 166 to tl Reviewed-by: chegar, martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/Callable.java ! src/share/classes/java/util/concurrent/CancellationException.java ! src/share/classes/java/util/concurrent/CompletableFuture.java ! src/share/classes/java/util/concurrent/CompletionService.java ! src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ExecutionException.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/FutureTask.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/RecursiveTask.java ! src/share/classes/java/util/concurrent/RejectedExecutionException.java ! src/share/classes/java/util/concurrent/RunnableFuture.java ! src/share/classes/java/util/concurrent/RunnableScheduledFuture.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java Changeset: 83c2976ef8ee Author: coffeys Date: 2013-07-09 16:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/83c2976ef8ee 8019979: Replace CheckPackageAccess test with better one from closed repo Reviewed-by: mullan ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 7bb17aa9a09f Author: dholmes Date: 2013-07-09 22:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7bb17aa9a09f 8016341: java/lang/ref/OOMEInReferenceHandler.java failing intermittently Summary: Ensure WeakRef object can't be prematurely gc'd Reviewed-by: chegar, plevart ! test/java/lang/ref/OOMEInReferenceHandler.java Changeset: 780a64979c8d Author: weijun Date: 2013-07-10 15:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/780a64979c8d 8019267: NPE in AbstractSaslImpl when trace level >= FINER in KRB5 Reviewed-by: mullan ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! test/sun/security/krb5/auto/SaslGSS.java Changeset: ff5df05222d1 Author: psandoz Date: 2013-07-10 09:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff5df05222d1 8017447: Unmodifiable map entry becomes modifiable if taken from a stream of map entries Reviewed-by: briangoetz ! src/share/classes/java/util/Collections.java + test/java/util/Collections/UnmodifiableMapEntrySet.java Changeset: 882baa1e0a38 Author: psandoz Date: 2013-07-10 10:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/882baa1e0a38 8020040: Improve and generalize the F/J tasks to handle right or left-balanced trees Reviewed-by: briangoetz Contributed-by: doug lea
, paul sandoz ! src/share/classes/java/util/stream/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/AbstractTask.java ! src/share/classes/java/util/stream/ForEachOps.java ! src/share/classes/java/util/stream/Nodes.java Changeset: 7c44ea602cc8 Author: darcy Date: 2013-07-10 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7c44ea602cc8 8020294: Fix doclint issues in java.util.Spliterator Reviewed-by: psandoz ! src/share/classes/java/util/Spliterator.java Changeset: 607fa1ff3de2 Author: bpb Date: 2013-07-09 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/607fa1ff3de2 6178739: (fmt) Formatter.format("%0.4f\n", 56789.456789) generates MissingFormatWidthException Summary: Change the field width specification to require a positive value. The exception is still thrown but that is now explicitly consistent with the specification. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java Changeset: 2ee772cda1d6 Author: bpb Date: 2013-07-09 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2ee772cda1d6 6480539: BigDecimal.stripTrailingZeros() has no effect on zero itself ("0.0") Summary: Make stripTrailingZeros() return BigDecimal.ZERO if the BigDecimal is numerically equal to zero. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigDecimal.java ! test/java/math/BigDecimal/StrippingZerosTest.java Changeset: 69d9fe8175a0 Author: sspitsyn Date: 2013-07-10 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/69d9fe8175a0 8020308: Fix doclint issues in java.lang.management Reviewed-by: darcy Contributed-by: serguei.spitsyn at oracle.com ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/MemoryMXBean.java ! src/share/classes/java/lang/management/MemoryNotificationInfo.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/MemoryUsage.java ! src/share/classes/java/lang/management/MonitorInfo.java ! src/share/classes/java/lang/management/RuntimeMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java Changeset: 702556f7977e Author: juh Date: 2013-07-10 18:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/702556f7977e 8020318: Fix doclint issues in java.net Reviewed-by: darcy, khazra ! src/share/classes/java/net/CookieStore.java ! src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/ProtocolFamily.java ! src/share/classes/java/net/SocketOption.java ! src/share/classes/java/net/URI.java Changeset: a46982a212e0 Author: jbachorik Date: 2013-07-11 09:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a46982a212e0 8019826: Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE Reviewed-by: sjiang, dholmes, mchung ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java Changeset: 05b164788aab Author: psandoz Date: 2013-07-11 13:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/05b164788aab 8019484: Sync j.u.c.ConcurrentHashMap from 166 to tl Reviewed-by: martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java Changeset: dadcfd84d33f Author: sundar Date: 2013-07-11 18:50 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dadcfd84d33f 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error Reviewed-by: mcimadamore, jlaskey, hannesw, attila ! src/share/classes/javax/script/ScriptEngineFactory.java Changeset: 162c015c434a Author: valeriep Date: 2013-07-11 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/162c015c434a 8020321: Problem in PKCS11 regression test TestRSAKeyLength Summary: Corrected the "isValidKeyLength" array Reviewed-by: xuelei ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java Changeset: f3211af79339 Author: jbachorik Date: 2013-07-11 21:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f3211af79339 8010285: Enforce the requirement of Management Interfaces being public Reviewed-by: sjiang, dfuchs, mchung ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/package.html ! src/share/classes/sun/management/ManagementFactoryHelper.java + test/javax/management/MBeanServer/MBeanFallbackTest.java + test/javax/management/MBeanServer/MBeanTest.java + test/javax/management/mxbean/MXBeanFallbackTest.java ! test/javax/management/mxbean/MXBeanTest.java + test/javax/management/proxy/JMXProxyFallbackTest.java + test/javax/management/proxy/JMXProxyTest.java Changeset: 0bd48087e2dc Author: ksrini Date: 2013-07-11 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0bd48087e2dc 8019799: api/java_util/jar/Pack200 test failed with compactX profiles. Reviewed-by: dholmes ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java Changeset: 10d2a4b1e576 Author: dxu Date: 2013-07-11 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/10d2a4b1e576 8017212: File.createTempFile requires unnecessary "read" permission Summary: Directly call FileSystem method to check a file existence. Also reviewed by tom.hawtin at oracle.com Reviewed-by: alanb ! src/share/classes/java/io/File.java + test/java/io/File/CheckPermission.java ! test/java/io/File/NulFile.java ! test/java/io/File/createTempFile/SpecialTempFile.java Changeset: f225da733291 Author: valeriep Date: 2013-07-05 13:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f225da733291 8012637: Adjust CipherInputStream class to work in AEAD/GCM mode Summary: Ensure the Cipher.doFinal() is called only once Reviewed-by: xuelei ! src/share/classes/javax/crypto/CipherInputStream.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCM.java Changeset: 6e2a5637b286 Author: valeriep Date: 2013-07-05 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6e2a5637b286 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful Summary: Check equality based on component values instead of encoding which may vary due to optional components Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: f321b78c7009 Author: ascarpino Date: 2013-07-08 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f321b78c7009 6755701: SunJCE DES/DESede SecretKeyFactory.generateSecret throws InvalidKeySpecExc if passed SecretKeySpec Reviewed-by: valeriep, wetmore, xuelei ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java + test/com/sun/crypto/provider/Cipher/DES/DESSecretKeySpec.java Changeset: 869bfa39d923 Author: valeriep Date: 2013-07-08 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/869bfa39d923 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java Changeset: 4fcac826628c Author: valeriep Date: 2013-07-09 15:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4fcac826628c Merge Changeset: 7bd2993e03fa Author: valeriep Date: 2013-07-10 18:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7bd2993e03fa 8020310: JDK-6356530 broke the old build Summary: Add serialVersionUID to AuthProvider and P11Key class. Reviewed-by: xuelei ! src/share/classes/java/security/AuthProvider.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: 4c95c032c395 Author: valeriep Date: 2013-07-11 17:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4c95c032c395 Merge Changeset: 858c75eb83b5 Author: mchung Date: 2013-07-08 14:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/858c75eb83b5 8014890: (ref) Reference queues may return more entries than expected Summary: When enqueuing references check whether the j.l.r.Reference has already been enqeued or removed in the lock. Do not enqueue them again. This occurs because multiple threads may try to enqueue the same j.l.r.Reference at the same time. Reviewed-by: mchung, dholmes, plevart, shade Contributed-by: thomas.schatzl at oracle.com ! src/share/classes/java/lang/ref/Reference.java ! src/share/classes/java/lang/ref/ReferenceQueue.java + test/java/lang/ref/EnqueuePollRace.java Changeset: 2504f01bc83f Author: joehw Date: 2013-07-12 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2504f01bc83f 8020430: NullPointerException in xml sqe nightly result on 2013-07-12 Reviewed-by: chegar, lancea + test/javax/xml/jaxp/common/8020430/JAXP15RegTest.java + test/javax/xml/jaxp/common/8020430/TestBase.java Changeset: af62c6175f92 Author: darcy Date: 2013-07-12 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/af62c6175f92 8010679: Clarify "present" and annotation ordering in Core Reflection for Annotations Reviewed-by: abuckley, jfranck ! src/share/classes/java/lang/reflect/AnnotatedElement.java Changeset: fe6e4e2c367d Author: mduigou Date: 2013-07-12 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fe6e4e2c367d 7129185: Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} Reviewed-by: dmocek, martin, smarks ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/NavigableSet.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/CheckedIdentityMap.java ! test/java/util/Collections/CheckedMapBash.java ! test/java/util/Collections/CheckedSetBash.java ! test/java/util/Collections/EmptyCollectionSerialization.java + test/java/util/Collections/EmptyNavigableMap.java + test/java/util/Collections/EmptyNavigableSet.java - test/java/util/Collections/EmptySortedSet.java ! test/java/util/Map/LockStep.java ! test/java/util/NavigableMap/LockStep.java Changeset: 623a10b23ed8 Author: mduigou Date: 2013-07-12 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/623a10b23ed8 8015317: Optional.filter, map, and flatMap Reviewed-by: psandoz, mduigou Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/OptionalDouble.java ! src/share/classes/java/util/OptionalInt.java ! src/share/classes/java/util/OptionalLong.java ! test/java/util/Optional/Basic.java Changeset: 06749efce430 Author: mduigou Date: 2013-07-12 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/06749efce430 8015315: Stream.concat methods Reviewed-by: psandoz, mduigou Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java Changeset: 5b6f94559589 Author: mduigou Date: 2013-07-12 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5b6f94559589 Merge - test/java/util/Collections/EmptySortedSet.java Changeset: be096613bfb5 Author: psandoz Date: 2013-07-03 21:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/be096613bfb5 8019395: Consolidate StreamSupport.{stream,parallelStream} into a single method Reviewed-by: henryjen, briangoetz ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/zip/ZipFile.java ! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/TestData.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java Changeset: b3ca5fb77e2c Author: vinnie Date: 2013-07-12 20:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b3ca5fb77e2c 8019627: RuntimeException gets obscured during OCSP cert revocation checking Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java Changeset: 9b17939958e7 Author: henryjen Date: 2013-07-12 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9b17939958e7 8015320: Pull spliterator() up from Collection to Iterable Reviewed-by: psandoz, mduigou Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/ConcurrentModificationException.java ! test/java/util/Spliterator/SpliteratorCollisions.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Changeset: 37c37361a7ad Author: henryjen Date: 2013-07-08 15:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/37c37361a7ad 8020062: Nest StreamBuilder interfaces inside relevant Stream interfaces Reviewed-by: psandoz, mduigou Contributed-by: brian goetz ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java - src/share/classes/java/util/stream/StreamBuilder.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java Changeset: 5f2a8db78aca Author: weijun Date: 2013-07-13 08:47 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5f2a8db78aca 8019410: sun/security/krb5/auto/ReplayCacheTestProc.java Reviewed-by: mullan ! test/sun/security/krb5/auto/ReplayCacheTestProc.java Changeset: e4ce6502eac0 Author: plevart Date: 2013-07-15 10:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e4ce6502eac0 7122142: (ann) Race condition between isAnnotationPresent and getAnnotations Reviewed-by: dholmes, jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/annotation/AnnotationType.java + test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java + test/java/lang/annotation/AnnotationType/AnnotationTypeRuntimeAssumptionTest.java Changeset: 7cc35dd1885d Author: coffeys Date: 2013-07-15 13:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7cc35dd1885d 8017566: Backout 8000450 - Cannot access to com.sun.corba.se.impl.orb.ORBImpl Reviewed-by: mchung ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 94e1a4b10811 Author: bpb Date: 2013-07-15 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/94e1a4b10811 8020409: Clean up doclint problems in java.util package, part 1 Summary: Clean up doclint problems in java.util package, part 1 Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Base64.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/ResourceBundle.java Changeset: f7af15e2c95b Author: juh Date: 2013-07-16 12:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f7af15e2c95b 8020557: javadoc cleanup in javax.security Reviewed-by: darcy ! src/share/classes/javax/security/auth/AuthPermission.java ! src/share/classes/javax/security/auth/DestroyFailedException.java ! src/share/classes/javax/security/auth/Destroyable.java ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/RefreshFailedException.java ! src/share/classes/javax/security/auth/Refreshable.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/callback/Callback.java ! src/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/share/classes/javax/security/auth/callback/ChoiceCallback.java ! src/share/classes/javax/security/auth/callback/ConfirmationCallback.java ! src/share/classes/javax/security/auth/callback/LanguageCallback.java ! src/share/classes/javax/security/auth/callback/NameCallback.java ! src/share/classes/javax/security/auth/callback/PasswordCallback.java ! src/share/classes/javax/security/auth/callback/TextInputCallback.java ! src/share/classes/javax/security/auth/callback/TextOutputCallback.java ! src/share/classes/javax/security/auth/callback/UnsupportedCallbackException.java + src/share/classes/javax/security/auth/callback/package-info.java - src/share/classes/javax/security/auth/callback/package.html ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/KerberosKey.java ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/javax/security/auth/kerberos/KerberosTicket.java ! src/share/classes/javax/security/auth/kerberos/KeyImpl.java ! src/share/classes/javax/security/auth/kerberos/KeyTab.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java + src/share/classes/javax/security/auth/kerberos/package-info.java - src/share/classes/javax/security/auth/kerberos/package.html ! src/share/classes/javax/security/auth/login/AccountExpiredException.java ! src/share/classes/javax/security/auth/login/AppConfigurationEntry.java ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/ConfigurationSpi.java ! src/share/classes/javax/security/auth/login/CredentialExpiredException.java ! src/share/classes/javax/security/auth/login/FailedLoginException.java ! src/share/classes/javax/security/auth/login/LoginContext.java + src/share/classes/javax/security/auth/login/package-info.java - src/share/classes/javax/security/auth/login/package.html + src/share/classes/javax/security/auth/package-info.java - src/share/classes/javax/security/auth/package.html ! src/share/classes/javax/security/auth/spi/LoginModule.java + src/share/classes/javax/security/auth/spi/package-info.java - src/share/classes/javax/security/auth/spi/package.html ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/javax/security/auth/x500/X500PrivateCredential.java + src/share/classes/javax/security/auth/x500/package-info.java - src/share/classes/javax/security/auth/x500/package.html ! src/share/classes/javax/security/cert/Certificate.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/CertificateParsingException.java ! src/share/classes/javax/security/cert/X509Certificate.java + src/share/classes/javax/security/cert/package-info.java - src/share/classes/javax/security/cert/package.html ! src/share/classes/javax/security/sasl/AuthenticationException.java ! src/share/classes/javax/security/sasl/AuthorizeCallback.java ! src/share/classes/javax/security/sasl/RealmCallback.java ! src/share/classes/javax/security/sasl/RealmChoiceCallback.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslClient.java ! src/share/classes/javax/security/sasl/SaslClientFactory.java ! src/share/classes/javax/security/sasl/SaslException.java ! src/share/classes/javax/security/sasl/SaslServer.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java + src/share/classes/javax/security/sasl/package-info.java - src/share/classes/javax/security/sasl/package.html Changeset: cbdd2529d93a Author: lana Date: 2013-07-17 00:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cbdd2529d93a Merge Changeset: f2558ef87d5a Author: lana Date: 2013-07-17 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f2558ef87d5a Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 5be9c5bfcfe9 Author: lana Date: 2013-07-22 17:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5be9c5bfcfe9 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 690161232823 Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/690161232823 Added tag jdk8-b100 for changeset 5be9c5bfcfe9 ! .hgtags From john.coomes at oracle.com Thu Jul 25 11:13:54 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 18:13:54 +0000 Subject: hg: hsx/hotspot-main/langtools: 25 new changesets Message-ID: <20130725181519.C5B214837C@hg.openjdk.java.net> Changeset: d6158f8d7235 Author: vromero Date: 2013-07-04 10:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d6158f8d7235 8009924: some langtools tools do not accept -cp as an alias for -classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/share/classes/com/sun/tools/javadoc/ToolOption.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/resources/l10n.properties ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties ! test/tools/doclint/tool/HelpTest.out Changeset: 79c3146e417b Author: vromero Date: 2013-07-04 10:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/79c3146e417b 6356530: -Xlint:serial does not flag abstract classes with concrete methods/members Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.java + test/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.out Changeset: 7b756b307e12 Author: mcimadamore Date: 2013-07-05 11:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7b756b307e12 8017618: NullPointerException in RichDiagnosticFormatter for bad input program Summary: RDF crashes when diagnostic contains type 'void' Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/lambda/BadNestedLambda.java + test/tools/javac/lambda/BadNestedLambda.out Changeset: 70b37cdb19d5 Author: mcimadamore Date: 2013-07-05 11:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/70b37cdb19d5 8019480: Javac crashes when method is called on a type-variable receiver from lambda expression Summary: Logic for shortcircuiting speculative attribution doesn't handle type-variable receivers Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/8019480/T8019480.java + test/tools/javac/lambda/8019480/T8019480.out Changeset: b0386f0dc28e Author: mcimadamore Date: 2013-07-05 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b0386f0dc28e 8016059: Cannot compile following lambda 8016060: Lambda isn't compiled with return statement Summary: Spurious error triggered during unnecessary recovery round Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/TargetType75.java Changeset: bfbedbfc522a Author: mcimadamore Date: 2013-07-05 11:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bfbedbfc522a 8016702: use of ternary operator in lambda expression gives incorrect results Summary: Constant types erroneously creep in during inference Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/conditional/T8016702.java Changeset: 42b3c5e92461 Author: mcimadamore Date: 2013-07-05 11:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/42b3c5e92461 8019824: very long error messages on inference error Summary: Inference error messages shows several spurious captured variables generated during an inference loop Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8019824/T8019824.java + test/tools/javac/generics/inference/8019824/T8019824.out Changeset: 49654c9c705b Author: lana Date: 2013-07-05 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/49654c9c705b Merge Changeset: aedb3bb327d5 Author: ksrini Date: 2013-07-09 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/aedb3bb327d5 8020214: TEST_BUG: test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java broken Reviewed-by: jjg ! test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java Changeset: 87a951c88a33 Author: mcimadamore Date: 2013-07-11 15:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/87a951c88a33 8013404: Unclear spec for target typing with conditional operator (?:) Summary: Fix previously ignored test Reviewed-by: jjg, vromero ! test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType36.out Changeset: 37031963493e Author: jjg Date: 2013-07-12 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/37031963493e 8020278: NPE in javadoc Reviewed-by: mcimadamore, vromero ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Env.java + test/tools/doclint/BadPackageCommentTest.java + test/tools/doclint/BadPackageCommentTest.out Changeset: 44e27378f523 Author: mcimadamore Date: 2013-07-17 14:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/44e27378f523 8012242: Lambda compatibility and checked exceptions Summary: Inference variables in 'throws' clause with no constraints should be inferred as RuntimeException Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/generics/6723444/T6723444.java - test/tools/javac/generics/6723444/T6723444.out + test/tools/javac/generics/6723444/T6723444_1.out + test/tools/javac/generics/6723444/T6723444_2.out ! test/tools/javac/generics/7015430/T7015430.java - test/tools/javac/generics/7015430/T7015430.out + test/tools/javac/generics/7015430/T7015430_1.out + test/tools/javac/generics/7015430/T7015430_2.out + test/tools/javac/lambda/TargetType63.java + test/tools/javac/lambda/TargetType63.out Changeset: 866c87c01285 Author: mcimadamore Date: 2013-07-17 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/866c87c01285 8016175: Add bottom-up type-checking support for unambiguous method references Summary: Type-checking of non-overloaded method references should be independent from target-type Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/MethodReference68.java + test/tools/javac/lambda/MethodReference68.out + test/tools/javac/lambda/MethodReference69.java + test/tools/javac/lambda/MethodReference69.out + test/tools/javac/lambda/MethodReference70.java + test/tools/javac/lambda/MethodReference70.out + test/tools/javac/lambda/MethodReference71.java + test/tools/javac/lambda/MethodReference71.out + test/tools/javac/lambda/MethodReference72.java + test/tools/javac/lambda/MethodReference72.out ! test/tools/javac/lambda/TargetType60.out + test/tools/javac/lambda/TargetType76.java Changeset: a204cf7aab7e Author: mcimadamore Date: 2013-07-17 14:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a204cf7aab7e 8012238: Nested method capture and inference 8008200: java/lang/Class/asSubclass/BasicUnit.java fails to compile Summary: Inference support should be more flexible w.r.t. nested method calls returning captured types Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/NestedCapture01.java + test/tools/javac/lambda/NestedCapture02.java + test/tools/javac/lambda/NestedCapture03.java Changeset: c60a5099863a Author: mcimadamore Date: 2013-07-17 14:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c60a5099863a 8020147: Spurious errors when compiling nested stuck lambdas Summary: Scope of deferred types is not copied correctly; postAttr analyzer should not run on stuck expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/lambda/8020147/T8020147.java + test/tools/javac/lambda/8020147/T8020147.out Changeset: 328896931b98 Author: mcimadamore Date: 2013-07-17 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/328896931b98 8020286: Wrong diagnostic after compaction Summary: compact diagnostic shows the least relevant method in the list Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/Diagnostics/compressed/T8020286.java + test/tools/javac/Diagnostics/compressed/T8020286.out Changeset: db2c539819dd Author: mcimadamore Date: 2013-07-17 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/db2c539819dd 7041019: Bogus type-variable substitution with array types with dependencies on accessibility check Summary: call to upperBound() when performing type-variable substitution on element type leads to unsoundness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/generics/7034511/T7034511a.java ! test/tools/javac/generics/7034511/T7034511a.out ! test/tools/javac/generics/7034511/T7034511b.java ! test/tools/javac/generics/7034511/T7034511b.out + test/tools/javac/generics/7034511/T7041019.java Changeset: fae8f309ff80 Author: mcimadamore Date: 2013-07-17 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fae8f309ff80 8016640: compiler hangs if the generics arity of a base class is wrong Summary: Check.checkCompatibleConcretes hang when javac creates synthetic supertypes for 269 model API Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java + test/tools/javac/generics/8016640/T8016640.java + test/tools/javac/generics/8016640/T8016640.out Changeset: 155809b1b969 Author: mcimadamore Date: 2013-07-17 14:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/155809b1b969 8020149: Graph inference: wrong logic for picking best variable to solve Summary: Replace logic for selecting best inference leaf in the graph during an unsticking round Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8020149/T8020149.java Changeset: b577222ef7b3 Author: mcimadamore Date: 2013-07-17 14:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b577222ef7b3 8019340: varargs-related warnings are meaningless on signature-polymorphic methods such as MethodHandle.invokeExact Summary: Disable certain varargs warnings when compiling polymorphic signature calls Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/meth/VarargsWarn.java + test/tools/javac/meth/VarargsWarn.out Changeset: f65a807714ba Author: mcimadamore Date: 2013-07-17 14:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f65a807714ba 8019942: Graph inference: avoid redundant computation during bound incorporation Summary: Bound incorporation should not perform same operation multiple times Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/generics/inference/8019824/T8019824.out Changeset: 10711bd8bb2d Author: jlahoda Date: 2013-07-17 15:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/10711bd8bb2d 8020586: Warning produced for an incorrect file Summary: Always using DeferredLintHandler.immediateHandler when processing import classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/warnings/6594914/Auxiliary.java + test/tools/javac/warnings/6594914/ExplicitCompilation.out + test/tools/javac/warnings/6594914/ImplicitCompilation.java + test/tools/javac/warnings/6594914/ImplicitCompilation.out Changeset: e990e6bcecbe Author: lana Date: 2013-07-17 10:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e990e6bcecbe Merge ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: 82f68da70e47 Author: lana Date: 2013-07-22 17:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/82f68da70e47 Merge - test/tools/javac/generics/6723444/T6723444.out - test/tools/javac/generics/7015430/T7015430.out Changeset: 0324dbf07b0f Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0324dbf07b0f Added tag jdk8-b100 for changeset 82f68da70e47 ! .hgtags From john.coomes at oracle.com Thu Jul 25 11:15:40 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 18:15:40 +0000 Subject: hg: hsx/hotspot-main/nashorn: 51 new changesets Message-ID: <20130725181625.ABFEE4837D@hg.openjdk.java.net> Changeset: 313bdcd2fd22 Author: sundar Date: 2013-07-03 00:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/313bdcd2fd22 8019629: void operator should always evaluate to undefined Reviewed-by: jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019629.js Changeset: 9d3a9fdab668 Author: sundar Date: 2013-07-03 13:13 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9d3a9fdab668 8019783: typeof does not work properly for java methods and foreign objects Reviewed-by: hannesw ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019783.js + test/script/basic/JDK-8019783.js.EXPECTED ! test/script/basic/NASHORN-759.js.EXPECTED Changeset: 4afdc5bec43b Author: sundar Date: 2013-07-03 14:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4afdc5bec43b 8019791: ~ is a unary operator Reviewed-by: hannesw ! src/jdk/nashorn/internal/parser/TokenType.java + test/script/basic/JDK-8019791.js + test/script/basic/JDK-8019791.js.EXPECTED Changeset: 18d467e94150 Author: attila Date: 2013-07-03 12:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/18d467e94150 8010946: AccessControl.doPrivileged is broken when called from js script Reviewed-by: jlaskey, sundar ! make/build.xml ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java + src/jdk/internal/dynalink/beans/CallerSensitiveDetector.java + src/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/DynamicMethod.java ! src/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java + src/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk/internal/dynalink/beans/StaticClassIntrospector.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + test/script/basic/JDK-8010946-2.js + test/script/basic/JDK-8010946-2.js.EXPECTED + test/script/basic/JDK-8010946-privileged.js + test/script/basic/JDK-8010946.js + test/script/basic/JDK-8010946.js.EXPECTED Changeset: b1980b5f00a1 Author: lagergren Date: 2013-07-03 13:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b1980b5f00a1 8019585: Sometimes a var declaration using itself in its init wasn't declared as canBeUndefined, causing erroneous bytecode Reviewed-by: sundar, attila ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java + test/script/basic/JDK-8019585.js Changeset: eb1437d16ab4 Author: sundar Date: 2013-07-03 17:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/eb1437d16ab4 8019805: for each (init; test; modify) is invalid Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019805.js + test/script/basic/JDK-8019805.js.EXPECTED ! test/script/basic/forin.js ! test/script/basic/forin.js.EXPECTED Changeset: 961cffae0828 Author: lagergren Date: 2013-07-03 15:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/961cffae0828 8019811: Static calls - self referential functions needed a return type conversion if they were specialized, as they can't use the same mechanism as indy calls Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! test/script/basic/JDK-8016667.js + test/script/basic/JDK-8019808.js + test/script/basic/JDK-8019810.js + test/script/basic/JDK-8019810.js.EXPECTED + test/script/basic/JDK-8019811.js + test/script/basic/JDK-8019817.js + test/script/currently-failing/JDK-8019809.js Changeset: fcb484c43348 Author: sundar Date: 2013-07-03 19:20 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fcb484c43348 8019814: Add regression test for passing cases Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ListAdapter.java + test/script/basic/JDK-8019814.js + test/script/basic/JDK-8019814.js.EXPECTED Changeset: 29b2b2ed954c Author: attila Date: 2013-07-03 18:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/29b2b2ed954c 8017768: allow dot as inner class name separator for Java.type Reviewed-by: jlaskey, sundar ! docs/JavaScriptingProgrammersGuide.html ! src/jdk/nashorn/internal/objects/NativeJava.java + test/script/basic/JDK-8017768.js + test/script/basic/JDK-8017768.js.EXPECTED ! test/src/jdk/nashorn/test/models/OuterClass.java Changeset: 7b072ebdf5aa Author: jlaskey Date: 2013-07-03 13:41 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7b072ebdf5aa 8011629: Object.defineProperty performance issue Reviewed-by: sundar, attila Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/AccessorProperty.java Changeset: ad6b18ee4666 Author: attila Date: 2013-07-04 14:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ad6b18ee4666 8019809: return after break incorrectly sets the block as terminal Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java + test/script/basic/JDK-8019809.js - test/script/currently-failing/JDK-8019809.js Changeset: be2087629eb9 Author: lagergren Date: 2013-07-04 17:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/be2087629eb9 8019821: allInteger switches were confused by boolean cases, as they are a narrower type than int Reviewed-by: sundar, hannesw ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8019821.js Changeset: 8c4a6d9b8a23 Author: lagergren Date: 2013-07-04 17:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8c4a6d9b8a23 Merge - test/script/currently-failing/JDK-8019809.js Changeset: ec84ba68ad39 Author: sundar Date: 2013-07-05 14:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ec84ba68ad39 8019947: inherited property invalidation does not work with two globals in same context Reviewed-by: jlaskey, lagergren, hannesw, attila ! make/build-nasgen.xml ! make/build.xml ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/JDK-8019947.js + test/script/basic/JDK-8019947.js.EXPECTED Changeset: edca88d3a03e Author: hannesw Date: 2013-07-05 14:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/edca88d3a03e 8017084: Use spill properties for large object literals Reviewed-by: lagergren, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java + src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/scripts/JO.java + test/script/basic/JDK-8017084.js + test/script/basic/JDK-8017084.js.EXPECTED Changeset: ce9cbe70f915 Author: attila Date: 2013-07-05 15:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ce9cbe70f915 8019819: scope symbol didn't get a slot in certain cases Reviewed-by: hannesw, jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8019819.js Changeset: 20b2c2dc20e8 Author: lagergren Date: 2013-07-05 19:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/20b2c2dc20e8 8019983: Void returns combined with return with expression picked the wrong return type Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8019983.js + test/script/basic/JDK-8019983.js.EXPECTED Changeset: 36d6b6a3fbe0 Author: sundar Date: 2013-07-08 16:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/36d6b6a3fbe0 8020015: shared PropertyMaps should not be used without duplication Reviewed-by: hannesw, attila ! buildtools/nasgen/build.xml ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! make/code_coverage.xml ! make/project.properties ! src/jdk/nashorn/internal/lookup/Lookup.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java Changeset: a75e75cc6a61 Author: sundar Date: 2013-07-08 18:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a75e75cc6a61 8020035: nashorn jdk buildfile BuildNashorn.gmk still renamed jdk.nashorn.internal.objects package Reviewed-by: attila, jlaskey ! makefiles/BuildNashorn.gmk Changeset: c96745616167 Author: sundar Date: 2013-07-08 18:43 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c96745616167 Merge Changeset: 5106d43feed7 Author: hannesw Date: 2013-07-08 19:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5106d43feed7 8019963: empty char range in regex Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java + test/script/basic/JDK-8019963.js + test/script/basic/JDK-8019963.js.EXPECTED Changeset: d3f4e5dea634 Author: attila Date: 2013-07-09 13:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d3f4e5dea634 8009758: reactivate the 8006529 test. Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java - test/script/currently-failing/JDK-8006529.js + test/script/trusted/JDK-8006529.js Changeset: 7538a59ca241 Author: sundar Date: 2013-07-09 17:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7538a59ca241 8014785: Ability to extend global instance by binding properties of another object Reviewed-by: attila, hannesw, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java + test/script/basic/JDK-8014785.js + test/script/basic/JDK-8014785.js.EXPECTED Changeset: d480015ab732 Author: lagergren Date: 2013-07-09 15:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d480015ab732 8020124: In the case of an eval switch, we might need explicit conversions of the tag store, as it was not known in the surrounding environment. Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8020124.js Changeset: 997a3215744a Author: sundar Date: 2013-07-10 13:25 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/997a3215744a 8020224: LinkageError: attempted duplicate class definition when --loader-per-compiler=false Reviewed-by: hannesw ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: a9b74daed4f9 Author: hannesw Date: 2013-07-10 10:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a9b74daed4f9 8016681: regex capture behaves differently than on V8 Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8016681.js + test/script/basic/JDK-8016681.js.EXPECTED Changeset: c501b1666bda Author: sundar Date: 2013-07-10 19:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c501b1666bda 8020276: interface checks in Invocable.getInterface implementation Reviewed-by: jlaskey, hannesw, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 798e3aa19718 Author: sundar Date: 2013-07-11 16:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/798e3aa19718 8020325: static property does not work on accessible, public classes Reviewed-by: attila, hannesw, lagergren ! make/build.xml ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/lookup/Lookup.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java + test/script/basic/JDK-8020325.js + test/script/basic/JDK-8020325.js.EXPECTED ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 58614b556a0d Author: sundar Date: 2013-07-11 18:23 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/58614b556a0d 8020380: __noSuchProperty__ defined in mozilla_compat.js script should be non-enumerable Reviewed-by: jlaskey, hannesw, attila ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8020380.js Changeset: 2c007a8bb0e7 Author: attila Date: 2013-07-11 18:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2c007a8bb0e7 8013925: Remove symbol fields from nodes that don't need them Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/RangeAnalyzer.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java + src/jdk/nashorn/internal/ir/BlockStatement.java ! src/jdk/nashorn/internal/ir/BreakableNode.java + src/jdk/nashorn/internal/ir/BreakableStatement.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java - src/jdk/nashorn/internal/ir/ExecuteNode.java + src/jdk/nashorn/internal/ir/Expression.java + src/jdk/nashorn/internal/ir/ExpressionStatement.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java + src/jdk/nashorn/internal/ir/LexicalContextExpression.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java + src/jdk/nashorn/internal/ir/LexicalContextStatement.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/LoopNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/TemporarySymbols.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! test/script/trusted/JDK-8006529.js Changeset: 9083af56bbcb Author: sundar Date: 2013-07-11 22:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9083af56bbcb 8012191: noSuchProperty can't cope with vararg functions Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8012191.js + test/script/basic/JDK-8012191.js.EXPECTED Changeset: 289923785ada Author: attila Date: 2013-07-11 22:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/289923785ada 8020125: PrintVisitor wasn't printing bodies of FunctionNode within UnaryNode Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java Changeset: d763da247244 Author: sundar Date: 2013-07-12 15:01 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d763da247244 8020437: Wrong handling of line numbers with multiline string literals Reviewed-by: attila, lagergren ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8020437.js + test/script/basic/JDK-8020437.js.EXPECTED + test/script/error/JDK-8020437-2.js + test/script/error/JDK-8020437-2.js.EXPECTED + test/script/error/JDK-8020437.js + test/script/error/JDK-8020437.js.EXPECTED Changeset: 1a6b1799f533 Author: sundar Date: 2013-07-12 15:27 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1a6b1799f533 8020223: ClassCastException: String can not be casted to ScriptFunction Reviewed-by: attila, lagergren ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8020223.js Changeset: e27ebcfed6fa Author: attila Date: 2013-07-12 11:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e27ebcfed6fa 8019822: Duplicate name and signature in finally block Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8019822.js Changeset: 8108ba8366fd Author: sundar Date: 2013-07-12 20:12 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8108ba8366fd Merge - src/jdk/nashorn/internal/ir/ExecuteNode.java - test/script/currently-failing/JDK-8006529.js Changeset: 5cdf4352ee0b Author: sundar Date: 2013-07-12 20:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5cdf4352ee0b 8020463: Input argument array wrapping in loadWithNewGlobal is wrong Reviewed-by: attila, jlaskey ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8020463.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: cbfeffbcd3f2 Author: sundar Date: 2013-07-12 20:13 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/cbfeffbcd3f2 Merge Changeset: 973d78ee0728 Author: attila Date: 2013-07-15 12:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/973d78ee0728 8020324: Implement Object.bindProperties(target, source) for beans Reviewed-by: hannesw, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethod.java + src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java + test/script/basic/JDK-8020324.js + test/script/basic/JDK-8020324.js.EXPECTED + test/src/jdk/nashorn/test/models/PropertyBind.java Changeset: 62c552bcc342 Author: hannesw Date: 2013-07-15 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/62c552bcc342 8020354: Object literal property initialization is not done in source order Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8020354.js + test/script/basic/JDK-8020354.js.EXPECTED Changeset: ede320e13c82 Author: attila Date: 2013-07-15 16:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ede320e13c82 8020508: Enforce reflection access restrictions on Object.bindProperties Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java + test/script/basic/JDK-8020508.js + test/script/basic/JDK-8020508.js.EXPECTED Changeset: e5505f0b10de Author: hannesw Date: 2013-07-15 16:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e5505f0b10de 8020283: Don't use exceptions for widening of ArrayData Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java Changeset: 01212f5e7dad Author: attila Date: 2013-07-15 16:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/01212f5e7dad 8011210: fix reporting of call site locations; print them on -tcs=miss Reviewed-by: jlaskey, hannesw ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java Changeset: 28f1f2374004 Author: hannesw Date: 2013-07-15 18:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/28f1f2374004 8020358: Array(0xfffffff) throws OutOfMemoryError Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + test/script/basic/JDK-8020358.js + test/script/basic/JDK-8020358.js.EXPECTED Changeset: d685fec24d13 Author: sundar Date: 2013-07-16 09:54 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d685fec24d13 Merge Changeset: 965d876853ec Author: attila Date: 2013-07-16 15:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/965d876853ec 8020357: throw RangeError for too large NativeArrayBuffer size Reviewed-by: jlaskey, hannesw, sundar ! src/jdk/nashorn/internal/objects/ArrayBufferView.java + test/script/basic/JDK-8020357.js + test/script/basic/JDK-8020357.js.EXPECTED Changeset: 7503f30c1355 Author: hannesw Date: 2013-07-16 16:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7503f30c1355 8010821: [findbugs] Some classes in jdk.nashorn.internal.runtime.regexp expose mutable objects Reviewed-by: attila, jlaskey, sundar ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java ! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Token.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/BackRefNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java Changeset: 78bdb8a7f1e7 Author: attila Date: 2013-07-16 17:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/78bdb8a7f1e7 8015356: array concatenation should skip empty elements Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8015356.js + test/script/basic/JDK-8015356.js.EXPECTED Changeset: 81cbb18d558a Author: lana Date: 2013-07-17 00:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/81cbb18d558a Merge Changeset: 598321c438b5 Author: lana Date: 2013-07-22 17:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/598321c438b5 Merge - src/jdk/nashorn/internal/ir/ExecuteNode.java - test/script/currently-failing/JDK-8006529.js Changeset: a302b05d0ee4 Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a302b05d0ee4 Added tag jdk8-b100 for changeset 598321c438b5 ! .hgtags From goetz.lindenmaier at sap.com Thu Jul 25 16:11:01 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 25 Jul 2013 23:11:01 +0000 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> Hi, we'd like to contribute our posix signal printing. We implemented some routines to print signal and sa_flags information in the os/posix files, and call them from os::print_siginfo and print_signal_handler() in the various unix variant directories. The output is a bit more verbose than the existing version. We contribute this here, as our aix code uses this too. Please review this and test it if you think we should add this. We'd appreciate it. http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ Thanks and best regards, Goetz. From vladimir.kozlov at oracle.com Thu Jul 25 16:37:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Jul 2013 16:37:49 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51F0BAF1.1090000@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> <51F0BAF1.1090000@oracle.com> Message-ID: <51F1B6CD.4040902@oracle.com> Hotspot JPRT testing passed. I will push these changes into stage repo when David's changes reach it. Thanks, Vladimir On 7/24/13 10:43 PM, Vladimir Kozlov wrote: > Thank you, Goetz, > > This looks good. > > David pushed makefile changes (8020799) in group's repo. I will try to > combine all these changes with staged sources and run JPRT test builds > tomorrow. > > Thanks, > Vladimir > > On 7/24/13 7:46 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I updated the webrev once more. >> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >> >> - I fixed encode_klass_not_null() >> - I cleaned up jni_ppc.h >> - added the guard in copy_ppc.hpp. >> >> Further there were problems on aix. >> I had to rename the condition code registers from CR0-7 to CCR0-7, >> as CR0-3 is defined in an AIX system header. >> >> David, can I mark the change as reviewed by you? >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 23. Juli 2013 09:59 >> To: Lindenmaier, Goetz >> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >> hotspot-dev at openjdk.java.net >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >> interpreter only VM. >> >> PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic >> copies for jlong are only correct on 64-bit. >> >> Is there other code in "bit-neutral" ppc files that is really only >> correct on 64-bit? >> >> David >> ----- >> >> On 23/07/2013 5:54 PM, David Holmes wrote: >>> On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >>>> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>>>> >>>>> I don't really care about the guard. Just tell me what to do... >>>> >>>> To be safe leave guards with PPC64 check instead of _lp64 as you >>>> suggested. >>> >>> Yes please do that. I think the guard is important as this is a >>> bit-neutral file. If/when someone creates a 32-bit PPC port we don't >>> want them to have to re-discover the atomicity bugs with jlong/jdouble >>> that were found on the existing platforms. >>> >>> Thanks, >>> David >>> >>>> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) >>>> ? : >>>> >>>> jniTypes_ppc.hpp: >>>> >>>> 48 #ifndef PPC64 >>>> 49 #error "ppc32 support currently not implemented!!!" >>>> 50 #endif // PPC64 >>>> >>>> Our reviews are based on assumption that this port only supports >>>> PPC64+LP64 combination. Is this correct assumption? >>>> >>>> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >>>> based macbook pro. But do we need it in this port? >>>> >>>> Regards, >>>> Vladimir >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Monday, July 22, 2013 6:48 PM >>>>> To: Lindenmaier, Goetz >>>>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>>>> hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>> interpreter only VM. >>>>> >>>>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>>>> ??? Or do you propose to change both of them to PPC64? >>>>>> Yes, sure, I want to change both. >>>>> >>>>> Why do we need this error if this code is only for PPC64 port? We will >>>>> have other compilation errors if we try to use >>>>> these sources for something else as we found already. Do you have an >>>>> other usage so you need this guard? >>>>> >>>>>>> All of the existing 64-bit ports have a direct correspondence >>>>>>> between >>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>> >>>>>> I know. And obviously there is a correspondence, as no one will >>>>>> Implement an LG64 memory model on a 32 bit machine. >>>>>> But the usage intermingles different memory model and architecture: >>>>>> >>>>>> E.g., the register declaration in register_x86_hpp is fine: >>>>>> >>>>>> #ifdef AMD64 >>>>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>>>> >>>>>> But I think this makes no sense (assembler_x86.hpp): >>>>>> >>>>>> #ifdef _LP64 >>>>>> void movsbq(Register dst, Address src); >>>>>> void movsbq(Register dst, Register src); >>>>>> // Move signed 32bit immediate to 64bit extending sign >>>>>> void movslq(Address dst, int32_t imm64); >>>>>> void movslq(Register dst, int32_t imm64); >>>>>> >>>>>> and should be guarded by AMD64. >>>>> >>>>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>>>> so using _LP64 works for us. Also using AMD64 >>>>> sometimes rise questions about Intel x64. So using _LP64 is more >>>>> neutral. >>>>> >>>>>> And I want to get the PPC port right in such matters. >>>>> >>>>> I agree with this since ppc is more flexible than x86, it seems. >>>>> >>>>>> I'm currently removing the ppc_ prefixes ... big fun:) >>>>> >>>>> Sorry about that. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>>> Best regards, >>>>>> >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Montag, 22. Juli 2013 13:38 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>>> hotspot-dev at openjdk.java.net >>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>> interpreter only VM. >>>>>> >>>>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>>>> >>>>>> > Hi David, >>>>>> >>>>>> > >>>>>> >>>>>> > PPC64: describes an instruction set / machine with all it's >>>>>> specialities. And the instruction set >>>>>> >>>>>> > we implemented the port for has an atomic 64-bit >>>>>> instruction. >>>>>> >>>>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>>>> , pointer == 64 bit. >>>>>> >>>>>> > In contraditction to ILP64 (int == 64bit) etc, which you >>>>>> could as >>>>>> well implement with the >>>>>> >>>>>> > PPC64 instruction set. You could also implement a system with >>>>>> ILP32 on PPC64, and then >>>>>> >>>>>> > you would have an atomic 64-bit instruction. >>>>>> >>>>>> That still doesn't explain why you think LP64 is okay for the atomic >>>>>> >>>>>> file but you want PPC64 for the orderAccess file. ??? Or do you >>>>>> propose >>>>>> >>>>>> to change both of them to PPC64? >>>>>> >>>>>> All of the existing 64-bit ports have a direct correspondence between >>>>>> >>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>> LP64 >>>>>> >>>>>> is the only 64-bit data model that the OpenJDK sources support. >>>>>> >>>>>> > Compressed oops make sense to protect with LP64, because they >>>>>> are >>>>>> only helpful >>>>>> >>>>>> > with 64 bit pointers. While usage of LP64 is not exactly >>>>>> correct >>>>>> here, ILP64, SLP64 >>>>>> >>>>>> > etc would also use compressed oops. But it's close enough I >>>>>> guess. >>>>>> >>>>>> I'm not concerned about compressed oops. No idea where that came from >>>>>> ;-) >>>>>> >>>>>> David >>>>>> >>>>>> ------ >>>>>> >>>>>> > Best regards, >>>>>> >>>>>> > Goetz. >>>>>> >>>>>> > >>>>>> >>>>>> > -----Original Message----- >>>>>> >>>>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> >>>>>> > Sent: Montag, 22. Juli 2013 05:27 >>>>>> >>>>>> > To: Lindenmaier, Goetz >>>>>> >>>>>> > Cc: hotspot-dev at openjdk.java.net >>>>>> ; >>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>> ; Vladimir Kozlov >>>>>> >>>>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>> for interpreter only VM. >>>>>> >>>>>> > >>>>>> >>>>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>> >> Hi David, >>>>>> >>>>>> >> >>>>>> >>>>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>> >>>>>> >>> 34 #ifndef _LP64 >>>>>> >>>>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>>>> >>>>>> >>> 36 #endif >>>>>> >>>>>> >> You're right, I'll fix this. >>>>>> >>>>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>>>> >>>>>> >> processor architecture and not the memory model. >>>>>> >>>>>> > >>>>>> >>>>>> > Is there some case where _LP64 would be true but PPC64 would not >>>>>> be ??? >>>>>> >>>>>> > They seem effectively interchangeable but I don't know why you >>>>>> would use >>>>>> >>>>>> > one in one file and the other in another file ?? >>>>>> >>>>>> > >>>>>> >>>>>> > Thanks, >>>>>> >>>>>> > David >>>>>> >>>>>> > >>>>>> >>>>>> >> If I will change the ppc_ prefixes that'll take a bit, >>>>>> especially >>>>>> >>>>>> >> as I will have to adapt all the alignments :(. >>>>>> >>>>>> >> But that does not matter, as we need to wait for your build >>>>>> >>>>>> >> change anyways. >>>>>> >>>>>> >> >>>>>> >>>>>> >> Best regards, >>>>>> >>>>>> >> Goetz. >>>>>> >>>>>> >> >>>>>> >>>>>> >> >>>>>> >>>>>> >> >>>>>> >>>>>> >> >>>>>> >>>>>> >> >>>>>> >>>>>> >> -----Original Message----- >>>>>> >>>>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> >>>>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>>>> >>>>>> >> To: Lindenmaier, Goetz >>>>>> >>>>>> >> Cc: hotspot-dev at openjdk.java.net >>>>>> ; >>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>> ; Vladimir Kozlov >>>>>> >>>>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>> for interpreter only VM. >>>>>> >>>>>> >> >>>>>> >>>>>> >> Hi Goetz, >>>>>> >>>>>> >> >>>>>> >>>>>> >> Only a brief glance through ... >>>>>> >>>>>> >> >>>>>> >>>>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>> >>>>>> >> >>>>>> >>>>>> >> 34 #ifndef _LP64 >>>>>> >>>>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>>>> >>>>>> >> 36 #endif >>>>>> >>>>>> >> >>>>>> >>>>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>>>> will only >>>>>> >>>>>> >> be atomic on ppc64). >>>>>> >>>>>> >> >>>>>> >>>>>> >> BTW typo: 35 #error "Atomic currently only impleneted for >>>>>> PPC64" >>>>>> >>>>>> >> >>>>>> >>>>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>>>> redundant. >>>>>> >>>>>> >> >>>>>> >>>>>> >> David >>>>>> >>>>>> >> ----- >>>>>> >>>>>> >> >>>>>> >>>>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>> >>> Hi, >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> This time with webrev. Sorry for the double mails. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> This change contains all the files in cpu/ppc and >>>>>> os_cpu/linux_ppc needed for >>>>>> >>>>>> >>> the PPC64 interpreter port on linux. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> With this change you can do a core build on ppc64 and run the >>>>>> VM interpreter only. >>>>>> >>>>>> >>> It executes simple programs as jvm98. >>>>>> >>>>>> >>> The change requires >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> * 8016697: Use stubs to implement safefetch >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> * 8020059: The flag introduced by 8014972 is not >>>>>> defined ... >>>>>> >>>>>> >>> which will arrive soon in the staging repository. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> I marked the change as XL as it contains a lot of code. >>>>>> Nevertheless the >>>>>> >>>>>> >>> code has no impact on the existing Oracle platforms. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> The change touches a single shared file, globals.hpp, >>>>>> removing a >>>>>> >>>>>> >>> special case introduced for the port. This is because we >>>>>> >>>>>> >>> integrated some changes earlier than originally intended. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> Please review the change. Does it need testing on Oracle >>>>>> side? >>>>>> >>>>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> Best regards, >>>>>> >>>>>> >>> Goetz. >>>>>> >>>>>> >>> >>>>>> From david.holmes at oracle.com Thu Jul 25 16:48:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jul 2013 09:48:37 +1000 Subject: RFR: 8021314 minimal1.make needs to force off components not supported by the minimal VM In-Reply-To: <51F13721.60306@oracle.com> References: <51F0CD7B.1020405@oracle.com> <51F13721.60306@oracle.com> Message-ID: <51F1B955.20406@oracle.com> On 26/07/2013 12:33 AM, BILL PITTORE wrote: > Not an official reviewer but I like it. Thanks Bill. Still need a Reviewer. David > bill > > On 7/25/2013 3:02 AM, David Holmes wrote: >> webrev: http://cr.openjdk.java.net/~dholmes/8021314/webrev/ >> >> A simple fix. Where we used ?= to only set an INCLUDE_* variable to >> false if not already set, we really want to set it to false >> regardless. You can still pass the variable as make arg to bypass this >> logic if you know what you are doing, but we don't want to other parts >> of the build to enable variables that the minimal VM doesn't support. >> >> Thanks, >> David >> > > From goetz.lindenmaier at sap.com Thu Jul 25 17:02:09 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 26 Jul 2013 00:02:09 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51F1B6CD.4040902@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> <51F0BAF1.1090000@oracle.com> <51F1B6CD.4040902@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF7FB2@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for testing! We soon need to apply this to 0009: diff -r 63458ae3c26f src/cpu/ppc/vm/frame_ppc.inline.hpp --- a/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:17:42 2013 +0200 +++ b/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:56:10 2013 +0200 @@ -224,8 +224,8 @@ return &tos[offset + 1]; // prepushed tos } -inline JavaCallWrapper* frame::entry_frame_call_wrapper() const { - return (JavaCallWrapper*)entry_frame_locals()->call_wrapper_address; +inline JavaCallWrapper** frame::entry_frame_call_wrapper_addr() const { + return (JavaCallWrapper**)&entry_frame_locals()->call_wrapper_address; } inline oop frame::saved_oop_result(RegisterMap* map) const { Probably the corresponding change will come with the build change. David, thanks for fixing the build. Best regards, Goetz. -----Original Message----- From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Friday, July 26, 2013 1:38 AM Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. Hotspot JPRT testing passed. I will push these changes into stage repo when David's changes reach it. Thanks, Vladimir On 7/24/13 10:43 PM, Vladimir Kozlov wrote: > Thank you, Goetz, > > This looks good. > > David pushed makefile changes (8020799) in group's repo. I will try to > combine all these changes with staged sources and run JPRT test builds > tomorrow. > > Thanks, > Vladimir > > On 7/24/13 7:46 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I updated the webrev once more. >> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >> >> - I fixed encode_klass_not_null() >> - I cleaned up jni_ppc.h >> - added the guard in copy_ppc.hpp. >> >> Further there were problems on aix. >> I had to rename the condition code registers from CR0-7 to CCR0-7, >> as CR0-3 is defined in an AIX system header. >> >> David, can I mark the change as reviewed by you? >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 23. Juli 2013 09:59 >> To: Lindenmaier, Goetz >> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >> hotspot-dev at openjdk.java.net >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >> interpreter only VM. >> >> PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic >> copies for jlong are only correct on 64-bit. >> >> Is there other code in "bit-neutral" ppc files that is really only >> correct on 64-bit? >> >> David >> ----- >> >> On 23/07/2013 5:54 PM, David Holmes wrote: >>> On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >>>> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>>>> >>>>> I don't really care about the guard. Just tell me what to do... >>>> >>>> To be safe leave guards with PPC64 check instead of _lp64 as you >>>> suggested. >>> >>> Yes please do that. I think the guard is important as this is a >>> bit-neutral file. If/when someone creates a 32-bit PPC port we don't >>> want them to have to re-discover the atomicity bugs with jlong/jdouble >>> that were found on the existing platforms. >>> >>> Thanks, >>> David >>> >>>> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) >>>> ? : >>>> >>>> jniTypes_ppc.hpp: >>>> >>>> 48 #ifndef PPC64 >>>> 49 #error "ppc32 support currently not implemented!!!" >>>> 50 #endif // PPC64 >>>> >>>> Our reviews are based on assumption that this port only supports >>>> PPC64+LP64 combination. Is this correct assumption? >>>> >>>> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >>>> based macbook pro. But do we need it in this port? >>>> >>>> Regards, >>>> Vladimir >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Monday, July 22, 2013 6:48 PM >>>>> To: Lindenmaier, Goetz >>>>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>>>> hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>> interpreter only VM. >>>>> >>>>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>>>> ??? Or do you propose to change both of them to PPC64? >>>>>> Yes, sure, I want to change both. >>>>> >>>>> Why do we need this error if this code is only for PPC64 port? We will >>>>> have other compilation errors if we try to use >>>>> these sources for something else as we found already. Do you have an >>>>> other usage so you need this guard? >>>>> >>>>>>> All of the existing 64-bit ports have a direct correspondence >>>>>>> between >>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>> >>>>>> I know. And obviously there is a correspondence, as no one will >>>>>> Implement an LG64 memory model on a 32 bit machine. >>>>>> But the usage intermingles different memory model and architecture: >>>>>> >>>>>> E.g., the register declaration in register_x86_hpp is fine: >>>>>> >>>>>> #ifdef AMD64 >>>>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>>>> >>>>>> But I think this makes no sense (assembler_x86.hpp): >>>>>> >>>>>> #ifdef _LP64 >>>>>> void movsbq(Register dst, Address src); >>>>>> void movsbq(Register dst, Register src); >>>>>> // Move signed 32bit immediate to 64bit extending sign >>>>>> void movslq(Address dst, int32_t imm64); >>>>>> void movslq(Register dst, int32_t imm64); >>>>>> >>>>>> and should be guarded by AMD64. >>>>> >>>>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>>>> so using _LP64 works for us. Also using AMD64 >>>>> sometimes rise questions about Intel x64. So using _LP64 is more >>>>> neutral. >>>>> >>>>>> And I want to get the PPC port right in such matters. >>>>> >>>>> I agree with this since ppc is more flexible than x86, it seems. >>>>> >>>>>> I'm currently removing the ppc_ prefixes ... big fun:) >>>>> >>>>> Sorry about that. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>>> Best regards, >>>>>> >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Montag, 22. Juli 2013 13:38 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>>> hotspot-dev at openjdk.java.net >>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>> interpreter only VM. >>>>>> >>>>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>>>> >>>>>> > Hi David, >>>>>> >>>>>> > >>>>>> >>>>>> > PPC64: describes an instruction set / machine with all it's >>>>>> specialities. And the instruction set >>>>>> >>>>>> > we implemented the port for has an atomic 64-bit >>>>>> instruction. >>>>>> >>>>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>>>> , pointer == 64 bit. >>>>>> >>>>>> > In contraditction to ILP64 (int == 64bit) etc, which you >>>>>> could as >>>>>> well implement with the >>>>>> >>>>>> > PPC64 instruction set. You could also implement a system with >>>>>> ILP32 on PPC64, and then >>>>>> >>>>>> > you would have an atomic 64-bit instruction. >>>>>> >>>>>> That still doesn't explain why you think LP64 is okay for the atomic >>>>>> >>>>>> file but you want PPC64 for the orderAccess file. ??? Or do you >>>>>> propose >>>>>> >>>>>> to change both of them to PPC64? >>>>>> >>>>>> All of the existing 64-bit ports have a direct correspondence between >>>>>> >>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>> LP64 >>>>>> >>>>>> is the only 64-bit data model that the OpenJDK sources support. >>>>>> >>>>>> > Compressed oops make sense to protect with LP64, because they >>>>>> are >>>>>> only helpful >>>>>> >>>>>> > with 64 bit pointers. While usage of LP64 is not exactly >>>>>> correct >>>>>> here, ILP64, SLP64 >>>>>> >>>>>> > etc would also use compressed oops. But it's close enough I >>>>>> guess. >>>>>> >>>>>> I'm not concerned about compressed oops. No idea where that came from >>>>>> ;-) >>>>>> >>>>>> David >>>>>> >>>>>> ------ >>>>>> >>>>>> > Best regards, >>>>>> >>>>>> > Goetz. >>>>>> >>>>>> > >>>>>> >>>>>> > -----Original Message----- >>>>>> >>>>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> >>>>>> > Sent: Montag, 22. Juli 2013 05:27 >>>>>> >>>>>> > To: Lindenmaier, Goetz >>>>>> >>>>>> > Cc: hotspot-dev at openjdk.java.net >>>>>> ; >>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>> ; Vladimir Kozlov >>>>>> >>>>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>> for interpreter only VM. >>>>>> >>>>>> > >>>>>> >>>>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>> >> Hi David, >>>>>> >>>>>> >> >>>>>> >>>>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>> >>>>>> >>> 34 #ifndef _LP64 >>>>>> >>>>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>>>> >>>>>> >>> 36 #endif >>>>>> >>>>>> >> You're right, I'll fix this. >>>>>> >>>>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>>>> >>>>>> >> processor architecture and not the memory model. >>>>>> >>>>>> > >>>>>> >>>>>> > Is there some case where _LP64 would be true but PPC64 would not >>>>>> be ??? >>>>>> >>>>>> > They seem effectively interchangeable but I don't know why you >>>>>> would use >>>>>> >>>>>> > one in one file and the other in another file ?? >>>>>> >>>>>> > >>>>>> >>>>>> > Thanks, >>>>>> >>>>>> > David >>>>>> >>>>>> > >>>>>> >>>>>> >> If I will change the ppc_ prefixes that'll take a bit, >>>>>> especially >>>>>> >>>>>> >> as I will have to adapt all the alignments :(. >>>>>> >>>>>> >> But that does not matter, as we need to wait for your build >>>>>> >>>>>> >> change anyways. >>>>>> >>>>>> >> >>>>>> >>>>>> >> Best regards, >>>>>> >>>>>> >> Goetz. >>>>>> >>>>>> >> >>>>>> >>>>>> >> >>>>>> >>>>>> >> >>>>>> >>>>>> >> >>>>>> >>>>>> >> >>>>>> >>>>>> >> -----Original Message----- >>>>>> >>>>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> >>>>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>>>> >>>>>> >> To: Lindenmaier, Goetz >>>>>> >>>>>> >> Cc: hotspot-dev at openjdk.java.net >>>>>> ; >>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>> ; Vladimir Kozlov >>>>>> >>>>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>> for interpreter only VM. >>>>>> >>>>>> >> >>>>>> >>>>>> >> Hi Goetz, >>>>>> >>>>>> >> >>>>>> >>>>>> >> Only a brief glance through ... >>>>>> >>>>>> >> >>>>>> >>>>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>> >>>>>> >> >>>>>> >>>>>> >> 34 #ifndef _LP64 >>>>>> >>>>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>>>> >>>>>> >> 36 #endif >>>>>> >>>>>> >> >>>>>> >>>>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>>>> will only >>>>>> >>>>>> >> be atomic on ppc64). >>>>>> >>>>>> >> >>>>>> >>>>>> >> BTW typo: 35 #error "Atomic currently only impleneted for >>>>>> PPC64" >>>>>> >>>>>> >> >>>>>> >>>>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>>>> redundant. >>>>>> >>>>>> >> >>>>>> >>>>>> >> David >>>>>> >>>>>> >> ----- >>>>>> >>>>>> >> >>>>>> >>>>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>> >>> Hi, >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> This time with webrev. Sorry for the double mails. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> This change contains all the files in cpu/ppc and >>>>>> os_cpu/linux_ppc needed for >>>>>> >>>>>> >>> the PPC64 interpreter port on linux. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> With this change you can do a core build on ppc64 and run the >>>>>> VM interpreter only. >>>>>> >>>>>> >>> It executes simple programs as jvm98. >>>>>> >>>>>> >>> The change requires >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> * 8016697: Use stubs to implement safefetch >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> * 8020059: The flag introduced by 8014972 is not >>>>>> defined ... >>>>>> >>>>>> >>> which will arrive soon in the staging repository. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> I marked the change as XL as it contains a lot of code. >>>>>> Nevertheless the >>>>>> >>>>>> >>> code has no impact on the existing Oracle platforms. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> The change touches a single shared file, globals.hpp, >>>>>> removing a >>>>>> >>>>>> >>> special case introduced for the port. This is because we >>>>>> >>>>>> >>> integrated some changes earlier than originally intended. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> Please review the change. Does it need testing on Oracle >>>>>> side? >>>>>> >>>>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> Best regards, >>>>>> >>>>>> >>> Goetz. >>>>>> >>>>>> >>> >>>>>> From vladimir.kozlov at oracle.com Thu Jul 25 17:12:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Jul 2013 17:12:48 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF7FB2@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> <51F0BAF1.1090000@oracle.com> <51F1B6CD.4040902@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF7FB2@DEWDFEMB12A.global.corp.sap> Message-ID: <51F1BF00.4070709@oracle.com> Hi Goetz, On 7/25/13 5:02 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for testing! > We soon need to apply this to 0009: What do you mean "soon"? Do you ask me to fix it in your latest ppcfiles-3-hotspot.changeset before pushing? Or it will be separate changeset? thanks, Vladimir > > diff -r 63458ae3c26f src/cpu/ppc/vm/frame_ppc.inline.hpp > --- a/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:17:42 2013 +0200 > +++ b/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:56:10 2013 +0200 > @@ -224,8 +224,8 @@ > return &tos[offset + 1]; // prepushed tos > } > > -inline JavaCallWrapper* frame::entry_frame_call_wrapper() const { > - return (JavaCallWrapper*)entry_frame_locals()->call_wrapper_address; > +inline JavaCallWrapper** frame::entry_frame_call_wrapper_addr() const { > + return (JavaCallWrapper**)&entry_frame_locals()->call_wrapper_address; > } > > inline oop frame::saved_oop_result(RegisterMap* map) const { > > Probably the corresponding change will come with the build change. > > David, thanks for fixing the build. > > Best regards, > Goetz. > > > -----Original Message----- > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Friday, July 26, 2013 1:38 AM > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > Hotspot JPRT testing passed. > > I will push these changes into stage repo when David's changes reach it. > > Thanks, > Vladimir > > On 7/24/13 10:43 PM, Vladimir Kozlov wrote: >> Thank you, Goetz, >> >> This looks good. >> >> David pushed makefile changes (8020799) in group's repo. I will try to >> combine all these changes with staged sources and run JPRT test builds >> tomorrow. >> >> Thanks, >> Vladimir >> >> On 7/24/13 7:46 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I updated the webrev once more. >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>> >>> - I fixed encode_klass_not_null() >>> - I cleaned up jni_ppc.h >>> - added the guard in copy_ppc.hpp. >>> >>> Further there were problems on aix. >>> I had to rename the condition code registers from CR0-7 to CCR0-7, >>> as CR0-3 is defined in an AIX system header. >>> >>> David, can I mark the change as reviewed by you? >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 23. Juli 2013 09:59 >>> To: Lindenmaier, Goetz >>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic >>> copies for jlong are only correct on 64-bit. >>> >>> Is there other code in "bit-neutral" ppc files that is really only >>> correct on 64-bit? >>> >>> David >>> ----- >>> >>> On 23/07/2013 5:54 PM, David Holmes wrote: >>>> On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >>>>> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>> I don't really care about the guard. Just tell me what to do... >>>>> >>>>> To be safe leave guards with PPC64 check instead of _lp64 as you >>>>> suggested. >>>> >>>> Yes please do that. I think the guard is important as this is a >>>> bit-neutral file. If/when someone creates a 32-bit PPC port we don't >>>> want them to have to re-discover the atomicity bugs with jlong/jdouble >>>> that were found on the existing platforms. >>>> >>>> Thanks, >>>> David >>>> >>>>> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) >>>>> ? : >>>>> >>>>> jniTypes_ppc.hpp: >>>>> >>>>> 48 #ifndef PPC64 >>>>> 49 #error "ppc32 support currently not implemented!!!" >>>>> 50 #endif // PPC64 >>>>> >>>>> Our reviews are based on assumption that this port only supports >>>>> PPC64+LP64 combination. Is this correct assumption? >>>>> >>>>> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >>>>> based macbook pro. But do we need it in this port? >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Monday, July 22, 2013 6:48 PM >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>>>>> hotspot-dev at openjdk.java.net >>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>> interpreter only VM. >>>>>> >>>>>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>>>>> ??? Or do you propose to change both of them to PPC64? >>>>>>> Yes, sure, I want to change both. >>>>>> >>>>>> Why do we need this error if this code is only for PPC64 port? We will >>>>>> have other compilation errors if we try to use >>>>>> these sources for something else as we found already. Do you have an >>>>>> other usage so you need this guard? >>>>>> >>>>>>>> All of the existing 64-bit ports have a direct correspondence >>>>>>>> between >>>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>>> >>>>>>> I know. And obviously there is a correspondence, as no one will >>>>>>> Implement an LG64 memory model on a 32 bit machine. >>>>>>> But the usage intermingles different memory model and architecture: >>>>>>> >>>>>>> E.g., the register declaration in register_x86_hpp is fine: >>>>>>> >>>>>>> #ifdef AMD64 >>>>>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>>>>> >>>>>>> But I think this makes no sense (assembler_x86.hpp): >>>>>>> >>>>>>> #ifdef _LP64 >>>>>>> void movsbq(Register dst, Address src); >>>>>>> void movsbq(Register dst, Register src); >>>>>>> // Move signed 32bit immediate to 64bit extending sign >>>>>>> void movslq(Address dst, int32_t imm64); >>>>>>> void movslq(Register dst, int32_t imm64); >>>>>>> >>>>>>> and should be guarded by AMD64. >>>>>> >>>>>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>>>>> so using _LP64 works for us. Also using AMD64 >>>>>> sometimes rise questions about Intel x64. So using _LP64 is more >>>>>> neutral. >>>>>> >>>>>>> And I want to get the PPC port right in such matters. >>>>>> >>>>>> I agree with this since ppc is more flexible than x86, it seems. >>>>>> >>>>>>> I'm currently removing the ppc_ prefixes ... big fun:) >>>>>> >>>>>> Sorry about that. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Montag, 22. Juli 2013 13:38 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>>>> hotspot-dev at openjdk.java.net >>>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>>> interpreter only VM. >>>>>>> >>>>>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>> > Hi David, >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > PPC64: describes an instruction set / machine with all it's >>>>>>> specialities. And the instruction set >>>>>>> >>>>>>> > we implemented the port for has an atomic 64-bit >>>>>>> instruction. >>>>>>> >>>>>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>>>>> , pointer == 64 bit. >>>>>>> >>>>>>> > In contraditction to ILP64 (int == 64bit) etc, which you >>>>>>> could as >>>>>>> well implement with the >>>>>>> >>>>>>> > PPC64 instruction set. You could also implement a system with >>>>>>> ILP32 on PPC64, and then >>>>>>> >>>>>>> > you would have an atomic 64-bit instruction. >>>>>>> >>>>>>> That still doesn't explain why you think LP64 is okay for the atomic >>>>>>> >>>>>>> file but you want PPC64 for the orderAccess file. ??? Or do you >>>>>>> propose >>>>>>> >>>>>>> to change both of them to PPC64? >>>>>>> >>>>>>> All of the existing 64-bit ports have a direct correspondence between >>>>>>> >>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>>> LP64 >>>>>>> >>>>>>> is the only 64-bit data model that the OpenJDK sources support. >>>>>>> >>>>>>> > Compressed oops make sense to protect with LP64, because they >>>>>>> are >>>>>>> only helpful >>>>>>> >>>>>>> > with 64 bit pointers. While usage of LP64 is not exactly >>>>>>> correct >>>>>>> here, ILP64, SLP64 >>>>>>> >>>>>>> > etc would also use compressed oops. But it's close enough I >>>>>>> guess. >>>>>>> >>>>>>> I'm not concerned about compressed oops. No idea where that came from >>>>>>> ;-) >>>>>>> >>>>>>> David >>>>>>> >>>>>>> ------ >>>>>>> >>>>>>> > Best regards, >>>>>>> >>>>>>> > Goetz. >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > -----Original Message----- >>>>>>> >>>>>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> >>>>>>> > Sent: Montag, 22. Juli 2013 05:27 >>>>>>> >>>>>>> > To: Lindenmaier, Goetz >>>>>>> >>>>>>> > Cc: hotspot-dev at openjdk.java.net >>>>>>> ; >>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>> ; Vladimir Kozlov >>>>>>> >>>>>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>>> for interpreter only VM. >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>> >> Hi David, >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>>> >>>>>>> >>> 34 #ifndef _LP64 >>>>>>> >>>>>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>>>>> >>>>>>> >>> 36 #endif >>>>>>> >>>>>>> >> You're right, I'll fix this. >>>>>>> >>>>>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>>>>> >>>>>>> >> processor architecture and not the memory model. >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > Is there some case where _LP64 would be true but PPC64 would not >>>>>>> be ??? >>>>>>> >>>>>>> > They seem effectively interchangeable but I don't know why you >>>>>>> would use >>>>>>> >>>>>>> > one in one file and the other in another file ?? >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > Thanks, >>>>>>> >>>>>>> > David >>>>>>> >>>>>>> > >>>>>>> >>>>>>> >> If I will change the ppc_ prefixes that'll take a bit, >>>>>>> especially >>>>>>> >>>>>>> >> as I will have to adapt all the alignments :(. >>>>>>> >>>>>>> >> But that does not matter, as we need to wait for your build >>>>>>> >>>>>>> >> change anyways. >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> Best regards, >>>>>>> >>>>>>> >> Goetz. >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> -----Original Message----- >>>>>>> >>>>>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> >>>>>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>>>>> >>>>>>> >> To: Lindenmaier, Goetz >>>>>>> >>>>>>> >> Cc: hotspot-dev at openjdk.java.net >>>>>>> ; >>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>> ; Vladimir Kozlov >>>>>>> >>>>>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>>> for interpreter only VM. >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> Hi Goetz, >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> Only a brief glance through ... >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> 34 #ifndef _LP64 >>>>>>> >>>>>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>>>>> >>>>>>> >> 36 #endif >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>>>>> will only >>>>>>> >>>>>>> >> be atomic on ppc64). >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> BTW typo: 35 #error "Atomic currently only impleneted for >>>>>>> PPC64" >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>>>>> redundant. >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> David >>>>>>> >>>>>>> >> ----- >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>> >>> Hi, >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> This time with webrev. Sorry for the double mails. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> This change contains all the files in cpu/ppc and >>>>>>> os_cpu/linux_ppc needed for >>>>>>> >>>>>>> >>> the PPC64 interpreter port on linux. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> With this change you can do a core build on ppc64 and run the >>>>>>> VM interpreter only. >>>>>>> >>>>>>> >>> It executes simple programs as jvm98. >>>>>>> >>>>>>> >>> The change requires >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> * 8016697: Use stubs to implement safefetch >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> * 8020059: The flag introduced by 8014972 is not >>>>>>> defined ... >>>>>>> >>>>>>> >>> which will arrive soon in the staging repository. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> I marked the change as XL as it contains a lot of code. >>>>>>> Nevertheless the >>>>>>> >>>>>>> >>> code has no impact on the existing Oracle platforms. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> The change touches a single shared file, globals.hpp, >>>>>>> removing a >>>>>>> >>>>>>> >>> special case introduced for the port. This is because we >>>>>>> >>>>>>> >>> integrated some changes earlier than originally intended. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> Please review the change. Does it need testing on Oracle >>>>>>> side? >>>>>>> >>>>>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> Best regards, >>>>>>> >>>>>>> >>> Goetz. >>>>>>> >>>>>>> >>> >>>>>>> From serguei.spitsyn at oracle.com Thu Jul 25 17:14:38 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Jul 2013 17:14:38 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments Message-ID: <51F1BF6E.1080801@oracle.com> Please, review the fix for: bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 Summary: Restore the appendix argument of a polymorphic intrinsic call needed for a invokestatic re-execution after JVMTI PopFrame(). Description When JVMTI's PopFrame removes a frame that was called via a call site that takes an appendix and that call site is reexecuted the appendix is not on the stack anymore because it got removed by the adapter. This fix is to detect such a case and push the appendix on the stack again before reexecution. Testing: UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, nsk.jdi.testlist Thanks, Serguei From coleen.phillimore at oracle.com Thu Jul 25 17:16:12 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 25 Jul 2013 20:16:12 -0400 Subject: RFR: 8021314 minimal1.make needs to force off components not supported by the minimal VM In-Reply-To: <51F1B955.20406@oracle.com> References: <51F0CD7B.1020405@oracle.com> <51F13721.60306@oracle.com> <51F1B955.20406@oracle.com> Message-ID: <51F1BFCC.3060305@oracle.com> Looks good to me. Coleen On 7/25/2013 7:48 PM, David Holmes wrote: > On 26/07/2013 12:33 AM, BILL PITTORE wrote: >> Not an official reviewer but I like it. > > Thanks Bill. > > Still need a Reviewer. > > David > >> bill >> >> On 7/25/2013 3:02 AM, David Holmes wrote: >>> webrev: http://cr.openjdk.java.net/~dholmes/8021314/webrev/ >>> >>> A simple fix. Where we used ?= to only set an INCLUDE_* variable to >>> false if not already set, we really want to set it to false >>> regardless. You can still pass the variable as make arg to bypass this >>> logic if you know what you are doing, but we don't want to other parts >>> of the build to enable variables that the minimal VM doesn't support. >>> >>> Thanks, >>> David >>> >> >> From jiangli.zhou at oracle.com Thu Jul 25 18:35:04 2013 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Fri, 26 Jul 2013 01:35:04 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20130726013511.01833483BB@hg.openjdk.java.net> Changeset: 01aa164323fa Author: dholmes Date: 2013-07-24 19:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/01aa164323fa 8020799: Allow customization of hotspot source directories and files Reviewed-by: kvn, dlong ! make/linux/makefiles/vm.make Changeset: a4b9a8ec8f4a Author: jiangli Date: 2013-07-25 18:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a4b9a8ec8f4a Merge From goetz.lindenmaier at sap.com Thu Jul 25 23:16:42 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 26 Jul 2013 06:16:42 +0000 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51F1BF00.4070709@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> <51F0BAF1.1090000@oracle.com> <51F1B6CD.4040902@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF7FB2@DEWDFEMB12A.global.corp.sap> <51F1BF00.4070709@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFF803B@DEWDFEMB12A.global.corp.sap> Hi Vladimir, the change will be necessary once 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' arrives in the stage repository. So I'd like to test 0009 once more before you push it, and adapt it accordingly. This should not invalidate your tests, as it's in a ppc file. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Freitag, 26. Juli 2013 02:13 To: Lindenmaier, Goetz Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. Hi Goetz, On 7/25/13 5:02 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for testing! > We soon need to apply this to 0009: What do you mean "soon"? Do you ask me to fix it in your latest ppcfiles-3-hotspot.changeset before pushing? Or it will be separate changeset? thanks, Vladimir > > diff -r 63458ae3c26f src/cpu/ppc/vm/frame_ppc.inline.hpp > --- a/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:17:42 2013 +0200 > +++ b/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:56:10 2013 +0200 > @@ -224,8 +224,8 @@ > return &tos[offset + 1]; // prepushed tos > } > > -inline JavaCallWrapper* frame::entry_frame_call_wrapper() const { > - return (JavaCallWrapper*)entry_frame_locals()->call_wrapper_address; > +inline JavaCallWrapper** frame::entry_frame_call_wrapper_addr() const { > + return (JavaCallWrapper**)&entry_frame_locals()->call_wrapper_address; > } > > inline oop frame::saved_oop_result(RegisterMap* map) const { > > Probably the corresponding change will come with the build change. > > David, thanks for fixing the build. > > Best regards, > Goetz. > > > -----Original Message----- > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Friday, July 26, 2013 1:38 AM > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > Hotspot JPRT testing passed. > > I will push these changes into stage repo when David's changes reach it. > > Thanks, > Vladimir > > On 7/24/13 10:43 PM, Vladimir Kozlov wrote: >> Thank you, Goetz, >> >> This looks good. >> >> David pushed makefile changes (8020799) in group's repo. I will try to >> combine all these changes with staged sources and run JPRT test builds >> tomorrow. >> >> Thanks, >> Vladimir >> >> On 7/24/13 7:46 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I updated the webrev once more. >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>> >>> - I fixed encode_klass_not_null() >>> - I cleaned up jni_ppc.h >>> - added the guard in copy_ppc.hpp. >>> >>> Further there were problems on aix. >>> I had to rename the condition code registers from CR0-7 to CCR0-7, >>> as CR0-3 is defined in an AIX system header. >>> >>> David, can I mark the change as reviewed by you? >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 23. Juli 2013 09:59 >>> To: Lindenmaier, Goetz >>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic >>> copies for jlong are only correct on 64-bit. >>> >>> Is there other code in "bit-neutral" ppc files that is really only >>> correct on 64-bit? >>> >>> David >>> ----- >>> >>> On 23/07/2013 5:54 PM, David Holmes wrote: >>>> On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >>>>> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>> I don't really care about the guard. Just tell me what to do... >>>>> >>>>> To be safe leave guards with PPC64 check instead of _lp64 as you >>>>> suggested. >>>> >>>> Yes please do that. I think the guard is important as this is a >>>> bit-neutral file. If/when someone creates a 32-bit PPC port we don't >>>> want them to have to re-discover the atomicity bugs with jlong/jdouble >>>> that were found on the existing platforms. >>>> >>>> Thanks, >>>> David >>>> >>>>> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) >>>>> ? : >>>>> >>>>> jniTypes_ppc.hpp: >>>>> >>>>> 48 #ifndef PPC64 >>>>> 49 #error "ppc32 support currently not implemented!!!" >>>>> 50 #endif // PPC64 >>>>> >>>>> Our reviews are based on assumption that this port only supports >>>>> PPC64+LP64 combination. Is this correct assumption? >>>>> >>>>> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >>>>> based macbook pro. But do we need it in this port? >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Monday, July 22, 2013 6:48 PM >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>>>>> hotspot-dev at openjdk.java.net >>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>> interpreter only VM. >>>>>> >>>>>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>>>>> ??? Or do you propose to change both of them to PPC64? >>>>>>> Yes, sure, I want to change both. >>>>>> >>>>>> Why do we need this error if this code is only for PPC64 port? We will >>>>>> have other compilation errors if we try to use >>>>>> these sources for something else as we found already. Do you have an >>>>>> other usage so you need this guard? >>>>>> >>>>>>>> All of the existing 64-bit ports have a direct correspondence >>>>>>>> between >>>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>>> >>>>>>> I know. And obviously there is a correspondence, as no one will >>>>>>> Implement an LG64 memory model on a 32 bit machine. >>>>>>> But the usage intermingles different memory model and architecture: >>>>>>> >>>>>>> E.g., the register declaration in register_x86_hpp is fine: >>>>>>> >>>>>>> #ifdef AMD64 >>>>>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>>>>> >>>>>>> But I think this makes no sense (assembler_x86.hpp): >>>>>>> >>>>>>> #ifdef _LP64 >>>>>>> void movsbq(Register dst, Address src); >>>>>>> void movsbq(Register dst, Register src); >>>>>>> // Move signed 32bit immediate to 64bit extending sign >>>>>>> void movslq(Address dst, int32_t imm64); >>>>>>> void movslq(Register dst, int32_t imm64); >>>>>>> >>>>>>> and should be guarded by AMD64. >>>>>> >>>>>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>>>>> so using _LP64 works for us. Also using AMD64 >>>>>> sometimes rise questions about Intel x64. So using _LP64 is more >>>>>> neutral. >>>>>> >>>>>>> And I want to get the PPC port right in such matters. >>>>>> >>>>>> I agree with this since ppc is more flexible than x86, it seems. >>>>>> >>>>>>> I'm currently removing the ppc_ prefixes ... big fun:) >>>>>> >>>>>> Sorry about that. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Montag, 22. Juli 2013 13:38 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>>>> hotspot-dev at openjdk.java.net >>>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>>> interpreter only VM. >>>>>>> >>>>>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>> > Hi David, >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > PPC64: describes an instruction set / machine with all it's >>>>>>> specialities. And the instruction set >>>>>>> >>>>>>> > we implemented the port for has an atomic 64-bit >>>>>>> instruction. >>>>>>> >>>>>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>>>>> , pointer == 64 bit. >>>>>>> >>>>>>> > In contraditction to ILP64 (int == 64bit) etc, which you >>>>>>> could as >>>>>>> well implement with the >>>>>>> >>>>>>> > PPC64 instruction set. You could also implement a system with >>>>>>> ILP32 on PPC64, and then >>>>>>> >>>>>>> > you would have an atomic 64-bit instruction. >>>>>>> >>>>>>> That still doesn't explain why you think LP64 is okay for the atomic >>>>>>> >>>>>>> file but you want PPC64 for the orderAccess file. ??? Or do you >>>>>>> propose >>>>>>> >>>>>>> to change both of them to PPC64? >>>>>>> >>>>>>> All of the existing 64-bit ports have a direct correspondence between >>>>>>> >>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>>> LP64 >>>>>>> >>>>>>> is the only 64-bit data model that the OpenJDK sources support. >>>>>>> >>>>>>> > Compressed oops make sense to protect with LP64, because they >>>>>>> are >>>>>>> only helpful >>>>>>> >>>>>>> > with 64 bit pointers. While usage of LP64 is not exactly >>>>>>> correct >>>>>>> here, ILP64, SLP64 >>>>>>> >>>>>>> > etc would also use compressed oops. But it's close enough I >>>>>>> guess. >>>>>>> >>>>>>> I'm not concerned about compressed oops. No idea where that came from >>>>>>> ;-) >>>>>>> >>>>>>> David >>>>>>> >>>>>>> ------ >>>>>>> >>>>>>> > Best regards, >>>>>>> >>>>>>> > Goetz. >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > -----Original Message----- >>>>>>> >>>>>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> >>>>>>> > Sent: Montag, 22. Juli 2013 05:27 >>>>>>> >>>>>>> > To: Lindenmaier, Goetz >>>>>>> >>>>>>> > Cc: hotspot-dev at openjdk.java.net >>>>>>> ; >>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>> ; Vladimir Kozlov >>>>>>> >>>>>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>>> for interpreter only VM. >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>> >> Hi David, >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>>> >>>>>>> >>> 34 #ifndef _LP64 >>>>>>> >>>>>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>>>>> >>>>>>> >>> 36 #endif >>>>>>> >>>>>>> >> You're right, I'll fix this. >>>>>>> >>>>>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>>>>> >>>>>>> >> processor architecture and not the memory model. >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > Is there some case where _LP64 would be true but PPC64 would not >>>>>>> be ??? >>>>>>> >>>>>>> > They seem effectively interchangeable but I don't know why you >>>>>>> would use >>>>>>> >>>>>>> > one in one file and the other in another file ?? >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > Thanks, >>>>>>> >>>>>>> > David >>>>>>> >>>>>>> > >>>>>>> >>>>>>> >> If I will change the ppc_ prefixes that'll take a bit, >>>>>>> especially >>>>>>> >>>>>>> >> as I will have to adapt all the alignments :(. >>>>>>> >>>>>>> >> But that does not matter, as we need to wait for your build >>>>>>> >>>>>>> >> change anyways. >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> Best regards, >>>>>>> >>>>>>> >> Goetz. >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> -----Original Message----- >>>>>>> >>>>>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> >>>>>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>>>>> >>>>>>> >> To: Lindenmaier, Goetz >>>>>>> >>>>>>> >> Cc: hotspot-dev at openjdk.java.net >>>>>>> ; >>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>> ; Vladimir Kozlov >>>>>>> >>>>>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>>> for interpreter only VM. >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> Hi Goetz, >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> Only a brief glance through ... >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> 34 #ifndef _LP64 >>>>>>> >>>>>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>>>>> >>>>>>> >> 36 #endif >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>>>>> will only >>>>>>> >>>>>>> >> be atomic on ppc64). >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> BTW typo: 35 #error "Atomic currently only impleneted for >>>>>>> PPC64" >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>>>>> redundant. >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> David >>>>>>> >>>>>>> >> ----- >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>> >>> Hi, >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> This time with webrev. Sorry for the double mails. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> This change contains all the files in cpu/ppc and >>>>>>> os_cpu/linux_ppc needed for >>>>>>> >>>>>>> >>> the PPC64 interpreter port on linux. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> With this change you can do a core build on ppc64 and run the >>>>>>> VM interpreter only. >>>>>>> >>>>>>> >>> It executes simple programs as jvm98. >>>>>>> >>>>>>> >>> The change requires >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> * 8016697: Use stubs to implement safefetch >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> * 8020059: The flag introduced by 8014972 is not >>>>>>> defined ... >>>>>>> >>>>>>> >>> which will arrive soon in the staging repository. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> I marked the change as XL as it contains a lot of code. >>>>>>> Nevertheless the >>>>>>> >>>>>>> >>> code has no impact on the existing Oracle platforms. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> The change touches a single shared file, globals.hpp, >>>>>>> removing a >>>>>>> >>>>>>> >>> special case introduced for the port. This is because we >>>>>>> >>>>>>> >>> integrated some changes earlier than originally intended. >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> Please review the change. Does it need testing on Oracle >>>>>>> side? >>>>>>> >>>>>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>> Best regards, >>>>>>> >>>>>>> >>> Goetz. >>>>>>> >>>>>>> >>> >>>>>>> From vladimir.kozlov at oracle.com Thu Jul 25 23:57:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Jul 2013 23:57:08 -0700 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF803B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> <51F0BAF1.1090000@oracle.com> <51F1B6CD.4040902@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF7FB2@DEWDFEMB12A.global.corp.sap> <51F1BF00.4070709@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF803B@DEWDFEMB12A.global.corp.sap> Message-ID: <51F21DC4.9050203@oracle.com> Thank you for explanation. I assume you will prepare a new 8019972 patch when 8016131 is pushed into stage repo (should be next week (crossing fingers)). And I want to push this 8019972 changes using JPRT. Regards, Vladimir On 7/25/13 11:16 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > the change will be necessary once > 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' > arrives in the stage repository. So I'd like to test 0009 once more before you > push it, and adapt it accordingly. > This should not invalidate your tests, as it's in a ppc file. > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Freitag, 26. Juli 2013 02:13 > To: Lindenmaier, Goetz > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. > > Hi Goetz, > > On 7/25/13 5:02 PM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> thanks for testing! >> We soon need to apply this to 0009: > > What do you mean "soon"? > > Do you ask me to fix it in your latest ppcfiles-3-hotspot.changeset > before pushing? Or it will be separate changeset? > > thanks, > Vladimir > >> >> diff -r 63458ae3c26f src/cpu/ppc/vm/frame_ppc.inline.hpp >> --- a/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:17:42 2013 +0200 >> +++ b/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:56:10 2013 +0200 >> @@ -224,8 +224,8 @@ >> return &tos[offset + 1]; // prepushed tos >> } >> >> -inline JavaCallWrapper* frame::entry_frame_call_wrapper() const { >> - return (JavaCallWrapper*)entry_frame_locals()->call_wrapper_address; >> +inline JavaCallWrapper** frame::entry_frame_call_wrapper_addr() const { >> + return (JavaCallWrapper**)&entry_frame_locals()->call_wrapper_address; >> } >> >> inline oop frame::saved_oop_result(RegisterMap* map) const { >> >> Probably the corresponding change will come with the build change. >> >> David, thanks for fixing the build. >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Friday, July 26, 2013 1:38 AM >> Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. >> >> Hotspot JPRT testing passed. >> >> I will push these changes into stage repo when David's changes reach it. >> >> Thanks, >> Vladimir >> >> On 7/24/13 10:43 PM, Vladimir Kozlov wrote: >>> Thank you, Goetz, >>> >>> This looks good. >>> >>> David pushed makefile changes (8020799) in group's repo. I will try to >>> combine all these changes with staged sources and run JPRT test builds >>> tomorrow. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/24/13 7:46 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I updated the webrev once more. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>> >>>> - I fixed encode_klass_not_null() >>>> - I cleaned up jni_ppc.h >>>> - added the guard in copy_ppc.hpp. >>>> >>>> Further there were problems on aix. >>>> I had to rename the condition code registers from CR0-7 to CCR0-7, >>>> as CR0-3 is defined in an AIX system header. >>>> >>>> David, can I mark the change as reviewed by you? >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 23. Juli 2013 09:59 >>>> To: Lindenmaier, Goetz >>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>> interpreter only VM. >>>> >>>> PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic >>>> copies for jlong are only correct on 64-bit. >>>> >>>> Is there other code in "bit-neutral" ppc files that is really only >>>> correct on 64-bit? >>>> >>>> David >>>> ----- >>>> >>>> On 23/07/2013 5:54 PM, David Holmes wrote: >>>>> On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >>>>>> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>> I don't really care about the guard. Just tell me what to do... >>>>>> >>>>>> To be safe leave guards with PPC64 check instead of _lp64 as you >>>>>> suggested. >>>>> >>>>> Yes please do that. I think the guard is important as this is a >>>>> bit-neutral file. If/when someone creates a 32-bit PPC port we don't >>>>> want them to have to re-discover the atomicity bugs with jlong/jdouble >>>>> that were found on the existing platforms. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) >>>>>> ? : >>>>>> >>>>>> jniTypes_ppc.hpp: >>>>>> >>>>>> 48 #ifndef PPC64 >>>>>> 49 #error "ppc32 support currently not implemented!!!" >>>>>> 50 #endif // PPC64 >>>>>> >>>>>> Our reviews are based on assumption that this port only supports >>>>>> PPC64+LP64 combination. Is this correct assumption? >>>>>> >>>>>> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc >>>>>> based macbook pro. But do we need it in this port? >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>>> Sent: Monday, July 22, 2013 6:48 PM >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>>>>>> hotspot-dev at openjdk.java.net >>>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>>> interpreter only VM. >>>>>>> >>>>>>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>>>>>> ??? Or do you propose to change both of them to PPC64? >>>>>>>> Yes, sure, I want to change both. >>>>>>> >>>>>>> Why do we need this error if this code is only for PPC64 port? We will >>>>>>> have other compilation errors if we try to use >>>>>>> these sources for something else as we found already. Do you have an >>>>>>> other usage so you need this guard? >>>>>>> >>>>>>>>> All of the existing 64-bit ports have a direct correspondence >>>>>>>>> between >>>>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>>>> >>>>>>>> I know. And obviously there is a correspondence, as no one will >>>>>>>> Implement an LG64 memory model on a 32 bit machine. >>>>>>>> But the usage intermingles different memory model and architecture: >>>>>>>> >>>>>>>> E.g., the register declaration in register_x86_hpp is fine: >>>>>>>> >>>>>>>> #ifdef AMD64 >>>>>>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>>>>>> >>>>>>>> But I think this makes no sense (assembler_x86.hpp): >>>>>>>> >>>>>>>> #ifdef _LP64 >>>>>>>> void movsbq(Register dst, Address src); >>>>>>>> void movsbq(Register dst, Register src); >>>>>>>> // Move signed 32bit immediate to 64bit extending sign >>>>>>>> void movslq(Address dst, int32_t imm64); >>>>>>>> void movslq(Register dst, int32_t imm64); >>>>>>>> >>>>>>>> and should be guarded by AMD64. >>>>>>> >>>>>>> Strictly speaking you are right. But we will never do ilp32 for AMD64 >>>>>>> so using _LP64 works for us. Also using AMD64 >>>>>>> sometimes rise questions about Intel x64. So using _LP64 is more >>>>>>> neutral. >>>>>>> >>>>>>>> And I want to get the PPC port right in such matters. >>>>>>> >>>>>>> I agree with this since ppc is more flexible than x86, it seems. >>>>>>> >>>>>>>> I'm currently removing the ppc_ prefixes ... big fun:) >>>>>>> >>>>>>> Sorry about that. >>>>>>> >>>>>>> Regards, >>>>>>> Vladimir >>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Goetz. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Montag, 22. Juli 2013 13:38 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>>>>> hotspot-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>>>> interpreter only VM. >>>>>>>> >>>>>>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>>>>>> >>>>>>>> > Hi David, >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> > PPC64: describes an instruction set / machine with all it's >>>>>>>> specialities. And the instruction set >>>>>>>> >>>>>>>> > we implemented the port for has an atomic 64-bit >>>>>>>> instruction. >>>>>>>> >>>>>>>> > LP64 describes a memory model. I.E, long == 64bit, int == 32bit >>>>>>>> , pointer == 64 bit. >>>>>>>> >>>>>>>> > In contraditction to ILP64 (int == 64bit) etc, which you >>>>>>>> could as >>>>>>>> well implement with the >>>>>>>> >>>>>>>> > PPC64 instruction set. You could also implement a system with >>>>>>>> ILP32 on PPC64, and then >>>>>>>> >>>>>>>> > you would have an atomic 64-bit instruction. >>>>>>>> >>>>>>>> That still doesn't explain why you think LP64 is okay for the atomic >>>>>>>> >>>>>>>> file but you want PPC64 for the orderAccess file. ??? Or do you >>>>>>>> propose >>>>>>>> >>>>>>>> to change both of them to PPC64? >>>>>>>> >>>>>>>> All of the existing 64-bit ports have a direct correspondence between >>>>>>>> >>>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>>>> LP64 >>>>>>>> >>>>>>>> is the only 64-bit data model that the OpenJDK sources support. >>>>>>>> >>>>>>>> > Compressed oops make sense to protect with LP64, because they >>>>>>>> are >>>>>>>> only helpful >>>>>>>> >>>>>>>> > with 64 bit pointers. While usage of LP64 is not exactly >>>>>>>> correct >>>>>>>> here, ILP64, SLP64 >>>>>>>> >>>>>>>> > etc would also use compressed oops. But it's close enough I >>>>>>>> guess. >>>>>>>> >>>>>>>> I'm not concerned about compressed oops. No idea where that came from >>>>>>>> ;-) >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> ------ >>>>>>>> >>>>>>>> > Best regards, >>>>>>>> >>>>>>>> > Goetz. >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> > -----Original Message----- >>>>>>>> >>>>>>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> >>>>>>>> > Sent: Montag, 22. Juli 2013 05:27 >>>>>>>> >>>>>>>> > To: Lindenmaier, Goetz >>>>>>>> >>>>>>>> > Cc: hotspot-dev at openjdk.java.net >>>>>>>> ; >>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>> ; Vladimir Kozlov >>>>>>>> >>>>>>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>>>> for interpreter only VM. >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>>>>>> >>>>>>>> >> Hi David, >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>>>> >>>>>>>> >>> 34 #ifndef _LP64 >>>>>>>> >>>>>>>> >>> 35 #error "Atomic currently only impleneted for PPC64" >>>>>>>> >>>>>>>> >>> 36 #endif >>>>>>>> >>>>>>>> >> You're right, I'll fix this. >>>>>>>> >>>>>>>> >> If you don't object I'll guard it by PPC64 as it depends on the >>>>>>>> >>>>>>>> >> processor architecture and not the memory model. >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> > Is there some case where _LP64 would be true but PPC64 would not >>>>>>>> be ??? >>>>>>>> >>>>>>>> > They seem effectively interchangeable but I don't know why you >>>>>>>> would use >>>>>>>> >>>>>>>> > one in one file and the other in another file ?? >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> > Thanks, >>>>>>>> >>>>>>>> > David >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> >> If I will change the ppc_ prefixes that'll take a bit, >>>>>>>> especially >>>>>>>> >>>>>>>> >> as I will have to adapt all the alignments :(. >>>>>>>> >>>>>>>> >> But that does not matter, as we need to wait for your build >>>>>>>> >>>>>>>> >> change anyways. >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> Best regards, >>>>>>>> >>>>>>>> >> Goetz. >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> -----Original Message----- >>>>>>>> >>>>>>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> >>>>>>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>>>>>> >>>>>>>> >> To: Lindenmaier, Goetz >>>>>>>> >>>>>>>> >> Cc: hotspot-dev at openjdk.java.net >>>>>>>> ; >>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>> ; Vladimir Kozlov >>>>>>>> >>>>>>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files >>>>>>>> for interpreter only VM. >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> Hi Goetz, >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> Only a brief glance through ... >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> 34 #ifndef _LP64 >>>>>>>> >>>>>>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>>>>>> >>>>>>>> >> 36 #endif >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong variants >>>>>>>> will only >>>>>>>> >>>>>>>> >> be atomic on ppc64). >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> BTW typo: 35 #error "Atomic currently only impleneted for >>>>>>>> PPC64" >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> I also find the ppc_ prefix used in the assembly code somewhat >>>>>>>> redundant. >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> David >>>>>>>> >>>>>>>> >> ----- >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>>>>>> >>>>>>>> >>> Hi, >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>> This time with webrev. Sorry for the double mails. >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>> This change contains all the files in cpu/ppc and >>>>>>>> os_cpu/linux_ppc needed for >>>>>>>> >>>>>>>> >>> the PPC64 interpreter port on linux. >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>> With this change you can do a core build on ppc64 and run the >>>>>>>> VM interpreter only. >>>>>>>> >>>>>>>> >>> It executes simple programs as jvm98. >>>>>>>> >>>>>>>> >>> The change requires >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>> * 8016697: Use stubs to implement safefetch >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>> * 8020059: The flag introduced by 8014972 is not >>>>>>>> defined ... >>>>>>>> >>>>>>>> >>> which will arrive soon in the staging repository. >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>> I marked the change as XL as it contains a lot of code. >>>>>>>> Nevertheless the >>>>>>>> >>>>>>>> >>> code has no impact on the existing Oracle platforms. >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>> The change touches a single shared file, globals.hpp, >>>>>>>> removing a >>>>>>>> >>>>>>>> >>> special case introduced for the port. This is because we >>>>>>>> >>>>>>>> >>> integrated some changes earlier than originally intended. >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>> Please review the change. Does it need testing on Oracle >>>>>>>> side? >>>>>>>> >>>>>>>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>> Best regards, >>>>>>>> >>>>>>>> >>> Goetz. >>>>>>>> >>>>>>>> >>> >>>>>>>> From serguei.spitsyn at oracle.com Fri Jul 26 02:00:55 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 26 Jul 2013 02:00:55 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51F164CF.50307@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> Message-ID: <51F23AC7.9050004@oracle.com> Hi Bill, Sorry for the big delay. http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ src/share/classes/com/sun/tools/attach/VirtualMachine.java: I'm suggesting to use the reference *Agent_OnAttach[_L]**||* even more consistently. (If, in some cases, you prefer the longer form to underline the difference between dynamically and statically linked libraries then feel free to leave it as it is.) It would simplify the following fragments: 304 * It then causes the target VM to invoke the Agent_OnAttach function 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function ==> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function 409 * It then causes the target VM to invoke the Agent_OnAttach 410 * function or, for a statically linked agent named 'L', the 411 * Agent_OnAttach_L function as specified in the ==> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] 410 * function as specified in the the following 4 identical fragments: 341 * If the Agent_OnAttach function returns an error 342 * or, for a statically linked agent named 'L', if the 343 * Agent_OnAttach_L function returns 344 * an error. 375 * If the Agent_OnAttach function returns an error 376 * or, for a statically linked agent named 'L', if the 377 * Agent_OnAttach_L function returns 378 * an error. 442 * If the Agent_OnAttach function returns an error 443 * or, for a statically linked agent named 'L', if the 444 * Agent_OnAttach_L function returns an error 475 * If the Agent_OnAttach function returns an error 476 * or, for a statically linked agent named 'L', if the 477 * Agent_OnAttach_L function returns 478 * an error. ==> 336 * If the Agent_OnAttach[_L] function returns an error. http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html src/share/vm/prims/jvmti.xml Lines 442-462: many extra

's. The fragment does not look well. I'd suggest to remove most of them. Also, these lines are too long. Could you make them shorter, please? The same is applied to other long new lines in this file. Lines 490-491, 502-503, 505-506: The same sentence is repeated 3 times: "the agent library may be statically linked ..." 490 Note that the agent library may be statically linked into the executable 491 in which case no actual loading takes place. 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, the VM will attempt to 502 load the shared library c:\myLibs\foo.dll. As mentioned above, the agent library may be statically linked into the executable 503 in which case no actual loading takes place 505 Note that the agent library may be statically linked into the executable 506 in which case no actual loading takes place. Lines 677-678: The dot is missed at the end of line 677: 677 and enabled the event src/os/posix/vm/os_posix.cpp - no comments src/os/windows/vm/os_windows.cpp - no comments src/share/vm/prims/jvmtiExport.cpp - no comments src/share/vm/runtime/arguments.hpp - no comments src/share/vm/runtime/os.cpp Space is missed after the 'if': 471 if(entryName != NULL) { Extra space after the '*': 483 void * saveHandle; src/share/vm/runtime/os.hpp - no comments src/share/vm/runtime/thread.cpp The line has been removed: 3866 break; I'm still in process of reading the code. Another pass is needed to make sure that nothing is missed. But in general, the code quality is pretty good. Thanks, Serguei On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: > Still need an official reviewer for the hotspot changes for statically > linked agents. > > thanks, > bill > >> These changes address bug 8014135 which adds support for statically >> linked agents in the VM. This is a followup to the recent JNI spec >> changes that addressed statically linked JNI libraries( 8005716). >> The JEP for this change is the same JEP as the JNI changes: >> http://openjdk.java.net/jeps/178 >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >> >> The changes to jvmti.xml can also be seen in the output file that I >> placed here: >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >> >> >> Thanks, >> bill >> > From karen.kinnear at oracle.com Fri Jul 26 05:08:18 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 26 Jul 2013 08:08:18 -0400 Subject: RFR: 8009130 JCK lambda test fails with IllegalAccessException In-Reply-To: <2C527CC3-375B-4C10-AB04-5CDA1BF687B0@oracle.com> References: <2C527CC3-375B-4C10-AB04-5CDA1BF687B0@oracle.com> Message-ID: <602B320D-BBC7-44C5-8603-AAA55F64B80A@oracle.com> I updated the webrev for review to: > http://cr.openjdk.java.net/~acorn/8009130.1/webrev/ I thought I had fixed a jvmti redefineclasses problem with the earlier one, but further testing showed I needed to a better fix, which is in this webrev, which is also against a more current hotspot-rt. thanks, Karen On Jul 24, 2013, at 5:33 PM, Karen Kinnear wrote: > > Please review fix for access checking and loader constraint checking for default methods: > > http://cr.openjdk.java.net/~acorn/8009130/webrev/ > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009130 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013085 > > Summary: > Now that javac is generating bridges for generic signatures in interfaces, and the JVM > does not need to handle generic signatures and covariant returns in handling default methods, > it is possible to simplify the handling of default methods. > > Default methods are concrete methods in interfaces. Their inheritance rules simplified are: > 1. class method or superclass method wins > 2. if there is a unique nonshadowed default method in superinterfaces it is chosen > (this logic was not changed, and many thanks to Keith McGuigan for writing that code so well) > 3. otherwise we get an AbstractMethodError on invocation > > Before this change, we created overpass (VM created bridge methods) added them to > the methods array and updated the constant pool. This allowed us to add checkcasts for > input and return arguments. We don't need those anymore so we don't need overpass methods > for default handling. The overpass methods added invokespecial invocation instructions which > ran into issues with access checking, i.e. not being able to access the constantpool of the > invokespecial linktime resolved method, since they did not always have permission to access the > interface class. > > With this change default methods are added as an array to instanceKlass and to the instanceKlass vtable. > Invocation method search order: > 1. local methods > 2. superclass methods > 3. default methods > 4. abstract interface methods > > The default methods retain their superinterface method_holder, i.e. owning klass, so the > access checking and loader constraint checking all works as expected with no special logic > needed. > > We continue to use overpasses for default exception handling, e.g. to create a custom > AbstractMethodError for the conflict case above. > > Tests run - all on linux64: > jck vm > expect a new failure mode for resolveMethod00602m1 and resolveMethod00602m2 in fastdebug > - they will get an assertion. They will be in the jck exclude list next week due to an existing bug: 8011311, support for > private instance methods in interfaces not working. > jck lang > jtreg jdk (concurrency=1) : java.util, java.lang, jdk.lambda > nsk vm.quick.testlist, vm.mlvm, vm.quick-jvmti.testlist > > 8009130 package private example > specifically fixes: > lang/CLSS/clss475/clss47501m21 and clss47501m211 > lang/INTF/intf024/intf02402m01 and intf02402m11 > 8013085 loader constraint example > nsk defmeth tests - with and without redefineclasses > - passes all tests that passed before this change, other existing bugs prevent complete passing > Reflect2 - reflection modeling > reflect.invoke - DefaultStaticTest.java > intfbug test > jcmd GC:class_stats > > thanks, > Karen > > > From alejandro.murillo at oracle.com Fri Jul 26 06:58:49 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 26 Jul 2013 13:58:49 +0000 Subject: hg: hsx/hsx25/hotspot: 39 new changesets Message-ID: <20130726140017.60635483D4@hg.openjdk.java.net> Changeset: 9d7b55c8a0c4 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9d7b55c8a0c4 Added tag jdk8-b100 for changeset 5787fac72e76 ! .hgtags Changeset: 2285b4a0a4e6 Author: amurillo Date: 2013-07-18 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2285b4a0a4e6 8020797: new hotspot build - hs25-b43 Reviewed-by: jcoomes ! make/hotspot_version Changeset: dbc0b5dc08f5 Author: fparain Date: 2013-07-10 15:49 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dbc0b5dc08f5 7143807: ResourceMark nesting problem in stringStream Reviewed-by: kvn, dcubed ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: c9a5fab39234 Author: zgu Date: 2013-07-11 13:15 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c9a5fab39234 8012241: NMT huge memory footprint, it usually leads to OOME Summary: Enforce memory limitation on NMT to prevent JVM OOM Reviewed-by: acorn, dcubed, minqi ! src/share/vm/services/memTracker.cpp Changeset: 5f056abe17c6 Author: zgu Date: 2013-07-12 04:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5f056abe17c6 Merge Changeset: 2e8f19c2feef Author: allwin Date: 2013-07-12 18:43 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2e8f19c2feef 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Summary: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Reviewed-by: dcubed, dholmes, sspitsyn, mgerdin, ctornqvi, dsamersoff ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/windows/vm/attachListener_windows.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.hpp + test/serviceability/attach/AttachWithStalePidFile.java + test/serviceability/attach/AttachWithStalePidFileTarget.java Changeset: c0cb474be37e Author: ctornqvi Date: 2013-07-12 20:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c0cb474be37e Merge Changeset: 862625d214fa Author: fparain Date: 2013-07-15 00:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/862625d214fa Merge Changeset: 23123fc6968a Author: rbackman Date: 2013-07-15 11:35 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/23123fc6968a 8019324: assert(_f2 == 0 || _f2 == f2) failed: illegal field change Reviewed-by: dholmes, rbackman Contributed-by: David Simms ! src/share/vm/oops/cpCache.hpp Changeset: ee9e76adced3 Author: rbackman Date: 2013-07-15 12:06 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ee9e76adced3 Merge Changeset: 33c52908bcdb Author: dholmes Date: 2013-07-15 23:23 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/33c52908bcdb 8015759: hotspot changes needed to compile with Visual Studio 2012 Reviewed-by: anthony, dholmes, dcubed Contributed-by: Tim Bell ! make/windows/makefiles/compile.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/vm.make ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp Changeset: 39deebbc90b3 Author: mgerdin Date: 2013-07-16 07:33 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/39deebbc90b3 6671508: JNI GetPrimitiveArrayCritical should not be callable on object arrays Summary: Checked JNI now reports error for Get/ReleasePrimitiveArrayCritical on object arrays Reviewed-by: dholmes, acorn Contributed-by: david.simms at oracle.com ! src/share/vm/prims/jniCheck.cpp Changeset: e619a2766bcc Author: rbackman Date: 2013-06-12 11:17 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e619a2766bcc 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Reviewed-by: jrose, kvn, mgronlun ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 732af649bc3a Author: ccheung Date: 2013-07-17 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/732af649bc3a 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 Summary: Added (sig < MAXSIGNUM) check in jsig.c Reviewed-by: dholmes, acorn ! src/os/linux/vm/jsig.c + test/runtime/jsig/Test8017498.sh + test/runtime/jsig/TestJNI.c + test/runtime/jsig/TestJNI.java Changeset: 825e6cb66923 Author: jiangli Date: 2013-07-17 18:06 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/825e6cb66923 8020309: Eliminate InstanceKlass::_cached_class_file_len. Summary: Use JvmtiCachedClassFileData. Reviewed-by: iklam, sspitsyn, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6388dbc4b7ca Author: jiangli Date: 2013-07-17 17:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6388dbc4b7ca Merge Changeset: c29568b733d2 Author: dholmes Date: 2013-07-18 06:47 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c29568b733d2 8020697: jniCheck.cpp:check_is_obj_array asserts on TypeArrayKlass::cast(aOop->klass()) Reviewed-by: dcubed, fparain, dholmes Contributed-by: David Simms ! src/share/vm/prims/jniCheck.cpp Changeset: 5e3b6f79d280 Author: rbackman Date: 2013-07-17 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5e3b6f79d280 8020701: Avoid crashes in WatcherThread Reviewed-by: acorn, dcubed, dsimms ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 248c459b2b75 Author: dcubed Date: 2013-07-18 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/248c459b2b75 Merge ! src/share/vm/services/memTracker.cpp Changeset: af21010d1062 Author: dcubed Date: 2013-07-18 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/af21010d1062 Merge ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/os.hpp Changeset: 02d7aa1456c9 Author: ccheung Date: 2013-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/02d7aa1456c9 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed Summary: this fix also removes the -XX:+UseStringCache option Reviewed-by: dholmes, acorn, iklam ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: 383a5e21cc2d Author: minqi Date: 2013-07-18 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/383a5e21cc2d Merge Changeset: 060ae9b7ffea Author: mgronlun Date: 2013-07-19 17:56 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/060ae9b7ffea 8020547: Event based tracing needs a UNICODE string type Reviewed-by: egahlin, rbackman, dcubed, brutisso, acorn ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/xinclude.mod Changeset: 4614a598dae1 Author: minqi Date: 2013-07-19 08:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4614a598dae1 8016538: volatile double access via Unsafe.cpp is not atomic Summary: volatile jdouble load/store is not atomic, fix by using of existing volatile jlong operations which are atomic for jdouble. Reviewed-by: kvn, vladidan, jrose Contributed-by: david.holmes at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp Changeset: 55a61ceb2fe7 Author: minqi Date: 2013-07-19 11:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/55a61ceb2fe7 Merge Changeset: 16511b7e3d35 Author: emc Date: 2013-07-22 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/16511b7e3d35 8019632: Method parameters are not copied in clone_with_new_data Summary: Add code to copy method parameters data in clone_with_new_data Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.cpp Changeset: 72727c4b6dec Author: ccheung Date: 2013-07-19 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/72727c4b6dec 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code Summary: Added -DLINUX to the gcc command and improved the .sh script Reviewed-by: dcubed, dholmes, minqi ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 5165d659cebd Author: minqi Date: 2013-07-22 22:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5165d659cebd Merge Changeset: c0f353803b47 Author: minqi Date: 2013-07-23 12:50 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c0f353803b47 Merge Changeset: c90c698831d7 Author: kvn Date: 2013-07-12 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c90c698831d7 8020215: Different execution plan when using JIT vs interpreter Summary: fix bytecode analyzer Reviewed-by: twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp + test/compiler/EscapeAnalysis/Test8020215.java Changeset: fcf521c3fbc6 Author: kvn Date: 2013-07-12 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fcf521c3fbc6 8007898: Incorrect optimization of Memory Barriers in Matcher::post_store_load_barrier() Summary: generate one "fat" membar instead of set of barriers for volitile store Reviewed-by: roland ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/membars/DekkerTest.java Changeset: 34ce0b5acb81 Author: morris Date: 2013-07-15 06:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/34ce0b5acb81 Merge Changeset: 0f57ccdb9084 Author: kvn Date: 2013-07-15 10:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0f57ccdb9084 8020433: Crash when using -XX:+RestoreMXCSROnJNICalls Summary: remove StubRoutines::x86::_mxcsr_std and use StubRoutines::_mxcsr_std Reviewed-by: jrose ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp + test/compiler/cpuflags/RestoreMXCSR.java Changeset: 46a90f83df31 Author: morris Date: 2013-07-19 13:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/46a90f83df31 Merge ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 6efedc114807 Author: morris Date: 2013-07-24 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6efedc114807 Merge Changeset: 01aa164323fa Author: dholmes Date: 2013-07-24 19:23 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/01aa164323fa 8020799: Allow customization of hotspot source directories and files Reviewed-by: kvn, dlong ! make/linux/makefiles/vm.make Changeset: a4b9a8ec8f4a Author: jiangli Date: 2013-07-25 18:12 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a4b9a8ec8f4a Merge Changeset: 46487ba40ff2 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/46487ba40ff2 Merge Changeset: f6921c876db1 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f6921c876db1 Added tag hs25-b43 for changeset 46487ba40ff2 ! .hgtags From alejandro.murillo at oracle.com Fri Jul 26 08:37:43 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 26 Jul 2013 15:37:43 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130726153807.09332483DD@hg.openjdk.java.net> Changeset: 9d7b55c8a0c4 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9d7b55c8a0c4 Added tag jdk8-b100 for changeset 5787fac72e76 ! .hgtags Changeset: 46487ba40ff2 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/46487ba40ff2 Merge Changeset: f6921c876db1 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f6921c876db1 Added tag hs25-b43 for changeset 46487ba40ff2 ! .hgtags Changeset: e84845884c85 Author: amurillo Date: 2013-07-26 04:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e84845884c85 8021566: new hotspot build - hs25-b44 Reviewed-by: jcoomes ! make/hotspot_version From christian.thalinger at oracle.com Fri Jul 26 09:21:18 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 26 Jul 2013 09:21:18 -0700 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> Message-ID: <57C1A33A-2D35-4745-977A-84C786AA87A6@oracle.com> Could you paste an example output? -- Chris On Jul 25, 2013, at 4:11 PM, "Lindenmaier, Goetz" wrote: > Hi, > > we'd like to contribute our posix signal printing. > We implemented some routines to print signal and sa_flags information > in the os/posix files, and call them from > os::print_siginfo and print_signal_handler() in the various unix > variant directories. > The output is a bit more verbose than the existing version. > > We contribute this here, as our aix code uses this too. > > Please review this and test it if you think we should add this. > We'd appreciate it. > http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ > > Thanks and best regards, > Goetz. From christian.thalinger at oracle.com Fri Jul 26 09:34:34 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 26 Jul 2013 09:34:34 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F1BF6E.1080801@oracle.com> References: <51F1BF6E.1080801@oracle.com> Message-ID: On Jul 25, 2013, at 5:14 PM, serguei.spitsyn at oracle.com wrote: > > Please, review the fix for: > bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 > jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 src/share/vm/classfile/javaClasses.hpp: + public: + // Accessors + static oop member(oop mh); + static void set_member(oop mh, oop member); Where is the implementation for these methods? Because if we had them you could use it here: src/share/vm/interpreter/interpreterRuntime.cpp: + oop member_name = (dmh_oop)->obj_field(java_lang_invoke_DirectMethodHandle::member_offset_in_bytes()); Otherwise this change looks really good and clean. It's not so bad after all. -- Chris > > Summary: > Restore the appendix argument of a polymorphic intrinsic call > needed for a invokestatic re-execution after JVMTI PopFrame(). > > Description > When JVMTI's PopFrame removes a frame that was called via a call site that > takes an appendix and that call site is reexecuted the appendix is not on > the stack anymore because it got removed by the adapter. > This fix is to detect such a case and push the appendix on the stack again before reexecution. > > > Testing: > UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, nsk.jdi.testlist > > Thanks, > Serguei From serguei.spitsyn at oracle.com Fri Jul 26 09:54:10 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 26 Jul 2013 09:54:10 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: References: <51F1BF6E.1080801@oracle.com> Message-ID: <51F2A9B2.6090206@oracle.com> On 7/26/13 9:34 AM, Christian Thalinger wrote: > On Jul 25, 2013, at 5:14 PM, serguei.spitsyn at oracle.com wrote: > >> Please, review the fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 > src/share/vm/classfile/javaClasses.hpp: > > + public: > + // Accessors > + static oop member(oop mh); > + static void set_member(oop mh, oop member); > > Where is the implementation for these methods? Because if we had them you could use it here: Good idea, I'll look at it. > > src/share/vm/interpreter/interpreterRuntime.cpp: > > + oop member_name = (dmh_oop)->obj_field(java_lang_invoke_DirectMethodHandle::member_offset_in_bytes()); > > Otherwise this change looks really good and clean. It's not so bad after all. Thank you for the review. I agree, it is not that ugly as it seemed to be initially. :) Thanks, Serguei > > -- Chris > >> Summary: >> Restore the appendix argument of a polymorphic intrinsic call >> needed for a invokestatic re-execution after JVMTI PopFrame(). >> >> Description >> When JVMTI's PopFrame removes a frame that was called via a call site that >> takes an appendix and that call site is reexecuted the appendix is not on >> the stack anymore because it got removed by the adapter. >> This fix is to detect such a case and push the appendix on the stack again before reexecution. >> >> >> Testing: >> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, nsk.jdi.testlist >> >> Thanks, >> Serguei From alejandro.murillo at oracle.com Fri Jul 26 11:36:40 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 26 Jul 2013 18:36:40 +0000 Subject: hg: hsx/hsx24/hotspot: 8021353: Event based tracing is missing thread exit Message-ID: <20130726183646.1FC15483E4@hg.openjdk.java.net> Changeset: bf3070e2ed2c Author: egahlin Date: 2013-07-26 16:19 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bf3070e2ed2c 8021353: Event based tracing is missing thread exit Reviewed-by: allwin, dcubed, acorn ! src/share/vm/runtime/thread.cpp ! src/share/vm/trace/traceMacros.hpp From vladimir.kozlov at oracle.com Fri Jul 26 12:11:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 26 Jul 2013 12:11:13 -0700 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> Message-ID: <51F2C9D1.60907@oracle.com> I think it is good cleanup. Thank you, Goetz. Few notes. Could you align elements/names in tables in get_signal_name() and get_signal_code_description() to make them aligned with each other and with #ifdefs? It looks like all unixes (including bsd) have NSIG value defined (I could be wrong). you can use it directly instead of MAX_SIGNAL_NUMBER. On Solaris it is: /usr/include/sys/signal.h:#define NSIG 73 /* valid signals range from 1 to NSIG-1 */ /usr/include/sys/signal.h:#define MAXSIG 72 /* size of u_signal[], NSIG-1 <= MAXSIG */ May be you can avoid #ifdef APPLE such way. describe_signal_set_short() method is bogus. Why you overwrite buf[0] with "0" or "1" and the rest of buffer with 0 each time? Should it be And why you need separate describe_signal_set_short() method? And why you need *10 for buffer size? I would prefer to see the code similar to describe_sa_flags() with list of signals instead of "01". Yes, it would be different from current code but it would much more useful to have signal names. In describe_sa_flags(): size_t remaining = size-1; // leave space for /0 Again, why you separated describe_sa_flags() method? In get_signal_code_description(): Add break: + for (int i = 0; t1[i].sig != -1; i ++) { + if (t1[i].sig == si->si_signo && t1[i].code == si->si_code) { + s_code = t1[i].s_code; + s_desc = t1[i].s_desc; + break; + } + } + Put on different lines: + out->s_name = out->s_desc = "unknown"; Why not use s_name instead of s_code to match out->s_name? Thanks, Vladimir On 7/25/13 4:11 PM, Lindenmaier, Goetz wrote: > Hi, > > we'd like to contribute our posix signal printing. > We implemented some routines to print signal and sa_flags information > in the os/posix files, and call them from > os::print_siginfo and print_signal_handler() in the various unix > variant directories. > The output is a bit more verbose than the existing version. > > We contribute this here, as our aix code uses this too. > > Please review this and test it if you think we should add this. > We'd appreciate it. > http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ > > Thanks and best regards, > Goetz. > From vladimir.kozlov at oracle.com Fri Jul 26 14:41:40 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 26 Jul 2013 21:41:40 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8008938: TieredCompilation should be default Message-ID: <20130726214145.D7B61483EE@hg.openjdk.java.net> Changeset: d90d1b96b65b Author: kvn Date: 2013-07-26 12:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d90d1b96b65b 8008938: TieredCompilation should be default Summary: switch on TieredCompilation by default Reviewed-by: twisti ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp From alejandro.murillo at oracle.com Fri Jul 26 15:43:24 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 26 Jul 2013 22:43:24 +0000 Subject: hg: hsx/hsx24/hotspot: 57 new changesets Message-ID: <20130726224530.5BD2F483F9@hg.openjdk.java.net> Changeset: 28bc4fc3ae68 Author: katleman Date: 2013-07-24 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/28bc4fc3ae68 Added tag jdk7u40-b35 for changeset 0af6bc95c1cb ! .hgtags Changeset: 3168f3e14339 Author: poonam Date: 2013-03-06 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3168f3e14339 8006309: More reliable control panel operation Summary: Added a comment in the dead Kernel code Reviewed-by: ahgross, sla, coleenp ! src/share/vm/runtime/thread.cpp Changeset: bf2d84c5103d Author: hseigel Date: 2013-03-12 16:23 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bf2d84c5103d 7158805: Better rewriting of nested subroutine calls Reviewed-by: mschoene, coleenp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/oops/generateOopMap.cpp Changeset: 238f85fd3c98 Author: katleman Date: 2013-03-12 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/238f85fd3c98 Added tag jdk7u25-b01 for changeset bf2d84c5103d ! .hgtags Changeset: 07119340f80f Author: kvn Date: 2013-03-15 09:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/07119340f80f 8009699: Methodhandle lookup Reviewed-by: ahgross, jrose, jdn ! src/share/vm/prims/methodHandles.cpp Changeset: cd733fbd5ca8 Author: katleman Date: 2013-03-19 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cd733fbd5ca8 Added tag jdk7u25-b02 for changeset 07119340f80f ! .hgtags Changeset: 655bea6843fb Author: coffeys Date: 2013-03-21 22:29 +0000 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/655bea6843fb Merge ! .hgtags Changeset: 96a4e612195c Author: katleman Date: 2013-03-26 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/96a4e612195c Added tag jdk7u25-b03 for changeset 655bea6843fb ! .hgtags Changeset: 1bc51c62d162 Author: katleman Date: 2013-04-02 12:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1bc51c62d162 Added tag jdk7u25-b04 for changeset 96a4e612195c ! .hgtags Changeset: fd81c9aeb9f5 Author: mullan Date: 2013-04-05 08:36 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fd81c9aeb9f5 8001330: Improve on checking order Reviewed-by: acorn, hawtin ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: 1d448101a555 Author: mullan Date: 2013-04-05 08:49 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1d448101a555 Merge Changeset: e565780c14d2 Author: coffeys Date: 2013-04-05 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e565780c14d2 Merge ! .hgtags Changeset: e37b316096a6 Author: katleman Date: 2013-03-04 14:17 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e37b316096a6 Added tag jdk7u17-b32 for changeset 8e04b403f580 ! .hgtags Changeset: e22194a44dc9 Author: asaha Date: 2013-04-08 15:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e22194a44dc9 Merge ! .hgtags Changeset: 47a9f44dd262 Author: asaha Date: 2013-04-08 16:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/47a9f44dd262 Merge ! .hgtags Changeset: efec74090462 Author: asaha Date: 2013-04-09 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/efec74090462 8011806: 7u25-b05 hotspot fastdebug build failure Summary: Backed out changeset fd81c9aeb9f5 Reviewed-by: mullan ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: 7151c26b8388 Author: asaha Date: 2013-04-09 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7151c26b8388 Merge Changeset: fbb5f6083dd0 Author: katleman Date: 2013-04-10 12:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fbb5f6083dd0 Added tag jdk7u25-b05 for changeset 7151c26b8388 ! .hgtags Changeset: 83abf4b2fc8a Author: katleman Date: 2013-04-16 11:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/83abf4b2fc8a Added tag jdk7u25-b06 for changeset fbb5f6083dd0 ! .hgtags Changeset: 631f703ba794 Author: katleman Date: 2013-04-18 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/631f703ba794 Added tag jdk7u25-b07 for changeset 83abf4b2fc8a ! .hgtags Changeset: 1410ff0b4ba2 Author: mullan Date: 2013-04-18 17:52 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1410ff0b4ba2 8001330: Improve on checking order 8011896: Add check for invalid offset for new AccessControlContext isAuthorized field Reviewed-by: acorn, hawtin ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: 525252cd9fca Author: mullan Date: 2013-04-18 17:58 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/525252cd9fca Merge Changeset: 706a255a8404 Author: katleman Date: 2013-04-23 16:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/706a255a8404 Added tag jdk7u25-b08 for changeset 525252cd9fca ! .hgtags Changeset: 402184622f60 Author: katleman Date: 2013-04-30 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/402184622f60 Added tag jdk7u25-b09 for changeset 706a255a8404 ! .hgtags Changeset: a2e45b168404 Author: katleman Date: 2013-05-07 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a2e45b168404 Added tag jdk7u25-b10 for changeset 402184622f60 ! .hgtags Changeset: cca49a35bf83 Author: asaha Date: 2013-05-10 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cca49a35bf83 8014312: Fork hs23.25 hsx from hs23.21 for jdk7u25 and reinitialize build number Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7ca68c0674df Author: katleman Date: 2013-05-15 13:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7ca68c0674df Added tag jdk7u25-b11 for changeset cca49a35bf83 ! .hgtags Changeset: 3e145a686fed Author: katleman Date: 2013-05-22 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3e145a686fed Added tag jdk7u25-b12 for changeset 7ca68c0674df ! .hgtags Changeset: 4fafaf293aa5 Author: katleman Date: 2013-05-24 16:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4fafaf293aa5 Added tag jdk7u25-b13 for changeset 3e145a686fed ! .hgtags Changeset: 40acb370626f Author: katleman Date: 2013-06-04 10:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/40acb370626f Added tag jdk7u25-b14 for changeset 4fafaf293aa5 ! .hgtags Changeset: 97a3ebd62052 Author: katleman Date: 2013-06-06 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/97a3ebd62052 Added tag jdk7u25-b15 for changeset 40acb370626f ! .hgtags Changeset: c4e434f6b4f3 Author: asaha Date: 2013-04-11 10:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c4e434f6b4f3 Merge ! .hgtags Changeset: 39628b02a383 Author: tonyp Date: 2012-03-23 10:53 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/39628b02a383 7146246: G1: expose some of the -XX flags that drive which old regions to collect during mixed GCs Summary: Make two G1 cmd line flags available in product builds: G1HeapWastePercent (previously called: G1OldReclaimableThresholdPercent) and G1MixedGCCountTarget (previous called: G1MaxMixedGCNum). Also changed the default of the former from 1% to 5% and the default for G1OldCSetRegionLiveThresholdPercent to 90%. Reviewed-by: azeemj, jwilhelm, johnc ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ae08248e0ed0 Author: dlong Date: 2012-04-26 16:24 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ae08248e0ed0 7162955: Attach api on Solaris, too many open files Summary: Release server-side socket after client receives it. Reviewed-by: sla, dsamersoff, dcubed, acorn Contributed-by: dean.long at oracle.com ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 202b7ee59b9d Author: brutisso Date: 2012-08-23 05:25 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/202b7ee59b9d 7193157: G1: Make some develpflags available in product builds Summary: Also reviewed by: vitalyd at gmail.com. Make G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, G1OldCSetRegionLiveThresholdPercent and G1OldCSetRegionThresholdPercent experimental flags Reviewed-by: ysr, johnc, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 27ae6b2b524f Author: johnc Date: 2013-04-26 16:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/27ae6b2b524f 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1Mixed GCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 5b9431420b1d Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5b9431420b1d 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 00dbf9fa12ec Author: asaha Date: 2013-04-30 20:38 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/00dbf9fa12ec 8013719: Increment build # of hs23.21 to b02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0940a9c6db12 Author: katleman Date: 2013-05-01 14:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0940a9c6db12 Added tag jdk7u21-b31 for changeset 00dbf9fa12ec ! .hgtags Changeset: 3f4d8e9235d7 Author: asaha Date: 2013-06-06 13:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3f4d8e9235d7 Merge ! .hgtags ! make/hotspot_version Changeset: d097540731cf Author: asaha Date: 2013-06-06 13:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d097540731cf 8016102: Increment build # of hs23.25 to b02 for 7u25-b31 psu Reviewed-by: jcoomes ! make/hotspot_version Changeset: 25ff58ae2858 Author: asaha Date: 2013-05-24 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/25ff58ae2858 8015411: Bump the hsx build number for 7u21-b50 for customer Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8386245b59c3 Author: iklam Date: 2013-03-28 19:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8386245b59c3 7107135: Stack guard pages are no more protected after loading a shared library with executable stack Summary: Detect the execstack attribute of the loaded library and attempt to fix the stack guard using Safepoint op. Reviewed-by: dholmes, zgu ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp + test/runtime/7107135/Test.java + test/runtime/7107135/Test7107135.sh + test/runtime/7107135/TestMT.java + test/runtime/7107135/test.c + test/runtime/8010389/VMThreadDlopen.java Changeset: 9da661161a5d Author: katleman Date: 2013-05-28 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9da661161a5d Added tag jdk7u21-b50 for changeset 8386245b59c3 ! .hgtags Changeset: 7a89d807b23e Author: asaha Date: 2013-06-06 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7a89d807b23e Merge ! .hgtags Changeset: 8d0aee729774 Author: jcoomes Date: 2013-05-31 08:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8d0aee729774 6725714: par compact - add a table to speed up bitmap searches Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 73863f836e34 Author: jcoomes Date: 2013-05-23 03:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/73863f836e34 8014611: reserve_and_align() assumptions are invalid on windows Summary: also reviewed by ron.durbin at oracle.com, thomas.schatzl at oracle.com Reviewed-by: dcubed, brutisso ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: dd9090ad5521 Author: katleman Date: 2013-06-11 17:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dd9090ad5521 Added tag jdk7u25-b31 for changeset 73863f836e34 ! .hgtags Changeset: 3e6901d0021b Author: katleman Date: 2013-06-18 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3e6901d0021b Added tag jdk7u25-b33 for changeset dd9090ad5521 ! .hgtags Changeset: 58c63a4e7746 Author: asaha Date: 2013-07-15 08:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/58c63a4e7746 8020525: Increment build # of hs23.25 to b03 for 7u25-b34 psu Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9af6a8fa6a55 Author: rasbold Date: 2013-04-03 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9af6a8fa6a55 8010437: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset Summary: Fix shorten_branches() to accurately count an initial nop that may be inserted in a block that starts with a safepoint. Reviewed-by: kvn ! src/share/vm/opto/output.cpp Changeset: 3265def2e0a2 Author: katleman Date: 2013-07-18 20:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3265def2e0a2 Added tag jdk7u25-b34 for changeset 9af6a8fa6a55 ! .hgtags Changeset: 63085fd28f10 Author: jcoomes Date: 2013-07-19 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/63085fd28f10 Merge ! .hgtags ! make/hotspot_version ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp Changeset: 97c998b91726 Author: asaha Date: 2013-07-23 20:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/97c998b91726 Merge ! .hgtags ! make/hotspot_version ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.hpp Changeset: cf4d5e8cadf6 Author: asaha Date: 2013-07-24 18:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cf4d5e8cadf6 Merge ! .hgtags Changeset: 675a89fd4548 Author: amurillo Date: 2013-07-26 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/675a89fd4548 Merge ! make/hotspot_version Changeset: 350bd7589660 Author: amurillo Date: 2013-07-26 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/350bd7589660 Added tag hs24-b55 for changeset 675a89fd4548 ! .hgtags From alejandro.murillo at oracle.com Fri Jul 26 19:43:52 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 27 Jul 2013 02:43:52 +0000 Subject: hg: hsx/hsx24/hotspot: 8021565: new hotspot build - hs24-b56 Message-ID: <20130727024359.4ACEE4840F@hg.openjdk.java.net> Changeset: b006d79fa741 Author: amurillo Date: 2013-07-26 12:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b006d79fa741 8021565: new hotspot build - hs24-b56 Reviewed-by: jcoomes ! make/hotspot_version From rednaxelafx at gmail.com Sun Jul 28 00:59:30 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sun, 28 Jul 2013 15:59:30 +0800 Subject: Avoid using deprecated stat64 on Mac OS X Message-ID: Hi all, I'm building a freshly cloned repo from the tip of hotspot-comp on Mac OS X 10.7.5, and got and error: llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -I. -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/share/vm/prims -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/share/vm -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/share/vm/precompiled -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/cpu/x86/vm -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b44-internal\"" -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"rednaxelafx\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 -pipe -fno-strict-aliasing -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -Os -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wunused-function -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -DALLOW_OPERATOR_NEW_USAGE -c -MMD -MP -MF ../generated/dependencies/attachListener_bsd.o.d -fpch-deps -o attachListener_bsd.o /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp cc1plus: warnings being treated as errors /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp: In static member function ?static void AttachListener::vm_start()?: /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: warning: ?stat64? is deprecated (declared at /usr/include/sys/stat.h:466) /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: warning: ?stat64? is deprecated (declared at /usr/include/sys/stat.h:466) make[6]: *** [attachListener_bsd.o] Error 1 The problem came from a recent commit [1]: 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand According to [2], the *-64 variants of the stat*() functions have been deprecated on Mac OS X and should be avoided. The fix is simple: diff -r d90d1b96b65b src/os/bsd/vm/attachListener_bsd.cpp --- a/src/os/bsd/vm/attachListener_bsd.cpp Fri Jul 26 12:37:39 2013 -0700 +++ b/src/os/bsd/vm/attachListener_bsd.cpp Sun Jul 28 15:55:54 2013 +0800 @@ -445,14 +445,14 @@ void AttachListener::vm_start() { char fn[UNIX_PATH_MAX]; - struct stat64 st; + struct stat st; int ret; int n = snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d", os::get_temp_directory(), os::current_process_id()); assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow"); - RESTARTABLE(::stat64(fn, &st), ret); + RESTARTABLE(::stat(fn, &st), ret); if (ret == 0) { ret = ::unlink(fn); if (ret == -1) { I'm not sure if this should be done for all BSD platforms. Could anybody help confirm this? Thanks, Kris (P.S. recovering from bad health...) [1]: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2e8f19c2feef [2]: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/stat64.2.html From david.holmes at oracle.com Sun Jul 28 19:46:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jul 2013 12:46:19 +1000 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> Message-ID: <51F5D77B.6040009@oracle.com> On 26/07/2013 9:11 AM, Lindenmaier, Goetz wrote: > Hi, > > we'd like to contribute our posix signal printing. This really isn't "posix signals" as it combines all the OS specific signal definitions into one chunk of code. + // A number high enough to contain all possible signal numbers. + #define MAX_SIGNAL_NUMBER 70 Why do you need this when you use sigaddset to check validity anyway? What is this "maximum signal number" meant to represent anyway? The maximum signal number on the platform, or the maximum signal number for a signal that the JVM will install a handler for? The runtime team will need to take a good look at this. Personally I'd rather not see all the different OS stuff piled in together. I'd certainly like to see as little duplication as possible, but I'd rather platform specific stuff was dealt with in platform specific files. David ----- > We implemented some routines to print signal and sa_flags information > in the os/posix files, and call them from > os::print_siginfo and print_signal_handler() in the various unix > variant directories. > The output is a bit more verbose than the existing version. > > We contribute this here, as our aix code uses this too. > Please review this and test it if you think we should add this. > We'd appreciate it. > http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ > > Thanks and best regards, > Goetz. > From david.holmes at oracle.com Sun Jul 28 21:11:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jul 2013 14:11:14 +1000 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F1BF6E.1080801@oracle.com> References: <51F1BF6E.1080801@oracle.com> Message-ID: <51F5EB62.4050002@oracle.com> Hi Serguei, On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: > > Please, review the fix for: > bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 > jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 In the templateInterpreter code why did you put this guard on your new code (from x86_32 version): 1923 #if INCLUDE_JVMTI when the whole chunk of code this is situated in is specifically for JVMTI support 1824 // 1825 // JVMTI PopFrame support 1826 // ??? David ----- > > Summary: > Restore the appendix argument of a polymorphic intrinsic call > needed for a invokestatic re-execution after JVMTI PopFrame(). > > Description > When JVMTI's PopFrame removes a frame that was called via a call site > that > takes an appendix and that call site is reexecuted the appendix is > not on > the stack anymore because it got removed by the adapter. > This fix is to detect such a case and push the appendix on the stack > again before reexecution. > > > Testing: > UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, > nsk.jdi.testlist > > Thanks, > Serguei From david.holmes at oracle.com Sun Jul 28 21:56:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jul 2013 14:56:15 +1000 Subject: Per-process core dump directory In-Reply-To: References: Message-ID: <51F5F5EF.70503@oracle.com> Hi Richard, Moving this to the hotspot-dev list, please drop the discuss list from further emails as it is not for discussion of specific technical issues in the code. Thanks, David On 26/07/2013 6:29 PM, Richard Fearn wrote: > Hi all, > > Yesterday I was looking at where core dumps are saved when Java > processes crash (on Linux). > > I know that the location of core dumps is set via the > kernel.core_pattern kernel parameter, and can be seen in > /proc/sys/kernel/core_pattern. This is a global setting, however, that > applies to any process that crashes. > > Apache httpd has a CoreDumpDirectory directive [1] that allows the > directory to be specified; Apache installs signal handlers [2] so that > the current directory is changed before the dump is written. > > Has anything similar ever been considered for the JVM? I had a quick > look in the bug database, but apart from lots of reports of core dumps > happening, I couldn't see anything about changing the location where > they are stored. Are there any existing bugs about this? > > Regards, > > Rich > > [1] http://httpd.apache.org/docs/current/mod/mpm_common.html#coredumpdirectory > > [2] http://stackoverflow.com/a/2698415/200609 > From david.holmes at oracle.com Sun Jul 28 22:24:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jul 2013 15:24:55 +1000 Subject: Avoid using deprecated stat64 on Mac OS X In-Reply-To: References: Message-ID: <51F5FCA7.4090102@oracle.com> Hi Kris, On 28/07/2013 5:59 PM, Krystal Mok wrote: > Hi all, > > I'm building a freshly cloned repo from the tip of hotspot-comp on Mac OS X > 10.7.5, and got and error: > > llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -I. > -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/share/vm/prims > -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/share/vm > -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/share/vm/precompiled > -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/cpu/x86/vm > -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm > -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm > -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/posix/vm > -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b44-internal\"" > -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" > -DHOTSPOT_BUILD_USER="\"rednaxelafx\"" -DHOTSPOT_LIB_ARCH=\"amd64\" > -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 > -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 > -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 > -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 > -pipe -fno-strict-aliasing -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 > -mmacosx-version-min=10.7.0 -Os -DVM_LITTLE_ENDIAN -D_LP64=1 > -fno-omit-frame-pointer -Werror -Wunused-function -DDTRACE_ENABLED > -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -DALLOW_OPERATOR_NEW_USAGE -c -MMD -MP > -MF ../generated/dependencies/attachListener_bsd.o.d -fpch-deps -o > attachListener_bsd.o > /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp > cc1plus: warnings being treated as errors > /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp: > In static member function ?static void AttachListener::vm_start()?: > /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: > warning: ?stat64? is deprecated (declared at /usr/include/sys/stat.h:466) > /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: > warning: ?stat64? is deprecated (declared at /usr/include/sys/stat.h:466) > make[6]: *** [attachListener_bsd.o] Error 1 > > The problem came from a recent commit [1]: > 7162400: Intermittent java.io.IOException: Bad file number during > HotSpotVirtualMachine.executeCommand > > According to [2], the *-64 variants of the stat*() functions have been > deprecated on Mac OS X and should be avoided. So is this purely an OSX issue or also a BSD one? I'm assuming OSX. Does anybody out there actually use the BSD port seperately from OSX? David ----- > > The fix is simple: > diff -r d90d1b96b65b src/os/bsd/vm/attachListener_bsd.cpp > --- a/src/os/bsd/vm/attachListener_bsd.cpp Fri Jul 26 12:37:39 2013 -0700 > +++ b/src/os/bsd/vm/attachListener_bsd.cpp Sun Jul 28 15:55:54 2013 +0800 > @@ -445,14 +445,14 @@ > > void AttachListener::vm_start() { > char fn[UNIX_PATH_MAX]; > - struct stat64 st; > + struct stat st; > int ret; > > int n = snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d", > os::get_temp_directory(), os::current_process_id()); > assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow"); > > - RESTARTABLE(::stat64(fn, &st), ret); > + RESTARTABLE(::stat(fn, &st), ret); > if (ret == 0) { > ret = ::unlink(fn); > if (ret == -1) { > > I'm not sure if this should be done for all BSD platforms. Could anybody > help confirm this? > > Thanks, > Kris > > (P.S. recovering from bad health...) > > [1]: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2e8f19c2feef > [2]: > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/stat64.2.html > From rednaxelafx at gmail.com Sun Jul 28 22:34:16 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 29 Jul 2013 13:34:16 +0800 Subject: Avoid using deprecated stat64 on Mac OS X In-Reply-To: <51F5FCA7.4090102@oracle.com> References: <51F5FCA7.4090102@oracle.com> Message-ID: Hi David, Thanks for taking a look. I'm not that familiar with other BSD variants, and I'm only encountering this on Mac OS X. Looking for help here. I think FreeBSD also uses the bsd-port in their downstream OpenJDK package. FreeBSD uses stat instead of stat64, too. Thanks, Kris On Mon, Jul 29, 2013 at 1:24 PM, David Holmes wrote: > Hi Kris, > > > On 28/07/2013 5:59 PM, Krystal Mok wrote: > >> Hi all, >> >> I'm building a freshly cloned repo from the tip of hotspot-comp on Mac OS >> X >> 10.7.5, and got and error: >> >> llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -I. >> -I/Users/rednaxelafx/build/**hotspot-comp/hotspot/src/**share/vm/prims >> -I/Users/rednaxelafx/build/**hotspot-comp/hotspot/src/**share/vm >> -I/Users/rednaxelafx/build/**hotspot-comp/hotspot/src/** >> share/vm/precompiled >> -I/Users/rednaxelafx/build/**hotspot-comp/hotspot/src/cpu/**x86/vm >> -I/Users/rednaxelafx/build/**hotspot-comp/hotspot/src/os_**cpu/bsd_x86/vm >> -I/Users/rednaxelafx/build/**hotspot-comp/hotspot/src/os/**bsd/vm >> -I/Users/rednaxelafx/build/**hotspot-comp/hotspot/src/os/**posix/vm >> -I../generated -DHOTSPOT_RELEASE_VERSION="\"**25.0-b44-internal\"" >> -DHOTSPOT_BUILD_TARGET="\"**fastdebug\"" >> -DHOTSPOT_BUILD_USER="\"**rednaxelafx\"" -DHOTSPOT_LIB_ARCH=\"amd64\" >> -DHOTSPOT_VM_DISTRO="\"**OpenJDK\"" -DTARGET_OS_FAMILY_bsd >> -DTARGET_ARCH_x86 >> -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 >> -DTARGET_OS_ARCH_MODEL_bsd_**x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 >> -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 >> -pipe -fno-strict-aliasing -DMAC_OS_X_VERSION_MAX_**ALLOWED=1070 >> -mmacosx-version-min=10.7.0 -Os -DVM_LITTLE_ENDIAN -D_LP64=1 >> -fno-omit-frame-pointer -Werror -Wunused-function -DDTRACE_ENABLED >> -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -DALLOW_OPERATOR_NEW_USAGE -c -MMD >> -MP >> -MF ../generated/dependencies/**attachListener_bsd.o.d -fpch-deps -o >> attachListener_bsd.o >> /Users/rednaxelafx/build/**hotspot-comp/hotspot/src/os/** >> bsd/vm/attachListener_bsd.cpp >> cc1plus: warnings being treated as errors >> /Users/rednaxelafx/build/**hotspot-comp/hotspot/src/os/** >> bsd/vm/attachListener_bsd.cpp: >> In static member function ?static void AttachListener::vm_start()?: >> /Users/rednaxelafx/build/**hotspot-comp/hotspot/src/os/** >> bsd/vm/attachListener_bsd.cpp:**455: >> warning: ?stat64? is deprecated (declared at /usr/include/sys/stat.h:466) >> /Users/rednaxelafx/build/**hotspot-comp/hotspot/src/os/** >> bsd/vm/attachListener_bsd.cpp:**455: >> warning: ?stat64? is deprecated (declared at /usr/include/sys/stat.h:466) >> make[6]: *** [attachListener_bsd.o] Error 1 >> >> The problem came from a recent commit [1]: >> 7162400: Intermittent java.io.IOException: Bad file number during >> HotSpotVirtualMachine.**executeCommand >> >> According to [2], the *-64 variants of the stat*() functions have been >> deprecated on Mac OS X and should be avoided. >> > > So is this purely an OSX issue or also a BSD one? I'm assuming OSX. > > Does anybody out there actually use the BSD port seperately from OSX? > > David > ----- > > > >> The fix is simple: >> diff -r d90d1b96b65b src/os/bsd/vm/attachListener_**bsd.cpp >> --- a/src/os/bsd/vm/**attachListener_bsd.cpp Fri Jul 26 12:37:39 2013 >> -0700 >> +++ b/src/os/bsd/vm/**attachListener_bsd.cpp Sun Jul 28 15:55:54 2013 >> +0800 >> @@ -445,14 +445,14 @@ >> >> void AttachListener::vm_start() { >> char fn[UNIX_PATH_MAX]; >> - struct stat64 st; >> + struct stat st; >> int ret; >> >> int n = snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d", >> os::get_temp_directory(), os::current_process_id()); >> assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow"); >> >> - RESTARTABLE(::stat64(fn, &st), ret); >> + RESTARTABLE(::stat(fn, &st), ret); >> if (ret == 0) { >> ret = ::unlink(fn); >> if (ret == -1) { >> >> I'm not sure if this should be done for all BSD platforms. Could anybody >> help confirm this? >> >> Thanks, >> Kris >> >> (P.S. recovering from bad health...) >> >> [1]: http://hg.openjdk.java.net/**hsx/hotspot-comp/hotspot/rev/** >> 2e8f19c2feef >> [2]: >> https://developer.apple.com/**library/mac/documentation/** >> Darwin/Reference/ManPages/**man2/stat64.2.html >> >> From david.holmes at oracle.com Sun Jul 28 22:57:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jul 2013 15:57:09 +1000 Subject: Avoid using deprecated stat64 on Mac OS X In-Reply-To: References: <51F5FCA7.4090102@oracle.com> Message-ID: <51F60435.5030408@oracle.com> On 29/07/2013 3:34 PM, Krystal Mok wrote: > Hi David, > > Thanks for taking a look. I'm not that familiar with other BSD variants, > and I'm only encountering this on Mac OS X. Looking for help here. I can only assume that the warning is new in 10.8 as we don't see it building on 10.7. And given we are about to enable building on 10.8 this is good to find now! I've filed 8021771. > I think FreeBSD also uses the bsd-port in their downstream OpenJDK > package. FreeBSD uses stat instead of stat64, too. We (ie whomever fixes this :) ) need to determine whether this can simply be changed or whether it needs to be ifdef'd on OSX. Thanks, David > Thanks, > Kris > > > On Mon, Jul 29, 2013 at 1:24 PM, David Holmes > wrote: > > Hi Kris, > > > On 28/07/2013 5:59 PM, Krystal Mok wrote: > > Hi all, > > I'm building a freshly cloned repo from the tip of hotspot-comp > on Mac OS X > 10.7.5, and got and error: > > llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -I. > -I/Users/rednaxelafx/build/__hotspot-comp/hotspot/src/__share/vm/prims > -I/Users/rednaxelafx/build/__hotspot-comp/hotspot/src/__share/vm > -I/Users/rednaxelafx/build/__hotspot-comp/hotspot/src/__share/vm/precompiled > -I/Users/rednaxelafx/build/__hotspot-comp/hotspot/src/cpu/__x86/vm > -I/Users/rednaxelafx/build/__hotspot-comp/hotspot/src/os___cpu/bsd_x86/vm > -I/Users/rednaxelafx/build/__hotspot-comp/hotspot/src/os/__bsd/vm > -I/Users/rednaxelafx/build/__hotspot-comp/hotspot/src/os/__posix/vm > -I../generated -DHOTSPOT_RELEASE_VERSION="\"__25.0-b44-internal\"" > -DHOTSPOT_BUILD_TARGET="\"__fastdebug\"" > -DHOTSPOT_BUILD_USER="\"__rednaxelafx\"" > -DHOTSPOT_LIB_ARCH=\"amd64\" > -DHOTSPOT_VM_DISTRO="\"__OpenJDK\"" -DTARGET_OS_FAMILY_bsd > -DTARGET_ARCH_x86 > -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 > -DTARGET_OS_ARCH_MODEL_bsd___x86_64 -DTARGET_COMPILER_gcc > -DCOMPILER2 > -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new > -m64 > -pipe -fno-strict-aliasing -DMAC_OS_X_VERSION_MAX___ALLOWED=1070 > -mmacosx-version-min=10.7.0 -Os -DVM_LITTLE_ENDIAN -D_LP64=1 > -fno-omit-frame-pointer -Werror -Wunused-function > -DDTRACE_ENABLED > -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -DALLOW_OPERATOR_NEW_USAGE > -c -MMD -MP > -MF ../generated/dependencies/__attachListener_bsd.o.d -fpch-deps -o > attachListener_bsd.o > /Users/rednaxelafx/build/__hotspot-comp/hotspot/src/os/__bsd/vm/attachListener_bsd.cpp > cc1plus: warnings being treated as errors > /Users/rednaxelafx/build/__hotspot-comp/hotspot/src/os/__bsd/vm/attachListener_bsd.cpp: > In static member function ?static void AttachListener::vm_start()?: > /Users/rednaxelafx/build/__hotspot-comp/hotspot/src/os/__bsd/vm/attachListener_bsd.cpp:__455: > warning: ?stat64? is deprecated (declared at > /usr/include/sys/stat.h:466) > /Users/rednaxelafx/build/__hotspot-comp/hotspot/src/os/__bsd/vm/attachListener_bsd.cpp:__455: > warning: ?stat64? is deprecated (declared at > /usr/include/sys/stat.h:466) > make[6]: *** [attachListener_bsd.o] Error 1 > > The problem came from a recent commit [1]: > 7162400: Intermittent java.io.IOException: Bad file number during > HotSpotVirtualMachine.__executeCommand > > According to [2], the *-64 variants of the stat*() functions > have been > deprecated on Mac OS X and should be avoided. > > > So is this purely an OSX issue or also a BSD one? I'm assuming OSX. > > Does anybody out there actually use the BSD port seperately from OSX? > > David > ----- > > > > The fix is simple: > diff -r d90d1b96b65b src/os/bsd/vm/attachListener___bsd.cpp > --- a/src/os/bsd/vm/__attachListener_bsd.cpp Fri Jul 26 12:37:39 > 2013 -0700 > +++ b/src/os/bsd/vm/__attachListener_bsd.cpp Sun Jul 28 15:55:54 > 2013 +0800 > @@ -445,14 +445,14 @@ > > void AttachListener::vm_start() { > char fn[UNIX_PATH_MAX]; > - struct stat64 st; > + struct stat st; > int ret; > > int n = snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d", > os::get_temp_directory(), os::current_process_id()); > assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer > overflow"); > > - RESTARTABLE(::stat64(fn, &st), ret); > + RESTARTABLE(::stat(fn, &st), ret); > if (ret == 0) { > ret = ::unlink(fn); > if (ret == -1) { > > I'm not sure if this should be done for all BSD platforms. Could > anybody > help confirm this? > > Thanks, > Kris > > (P.S. recovering from bad health...) > > [1]: > http://hg.openjdk.java.net/__hsx/hotspot-comp/hotspot/rev/__2e8f19c2feef > > [2]: > https://developer.apple.com/__library/mac/documentation/__Darwin/Reference/ManPages/__man2/stat64.2.html > > > From rednaxelafx at gmail.com Sun Jul 28 23:02:04 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 29 Jul 2013 14:02:04 +0800 Subject: Avoid using deprecated stat64 on Mac OS X In-Reply-To: <51F60435.5030408@oracle.com> References: <51F5FCA7.4090102@oracle.com> <51F60435.5030408@oracle.com> Message-ID: Thank you very much, David. By the way, my build environment that had this problem was: Mac OS X 10.7.5, XCode 4.1 i686-apple-darwin11-llvm-g++-4.2 - Kris On Mon, Jul 29, 2013 at 1:57 PM, David Holmes wrote: > On 29/07/2013 3:34 PM, Krystal Mok wrote: > >> Hi David, >> >> Thanks for taking a look. I'm not that familiar with other BSD variants, >> and I'm only encountering this on Mac OS X. Looking for help here. >> > > I can only assume that the warning is new in 10.8 as we don't see it > building on 10.7. And given we are about to enable building on 10.8 this is > good to find now! I've filed 8021771. > > > I think FreeBSD also uses the bsd-port in their downstream OpenJDK >> package. FreeBSD uses stat instead of stat64, too. >> > > We (ie whomever fixes this :) ) need to determine whether this can simply > be changed or whether it needs to be ifdef'd on OSX. > > Thanks, > David > > Thanks, >> Kris >> >> >> On Mon, Jul 29, 2013 at 1:24 PM, David Holmes > >> wrote: >> >> Hi Kris, >> >> >> On 28/07/2013 5:59 PM, Krystal Mok wrote: >> >> Hi all, >> >> I'm building a freshly cloned repo from the tip of hotspot-comp >> on Mac OS X >> 10.7.5, and got and error: >> >> llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -I. >> -I/Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/__** >> share/vm/prims >> -I/Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/__** >> share/vm >> -I/Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/__** >> share/vm/precompiled >> -I/Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/cpu/_** >> _x86/vm >> -I/Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/os___** >> cpu/bsd_x86/vm >> -I/Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/os/__** >> bsd/vm >> -I/Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/os/__** >> posix/vm >> -I../generated -DHOTSPOT_RELEASE_VERSION="\"_** >> _25.0-b44-internal\"" >> -DHOTSPOT_BUILD_TARGET="\"__**fastdebug\"" >> -DHOTSPOT_BUILD_USER="\"__**rednaxelafx\"" >> -DHOTSPOT_LIB_ARCH=\"amd64\" >> -DHOTSPOT_VM_DISTRO="\"__**OpenJDK\"" -DTARGET_OS_FAMILY_bsd >> -DTARGET_ARCH_x86 >> -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 >> -DTARGET_OS_ARCH_MODEL_bsd___**x86_64 -DTARGET_COMPILER_gcc >> >> -DCOMPILER2 >> -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new >> -m64 >> -pipe -fno-strict-aliasing -DMAC_OS_X_VERSION_MAX___** >> ALLOWED=1070 >> >> -mmacosx-version-min=10.7.0 -Os -DVM_LITTLE_ENDIAN -D_LP64=1 >> -fno-omit-frame-pointer -Werror -Wunused-function >> -DDTRACE_ENABLED >> -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -DALLOW_OPERATOR_NEW_USAGE >> -c -MMD -MP >> -MF ../generated/dependencies/__**attachListener_bsd.o.d >> -fpch-deps -o >> attachListener_bsd.o >> /Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/os/__** >> bsd/vm/attachListener_bsd.cpp >> >> cc1plus: warnings being treated as errors >> /Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/os/__** >> bsd/vm/attachListener_bsd.cpp: >> >> In static member function ?static void >> AttachListener::vm_start()?: >> /Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/os/__** >> bsd/vm/attachListener_bsd.cpp:**__455: >> >> warning: ?stat64? is deprecated (declared at >> /usr/include/sys/stat.h:466) >> /Users/rednaxelafx/build/__**hotspot-comp/hotspot/src/os/__** >> bsd/vm/attachListener_bsd.cpp:**__455: >> >> warning: ?stat64? is deprecated (declared at >> /usr/include/sys/stat.h:466) >> make[6]: *** [attachListener_bsd.o] Error 1 >> >> The problem came from a recent commit [1]: >> 7162400: Intermittent java.io.IOException: Bad file number during >> HotSpotVirtualMachine.__**executeCommand >> >> >> According to [2], the *-64 variants of the stat*() functions >> have been >> deprecated on Mac OS X and should be avoided. >> >> >> So is this purely an OSX issue or also a BSD one? I'm assuming OSX. >> >> Does anybody out there actually use the BSD port seperately from OSX? >> >> David >> ----- >> >> >> >> The fix is simple: >> diff -r d90d1b96b65b src/os/bsd/vm/attachListener__**_bsd.cpp >> --- a/src/os/bsd/vm/__**attachListener_bsd.cpp Fri Jul 26 >> 12:37:39 >> 2013 -0700 >> +++ b/src/os/bsd/vm/__**attachListener_bsd.cpp Sun Jul 28 >> 15:55:54 >> >> 2013 +0800 >> @@ -445,14 +445,14 @@ >> >> void AttachListener::vm_start() { >> char fn[UNIX_PATH_MAX]; >> - struct stat64 st; >> + struct stat st; >> int ret; >> >> int n = snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d", >> os::get_temp_directory(), os::current_process_id()); >> assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer >> overflow"); >> >> - RESTARTABLE(::stat64(fn, &st), ret); >> + RESTARTABLE(::stat(fn, &st), ret); >> if (ret == 0) { >> ret = ::unlink(fn); >> if (ret == -1) { >> >> I'm not sure if this should be done for all BSD platforms. Could >> anybody >> help confirm this? >> >> Thanks, >> Kris >> >> (P.S. recovering from bad health...) >> >> [1]: >> http://hg.openjdk.java.net/__**hsx/hotspot-comp/hotspot/rev/_** >> _2e8f19c2feef >> > 2e8f19c2feef >> > >> [2]: >> https://developer.apple.com/__**library/mac/documentation/__** >> Darwin/Reference/ManPages/__**man2/stat64.2.html >> > Darwin/Reference/ManPages/**man2/stat64.2.html >> > >> >> >> From david.holmes at oracle.com Sun Jul 28 23:10:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jul 2013 16:10:25 +1000 Subject: Avoid using deprecated stat64 on Mac OS X In-Reply-To: References: <51F5FCA7.4090102@oracle.com> <51F60435.5030408@oracle.com> Message-ID: <51F60751.9050302@oracle.com> On 29/07/2013 4:02 PM, Krystal Mok wrote: > Thank you very much, David. > > By the way, my build environment that had this problem was: > Mac OS X 10.7.5, > XCode 4.1 > i686-apple-darwin11-llvm-g++-4.2 Ooops - thanks. David > - Kris > > > On Mon, Jul 29, 2013 at 1:57 PM, David Holmes > wrote: > > On 29/07/2013 3:34 PM, Krystal Mok wrote: > > Hi David, > > Thanks for taking a look. I'm not that familiar with other BSD > variants, > and I'm only encountering this on Mac OS X. Looking for help here. > > > I can only assume that the warning is new in 10.8 as we don't see it > building on 10.7. And given we are about to enable building on 10.8 > this is good to find now! I've filed 8021771. > > > I think FreeBSD also uses the bsd-port in their downstream OpenJDK > package. FreeBSD uses stat instead of stat64, too. > > > We (ie whomever fixes this :) ) need to determine whether this can > simply be changed or whether it needs to be ifdef'd on OSX. > > Thanks, > David > > Thanks, > Kris > > > On Mon, Jul 29, 2013 at 1:24 PM, David Holmes > > >> wrote: > > Hi Kris, > > > On 28/07/2013 5:59 PM, Krystal Mok wrote: > > Hi all, > > I'm building a freshly cloned repo from the tip of > hotspot-comp > on Mac OS X > 10.7.5, and got and error: > > llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > -DASSERT -I. > > -I/Users/rednaxelafx/build/____hotspot-comp/hotspot/src/____share/vm/prims > > -I/Users/rednaxelafx/build/____hotspot-comp/hotspot/src/____share/vm > > -I/Users/rednaxelafx/build/____hotspot-comp/hotspot/src/____share/vm/precompiled > > -I/Users/rednaxelafx/build/____hotspot-comp/hotspot/src/cpu/____x86/vm > > -I/Users/rednaxelafx/build/____hotspot-comp/hotspot/src/os_____cpu/bsd_x86/vm > > -I/Users/rednaxelafx/build/____hotspot-comp/hotspot/src/os/____bsd/vm > > -I/Users/rednaxelafx/build/____hotspot-comp/hotspot/src/os/____posix/vm > -I../generated > -DHOTSPOT_RELEASE_VERSION="\"____25.0-b44-internal\"" > -DHOTSPOT_BUILD_TARGET="\"____fastdebug\"" > -DHOTSPOT_BUILD_USER="\"____rednaxelafx\"" > -DHOTSPOT_LIB_ARCH=\"amd64\" > -DHOTSPOT_VM_DISTRO="\"____OpenJDK\"" > -DTARGET_OS_FAMILY_bsd > -DTARGET_ARCH_x86 > -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 > -DTARGET_OS_ARCH_MODEL_bsd_____x86_64 -DTARGET_COMPILER_gcc > > -DCOMPILER2 > -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread > -fcheck-new > -m64 > -pipe -fno-strict-aliasing > -DMAC_OS_X_VERSION_MAX_____ALLOWED=1070 > > -mmacosx-version-min=10.7.0 -Os -DVM_LITTLE_ENDIAN > -D_LP64=1 > -fno-omit-frame-pointer -Werror -Wunused-function > -DDTRACE_ENABLED > -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE > -DALLOW_OPERATOR_NEW_USAGE > -c -MMD -MP > -MF > ../generated/dependencies/____attachListener_bsd.o.d -fpch-deps -o > attachListener_bsd.o > > /Users/rednaxelafx/build/____hotspot-comp/hotspot/src/os/____bsd/vm/attachListener_bsd.cpp > > cc1plus: warnings being treated as errors > > /Users/rednaxelafx/build/____hotspot-comp/hotspot/src/os/____bsd/vm/attachListener_bsd.cpp: > > In static member function ?static void > AttachListener::vm_start()?: > > /Users/rednaxelafx/build/____hotspot-comp/hotspot/src/os/____bsd/vm/attachListener_bsd.cpp:____455: > > warning: ?stat64? is deprecated (declared at > /usr/include/sys/stat.h:466) > > /Users/rednaxelafx/build/____hotspot-comp/hotspot/src/os/____bsd/vm/attachListener_bsd.cpp:____455: > > warning: ?stat64? is deprecated (declared at > /usr/include/sys/stat.h:466) > make[6]: *** [attachListener_bsd.o] Error 1 > > The problem came from a recent commit [1]: > 7162400: Intermittent java.io.IOException: Bad file > number during > HotSpotVirtualMachine.____executeCommand > > > According to [2], the *-64 variants of the stat*() > functions > have been > deprecated on Mac OS X and should be avoided. > > > So is this purely an OSX issue or also a BSD one? I'm > assuming OSX. > > Does anybody out there actually use the BSD port seperately > from OSX? > > David > ----- > > > > The fix is simple: > diff -r d90d1b96b65b > src/os/bsd/vm/attachListener_____bsd.cpp > --- a/src/os/bsd/vm/____attachListener_bsd.cpp Fri Jul > 26 12:37:39 > 2013 -0700 > +++ b/src/os/bsd/vm/____attachListener_bsd.cpp Sun Jul > 28 15:55:54 > > 2013 +0800 > @@ -445,14 +445,14 @@ > > void AttachListener::vm_start() { > char fn[UNIX_PATH_MAX]; > - struct stat64 st; > + struct stat st; > int ret; > > int n = snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d", > os::get_temp_directory(), > os::current_process_id()); > assert(n < (int)UNIX_PATH_MAX, "java_pid file name > buffer > overflow"); > > - RESTARTABLE(::stat64(fn, &st), ret); > + RESTARTABLE(::stat(fn, &st), ret); > if (ret == 0) { > ret = ::unlink(fn); > if (ret == -1) { > > I'm not sure if this should be done for all BSD > platforms. Could > anybody > help confirm this? > > Thanks, > Kris > > (P.S. recovering from bad health...) > > [1]: > http://hg.openjdk.java.net/____hsx/hotspot-comp/hotspot/rev/____2e8f19c2feef > > > > > [2]: > https://developer.apple.com/____library/mac/documentation/____Darwin/Reference/ManPages/____man2/stat64.2.html > > > > > > > From rednaxelafx at gmail.com Mon Jul 29 00:53:22 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 29 Jul 2013 15:53:22 +0800 Subject: SA: Various fixes to sa.js to make it work in JDK8 Message-ID: Hi all, Could I have a couple of reviews for this patch, please? https://gist.github.com/rednaxelafx/6102608 Switching the JavaScript engine from Rhino to Nashorn and the No PermGen project caused a few issues that stopped sa.js from working. This is a patch that tries to fix the issues that I've run into. I'll walkthrough the patch below: (line numbers refer to sajs.patch, not sa.js) Line 8-12: Since Nashorn implements ECMAScript 5.1, using JavaScript keywords as the property name in the "dot" syntax is not a problem anymore. So I'm un-commenting these lines. Line 20-42, 51-76: When implementing a JavaAdapter for SA ScriptObject, the __get__ function calls the __has__ function: this.__has__(name) which is working at the wrong level: __has__ is a special hook function, and cannot be called via "this" this way. It'll trigger the __call__ hook to find the "__has__" member, but the JavaAdapter here does not override __call__, and then the lookup will fail. Rather than going through the trouble of implementing the __call__ hook just for this purpose, I move the __has__ function up, and made __get__ call __has__ directly instead. Now it won't trigger the __call__ hook for the lookup, the things will work fine again. Line 45-48: Removed trailing whitespace. Line 84-85: This code used to work in Rhino, but apparently Nashorn doesn't automatically convert a JavaScript Array into a Java array when doing JS-to-Java interop, so this conversion has to be done manually. Line 93-104: I'm a little confused in this part. Nashorn exposes a "print" function that's defined in jdk/nashorn/api/scripting/resources/engine.js, and that it doesn't expose a corresponding "println" function. I'm not sure if this code really worked when using Rhino...anyway, the "println" function is missing, so "writeln = println" doesn't do anything useful. I'm adding a shim here just in case either of "print" or "println" functions are missing. This fixes an error when calling "println" in line 87 of this patch. Line 113: This is the same change as purposed by Yunda back in April. [1] A missing fix from the NPG changes. Line 121-122, 129-130: When specifying a method overload in Nashorn, the argument syntax it takes for inner classes uses "." as the separator between the enclosing class name and the inner class name, instead of "$" as in the "binary name". Line 138-144, 152-160: Nashorn has stricter default behaviors than Rhino when overriding Java methods. Where as Rhino defaults to a "do nothing" implementation, Nashorn defaults to throwing UnsupportedOperationException for unimplemented methods. Line 168-172: Before the fix, this code only replace the first occurrence of the specified special characters, which happens to be not enough for newer HotSpot types in C++ templates. That's all for this patch. BTW, there is another patches pending review, too: JDK-8011979 [2] Thanks, Kris [1]: http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-April/009043.html [2]: http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-April/009149.html From serguei.spitsyn at oracle.com Mon Jul 29 09:51:53 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Jul 2013 09:51:53 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F5EB62.4050002@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> Message-ID: <51F69DA9.4030304@oracle.com> Hi David, Nice catch! I moved the fragment from another file and forgot to remove the #if. Thanks! Serguei On 7/28/13 9:11 PM, David Holmes wrote: > Hi Serguei, > > On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >> >> Please, review the fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >> > > In the templateInterpreter code why did you put this guard on your new > code (from x86_32 version): > > 1923 #if INCLUDE_JVMTI > > when the whole chunk of code this is situated in is specifically for > JVMTI support > > 1824 // > 1825 // JVMTI PopFrame support > 1826 // > > ??? > > David > ----- > >> >> Summary: >> Restore the appendix argument of a polymorphic intrinsic call >> needed for a invokestatic re-execution after JVMTI PopFrame(). >> >> Description >> When JVMTI's PopFrame removes a frame that was called via a call site >> that >> takes an appendix and that call site is reexecuted the appendix is >> not on >> the stack anymore because it got removed by the adapter. >> This fix is to detect such a case and push the appendix on the stack >> again before reexecution. >> >> >> Testing: >> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >> nsk.jdi.testlist >> >> Thanks, >> Serguei From serguei.spitsyn at oracle.com Mon Jul 29 17:34:08 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Jul 2013 17:34:08 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F5EB62.4050002@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> Message-ID: <51F70A00.7010505@oracle.com> Christian and David, Thank you for the quick review and comments! This is a new version of webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 Thanks, Serguei On 7/28/13 9:11 PM, David Holmes wrote: > Hi Serguei, > > On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >> >> Please, review the fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >> > > In the templateInterpreter code why did you put this guard on your new > code (from x86_32 version): > > 1923 #if INCLUDE_JVMTI > > when the whole chunk of code this is situated in is specifically for > JVMTI support > > 1824 // > 1825 // JVMTI PopFrame support > 1826 // > > ??? > > David > ----- > >> >> Summary: >> Restore the appendix argument of a polymorphic intrinsic call >> needed for a invokestatic re-execution after JVMTI PopFrame(). >> >> Description >> When JVMTI's PopFrame removes a frame that was called via a call site >> that >> takes an appendix and that call site is reexecuted the appendix is >> not on >> the stack anymore because it got removed by the adapter. >> This fix is to detect such a case and push the appendix on the stack >> again before reexecution. >> >> >> Testing: >> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >> nsk.jdi.testlist >> >> Thanks, >> Serguei From david.holmes at oracle.com Mon Jul 29 20:22:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jul 2013 13:22:36 +1000 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F70A00.7010505@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> Message-ID: <51F7317C.5030400@oracle.com> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: > Christian and David, > > Thank you for the quick review and comments! > > This is a new version of webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 Sorry. You need that guard after all - at least you do if you continue to use it in interpreterRuntime - otherwise member_name_arg_or_null will not exist: __ call_VM(rax, CAST_FROM_FN_PTR(address, InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); I'm a little surprised that the assembly code does not have that whole section guarded with INCLUDE_JVMTI - perhaps it should? Run this through a JPRT test build for productEmb to check that the minimal VM builds ok. David ----- > > Thanks, > Serguei > > > On 7/28/13 9:11 PM, David Holmes wrote: >> Hi Serguei, >> >> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Please, review the fix for: >>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>> >> >> In the templateInterpreter code why did you put this guard on your new >> code (from x86_32 version): >> >> 1923 #if INCLUDE_JVMTI >> >> when the whole chunk of code this is situated in is specifically for >> JVMTI support >> >> 1824 // >> 1825 // JVMTI PopFrame support >> 1826 // >> >> ??? >> >> David >> ----- >> >>> >>> Summary: >>> Restore the appendix argument of a polymorphic intrinsic call >>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>> >>> Description >>> When JVMTI's PopFrame removes a frame that was called via a call site >>> that >>> takes an appendix and that call site is reexecuted the appendix is >>> not on >>> the stack anymore because it got removed by the adapter. >>> This fix is to detect such a case and push the appendix on the stack >>> again before reexecution. >>> >>> >>> Testing: >>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>> nsk.jdi.testlist >>> >>> Thanks, >>> Serguei > From serguei.spitsyn at oracle.com Mon Jul 29 22:05:09 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Jul 2013 22:05:09 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F7317C.5030400@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> Message-ID: <51F74985.6070905@oracle.com> On 7/29/13 8:22 PM, David Holmes wrote: > On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >> Christian and David, >> >> Thank you for the quick review and comments! >> >> This is a new version of webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >> > > Sorry. You need that guard after all - at least you do if you continue > to use it in interpreterRuntime - otherwise member_name_arg_or_null > will not exist: > > __ call_VM(rax, CAST_FROM_FN_PTR(address, > InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); > You are right, nice catch again. Probably, it was the reason, I did not remove the #if/#endif in the first place. :) > I'm a little surprised that the assembly code does not have that whole > section guarded with INCLUDE_JVMTI - perhaps it should? It should. But it can be non-trivial because of other dependencies like the above. To make it right, both _remove_activation_preserving_args_entry and generate_earlyret_entry_for must be isolated with #if INCLUDE_JVMTI. Then more files have to be involved in this chain of changes: interpreter/templateInterpreter.hpp interpreter/templateInterpreter.hpp memory/universe.hpp memory/universe.cpp code/codeCache.hpp code/codeCache.cpp . . . etc .. Please, note, that the HOTSWAP macro is used in many places as well. I'm not sure we still need it, so that another decision is needed for it. So, it seems that this kind of clean up is going far beyond my fix. My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 platform-dependent files as it was in the webrev v1. I'm a little bit reluctant to open another clean-up bug for this issue but maybe it is needed. Please, let me know if you are comfortable with this solution. Thanks, Serguei > > Run this through a JPRT test build for productEmb to check that the > minimal VM builds ok. > > David > ----- > >> >> Thanks, >> Serguei >> >> >> On 7/28/13 9:11 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>> >>>> Please, review the fix for: >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>> >>>> >>> >>> In the templateInterpreter code why did you put this guard on your new >>> code (from x86_32 version): >>> >>> 1923 #if INCLUDE_JVMTI >>> >>> when the whole chunk of code this is situated in is specifically for >>> JVMTI support >>> >>> 1824 // >>> 1825 // JVMTI PopFrame support >>> 1826 // >>> >>> ??? >>> >>> David >>> ----- >>> >>>> >>>> Summary: >>>> Restore the appendix argument of a polymorphic intrinsic call >>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>> >>>> Description >>>> When JVMTI's PopFrame removes a frame that was called via a call >>>> site >>>> that >>>> takes an appendix and that call site is reexecuted the appendix is >>>> not on >>>> the stack anymore because it got removed by the adapter. >>>> This fix is to detect such a case and push the appendix on the >>>> stack >>>> again before reexecution. >>>> >>>> >>>> Testing: >>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>> nsk.jdi.testlist >>>> >>>> Thanks, >>>> Serguei >> From david.holmes at oracle.com Mon Jul 29 22:11:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jul 2013 15:11:05 +1000 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F74985.6070905@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> <51F74985.6070905@oracle.com> Message-ID: <51F74AE9.3050603@oracle.com> Hi Serguei, I'm fine with restoring to what was in the first webrev. Further trimming of the JVMTI code is something the embedded folk could look at. It may not be worthwhile. Thanks, David On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote: > On 7/29/13 8:22 PM, David Holmes wrote: >> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >>> Christian and David, >>> >>> Thank you for the quick review and comments! >>> >>> This is a new version of webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >>> >> >> Sorry. You need that guard after all - at least you do if you continue >> to use it in interpreterRuntime - otherwise member_name_arg_or_null >> will not exist: >> >> __ call_VM(rax, CAST_FROM_FN_PTR(address, >> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); >> > You are right, nice catch again. > Probably, it was the reason, I did not remove the #if/#endif in the > first place. :) > >> I'm a little surprised that the assembly code does not have that whole >> section guarded with INCLUDE_JVMTI - perhaps it should? > It should. > But it can be non-trivial because of other dependencies like the above. > To make it right, both _remove_activation_preserving_args_entry and > generate_earlyret_entry_for > must be isolated with #if INCLUDE_JVMTI. > Then more files have to be involved in this chain of changes: > interpreter/templateInterpreter.hpp > interpreter/templateInterpreter.hpp > memory/universe.hpp > memory/universe.cpp > code/codeCache.hpp > code/codeCache.cpp > . . . etc .. > > Please, note, that the HOTSWAP macro is used in many places as well. > I'm not sure we still need it, so that another decision is needed for it. > > So, it seems that this kind of clean up is going far beyond my fix. > My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 > platform-dependent files as it was in the webrev v1. > I'm a little bit reluctant to open another clean-up bug for this issue > but maybe it is needed. > Please, let me know if you are comfortable with this solution. > > Thanks, > Serguei > >> >> Run this through a JPRT test build for productEmb to check that the >> minimal VM builds ok. >> >> David >> ----- >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/28/13 9:11 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Please, review the fix for: >>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>>> >>>>> >>>> >>>> In the templateInterpreter code why did you put this guard on your new >>>> code (from x86_32 version): >>>> >>>> 1923 #if INCLUDE_JVMTI >>>> >>>> when the whole chunk of code this is situated in is specifically for >>>> JVMTI support >>>> >>>> 1824 // >>>> 1825 // JVMTI PopFrame support >>>> 1826 // >>>> >>>> ??? >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Summary: >>>>> Restore the appendix argument of a polymorphic intrinsic call >>>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>>> >>>>> Description >>>>> When JVMTI's PopFrame removes a frame that was called via a call >>>>> site >>>>> that >>>>> takes an appendix and that call site is reexecuted the appendix is >>>>> not on >>>>> the stack anymore because it got removed by the adapter. >>>>> This fix is to detect such a case and push the appendix on the >>>>> stack >>>>> again before reexecution. >>>>> >>>>> >>>>> Testing: >>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>>> nsk.jdi.testlist >>>>> >>>>> Thanks, >>>>> Serguei >>> > From serguei.spitsyn at oracle.com Tue Jul 30 02:33:34 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Jul 2013 02:33:34 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F74AE9.3050603@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> <51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com> Message-ID: <51F7886E.4090706@oracle.com> Thanks, David! >Run this through a JPRT test build for productEmb to check that the minimal VM builds ok. Yes, I'll test it with a JPRT test build. Thanks, Serguei On 7/29/13 10:11 PM, David Holmes wrote: > Hi Serguei, > > I'm fine with restoring to what was in the first webrev. > > Further trimming of the JVMTI code is something the embedded folk > could look at. It may not be worthwhile. > > Thanks, > David > > On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote: >> On 7/29/13 8:22 PM, David Holmes wrote: >>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >>>> Christian and David, >>>> >>>> Thank you for the quick review and comments! >>>> >>>> This is a new version of webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >>>> >>>> >>> >>> Sorry. You need that guard after all - at least you do if you continue >>> to use it in interpreterRuntime - otherwise member_name_arg_or_null >>> will not exist: >>> >>> __ call_VM(rax, CAST_FROM_FN_PTR(address, >>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); >>> >> You are right, nice catch again. >> Probably, it was the reason, I did not remove the #if/#endif in the >> first place. :) >> >>> I'm a little surprised that the assembly code does not have that whole >>> section guarded with INCLUDE_JVMTI - perhaps it should? >> It should. >> But it can be non-trivial because of other dependencies like the above. >> To make it right, both _remove_activation_preserving_args_entry and >> generate_earlyret_entry_for >> must be isolated with #if INCLUDE_JVMTI. >> Then more files have to be involved in this chain of changes: >> interpreter/templateInterpreter.hpp >> interpreter/templateInterpreter.hpp >> memory/universe.hpp >> memory/universe.cpp >> code/codeCache.hpp >> code/codeCache.cpp >> . . . etc .. >> >> Please, note, that the HOTSWAP macro is used in many places as well. >> I'm not sure we still need it, so that another decision is needed for >> it. >> >> So, it seems that this kind of clean up is going far beyond my fix. >> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 >> platform-dependent files as it was in the webrev v1. >> I'm a little bit reluctant to open another clean-up bug for this issue >> but maybe it is needed. >> Please, let me know if you are comfortable with this solution. >> >> Thanks, >> Serguei >> >>> >>> Run this through a JPRT test build for productEmb to check that the >>> minimal VM builds ok. >>> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 7/28/13 9:11 PM, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>> Please, review the fix for: >>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>>>> >>>>>> >>>>>> >>>>> >>>>> In the templateInterpreter code why did you put this guard on your >>>>> new >>>>> code (from x86_32 version): >>>>> >>>>> 1923 #if INCLUDE_JVMTI >>>>> >>>>> when the whole chunk of code this is situated in is specifically for >>>>> JVMTI support >>>>> >>>>> 1824 // >>>>> 1825 // JVMTI PopFrame support >>>>> 1826 // >>>>> >>>>> ??? >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Summary: >>>>>> Restore the appendix argument of a polymorphic intrinsic call >>>>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>>>> >>>>>> Description >>>>>> When JVMTI's PopFrame removes a frame that was called via a call >>>>>> site >>>>>> that >>>>>> takes an appendix and that call site is reexecuted the >>>>>> appendix is >>>>>> not on >>>>>> the stack anymore because it got removed by the adapter. >>>>>> This fix is to detect such a case and push the appendix on the >>>>>> stack >>>>>> again before reexecution. >>>>>> >>>>>> >>>>>> Testing: >>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>>>> nsk.jdi.testlist >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >> From serguei.spitsyn at oracle.com Tue Jul 30 10:00:46 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Jul 2013 10:00:46 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F74AE9.3050603@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> <51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com> Message-ID: <51F7F13E.8040104@oracle.com> The updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/ Thanks, Serguei On 7/29/13 10:11 PM, David Holmes wrote: > Hi Serguei, > > I'm fine with restoring to what was in the first webrev. > > Further trimming of the JVMTI code is something the embedded folk > could look at. It may not be worthwhile. > > Thanks, > David > > On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote: >> On 7/29/13 8:22 PM, David Holmes wrote: >>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >>>> Christian and David, >>>> >>>> Thank you for the quick review and comments! >>>> >>>> This is a new version of webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >>>> >>>> >>> >>> Sorry. You need that guard after all - at least you do if you continue >>> to use it in interpreterRuntime - otherwise member_name_arg_or_null >>> will not exist: >>> >>> __ call_VM(rax, CAST_FROM_FN_PTR(address, >>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); >>> >> You are right, nice catch again. >> Probably, it was the reason, I did not remove the #if/#endif in the >> first place. :) >> >>> I'm a little surprised that the assembly code does not have that whole >>> section guarded with INCLUDE_JVMTI - perhaps it should? >> It should. >> But it can be non-trivial because of other dependencies like the above. >> To make it right, both _remove_activation_preserving_args_entry and >> generate_earlyret_entry_for >> must be isolated with #if INCLUDE_JVMTI. >> Then more files have to be involved in this chain of changes: >> interpreter/templateInterpreter.hpp >> interpreter/templateInterpreter.hpp >> memory/universe.hpp >> memory/universe.cpp >> code/codeCache.hpp >> code/codeCache.cpp >> . . . etc .. >> >> Please, note, that the HOTSWAP macro is used in many places as well. >> I'm not sure we still need it, so that another decision is needed for >> it. >> >> So, it seems that this kind of clean up is going far beyond my fix. >> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 >> platform-dependent files as it was in the webrev v1. >> I'm a little bit reluctant to open another clean-up bug for this issue >> but maybe it is needed. >> Please, let me know if you are comfortable with this solution. >> >> Thanks, >> Serguei >> >>> >>> Run this through a JPRT test build for productEmb to check that the >>> minimal VM builds ok. >>> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 7/28/13 9:11 PM, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>> Please, review the fix for: >>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>>>> >>>>>> >>>>>> >>>>> >>>>> In the templateInterpreter code why did you put this guard on your >>>>> new >>>>> code (from x86_32 version): >>>>> >>>>> 1923 #if INCLUDE_JVMTI >>>>> >>>>> when the whole chunk of code this is situated in is specifically for >>>>> JVMTI support >>>>> >>>>> 1824 // >>>>> 1825 // JVMTI PopFrame support >>>>> 1826 // >>>>> >>>>> ??? >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Summary: >>>>>> Restore the appendix argument of a polymorphic intrinsic call >>>>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>>>> >>>>>> Description >>>>>> When JVMTI's PopFrame removes a frame that was called via a call >>>>>> site >>>>>> that >>>>>> takes an appendix and that call site is reexecuted the >>>>>> appendix is >>>>>> not on >>>>>> the stack anymore because it got removed by the adapter. >>>>>> This fix is to detect such a case and push the appendix on the >>>>>> stack >>>>>> again before reexecution. >>>>>> >>>>>> >>>>>> Testing: >>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>>>> nsk.jdi.testlist >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >> From bill.pittore at oracle.com Tue Jul 30 12:17:31 2013 From: bill.pittore at oracle.com (bill.pittore at oracle.com) Date: Tue, 30 Jul 2013 15:17:31 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51F23AC7.9050004@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> Message-ID: <51F8114B.2040302@oracle.com> Thanks Serguei for the comments. Some comments inline. I updated the webrevs at http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: > Hi Bill, > > Sorry for the big delay. > > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ > > > src/share/classes/com/sun/tools/attach/VirtualMachine.java: > > > I'm suggesting to use the reference > *Agent_OnAttach[_L]**||* even more consistently. > (If, in some cases, you prefer the longer form to underline the > difference between > dynamically and statically linked libraries then feel free to leave > it as it is.) > > It would simplify the following fragments: > > 304 * It then causes the target VM to invoke the Agent_OnAttach function > 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function > ==> > > 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function > > 409 * It then causes the target VM to invoke the Agent_OnAttach > 410 * function or, for a statically linked agent named 'L', the > 411 * Agent_OnAttach_L function as specified in the > ==> > 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] > 410 * function as specified in the > I left the above as is since it's part of the method description. The following fragments below I simplified as you suggested. > > the following 4 identical fragments: > > 341 * If the Agent_OnAttach function returns an error > 342 * or, for a statically linked agent named 'L', if the > 343 * Agent_OnAttach_L function returns > 344 * an error. > 375 * If the Agent_OnAttach function returns an error > 376 * or, for a statically linked agent named 'L', if the > 377 * Agent_OnAttach_L function returns > 378 * an error. > 442 * If the Agent_OnAttach function returns an error > 443 * or, for a statically linked agent named 'L', if the > 444 * Agent_OnAttach_L function returns an error > 475 * If the Agent_OnAttach function returns an error > 476 * or, for a statically linked agent named 'L', if the > 477 * Agent_OnAttach_L function returns > 478 * an error. > ==> > > 336 * If the Agent_OnAttach[_L] function > returns an error. > > > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ > > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html > src/share/vm/prims/jvmti.xml > > Lines 442-462: many extra

's. The fragment does not look well. > I'd suggest to remove most of them. > Also, these lines are too long. Could you make them shorter, please? > The same is applied to other long new lines in this file. Cleaned this up a bit. > > Lines 490-491, 502-503, 505-506: > The same sentence is repeated 3 times: "the agent library may be > statically linked ..." > > 490 Note that the agent library may be statically linked into the > executable > 491 in which case no actual loading takes place. Fixed. > > 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, > the VM will attempt to > 502 load the shared library c:\myLibs\foo.dll. > As mentioned above, the agent library may be statically linked into > the executable > 503 in which case no actual loading takes place > > 505 Note that the agent library may be statically linked into the > executable > 506 in which case no actual loading takes place. > Tweaked the above a bit to make it less wordy. > Lines 677-678: The dot is missed at the end of line 677: > > 677 and enabled the event > Fixed. > > src/os/posix/vm/os_posix.cpp > > - no comments > > src/os/windows/vm/os_windows.cpp > > - no comments > > src/share/vm/prims/jvmtiExport.cpp > > - no comments > > src/share/vm/runtime/arguments.hpp > > - no comments > > src/share/vm/runtime/os.cpp > > Space is missed after the 'if': > 471 if(entryName != NULL) { > Fixed. > Extra space after the '*': > 483 void * saveHandle; > Fixed. > src/share/vm/runtime/os.hpp > > - no comments > > src/share/vm/runtime/thread.cpp > > The line has been removed: > 3866 break; > Correct, the inner for loop was removed so no need for the break; > > I'm still in process of reading the code. > Another pass is needed to make sure that nothing is missed. > But in general, the code quality is pretty good. > > Thanks, > Serguei > > > > On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >> Still need an official reviewer for the hotspot changes for >> statically linked agents. >> >> thanks, >> bill >> >>> These changes address bug 8014135 which adds support for statically >>> linked agents in the VM. This is a followup to the recent JNI spec >>> changes that addressed statically linked JNI libraries( 8005716). >>> The JEP for this change is the same JEP as the JNI changes: >>> http://openjdk.java.net/jeps/178 >>> >>> Webrevs are here: >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>> >>> The changes to jvmti.xml can also be seen in the output file that I >>> placed here: >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>> >>> >>> Thanks, >>> bill >>> >> > From rednaxelafx at gmail.com Wed Jul 31 07:11:57 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 31 Jul 2013 22:11:57 +0800 Subject: SA: Various fixes to sa.js to make it work in JDK8 In-Reply-To: References: Message-ID: Hi all, I've just learned that there's a bug number that's exactly what I was trying to fix with this patch: Bug 8011888: http://bugs.sun.com/view_bug.do?bug_id=8011888 If there's already a fix to this bug then I'm fine with it. Just like to see the fix in mainline tip so that CLHSDB would work out of the box again. Thanks, Kris On Mon, Jul 29, 2013 at 3:53 PM, Krystal Mok wrote: > Hi all, > > Could I have a couple of reviews for this patch, please? > > https://gist.github.com/rednaxelafx/6102608 > > Switching the JavaScript engine from Rhino to Nashorn and the No PermGen > project caused a few issues that stopped sa.js from working. This is a > patch that tries to fix the issues that I've run into. > > I'll walkthrough the patch below: (line numbers refer to sajs.patch, not > sa.js) > > Line 8-12: > > Since Nashorn implements ECMAScript 5.1, using JavaScript keywords as the > property name in the "dot" syntax is not a problem anymore. So I'm > un-commenting these lines. > > Line 20-42, 51-76: > > When implementing a JavaAdapter for SA ScriptObject, the __get__ function > calls the __has__ function: > this.__has__(name) > which is working at the wrong level: __has__ is a special hook function, > and cannot be called via "this" this way. It'll trigger the __call__ hook > to find the "__has__" member, but the JavaAdapter here does not override > __call__, and then the lookup will fail. > > Rather than going through the trouble of implementing the __call__ hook > just for this purpose, I move the __has__ function up, and made __get__ > call __has__ directly instead. Now it won't trigger the __call__ hook for > the lookup, the things will work fine again. > > Line 45-48: > > Removed trailing whitespace. > > Line 84-85: > > This code used to work in Rhino, but apparently Nashorn doesn't > automatically convert a JavaScript Array into a Java array when doing > JS-to-Java interop, so this conversion has to be done manually. > > Line 93-104: > > I'm a little confused in this part. Nashorn exposes a "print" function > that's defined in jdk/nashorn/api/scripting/resources/engine.js, and that > it doesn't expose a corresponding "println" function. I'm not sure if this > code really worked when using Rhino...anyway, the "println" function is > missing, so "writeln = println" doesn't do anything useful. I'm adding a > shim here just in case either of "print" or "println" functions are > missing. This fixes an error when calling "println" in line 87 of this > patch. > > Line 113: > > This is the same change as purposed by Yunda back in April. [1] A missing > fix from the NPG changes. > > Line 121-122, 129-130: > > When specifying a method overload in Nashorn, the argument syntax it takes > for inner classes uses "." as the separator between the enclosing class > name and the inner class name, instead of "$" as in the "binary name". > > Line 138-144, 152-160: > > Nashorn has stricter default behaviors than Rhino when overriding Java > methods. Where as Rhino defaults to a "do nothing" implementation, Nashorn > defaults to throwing UnsupportedOperationException for unimplemented > methods. > > Line 168-172: > > Before the fix, this code only replace the first occurrence of the > specified special characters, which happens to be not enough for newer > HotSpot types in C++ templates. > > That's all for this patch. > > BTW, there is another patches pending review, too: JDK-8011979 [2] > > Thanks, > Kris > > [1]: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-April/009043.html > [2]: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-April/009149.html > From frederic.parain at oracle.com Wed Jul 31 12:11:38 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 31 Jul 2013 19:11:38 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20130731191154.979FA484CA@hg.openjdk.java.net> Changeset: 1b6395189726 Author: minqi Date: 2013-07-19 14:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1b6395189726 8012263: ciReplay: gracefully exit & report meaningful error when replay data parsing fails Summary: find_method could return NULL so need explicitly check if there is error after parse_method, exit on error to avoid crash. Reviewed-by: kvn, twisti Contributed-by: yumin.qi at oracle.com ! src/share/vm/ci/ciReplay.cpp Changeset: 5ad7f8179bf7 Author: minqi Date: 2013-07-24 08:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ad7f8179bf7 Merge Changeset: b6baf306e698 Author: fparain Date: 2013-07-26 05:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b6baf306e698 Merge Changeset: 83ca9dc4564d Author: fparain Date: 2013-07-26 15:24 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/83ca9dc4564d 8019845: Memory leak during class redefinition Reviewed-by: acorn, jmasa, coleenp, dcubed, mgerdin ! src/share/vm/memory/metaspace.cpp Changeset: f9ee986a9fea Author: ccheung Date: 2013-07-30 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f9ee986a9fea 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases Summary: Added checking for gcc and simplified the sig_handler() in the test case Reviewed-by: dcubed, coleenp, minqi, dlong ! test/runtime/6929067/Test6929067.sh ! test/runtime/7107135/Test7107135.sh ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 0f98cc013b21 Author: fparain Date: 2013-07-31 08:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0f98cc013b21 Merge From david.holmes at oracle.com Wed Jul 31 18:03:15 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 01 Aug 2013 01:03:15 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20130801010324.6D10E484DE@hg.openjdk.java.net> Changeset: c65045599519 Author: dholmes Date: 2013-07-25 21:05 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c65045599519 8021314: minimal1.make needs to force off components not supported by the minimal VM Reviewed-by: coleenp, bpittore ! make/bsd/makefiles/minimal1.make ! make/linux/makefiles/minimal1.make Changeset: 078e5eb2e52e Author: clucasius Date: 2013-07-27 17:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/078e5eb2e52e Merge Changeset: da839a3c5735 Author: dholmes Date: 2013-07-31 19:05 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/da839a3c5735 Merge