From jaroslav.bachorik at oracle.com Wed Apr 1 08:56:29 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 01 Apr 2015 10:56:29 +0200 Subject: RFR 8076344: serviceability/dcmd/vm/SetVMFlagTest.java test fails with "java.lang.Error: 'MaxHeapSize' flag is not available or immutable" Message-ID: <551BB2BD.6030306@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8076344 Webrev: http://cr.openjdk.java.net/~jbachorik/8076344/webrev.00 Originally, the test used some well known flags to assert the correct functionality. I didn't expect eg. 'MaxHeapSize' flag to go away so quickly :) The solution is to pick whichever mutable/immutable flag of a certain type and carry on the test using this flag. This way the test will always use only the available flags. Thanks, -JB- From staffan.larsen at oracle.com Wed Apr 1 09:04:11 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 1 Apr 2015 11:04:11 +0200 Subject: RFR 8076344: serviceability/dcmd/vm/SetVMFlagTest.java test fails with "java.lang.Error: 'MaxHeapSize' flag is not available or immutable" In-Reply-To: <551BB2BD.6030306@oracle.com> References: <551BB2BD.6030306@oracle.com> Message-ID: Looks good! nit: L133: ?existeng? -> ?existing" Thanks, /Staffan > On 1 apr 2015, at 10:56, Jaroslav Bachorik wrote: > > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8076344 > Webrev: http://cr.openjdk.java.net/~jbachorik/8076344/webrev.00 > > Originally, the test used some well known flags to assert the correct functionality. I didn't expect eg. 'MaxHeapSize' flag to go away so quickly :) > > The solution is to pick whichever mutable/immutable flag of a certain type and carry on the test using this flag. This way the test will always use only the available flags. > > Thanks, > > -JB- From sgehwolf at redhat.com Wed Apr 1 12:26:31 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 01 Apr 2015 14:26:31 +0200 Subject: [8u60] RFR(xs): 8076460: Zero fastdebug build does not compile Message-ID: <1427891191.3876.38.camel@redhat.com> Hi, Could somebody please review and sponsor this change? It's a JDK 8u only issue. The Zero JVM variant fastdebug build does not compile. Product and slowdebug builds compile fine. JDK-9 does not have this issue and has received the same fixes, AFAIK. Bug: https://bugs.openjdk.java.net/browse/JDK-8076460 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076460/webrev.01/ Once approved, could somebody please push this to jdk8u? Thanks, Severin From bengt.rutisson at oracle.com Wed Apr 1 12:58:25 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 01 Apr 2015 14:58:25 +0200 Subject: RFR: 8075955: Replace the macro based implementation of oop_oop_iterate with a template based solution In-Reply-To: <5514354B.6060505@oracle.com> References: <5514354B.6060505@oracle.com> Message-ID: <551BEB71.6000506@oracle.com> Hi Stefan, We've looked through previous versions of this patch in quite some detail. I've browsed the latest webrev and as far as I can tell it looks good. Reviewed. Bengt On 2015-03-26 17:35, Stefan Karlsson wrote: > Hi, > > Please review this patch to replace the macro based implementation of > oop_oop_iterate with a template based solution. > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075955 > > Summary of the changes: > > - Replace the macro implementation of the different oop_oop_iterate > functions with template functions. The implementation is moved out > from the *Klass.cpp files into the *Klass.inline.hpp files, to be able > to generate the specialized oop_oop_iterate functions in suitable GC > specific files. > > See the old macro implementation: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.cpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html > > > That has now been converted into template functions: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.inline.hpp.html > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.inline.hpp.udiff.html > > > There's still a closure specialization layer implemented with macros > to support the code to allows the code to pass down the concrete > closure type, past the virtual Klass::oop_oop_iterate_nv(...) call. > The macros just calls the new template functions: > > 191 #define InstanceKlass_OOP_OOP_ITERATE_DEFN(OopClosureType, > nv_suffix) \ > 192 int InstanceKlass::oop_oop_iterate##nv_suffix(oop obj, > OopClosureType* closure) { \ > 193 return oop_oop_iterate(obj, > closure); \ > 194 } > > We might want to remove this in a future patch, by providing our own > dispatch mechanism. > > > - Split the generation of the specialized oop_oop_iterate definitions, > so that we keep code from different GCs separated. Before this patch, > code from all GCs were generated into instanceKlass.cpp, > instanceMirrorKlass.cpp, instanceClassLoaderKlass.cpp, > instanceRefKlass.cpp, typeArrayKlass.cpp, and objArrayKlass.cpp. > > Now the definitions are generated into: > G1: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/g1/g1OopClosures.cpp.udiff.html > CMS: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.cpp.html > ParNew: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.cpp.html > Serial: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/genOopClosures.cpp.html > > > - The other GCs don't use use the above mentioned closure > specialization, that is, they don't call obj->oop_iterate(&cl) to > follow the objects. Instead they have their own "visitor" functions > located in the oopDesc and *Klass classes. For example, Parallel > Scavenge calls obj->push_contents(...), which calls > Klass::oop_push_contents(...), to follow outgoing pointers after an > object has been moved. These visitor functions used to use the oop > iterate macros and pass down snippets of code to be applied to each > oop*. This has now been changed to use use closures and the new > oop_oop_iterate template functions. > > The implementation of these object visitor functions have been moved > out from the *Klass.cpp files and into the GCs that the functions > support. > > Using Parallel Scavenge as and example: > > The implementation to handle the references out of a copied object was > located in: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html > > > -void InstanceKlass::oop_push_contents(PSPromotionManager* pm, oop obj) { > - InstanceKlass_OOP_MAP_REVERSE_ITERATE( \ > - obj, \ > - if (PSScavenge::should_scavenge(p)) { \ > - pm->claim_or_forward_depth(p); \ > - }, \ > - assert_nothing ) > -} > > and has now been moved to: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html > > > +void InstanceKlass::oop_ps_push_contents(oop obj, PSPromotionManager* > pm) { > + PushContentsClosure cl(pm); > + oop_oop_iterate_oop_maps_reverse(obj, &cl); > +} > > where the do_oop function is implemented as: > + > + template void do_oop_nv(T* p) { > + if (PSScavenge::should_scavenge(p)) { > + _pm->claim_or_forward_depth(p); > + } > > From the same file, it can be seen how that the implementation to > follow the references in the mirrors are using the same closure: > > +void InstanceMirrorKlass::oop_ps_push_contents(oop obj, > PSPromotionManager* pm) { > ... > + InstanceKlass::oop_ps_push_contents(obj, pm); > + > + PushContentsClosure cl(pm); > + oop_oop_iterate_statics(obj, &cl); > +} > > As can be seen above, the functions are still members of the different > Klasses, but only the declaration is put in the klass.hpp files. The > actual implementation is put in the GC files. This helps decoupling > the different GCs and the Klasses. We could move the functions over to > a GC specific "visitor" and have a generic "accept" function in the > Klasses, but that approach would require two virtual calls, while the > current implementation only needs one. > > In the future we might want to remove these functions from the > *Klasses and reuse the already existing code in the oop_oop_iterate > framework. > > If we take the InstanceMirrorKlass::oop_ps_push_contents function > above as an example, it could be implemented with > InstanceMirrorKlass::oop_oop_iterate, since they share the same > structure: > > 54 template > 55 int InstanceMirrorKlass::oop_oop_iterate(oop obj, OopClosureType* > closure) { > 56 InstanceKlass::oop_oop_iterate(obj, closure); > 57 > 58 if (Devirtualizer::do_metadata(closure)) { > 59 Klass* klass = java_lang_Class::as_Klass(obj); > 60 // We'll get NULL for primitive mirrors. > 61 if (klass != NULL) { > 62 Devirtualizer::do_klass(closure, klass); > 63 } > 64 } > 65 > 66 oop_oop_iterate_statics(obj, closure); > 67 > 68 return oop_size(obj); > 69 } > > Parallel Scavenge doesn't visit the klass pointers and do_metadata > returns false, so that code path will be eliminated by the compiler. > We would have to do something about the return oop_size(obj), since we > don't want to do that unnecessarily. To change the GC object visitors > to entirely use the oop_oop_iterator framework is out of scope for > this patch. > > The object visitor functions were renamed and moved as follows: > oop_follow_contents(opp) -> oop_ms_follow_contents(oop) in markSweep.cpp > oop_adjust_pointers(oop) -> oop_ms_adjust_pointers(oop) in markSweep.cpp > oop_follow_contents(oop, ParCompactionManager*) -> > oop_pc_follow_contents(...) in psCompactionManager.cpp > oop_update_pointers(oop) -> oop_pc_update_pointers(oop) in > psParallelCompact.cpp > oop_push_contents(oop, PSPromotionManager*) -> > oop_ps_push_contents(...) in psPromotionManager.cpp > > > - The oop iterate macros used to take an assert parameter to be > applied to oop* that were visited. By default, the check was > assert_is_in_closed_subset, but MS, PS and PC provided their own > asserts. ExtendedOopClosure has been handed the task to provide the > default verification, but also a way to turn it off for individual > closures, so that they can provide their own asserts. See: > ExtendedOopClosure::verify() and > ExtendedOopClosure::should_verify_oops() and how the Devirtualizer > dispatch class calls the verification code: > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/iterator.inline.hpp.udiff.html > > > +template > +inline void Devirtualizer::do_oop(OopClosureType* closure, T* p) { > + debug_only(closure->verify(p)); > + closure->do_oop_nv(p); > +} > > > - Moved PSParallelCompact::MarkAndPushClosure::do_oop, > PSParallelCompact::AdjustPointerClosure::do_oop, mark_and_push, adjust > pointer, and follow_klass to psParallelCompact.inline.hpp > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html > > > > - Add seemingly incorrect includes between GCs. This is needed since > we currently have no separation between GCs when we generate the > oop_since_save_marks_iterate functions. See: > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/defNewGeneration.cpp.udiff.html > > > and the include of ParNew specific closures: > 51 #if INCLUDE_ALL_GCS > 52 #include "gc_implementation/parNew/parOopClosures.hpp" > 53 #endif > > which is needed to be able to generate: > 856 ALL_SINCE_SAVE_MARKS_CLOSURES(DefNew_SINCE_SAVE_MARKS_DEFN) > > This should be changed in a separate patch, so that DefNew only > generates oop_since_save_marks_iterate that takes DefNew specfic > closures. > > > The initial performance runs showed a slight increase of the GC times > on some benchmarks on Solaris and Windows. The reason for this > increase was that the these compilers didn't inline as much as the > hand-inlined macros used to do. To remedy this I've increased the > inlining in to ways: > > - Turned on extra inlining for psPromotionManager.cpp when compiling > with the Solaris Studio Compiler > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/make/solaris/makefiles/product.make.udiff.html > > > > - Added __forceinline to the InstanceKlass::oop_oop_iterate functions > when compiling with the MS compiler. > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html > > > > A previous version of this patch has been run through our testing, but > I've recently done changes and extracted smaller patches, so I'll have > to rerun all testing. > > Any requests for extra testing to be done? > > Thanks, > StefanK > From stefan.karlsson at oracle.com Wed Apr 1 13:11:47 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 01 Apr 2015 15:11:47 +0200 Subject: RFR: 8075955: Replace the macro based implementation of oop_oop_iterate with a template based solution In-Reply-To: <551BEB71.6000506@oracle.com> References: <5514354B.6060505@oracle.com> <551BEB71.6000506@oracle.com> Message-ID: <551BEE93.9020809@oracle.com> On 2015-04-01 14:58, Bengt Rutisson wrote: > > Hi Stefan, > > We've looked through previous versions of this patch in quite some > detail. I've browsed the latest webrev and as far as I can tell it > looks good. > > Reviewed. Thanks, Bengt! StefanK > > Bengt > > On 2015-03-26 17:35, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to replace the macro based implementation of >> oop_oop_iterate with a template based solution. >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075955 >> >> Summary of the changes: >> >> - Replace the macro implementation of the different oop_oop_iterate >> functions with template functions. The implementation is moved out >> from the *Klass.cpp files into the *Klass.inline.hpp files, to be >> able to generate the specialized oop_oop_iterate functions in >> suitable GC specific files. >> >> See the old macro implementation: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.cpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html >> >> >> That has now been converted into template functions: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceMirrorKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceRefKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/typeArrayKlass.inline.hpp.html >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/objArrayKlass.inline.hpp.udiff.html >> >> >> There's still a closure specialization layer implemented with macros >> to support the code to allows the code to pass down the concrete >> closure type, past the virtual Klass::oop_oop_iterate_nv(...) call. >> The macros just calls the new template functions: >> >> 191 #define InstanceKlass_OOP_OOP_ITERATE_DEFN(OopClosureType, >> nv_suffix) \ >> 192 int InstanceKlass::oop_oop_iterate##nv_suffix(oop obj, >> OopClosureType* closure) { \ >> 193 return oop_oop_iterate(obj, >> closure); \ >> 194 } >> >> We might want to remove this in a future patch, by providing our own >> dispatch mechanism. >> >> >> - Split the generation of the specialized oop_oop_iterate >> definitions, so that we keep code from different GCs separated. >> Before this patch, code from all GCs were generated into >> instanceKlass.cpp, instanceMirrorKlass.cpp, >> instanceClassLoaderKlass.cpp, instanceRefKlass.cpp, >> typeArrayKlass.cpp, and objArrayKlass.cpp. >> >> Now the definitions are generated into: >> G1: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/g1/g1OopClosures.cpp.udiff.html >> CMS: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.cpp.html >> ParNew: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.cpp.html >> Serial: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/genOopClosures.cpp.html >> >> >> - The other GCs don't use use the above mentioned closure >> specialization, that is, they don't call obj->oop_iterate(&cl) to >> follow the objects. Instead they have their own "visitor" functions >> located in the oopDesc and *Klass classes. For example, Parallel >> Scavenge calls obj->push_contents(...), which calls >> Klass::oop_push_contents(...), to follow outgoing pointers after an >> object has been moved. These visitor functions used to use the oop >> iterate macros and pass down snippets of code to be applied to each >> oop*. This has now been changed to use use closures and the new >> oop_oop_iterate template functions. >> >> The implementation of these object visitor functions have been moved >> out from the *Klass.cpp files and into the GCs that the functions >> support. >> >> Using Parallel Scavenge as and example: >> >> The implementation to handle the references out of a copied object >> was located in: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html >> >> >> -void InstanceKlass::oop_push_contents(PSPromotionManager* pm, oop >> obj) { >> - InstanceKlass_OOP_MAP_REVERSE_ITERATE( \ >> - obj, \ >> - if (PSScavenge::should_scavenge(p)) { \ >> - pm->claim_or_forward_depth(p); \ >> - }, \ >> - assert_nothing ) >> -} >> >> and has now been moved to: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html >> >> >> +void InstanceKlass::oop_ps_push_contents(oop obj, >> PSPromotionManager* pm) { >> + PushContentsClosure cl(pm); >> + oop_oop_iterate_oop_maps_reverse(obj, &cl); >> +} >> >> where the do_oop function is implemented as: >> + >> + template void do_oop_nv(T* p) { >> + if (PSScavenge::should_scavenge(p)) { >> + _pm->claim_or_forward_depth(p); >> + } >> >> From the same file, it can be seen how that the implementation to >> follow the references in the mirrors are using the same closure: >> >> +void InstanceMirrorKlass::oop_ps_push_contents(oop obj, >> PSPromotionManager* pm) { >> ... >> + InstanceKlass::oop_ps_push_contents(obj, pm); >> + >> + PushContentsClosure cl(pm); >> + oop_oop_iterate_statics(obj, &cl); >> +} >> >> As can be seen above, the functions are still members of the >> different Klasses, but only the declaration is put in the klass.hpp >> files. The actual implementation is put in the GC files. This helps >> decoupling the different GCs and the Klasses. We could move the >> functions over to a GC specific "visitor" and have a generic "accept" >> function in the Klasses, but that approach would require two virtual >> calls, while the current implementation only needs one. >> >> In the future we might want to remove these functions from the >> *Klasses and reuse the already existing code in the oop_oop_iterate >> framework. >> >> If we take the InstanceMirrorKlass::oop_ps_push_contents function >> above as an example, it could be implemented with >> InstanceMirrorKlass::oop_oop_iterate, since they share the same >> structure: >> >> 54 template >> 55 int InstanceMirrorKlass::oop_oop_iterate(oop obj, >> OopClosureType* closure) { >> 56 InstanceKlass::oop_oop_iterate(obj, closure); >> 57 >> 58 if (Devirtualizer::do_metadata(closure)) { >> 59 Klass* klass = java_lang_Class::as_Klass(obj); >> 60 // We'll get NULL for primitive mirrors. >> 61 if (klass != NULL) { >> 62 Devirtualizer::do_klass(closure, klass); >> 63 } >> 64 } >> 65 >> 66 oop_oop_iterate_statics(obj, closure); >> 67 >> 68 return oop_size(obj); >> 69 } >> >> Parallel Scavenge doesn't visit the klass pointers and do_metadata >> returns false, so that code path will be eliminated by the compiler. >> We would have to do something about the return oop_size(obj), since >> we don't want to do that unnecessarily. To change the GC object >> visitors to entirely use the oop_oop_iterator framework is out of >> scope for this patch. >> >> The object visitor functions were renamed and moved as follows: >> oop_follow_contents(opp) -> oop_ms_follow_contents(oop) in >> markSweep.cpp >> oop_adjust_pointers(oop) -> oop_ms_adjust_pointers(oop) in >> markSweep.cpp >> oop_follow_contents(oop, ParCompactionManager*) -> >> oop_pc_follow_contents(...) in psCompactionManager.cpp >> oop_update_pointers(oop) -> oop_pc_update_pointers(oop) in >> psParallelCompact.cpp >> oop_push_contents(oop, PSPromotionManager*) -> >> oop_ps_push_contents(...) in psPromotionManager.cpp >> >> >> - The oop iterate macros used to take an assert parameter to be >> applied to oop* that were visited. By default, the check was >> assert_is_in_closed_subset, but MS, PS and PC provided their own >> asserts. ExtendedOopClosure has been handed the task to provide the >> default verification, but also a way to turn it off for individual >> closures, so that they can provide their own asserts. See: >> ExtendedOopClosure::verify() and >> ExtendedOopClosure::should_verify_oops() and how the Devirtualizer >> dispatch class calls the verification code: >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/iterator.inline.hpp.udiff.html >> >> >> +template >> +inline void Devirtualizer::do_oop(OopClosureType* closure, T* >> p) { >> + debug_only(closure->verify(p)); >> + closure->do_oop_nv(p); >> +} >> >> >> - Moved PSParallelCompact::MarkAndPushClosure::do_oop, >> PSParallelCompact::AdjustPointerClosure::do_oop, mark_and_push, >> adjust pointer, and follow_klass to psParallelCompact.inline.hpp >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html >> >> >> >> - Add seemingly incorrect includes between GCs. This is needed since >> we currently have no separation between GCs when we generate the >> oop_since_save_marks_iterate functions. See: >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/memory/defNewGeneration.cpp.udiff.html >> >> >> and the include of ParNew specific closures: >> 51 #if INCLUDE_ALL_GCS >> 52 #include "gc_implementation/parNew/parOopClosures.hpp" >> 53 #endif >> >> which is needed to be able to generate: >> 856 ALL_SINCE_SAVE_MARKS_CLOSURES(DefNew_SINCE_SAVE_MARKS_DEFN) >> >> This should be changed in a separate patch, so that DefNew only >> generates oop_since_save_marks_iterate that takes DefNew specfic >> closures. >> >> >> The initial performance runs showed a slight increase of the GC times >> on some benchmarks on Solaris and Windows. The reason for this >> increase was that the these compilers didn't inline as much as the >> hand-inlined macros used to do. To remedy this I've increased the >> inlining in to ways: >> >> - Turned on extra inlining for psPromotionManager.cpp when compiling >> with the Solaris Studio Compiler >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/make/solaris/makefiles/product.make.udiff.html >> >> >> >> - Added __forceinline to the InstanceKlass::oop_oop_iterate functions >> when compiling with the MS compiler. >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/src/share/vm/oops/instanceKlass.inline.hpp.html >> >> >> >> A previous version of this patch has been run through our testing, >> but I've recently done changes and extracted smaller patches, so I'll >> have to rerun all testing. >> >> Any requests for extra testing to be done? >> >> Thanks, >> StefanK >> > From aph at redhat.com Wed Apr 1 14:54:07 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 01 Apr 2015 15:54:07 +0100 Subject: RFR: 8076467: AARCH64: assertion fail with -XX:+UseG1GC Message-ID: <551C068F.3090002@redhat.com> UseG1GC doesn't work on AArch64 debug builds because of an assertion failure. Register::bit(bool) returns a bit for ORing into a bitmask which represents a set of registers. The bool passed to bit() may be true or false; if it is false the passed register may be noreg, in which case we should not call Register::encoding(). http://cr.openjdk.java.net/~aph/8076467/ Andrew. From adinn at redhat.com Wed Apr 1 15:11:40 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 01 Apr 2015 16:11:40 +0100 Subject: RFR: 8076467: AARCH64: assertion fail with -XX:+UseG1GC In-Reply-To: <551C068F.3090002@redhat.com> References: <551C068F.3090002@redhat.com> Message-ID: <551C0AAC.3090706@redhat.com> On 01/04/15 15:54, Andrew Haley wrote: > UseG1GC doesn't work on AArch64 debug builds because of an assertion > failure. > > Register::bit(bool) returns a bit for ORing into a bitmask which > represents a set of registers. The bool passed to bit() may be true > or false; if it is false the passed register may be noreg, in which > case we should not call Register::encoding(). > > http://cr.openjdk.java.net/~aph/8076467/ If this is in need an AArch64-only review then it looks good to me. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From volker.simonis at gmail.com Wed Apr 1 15:32:36 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Apr 2015 17:32:36 +0200 Subject: Has "jdk9/hs-emb" been removed intentionally? Message-ID: Hi, we used to build jdk9/hs-emb/hotspot regularly on our porting platforms in order to catch errors which affect our ports early, before they go into jdk9/hs/hotspot. Now we've realized that jdk9/hs-emb isn't available any more. Has it been removed intentionally or is this just a mistake? Thanks, Volker From bill.pittore at oracle.com Wed Apr 1 15:54:13 2015 From: bill.pittore at oracle.com (bill pittore) Date: Wed, 01 Apr 2015 11:54:13 -0400 Subject: Has "jdk9/hs-emb" been removed intentionally? In-Reply-To: References: Message-ID: <551C14A5.4070002@oracle.com> It was intentionally removed as we are pushing any embedded specific changes up through other appropriate repos such as runtime, gc, or compiler and so on. bill On 4/1/2015 11:32 AM, Volker Simonis wrote: > Hi, > > we used to build jdk9/hs-emb/hotspot regularly on our porting > platforms in order to catch errors which affect our ports early, > before they go into jdk9/hs/hotspot. Now we've realized that > jdk9/hs-emb isn't available any more. Has it been removed > intentionally or is this just a mistake? > > > Thanks, > Volker From volker.simonis at gmail.com Wed Apr 1 15:58:25 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Apr 2015 17:58:25 +0200 Subject: Has "jdk9/hs-emb" been removed intentionally? In-Reply-To: <551C14A5.4070002@oracle.com> References: <551C14A5.4070002@oracle.com> Message-ID: Thanks for the clarification Bill! Regards, Volker On Wed, Apr 1, 2015 at 5:54 PM, bill pittore wrote: > It was intentionally removed as we are pushing any embedded specific changes > up through other appropriate repos such as runtime, gc, or compiler and so > on. > > bill > > > On 4/1/2015 11:32 AM, Volker Simonis wrote: >> >> Hi, >> >> we used to build jdk9/hs-emb/hotspot regularly on our porting >> platforms in order to catch errors which affect our ports early, >> before they go into jdk9/hs/hotspot. Now we've realized that >> jdk9/hs-emb isn't available any more. Has it been removed >> intentionally or is this just a mistake? >> >> >> Thanks, >> Volker > > From edward.nevill at linaro.org Wed Apr 1 16:28:04 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 01 Apr 2015 17:28:04 +0100 Subject: RFR: AARCH64: jdk9 fails to build from source Message-ID: <1427905684.1631.12.camel@mylittlepony.linaroharston> Hi, The following webrev fixes a build failure in jdk9/aarch64 http://cr.openjdk.java.net/~enevill/8076488/webrev/ Issue report here https://bugs.openjdk.java.net/browse/JDK-8076488 Please review and push if appropriate. Thanks, Ed. From coleen.phillimore at oracle.com Wed Apr 1 16:41:59 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 01 Apr 2015 12:41:59 -0400 Subject: RFR: 8076421: Fix Zero Interpreter bugs in class redefinition and template interpreter changeS Message-ID: <551C1FD7.8060008@oracle.com> Summary: metadata_do walking interpreted frames was wrong and generate_Reference_get is not necessarily an accessor method. Tested internal and test/runtime/RedefineTests with fix. Also tested class redefinition tests with linux x64 since there were shared code changes. open webrev at http://cr.openjdk.java.net/~coleenp/8076421/ bug link https://bugs.openjdk.java.net/browse/JDK-8076421 Thanks, Coleen From kirill.zhaldybin at oracle.com Wed Apr 1 17:19:30 2015 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Wed, 01 Apr 2015 20:19:30 +0300 Subject: RFR(XS): JDK-8043225: Make whitebox API functions more stable Message-ID: <551C28A2.8060602@oracle.com> Hi! Could you please review the following patch for WB methods? To make API functions more stable I added checks on null values where applicable. CR: https://bugs.openjdk.java.net/browse/JDK-8043225 Webrev: top: http://cr.openjdk.java.net/~ppunegov/kzhaldybin/8043225/webrev/ 113 lines changed: 92 ins; 0 del; 21 mod; hotspot: http://cr.openjdk.java.net/~ppunegov/kzhaldybin/8043225/hotspot/webrev/ 20 lines changed: 0 ins; 0 del; 20 mod; Tests: jprt Thanks, Kirill From vladimir.kozlov at oracle.com Wed Apr 1 17:51:09 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Apr 2015 10:51:09 -0700 Subject: RFR: 8076488: AARCH64: jdk9 fails to build from source In-Reply-To: <1427905684.1631.12.camel@mylittlepony.linaroharston> References: <1427905684.1631.12.camel@mylittlepony.linaroharston> Message-ID: <551C300D.2090005@oracle.com> Looks good to me. Edward, please, include bug id into mail's Subject (I added it this time). Thanks, Vladimir On 4/1/15 9:28 AM, Edward Nevill wrote: > Hi, > > The following webrev fixes a build failure in jdk9/aarch64 > > http://cr.openjdk.java.net/~enevill/8076488/webrev/ > > Issue report here > > https://bugs.openjdk.java.net/browse/JDK-8076488 > > Please review and push if appropriate. > > Thanks, > Ed. > > From vladimir.kozlov at oracle.com Wed Apr 1 17:52:37 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Apr 2015 10:52:37 -0700 Subject: RFR: 8076467: AARCH64: assertion fail with -XX:+UseG1GC In-Reply-To: <551C068F.3090002@redhat.com> References: <551C068F.3090002@redhat.com> Message-ID: <551C3065.6040006@oracle.com> Good. Thanks, Vladimir On 4/1/15 7:54 AM, Andrew Haley wrote: > UseG1GC doesn't work on AArch64 debug builds because of an assertion > failure. > > Register::bit(bool) returns a bit for ORing into a bitmask which > represents a set of registers. The bool passed to bit() may be true > or false; if it is false the passed register may be noreg, in which > case we should not call Register::encoding(). > > http://cr.openjdk.java.net/~aph/8076467/ > > Andrew. > From vladimir.kozlov at oracle.com Wed Apr 1 17:57:25 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Apr 2015 10:57:25 -0700 Subject: [8u60] RFR(xs): 8076460: Zero fastdebug build does not compile In-Reply-To: <1427891191.3876.38.camel@redhat.com> References: <1427891191.3876.38.camel@redhat.com> Message-ID: <551C3185.4020602@oracle.com> Hi, Severin Instead of creating a new bug we should just backport 8055231 fix. Please, verify if it is the same fix and we will do backport. Regards, Vladimir On 4/1/15 5:26 AM, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this change? > > It's a JDK 8u only issue. The Zero JVM variant fastdebug build does not > compile. Product and slowdebug builds compile fine. JDK-9 does not have > this issue and has received the same fixes, AFAIK. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076460 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076460/webrev.01/ > > Once approved, could somebody please push this to jdk8u? > > Thanks, > Severin > From sgehwolf at redhat.com Wed Apr 1 17:57:20 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 01 Apr 2015 19:57:20 +0200 Subject: RFR: 8076421: Fix Zero Interpreter bugs in class redefinition and template interpreter changeS In-Reply-To: <551C1FD7.8060008@oracle.com> References: <551C1FD7.8060008@oracle.com> Message-ID: <1427911040.3876.56.camel@redhat.com> Hi, On Wed, 2015-04-01 at 12:41 -0400, Coleen Phillimore wrote: > Summary: metadata_do walking interpreted frames was wrong and > generate_Reference_get is not necessarily an accessor method. > > Tested internal and test/runtime/RedefineTests with fix. Also tested > class redefinition tests with linux x64 since there were shared code > changes. > > open webrev at http://cr.openjdk.java.net/~coleenp/8076421/ > bug link https://bugs.openjdk.java.net/browse/JDK-8076421 > > Thanks, > Coleen Disclaimer: Not a reviewer. Zero JVMs (release/fastdebug/slowdebug) compile fine with this. Test passes for me too. Thumbs up from me. Thanks! Cheers, Severin From sgehwolf at redhat.com Wed Apr 1 18:24:17 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 01 Apr 2015 20:24:17 +0200 Subject: [8u60] RFR(xs): 8076460: Zero fastdebug build does not compile In-Reply-To: <551C3185.4020602@oracle.com> References: <1427891191.3876.38.camel@redhat.com> <551C3185.4020602@oracle.com> Message-ID: <1427912657.3876.59.camel@redhat.com> Hi Vladimir, On Wed, 2015-04-01 at 10:57 -0700, Vladimir Kozlov wrote: > Hi, Severin > > Instead of creating a new bug we should just backport 8055231 fix. > Please, verify if it is the same fix and we will do backport. Confirmed. Sorry, it slipped my mind (and I should have checked) that a similar fix went into 9. I've closed JDK-8076460 as a duplicate of JDK-8055231. Is there anything else I need to do to get 8055231 backported? Thanks, Severin > Regards, > Vladimir > > On 4/1/15 5:26 AM, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review and sponsor this change? > > > > It's a JDK 8u only issue. The Zero JVM variant fastdebug build does not > > compile. Product and slowdebug builds compile fine. JDK-9 does not have > > this issue and has received the same fixes, AFAIK. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076460 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076460/webrev.01/ > > > > Once approved, could somebody please push this to jdk8u? > > > > Thanks, > > Severin > > From coleen.phillimore at oracle.com Wed Apr 1 18:42:38 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 01 Apr 2015 14:42:38 -0400 Subject: RFR: 8076421: Fix Zero Interpreter bugs in class redefinition and template interpreter changeS In-Reply-To: <1427911040.3876.56.camel@redhat.com> References: <551C1FD7.8060008@oracle.com> <1427911040.3876.56.camel@redhat.com> Message-ID: <551C3C1E.40100@oracle.com> Thank you, Severin. The hotspot/test/runtime tests still don't run very well because Zero should support compressed oops or class data sharing (CDS). Fixing this would enable Zero to work with CDS: https://bugs.openjdk.java.net/browse/JDK-8005165 But we're probably not going to do this for a while though. thanks, Coleen On 4/1/15, 1:57 PM, Severin Gehwolf wrote: > Hi, > > On Wed, 2015-04-01 at 12:41 -0400, Coleen Phillimore wrote: >> Summary: metadata_do walking interpreted frames was wrong and >> generate_Reference_get is not necessarily an accessor method. >> >> Tested internal and test/runtime/RedefineTests with fix. Also tested >> class redefinition tests with linux x64 since there were shared code >> changes. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8076421/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8076421 >> >> Thanks, >> Coleen > Disclaimer: Not a reviewer. > > Zero JVMs (release/fastdebug/slowdebug) compile fine with this. Test > passes for me too. Thumbs up from me. Thanks! > > Cheers, > Severin > From vladimir.kozlov at oracle.com Wed Apr 1 18:42:27 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Apr 2015 11:42:27 -0700 Subject: [8u60] RFR(xs): 8076460: Zero fastdebug build does not compile In-Reply-To: <1427912657.3876.59.camel@redhat.com> References: <1427891191.3876.38.camel@redhat.com> <551C3185.4020602@oracle.com> <1427912657.3876.59.camel@redhat.com> Message-ID: <551C3C13.6040903@oracle.com> On 4/1/15 11:24 AM, Severin Gehwolf wrote: > Hi Vladimir, > > On Wed, 2015-04-01 at 10:57 -0700, Vladimir Kozlov wrote: >> Hi, Severin >> >> Instead of creating a new bug we should just backport 8055231 fix. >> Please, verify if it is the same fix and we will do backport. > > Confirmed. > > Sorry, it slipped my mind (and I should have checked) that a similar fix > went into 9. I've closed JDK-8076460 as a duplicate of JDK-8055231. Is > there anything else I need to do to get 8055231 backported? Everything is good. Patch 8055231 was applied cleanly to 8u. The push job is in JPRT queue. Vladimir > > Thanks, > Severin > >> Regards, >> Vladimir >> >> On 4/1/15 5:26 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review and sponsor this change? >>> >>> It's a JDK 8u only issue. The Zero JVM variant fastdebug build does not >>> compile. Product and slowdebug builds compile fine. JDK-9 does not have >>> this issue and has received the same fixes, AFAIK. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076460 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076460/webrev.01/ >>> >>> Once approved, could somebody please push this to jdk8u? >>> >>> Thanks, >>> Severin >>> > > > From max.ockner at oracle.com Wed Apr 1 20:33:22 2015 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 01 Apr 2015 16:33:22 -0400 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <55146A38.8090501@oracle.com> References: <55117B1C.5080602@oracle.com> <55119244.6020309@oracle.com> <55119880.5040407@oracle.com> <55119B46.4090909@oracle.com> <5512376C.9050509@oracle.com> <55146A38.8090501@oracle.com> Message-ID: <551C5612.5050808@oracle.com> Hello, I have removed the unwanted comment. New webrev: http://cr.openjdk.java.net/~mockner/6983747.3/ (For now, please reply to me as well since I am trying to resolve some issues with the hotspot-dev mailing list) Thanks, Max On 3/26/2015 4:21 PM, Coleen Phillimore wrote: > > Goetz or Volker, did you see this? > thanks! > Coleen > > On 3/25/15, 12:19 AM, David Holmes wrote: >> On 25/03/2015 3:13 AM, harold seigel wrote: >>> Hi Max, >>> >>> Should this comment be removed from both files? >>> >>> // Glibc-2.0 libdl is not MT safe. If you are building with any >>> glibc, >>> // chances are you might want to run the generated bits against >>> glibc-2.0 >>> // libdl.so, so always use locking for any version of glibc. >> >> Yes that should also be deleted - it was part of the incorrect copy >> done by 6721093. And as per 6626677 glibc was fixed at version 2.1 >> back in 1997. >> >> Since this was all investigated we had the AIX code added, so we need >> to get one of the AIX folk to confirm that no locking is needed >> around dlsym on that platform. (I would be very surprised if it were >> needed :) ) >> >> Thanks, >> David >> >>> Thanks, Harold >>> >>> On 3/24/2015 1:01 PM, Max Ockner wrote: >>>> This was not intentional. I thought the comment was referring to the >>>> line containing dl_mutex, but it was not. I put the comment back in. >>>> New webrev: http://cr.openjdk.java.net/~mockner/6983747.2/ >>>> Thanks, >>>> Max >>>> >>>> On 3/24/2015 12:35 PM, Dmitry Dmitriev wrote: >>>>> Hi Max, >>>>> >>>>> Can you please tell me, you intentionally delete following comment >>>>> from os_linux.cpp file: >>>>> 4680 // else it defaults to CLOCK_REALTIME >>>>> >>>>> It seems that this comment should be leaved. What you think about >>>>> that? >>>>> >>>>> I am not a reviewer. >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>> On 24.03.2015 17:56, Max Ockner wrote: >>>>>> Hello, >>>>>> please review my clean up of the unused dl_mutex lock. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 >>>>>> Webrev: http://cr.openjdk.java.net/~mockner/6983747/ >>>>>> Summary: Deleted all references to the dl_mutex lock which was no >>>>>> longer used. >>>>>> >>>>>> Tested with jtreg runtime tests. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Max Ockner >>>>> >>>> >>> > From harold.seigel at oracle.com Wed Apr 1 20:36:27 2015 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 01 Apr 2015 16:36:27 -0400 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <551C5612.5050808@oracle.com> References: <55117B1C.5080602@oracle.com> <55119244.6020309@oracle.com> <55119880.5040407@oracle.com> <55119B46.4090909@oracle.com> <5512376C.9050509@oracle.com> <55146A38.8090501@oracle.com> <551C5612.5050808@oracle.com> Message-ID: <551C56CB.7080605@oracle.com> It looks good. Harold On 4/1/2015 4:33 PM, Max Ockner wrote: > Hello, > > I have removed the unwanted comment. > > New webrev: http://cr.openjdk.java.net/~mockner/6983747.3/ > > (For now, please reply to me as well since I am trying to resolve some > issues with the hotspot-dev mailing list) > > Thanks, > Max > > > > On 3/26/2015 4:21 PM, Coleen Phillimore wrote: >> >> Goetz or Volker, did you see this? >> thanks! >> Coleen >> >> On 3/25/15, 12:19 AM, David Holmes wrote: >>> On 25/03/2015 3:13 AM, harold seigel wrote: >>>> Hi Max, >>>> >>>> Should this comment be removed from both files? >>>> >>>> // Glibc-2.0 libdl is not MT safe. If you are building with any >>>> glibc, >>>> // chances are you might want to run the generated bits against >>>> glibc-2.0 >>>> // libdl.so, so always use locking for any version of glibc. >>> >>> Yes that should also be deleted - it was part of the incorrect copy >>> done by 6721093. And as per 6626677 glibc was fixed at version 2.1 >>> back in 1997. >>> >>> Since this was all investigated we had the AIX code added, so we >>> need to get one of the AIX folk to confirm that no locking is needed >>> around dlsym on that platform. (I would be very surprised if it were >>> needed :) ) >>> >>> Thanks, >>> David >>> >>>> Thanks, Harold >>>> >>>> On 3/24/2015 1:01 PM, Max Ockner wrote: >>>>> This was not intentional. I thought the comment was referring to the >>>>> line containing dl_mutex, but it was not. I put the comment back in. >>>>> New webrev: http://cr.openjdk.java.net/~mockner/6983747.2/ >>>>> Thanks, >>>>> Max >>>>> >>>>> On 3/24/2015 12:35 PM, Dmitry Dmitriev wrote: >>>>>> Hi Max, >>>>>> >>>>>> Can you please tell me, you intentionally delete following comment >>>>>> from os_linux.cpp file: >>>>>> 4680 // else it defaults to CLOCK_REALTIME >>>>>> >>>>>> It seems that this comment should be leaved. What you think about >>>>>> that? >>>>>> >>>>>> I am not a reviewer. >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>> On 24.03.2015 17:56, Max Ockner wrote: >>>>>>> Hello, >>>>>>> please review my clean up of the unused dl_mutex lock. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/6983747/ >>>>>>> Summary: Deleted all references to the dl_mutex lock which was no >>>>>>> longer used. >>>>>>> >>>>>>> Tested with jtreg runtime tests. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max Ockner >>>>>> >>>>> >>>> >> > From coleen.phillimore at oracle.com Wed Apr 1 21:35:01 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 01 Apr 2015 17:35:01 -0400 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <551C56CB.7080605@oracle.com> References: <55117B1C.5080602@oracle.com> <55119244.6020309@oracle.com> <55119880.5040407@oracle.com> <55119B46.4090909@oracle.com> <5512376C.9050509@oracle.com> <55146A38.8090501@oracle.com> <551C5612.5050808@oracle.com> <551C56CB.7080605@oracle.com> Message-ID: <551C6485.8030905@oracle.com> Yes, this looks good. Coleen On 4/1/15, 4:36 PM, harold seigel wrote: > It looks good. > > Harold > > On 4/1/2015 4:33 PM, Max Ockner wrote: >> Hello, >> >> I have removed the unwanted comment. >> >> New webrev: http://cr.openjdk.java.net/~mockner/6983747.3/ >> >> (For now, please reply to me as well since I am trying to resolve >> some issues with the hotspot-dev mailing list) >> >> Thanks, >> Max >> >> >> >> On 3/26/2015 4:21 PM, Coleen Phillimore wrote: >>> >>> Goetz or Volker, did you see this? >>> thanks! >>> Coleen >>> >>> On 3/25/15, 12:19 AM, David Holmes wrote: >>>> On 25/03/2015 3:13 AM, harold seigel wrote: >>>>> Hi Max, >>>>> >>>>> Should this comment be removed from both files? >>>>> >>>>> // Glibc-2.0 libdl is not MT safe. If you are building with any >>>>> glibc, >>>>> // chances are you might want to run the generated bits against >>>>> glibc-2.0 >>>>> // libdl.so, so always use locking for any version of glibc. >>>> >>>> Yes that should also be deleted - it was part of the incorrect copy >>>> done by 6721093. And as per 6626677 glibc was fixed at version 2.1 >>>> back in 1997. >>>> >>>> Since this was all investigated we had the AIX code added, so we >>>> need to get one of the AIX folk to confirm that no locking is >>>> needed around dlsym on that platform. (I would be very surprised if >>>> it were needed :) ) >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, Harold >>>>> >>>>> On 3/24/2015 1:01 PM, Max Ockner wrote: >>>>>> This was not intentional. I thought the comment was referring to the >>>>>> line containing dl_mutex, but it was not. I put the comment back in. >>>>>> New webrev: http://cr.openjdk.java.net/~mockner/6983747.2/ >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 3/24/2015 12:35 PM, Dmitry Dmitriev wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> Can you please tell me, you intentionally delete following comment >>>>>>> from os_linux.cpp file: >>>>>>> 4680 // else it defaults to CLOCK_REALTIME >>>>>>> >>>>>>> It seems that this comment should be leaved. What you think >>>>>>> about that? >>>>>>> >>>>>>> I am not a reviewer. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>>> On 24.03.2015 17:56, Max Ockner wrote: >>>>>>>> Hello, >>>>>>>> please review my clean up of the unused dl_mutex lock. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 >>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/6983747/ >>>>>>>> Summary: Deleted all references to the dl_mutex lock which was no >>>>>>>> longer used. >>>>>>>> >>>>>>>> Tested with jtreg runtime tests. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max Ockner >>>>>>> >>>>>> >>>>> >>> >> > From kim.barrett at oracle.com Thu Apr 2 00:08:18 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Apr 2015 20:08:18 -0400 Subject: RFR: 8075955: Replace the macro based implementation of oop_oop_iterate with a template based solution In-Reply-To: <5514354B.6060505@oracle.com> References: <5514354B.6060505@oracle.com> Message-ID: On Mar 26, 2015, at 12:35 PM, Stefan Karlsson wrote: > > Hi, > > Please review this patch to replace the macro based implementation of oop_oop_iterate with a template based solution. > > http://cr.openjdk.java.net/~stefank/8075955/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075955 I haven't had time to do a careful line by line review, though I've looked at a lot of the code. So far I've mostly been looking at structural things and overall design. Below are a few comments. While I think we can do better, I think this is very much a step in the right direction. I don't think anything below is required for acceptance of this change set. I might have more comments later, but don't let that possibility hold you back. ------------------------------------------------------------------------------ I would like to have the definitions of the various closure classes and their do_oop_nv functions placed in their natural locations. I really hate that one might have a closure class that is used in one place in a .cpp, and one ends up putting the declaration and definition far away in some other .hpp and .inline.hpp files. I think this could be done within the proposed infrastructure, but don't think it should be part of this change set. (It might even have been possible previously.) The idea is that, rather than having files like g1OopClosure.hpp and g1OopClosure.inline.hpp, instead define the closure class near where it is used, and follow it's definition with an application of ALL_KLASS_OOP_OOP_ITERATE_DEFN (if I've remembered the right macro). ------------------------------------------------------------------------------ I think that for "specialized" closure classes we shouldn't even provide or generate code for the "generic" case that we don't ever want to have used. Ideally we want a compiler error if we *unintentionally* attempt to apply a specialized closure in an unspecialized context. And we should work hard to eliminate the intentional cases. For those cases where a specialized closure gets passed through some API that loses the specialized information, it would be much better if we can recover most of it later, rather than just falling into the generic iterate calling virtual do_oop for each subobject. [What I'm thinking of for the above is the visitor-like pattern you alluded to, in conjunction with the specialization framework. So a specialized closure class would implement the visitor as calling oop_iterate with itself, with the specialization mechanism transforming that into a specialized call. So a "good" oop_iterate has only one virtual call for specialized closures, while a type-erased oop_iterate for specialized closures takes two virtual function calls, the first to the closure's visitor to recover the closure's type.] I think these can be accomplished with a better template-based dispatching infrastructure for oop_iterate and friends. [I think I know how to accomplish this, but haven't had time to get any of it written down in a form that is coherent even to me.] ------------------------------------------------------------------------------ I think a lot of dispatches on UseCompressedOops can be eliminated by doing things like the following. (Warning: I haven't made any attempt to actually try this in real code. This is only a sketch so far.) This also foreshadows some of what I'm thinking for oop_iterate dispatching. But it's a little easier without the extra complexity of dealing with the closure argument whose exact type we want to propogate through some API layers. Change class Klass: remove virtual oop_follow_contents. remove namespace-scope oop_follow_contents_specialized, instead making them (non-virtual protected) ordinary member function templates for the corresponding classes. Replace with protected: // each derived class implements these with the "specialized" code, // e.g. call oop_follow_contents_specialized(obj). virtual void oop_follow_contents_narrow(oop obj) = 0; virtual void oop_follow_contents_wide(oop obj) = 0; // each derived class with a specialized implementation of // oop_follow_contents provides protected. a base class // implementation can be called from a derived class, e.g. at the end // of InstanceKlassRef::oop_follow_contents_specialized(oop obj), // replace // klass->InstanceKlass::oop_follow_contents(obj); // with // InstanceKlass::oop_follow_contents_specialized(obj); void oop_follow_contents_specialized(oop obj); public: // use this when UseCompressedOops is known. // OopRep is either narrowOop or oop. template void oop_follow_contents(oop obj); // use this when OopRep is not known, to dispatch on UseCompressedOops void oop_follow_contents(oop obj); ---- definitions ---- template<> void Klass::oop_follow_contents(oop obj) { oop_follow_contents_narrow(obj); } template<> void Klass::oop_follow_contents(oop obj) { oop_follow_contents_wide(obj); } void Klass::oop_follow_contents(oop obj) { if (UseCompressedOops) { oop_follow_contents(obj); } else { oop_follow_contents(obj); } } From david.holmes at oracle.com Thu Apr 2 00:36:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Apr 2015 10:36:43 +1000 Subject: Has "jdk9/hs-emb" been removed intentionally? In-Reply-To: References: <551C14A5.4070002@oracle.com> Message-ID: <551C8F1B.9000109@oracle.com> Also note that hs-emb was only being updated via pulls down from hs, so it was getting things after they pushed to hs not before. David On 2/04/2015 1:58 AM, Volker Simonis wrote: > Thanks for the clarification Bill! > > Regards, > Volker > > > On Wed, Apr 1, 2015 at 5:54 PM, bill pittore wrote: >> It was intentionally removed as we are pushing any embedded specific changes >> up through other appropriate repos such as runtime, gc, or compiler and so >> on. >> >> bill >> >> >> On 4/1/2015 11:32 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> we used to build jdk9/hs-emb/hotspot regularly on our porting >>> platforms in order to catch errors which affect our ports early, >>> before they go into jdk9/hs/hotspot. Now we've realized that >>> jdk9/hs-emb isn't available any more. Has it been removed >>> intentionally or is this just a mistake? >>> >>> >>> Thanks, >>> Volker >> >> From david.holmes at oracle.com Thu Apr 2 00:57:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Apr 2015 10:57:20 +1000 Subject: RFR(XS): JDK-8043225: Make whitebox API functions more stable In-Reply-To: <551C28A2.8060602@oracle.com> References: <551C28A2.8060602@oracle.com> Message-ID: <551C93F0.10408@oracle.com> Hi Kirill, This all looks okay to me. Thanks, David On 2/04/2015 3:19 AM, Kirill Zhaldybin wrote: > Hi! > > Could you please review the following patch for WB methods? > To make API functions more stable I added checks on null values where > applicable. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8043225 > > Webrev: > top: http://cr.openjdk.java.net/~ppunegov/kzhaldybin/8043225/webrev/ > 113 lines changed: 92 ins; 0 del; 21 mod; > hotspot: > http://cr.openjdk.java.net/~ppunegov/kzhaldybin/8043225/hotspot/webrev/ > 20 lines changed: 0 ins; 0 del; 20 mod; > Tests: > jprt > > Thanks, > Kirill From david.holmes at oracle.com Thu Apr 2 00:59:40 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Apr 2015 10:59:40 +1000 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <551C5612.5050808@oracle.com> References: <55117B1C.5080602@oracle.com> <55119244.6020309@oracle.com> <55119880.5040407@oracle.com> <55119B46.4090909@oracle.com> <5512376C.9050509@oracle.com> <55146A38.8090501@oracle.com> <551C5612.5050808@oracle.com> Message-ID: <551C947C.3080801@oracle.com> Looks good Max! Thanks, David On 2/04/2015 6:33 AM, Max Ockner wrote: > Hello, > > I have removed the unwanted comment. > > New webrev: http://cr.openjdk.java.net/~mockner/6983747.3/ > > (For now, please reply to me as well since I am trying to resolve some > issues with the hotspot-dev mailing list) > > Thanks, > Max > > > > On 3/26/2015 4:21 PM, Coleen Phillimore wrote: >> >> Goetz or Volker, did you see this? >> thanks! >> Coleen >> >> On 3/25/15, 12:19 AM, David Holmes wrote: >>> On 25/03/2015 3:13 AM, harold seigel wrote: >>>> Hi Max, >>>> >>>> Should this comment be removed from both files? >>>> >>>> // Glibc-2.0 libdl is not MT safe. If you are building with any >>>> glibc, >>>> // chances are you might want to run the generated bits against >>>> glibc-2.0 >>>> // libdl.so, so always use locking for any version of glibc. >>> >>> Yes that should also be deleted - it was part of the incorrect copy >>> done by 6721093. And as per 6626677 glibc was fixed at version 2.1 >>> back in 1997. >>> >>> Since this was all investigated we had the AIX code added, so we need >>> to get one of the AIX folk to confirm that no locking is needed >>> around dlsym on that platform. (I would be very surprised if it were >>> needed :) ) >>> >>> Thanks, >>> David >>> >>>> Thanks, Harold >>>> >>>> On 3/24/2015 1:01 PM, Max Ockner wrote: >>>>> This was not intentional. I thought the comment was referring to the >>>>> line containing dl_mutex, but it was not. I put the comment back in. >>>>> New webrev: http://cr.openjdk.java.net/~mockner/6983747.2/ >>>>> Thanks, >>>>> Max >>>>> >>>>> On 3/24/2015 12:35 PM, Dmitry Dmitriev wrote: >>>>>> Hi Max, >>>>>> >>>>>> Can you please tell me, you intentionally delete following comment >>>>>> from os_linux.cpp file: >>>>>> 4680 // else it defaults to CLOCK_REALTIME >>>>>> >>>>>> It seems that this comment should be leaved. What you think about >>>>>> that? >>>>>> >>>>>> I am not a reviewer. >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>> On 24.03.2015 17:56, Max Ockner wrote: >>>>>>> Hello, >>>>>>> please review my clean up of the unused dl_mutex lock. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/6983747/ >>>>>>> Summary: Deleted all references to the dl_mutex lock which was no >>>>>>> longer used. >>>>>>> >>>>>>> Tested with jtreg runtime tests. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max Ockner >>>>>> >>>>> >>>> >> > From david.holmes at oracle.com Thu Apr 2 01:20:47 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Apr 2015 11:20:47 +1000 Subject: RFR: 8076421: Fix Zero Interpreter bugs in class redefinition and template interpreter changeS In-Reply-To: <551C1FD7.8060008@oracle.com> References: <551C1FD7.8060008@oracle.com> Message-ID: <551C996F.6070607@oracle.com> Hi Coleen, On 2/04/2015 2:41 AM, Coleen Phillimore wrote: > Summary: metadata_do walking interpreted frames was wrong and > generate_Reference_get is not necessarily an accessor method. > > Tested internal and test/runtime/RedefineTests with fix. Also tested > class redefinition tests with linux x64 since there were shared code > changes. > > open webrev at http://cr.openjdk.java.net/~coleenp/8076421/ > bug link https://bugs.openjdk.java.net/browse/JDK-8076421 In frame.cpp: - if (_cb != NULL && Interpreter::contains(pc())) { + if (is_interpreted_frame()) { Given most platforms (Zero being the exception!) define is_interpreted_frame() as Interpreter::contains(pc()) this change seems okay. But I do wonder what role if any _cb should be playing here and whether it can in fact be NULL? Can't comment on Zero specifics. Thanks, David > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Apr 2 01:45:10 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 01 Apr 2015 21:45:10 -0400 Subject: RFR: 8076421: Fix Zero Interpreter bugs in class redefinition and template interpreter changeS In-Reply-To: <551C996F.6070607@oracle.com> References: <551C1FD7.8060008@oracle.com> <551C996F.6070607@oracle.com> Message-ID: <551C9F26.7030203@oracle.com> On 4/1/15, 9:20 PM, David Holmes wrote: > Hi Coleen, > > On 2/04/2015 2:41 AM, Coleen Phillimore wrote: >> Summary: metadata_do walking interpreted frames was wrong and >> generate_Reference_get is not necessarily an accessor method. >> >> Tested internal and test/runtime/RedefineTests with fix. Also tested >> class redefinition tests with linux x64 since there were shared code >> changes. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8076421/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8076421 > > In frame.cpp: > > - if (_cb != NULL && Interpreter::contains(pc())) { > + if (is_interpreted_frame()) { > > Given most platforms (Zero being the exception!) define > is_interpreted_frame() as Interpreter::contains(pc()) this change > seems okay. But I do wonder what role if any _cb should be playing > here and whether it can in fact be NULL? I copied the code that checked for _cb != NULL from frame::print_on_error, but the code for frame::oops_do_internal() does not check _cb != NULL. The metadata_do function doesn't care about _cb anyway so even if it was Null that would be okay. I ran through the redefine tests just to make sure though. :) Thanks, Coleen > > Can't comment on Zero specifics. > > Thanks, > David > >> Thanks, >> Coleen From igor.ignatyev at oracle.com Thu Apr 2 04:09:33 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 01 Apr 2015 21:09:33 -0700 Subject: RFR(XS): JDK-8043225: Make whitebox API functions more stable In-Reply-To: <551C28A2.8060602@oracle.com> References: <551C28A2.8060602@oracle.com> Message-ID: <551CC0FD.5020503@oracle.com> Hi Kirill, the patch looks good to me. -- Thanks, Igor On 04/01/2015 10:19 AM, Kirill Zhaldybin wrote: > Hi! > > Could you please review the following patch for WB methods? > To make API functions more stable I added checks on null values where > applicable. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8043225 > > Webrev: > top: http://cr.openjdk.java.net/~ppunegov/kzhaldybin/8043225/webrev/ > 113 lines changed: 92 ins; 0 del; 21 mod; > hotspot: > http://cr.openjdk.java.net/~ppunegov/kzhaldybin/8043225/hotspot/webrev/ > 20 lines changed: 0 ins; 0 del; 20 mod; > Tests: > jprt > > Thanks, > Kirill From stefan.karlsson at oracle.com Thu Apr 2 06:45:27 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 02 Apr 2015 08:45:27 +0200 Subject: RFR: 8075955: Replace the macro based implementation of oop_oop_iterate with a template based solution In-Reply-To: References: <5514354B.6060505@oracle.com> Message-ID: <551CE587.3000701@oracle.com> On 2015-04-02 02:08, Kim Barrett wrote: > On Mar 26, 2015, at 12:35 PM, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to replace the macro based implementation of oop_oop_iterate with a template based solution. >> >> http://cr.openjdk.java.net/~stefank/8075955/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075955 > I haven't had time to do a careful line by line review, though I've > looked at a lot of the code. So far I've mostly been looking at > structural things and overall design. > > Below are a few comments. > > While I think we can do better, I think this is very much a step in > the right direction. I fully agree. > I don't think anything below is required for > acceptance of this change set. I might have more comments later, but > don't let that possibility hold you back. Thanks. We can always change the code again. > > ------------------------------------------------------------------------------ > > I would like to have the definitions of the various closure classes > and their do_oop_nv functions placed in their natural locations. I > really hate that one might have a closure class that is used in one > place in a .cpp, and one ends up putting the declaration and > definition far away in some other .hpp and .inline.hpp files. I think > this could be done within the proposed infrastructure, but don't think > it should be part of this change set. (It might even have been > possible previously.) > > The idea is that, rather than having files like g1OopClosure.hpp and > g1OopClosure.inline.hpp, instead define the closure class near where > it is used, and follow it's definition with an application of > ALL_KLASS_OOP_OOP_ITERATE_DEFN (if I've remembered the right macro). Yes. I intentionally left the closure implementation where they are located for this patch. One of the motivation for the rewrite is to be able to implement what you suggest. I would also like to get rid of all the OOP_OOP_ITERATE_DEFN macros. > > ------------------------------------------------------------------------------ > > I think that for "specialized" closure classes we shouldn't even > provide or generate code for the "generic" case that we don't ever > want to have used. Ideally we want a compiler error if we > *unintentionally* attempt to apply a specialized closure in an > unspecialized context. And we should work hard to eliminate the > intentional cases. > > For those cases where a specialized closure gets passed through some > API that loses the specialized information, it would be much better if > we can recover most of it later, rather than just falling into the > generic iterate calling virtual do_oop for each subobject. > > [What I'm thinking of for the above is the visitor-like pattern you > alluded to, in conjunction with the specialization framework. So a > specialized closure class would implement the visitor as calling > oop_iterate with itself, with the specialization mechanism > transforming that into a specialized call. So a "good" oop_iterate > has only one virtual call for specialized closures, while a > type-erased oop_iterate for specialized closures takes two virtual > function calls, the first to the closure's visitor to recover the > closure's type.] > > I think these can be accomplished with a better template-based > dispatching infrastructure for oop_iterate and friends. [I think I > know how to accomplish this, but haven't had time to get any of it > written down in a form that is coherent even to me.] Sounds good to me. There are a few places where the virtual do_oop functions are used outside of the oop_iterate framework, so we would have to cater for those as well. For example, see the usage of the AdjustPointersClosure in PSParallelCompact::adjust_roots(). > > ------------------------------------------------------------------------------ > > I think a lot of dispatches on UseCompressedOops can be eliminated by > doing things like the following. (Warning: I haven't made any attempt > to actually try this in real code. This is only a sketch so far.) > This also foreshadows some of what I'm thinking for oop_iterate > dispatching. But it's a little easier without the extra complexity of > dealing with the closure argument whose exact type we want to > propogate through some API layers. > > Change class Klass: > > remove virtual oop_follow_contents. > remove namespace-scope oop_follow_contents_specialized, instead making > them (non-virtual protected) ordinary member function templates for > the corresponding classes. > > Replace with > > protected: > // each derived class implements these with the "specialized" code, > // e.g. call oop_follow_contents_specialized(obj). > virtual void oop_follow_contents_narrow(oop obj) = 0; > virtual void oop_follow_contents_wide(oop obj) = 0; > > // each derived class with a specialized implementation of > // oop_follow_contents provides protected. a base class > // implementation can be called from a derived class, e.g. at the end > // of InstanceKlassRef::oop_follow_contents_specialized(oop obj), > // replace > // klass->InstanceKlass::oop_follow_contents(obj); > // with > // InstanceKlass::oop_follow_contents_specialized(obj); > void oop_follow_contents_specialized(oop obj); > > public: > > // use this when UseCompressedOops is known. > // OopRep is either narrowOop or oop. > template > void oop_follow_contents(oop obj); > > // use this when OopRep is not known, to dispatch on UseCompressedOops > void oop_follow_contents(oop obj); > > ---- definitions ---- > template<> > void Klass::oop_follow_contents(oop obj) { > oop_follow_contents_narrow(obj); > } > > template<> > void Klass::oop_follow_contents(oop obj) { > oop_follow_contents_wide(obj); > } > > void Klass::oop_follow_contents(oop obj) { > if (UseCompressedOops) { > oop_follow_contents(obj); > } else { > oop_follow_contents(obj); > } > } The implementations of oop_follow_contents_narrow and oop_follow_contents_wide are the same in all code I've changed. So, we would have to either code duplicate the implementation, or yet again have to dispatch to a specialized version. void InstanceKlass::oop_follow_contents_wide(oop obj) { oop_follow_contents_specialized(obj); } void InstanceKlass::oop_follow_contents_narrow(oop obj) { oop_follow_contents_specialized(obj); } I see that this would be one way to get rid of the UseCompressedOops call when calling InstanceKlass::oop_follow_contents from one of the sub-classes. I'm not convinced that that is important for performance, or that the proposal makes the code any cleaner. What would the motivation for your suggested change be? Thanks for looking at the patch! StefanK > > From max.ockner at oracle.com Thu Apr 2 06:42:18 2015 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 02 Apr 2015 02:42:18 -0400 Subject: RFR: 8068349: Removed unused fast_iagetfield() function. In-Reply-To: <551AE2ED.6000106@oracle.com> References: <551AE101.2070600@oracle.com> <551AE2ED.6000106@oracle.com> Message-ID: <551CE4CA.7000404@oracle.com> Forgot to thank my reviewers. Thank you, reviewers! Max On 3/31/2015 2:09 PM, harold seigel wrote: > Hi Max, > > The change looks good. Can you update the copyrights? > > Thanks, Harold > > On 3/31/2015 2:01 PM, Max Ockner wrote: >> Hello all, >> please review yet another code removal. This is the Open portion of >> the fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8068349 >> Webrev: http://cr.openjdk.java.net/~mockner/8068349/ >> >> Summary: The function fast_iagetfield() is never used, and has been >> removed. >> >> Tested with jtreg runtime tests. >> >> Thanks, >> Max Ockner >> > From david.simms at oracle.com Thu Apr 2 08:47:19 2015 From: david.simms at oracle.com (David Simms) Date: Thu, 02 Apr 2015 10:47:19 +0200 Subject: RFR (S) JNI Specification Issue: JDK-8034923 JNI: static linking assertions specs are incomplete and are in the wrong section of spec Message-ID: <551D0217.7090508@oracle.com> Greetings, JDK Bug: https://bugs.openjdk.java.net/browse/JDK-8034923 Web review: http://cr.openjdk.java.net/~dsimms/jnispec/8034923/ Original (for HTML comparison): http://docs.oracle.com/javase/8/docs/technotes/guides/jni/index.html Summary of changes: Wholly confined to documentation changes, no code modifications made: * The "index.html" has named a "JNI version" number which has never been consistent. After some initial consultation with Stuart Marks and Alex Buckley, we decided to remove version from the document. o There are minor clarifications added to "enhancements.html" and "GetVersion" function documentation, listing the platform release mapped to JNI_VERSION_ constants. * Added the missing "JNI_VERSION_1_8" constant to GetVersion constants. * Moved most of the details regarding static library support (JEP 178) from "Design - Compiling, Loading and Linking Native Methods" to "Invocation API - Library and Version Management" o Rewording to clearly delineate static vs dynamic linked library load and unload hooks o Emphasis on statically linked libraries requiring "JNI_OnLoad_" hook. o Typos, function declaration and linkage sections cleaned up. * Reinstated the "Enhancements" links to JDK 1.2 & JDK 1.4 changes, and added new files for 1.6 and 1.8. Cheers /David Simms From volker.simonis at gmail.com Thu Apr 2 09:12:43 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Apr 2015 11:12:43 +0200 Subject: RFR(XXS): 8076532: Fix format warning/error in methodHandles_ppc.cpp Message-ID: Hi, can I please get a review for this tiny, ppc-only change: https://bugs.openjdk.java.net/browse/JDK-8076532 http://cr.openjdk.java.net/~simonis/webrevs/2015/8076532/ With newer GCCs we currently get the following warning/error: methodHandles_ppc.cpp: In function ?void trace_method_handle_stub(const char*, oopDesc*, intptr_t*, intptr_t*)?: methodHandles_ppc.cpp:469:66: error: format ?%lx? expects argument of type ?long unsigned int?, but argument 6 has type ?intptr_t* {aka long int*}? [-Werror=format=] adaptername, mh_reg_name, (intptr_t) mh, entry_sp); for this code code in methodHandles_ppc.cpp: tty->print_cr("MH %s %s="INTPTR_FORMAT " sp=" INTPTR_FORMAT, adaptername, mh_reg_name, (intptr_t) mh, entry_sp); The fix is trivial - just use the "p2i()" helper function to cast the pointers to the appropriate type: tty->print_cr("MH %s %s="INTPTR_FORMAT " sp=" INTPTR_FORMAT, adaptername, mh_reg_name, p2i(mh), p2i(entry_sp)); Thanks, Volker From david.holmes at oracle.com Thu Apr 2 09:17:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Apr 2015 19:17:08 +1000 Subject: RFR(XXS): 8076532: Fix format warning/error in methodHandles_ppc.cpp In-Reply-To: References: Message-ID: <551D0914.4090508@oracle.com> Looks fine Volker! Thanks, David On 2/04/2015 7:12 PM, Volker Simonis wrote: > Hi, > > can I please get a review for this tiny, ppc-only change: > > https://bugs.openjdk.java.net/browse/JDK-8076532 > http://cr.openjdk.java.net/~simonis/webrevs/2015/8076532/ > > With newer GCCs we currently get the following warning/error: > > methodHandles_ppc.cpp: In function ?void > trace_method_handle_stub(const char*, oopDesc*, intptr_t*, > intptr_t*)?: > methodHandles_ppc.cpp:469:66: error: format ?%lx? expects argument of > type ?long unsigned int?, but argument 6 has type ?intptr_t* {aka long > int*}? [-Werror=format=] > adaptername, mh_reg_name, (intptr_t) mh, entry_sp); > > for this code code in methodHandles_ppc.cpp: > > tty->print_cr("MH %s %s="INTPTR_FORMAT " sp=" INTPTR_FORMAT, > adaptername, mh_reg_name, (intptr_t) mh, entry_sp); > > The fix is trivial - just use the "p2i()" helper function to cast the > pointers to the appropriate type: > > tty->print_cr("MH %s %s="INTPTR_FORMAT " sp=" INTPTR_FORMAT, > adaptername, mh_reg_name, p2i(mh), p2i(entry_sp)); > > > Thanks, > Volker > From volker.simonis at gmail.com Thu Apr 2 09:19:28 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Apr 2015 11:19:28 +0200 Subject: RFR(XXS): 8076532: Fix format warning/error in methodHandles_ppc.cpp In-Reply-To: <551D0914.4090508@oracle.com> References: <551D0914.4090508@oracle.com> Message-ID: Thanks David! Volker On Thu, Apr 2, 2015 at 11:17 AM, David Holmes wrote: > Looks fine Volker! > > Thanks, > David > > > On 2/04/2015 7:12 PM, Volker Simonis wrote: >> >> Hi, >> >> can I please get a review for this tiny, ppc-only change: >> >> https://bugs.openjdk.java.net/browse/JDK-8076532 >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8076532/ >> >> With newer GCCs we currently get the following warning/error: >> >> methodHandles_ppc.cpp: In function ?void >> trace_method_handle_stub(const char*, oopDesc*, intptr_t*, >> intptr_t*)?: >> methodHandles_ppc.cpp:469:66: error: format ?%lx? expects argument of >> type ?long unsigned int?, but argument 6 has type ?intptr_t* {aka long >> int*}? [-Werror=format=] >> adaptername, mh_reg_name, (intptr_t) mh, entry_sp); >> >> for this code code in methodHandles_ppc.cpp: >> >> tty->print_cr("MH %s %s="INTPTR_FORMAT " sp=" INTPTR_FORMAT, >> adaptername, mh_reg_name, (intptr_t) mh, entry_sp); >> >> The fix is trivial - just use the "p2i()" helper function to cast the >> pointers to the appropriate type: >> >> tty->print_cr("MH %s %s="INTPTR_FORMAT " sp=" INTPTR_FORMAT, >> adaptername, mh_reg_name, p2i(mh), p2i(entry_sp)); >> >> >> Thanks, >> Volker >> > From aph at redhat.com Thu Apr 2 09:27:51 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 02 Apr 2015 10:27:51 +0100 Subject: RFR: 8075860: aarch64: jdk9/dev fails to build In-Reply-To: <5512F192.9060401@oracle.com> References: <1427275648.7353.8.camel@mylittlepony.linaroharston> <5512F192.9060401@oracle.com> Message-ID: <551D0B97.2010608@redhat.com> On 03/25/2015 05:34 PM, Vladimir Kozlov wrote: > Looks good. > > It is in JPRT queue for push. I don't see it. What happened? Thanks, Andrew. From thomas.stuefe at gmail.com Thu Apr 2 10:06:06 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 2 Apr 2015 12:06:06 +0200 Subject: Getting rid of the requested_addr parameter in os::reserve_memory? Message-ID: Hi all, Proposal: I would like to remove the "requested_addr" parameter from os::reserve_memory(), because it is dangerous and should not be used. Here is why: when reserving memory, there are two reasons to specify a wish address. 1) we want to reserve a memory range at a given address, because we find that address numerically pleasing for some reason (heap optimized for compressed oops etc). In this case, we only want to probe; we can live with the address being different and certainly do not want to trash any pre-existing mappings. 2) we want to change properties of a pre-existing memory range, e.g. commit the memory which was only reserved before. For both cases, os::reserve_memory() is the wrong choice. For (1), we have os::attempt_reserve_memory_at(). For (2), we have os::commit_memory() etc. In the current implementation of os::reserve_memory(), when requested_addr != NULL, we may trash existing mappings, this depends on the implementation. - On windows, we use VirtualAlloc(), which will not trash. - On mmap-based implementations (linux,bsd,solaris), specifying requested_addr on os::reserve_memory() will cause mmap() to be called with MAP_FIXED, which at least on Linux and Solaris (not sure about BSD) trashes pre-existing mappings. - On AIX, we use SystemV shm for most allocations; besides, MAP_FIXED won't normally trash existing mappings. Normally, os::reserve_memory() is called with requested_addr=NULL; I found only two places where we actually hand a non-NULL requested_addr to os::reserve_memory(), and I think both could be considered errors: A) on Windows, we use it in os::pd_split_reserved_memory(). Here, we want to split a preallocated range into two ranges, in order to be able to release them independentally. This code wants to work around the fact that VirtualAlloc() allocations are one entity and can only be released as such, as opposed to mmap(), where you can unmap page-wise. It does this by deallocating the whole range and allocating twice two separate ranges in the same address range. This coding is racy: some other allocation may come between the deallocation and the subsequent allocations. Neither is there any error checking, so we will not notice if this fails. B) on Linux, we call os::reserve_memory() with a non-NULL address in os::Linux::reserve_memory_special_huge_tlbfs_mixed(). This code gets called via some code paths when allocating large paged heap, and I think this is simply wrong and may trash existing mappings. The larger the heap is and the more refined the "lets-try-to-allocate-heap-at-compressed-oops-friendly-address" logic, the more probable this becomes. ---- Therefore I would like to get rid of the requested_addr parameter in os::reserve_memory() and also change code that uses it (A) and (B) to either attempt_reserve_memory_at() or something different altogether. (A) could be just rewritten using VirtualAlloc() calls directly, though that does not solve the bad design. (B), I don't know - would have to look at this more closely. Note that this is not a theoretical problem; from time to time we have problems because programmers are unaware of the MAP_FIXED problem and used os::reserve_memory() instead of os::attempt_reserve_memory_at(). The nasty thing about this is that you normally will not notice, not in a normal java launcher scenario, where memory allocation at process startup is somewhat deterministic. But our (SAP) java VM gets used a lot with other launchers, which usually initialize the java vm last, after doing a lot of other stuff; here, the address space may be already populated with lots of non-java mappings. What do you think? Also, happy easter :) ...Thomas Stuefe From stefan.karlsson at oracle.com Thu Apr 2 10:38:59 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 02 Apr 2015 12:38:59 +0200 Subject: Getting rid of the requested_addr parameter in os::reserve_memory? In-Reply-To: References: Message-ID: <551D1C43.5000508@oracle.com> Hi Thomas, On 2015-04-02 12:06, Thomas St?fe wrote: > Hi all, > > Proposal: I would like to remove the "requested_addr" parameter from > os::reserve_memory(), because it is dangerous and should not be used. > > Here is why: > > when reserving memory, there are two reasons to specify a wish address. > > 1) we want to reserve a memory range at a given address, because we find > that address numerically pleasing for some reason (heap optimized for > compressed oops etc). In this case, we only want to probe; we can live with > the address being different and certainly do not want to trash any > pre-existing mappings. > > 2) we want to change properties of a pre-existing memory range, e.g. commit > the memory which was only reserved before. > > For both cases, os::reserve_memory() is the wrong choice. For (1), we have > os::attempt_reserve_memory_at(). For (2), we have os::commit_memory() etc. > > In the current implementation of os::reserve_memory(), when requested_addr > != NULL, we may trash existing mappings, this depends on the implementation. > - On windows, we use VirtualAlloc(), which will not trash. > - On mmap-based implementations (linux,bsd,solaris), specifying > requested_addr on os::reserve_memory() will cause mmap() to be called with > MAP_FIXED, which at least on Linux and Solaris (not sure about BSD) trashes > pre-existing mappings. > - On AIX, we use SystemV shm for most allocations; besides, MAP_FIXED won't > normally trash existing mappings. > > Normally, os::reserve_memory() is called with requested_addr=NULL; I found > only two places where we actually hand a non-NULL requested_addr to > os::reserve_memory(), and I think both could be considered errors: > > A) on Windows, we use it in os::pd_split_reserved_memory(). Here, we want > to split a preallocated range into two ranges, in order to be able to > release them independentally. This code wants to work around the fact that > VirtualAlloc() allocations are one entity and can only be released as such, > as opposed to mmap(), where you can unmap page-wise. > It does this by deallocating the whole range and allocating twice two > separate ranges in the same address range. This coding is racy: some other > allocation may come between the deallocation and the subsequent > allocations. Neither is there any error checking, so we will not notice if > this fails. > > B) on Linux, we call os::reserve_memory() with a non-NULL address in > os::Linux::reserve_memory_special_huge_tlbfs_mixed(). This code gets called > via some code paths when allocating large paged heap, and I think this is > simply wrong and may trash existing mappings. The larger the heap is and > the more refined the > "lets-try-to-allocate-heap-at-compressed-oops-friendly-address" logic, the > more probable this becomes. > > ---- > > Therefore I would like to get rid of the requested_addr parameter in > os::reserve_memory() and also change code that uses it (A) and (B) to > either attempt_reserve_memory_at() or something different altogether. (A) > could be just rewritten using VirtualAlloc() calls directly, though that > does not solve the bad design. (B), I don't know - would have to look at > this more closely. > > Note that this is not a theoretical problem; from time to time we have > problems because programmers are unaware of the MAP_FIXED problem and used > os::reserve_memory() instead of os::attempt_reserve_memory_at(). The nasty > thing about this is that you normally will not notice, not in a normal java > launcher scenario, where memory allocation at process startup is somewhat > deterministic. But our (SAP) java VM gets used a lot with other launchers, > which usually initialize the java vm last, after doing a lot of other > stuff; here, the address space may be already populated with lots of > non-java mappings. > > What do you think? Sounds good to me. StefanK > > Also, happy easter :) > > ...Thomas Stuefe From max.ockner at oracle.com Thu Apr 2 14:16:07 2015 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 02 Apr 2015 10:16:07 -0400 Subject: RFR: 6983747: Clean up of unused dl_mutex lock. In-Reply-To: <551C947C.3080801@oracle.com> References: <55117B1C.5080602@oracle.com> <55119244.6020309@oracle.com> <55119880.5040407@oracle.com> <55119B46.4090909@oracle.com> <5512376C.9050509@oracle.com> <55146A38.8090501@oracle.com> <551C5612.5050808@oracle.com> <551C947C.3080801@oracle.com> Message-ID: <551D4F27.90903@oracle.com> Thanks for reviewing this. I have committed it. Max On 4/1/2015 8:59 PM, David Holmes wrote: > Looks good Max! > > Thanks, > David > > On 2/04/2015 6:33 AM, Max Ockner wrote: >> Hello, >> >> I have removed the unwanted comment. >> >> New webrev: http://cr.openjdk.java.net/~mockner/6983747.3/ >> >> (For now, please reply to me as well since I am trying to resolve some >> issues with the hotspot-dev mailing list) >> >> Thanks, >> Max >> >> >> >> On 3/26/2015 4:21 PM, Coleen Phillimore wrote: >>> >>> Goetz or Volker, did you see this? >>> thanks! >>> Coleen >>> >>> On 3/25/15, 12:19 AM, David Holmes wrote: >>>> On 25/03/2015 3:13 AM, harold seigel wrote: >>>>> Hi Max, >>>>> >>>>> Should this comment be removed from both files? >>>>> >>>>> // Glibc-2.0 libdl is not MT safe. If you are building with any >>>>> glibc, >>>>> // chances are you might want to run the generated bits against >>>>> glibc-2.0 >>>>> // libdl.so, so always use locking for any version of glibc. >>>> >>>> Yes that should also be deleted - it was part of the incorrect copy >>>> done by 6721093. And as per 6626677 glibc was fixed at version 2.1 >>>> back in 1997. >>>> >>>> Since this was all investigated we had the AIX code added, so we need >>>> to get one of the AIX folk to confirm that no locking is needed >>>> around dlsym on that platform. (I would be very surprised if it were >>>> needed :) ) >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, Harold >>>>> >>>>> On 3/24/2015 1:01 PM, Max Ockner wrote: >>>>>> This was not intentional. I thought the comment was referring to the >>>>>> line containing dl_mutex, but it was not. I put the comment back in. >>>>>> New webrev: http://cr.openjdk.java.net/~mockner/6983747.2/ >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 3/24/2015 12:35 PM, Dmitry Dmitriev wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> Can you please tell me, you intentionally delete following comment >>>>>>> from os_linux.cpp file: >>>>>>> 4680 // else it defaults to CLOCK_REALTIME >>>>>>> >>>>>>> It seems that this comment should be leaved. What you think about >>>>>>> that? >>>>>>> >>>>>>> I am not a reviewer. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>>> On 24.03.2015 17:56, Max Ockner wrote: >>>>>>>> Hello, >>>>>>>> please review my clean up of the unused dl_mutex lock. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6983747 >>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/6983747/ >>>>>>>> Summary: Deleted all references to the dl_mutex lock which was no >>>>>>>> longer used. >>>>>>>> >>>>>>>> Tested with jtreg runtime tests. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max Ockner >>>>>>> >>>>>> >>>>> >>> >> From volker.simonis at gmail.com Thu Apr 2 16:06:01 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Apr 2015 18:06:01 +0200 Subject: We REALLY nead a NON-PCH build in JPRT NOW! Message-ID: Hi, while precompiled headers (PCH) are a nice and effective way of improving hotspot build times this feature also drastically increases the risk of introducing missing dependencies into the source base. This is especially annoying on platforms where precompield headers aren't available at all. In the last two weeks we had two cases [1,2] of such missing dependencies which haven't been caught by JPRT because JPRT uses the default platform settings and thus always uses PCHs on all platforms where they are supported. I want to strongly advocate for a change in the JPRT configurations such that at least on one Windows and one Linux platform the automatic pre-integration builds are done with "--with-debug-level=[slow/fast]debug --disable-precompiled-headers". This simple change which comes at the minor cost of a few CPU-cycles will save a big amount of (hopfully) much more precious developer cycles and at the same time considerably improve the code quality. Notice that I intentionally ask for a *debug build without PCHs because debug builds exercise much more source code and are specifically prone to missing include dependency errors. As this change can only be decided upon and implemented inside Oracle I hereby kindly ask for an appropriate sponsor. Thank you and best regards, Volker [1] Introduced by: https://bugs.openjdk.java.net/browse/JDK-8075416 Fixed by: https://bugs.openjdk.java.net/browse/JDK-8075735 [2] Introduced by: https://bugs.openjdk.java.net/browse/JDK-8076314 Fix proposed: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-April/012659.html From vladimir.kozlov at oracle.com Thu Apr 2 16:21:03 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Apr 2015 09:21:03 -0700 Subject: RFR: 8075860: aarch64: jdk9/dev fails to build In-Reply-To: <551D0B97.2010608@redhat.com> References: <1427275648.7353.8.camel@mylittlepony.linaroharston> <5512F192.9060401@oracle.com> <551D0B97.2010608@redhat.com> Message-ID: <551D6C6F.3090401@oracle.com> I accidentally pushed it into hs/ instead of hs-comp/: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/21ea7a2e3afc Should be synced to all repos at the end of this week. Regards, Vladimir On 4/2/15 2:27 AM, Andrew Haley wrote: > On 03/25/2015 05:34 PM, Vladimir Kozlov wrote: >> Looks good. >> >> It is in JPRT queue for push. > > I don't see it. What happened? > > Thanks, > Andrew. > From coleen.phillimore at oracle.com Thu Apr 2 17:01:22 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 02 Apr 2015 13:01:22 -0400 Subject: RFR(XXS): 8076532: Fix format warning/error in methodHandles_ppc.cpp In-Reply-To: References: Message-ID: <551D75E2.3000701@oracle.com> Yes, this looks fine if you need another reviewer. Coleen On 4/2/15, 5:12 AM, Volker Simonis wrote: > Hi, > > can I please get a review for this tiny, ppc-only change: > > https://bugs.openjdk.java.net/browse/JDK-8076532 > http://cr.openjdk.java.net/~simonis/webrevs/2015/8076532/ > > With newer GCCs we currently get the following warning/error: > > methodHandles_ppc.cpp: In function ?void > trace_method_handle_stub(const char*, oopDesc*, intptr_t*, > intptr_t*)?: > methodHandles_ppc.cpp:469:66: error: format ?%lx? expects argument of > type ?long unsigned int?, but argument 6 has type ?intptr_t* {aka long > int*}? [-Werror=format=] > adaptername, mh_reg_name, (intptr_t) mh, entry_sp); > > for this code code in methodHandles_ppc.cpp: > > tty->print_cr("MH %s %s="INTPTR_FORMAT " sp=" INTPTR_FORMAT, > adaptername, mh_reg_name, (intptr_t) mh, entry_sp); > > The fix is trivial - just use the "p2i()" helper function to cast the > pointers to the appropriate type: > > tty->print_cr("MH %s %s="INTPTR_FORMAT " sp=" INTPTR_FORMAT, > adaptername, mh_reg_name, p2i(mh), p2i(entry_sp)); > > > Thanks, > Volker From tim.bell at oracle.com Thu Apr 2 17:28:22 2015 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 02 Apr 2015 10:28:22 -0700 Subject: Fwd: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <551D72C5.3010904@oracle.com> References: <551D72C5.3010904@oracle.com> Message-ID: <551D7C36.7000903@oracle.com> Thanks, Jon and Volker I filed a new bug report to track this issue: JDK-8076581 - Need a NON-PCH build to quickly detect missing dependencies in the source base has been successfully created. https://bugs.openjdk.java.net/browse/JDK-8076581 Tim On 04/02/15 09:48, Jon Masamitsu wrote: > > > > -------- Forwarded Message -------- > Subject: We REALLY nead a NON-PCH build in JPRT NOW! > Date: Thu, 2 Apr 2015 18:06:01 +0200 > From: Volker Simonis > To: HotSpot Open Source Developers > > > > Hi, > > while precompiled headers (PCH) are a nice and effective way of > improving hotspot build times this feature also drastically increases > the risk of introducing missing dependencies into the source base. > This is especially annoying on platforms where precompield headers > aren't available at all. > > In the last two weeks we had two cases [1,2] of such missing > dependencies which haven't been caught by JPRT because JPRT uses the > default platform settings and thus always uses PCHs on all platforms > where they are supported. > > I want to strongly advocate for a change in the JPRT configurations > such that at least on one Windows and one Linux platform the automatic > pre-integration builds are done with > "--with-debug-level=[slow/fast]debug --disable-precompiled-headers". > This simple change which comes at the minor cost of a few CPU-cycles > will save a big amount of (hopfully) much more precious developer > cycles and at the same time considerably improve the code quality. > Notice that I intentionally ask for a *debug build without PCHs > because debug builds exercise much more source code and are > specifically prone to missing include dependency errors. > > As this change can only be decided upon and implemented inside Oracle > I hereby kindly ask for an appropriate sponsor. > > Thank you and best regards, > Volker > > [1] > Introduced by: https://bugs.openjdk.java.net/browse/JDK-8075416 > Fixed by: https://bugs.openjdk.java.net/browse/JDK-8075735 > > [2] > Introduced by: https://bugs.openjdk.java.net/browse/JDK-8076314 > Fix proposed: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-April/012659.html > > > From max.ockner at oracle.com Thu Apr 2 18:43:14 2015 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 02 Apr 2015 14:43:14 -0400 Subject: RFR: 8073989: Deprecated integer options are now recognized as obsolete. In-Reply-To: <5519FFF4.1050507@oracle.com> References: <55199108.9030102@oracle.com> <5519FFF4.1050507@oracle.com> Message-ID: <551D8DC2.6010808@oracle.com> I have rearranged the misplaced comments. New Webrev: http://cr.openjdk.java.net/~mockner/8073989.3/ I still need one more (r)eviewer. Thanks, Max On 3/30/2015 10:01 PM, David Holmes wrote: > Hi Max, > > On 31/03/2015 4:08 AM, Max Ockner wrote: >> Hello all, >> Please review this change involving the handling of obsolete command >> line flags. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073989 >> Webrev: http://cr.openjdk.java.net/~mockner/8073989.2/ > > Argument processing seems to be a never ending source of bugs. > >> Summary: Three key components to this bug: > > Thanks for the detailed description! > >> (1) When is_newly_obsolete() checks for "SomeObsoleteIntegerFlag=100" in >> the flag table, it is not recognized as a match with >> "SomeObsoleteIntegerFlag" because the lengths are different. This has >> been fixed. Arguments:process_argument() now strips everything except >> for the arguments name. (example: -XX:+SomeBooleanFlag -> >> "SomeBooleanFlag", and -XX:SomeIntegerFlag=100 -> "SomeIntegerFlag") >> This stripped argument name (fittingly called stripped_argname) is now >> passed into is_newly_obsolete, preventing the length check from failing >> on obsolete (but formeerly valid) arguments. It also eliminates the need >> for any case work and other string gymnastics from the the body of >> is_newly_obsolete. If the argument is found to be newly obsolete, the >> warning message now prints stripped_argname instead of argname to avoid >> suggesting that "SomeBooleanFlag=100" was ever a supported option. > > So previously is_newly_obsolete handled +/- but despite the comment > didn't really handle the flag=xxx form. So now before calling > is_newly_obsolete the leading +/- or trailing = is stripped, so only > the base argument name is actually checked. Ok. > > I think these comments were misplaced originally, and seem more so now: > > 874 // For locked flags, report a custom error message if available. > 875 // Otherwise, report the standard unrecognized VM option. > > they belong after the is_newly_obsolete calling block, prior to: > > 883 Flag* found_flag = Flag::find_flag((const char*)argname, > arg_len, true, true); > 884 if (found_flag != NULL) { > >> (2) Some flags used to be defined in both the flags table and the >> obsolete flags table. Because of this, those obsolete flags which were >> also defined in the flags table could be fuzzy matched to provide better >> error messages. Now that no flag is allowed to be in both tables, it is >> pointless to attempt to fuzzy match an obsolete flag, since fuzzy >> matching only looks in the flags table (not the obsolete flags table). >> The section at the end of Arguments:process_argument in which fuzzy >> matching is attempted on obsolete arguments no longer makes sense and >> has been removed. > > Ok. > >> (3) ObsoleteFlagErrorMessage.java has been modified. The existing test >> for an obsolete flag with appended junk no longer tests for fuzzy >> matching, and a second test case has been added for integer valued >> flags. > > Ok. The test will need to use a new "newly obsolete" flag in JDK 10. :) > > Reviewed! > > Thanks, > David > >> Tested with jtreg runtime tests. >> >> Thanks, >> Max Ockner From harold.seigel at oracle.com Thu Apr 2 19:02:29 2015 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 02 Apr 2015 15:02:29 -0400 Subject: RFR: 8073989: Deprecated integer options are now recognized as obsolete. In-Reply-To: <551D8DC2.6010808@oracle.com> References: <55199108.9030102@oracle.com> <5519FFF4.1050507@oracle.com> <551D8DC2.6010808@oracle.com> Message-ID: <551D9245.4070907@oracle.com> Hi Max, Your changes look good. Harold On 4/2/2015 2:43 PM, Max Ockner wrote: > I have rearranged the misplaced comments. > New Webrev: http://cr.openjdk.java.net/~mockner/8073989.3/ > > I still need one more (r)eviewer. > > Thanks, > Max > > On 3/30/2015 10:01 PM, David Holmes wrote: >> Hi Max, >> >> On 31/03/2015 4:08 AM, Max Ockner wrote: >>> Hello all, >>> Please review this change involving the handling of obsolete command >>> line flags. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073989 >>> Webrev: http://cr.openjdk.java.net/~mockner/8073989.2/ >> >> Argument processing seems to be a never ending source of bugs. >> >>> Summary: Three key components to this bug: >> >> Thanks for the detailed description! >> >>> (1) When is_newly_obsolete() checks for >>> "SomeObsoleteIntegerFlag=100" in >>> the flag table, it is not recognized as a match with >>> "SomeObsoleteIntegerFlag" because the lengths are different. This has >>> been fixed. Arguments:process_argument() now strips everything except >>> for the arguments name. (example: -XX:+SomeBooleanFlag -> >>> "SomeBooleanFlag", and -XX:SomeIntegerFlag=100 -> "SomeIntegerFlag") >>> This stripped argument name (fittingly called stripped_argname) is now >>> passed into is_newly_obsolete, preventing the length check from failing >>> on obsolete (but formeerly valid) arguments. It also eliminates the >>> need >>> for any case work and other string gymnastics from the the body of >>> is_newly_obsolete. If the argument is found to be newly obsolete, the >>> warning message now prints stripped_argname instead of argname to avoid >>> suggesting that "SomeBooleanFlag=100" was ever a supported option. >> >> So previously is_newly_obsolete handled +/- but despite the comment >> didn't really handle the flag=xxx form. So now before calling >> is_newly_obsolete the leading +/- or trailing = is stripped, so only >> the base argument name is actually checked. Ok. >> >> I think these comments were misplaced originally, and seem more so now: >> >> 874 // For locked flags, report a custom error message if available. >> 875 // Otherwise, report the standard unrecognized VM option. >> >> they belong after the is_newly_obsolete calling block, prior to: >> >> 883 Flag* found_flag = Flag::find_flag((const char*)argname, >> arg_len, true, true); >> 884 if (found_flag != NULL) { >> >>> (2) Some flags used to be defined in both the flags table and the >>> obsolete flags table. Because of this, those obsolete flags which were >>> also defined in the flags table could be fuzzy matched to provide >>> better >>> error messages. Now that no flag is allowed to be in both tables, it is >>> pointless to attempt to fuzzy match an obsolete flag, since fuzzy >>> matching only looks in the flags table (not the obsolete flags table). >>> The section at the end of Arguments:process_argument in which fuzzy >>> matching is attempted on obsolete arguments no longer makes sense and >>> has been removed. >> >> Ok. >> >>> (3) ObsoleteFlagErrorMessage.java has been modified. The existing test >>> for an obsolete flag with appended junk no longer tests for fuzzy >>> matching, and a second test case has been added for integer valued >>> flags. >> >> Ok. The test will need to use a new "newly obsolete" flag in JDK 10. :) >> >> Reviewed! >> >> Thanks, >> David >> >>> Tested with jtreg runtime tests. >>> >>> Thanks, >>> Max Ockner > From max.ockner at oracle.com Thu Apr 2 19:38:46 2015 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 02 Apr 2015 15:38:46 -0400 Subject: RFR: 8029630: Print thread id hex representation in error messages. Message-ID: <551D9AC6.50208@oracle.com> Hello, Please review this change: Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ Summary: Existing error messages for vm crashes print the decimal representation of the current thread id. The message format has been changed to print the hex value of the thread id. Tested with jtreg runtime to make sure nothing was broken. I tested the new functionality separately. I crashed the vm and examined the debugger output to make sure the hexadecimal thread id printed in the error message matched one of the threads listed by the debugger. Thanks, Max From dmitry.dmitriev at oracle.com Thu Apr 2 21:23:27 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 03 Apr 2015 00:23:27 +0300 Subject: RFR: 8073989: Deprecated integer options are now recognized as obsolete. In-Reply-To: <551D8DC2.6010808@oracle.com> References: <55199108.9030102@oracle.com> <5519FFF4.1050507@oracle.com> <551D8DC2.6010808@oracle.com> Message-ID: <551DB34F.9030404@oracle.com> Hi Max, Thank you fixing that issue! Looks good to me, but I am not a reviewer. Regards, Dmitry On 02.04.2015 21:43, Max Ockner wrote: > I have rearranged the misplaced comments. > New Webrev: http://cr.openjdk.java.net/~mockner/8073989.3/ > > I still need one more (r)eviewer. > > Thanks, > Max > > On 3/30/2015 10:01 PM, David Holmes wrote: >> Hi Max, >> >> On 31/03/2015 4:08 AM, Max Ockner wrote: >>> Hello all, >>> Please review this change involving the handling of obsolete command >>> line flags. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073989 >>> Webrev: http://cr.openjdk.java.net/~mockner/8073989.2/ >> >> Argument processing seems to be a never ending source of bugs. >> >>> Summary: Three key components to this bug: >> >> Thanks for the detailed description! >> >>> (1) When is_newly_obsolete() checks for >>> "SomeObsoleteIntegerFlag=100" in >>> the flag table, it is not recognized as a match with >>> "SomeObsoleteIntegerFlag" because the lengths are different. This has >>> been fixed. Arguments:process_argument() now strips everything except >>> for the arguments name. (example: -XX:+SomeBooleanFlag -> >>> "SomeBooleanFlag", and -XX:SomeIntegerFlag=100 -> "SomeIntegerFlag") >>> This stripped argument name (fittingly called stripped_argname) is now >>> passed into is_newly_obsolete, preventing the length check from failing >>> on obsolete (but formeerly valid) arguments. It also eliminates the >>> need >>> for any case work and other string gymnastics from the the body of >>> is_newly_obsolete. If the argument is found to be newly obsolete, the >>> warning message now prints stripped_argname instead of argname to avoid >>> suggesting that "SomeBooleanFlag=100" was ever a supported option. >> >> So previously is_newly_obsolete handled +/- but despite the comment >> didn't really handle the flag=xxx form. So now before calling >> is_newly_obsolete the leading +/- or trailing = is stripped, so only >> the base argument name is actually checked. Ok. >> >> I think these comments were misplaced originally, and seem more so now: >> >> 874 // For locked flags, report a custom error message if available. >> 875 // Otherwise, report the standard unrecognized VM option. >> >> they belong after the is_newly_obsolete calling block, prior to: >> >> 883 Flag* found_flag = Flag::find_flag((const char*)argname, >> arg_len, true, true); >> 884 if (found_flag != NULL) { >> >>> (2) Some flags used to be defined in both the flags table and the >>> obsolete flags table. Because of this, those obsolete flags which were >>> also defined in the flags table could be fuzzy matched to provide >>> better >>> error messages. Now that no flag is allowed to be in both tables, it is >>> pointless to attempt to fuzzy match an obsolete flag, since fuzzy >>> matching only looks in the flags table (not the obsolete flags table). >>> The section at the end of Arguments:process_argument in which fuzzy >>> matching is attempted on obsolete arguments no longer makes sense and >>> has been removed. >> >> Ok. >> >>> (3) ObsoleteFlagErrorMessage.java has been modified. The existing test >>> for an obsolete flag with appended junk no longer tests for fuzzy >>> matching, and a second test case has been added for integer valued >>> flags. >> >> Ok. The test will need to use a new "newly obsolete" flag in JDK 10. :) >> >> Reviewed! >> >> Thanks, >> David >> >>> Tested with jtreg runtime tests. >>> >>> Thanks, >>> Max Ockner > From kim.barrett at oracle.com Thu Apr 2 22:36:19 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 2 Apr 2015 18:36:19 -0400 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: References: Message-ID: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> On Apr 2, 2015, at 12:06 PM, Volker Simonis wrote: > > while precompiled headers (PCH) are a nice and effective way of > improving hotspot build times Are we sure about that? Earlier today I ran into a local build failure that appeared to me to be possibly PCH-related. So I decided to try disabling PCH, since I now know about the option for doing so, from Volker's email. But I wanted to see how much slower my build times would be. Imagine my surprise when disabling PCH made my clean builds 10-15% *faster*. This is for a full jdk root "make images" build, which makes that much of a difference even more astonishing, because there's a lot more going on there than just compiling Hotspot. So how sure are we that PCH (or perhaps the way we are using it) provides any positive benefit at all? I'm pretty sure it's not doing anything good for me. For reference, my build configuration is Ubuntu 14.04 x86_64, reporting 24 processors. My configure options are --enable-ccache --with-debug-level=release --disable-zip-debug-info --disable-precompiled-headers -- new --with-jobs=24 I made sure to clear the ccache between each build. From serguei.spitsyn at oracle.com Fri Apr 3 00:03:07 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 02 Apr 2015 17:03:07 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. Message-ID: <551DD8BB.5040001@oracle.com> Please, review the jdk 8u60 backport for: https://bugs.openjdk.java.net/browse/JDK-8067662 8u60 hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 8u60 webrev for unit test update (the fix applies cleanly): http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 9 hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 9 webrev for unit test update: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 Summary: The 9 fix can not be applied cleanly so that I have to rework the fix a little bit. An NPE is trown in a thread dumping via JMX when doing CPU profiling in NetBeans Profiler and VisualVM. The issue is that the methods and related klass versions are not kept alive if a class redefinition takes place between catching a Throwable and taking a thread dump. It can result in loosing an obsolete method, and so, the reconstruction of method name becomes impossible. In such a case, the null reference is returned instead of a valid method name. The solution is to use current klass version and method orig_idnum instead of ordinary method idnum to find required method pointer. In the worst case when the related klass version is gone (was not included to or was removed from the previous_versions linked list), a saved method name CP index of the latest klass version can be used to restore the method name. The footprint extra overhead for this approach is u2 per stack frame. Testing in progress: In progress: nsk redefine classes tests, JTREG java/lang/instrument Thanks, Serguei From david.holmes at oracle.com Fri Apr 3 01:04:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Apr 2015 11:04:38 +1000 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: References: Message-ID: <551DE726.3060809@oracle.com> On 3/04/2015 2:06 AM, Volker Simonis wrote: > Hi, > > while precompiled headers (PCH) are a nice and effective way of > improving hotspot build times this feature also drastically increases IIUC PCH benefits incremental build times, not clean builds. It's useful for developer builds but not JPRT builds (or any official build). > the risk of introducing missing dependencies into the source base. > This is especially annoying on platforms where precompield headers > aren't available at all. > > In the last two weeks we had two cases [1,2] of such missing > dependencies which haven't been caught by JPRT because JPRT uses the > default platform settings and thus always uses PCHs on all platforms > where they are supported. > > I want to strongly advocate for a change in the JPRT configurations > such that at least on one Windows and one Linux platform the automatic > pre-integration builds are done with > "--with-debug-level=[slow/fast]debug --disable-precompiled-headers". One of the main areas where PCH hides problems is with the minimal VM, unfortunately the only builds that build the minimal VM are the embedded builds. Arguably we could add the minimal VM to a linux x86 build but we need to look at overall build times etc before making that the default. David > This simple change which comes at the minor cost of a few CPU-cycles > will save a big amount of (hopfully) much more precious developer > cycles and at the same time considerably improve the code quality. > Notice that I intentionally ask for a *debug build without PCHs > because debug builds exercise much more source code and are > specifically prone to missing include dependency errors. > > As this change can only be decided upon and implemented inside Oracle > I hereby kindly ask for an appropriate sponsor. > > Thank you and best regards, > Volker > > [1] > Introduced by: https://bugs.openjdk.java.net/browse/JDK-8075416 > Fixed by: https://bugs.openjdk.java.net/browse/JDK-8075735 > > [2] > Introduced by: https://bugs.openjdk.java.net/browse/JDK-8076314 > Fix proposed: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-April/012659.html > From stefan.karlsson at oracle.com Fri Apr 3 06:36:09 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 03 Apr 2015 08:36:09 +0200 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> Message-ID: <551E34D9.60508@oracle.com> On 2015-04-03 00:36, Kim Barrett wrote: > On Apr 2, 2015, at 12:06 PM, Volker Simonis wrote: >> while precompiled headers (PCH) are a nice and effective way of >> improving hotspot build times > Are we sure about that? I'm sure that my full builds are faster with PCH, while others report the opposite. These are the hotspot builds times I got a couple of months ago: slowdebug PCH real 1m9.998s user 12m0.437s sys 1m56.291s No PCH real 1m27.170s user 23m21.101s sys 1m43.651s product PCH real 1m19.933s user 17m54.229s sys 2m4.508s No PCH real 1m36.768s user 28m9.931s sys 1m46.288s > > Earlier today I ran into a local build failure that appeared to me to > be possibly PCH-related. > > So I decided to try disabling PCH, since I now know about the option > for doing so, from Volker's email. But I wanted to see how much > slower my build times would be. > > Imagine my surprise when disabling PCH made my clean builds 10-15% > *faster*. This is for a full jdk root "make images" build, which > makes that much of a difference even more astonishing, because there's > a lot more going on there than just compiling Hotspot. > > So how sure are we that PCH (or perhaps the way we are using it) > provides any positive benefit at all? I'm pretty sure it's not doing > anything good for me. > > For reference, my build configuration is Ubuntu 14.04 x86_64, > reporting 24 processors. My configure options are > > --enable-ccache > --with-debug-level=release > --disable-zip-debug-info > --disable-precompiled-headers -- new > --with-jobs=24 > > I made sure to clear the ccache between each build. IIRC, running without ccache is usually faster for me. StefanK From stefan.karlsson at oracle.com Fri Apr 3 06:39:29 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 03 Apr 2015 08:39:29 +0200 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <551DE726.3060809@oracle.com> References: <551DE726.3060809@oracle.com> Message-ID: <551E35A1.9010801@oracle.com> On 2015-04-03 03:04, David Holmes wrote: > On 3/04/2015 2:06 AM, Volker Simonis wrote: >> Hi, >> >> while precompiled headers (PCH) are a nice and effective way of >> improving hotspot build times this feature also drastically increases > > IIUC PCH benefits incremental build times, not clean builds. It's > useful for developer builds but not JPRT builds (or any official build). I don't think this is the case. Usually incremental builds with PCH force you to "unnecessarily" recompile more files than you really have to. If I know that I'm doing a lot of incremental changes to header files, I usually turn off PCH. StefanK > >> the risk of introducing missing dependencies into the source base. >> This is especially annoying on platforms where precompield headers >> aren't available at all. >> >> In the last two weeks we had two cases [1,2] of such missing >> dependencies which haven't been caught by JPRT because JPRT uses the >> default platform settings and thus always uses PCHs on all platforms >> where they are supported. >> >> I want to strongly advocate for a change in the JPRT configurations >> such that at least on one Windows and one Linux platform the automatic >> pre-integration builds are done with >> "--with-debug-level=[slow/fast]debug --disable-precompiled-headers". > > One of the main areas where PCH hides problems is with the minimal VM, > unfortunately the only builds that build the minimal VM are the > embedded builds. Arguably we could add the minimal VM to a linux x86 > build but we need to look at overall build times etc before making > that the default. > > David > >> This simple change which comes at the minor cost of a few CPU-cycles >> will save a big amount of (hopfully) much more precious developer >> cycles and at the same time considerably improve the code quality. >> Notice that I intentionally ask for a *debug build without PCHs >> because debug builds exercise much more source code and are >> specifically prone to missing include dependency errors. >> >> As this change can only be decided upon and implemented inside Oracle >> I hereby kindly ask for an appropriate sponsor. >> >> Thank you and best regards, >> Volker >> >> [1] >> Introduced by: https://bugs.openjdk.java.net/browse/JDK-8075416 >> Fixed by: https://bugs.openjdk.java.net/browse/JDK-8075735 >> >> [2] >> Introduced by: https://bugs.openjdk.java.net/browse/JDK-8076314 >> Fix proposed: >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-April/012659.html >> From thomas.stuefe at gmail.com Fri Apr 3 08:53:02 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 3 Apr 2015 10:53:02 +0200 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <551E34D9.60508@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551E34D9.60508@oracle.com> Message-ID: Hi, On Fri, Apr 3, 2015 at 8:36 AM, Stefan Karlsson wrote: > On 2015-04-03 00:36, Kim Barrett wrote: > >> On Apr 2, 2015, at 12:06 PM, Volker Simonis >> wrote: >> >>> while precompiled headers (PCH) are a nice and effective way of >>> improving hotspot build times >>> >> Are we sure about that? >> > > I'm sure that my full builds are faster with PCH, while others report the > opposite. > > These are the hotspot builds times I got a couple of months ago: > slowdebug > PCH > real 1m9.998s > user 12m0.437s > sys 1m56.291s > > No PCH > real 1m27.170s > user 23m21.101s > sys 1m43.651s > > > product > PCH > real 1m19.933s > user 17m54.229s > sys 2m4.508s > > No PCH > real 1m36.768s > user 28m9.931s > sys 1m46.288s > > For me its (slowdebug, pch) 4m10 vs (slowdebug, no pch) 4m54, so ~ 10% faster. That is for a total scratch build, which I seldom do. However, we should take into account lost time due to: - you need (or at least should) compile once from scratch without pch, before pushing your change, to ensure you do not break non-pch builds. Once JPRT is changed, this practice will become standard. - If you do not do that and break the build, add the time it takes others to track down your change and find the cause for the build error. Its quite annoying and IMHO not worth the seconds I save when building, therefore I disabled pch - at least on fast machines - a while ago. > >> Earlier today I ran into a local build failure that appeared to me to >> be possibly PCH-related. >> >> So I decided to try disabling PCH, since I now know about the option >> for doing so, from Volker's email. But I wanted to see how much >> slower my build times would be. >> >> Imagine my surprise when disabling PCH made my clean builds 10-15% >> *faster*. This is for a full jdk root "make images" build, which >> makes that much of a difference even more astonishing, because there's >> a lot more going on there than just compiling Hotspot. >> >> So how sure are we that PCH (or perhaps the way we are using it) >> provides any positive benefit at all? I'm pretty sure it's not doing >> anything good for me. >> >> For reference, my build configuration is Ubuntu 14.04 x86_64, >> reporting 24 processors. My configure options are >> >> --enable-ccache >> --with-debug-level=release >> --disable-zip-debug-info >> --disable-precompiled-headers -- new >> --with-jobs=24 >> >> I made sure to clear the ccache between each build. >> > > IIRC, running without ccache is usually faster for me. > > StefanK > ..Thomas From thomas.stuefe at gmail.com Fri Apr 3 09:42:03 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 3 Apr 2015 11:42:03 +0200 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <551D9AC6.50208@oracle.com> References: <551D9AC6.50208@oracle.com> Message-ID: Hi Max, Disclaimer: not a Reviewer. In thread.cpp, the code prints the value of Thread* pointer, not a thread id. So the code was correct before. That said, I find this pretty confusing, especially because it prints "tid=". Maybe one should change this or throw it away. -- As for vmError.cpp: this seems to be correct. However, I would like to see this abstracted somehow, here is why: The OpenJDK simply assumes thread id to be 32bit unsigned. This is not really portable and may bite us in the face (I am not sure if it already did, was not thread id 64bit on AIX? at least for kernel thread ids?). If you use pthread_t to implement thread id, like many ports do, thread id may be anything - 64bit number, array, struct. POSIX leaves that open. So, instead of a raw "%x", I propose as quick fix a format specifier for thread ids, e.g. "THREAD_ID_FORMAT". That way we could at least easily find all places where we print thread ids, if we later decide to change the type for thread ids. Regards, Thomas On Thu, Apr 2, 2015 at 9:38 PM, Max Ockner wrote: > Hello, > Please review this change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 > Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ > Summary: Existing error messages for vm crashes print the decimal > representation of the current thread id. The message format has been > changed to print the hex value of the thread id. > > Tested with jtreg runtime to make sure nothing was broken. I tested the > new functionality separately. I crashed the vm and examined the debugger > output to make sure the hexadecimal thread id printed in the error message > matched one of the threads listed by the debugger. > > Thanks, > Max > From dmitry.dmitriev at oracle.com Fri Apr 3 09:49:48 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 03 Apr 2015 12:49:48 +0300 Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 Message-ID: <551E623C.9060102@oracle.com> Hello, Please review this small fix for JDK-8076311. Also, I need a sponsor for this fix, who can push it, because I'm not have a OpenJDK name. Fix for JDK-6521376 add explicit processing of MaxTenuringThreshold XX option. When bad value for MaxTenuringThreshold is passed(e.g. negative value for unsigned option "-XX:MaxTenuringThreshold=-1"), then function print warning and continue execution with default value(0). This behavior differs from Java 8. Java 8 process this situation in common way for unsigned options, i.e. print waring and reports a error. So, I fix Java 9 MaxTenuringThreshold option processing. Also, I add new test case to the test/gc/arguments/TestInitialTenuringThreshold.java to test this situation. Open webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8076311/webrev.00/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8076311 Tested: JPRT Thank you, Dmitry From david.holmes at oracle.com Fri Apr 3 10:11:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Apr 2015 20:11:16 +1000 Subject: RFR: 8073989: Deprecated integer options are now recognized as obsolete. In-Reply-To: <551D8DC2.6010808@oracle.com> References: <55199108.9030102@oracle.com> <5519FFF4.1050507@oracle.com> <551D8DC2.6010808@oracle.com> Message-ID: <551E6744.4040402@oracle.com> Thanks looks good. David On 3/04/2015 4:43 AM, Max Ockner wrote: > I have rearranged the misplaced comments. > New Webrev: http://cr.openjdk.java.net/~mockner/8073989.3/ > > I still need one more (r)eviewer. > > Thanks, > Max > > On 3/30/2015 10:01 PM, David Holmes wrote: >> Hi Max, >> >> On 31/03/2015 4:08 AM, Max Ockner wrote: >>> Hello all, >>> Please review this change involving the handling of obsolete command >>> line flags. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073989 >>> Webrev: http://cr.openjdk.java.net/~mockner/8073989.2/ >> >> Argument processing seems to be a never ending source of bugs. >> >>> Summary: Three key components to this bug: >> >> Thanks for the detailed description! >> >>> (1) When is_newly_obsolete() checks for "SomeObsoleteIntegerFlag=100" in >>> the flag table, it is not recognized as a match with >>> "SomeObsoleteIntegerFlag" because the lengths are different. This has >>> been fixed. Arguments:process_argument() now strips everything except >>> for the arguments name. (example: -XX:+SomeBooleanFlag -> >>> "SomeBooleanFlag", and -XX:SomeIntegerFlag=100 -> "SomeIntegerFlag") >>> This stripped argument name (fittingly called stripped_argname) is now >>> passed into is_newly_obsolete, preventing the length check from failing >>> on obsolete (but formeerly valid) arguments. It also eliminates the need >>> for any case work and other string gymnastics from the the body of >>> is_newly_obsolete. If the argument is found to be newly obsolete, the >>> warning message now prints stripped_argname instead of argname to avoid >>> suggesting that "SomeBooleanFlag=100" was ever a supported option. >> >> So previously is_newly_obsolete handled +/- but despite the comment >> didn't really handle the flag=xxx form. So now before calling >> is_newly_obsolete the leading +/- or trailing = is stripped, so only >> the base argument name is actually checked. Ok. >> >> I think these comments were misplaced originally, and seem more so now: >> >> 874 // For locked flags, report a custom error message if available. >> 875 // Otherwise, report the standard unrecognized VM option. >> >> they belong after the is_newly_obsolete calling block, prior to: >> >> 883 Flag* found_flag = Flag::find_flag((const char*)argname, >> arg_len, true, true); >> 884 if (found_flag != NULL) { >> >>> (2) Some flags used to be defined in both the flags table and the >>> obsolete flags table. Because of this, those obsolete flags which were >>> also defined in the flags table could be fuzzy matched to provide better >>> error messages. Now that no flag is allowed to be in both tables, it is >>> pointless to attempt to fuzzy match an obsolete flag, since fuzzy >>> matching only looks in the flags table (not the obsolete flags table). >>> The section at the end of Arguments:process_argument in which fuzzy >>> matching is attempted on obsolete arguments no longer makes sense and >>> has been removed. >> >> Ok. >> >>> (3) ObsoleteFlagErrorMessage.java has been modified. The existing test >>> for an obsolete flag with appended junk no longer tests for fuzzy >>> matching, and a second test case has been added for integer valued >>> flags. >> >> Ok. The test will need to use a new "newly obsolete" flag in JDK 10. :) >> >> Reviewed! >> >> Thanks, >> David >> >>> Tested with jtreg runtime tests. >>> >>> Thanks, >>> Max Ockner > From max.ockner at oracle.com Fri Apr 3 15:55:59 2015 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 03 Apr 2015 11:55:59 -0400 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: References: <551D9AC6.50208@oracle.com> Message-ID: <551EB80F.2030406@oracle.com> Thomas, Thanks for pointing out the flaw in thread.cpp. I will fix that. I originally looked for an abstraction but couldn't find one. If you think it would be better to create a new format specifier, then I will do that as well. Max On 4/3/2015 5:42 AM, Thomas St?fe wrote: > Hi Max, > > Disclaimer: not a Reviewer. > > In thread.cpp, the code prints the value of Thread* pointer, not a > thread id. So the code was correct before. > > That said, I find this pretty confusing, especially because it prints > "tid=". Maybe one should change this or throw it away. > > -- > > As for vmError.cpp: this seems to be correct. > > However, I would like to see this abstracted somehow, here is why: > > The OpenJDK simply assumes thread id to be 32bit unsigned. This is not > really portable and may bite us in the face (I am not sure if it > already did, was not thread id 64bit on AIX? at least for kernel > thread ids?). > > If you use pthread_t to implement thread id, like many ports do, > thread id may be anything - 64bit number, array, struct. POSIX leaves > that open. > > So, instead of a raw "%x", I propose as quick fix a format specifier > for thread ids, e.g. "THREAD_ID_FORMAT". That way we could at least > easily find all places where we print thread ids, if we later decide > to change the type for thread ids. > > Regards, Thomas > > > On Thu, Apr 2, 2015 at 9:38 PM, Max Ockner > wrote: > > Hello, > Please review this change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 > Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ > > Summary: Existing error messages for vm crashes print the decimal > representation of the current thread id. The message format has > been changed to print the hex value of the thread id. > > Tested with jtreg runtime to make sure nothing was broken. I > tested the new functionality separately. I crashed the vm and > examined the debugger output to make sure the hexadecimal thread > id printed in the error message matched one of the threads listed > by the debugger. > > Thanks, > Max > > From thomas.stuefe at gmail.com Fri Apr 3 17:34:24 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 3 Apr 2015 19:34:24 +0200 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <551EB80F.2030406@oracle.com> References: <551D9AC6.50208@oracle.com> <551EB80F.2030406@oracle.com> Message-ID: Hi Max, I guess both would be fine: leave it at %x or add a new format specifier macro. We also could deal with a better abstraction for thread ids in a later change. ..Thomas On Fri, Apr 3, 2015 at 5:55 PM, Max Ockner wrote: > Thomas, > Thanks for pointing out the flaw in thread.cpp. I will fix that. > I originally looked for an abstraction but couldn't find one. If you think > it would be better to create a new format specifier, then I will do that as > well. > Max > > On 4/3/2015 5:42 AM, Thomas St?fe wrote: > > Hi Max, > > Disclaimer: not a Reviewer. > > In thread.cpp, the code prints the value of Thread* pointer, not a > thread id. So the code was correct before. > > That said, I find this pretty confusing, especially because it prints > "tid=". Maybe one should change this or throw it away. > > -- > > As for vmError.cpp: this seems to be correct. > > However, I would like to see this abstracted somehow, here is why: > > The OpenJDK simply assumes thread id to be 32bit unsigned. This is not > really portable and may bite us in the face (I am not sure if it already > did, was not thread id 64bit on AIX? at least for kernel thread ids?). > > If you use pthread_t to implement thread id, like many ports do, thread > id may be anything - 64bit number, array, struct. POSIX leaves that open. > > So, instead of a raw "%x", I propose as quick fix a format specifier for > thread ids, e.g. "THREAD_ID_FORMAT". That way we could at least easily find > all places where we print thread ids, if we later decide to change the type > for thread ids. > > Regards, Thomas > > > On Thu, Apr 2, 2015 at 9:38 PM, Max Ockner wrote: > >> Hello, >> Please review this change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >> Summary: Existing error messages for vm crashes print the decimal >> representation of the current thread id. The message format has been >> changed to print the hex value of the thread id. >> >> Tested with jtreg runtime to make sure nothing was broken. I tested the >> new functionality separately. I crashed the vm and examined the debugger >> output to make sure the hexadecimal thread id printed in the error message >> matched one of the threads listed by the debugger. >> >> Thanks, >> Max >> > > > From kim.barrett at oracle.com Fri Apr 3 19:13:35 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 3 Apr 2015 15:13:35 -0400 Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 In-Reply-To: <551E623C.9060102@oracle.com> References: <551E623C.9060102@oracle.com> Message-ID: On Apr 3, 2015, at 5:49 AM, Dmitry Dmitriev wrote: > > Hello, > > Please review this small fix for JDK-8076311. Also, I need a sponsor for this fix, who can push it, because I'm not have a OpenJDK name. > > Fix for JDK-6521376 add explicit processing of MaxTenuringThreshold XX option. When bad value for MaxTenuringThreshold is passed(e.g. negative value for unsigned option "-XX:MaxTenuringThreshold=-1"), then function print warning and continue execution with default value(0). This behavior differs from Java 8. Java 8 process this situation in common way for unsigned options, i.e. print waring and reports a error. So, I fix Java 9 MaxTenuringThreshold option processing. > > Also, I add new test case to the test/gc/arguments/TestInitialTenuringThreshold.java to test this situation. > > Open webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8076311/webrev.00/ > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8076311 > > Tested: JPRT Looks good. From dmitry.samersoff at oracle.com Fri Apr 3 20:32:46 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 03 Apr 2015 23:32:46 +0300 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> Message-ID: <551EF8EE.8090707@oracle.com> Kim, On my experience PCH significantly slow-down ccache-enabled build. Probably because ccache requires some tricks to work with PCH see: http://ccache.samba.org/manual.html#_precompiled_headers -Dmitry On 2015-04-03 01:36, Kim Barrett wrote: > On Apr 2, 2015, at 12:06 PM, Volker Simonis wrote: >> >> while precompiled headers (PCH) are a nice and effective way of >> improving hotspot build times > > Are we sure about that? > > Earlier today I ran into a local build failure that appeared to me to > be possibly PCH-related. > > So I decided to try disabling PCH, since I now know about the option > for doing so, from Volker's email. But I wanted to see how much > slower my build times would be. > > Imagine my surprise when disabling PCH made my clean builds 10-15% > *faster*. This is for a full jdk root "make images" build, which > makes that much of a difference even more astonishing, because there's > a lot more going on there than just compiling Hotspot. > > So how sure are we that PCH (or perhaps the way we are using it) > provides any positive benefit at all? I'm pretty sure it's not doing > anything good for me. > > For reference, my build configuration is Ubuntu 14.04 x86_64, > reporting 24 processors. My configure options are > > --enable-ccache > --with-debug-level=release > --disable-zip-debug-info > --disable-precompiled-headers -- new > --with-jobs=24 > > I made sure to clear the ccache between each build. > -- 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 jon.masamitsu at oracle.com Fri Apr 3 21:53:33 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 03 Apr 2015 14:53:33 -0700 Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 In-Reply-To: <551E623C.9060102@oracle.com> References: <551E623C.9060102@oracle.com> Message-ID: <551F0BDD.7020707@oracle.com> Dmitry, Change looks good. Reviewed. I can sponsor the push. Send the final patch once you have all your reviews. Jon On 4/3/2015 2:49 AM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix for JDK-8076311. Also, I need a sponsor > for this fix, who can push it, because I'm not have a OpenJDK name. > > Fix for JDK-6521376 add explicit processing of MaxTenuringThreshold XX > option. When bad value for MaxTenuringThreshold is passed(e.g. > negative value for unsigned option "-XX:MaxTenuringThreshold=-1"), > then function print warning and continue execution with default > value(0). This behavior differs from Java 8. Java 8 process this > situation in common way for unsigned options, i.e. print waring and > reports a error. So, I fix Java 9 MaxTenuringThreshold option processing. > > Also, I add new test case to the > test/gc/arguments/TestInitialTenuringThreshold.java to test this > situation. > > Open webrev: > http://cr.openjdk.java.net/~ctornqvi/webrev/8076311/webrev.00/ > > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8076311 > > Tested: JPRT > > Thank you, > Dmitry From thomas.stuefe at gmail.com Sun Apr 5 08:44:22 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 5 Apr 2015 10:44:22 +0200 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: References: <551D9AC6.50208@oracle.com> <551EB80F.2030406@oracle.com> Message-ID: Hi Max, sorry, I missed that current_thread_id() is defined as intx, which means that your change in vmError.cpp is not correct. %x will only print 32bit values. For hex values, I guess your best bet would be either PTR_FORMAT or something like SIZE_FORMAT_HEX, depending on whether you want to print the value with leading zeros or not. Regards, Thomas On Fri, Apr 3, 2015 at 7:34 PM, Thomas St?fe wrote: > Hi Max, > > I guess both would be fine: leave it at %x or add a new format specifier > macro. We also could deal with a better abstraction for thread ids in a > later change. > > ..Thomas > > On Fri, Apr 3, 2015 at 5:55 PM, Max Ockner wrote: > >> Thomas, >> Thanks for pointing out the flaw in thread.cpp. I will fix that. >> I originally looked for an abstraction but couldn't find one. If you >> think it would be better to create a new format specifier, then I will do >> that as well. >> Max >> >> On 4/3/2015 5:42 AM, Thomas St?fe wrote: >> >> Hi Max, >> >> Disclaimer: not a Reviewer. >> >> In thread.cpp, the code prints the value of Thread* pointer, not a >> thread id. So the code was correct before. >> >> That said, I find this pretty confusing, especially because it prints >> "tid=". Maybe one should change this or throw it away. >> >> -- >> >> As for vmError.cpp: this seems to be correct. >> >> However, I would like to see this abstracted somehow, here is why: >> >> The OpenJDK simply assumes thread id to be 32bit unsigned. This is not >> really portable and may bite us in the face (I am not sure if it already >> did, was not thread id 64bit on AIX? at least for kernel thread ids?). >> >> If you use pthread_t to implement thread id, like many ports do, thread >> id may be anything - 64bit number, array, struct. POSIX leaves that open. >> >> So, instead of a raw "%x", I propose as quick fix a format specifier >> for thread ids, e.g. "THREAD_ID_FORMAT". That way we could at least easily >> find all places where we print thread ids, if we later decide to change the >> type for thread ids. >> >> Regards, Thomas >> >> >> On Thu, Apr 2, 2015 at 9:38 PM, Max Ockner wrote: >> >>> Hello, >>> Please review this change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >>> Summary: Existing error messages for vm crashes print the decimal >>> representation of the current thread id. The message format has been >>> changed to print the hex value of the thread id. >>> >>> Tested with jtreg runtime to make sure nothing was broken. I tested the >>> new functionality separately. I crashed the vm and examined the debugger >>> output to make sure the hexadecimal thread id printed in the error message >>> matched one of the threads listed by the debugger. >>> >>> Thanks, >>> Max >>> >> >> >> > From dmitry.dmitriev at oracle.com Sun Apr 5 09:29:35 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Sun, 05 Apr 2015 12:29:35 +0300 Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 In-Reply-To: <551F0BDD.7020707@oracle.com> References: <551E623C.9060102@oracle.com> <551F0BDD.7020707@oracle.com> Message-ID: <5521007F.3060506@oracle.com> Jon, thank you for review and sponsorship! In review request I mention that I don't OpenJDK Author, but at Friday I got OpenJDK Author for JDK 9, so I will sent you a final patch with my commit. Thanks, Dmitry On 04.04.2015 0:53, Jon Masamitsu wrote: > Dmitry, > > Change looks good. > > Reviewed. > > I can sponsor the push. Send the final patch once you have all > your reviews. > > Jon > > > On 4/3/2015 2:49 AM, Dmitry Dmitriev wrote: >> Hello, >> >> Please review this small fix for JDK-8076311. Also, I need a sponsor >> for this fix, who can push it, because I'm not have a OpenJDK name. >> >> Fix for JDK-6521376 add explicit processing of MaxTenuringThreshold >> XX option. When bad value for MaxTenuringThreshold is passed(e.g. >> negative value for unsigned option "-XX:MaxTenuringThreshold=-1"), >> then function print warning and continue execution with default >> value(0). This behavior differs from Java 8. Java 8 process this >> situation in common way for unsigned options, i.e. print waring and >> reports a error. So, I fix Java 9 MaxTenuringThreshold option >> processing. >> >> Also, I add new test case to the >> test/gc/arguments/TestInitialTenuringThreshold.java to test this >> situation. >> >> Open webrev: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8076311/webrev.00/ >> >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8076311 >> >> Tested: JPRT >> >> Thank you, >> Dmitry > From serguei.spitsyn at oracle.com Mon Apr 6 23:50:07 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 06 Apr 2015 16:50:07 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <551DD8BB.5040001@oracle.com> References: <551DD8BB.5040001@oracle.com> Message-ID: <55231BAF.3030601@oracle.com> Coleen and Dan, I'm asking you as the jdk 9 reviewers... Please, let me know if you have any chance and plans to review this. Would it be enough to have just one (R) reviewer for a non-clean backport? Thanks, Serguei On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 8u60 backport for: > https://bugs.openjdk.java.net/browse/JDK-8067662 > > 8u60 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 > > > 8u60 webrev for unit test update (the fix applies cleanly): > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 > > > > > 9 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 > > > 9 webrev for unit test update: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 > > > > Summary: > The 9 fix can not be applied cleanly so that I have to rework the > fix a little bit. > > An NPE is trown in a thread dumping via JMX when doing CPU profiling > in NetBeans Profiler and VisualVM. > The issue is that the methods and related klass versions are not > kept alive if a class redefinition > takes place between catching a Throwable and taking a thread dump. > It can result in loosing an obsolete method, and so, the > reconstruction of method name becomes impossible. > In such a case, the null reference is returned instead of a valid > method name. > > The solution is to use current klass version and method orig_idnum > instead of ordinary method idnum > to find required method pointer. In the worst case when the related > klass version is gone > (was not included to or was removed from the previous_versions > linked list), a saved method name > CP index of the latest klass version can be used to restore the > method name. > The footprint extra overhead for this approach is u2 per stack frame. > > Testing in progress: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei > From david.holmes at oracle.com Tue Apr 7 01:10:40 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Apr 2015 11:10:40 +1000 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <551D9AC6.50208@oracle.com> References: <551D9AC6.50208@oracle.com> Message-ID: <55232E90.7060701@oracle.com> Hi Max, On 3/04/2015 5:38 AM, Max Ockner wrote: > Hello, > Please review this change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 > Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ > Summary: Existing error messages for vm crashes print the decimal > representation of the current thread id. The message format has been > changed to print the hex value of the thread id. src/share/vm/runtime/thread.cpp The change is incorrect and unnecessary. 'this' is a pointer type so INTPTR_FORMAT seems correct (though it may need p2i(this)?) while %x assumes 'this' is always 32-bit. Further INTPTR_FORMAT is already hex not decimal. src/share/vm/utilities/vmError.cpp As Thomas pointed out%x assumes 32-bit and so is incorrect for intx type. As intx is a typedef for intptr_t then INTPTR_FORMAT should be usable here as well. David > Tested with jtreg runtime to make sure nothing was broken. I tested the > new functionality separately. I crashed the vm and examined the debugger > output to make sure the hexadecimal thread id printed in the error > message matched one of the threads listed by the debugger. > > Thanks, > Max From coleen.phillimore at oracle.com Tue Apr 7 01:49:38 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 06 Apr 2015 21:49:38 -0400 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55231BAF.3030601@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> Message-ID: <552337B2.2080306@oracle.com> This backport looks good. Why didn't the patch apply cleanly? It seems mostly the same to me. Thanks, Coleen On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: > Coleen and Dan, > > I'm asking you as the jdk 9 reviewers... > > Please, let me know if you have any chance and plans to review this. > Would it be enough to have just one (R) reviewer for a non-clean > backport? > > Thanks, > Serguei > > > > On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 8u60 backport for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> 8u60 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >> >> >> 8u60 webrev for unit test update (the fix applies cleanly): >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >> >> >> >> >> 9 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >> >> >> 9 webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >> >> >> >> Summary: >> The 9 fix can not be applied cleanly so that I have to rework the >> fix a little bit. >> >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> Testing in progress: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Tue Apr 7 05:09:13 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 06 Apr 2015 22:09:13 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <552337B2.2080306@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> Message-ID: <55236679.1040807@oracle.com> Coleen, Thank you for looking at this! The main difference is in instanceKlass.cpp and instanceKlass.hpp. 8u60: +Method* InstanceKlass::method_with_orig_idnum(int idnum) { + if (idnum >= methods()->length()) { + return NULL; + } + Method* m = methods()->at(idnum); + if (m != NULL && m->orig_method_idnum() == idnum) { + return m; + } + // Obsolete method idnum does not match the original idnum + for (int index = 0; index < methods()->length(); ++index) { + m = methods()->at(index); + if (m->orig_method_idnum() == idnum) { + return m; + } + } + // None found, return null for the caller to handle. + return NULL; +} + + +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { + if (constants()->version() == version) { + return method_with_orig_idnum(idnum); + } + ConstantPoolCache* cp_cache = NULL; + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); + pv_node != NULL; pv_node = pvw.next_previous_version()) { + ConstantPool* prev_cp = pv_node->prev_constant_pool(); + if (prev_cp->version() == version) { + cp_cache = prev_cp->cache(); + break; + } + } + if (cp_cache == NULL) { + return NULL; // The pv_node is gone, no method is found + } + Method* method = NULL; + for (int i = 0; i < cp_cache->length(); i++) { + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); + method = entry->get_interesting_method_entry(this); + if (method == NULL) { + continue; // skip uninteresting entries + } + if (method->orig_method_idnum() == idnum) { + return method; + } + } + // None found, return null for the caller to handle. + return NULL; +} jdk 9: +Method* InstanceKlass::method_with_orig_idnum(int idnum) { + if (idnum >= methods()->length()) { + return NULL; + } + Method* m = methods()->at(idnum); + if (m != NULL && m->orig_method_idnum() == idnum) { + return m; + } + // Obsolete method idnum does not match the original idnum + for (int index = 0; index < methods()->length(); ++index) { + m = methods()->at(index); + if (m->orig_method_idnum() == idnum) { + return m; + } + } + // None found, return null for the caller to handle. + return NULL; +} + + +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { + InstanceKlass* holder = get_klass_version(version); + if (holder == NULL) { + return NULL; // The version of klass is gone, no method is found + } + Method* method = holder->method_with_orig_idnum(idnum); + return method; +} Thanks, Serguei On 4/6/15 6:49 PM, Coleen Phillimore wrote: > > This backport looks good. Why didn't the patch apply cleanly? It > seems mostly the same to me. > Thanks, > Coleen > > On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >> Coleen and Dan, >> >> I'm asking you as the jdk 9 reviewers... >> >> Please, let me know if you have any chance and plans to review this. >> Would it be enough to have just one (R) reviewer for a non-clean >> backport? >> >> Thanks, >> Serguei >> >> >> >> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 8u60 backport for: >>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>> >>> 8u60 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>> >>> >>> 8u60 webrev for unit test update (the fix applies cleanly): >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>> >>> >>> >>> >>> 9 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>> >>> >>> 9 webrev for unit test update: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>> >>> >>> >>> Summary: >>> The 9 fix can not be applied cleanly so that I have to rework the >>> fix a little bit. >>> >>> An NPE is trown in a thread dumping via JMX when doing CPU >>> profiling in NetBeans Profiler and VisualVM. >>> The issue is that the methods and related klass versions are not >>> kept alive if a class redefinition >>> takes place between catching a Throwable and taking a thread dump. >>> It can result in loosing an obsolete method, and so, the >>> reconstruction of method name becomes impossible. >>> In such a case, the null reference is returned instead of a valid >>> method name. >>> >>> The solution is to use current klass version and method orig_idnum >>> instead of ordinary method idnum >>> to find required method pointer. In the worst case when the >>> related klass version is gone >>> (was not included to or was removed from the previous_versions >>> linked list), a saved method name >>> CP index of the latest klass version can be used to restore the >>> method name. >>> The footprint extra overhead for this approach is u2 per stack frame. >>> >>> Testing in progress: >>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>> >>> >>> Thanks, >>> Serguei >>> >> > From per.liden at oracle.com Tue Apr 7 09:36:56 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 07 Apr 2015 11:36:56 +0200 Subject: RFR(xs): 8076534: CollectedHeapName in SA agent incorrect Message-ID: <5523A538.9070909@oracle.com> Hi, Could I please have someone review this minor fix. In a recent change made to CollectedHeap::Name, the Abstract member was removed (JDK-8076294). This patch removes the equivalent from the SA agent's CollectedHeapName and turns its CollectedHeap into an abstract class. Webrev: http://cr.openjdk.java.net/~pliden/8076534/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076534 Testing: jprt, manual runs with jmap -F -heap with all collectors /Per From dmitry.samersoff at oracle.com Tue Apr 7 10:03:13 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 07 Apr 2015 13:03:13 +0300 Subject: RFR(xs): 8076534: CollectedHeapName in SA agent incorrect In-Reply-To: <5523A538.9070909@oracle.com> References: <5523A538.9070909@oracle.com> Message-ID: <5523AB61.8040708@oracle.com> Looks good for me! -Dmitry On 2015-04-07 12:36, Per Liden wrote: > Hi, > > Could I please have someone review this minor fix. > > In a recent change made to CollectedHeap::Name, the Abstract member was > removed (JDK-8076294). This patch removes the equivalent from the SA > agent's CollectedHeapName and turns its CollectedHeap into an abstract > class. > > Webrev: http://cr.openjdk.java.net/~pliden/8076534/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076534 > > Testing: jprt, manual runs with jmap -F -heap with all collectors > > /Per > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Tue Apr 7 10:22:59 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 7 Apr 2015 12:22:59 +0200 Subject: RFR(xs): 8076534: CollectedHeapName in SA agent incorrect In-Reply-To: <5523A538.9070909@oracle.com> References: <5523A538.9070909@oracle.com> Message-ID: <24F7770B-D386-458C-8B64-CCBC44BB98DE@oracle.com> Looks good! Thanks, /Staffan > On 7 apr 2015, at 11:36, Per Liden wrote: > > Hi, > > Could I please have someone review this minor fix. > > In a recent change made to CollectedHeap::Name, the Abstract member was removed (JDK-8076294). This patch removes the equivalent from the SA agent's CollectedHeapName and turns its CollectedHeap into an abstract class. > > Webrev: http://cr.openjdk.java.net/~pliden/8076534/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076534 > > Testing: jprt, manual runs with jmap -F -heap with all collectors > > /Per > From david.simms at oracle.com Tue Apr 7 11:37:13 2015 From: david.simms at oracle.com (David Simms) Date: Tue, 07 Apr 2015 13:37:13 +0200 Subject: RFR (S) JNI Specification Issue: JDK-8034923 JNI: static linking assertions specs are incomplete and are in the wrong section of spec In-Reply-To: <551D0217.7090508@oracle.com> References: <551D0217.7090508@oracle.com> Message-ID: <5523C169.6030903@oracle.com> Couple of minor updates to the posted review * SINCE: JDK/JRE 1.8 tags on JNI_OnLoad_L and JNI_OnUnload_L * table mapping SE->JNI should use SE 6/7/8 not 6.0/7.0/8.0 * jniTOC.html: removed "Changes" link for ch.1. On 02/04/15 10:47, David Simms wrote: > > Greetings, > > JDK Bug: https://bugs.openjdk.java.net/browse/JDK-8034923 > > Web review: http://cr.openjdk.java.net/~dsimms/jnispec/8034923/ > > Original (for HTML comparison): > http://docs.oracle.com/javase/8/docs/technotes/guides/jni/index.html > > > Summary of changes: > > Wholly confined to documentation changes, no code modifications made: > > * The "index.html" has named a "JNI version" number which has never > been consistent. After some initial consultation with Stuart Marks > and Alex Buckley, we decided to remove version from the document. > o There are minor clarifications added to "enhancements.html" > and "GetVersion" function documentation, listing the platform > release mapped to JNI_VERSION_ constants. > * Added the missing "JNI_VERSION_1_8" constant to GetVersion constants. > * Moved most of the details regarding static library support (JEP > 178) from "Design - Compiling, Loading and Linking Native Methods" > to "Invocation API - Library and Version Management" > o Rewording to clearly delineate static vs dynamic linked > library load and unload hooks > o Emphasis on statically linked libraries requiring > "JNI_OnLoad_" hook. > o Typos, function declaration and linkage sections cleaned up. > * Reinstated the "Enhancements" links to JDK 1.2 & JDK 1.4 changes, > and added new files for 1.6 and 1.8. > > > Cheers > /David Simms From thomas.schatzl at oracle.com Tue Apr 7 13:20:35 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 07 Apr 2015 15:20:35 +0200 Subject: RFR(xs): 8076534: CollectedHeapName in SA agent incorrect In-Reply-To: <5523A538.9070909@oracle.com> References: <5523A538.9070909@oracle.com> Message-ID: <1428412835.3443.49.camel@oracle.com> Hi Per, On Tue, 2015-04-07 at 11:36 +0200, Per Liden wrote: > Hi, > > Could I please have someone review this minor fix. > > In a recent change made to CollectedHeap::Name, the Abstract member was > removed (JDK-8076294). This patch removes the equivalent from the SA > agent's CollectedHeapName and turns its CollectedHeap into an abstract > class. > > Webrev: http://cr.openjdk.java.net/~pliden/8076534/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076534 > > Testing: jprt, manual runs with jmap -F -heap with all collectors looks good. Thomas From per.liden at oracle.com Tue Apr 7 14:04:29 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 07 Apr 2015 16:04:29 +0200 Subject: RFR(xs): 8076534: CollectedHeapName in SA agent incorrect In-Reply-To: <5523AB61.8040708@oracle.com> References: <5523A538.9070909@oracle.com> <5523AB61.8040708@oracle.com> Message-ID: <5523E3ED.7070706@oracle.com> Thanks Dmitry! /Per On 2015-04-07 12:03, Dmitry Samersoff wrote: > Looks good for me! > > -Dmitry > > > On 2015-04-07 12:36, Per Liden wrote: >> Hi, >> >> Could I please have someone review this minor fix. >> >> In a recent change made to CollectedHeap::Name, the Abstract member was >> removed (JDK-8076294). This patch removes the equivalent from the SA >> agent's CollectedHeapName and turns its CollectedHeap into an abstract >> class. >> >> Webrev: http://cr.openjdk.java.net/~pliden/8076534/webrev.0/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076534 >> >> Testing: jprt, manual runs with jmap -F -heap with all collectors >> >> /Per >> > > From per.liden at oracle.com Tue Apr 7 14:04:43 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 07 Apr 2015 16:04:43 +0200 Subject: RFR(xs): 8076534: CollectedHeapName in SA agent incorrect In-Reply-To: <24F7770B-D386-458C-8B64-CCBC44BB98DE@oracle.com> References: <5523A538.9070909@oracle.com> <24F7770B-D386-458C-8B64-CCBC44BB98DE@oracle.com> Message-ID: <5523E3FB.6080001@oracle.com> Thanks Staffan! /Per On 2015-04-07 12:22, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 7 apr 2015, at 11:36, Per Liden wrote: >> >> Hi, >> >> Could I please have someone review this minor fix. >> >> In a recent change made to CollectedHeap::Name, the Abstract member was removed (JDK-8076294). This patch removes the equivalent from the SA agent's CollectedHeapName and turns its CollectedHeap into an abstract class. >> >> Webrev: http://cr.openjdk.java.net/~pliden/8076534/webrev.0/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076534 >> >> Testing: jprt, manual runs with jmap -F -heap with all collectors >> >> /Per >> > From per.liden at oracle.com Tue Apr 7 14:04:59 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 07 Apr 2015 16:04:59 +0200 Subject: RFR(xs): 8076534: CollectedHeapName in SA agent incorrect In-Reply-To: <1428412835.3443.49.camel@oracle.com> References: <5523A538.9070909@oracle.com> <1428412835.3443.49.camel@oracle.com> Message-ID: <5523E40B.9080306@oracle.com> Thanks Thomas! /Per On 2015-04-07 15:20, Thomas Schatzl wrote: > Hi Per, > > On Tue, 2015-04-07 at 11:36 +0200, Per Liden wrote: >> Hi, >> >> Could I please have someone review this minor fix. >> >> In a recent change made to CollectedHeap::Name, the Abstract member was >> removed (JDK-8076294). This patch removes the equivalent from the SA >> agent's CollectedHeapName and turns its CollectedHeap into an abstract >> class. >> >> Webrev: http://cr.openjdk.java.net/~pliden/8076534/webrev.0/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076534 >> >> Testing: jprt, manual runs with jmap -F -heap with all collectors > > looks good. > > Thomas > > From daniel.daugherty at oracle.com Tue Apr 7 16:44:37 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 07 Apr 2015 10:44:37 -0600 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <55135DE5.2010705@oracle.com> References: <55135DE5.2010705@oracle.com> Message-ID: <55240975.4080009@oracle.com> On 3/25/15 7:16 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8066679 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ > src/share/vm/prims/jvmtiRedefineClasses.cpp I concur that the old assertions are bad. They assume that the cached class file bytes on the scratch_class must match the cached class file bytes on the target class. That's a valid assumption in a RedefineClasses() only world, but that's not true when RetransformClasses() is used. This will be hard to test. I think the race can only happen on the first retransform of a class. If you have two parallel retransform threads, both see that there are no cached bytes so both cache the initial bytes and then both have to update the cached bytes pointer at about the same time... Very hard to do... Thumbs up. Dan > > > Summary: > > There can be multiple concurrent RetransformClasses calls on > different threads. > So that, the assert "cache ptrs must match" is incorrect as it was > based on wrong assumptions. > The fix removes two related asserts and also frees the scratch_class > cached_class_file_bytes > if it is necessary to avoid leaking the memory. > > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei > From daniel.daugherty at oracle.com Tue Apr 7 16:54:34 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 07 Apr 2015 10:54:34 -0600 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <551DD8BB.5040001@oracle.com> References: <551DD8BB.5040001@oracle.com> Message-ID: <55240BC9.8070500@oracle.com> On 4/2/15 6:03 PM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 8u60 backport for: > https://bugs.openjdk.java.net/browse/JDK-8067662 > > 8u60 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 > Nit - please update copyright years as needed before you push. src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/classfile/javaClasses.cpp No comments. src/share/vm/oops/instanceKlass.hpp No comments. src/share/vm/oops/instanceKlass.cpp No comments. Thumbs up. Dan > > 8u60 webrev for unit test update (the fix applies cleanly): > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 > > > > > 9 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 > > > 9 webrev for unit test update: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 > > > > Summary: > The 9 fix can not be applied cleanly so that I have to rework the > fix a little bit. > > An NPE is trown in a thread dumping via JMX when doing CPU profiling > in NetBeans Profiler and VisualVM. > The issue is that the methods and related klass versions are not > kept alive if a class redefinition > takes place between catching a Throwable and taking a thread dump. > It can result in loosing an obsolete method, and so, the > reconstruction of method name becomes impossible. > In such a case, the null reference is returned instead of a valid > method name. > > The solution is to use current klass version and method orig_idnum > instead of ordinary method idnum > to find required method pointer. In the worst case when the related > klass version is gone > (was not included to or was removed from the previous_versions > linked list), a saved method name > CP index of the latest klass version can be used to restore the > method name. > The footprint extra overhead for this approach is u2 per stack frame. > > Testing in progress: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei > > > From daniel.daugherty at oracle.com Tue Apr 7 16:59:54 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 07 Apr 2015 10:59:54 -0600 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55231BAF.3030601@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> Message-ID: <55240D0A.7000801@oracle.com> I _think_ you're OK with a single (R)eviewer for a backport even when minor changes are required, but I can never remember all these rules for sure... Dan On 4/6/15 5:50 PM, serguei.spitsyn at oracle.com wrote: > Coleen and Dan, > > I'm asking you as the jdk 9 reviewers... > > Please, let me know if you have any chance and plans to review this. > Would it be enough to have just one (R) reviewer for a non-clean > backport? > > Thanks, > Serguei > > > > On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 8u60 backport for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> 8u60 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >> >> >> 8u60 webrev for unit test update (the fix applies cleanly): >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >> >> >> >> >> 9 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >> >> >> 9 webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >> >> >> >> Summary: >> The 9 fix can not be applied cleanly so that I have to rework the >> fix a little bit. >> >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> Testing in progress: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> > > From coleen.phillimore at oracle.com Tue Apr 7 18:20:39 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 07 Apr 2015 14:20:39 -0400 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55236679.1040807@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> Message-ID: <55241FF7.3060801@oracle.com> I see. The PreviousVersionWalker is gone in 9 and you're using it to find the method. But this is only going to find the method if it happens to be in the cpCache somewhere. I think pv_node->prev_constant_pool()->pool_holder() is scratch_class (not 100% sure). In which case, you can look at that class to find the method with idnum. Coleen On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: > Coleen, > > Thank you for looking at this! > > The main difference is in instanceKlass.cpp and instanceKlass.hpp. > > 8u60: > +Method* InstanceKlass::method_with_orig_idnum(int idnum) { > + if (idnum >= methods()->length()) { > + return NULL; > + } > + Method* m = methods()->at(idnum); > + if (m != NULL && m->orig_method_idnum() == idnum) { > + return m; > + } > + // Obsolete method idnum does not match the original idnum > + for (int index = 0; index < methods()->length(); ++index) { > + m = methods()->at(index); > + if (m->orig_method_idnum() == idnum) { > + return m; > + } > + } > + // None found, return null for the caller to handle. > + return NULL; > +} > + > + > +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { > + if (constants()->version() == version) { > + return method_with_orig_idnum(idnum); > + } > + ConstantPoolCache* cp_cache = NULL; > + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); > + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); > + pv_node != NULL; pv_node = pvw.next_previous_version()) { > + ConstantPool* prev_cp = pv_node->prev_constant_pool(); > + if (prev_cp->version() == version) { > + cp_cache = prev_cp->cache(); > + break; > + } > + } > + if (cp_cache == NULL) { > + return NULL; // The pv_node is gone, no method is found > + } > + Method* method = NULL; > + for (int i = 0; i < cp_cache->length(); i++) { > + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); > + method = entry->get_interesting_method_entry(this); > + if (method == NULL) { > + continue; // skip uninteresting entries > + } > + if (method->orig_method_idnum() == idnum) { > + return method; > + } > + } > + // None found, return null for the caller to handle. > + return NULL; > +} > > > jdk 9: > > +Method* InstanceKlass::method_with_orig_idnum(int idnum) { > + if (idnum >= methods()->length()) { > + return NULL; > + } > + Method* m = methods()->at(idnum); > + if (m != NULL && m->orig_method_idnum() == idnum) { > + return m; > + } > + // Obsolete method idnum does not match the original idnum > + for (int index = 0; index < methods()->length(); ++index) { > + m = methods()->at(index); > + if (m->orig_method_idnum() == idnum) { > + return m; > + } > + } > + // None found, return null for the caller to handle. > + return NULL; > +} > + > + > +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { > + InstanceKlass* holder = get_klass_version(version); > + if (holder == NULL) { > + return NULL; // The version of klass is gone, no method is found > + } > + Method* method = holder->method_with_orig_idnum(idnum); > + return method; > +} > > > Thanks, > Serguei > > > On 4/6/15 6:49 PM, Coleen Phillimore wrote: >> >> This backport looks good. Why didn't the patch apply cleanly? It >> seems mostly the same to me. >> Thanks, >> Coleen >> >> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>> Coleen and Dan, >>> >>> I'm asking you as the jdk 9 reviewers... >>> >>> Please, let me know if you have any chance and plans to review this. >>> Would it be enough to have just one (R) reviewer for a non-clean >>> backport? >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the jdk 8u60 backport for: >>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>> >>>> 8u60 hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>> >>>> >>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>> >>>> >>>> >>>> >>>> 9 hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>> >>>> >>>> 9 webrev for unit test update: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>> >>>> >>>> >>>> Summary: >>>> The 9 fix can not be applied cleanly so that I have to rework the >>>> fix a little bit. >>>> >>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>> profiling in NetBeans Profiler and VisualVM. >>>> The issue is that the methods and related klass versions are not >>>> kept alive if a class redefinition >>>> takes place between catching a Throwable and taking a thread dump. >>>> It can result in loosing an obsolete method, and so, the >>>> reconstruction of method name becomes impossible. >>>> In such a case, the null reference is returned instead of a valid >>>> method name. >>>> >>>> The solution is to use current klass version and method >>>> orig_idnum instead of ordinary method idnum >>>> to find required method pointer. In the worst case when the >>>> related klass version is gone >>>> (was not included to or was removed from the previous_versions >>>> linked list), a saved method name >>>> CP index of the latest klass version can be used to restore the >>>> method name. >>>> The footprint extra overhead for this approach is u2 per stack >>>> frame. >>>> >>>> Testing in progress: >>>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Apr 7 20:14:18 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 13:14:18 -0700 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <55240975.4080009@oracle.com> References: <55135DE5.2010705@oracle.com> <55240975.4080009@oracle.com> Message-ID: <55243A9A.6060603@oracle.com> Great Thanks, Dan! Serguei On 4/7/15 9:44 AM, Daniel D. Daugherty wrote: > On 3/25/15 7:16 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8066679 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ >> > > src/share/vm/prims/jvmtiRedefineClasses.cpp > I concur that the old assertions are bad. They assume that > the cached class file bytes on the scratch_class must match > the cached class file bytes on the target class. That's a > valid assumption in a RedefineClasses() only world, but that's > not true when RetransformClasses() is used. > > This will be hard to test. I think the race can only happen > on the first retransform of a class. If you have two parallel > retransform threads, both see that there are no cached bytes > so both cache the initial bytes and then both have to update > the cached bytes pointer at about the same time... Very hard > to do... > > Thumbs up. > > Dan > > >> >> >> Summary: >> >> There can be multiple concurrent RetransformClasses calls on >> different threads. >> So that, the assert "cache ptrs must match" is incorrect as it was >> based on wrong assumptions. >> The fix removes two related asserts and also frees the >> scratch_class cached_class_file_bytes >> if it is necessary to avoid leaking the memory. >> >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Tue Apr 7 20:15:37 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 13:15:37 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55240BC9.8070500@oracle.com> References: <551DD8BB.5040001@oracle.com> <55240BC9.8070500@oracle.com> Message-ID: <55243AE9.9090502@oracle.com> Dan, thank you for the review! On 4/7/15 9:54 AM, Daniel D. Daugherty wrote: > On 4/2/15 6:03 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 8u60 backport for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> 8u60 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >> > > Nit - please update copyright years as needed before you push. Sure, that's the plan. Thanks, Serguei > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/classfile/javaClasses.cpp > No comments. > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > No comments. > > > Thumbs up. > > Dan > > > > >> >> 8u60 webrev for unit test update (the fix applies cleanly): >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >> >> >> >> >> 9 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >> >> >> 9 webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >> >> >> >> Summary: >> The 9 fix can not be applied cleanly so that I have to rework the >> fix a little bit. >> >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> Testing in progress: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> >> >> > From serguei.spitsyn at oracle.com Tue Apr 7 20:17:28 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 13:17:28 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55240D0A.7000801@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <55240D0A.7000801@oracle.com> Message-ID: <55243B58.8040709@oracle.com> Ok, thanks! Serguei On 4/7/15 9:59 AM, Daniel D. Daugherty wrote: > I _think_ you're OK with a single (R)eviewer for a backport even > when minor changes are required, but I can never remember all these > rules for sure... > > Dan > > > On 4/6/15 5:50 PM, serguei.spitsyn at oracle.com wrote: >> Coleen and Dan, >> >> I'm asking you as the jdk 9 reviewers... >> >> Please, let me know if you have any chance and plans to review this. >> Would it be enough to have just one (R) reviewer for a non-clean >> backport? >> >> Thanks, >> Serguei >> >> >> >> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 8u60 backport for: >>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>> >>> 8u60 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>> >>> >>> 8u60 webrev for unit test update (the fix applies cleanly): >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>> >>> >>> >>> >>> 9 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>> >>> >>> 9 webrev for unit test update: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>> >>> >>> >>> Summary: >>> The 9 fix can not be applied cleanly so that I have to rework the >>> fix a little bit. >>> >>> An NPE is trown in a thread dumping via JMX when doing CPU >>> profiling in NetBeans Profiler and VisualVM. >>> The issue is that the methods and related klass versions are not >>> kept alive if a class redefinition >>> takes place between catching a Throwable and taking a thread dump. >>> It can result in loosing an obsolete method, and so, the >>> reconstruction of method name becomes impossible. >>> In such a case, the null reference is returned instead of a valid >>> method name. >>> >>> The solution is to use current klass version and method orig_idnum >>> instead of ordinary method idnum >>> to find required method pointer. In the worst case when the >>> related klass version is gone >>> (was not included to or was removed from the previous_versions >>> linked list), a saved method name >>> CP index of the latest klass version can be used to restore the >>> method name. >>> The footprint extra overhead for this approach is u2 per stack frame. >>> >>> Testing in progress: >>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>> >>> >>> Thanks, >>> Serguei >>> >> >> > From serguei.spitsyn at oracle.com Tue Apr 7 21:01:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 14:01:35 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55241FF7.3060801@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> Message-ID: <552445AF.50209@oracle.com> On 4/7/15 11:20 AM, Coleen Phillimore wrote: > > ?I see. The PreviousVersionWalker is gone in 9 and you're using it to > find the method. > > But this is only going to find the method if it happens to be in the > cpCache somewhere. I think > pv_node->prev_constant_pool()->pool_holder() is scratch_class (not > 100% sure). In which case, you can look at that class to find the > method with idnum. I'm not 100% sure either. Ok, I will check if using the prev_constant_pool()->pool_holder() is going to work. It'd make it more consistent with the jdk 9 fix. Important part is that at least the saved cpref can be used to find method name in the the_class cpool if the attempt to find in the previous list cpCaches was unsuccessful. Thanks, Serguei > > Coleen > > On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> Thank you for looking at this! >> >> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >> >> 8u60: >> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >> + if (idnum >= methods()->length()) { >> + return NULL; >> + } >> + Method* m = methods()->at(idnum); >> + if (m != NULL && m->orig_method_idnum() == idnum) { >> + return m; >> + } >> + // Obsolete method idnum does not match the original idnum >> + for (int index = 0; index < methods()->length(); ++index) { >> + m = methods()->at(index); >> + if (m->orig_method_idnum() == idnum) { >> + return m; >> + } >> + } >> + // None found, return null for the caller to handle. >> + return NULL; >> +} >> + >> + >> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >> + if (constants()->version() == version) { >> + return method_with_orig_idnum(idnum); >> + } >> + ConstantPoolCache* cp_cache = NULL; >> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >> + if (prev_cp->version() == version) { >> + cp_cache = prev_cp->cache(); >> + break; >> + } >> + } >> + if (cp_cache == NULL) { >> + return NULL; // The pv_node is gone, no method is found >> + } >> + Method* method = NULL; >> + for (int i = 0; i < cp_cache->length(); i++) { >> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >> + method = entry->get_interesting_method_entry(this); >> + if (method == NULL) { >> + continue; // skip uninteresting entries >> + } >> + if (method->orig_method_idnum() == idnum) { >> + return method; >> + } >> + } >> + // None found, return null for the caller to handle. >> + return NULL; >> +} >> >> >> jdk 9: >> >> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >> + if (idnum >= methods()->length()) { >> + return NULL; >> + } >> + Method* m = methods()->at(idnum); >> + if (m != NULL && m->orig_method_idnum() == idnum) { >> + return m; >> + } >> + // Obsolete method idnum does not match the original idnum >> + for (int index = 0; index < methods()->length(); ++index) { >> + m = methods()->at(index); >> + if (m->orig_method_idnum() == idnum) { >> + return m; >> + } >> + } >> + // None found, return null for the caller to handle. >> + return NULL; >> +} >> + >> + >> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >> + InstanceKlass* holder = get_klass_version(version); >> + if (holder == NULL) { >> + return NULL; // The version of klass is gone, no method is found >> + } >> + Method* method = holder->method_with_orig_idnum(idnum); >> + return method; >> +} >> >> >> Thanks, >> Serguei >> >> >> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>> >>> This backport looks good. Why didn't the patch apply cleanly? It >>> seems mostly the same to me. >>> Thanks, >>> Coleen >>> >>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>> Coleen and Dan, >>>> >>>> I'm asking you as the jdk 9 reviewers... >>>> >>>> Please, let me know if you have any chance and plans to review this. >>>> Would it be enough to have just one (R) reviewer for a non-clean >>>> backport? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the jdk 8u60 backport for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>> >>>>> 8u60 hotspot webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>> >>>>> >>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>> >>>>> >>>>> >>>>> >>>>> 9 hotspot webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>> >>>>> >>>>> 9 webrev for unit test update: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>> >>>>> >>>>> >>>>> Summary: >>>>> The 9 fix can not be applied cleanly so that I have to rework >>>>> the fix a little bit. >>>>> >>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>> profiling in NetBeans Profiler and VisualVM. >>>>> The issue is that the methods and related klass versions are not >>>>> kept alive if a class redefinition >>>>> takes place between catching a Throwable and taking a thread dump. >>>>> It can result in loosing an obsolete method, and so, the >>>>> reconstruction of method name becomes impossible. >>>>> In such a case, the null reference is returned instead of a >>>>> valid method name. >>>>> >>>>> The solution is to use current klass version and method >>>>> orig_idnum instead of ordinary method idnum >>>>> to find required method pointer. In the worst case when the >>>>> related klass version is gone >>>>> (was not included to or was removed from the previous_versions >>>>> linked list), a saved method name >>>>> CP index of the latest klass version can be used to restore the >>>>> method name. >>>>> The footprint extra overhead for this approach is u2 per stack >>>>> frame. >>>>> >>>>> Testing in progress: >>>>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Apr 8 01:07:57 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 18:07:57 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <552445AF.50209@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> Message-ID: <55247F6D.5090003@oracle.com> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: > On 4/7/15 11:20 AM, Coleen Phillimore wrote: >> >> ?I see. The PreviousVersionWalker is gone in 9 and you're using it >> to find the method. >> >> But this is only going to find the method if it happens to be in the >> cpCache somewhere. I think >> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not >> 100% sure). In which case, you can look at that class to find the >> method with idnum. > I'm not 100% sure either. > Ok, I will check if using the prev_constant_pool()->pool_holder() is > going to work. > It'd make it more consistent with the jdk 9 fix. This is the updated webrev. It is more consistent with the jdk 9 fix. Thank you for the suggestion! Thanks, Serguei > > Important part is that at least the saved cpref can be used to find > method name in the > the_class cpool if the attempt to find in the previous list cpCaches > was unsuccessful. > > Thanks, > Serguei > >> >> Coleen >> >> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>> Coleen, >>> >>> Thank you for looking at this! >>> >>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>> >>> 8u60: >>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>> + if (idnum >= methods()->length()) { >>> + return NULL; >>> + } >>> + Method* m = methods()->at(idnum); >>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>> + return m; >>> + } >>> + // Obsolete method idnum does not match the original idnum >>> + for (int index = 0; index < methods()->length(); ++index) { >>> + m = methods()->at(index); >>> + if (m->orig_method_idnum() == idnum) { >>> + return m; >>> + } >>> + } >>> + // None found, return null for the caller to handle. >>> + return NULL; >>> +} >>> + >>> + >>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>> + if (constants()->version() == version) { >>> + return method_with_orig_idnum(idnum); >>> + } >>> + ConstantPoolCache* cp_cache = NULL; >>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>> + if (prev_cp->version() == version) { >>> + cp_cache = prev_cp->cache(); >>> + break; >>> + } >>> + } >>> + if (cp_cache == NULL) { >>> + return NULL; // The pv_node is gone, no method is found >>> + } >>> + Method* method = NULL; >>> + for (int i = 0; i < cp_cache->length(); i++) { >>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>> + method = entry->get_interesting_method_entry(this); >>> + if (method == NULL) { >>> + continue; // skip uninteresting entries >>> + } >>> + if (method->orig_method_idnum() == idnum) { >>> + return method; >>> + } >>> + } >>> + // None found, return null for the caller to handle. >>> + return NULL; >>> +} >>> >>> >>> jdk 9: >>> >>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>> + if (idnum >= methods()->length()) { >>> + return NULL; >>> + } >>> + Method* m = methods()->at(idnum); >>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>> + return m; >>> + } >>> + // Obsolete method idnum does not match the original idnum >>> + for (int index = 0; index < methods()->length(); ++index) { >>> + m = methods()->at(index); >>> + if (m->orig_method_idnum() == idnum) { >>> + return m; >>> + } >>> + } >>> + // None found, return null for the caller to handle. >>> + return NULL; >>> +} >>> + >>> + >>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>> + InstanceKlass* holder = get_klass_version(version); >>> + if (holder == NULL) { >>> + return NULL; // The version of klass is gone, no method is found >>> + } >>> + Method* method = holder->method_with_orig_idnum(idnum); >>> + return method; >>> +} >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>> >>>> This backport looks good. Why didn't the patch apply cleanly? It >>>> seems mostly the same to me. >>>> Thanks, >>>> Coleen >>>> >>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>> Coleen and Dan, >>>>> >>>>> I'm asking you as the jdk 9 reviewers... >>>>> >>>>> Please, let me know if you have any chance and plans to review this. >>>>> Would it be enough to have just one (R) reviewer for a non-clean >>>>> backport? >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the jdk 8u60 backport for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>> >>>>>> 8u60 hotspot webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>> >>>>>> >>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 9 hotspot webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>> >>>>>> >>>>>> 9 webrev for unit test update: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> The 9 fix can not be applied cleanly so that I have to rework >>>>>> the fix a little bit. >>>>>> >>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>> The issue is that the methods and related klass versions are >>>>>> not kept alive if a class redefinition >>>>>> takes place between catching a Throwable and taking a thread dump. >>>>>> It can result in loosing an obsolete method, and so, the >>>>>> reconstruction of method name becomes impossible. >>>>>> In such a case, the null reference is returned instead of a >>>>>> valid method name. >>>>>> >>>>>> The solution is to use current klass version and method >>>>>> orig_idnum instead of ordinary method idnum >>>>>> to find required method pointer. In the worst case when the >>>>>> related klass version is gone >>>>>> (was not included to or was removed from the previous_versions >>>>>> linked list), a saved method name >>>>>> CP index of the latest klass version can be used to restore the >>>>>> method name. >>>>>> The footprint extra overhead for this approach is u2 per stack >>>>>> frame. >>>>>> >>>>>> Testing in progress: >>>>>> In progress: nsk redefine classes tests, JTREG >>>>>> java/lang/instrument >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Apr 8 01:09:31 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 18:09:31 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55247F6D.5090003@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> Message-ID: <55247FCB.6050000@oracle.com> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: > > > On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>> >>> ?I see. The PreviousVersionWalker is gone in 9 and you're using it >>> to find the method. >>> >>> But this is only going to find the method if it happens to be in the >>> cpCache somewhere. I think >>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not >>> 100% sure). In which case, you can look at that class to find the >>> method with idnum. >> I'm not 100% sure either. >> Ok, I will check if using the prev_constant_pool()->pool_holder() is >> going to work. >> It'd make it more consistent with the jdk 9 fix. > > This is the updated webrev. Sorry, forgot to paste the link: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ Thanks, Serguei > It is more consistent with the jdk 9 fix. > Thank you for the suggestion! > > Thanks, > Serguei > >> >> Important part is that at least the saved cpref can be used to find >> method name in the >> the_class cpool if the attempt to find in the previous list cpCaches >> was unsuccessful. >> >> Thanks, >> Serguei >> >>> >>> Coleen >>> >>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>> Coleen, >>>> >>>> Thank you for looking at this! >>>> >>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>> >>>> 8u60: >>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>> + if (idnum >= methods()->length()) { >>>> + return NULL; >>>> + } >>>> + Method* m = methods()->at(idnum); >>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>> + return m; >>>> + } >>>> + // Obsolete method idnum does not match the original idnum >>>> + for (int index = 0; index < methods()->length(); ++index) { >>>> + m = methods()->at(index); >>>> + if (m->orig_method_idnum() == idnum) { >>>> + return m; >>>> + } >>>> + } >>>> + // None found, return null for the caller to handle. >>>> + return NULL; >>>> +} >>>> + >>>> + >>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>> + if (constants()->version() == version) { >>>> + return method_with_orig_idnum(idnum); >>>> + } >>>> + ConstantPoolCache* cp_cache = NULL; >>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>> + if (prev_cp->version() == version) { >>>> + cp_cache = prev_cp->cache(); >>>> + break; >>>> + } >>>> + } >>>> + if (cp_cache == NULL) { >>>> + return NULL; // The pv_node is gone, no method is found >>>> + } >>>> + Method* method = NULL; >>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>> + method = entry->get_interesting_method_entry(this); >>>> + if (method == NULL) { >>>> + continue; // skip uninteresting entries >>>> + } >>>> + if (method->orig_method_idnum() == idnum) { >>>> + return method; >>>> + } >>>> + } >>>> + // None found, return null for the caller to handle. >>>> + return NULL; >>>> +} >>>> >>>> >>>> jdk 9: >>>> >>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>> + if (idnum >= methods()->length()) { >>>> + return NULL; >>>> + } >>>> + Method* m = methods()->at(idnum); >>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>> + return m; >>>> + } >>>> + // Obsolete method idnum does not match the original idnum >>>> + for (int index = 0; index < methods()->length(); ++index) { >>>> + m = methods()->at(index); >>>> + if (m->orig_method_idnum() == idnum) { >>>> + return m; >>>> + } >>>> + } >>>> + // None found, return null for the caller to handle. >>>> + return NULL; >>>> +} >>>> + >>>> + >>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>> + InstanceKlass* holder = get_klass_version(version); >>>> + if (holder == NULL) { >>>> + return NULL; // The version of klass is gone, no method is found >>>> + } >>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>> + return method; >>>> +} >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>> >>>>> This backport looks good. Why didn't the patch apply cleanly? It >>>>> seems mostly the same to me. >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Coleen and Dan, >>>>>> >>>>>> I'm asking you as the jdk 9 reviewers... >>>>>> >>>>>> Please, let me know if you have any chance and plans to review this. >>>>>> Would it be enough to have just one (R) reviewer for a non-clean >>>>>> backport? >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the jdk 8u60 backport for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>> >>>>>>> 8u60 hotspot webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>> >>>>>>> >>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 9 hotspot webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>> >>>>>>> >>>>>>> 9 webrev for unit test update: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> The 9 fix can not be applied cleanly so that I have to rework >>>>>>> the fix a little bit. >>>>>>> >>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>> The issue is that the methods and related klass versions are >>>>>>> not kept alive if a class redefinition >>>>>>> takes place between catching a Throwable and taking a thread >>>>>>> dump. >>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>> reconstruction of method name becomes impossible. >>>>>>> In such a case, the null reference is returned instead of a >>>>>>> valid method name. >>>>>>> >>>>>>> The solution is to use current klass version and method >>>>>>> orig_idnum instead of ordinary method idnum >>>>>>> to find required method pointer. In the worst case when the >>>>>>> related klass version is gone >>>>>>> (was not included to or was removed from the previous_versions >>>>>>> linked list), a saved method name >>>>>>> CP index of the latest klass version can be used to restore >>>>>>> the method name. >>>>>>> The footprint extra overhead for this approach is u2 per stack >>>>>>> frame. >>>>>>> >>>>>>> Testing in progress: >>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>> java/lang/instrument >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>> >>>>> >>>> >>> >> > From dmitry.dmitriev at oracle.com Wed Apr 8 06:40:21 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Tue, 7 Apr 2015 23:40:21 -0700 (PDT) Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 Message-ID: Hello, I am need one more Reviewer. Can someone review this patch? Thanks! Dmitry ----- Original Message ----- From: dmitry.dmitriev at oracle.com To: hotspot-dev at openjdk.java.net Sent: Friday, April 3, 2015 12:50:28 PM GMT +03:00 Iraq Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 Hello, Please review this small fix for JDK-8076311. Also, I need a sponsor for this fix, who can push it, because I'm not have a OpenJDK name. Fix for JDK-6521376 add explicit processing of MaxTenuringThreshold XX option. When bad value for MaxTenuringThreshold is passed(e.g. negative value for unsigned option "-XX:MaxTenuringThreshold=-1"), then function print warning and continue execution with default value(0). This behavior differs from Java 8. Java 8 process this situation in common way for unsigned options, i.e. print waring and reports a error. So, I fix Java 9 MaxTenuringThreshold option processing. Also, I add new test case to the test/gc/arguments/TestInitialTenuringThreshold.java to test this situation. Open webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8076311/webrev.00/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8076311 Tested: JPRT Thank you, Dmitry From david.holmes at oracle.com Wed Apr 8 06:57:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Apr 2015 16:57:51 +1000 Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 In-Reply-To: References: Message-ID: <5524D16F.2010703@oracle.com> On 8/04/2015 4:40 PM, Dmitry Dmitriev wrote: > Hello, > > I am need one more Reviewer. Can someone review this patch? Thanks! Looks okay. In comparing to JDK 8 I note there is no longer a maximum MaxTenuringThreshold enforced, so presumably only negative values are illegal now. Thanks, David > Dmitry > > ----- Original Message ----- > From: dmitry.dmitriev at oracle.com > To: hotspot-dev at openjdk.java.net > Sent: Friday, April 3, 2015 12:50:28 PM GMT +03:00 Iraq > Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 > > Hello, > > Please review this small fix for JDK-8076311. Also, I need a sponsor for > this fix, who can push it, because I'm not have a OpenJDK name. > > Fix for JDK-6521376 add explicit processing of MaxTenuringThreshold XX > option. When bad value for MaxTenuringThreshold is passed(e.g. negative > value for unsigned option "-XX:MaxTenuringThreshold=-1"), then function > print warning and continue execution with default value(0). This > behavior differs from Java 8. Java 8 process this situation in common > way for unsigned options, i.e. print waring and reports a error. So, I > fix Java 9 MaxTenuringThreshold option processing. > > Also, I add new test case to the > test/gc/arguments/TestInitialTenuringThreshold.java to test this situation. > > Open webrev: > http://cr.openjdk.java.net/~ctornqvi/webrev/8076311/webrev.00/ > > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8076311 > > Tested: JPRT > > Thank you, > Dmitry > From dmitry.dmitriev at oracle.com Wed Apr 8 07:21:51 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 8 Apr 2015 00:21:51 -0700 (PDT) Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 Message-ID: <07f16cad-edc0-4f4f-9ec3-00306e213878@default> Thank you, David! About maximum MaxTenuringThreshold - as I see it still exist in JDK 9, but currently it equal to 16(was 15 in JDK 8). Check for inverval is exist in Arguments::check_vm_args_consistency() function. Regards, Dmitry ----- Original Message ----- From: david.holmes at oracle.com To: dmitry.dmitriev at oracle.com, hotspot-dev at openjdk.java.net Sent: Wednesday, April 8, 2015 9:57:58 AM GMT +03:00 Iraq Subject: Re: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 On 8/04/2015 4:40 PM, Dmitry Dmitriev wrote: > Hello, > > I am need one more Reviewer. Can someone review this patch? Thanks! Looks okay. In comparing to JDK 8 I note there is no longer a maximum MaxTenuringThreshold enforced, so presumably only negative values are illegal now. Thanks, David > Dmitry > > ----- Original Message ----- > From: dmitry.dmitriev at oracle.com > To: hotspot-dev at openjdk.java.net > Sent: Friday, April 3, 2015 12:50:28 PM GMT +03:00 Iraq > Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 > > Hello, > > Please review this small fix for JDK-8076311. Also, I need a sponsor for > this fix, who can push it, because I'm not have a OpenJDK name. > > Fix for JDK-6521376 add explicit processing of MaxTenuringThreshold XX > option. When bad value for MaxTenuringThreshold is passed(e.g. negative > value for unsigned option "-XX:MaxTenuringThreshold=-1"), then function > print warning and continue execution with default value(0). This > behavior differs from Java 8. Java 8 process this situation in common > way for unsigned options, i.e. print waring and reports a error. So, I > fix Java 9 MaxTenuringThreshold option processing. > > Also, I add new test case to the > test/gc/arguments/TestInitialTenuringThreshold.java to test this situation. > > Open webrev: > http://cr.openjdk.java.net/~ctornqvi/webrev/8076311/webrev.00/ > > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8076311 > > Tested: JPRT > > Thank you, > Dmitry > From david.holmes at oracle.com Wed Apr 8 08:01:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Apr 2015 18:01:53 +1000 Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 In-Reply-To: <07f16cad-edc0-4f4f-9ec3-00306e213878@default> References: <07f16cad-edc0-4f4f-9ec3-00306e213878@default> Message-ID: <5524E071.9000401@oracle.com> On 8/04/2015 5:21 PM, Dmitry Dmitriev wrote: > Thank you, David! > > About maximum MaxTenuringThreshold - as I see it still exist in JDK 9, but currently it equal to 16(was 15 in JDK 8). Check for inverval is exist in Arguments::check_vm_args_consistency() function. Ah I see. So parse_uintx will check the value is numeric and not below the minimum value, and then verify_interval will check both the minimum and maximum values. Thanks, David > Regards, > Dmitry > > ----- Original Message ----- > From: david.holmes at oracle.com > To: dmitry.dmitriev at oracle.com, hotspot-dev at openjdk.java.net > Sent: Wednesday, April 8, 2015 9:57:58 AM GMT +03:00 Iraq > Subject: Re: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 > > On 8/04/2015 4:40 PM, Dmitry Dmitriev wrote: >> Hello, >> >> I am need one more Reviewer. Can someone review this patch? Thanks! > > Looks okay. In comparing to JDK 8 I note there is no longer a maximum > MaxTenuringThreshold enforced, so presumably only negative values are > illegal now. > > Thanks, > David > >> Dmitry >> >> ----- Original Message ----- >> From: dmitry.dmitriev at oracle.com >> To: hotspot-dev at openjdk.java.net >> Sent: Friday, April 3, 2015 12:50:28 PM GMT +03:00 Iraq >> Subject: RFR(XS) 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 >> >> Hello, >> >> Please review this small fix for JDK-8076311. Also, I need a sponsor for >> this fix, who can push it, because I'm not have a OpenJDK name. >> >> Fix for JDK-6521376 add explicit processing of MaxTenuringThreshold XX >> option. When bad value for MaxTenuringThreshold is passed(e.g. negative >> value for unsigned option "-XX:MaxTenuringThreshold=-1"), then function >> print warning and continue execution with default value(0). This >> behavior differs from Java 8. Java 8 process this situation in common >> way for unsigned options, i.e. print waring and reports a error. So, I >> fix Java 9 MaxTenuringThreshold option processing. >> >> Also, I add new test case to the >> test/gc/arguments/TestInitialTenuringThreshold.java to test this situation. >> >> Open webrev: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8076311/webrev.00/ >> >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8076311 >> >> Tested: JPRT >> >> Thank you, >> Dmitry >> From roland.westrelin at oracle.com Wed Apr 8 13:04:41 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 8 Apr 2015 15:04:41 +0200 Subject: [8u] backport of 8069263: assert(fm == NULL || fm->method_holder() == _participants[n]) failed: sanity Message-ID: <9674B27B-9CF3-4254-93E9-EEA9DAA32943@oracle.com> 8u backport request. 8069263 was pushed to jdk9 2 weeks ago and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u. https://bugs.openjdk.java.net/browse/JDK-8069263 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/da130fa0ba00 Roland. From roland.westrelin at oracle.com Wed Apr 8 13:16:20 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 8 Apr 2015 15:16:20 +0200 Subject: [8u] backport of 8075587: Compilation of constant array containing different sub classes crashes the JVM Message-ID: <0DFBD0F8-8112-43F5-B295-BB99BDB18327@oracle.com> 8u backport request. 8075587 was pushed to jdk9 1 week ago and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u (identical change with an offset of -133 lines in file type.cpp). https://bugs.openjdk.java.net/browse/JDK-8075587 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/215053fb9d59 Roland. From daniel.daugherty at oracle.com Wed Apr 8 13:54:26 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 08 Apr 2015 07:54:26 -0600 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55247FCB.6050000@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> <55247FCB.6050000@oracle.com> Message-ID: <55253312.7040105@oracle.com> On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote: > On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: >> >> >> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >>> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>>> >>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using it >>>> to find the method. >>>> >>>> But this is only going to find the method if it happens to be in >>>> the cpCache somewhere. I think >>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not >>>> 100% sure). In which case, you can look at that class to find the >>>> method with idnum. >>> I'm not 100% sure either. >>> Ok, I will check if using the prev_constant_pool()->pool_holder() is >>> going to work. >>> It'd make it more consistent with the jdk 9 fix. >> >> This is the updated webrev. > Sorry, forgot to paste the link: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ Comparing the two patch files looks good. A couple of nits: src/share/vm/classfile/javaClasses.cpp L1451: // Use specific ik version... L1884: // Use specific ik version... grammar: 'Use a specific ik version...' L1452: // refer to version that... L1885: // refer to version that... grammar: 'refer to a version that...' src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/oops/instanceKlass.cpp No comments. src/share/vm/oops/instanceKlass.hpp No comments. Thumbs up. Dan > > Thanks, > Serguei > >> It is more consistent with the jdk 9 fix. >> Thank you for the suggestion! >> >> Thanks, >> Serguei >> >>> >>> Important part is that at least the saved cpref can be used to find >>> method name in the >>> the_class cpool if the attempt to find in the previous list cpCaches >>> was unsuccessful. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Coleen >>>> >>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>>> Coleen, >>>>> >>>>> Thank you for looking at this! >>>>> >>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>>> >>>>> 8u60: >>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>> + if (idnum >= methods()->length()) { >>>>> + return NULL; >>>>> + } >>>>> + Method* m = methods()->at(idnum); >>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>> + return m; >>>>> + } >>>>> + // Obsolete method idnum does not match the original idnum >>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>> + m = methods()->at(index); >>>>> + if (m->orig_method_idnum() == idnum) { >>>>> + return m; >>>>> + } >>>>> + } >>>>> + // None found, return null for the caller to handle. >>>>> + return NULL; >>>>> +} >>>>> + >>>>> + >>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>> + if (constants()->version() == version) { >>>>> + return method_with_orig_idnum(idnum); >>>>> + } >>>>> + ConstantPoolCache* cp_cache = NULL; >>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>>> + if (prev_cp->version() == version) { >>>>> + cp_cache = prev_cp->cache(); >>>>> + break; >>>>> + } >>>>> + } >>>>> + if (cp_cache == NULL) { >>>>> + return NULL; // The pv_node is gone, no method is found >>>>> + } >>>>> + Method* method = NULL; >>>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>>> + method = entry->get_interesting_method_entry(this); >>>>> + if (method == NULL) { >>>>> + continue; // skip uninteresting entries >>>>> + } >>>>> + if (method->orig_method_idnum() == idnum) { >>>>> + return method; >>>>> + } >>>>> + } >>>>> + // None found, return null for the caller to handle. >>>>> + return NULL; >>>>> +} >>>>> >>>>> >>>>> jdk 9: >>>>> >>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>> + if (idnum >= methods()->length()) { >>>>> + return NULL; >>>>> + } >>>>> + Method* m = methods()->at(idnum); >>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>> + return m; >>>>> + } >>>>> + // Obsolete method idnum does not match the original idnum >>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>> + m = methods()->at(index); >>>>> + if (m->orig_method_idnum() == idnum) { >>>>> + return m; >>>>> + } >>>>> + } >>>>> + // None found, return null for the caller to handle. >>>>> + return NULL; >>>>> +} >>>>> + >>>>> + >>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>> + InstanceKlass* holder = get_klass_version(version); >>>>> + if (holder == NULL) { >>>>> + return NULL; // The version of klass is gone, no method is found >>>>> + } >>>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>>> + return method; >>>>> +} >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>>> >>>>>> This backport looks good. Why didn't the patch apply cleanly? >>>>>> It seems mostly the same to me. >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Coleen and Dan, >>>>>>> >>>>>>> I'm asking you as the jdk 9 reviewers... >>>>>>> >>>>>>> Please, let me know if you have any chance and plans to review >>>>>>> this. >>>>>>> Would it be enough to have just one (R) reviewer for a non-clean >>>>>>> backport? >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the jdk 8u60 backport for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>>> >>>>>>>> 8u60 hotspot webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>>> >>>>>>>> >>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 9 hotspot webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>>> >>>>>>>> >>>>>>>> 9 webrev for unit test update: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> The 9 fix can not be applied cleanly so that I have to rework >>>>>>>> the fix a little bit. >>>>>>>> >>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>>> The issue is that the methods and related klass versions are >>>>>>>> not kept alive if a class redefinition >>>>>>>> takes place between catching a Throwable and taking a thread >>>>>>>> dump. >>>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>>> reconstruction of method name becomes impossible. >>>>>>>> In such a case, the null reference is returned instead of a >>>>>>>> valid method name. >>>>>>>> >>>>>>>> The solution is to use current klass version and method >>>>>>>> orig_idnum instead of ordinary method idnum >>>>>>>> to find required method pointer. In the worst case when the >>>>>>>> related klass version is gone >>>>>>>> (was not included to or was removed from the >>>>>>>> previous_versions linked list), a saved method name >>>>>>>> CP index of the latest klass version can be used to restore >>>>>>>> the method name. >>>>>>>> The footprint extra overhead for this approach is u2 per >>>>>>>> stack frame. >>>>>>>> >>>>>>>> Testing in progress: >>>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>>> java/lang/instrument >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From volker.simonis at gmail.com Wed Apr 8 14:11:58 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Apr 2015 16:11:58 +0200 Subject: RFR(xxs): 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly (AIX only) In-Reply-To: References: Message-ID: Hi Thomas, the change looks good and I can sponsor it because it only touches AIX-specific files. Thank you and best regards, Volker On Wed, Apr 8, 2015 at 12:59 PM, Thomas St?fe wrote: > Hi, > > please review this tiny, AIX-only change: > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8077257 > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8077257/webrev.00 > > Thanks! > > Thomas Stuefe > From aph at redhat.com Wed Apr 8 14:44:30 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 08 Apr 2015 15:44:30 +0100 Subject: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated Message-ID: <55253ECE.7070209@redhat.com> I keep seeing this message: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated It happens because classpath is this: "/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/jdk.zipfs:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.transaction:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.desktop:/local/aarch64/dev/build/linux-aarch64-normal-serv..." 4533 characters long. It's because of modules. Should we increase O_BUFLEN or remove the message? Andrew. From thomas.stuefe at gmail.com Wed Apr 8 14:53:27 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 8 Apr 2015 16:53:27 +0200 Subject: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated In-Reply-To: <55253ECE.7070209@redhat.com> References: <55253ECE.7070209@redhat.com> Message-ID: Hi Andrew, This would increase stack requirements in error situations, especially when secondary signals occur during error reporting. Also, I think, there would be no safe value to use, because classpath can be arbitrarily long? I think in this case, printing code should be corrected. Regards, Thomas On Wed, Apr 8, 2015 at 4:44 PM, Andrew Haley wrote: > I keep seeing this message: > > OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- > output truncated > > It happens because classpath is this: > > > "/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/jdk.zipfs:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.transaction:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.desktop:/local/aarch64/dev/build/linux-aarch64-normal-serv..." > 4533 characters long. > > It's because of modules. > > Should we increase O_BUFLEN or remove the message? > > Andrew. > From thomas.stuefe at gmail.com Wed Apr 8 14:56:46 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 8 Apr 2015 16:56:46 +0200 Subject: RFR(xxs): 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly (AIX only) In-Reply-To: References: Message-ID: Thanks :-) On Apr 8, 2015 4:11 PM, "Volker Simonis" wrote: > Hi Thomas, > > the change looks good and I can sponsor it because it only touches > AIX-specific files. > > Thank you and best regards, > Volker > > > On Wed, Apr 8, 2015 at 12:59 PM, Thomas St?fe > wrote: > > Hi, > > > > please review this tiny, AIX-only change: > > > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8077257 > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8077257/webrev.00 > > > > Thanks! > > > > Thomas Stuefe > > > From aph at redhat.com Wed Apr 8 14:59:09 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 08 Apr 2015 15:59:09 +0100 Subject: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated In-Reply-To: References: <55253ECE.7070209@redhat.com> Message-ID: <5525423D.4060303@redhat.com> Hi Thomas, OK, but I have no idea what you mean by "printing code should be corrected". Sure, it should be corrected, but do do what? It seems a bit lame that debugging printf can't print long strings. Andrew. On 04/08/2015 03:53 PM, Thomas St?fe wrote: > Hi Andrew, > > This would increase stack requirements in error situations, especially when > secondary signals occur during error reporting. Also, I think, there would > be no safe value to use, because classpath can be arbitrarily long? > > I think in this case, printing code should be corrected. > > Regards, Thomas > > > On Wed, Apr 8, 2015 at 4:44 PM, Andrew Haley wrote: > >> I keep seeing this message: >> >> OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- >> output truncated >> >> It happens because classpath is this: >> >> >> "/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/jdk.zipfs:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.transaction:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.desktop:/local/aarch64/dev/build/linux-aarch64-normal-serv..." >> 4533 characters long. >> >> It's because of modules. >> >> Should we increase O_BUFLEN or remove the message? >> >> Andrew. >> > From thomas.stuefe at gmail.com Wed Apr 8 15:10:02 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 8 Apr 2015 17:10:02 +0200 Subject: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated In-Reply-To: <5525423D.4060303@redhat.com> References: <55253ECE.7070209@redhat.com> <5525423D.4060303@redhat.com> Message-ID: Hi Andrew, yes, it is lame. The short term answer would be to fix the expression which prints out the classpath. Where is this print statement? The long term answer could be e.g.: we could implement our own printf() routines. We (SAP) actually already did this inside our JVM for parts of our own tracing system. It is not rocket science, just a bit of work. If done right, there are several advantages, among others that you do not need temporary buffers for the libc printf() to print into. Depending on interest, I could try to contribute this to the OpenJDK. ..Thomas On Wed, Apr 8, 2015 at 4:59 PM, Andrew Haley wrote: > Hi Thomas, > > OK, but I have no idea what you mean by "printing code should be > corrected". Sure, it should be corrected, but do do what? It seems a > bit lame that debugging printf can't print long strings. > > Andrew. > > > On 04/08/2015 03:53 PM, Thomas St?fe wrote: > > Hi Andrew, > > > > This would increase stack requirements in error situations, especially > when > > secondary signals occur during error reporting. Also, I think, there > would > > be no safe value to use, because classpath can be arbitrarily long? > > > > I think in this case, printing code should be corrected. > > > > Regards, Thomas > > > > > > On Wed, Apr 8, 2015 at 4:44 PM, Andrew Haley wrote: > > > >> I keep seeing this message: > >> > >> OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- > >> output truncated > >> > >> It happens because classpath is this: > >> > >> > >> > "/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/jdk.zipfs:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.transaction:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.desktop:/local/aarch64/dev/build/linux-aarch64-normal-serv..." > >> 4533 characters long. > >> > >> It's because of modules. > >> > >> Should we increase O_BUFLEN or remove the message? > >> > >> Andrew. > >> > > > > From aph at redhat.com Wed Apr 8 15:27:58 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 08 Apr 2015 16:27:58 +0100 Subject: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated In-Reply-To: References: <55253ECE.7070209@redhat.com> <5525423D.4060303@redhat.com> Message-ID: <552548FE.5070303@redhat.com> On 04/08/2015 04:10 PM, Thomas St?fe wrote: > Hi Andrew, > > yes, it is lame. The short term answer would be to fix the expression which > prints out the classpath. Where is this print statement? ostream.cpp: for (SystemProperty* p = Arguments::system_properties(); p != NULL; p = p->next()) { xs->text()->print_cr("%s=%s", p->key(), p->value()); (gdb) p p->key() $24 = 0x3ffb00016a0 "sun.boot.class.path" (gdb) p p->value() $25 = 0x3ffb00029e0 "/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/jdk.zipfs:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.transaction:/local/aarch64/dev/buil"... > The long term answer could be e.g.: we could implement our own printf() > routines. We (SAP) actually already did this inside our JVM for parts of > our own tracing system. It is not rocket science, just a bit of work. If > done right, there are several advantages, among others that you do not need > temporary buffers for the libc printf() to print into. Depending on > interest, I could try to contribute this to the OpenJDK. In this case we don't need formatted printing at all. for (SystemProperty* p = Arguments::system_properties(); p != NULL; p = p->next()) { outputStream *text = xs->text(); text->print_raw(p->key()); text->put('='); text->print_raw_cr(p->value()); } works just fine. It's a bit of a kludge tho'. :-) Andrew. From vladimir.kozlov at oracle.com Wed Apr 8 15:31:12 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 08 Apr 2015 08:31:12 -0700 Subject: [8u] backport of 8069263: assert(fm == NULL || fm->method_holder() == _participants[n]) failed: sanity In-Reply-To: <9674B27B-9CF3-4254-93E9-EEA9DAA32943@oracle.com> References: <9674B27B-9CF3-4254-93E9-EEA9DAA32943@oracle.com> Message-ID: <552549C0.6050207@oracle.com> Good. Thanks, Vladimir On 4/8/15 6:04 AM, Roland Westrelin wrote: > 8u backport request. 8069263 was pushed to jdk9 2 weeks ago and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u. > > https://bugs.openjdk.java.net/browse/JDK-8069263 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/da130fa0ba00 > > Roland. > From vladimir.kozlov at oracle.com Wed Apr 8 15:34:26 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 08 Apr 2015 08:34:26 -0700 Subject: [8u] backport of 8075587: Compilation of constant array containing different sub classes crashes the JVM In-Reply-To: <0DFBD0F8-8112-43F5-B295-BB99BDB18327@oracle.com> References: <0DFBD0F8-8112-43F5-B295-BB99BDB18327@oracle.com> Message-ID: <55254A82.50109@oracle.com> Okay. Thanks, Vladimir On 4/8/15 6:16 AM, Roland Westrelin wrote: > 8u backport request. 8075587 was pushed to jdk9 1 week ago and it hasn?t caused any new failures during nightly testing. The > change applies cleanly to 8u (identical change with an offset of -133 lines in file type.cpp). > > https://bugs.openjdk.java.net/browse/JDK-8075587 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/215053fb9d59 > > Roland. > From vladimir.x.ivanov at oracle.com Wed Apr 8 15:41:15 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 08 Apr 2015 18:41:15 +0300 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names Message-ID: <55254C1B.2040603@oracle.com> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/jdk http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/hotspot https://bugs.openjdk.java.net/browse/JDK-8057919 The logic to compute simple name (Class.getSimpleName()) for inner/nested/local classes is tightly coupled with Java naming scheme and sometimes fails for classes generated from non-Java code. Instead of parsing class name and try to extract simple name based on JLS rules, the fix I propose is to use InnerClasses attribute from the class file. Simple name is already recorded there. JVMS-4.7.6: The InnerClasses Attribute "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the inner_name_index item must be zero. Otherwise, the value of the inner_name_index item must be a valid index into the constant_pool table, and the entry at that index must be a CONSTANT_Utf8_info structure (?4.4.7) that represents the original simple name of C, as given in the source code from which this class file was compiled." Since I consider backporting the fix into 8u60, I'd like to hear opinions about backward compatibility of such change. As an alternative solution, I can restore original logic and consult InnerClasses attribute when class name parsing logic fails. Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ Thanks! Best regards, Vladimir Ivanov From thomas.stuefe at gmail.com Wed Apr 8 15:42:49 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 8 Apr 2015 17:42:49 +0200 Subject: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated In-Reply-To: <552548FE.5070303@redhat.com> References: <55253ECE.7070209@redhat.com> <5525423D.4060303@redhat.com> <552548FE.5070303@redhat.com> Message-ID: On Wed, Apr 8, 2015 at 5:27 PM, Andrew Haley wrote: > On 04/08/2015 04:10 PM, Thomas St?fe wrote: > > Hi Andrew, > > > > yes, it is lame. The short term answer would be to fix the expression > which > > prints out the classpath. Where is this print statement? > > ostream.cpp: > > for (SystemProperty* p = Arguments::system_properties(); p != NULL; > p = p->next()) { > xs->text()->print_cr("%s=%s", p->key(), p->value()); > > (gdb) p p->key() > $24 = 0x3ffb00016a0 "sun.boot.class.path" > (gdb) p p->value() > $25 = 0x3ffb00029e0 > "/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/jdk.zipfs:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.transaction:/local/aarch64/dev/buil"... > > > The long term answer could be e.g.: we could implement our own printf() > > routines. We (SAP) actually already did this inside our JVM for parts of > > our own tracing system. It is not rocket science, just a bit of work. If > > done right, there are several advantages, among others that you do not > need > > temporary buffers for the libc printf() to print into. Depending on > > interest, I could try to contribute this to the OpenJDK. > > In this case we don't need formatted printing at all. > > for (SystemProperty* p = Arguments::system_properties(); p != NULL; > p = p->next()) { > outputStream *text = xs->text(); > text->print_raw(p->key()); > text->put('='); > text->print_raw_cr(p->value()); > } > > works just fine. It's a bit of a kludge tho'. :-) > Looks like a valid fix to me :) Thomas > > Andrew. > > From ioi.lam at oracle.com Wed Apr 8 17:59:19 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 08 Apr 2015 10:59:19 -0700 Subject: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated In-Reply-To: References: <55253ECE.7070209@redhat.com> <5525423D.4060303@redhat.com> <552548FE.5070303@redhat.com> Message-ID: <55256C77.2080007@oracle.com> On 4/8/15 8:42 AM, Thomas St?fe wrote: > On Wed, Apr 8, 2015 at 5:27 PM, Andrew Haley wrote: > >> On 04/08/2015 04:10 PM, Thomas St?fe wrote: >>> Hi Andrew, >>> >>> yes, it is lame. The short term answer would be to fix the expression >> which >>> prints out the classpath. Where is this print statement? >> ostream.cpp: >> >> for (SystemProperty* p = Arguments::system_properties(); p != NULL; >> p = p->next()) { >> xs->text()->print_cr("%s=%s", p->key(), p->value()); >> >> (gdb) p p->key() >> $24 = 0x3ffb00016a0 "sun.boot.class.path" >> (gdb) p p->value() >> $25 = 0x3ffb00029e0 >> "/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/jdk.zipfs:/local/aarch64/dev/build/linux-aarch64-normal-server-slowdebug/jdk/modules/java.transaction:/local/aarch64/dev/buil"... >> >>> The long term answer could be e.g.: we could implement our own printf() >>> routines. We (SAP) actually already did this inside our JVM for parts of >>> our own tracing system. It is not rocket science, just a bit of work. If >>> done right, there are several advantages, among others that you do not >> need >>> temporary buffers for the libc printf() to print into. Depending on >>> interest, I could try to contribute this to the OpenJDK. >> In this case we don't need formatted printing at all. >> >> for (SystemProperty* p = Arguments::system_properties(); p != NULL; >> p = p->next()) { >> outputStream *text = xs->text(); >> text->print_raw(p->key()); >> text->put('='); >> text->print_raw_cr(p->value()); >> } >> >> works just fine. It's a bit of a kludge tho'. :-) >> > Looks like a valid fix to me :) I agree. If the string may have an unpredictable length, it should not be printed using print_cr(). > Thomas > > >> Andrew. >> >> From serguei.spitsyn at oracle.com Wed Apr 8 18:38:21 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 08 Apr 2015 11:38:21 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55253312.7040105@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> <55247FCB.6050000@oracle.com> <55253312.7040105@oracle.com> Message-ID: <5525759D.8090506@oracle.com> Thanks, Dan! I will correct the grammar before the push.. Thanks, Serguei On 4/8/15 6:54 AM, Daniel D. Daugherty wrote: > On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote: >> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: >>> >>> >>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>>>> >>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using >>>>> it to find the method. >>>>> >>>>> But this is only going to find the method if it happens to be in >>>>> the cpCache somewhere. I think >>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not >>>>> 100% sure). In which case, you can look at that class to find the >>>>> method with idnum. >>>> I'm not 100% sure either. >>>> Ok, I will check if using the prev_constant_pool()->pool_holder() >>>> is going to work. >>>> It'd make it more consistent with the jdk 9 fix. >>> >>> This is the updated webrev. >> Sorry, forgot to paste the link: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ > > Comparing the two patch files looks good. A couple of nits: > > src/share/vm/classfile/javaClasses.cpp > L1451: // Use specific ik version... > L1884: // Use specific ik version... > grammar: 'Use a specific ik version...' > > L1452: // refer to version that... > L1885: // refer to version that... > grammar: 'refer to a version that...' > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > No comments. > > src/share/vm/oops/instanceKlass.hpp > No comments. > > Thumbs up. > > Dan > > >> >> Thanks, >> Serguei >> >>> It is more consistent with the jdk 9 fix. >>> Thank you for the suggestion! >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Important part is that at least the saved cpref can be used to find >>>> method name in the >>>> the_class cpool if the attempt to find in the previous list >>>> cpCaches was unsuccessful. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Coleen >>>>> >>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Coleen, >>>>>> >>>>>> Thank you for looking at this! >>>>>> >>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>>>> >>>>>> 8u60: >>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>> + if (idnum >= methods()->length()) { >>>>>> + return NULL; >>>>>> + } >>>>>> + Method* m = methods()->at(idnum); >>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>> + return m; >>>>>> + } >>>>>> + // Obsolete method idnum does not match the original idnum >>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>> + m = methods()->at(index); >>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>> + return m; >>>>>> + } >>>>>> + } >>>>>> + // None found, return null for the caller to handle. >>>>>> + return NULL; >>>>>> +} >>>>>> + >>>>>> + >>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>> + if (constants()->version() == version) { >>>>>> + return method_with_orig_idnum(idnum); >>>>>> + } >>>>>> + ConstantPoolCache* cp_cache = NULL; >>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>>>> + if (prev_cp->version() == version) { >>>>>> + cp_cache = prev_cp->cache(); >>>>>> + break; >>>>>> + } >>>>>> + } >>>>>> + if (cp_cache == NULL) { >>>>>> + return NULL; // The pv_node is gone, no method is found >>>>>> + } >>>>>> + Method* method = NULL; >>>>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>>>> + method = entry->get_interesting_method_entry(this); >>>>>> + if (method == NULL) { >>>>>> + continue; // skip uninteresting entries >>>>>> + } >>>>>> + if (method->orig_method_idnum() == idnum) { >>>>>> + return method; >>>>>> + } >>>>>> + } >>>>>> + // None found, return null for the caller to handle. >>>>>> + return NULL; >>>>>> +} >>>>>> >>>>>> >>>>>> jdk 9: >>>>>> >>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>> + if (idnum >= methods()->length()) { >>>>>> + return NULL; >>>>>> + } >>>>>> + Method* m = methods()->at(idnum); >>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>> + return m; >>>>>> + } >>>>>> + // Obsolete method idnum does not match the original idnum >>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>> + m = methods()->at(index); >>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>> + return m; >>>>>> + } >>>>>> + } >>>>>> + // None found, return null for the caller to handle. >>>>>> + return NULL; >>>>>> +} >>>>>> + >>>>>> + >>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>> + InstanceKlass* holder = get_klass_version(version); >>>>>> + if (holder == NULL) { >>>>>> + return NULL; // The version of klass is gone, no method is found >>>>>> + } >>>>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>>>> + return method; >>>>>> +} >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> This backport looks good. Why didn't the patch apply cleanly? >>>>>>> It seems mostly the same to me. >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Coleen and Dan, >>>>>>>> >>>>>>>> I'm asking you as the jdk 9 reviewers... >>>>>>>> >>>>>>>> Please, let me know if you have any chance and plans to review >>>>>>>> this. >>>>>>>> Would it be enough to have just one (R) reviewer for a >>>>>>>> non-clean backport? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the jdk 8u60 backport for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>>>> >>>>>>>>> 8u60 hotspot webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>>>> >>>>>>>>> >>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 9 hotspot webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>>>> >>>>>>>>> >>>>>>>>> 9 webrev for unit test update: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> The 9 fix can not be applied cleanly so that I have to >>>>>>>>> rework the fix a little bit. >>>>>>>>> >>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>>>> The issue is that the methods and related klass versions are >>>>>>>>> not kept alive if a class redefinition >>>>>>>>> takes place between catching a Throwable and taking a thread >>>>>>>>> dump. >>>>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>>>> reconstruction of method name becomes impossible. >>>>>>>>> In such a case, the null reference is returned instead of a >>>>>>>>> valid method name. >>>>>>>>> >>>>>>>>> The solution is to use current klass version and method >>>>>>>>> orig_idnum instead of ordinary method idnum >>>>>>>>> to find required method pointer. In the worst case when the >>>>>>>>> related klass version is gone >>>>>>>>> (was not included to or was removed from the >>>>>>>>> previous_versions linked list), a saved method name >>>>>>>>> CP index of the latest klass version can be used to restore >>>>>>>>> the method name. >>>>>>>>> The footprint extra overhead for this approach is u2 per >>>>>>>>> stack frame. >>>>>>>>> >>>>>>>>> Testing in progress: >>>>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>>>> java/lang/instrument >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed Apr 8 18:49:28 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 08 Apr 2015 14:49:28 -0400 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5525759D.8090506@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> <55247FCB.6050000@oracle.com> <55253312.7040105@oracle.com> <5525759D.8090506@oracle.com> Message-ID: <55257838.8080605@oracle.com> Serguei, This latest version looks great. Coleen On 4/8/15, 2:38 PM, serguei.spitsyn at oracle.com wrote: > Thanks, Dan! > > I will correct the grammar before the push.. > > Thanks, > Serguei > > On 4/8/15 6:54 AM, Daniel D. Daugherty wrote: >> On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote: >>> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>> >>>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>>>>> >>>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using >>>>>> it to find the method. >>>>>> >>>>>> But this is only going to find the method if it happens to be in >>>>>> the cpCache somewhere. I think >>>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class >>>>>> (not 100% sure). In which case, you can look at that class to >>>>>> find the method with idnum. >>>>> I'm not 100% sure either. >>>>> Ok, I will check if using the prev_constant_pool()->pool_holder() >>>>> is going to work. >>>>> It'd make it more consistent with the jdk 9 fix. >>>> >>>> This is the updated webrev. >>> Sorry, forgot to paste the link: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ >> >> Comparing the two patch files looks good. A couple of nits: >> >> src/share/vm/classfile/javaClasses.cpp >> L1451: // Use specific ik version... >> L1884: // Use specific ik version... >> grammar: 'Use a specific ik version...' >> >> L1452: // refer to version that... >> L1885: // refer to version that... >> grammar: 'refer to a version that...' >> >> src/share/vm/classfile/javaClasses.hpp >> No comments. >> >> src/share/vm/oops/instanceKlass.cpp >> No comments. >> >> src/share/vm/oops/instanceKlass.hpp >> No comments. >> >> Thumbs up. >> >> Dan >> >> >>> >>> Thanks, >>> Serguei >>> >>>> It is more consistent with the jdk 9 fix. >>>> Thank you for the suggestion! >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Important part is that at least the saved cpref can be used to >>>>> find method name in the >>>>> the_class cpool if the attempt to find in the previous list >>>>> cpCaches was unsuccessful. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Coleen, >>>>>>> >>>>>>> Thank you for looking at this! >>>>>>> >>>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>>>>> >>>>>>> 8u60: >>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>>> + if (idnum >= methods()->length()) { >>>>>>> + return NULL; >>>>>>> + } >>>>>>> + Method* m = methods()->at(idnum); >>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>>> + return m; >>>>>>> + } >>>>>>> + // Obsolete method idnum does not match the original idnum >>>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>>> + m = methods()->at(index); >>>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>>> + return m; >>>>>>> + } >>>>>>> + } >>>>>>> + // None found, return null for the caller to handle. >>>>>>> + return NULL; >>>>>>> +} >>>>>>> + >>>>>>> + >>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>>> + if (constants()->version() == version) { >>>>>>> + return method_with_orig_idnum(idnum); >>>>>>> + } >>>>>>> + ConstantPoolCache* cp_cache = NULL; >>>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>>>>> + if (prev_cp->version() == version) { >>>>>>> + cp_cache = prev_cp->cache(); >>>>>>> + break; >>>>>>> + } >>>>>>> + } >>>>>>> + if (cp_cache == NULL) { >>>>>>> + return NULL; // The pv_node is gone, no method is found >>>>>>> + } >>>>>>> + Method* method = NULL; >>>>>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>>>>> + method = entry->get_interesting_method_entry(this); >>>>>>> + if (method == NULL) { >>>>>>> + continue; // skip uninteresting entries >>>>>>> + } >>>>>>> + if (method->orig_method_idnum() == idnum) { >>>>>>> + return method; >>>>>>> + } >>>>>>> + } >>>>>>> + // None found, return null for the caller to handle. >>>>>>> + return NULL; >>>>>>> +} >>>>>>> >>>>>>> >>>>>>> jdk 9: >>>>>>> >>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>>> + if (idnum >= methods()->length()) { >>>>>>> + return NULL; >>>>>>> + } >>>>>>> + Method* m = methods()->at(idnum); >>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>>> + return m; >>>>>>> + } >>>>>>> + // Obsolete method idnum does not match the original idnum >>>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>>> + m = methods()->at(index); >>>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>>> + return m; >>>>>>> + } >>>>>>> + } >>>>>>> + // None found, return null for the caller to handle. >>>>>>> + return NULL; >>>>>>> +} >>>>>>> + >>>>>>> + >>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>>> + InstanceKlass* holder = get_klass_version(version); >>>>>>> + if (holder == NULL) { >>>>>>> + return NULL; // The version of klass is gone, no method is found >>>>>>> + } >>>>>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>>>>> + return method; >>>>>>> +} >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> This backport looks good. Why didn't the patch apply cleanly? >>>>>>>> It seems mostly the same to me. >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Coleen and Dan, >>>>>>>>> >>>>>>>>> I'm asking you as the jdk 9 reviewers... >>>>>>>>> >>>>>>>>> Please, let me know if you have any chance and plans to review >>>>>>>>> this. >>>>>>>>> Would it be enough to have just one (R) reviewer for a >>>>>>>>> non-clean backport? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the jdk 8u60 backport for: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>>>>> >>>>>>>>>> 8u60 hotspot webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 9 hotspot webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 9 webrev for unit test update: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> The 9 fix can not be applied cleanly so that I have to >>>>>>>>>> rework the fix a little bit. >>>>>>>>>> >>>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>>>>> The issue is that the methods and related klass versions >>>>>>>>>> are not kept alive if a class redefinition >>>>>>>>>> takes place between catching a Throwable and taking a >>>>>>>>>> thread dump. >>>>>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>>>>> reconstruction of method name becomes impossible. >>>>>>>>>> In such a case, the null reference is returned instead of a >>>>>>>>>> valid method name. >>>>>>>>>> >>>>>>>>>> The solution is to use current klass version and method >>>>>>>>>> orig_idnum instead of ordinary method idnum >>>>>>>>>> to find required method pointer. In the worst case when the >>>>>>>>>> related klass version is gone >>>>>>>>>> (was not included to or was removed from the >>>>>>>>>> previous_versions linked list), a saved method name >>>>>>>>>> CP index of the latest klass version can be used to restore >>>>>>>>>> the method name. >>>>>>>>>> The footprint extra overhead for this approach is u2 per >>>>>>>>>> stack frame. >>>>>>>>>> >>>>>>>>>> Testing in progress: >>>>>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>>>>> java/lang/instrument >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Apr 8 18:58:07 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 08 Apr 2015 11:58:07 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55257838.8080605@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> <55247FCB.6050000@oracle.com> <55253312.7040105@oracle.com> <5525759D.8090506@oracle.com> <55257838.8080605@oracle.com> Message-ID: <55257A3F.5020700@oracle.com> Thanks, Collen! It was a great suggestion. :) Thanks, Serguei On 4/8/15 11:49 AM, Coleen Phillimore wrote: > > Serguei, This latest version looks great. > Coleen > > On 4/8/15, 2:38 PM, serguei.spitsyn at oracle.com wrote: >> Thanks, Dan! >> >> I will correct the grammar before the push.. >> >> Thanks, >> Serguei >> >> On 4/8/15 6:54 AM, Daniel D. Daugherty wrote: >>> On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote: >>>> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> >>>>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using >>>>>>> it to find the method. >>>>>>> >>>>>>> But this is only going to find the method if it happens to be in >>>>>>> the cpCache somewhere. I think >>>>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class >>>>>>> (not 100% sure). In which case, you can look at that class to >>>>>>> find the method with idnum. >>>>>> I'm not 100% sure either. >>>>>> Ok, I will check if using the prev_constant_pool()->pool_holder() >>>>>> is going to work. >>>>>> It'd make it more consistent with the jdk 9 fix. >>>>> >>>>> This is the updated webrev. >>>> Sorry, forgot to paste the link: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ >>> >>> Comparing the two patch files looks good. A couple of nits: >>> >>> src/share/vm/classfile/javaClasses.cpp >>> L1451: // Use specific ik version... >>> L1884: // Use specific ik version... >>> grammar: 'Use a specific ik version...' >>> >>> L1452: // refer to version that... >>> L1885: // refer to version that... >>> grammar: 'refer to a version that...' >>> >>> src/share/vm/classfile/javaClasses.hpp >>> No comments. >>> >>> src/share/vm/oops/instanceKlass.cpp >>> No comments. >>> >>> src/share/vm/oops/instanceKlass.hpp >>> No comments. >>> >>> Thumbs up. >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> It is more consistent with the jdk 9 fix. >>>>> Thank you for the suggestion! >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Important part is that at least the saved cpref can be used to >>>>>> find method name in the >>>>>> the_class cpool if the attempt to find in the previous list >>>>>> cpCaches was unsuccessful. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Coleen, >>>>>>>> >>>>>>>> Thank you for looking at this! >>>>>>>> >>>>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>>>>>> >>>>>>>> 8u60: >>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>>>> + if (idnum >= methods()->length()) { >>>>>>>> + return NULL; >>>>>>>> + } >>>>>>>> + Method* m = methods()->at(idnum); >>>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>>>> + return m; >>>>>>>> + } >>>>>>>> + // Obsolete method idnum does not match the original idnum >>>>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>>>> + m = methods()->at(index); >>>>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>>>> + return m; >>>>>>>> + } >>>>>>>> + } >>>>>>>> + // None found, return null for the caller to handle. >>>>>>>> + return NULL; >>>>>>>> +} >>>>>>>> + >>>>>>>> + >>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>>>> + if (constants()->version() == version) { >>>>>>>> + return method_with_orig_idnum(idnum); >>>>>>>> + } >>>>>>>> + ConstantPoolCache* cp_cache = NULL; >>>>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>>>>>> + if (prev_cp->version() == version) { >>>>>>>> + cp_cache = prev_cp->cache(); >>>>>>>> + break; >>>>>>>> + } >>>>>>>> + } >>>>>>>> + if (cp_cache == NULL) { >>>>>>>> + return NULL; // The pv_node is gone, no method is found >>>>>>>> + } >>>>>>>> + Method* method = NULL; >>>>>>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>>>>>> + method = entry->get_interesting_method_entry(this); >>>>>>>> + if (method == NULL) { >>>>>>>> + continue; // skip uninteresting entries >>>>>>>> + } >>>>>>>> + if (method->orig_method_idnum() == idnum) { >>>>>>>> + return method; >>>>>>>> + } >>>>>>>> + } >>>>>>>> + // None found, return null for the caller to handle. >>>>>>>> + return NULL; >>>>>>>> +} >>>>>>>> >>>>>>>> >>>>>>>> jdk 9: >>>>>>>> >>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>>>> + if (idnum >= methods()->length()) { >>>>>>>> + return NULL; >>>>>>>> + } >>>>>>>> + Method* m = methods()->at(idnum); >>>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>>>> + return m; >>>>>>>> + } >>>>>>>> + // Obsolete method idnum does not match the original idnum >>>>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>>>> + m = methods()->at(index); >>>>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>>>> + return m; >>>>>>>> + } >>>>>>>> + } >>>>>>>> + // None found, return null for the caller to handle. >>>>>>>> + return NULL; >>>>>>>> +} >>>>>>>> + >>>>>>>> + >>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>>>> + InstanceKlass* holder = get_klass_version(version); >>>>>>>> + if (holder == NULL) { >>>>>>>> + return NULL; // The version of klass is gone, no method is found >>>>>>>> + } >>>>>>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>>>>>> + return method; >>>>>>>> +} >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> This backport looks good. Why didn't the patch apply >>>>>>>>> cleanly? It seems mostly the same to me. >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Coleen and Dan, >>>>>>>>>> >>>>>>>>>> I'm asking you as the jdk 9 reviewers... >>>>>>>>>> >>>>>>>>>> Please, let me know if you have any chance and plans to >>>>>>>>>> review this. >>>>>>>>>> Would it be enough to have just one (R) reviewer for a >>>>>>>>>> non-clean backport? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Please, review the jdk 8u60 backport for: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>>>>>> >>>>>>>>>>> 8u60 hotspot webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 9 hotspot webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 9 webrev for unit test update: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> The 9 fix can not be applied cleanly so that I have to >>>>>>>>>>> rework the fix a little bit. >>>>>>>>>>> >>>>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>>>>>> The issue is that the methods and related klass versions >>>>>>>>>>> are not kept alive if a class redefinition >>>>>>>>>>> takes place between catching a Throwable and taking a >>>>>>>>>>> thread dump. >>>>>>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>>>>>> reconstruction of method name becomes impossible. >>>>>>>>>>> In such a case, the null reference is returned instead of >>>>>>>>>>> a valid method name. >>>>>>>>>>> >>>>>>>>>>> The solution is to use current klass version and method >>>>>>>>>>> orig_idnum instead of ordinary method idnum >>>>>>>>>>> to find required method pointer. In the worst case when >>>>>>>>>>> the related klass version is gone >>>>>>>>>>> (was not included to or was removed from the >>>>>>>>>>> previous_versions linked list), a saved method name >>>>>>>>>>> CP index of the latest klass version can be used to >>>>>>>>>>> restore the method name. >>>>>>>>>>> The footprint extra overhead for this approach is u2 per >>>>>>>>>>> stack frame. >>>>>>>>>>> >>>>>>>>>>> Testing in progress: >>>>>>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>>>>>> java/lang/instrument >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Wed Apr 8 20:53:50 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 08 Apr 2015 22:53:50 +0200 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> Message-ID: <5525955E.5000302@oracle.com> On 2015-04-03 00:36, Kim Barrett wrote: > On Apr 2, 2015, at 12:06 PM, Volker Simonis wrote: >> while precompiled headers (PCH) are a nice and effective way of >> improving hotspot build times > Are we sure about that? No, we're not. :-) We in the build team, mainly Erik, have done testing on several occasions for the two major special tricks for enhancing build performance: PCH and ccache. Erik can probably quote you some numbers, but what I remember as the bottom line is that it is very much YMMV. There are many different scenarios: * occasionally doing full builds from scratch * incremental rebuilds * repeatingly building full builds from scrach (which benefits ccache) There are also different versions of compilers and ccache, and different operating systems with different file caching policies, and different hardware profiles (is your CPU or disk the bottleneck, etc). Also, it is worth noting that ccache and PCH genereally do not play very well together. Sometimes enabling both will result in worse performance than just enabling one of them. So there is no golden answer, the one thing that is most efficient in all circumstances. We try to provide a reasonable default which works well in most cases (this currently means ccache off by default and PCH on, for hotspot). If you care about performance, the best thing you can do is to measure with and without PCH and ccache on your typical work case. Regarding PCH and JPRT, there seem to be agreement that it typically improves compilation performance, at least on some platforms. /Magnus From ioi.lam at oracle.com Wed Apr 8 23:49:59 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 08 Apr 2015 16:49:59 -0700 Subject: RFR 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: References: <551DE379.7050607@oracle.com> Message-ID: <5525BEA7.9000803@oracle.com> CC-int hotspot-dev to include the wider audience. On 4/8/15 3:24 PM, John Rose wrote: > On Apr 2, 2015, at 5:48 PM, Calvin Cheung wrote: >> Please review this enhancement for Symbol comparison. >> >> This should allow future enhancement such as multiple SymbolTable and symbols with the same utf8 strings in different tables should be considered "equivalent". >> >> Although this changeset touches many files, the main change is in src/share/vm/oops/symbol.hpp with a new SymbolRef class. The rest of the change is mostly replacing Symbol* with SymbolRef. >> >> Since currently there's only one single SymbolTable, it isn't feasible to write a specific testcase for this enhancement. We will provide a testcase when this enhancement is used. >> >> Note also that the copyright header will be fixed before this changeset is committed. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8071627 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.00/ >> >> Tests: >> JPRT >> nsk.jvmti on linux_x64 >> >> the following performance benmarks on linux_x64, solaris_x64, solaris_sparc, mac, windows_x64 with no significant performance degradation: >> jetstream, scimark, specjbb2000, specjbb2005, specjvm98, volano25 >> >> some internal class loading performance tests >> >> thanks, >> Calvin > 8600 lines of patch in 143 files is a disruptive change of the first order. All by itself it will add cost to most backports, including CPUs. > > I would like to understand the need for such a change before it goes into the repo. > > In particular, exactly how many uses of SymbolRef::operator== are there in the new code? What would be the complexity of changing those occurrences only? You can easily find the answer to this question by renaming SymbolRef::operator== to SymbolRef::identity_equals, debugging, and then counting the occurrences of the new name. > > (I know there's a forward-moving cost to leaving C++ pointer-equality as a possible source of bugs. But we can deal with this in other ways than removing a C++ pointer type from our source base.) > > ? John John, We need to do this because we are trying to support the loading of multiple CDS archives into the same application process. These CDS archives may be created independently, and concurrently. It will be a big management headache to require that "all references to the same UTF8 name must be represented by a unique Symbol* pointer". That's why we want to relax the requirement, such that the same UTF8 string can be allocated multiple times, one in each CDS archive. These UTF8 strings are used to reference things across CDS archives. For example, archive A may invoke a class "X" in archive B. Both archives A and B are memory mapped images of HotSpot metadata objects (InstanceKlass, Method, ConstantPool, etc). For example, A may be mapped to the address range 1000 ~ 2000, and B mapped to 5000 ~ 6000. In archive A, the class name "X" would be represented by a Symbol whose address is 1234; In archive B, the class name "X" would be represented by a Symbol whose address is 5678; We need to test that these two Symbols refer to the same name "X". There are many places where (Symbol* == Symbol*) are tested inside the current hotspot code. Unfortunately, if we allow multiple Symbols to refer to the same name, all of such code need to be changed. We cannot just selectively change some of them to Symbol::equals(). Also, even if we change all (Symbol* == Symbol*) to (symbolA->equals(symbolB)), someone may by mistake introduce a new line of (Symbol* == Symbol*), and it will be very hard to detect such changes automatically and reliably. Yes, I understand that the change is big, but it looks more scary than it actually is. Most of the changes in the webrev are mechanical changes, such as replacing "Symbol*" with "SymbolRef". It would cause some pain in back ports, but should be manageable. Also, after this change, most code will NOT use Symbol anymore, and it will be very hard for you to try to get to a Symbol* pointer. So the chance of someone polluting the code again with a (Symbol* == Symbol*) line is very low. - Ioi From ioi.lam at oracle.com Wed Apr 8 23:53:16 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 08 Apr 2015 16:53:16 -0700 Subject: RFR 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: <53D0E131-EDE6-49B8-A5AF-2DF897CC823A@oracle.com> References: <551DE379.7050607@oracle.com> <53D0E131-EDE6-49B8-A5AF-2DF897CC823A@oracle.com> Message-ID: <5525BF6C.3060206@oracle.com> Hi John, Thanks for sending the draft. As I mentioned in my other reply, we don't just have a few T*::operator== that we don't like. We don't like all of the Symbol*==Symbol* comparisons :-( Also, we don't want to leave behind any Symbol* pointers that someone could do a == comparison by mistake. That's why we're replacing all the Symbol* with SymbolRef. - Ioi On 4/8/15 4:11 PM, John Rose wrote: > P.S. I posted a sketch of a design pattern which can help us tame uses of T*::operator== using a wrapper template. > > This does not require a mass rewrite, just introduction of a cast-like operator near every use of T*::operator== that we don't like. > > http://cr.openjdk.java.net/~jrose/draft/saferef.cpp > > It's probably too clever, though: Like the proposed mega-change, it would disguise the meaning of the affected operator== occurrences. > > It may be better to just rewrite the operator== occurrences as Symbol::identity_equals, and document that engineers should avoid direct uses of Symbol*::operator==. > > (Yes, I know that Symbol* has risky aspects in its pointer-ness. But trying to code in C++ without dealing with the oddities of pointer types is IMO futile. You end up with an embedded DSL which nobody wants to understand.) > From david.holmes at oracle.com Thu Apr 9 02:52:15 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Apr 2015 12:52:15 +1000 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <55254C1B.2040603@oracle.com> References: <55254C1B.2040603@oracle.com> Message-ID: <5525E95F.7080306@oracle.com> Hi Vladimir, On 9/04/2015 1:41 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/jdk > http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/hotspot > https://bugs.openjdk.java.net/browse/JDK-8057919 > > The logic to compute simple name (Class.getSimpleName()) for > inner/nested/local classes is tightly coupled with Java naming scheme > and sometimes fails for classes generated from non-Java code. Meta-question: if this is non-Java code then what does/should "simpleName" even mean? "Returns the simple name of the underlying class as given in the source code." If there is no (java) source code does this have any meaning? Should it return "" ? > Instead of parsing class name and try to extract simple name based on > JLS rules, the fix I propose is to use InnerClasses attribute from the > class file. Simple name is already recorded there. > > JVMS-4.7.6: The InnerClasses Attribute > "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the > inner_name_index item must be zero. Otherwise, the value of the > inner_name_index item must be a valid index into the constant_pool > table, and the entry at that index must be a CONSTANT_Utf8_info > structure (?4.4.7) that represents the original simple name of C, as > given in the source code from which this class file was compiled." > > Since I consider backporting the fix into 8u60, I'd like to hear > opinions about backward compatibility of such change. > > As an alternative solution, I can restore original logic and consult > InnerClasses attribute when class name parsing logic fails. I think I'd prefer to see the VM call only used as a fallback if the regular parsing fails. That would prevent any compatibility issues for the 8u backport (ignoring tests that deliberately generate invalidly named classes). Thanks, David > Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ > > Thanks! > > Best regards, > Vladimir Ivanov From forax at univ-mlv.fr Thu Apr 9 06:10:57 2015 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 09 Apr 2015 06:10:57 +0000 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <5525E95F.7080306@oracle.com> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> Message-ID: <3AD9FDA1-CB4E-4F08-BC42-F1B311AA8D3A@univ-mlv.fr> Hi David, The problem is that j.l.i.MethodType.toString uses getSimpleName and j.l i.WrongMethodTypeException uses MethodType.toString. So if getSimpleName returns a blank string, you destroy the debuggability of any invokedynamic/methodhandle calls. regards, R?mi Le 9 avril 2015 04:52:15 CEST, David Holmes a ?crit : >Hi Vladimir, > >On 9/04/2015 1:41 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/jdk >> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/hotspot >> https://bugs.openjdk.java.net/browse/JDK-8057919 >> >> The logic to compute simple name (Class.getSimpleName()) for >> inner/nested/local classes is tightly coupled with Java naming scheme >> and sometimes fails for classes generated from non-Java code. > >Meta-question: if this is non-Java code then what does/should >"simpleName" even mean? "Returns the simple name of the underlying >class >as given in the source code." If there is no (java) source code does >this have any meaning? Should it return "" ? > >> Instead of parsing class name and try to extract simple name based on >> JLS rules, the fix I propose is to use InnerClasses attribute from >the >> class file. Simple name is already recorded there. > > >> JVMS-4.7.6: The InnerClasses Attribute >> "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the >> inner_name_index item must be zero. Otherwise, the value of the >> inner_name_index item must be a valid index into the constant_pool >> table, and the entry at that index must be a CONSTANT_Utf8_info >> structure (?4.4.7) that represents the original simple name of C, as >> given in the source code from which this class file was compiled." >> >> Since I consider backporting the fix into 8u60, I'd like to hear >> opinions about backward compatibility of such change. >> >> As an alternative solution, I can restore original logic and consult >> InnerClasses attribute when class name parsing logic fails. > >I think I'd prefer to see the VM call only used as a fallback if the >regular parsing fails. That would prevent any compatibility issues for >the 8u backport (ignoring tests that deliberately generate invalidly >named classes). > >Thanks, >David > >> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From david.holmes at oracle.com Thu Apr 9 06:27:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Apr 2015 16:27:33 +1000 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <3AD9FDA1-CB4E-4F08-BC42-F1B311AA8D3A@univ-mlv.fr> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> <3AD9FDA1-CB4E-4F08-BC42-F1B311AA8D3A@univ-mlv.fr> Message-ID: <55261BD5.9070208@oracle.com> Hi Remi, On 9/04/2015 4:10 PM, R?mi Forax wrote: > Hi David, > The problem is that j.l.i.MethodType.toString uses getSimpleName and j.l > i.WrongMethodTypeException uses MethodType.toString. > > So if getSimpleName returns a blank string, you destroy the debuggability of any invokedynamic/methodhandle calls. Okay, so an alternative there is for MethodType.toString to not use getSimpleName :) More seriously perhaps things like getSimpleName need to be re-specified to account for classes coming from other than Java source code? Even the INNERCLASSES_Attribute associates the name with Java source code: "original simple name of C, as given in the source code from which this class file was compiled". And what is a "simple name"? It should be the most basic name given to a class without any prefix that indicates an enclosing type or containing package - but if non-Java-language-names are allowed how can you recognize such a prefix? Cheers, David > regards, > R?mi > > Le 9 avril 2015 04:52:15 CEST, David Holmes a ?crit : >> Hi Vladimir, >> >> On 9/04/2015 1:41 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/jdk >>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/hotspot >>> https://bugs.openjdk.java.net/browse/JDK-8057919 >>> >>> The logic to compute simple name (Class.getSimpleName()) for >>> inner/nested/local classes is tightly coupled with Java naming scheme >>> and sometimes fails for classes generated from non-Java code. >> >> Meta-question: if this is non-Java code then what does/should >> "simpleName" even mean? "Returns the simple name of the underlying >> class >> as given in the source code." If there is no (java) source code does >> this have any meaning? Should it return "" ? >> >>> Instead of parsing class name and try to extract simple name based on >>> JLS rules, the fix I propose is to use InnerClasses attribute from >> the >>> class file. Simple name is already recorded there. >>> >>> JVMS-4.7.6: The InnerClasses Attribute >>> "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the >>> inner_name_index item must be zero. Otherwise, the value of the >>> inner_name_index item must be a valid index into the constant_pool >>> table, and the entry at that index must be a CONSTANT_Utf8_info >>> structure (?4.4.7) that represents the original simple name of C, as >>> given in the source code from which this class file was compiled." >>> >>> Since I consider backporting the fix into 8u60, I'd like to hear >>> opinions about backward compatibility of such change. >>> >>> As an alternative solution, I can restore original logic and consult >>> InnerClasses attribute when class name parsing logic fails. >> >> I think I'd prefer to see the VM call only used as a fallback if the >> regular parsing fails. That would prevent any compatibility issues for >> the 8u backport (ignoring tests that deliberately generate invalidly >> named classes). >> >> Thanks, >> David >> >>> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov > From john.r.rose at oracle.com Thu Apr 9 06:33:41 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Apr 2015 23:33:41 -0700 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <5525E95F.7080306@oracle.com> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> Message-ID: <238882B4-E15A-494E-A88C-F9D6A145E2CD@oracle.com> On Apr 8, 2015, at 7:52 PM, David Holmes wrote: > > Meta-question: if this is non-Java code then what does/should "simpleName" even mean? "Returns the simple name of the underlying class as given in the source code." If there is no (java) source code does this have any meaning? Should it return "" ? Non-Java languages can use the JVM's features, including the InnerClasses attribute. The simple name of a class has a natural (JVM-level) definition in terms of the contents of the class's InnerClasses attribute. Parsing the name string was always a buggy stopgap. It doesn't fully make sense for either Java or non-Java programs. ? John From erik.joelsson at oracle.com Thu Apr 9 08:02:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 09 Apr 2015 10:02:53 +0200 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <551EF8EE.8090707@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> Message-ID: <5526322D.1070008@oracle.com> On 2015-04-03 22:32, Dmitry Samersoff wrote: > Kim, > > On my experience PCH significantly slow-down ccache-enabled build. > > Probably because ccache requires some tricks to work with PCH > > see: http://ccache.samba.org/manual.html#_precompiled_headers Historically, this is true, but I fixed this rather recently in configure so that ccache uses the correct configuration for PCH, when PCH is enabled. So if you think it could help, I would urge you to retry ccache, but use a recent version. Still, both techniques work better alone than together and should be used to match your use case. On my linux workstation (32 virtual cpus including HT), using the Oracle internal offical devkits (gcc 4.8.2) for building, my build is faster without PCH. I recently did work on a mac (while working on the new hotspot makefiles) and when I got PCH to work, build times for just Hotspot went from 18 minutes to 6 minutes, using clang, Xcode 5.1.1 and JOBS=2. The mac in question is a standard Stockholm JPRT mac, so in that case, PCH very much helps build times in JPRT. The problem with ccache in Hotspot is that when you change a header file, most of the time, most of the cache is invalidated. This is because most header files are included in most cpp files. Because of this, using ccache in JPRT has been deemed pointless. This is also why PCH tends to help full builds for Hotspot, as a large part of the code is saved from being compiled over and over. I think that as long as we claim to support building both with and without PCH, the automatic testing should test both with and without PCH. By adding one or two build targets, or perhaps change an existing target, we could increase our test matrix to cover this easily. /Erik > -Dmitry > > > On 2015-04-03 01:36, Kim Barrett wrote: >> On Apr 2, 2015, at 12:06 PM, Volker Simonis wrote: >>> while precompiled headers (PCH) are a nice and effective way of >>> improving hotspot build times >> Are we sure about that? >> >> Earlier today I ran into a local build failure that appeared to me to >> be possibly PCH-related. >> >> So I decided to try disabling PCH, since I now know about the option >> for doing so, from Volker's email. But I wanted to see how much >> slower my build times would be. >> >> Imagine my surprise when disabling PCH made my clean builds 10-15% >> *faster*. This is for a full jdk root "make images" build, which >> makes that much of a difference even more astonishing, because there's >> a lot more going on there than just compiling Hotspot. >> >> So how sure are we that PCH (or perhaps the way we are using it) >> provides any positive benefit at all? I'm pretty sure it's not doing >> anything good for me. >> >> For reference, my build configuration is Ubuntu 14.04 x86_64, >> reporting 24 processors. My configure options are >> >> --enable-ccache >> --with-debug-level=release >> --disable-zip-debug-info >> --disable-precompiled-headers -- new >> --with-jobs=24 >> >> I made sure to clear the ccache between each build. >> > From adinn at redhat.com Thu Apr 9 08:10:48 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 09 Apr 2015 09:10:48 +0100 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <5526322D.1070008@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> Message-ID: <55263408.3040200@redhat.com> On 09/04/15 09:02, Erik Joelsson wrote: > I think that as long as we claim to support building both with and > without PCH, the automatic testing should test both with and without > PCH. By adding one or two build targets, or perhaps change an existing > target, we could increase our test matrix to cover this easily. I think this restates Volker's original remarks in redux. So, given that we do need this (NOW! :-) is anyone able and willing to sponsor this? regards, Andrew Dinn ----------- From edward.nevill at linaro.org Thu Apr 9 09:31:13 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Thu, 09 Apr 2015 10:31:13 +0100 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5512B817.3080802@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> Message-ID: <1428571873.26527.24.camel@mylittlepony.linaroharston> Hi Zolt?n, Thanks for the review. I have updated the patch to take account of your comments. New patch at http://cr.openjdk.java.net/~enevill/8075930/webrev.02/ Could someone please review this patch and if approved push. See inline comments below. On Wed, 2015-03-25 at 14:28 +0100, Zolt?n Maj? wrote: > On 03/25/2015 02:02 PM, Edward Nevill wrote: > > Hi, > > > > The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation. > > It seems to me that the C2 compiler currently saves the SP into FP on > method handle invokes. This functionality is encoded by > aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages > of FrameMap::method_handle_invoke_SP_save_opr()). So, this is an issue for C2 only, since my proposed patch does not affect register usage in C1, so C1 will continue to keep FP as unallocated. The change required for C2 is to let the register allocator know that FP will be killed by a methodhandle call. This is accomplished by the following change in aarch64.ad const RegMask Matcher::method_handle_invoke_SP_save_mask() { - return RegMask(); + return FP_REG_mask(); } > > Stack walking relies on having the SP saved into FP for method handle > invokes (e.g., in frame::adjust_unextended_sp()). > > Saving the SP into FP is not needed on some architectures (e.g., x86). > I'm currently working on an enhancement that disables saving the SP into > FP on x86 (see JDK-8068945). Maybe that could work for aarch64 as well. > > Does your change consider this aspect? Maybe running the tests in > jdk/test/java/lang/invoke/ could trigger some failures that are caused > by the FP not containing the SP of the caller of a method handle invocation. > I have run the jdk/test/java/lang/invoke tests both with and without the proposed patch. In bot cases 62 tests out of 62 passed. I have also rerun JTreg hotspot and langtools with the following results:- Before:- Hotspot: Test results: passed: 596; failed: 190; error: 26 Langtools: Test results: passed: 3,237; error: 9 After:- Hotspot: Test results: passed: 596; failed: 190; error: 26 Langtools: Test results: passed: 3,238; error: 8 All the best, Ed. From volker.simonis at gmail.com Thu Apr 9 09:34:41 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 9 Apr 2015 11:34:41 +0200 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <55263408.3040200@redhat.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> Message-ID: On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn wrote: > On 09/04/15 09:02, Erik Joelsson wrote: >> I think that as long as we claim to support building both with and >> without PCH, the automatic testing should test both with and without >> PCH. By adding one or two build targets, or perhaps change an existing >> target, we could increase our test matrix to cover this easily. > > I think this restates Volker's original remarks in redux. > No, not at all! I don't necessarily want to test more build configurations (that's another topic). My point is that PCH changes the compilation semantics and can hide real program errors. That's because with PCHs, every compilation unit sees the full precompiled header database (i.e. all the headers which are included in the "precompiled.hpp" PCH file). So if somebody forgets to include a dependency X.hpp in A.cpp, A.cpp may still compile with PCH because it includes the precompiled header file "precompiled.hpp" which in turn includes X.hpp. But the compilation of A.cpp will fail on platforms/configurations where we do not use precompiled headers. The two references I gave in my original mail are bugs that resulted from this problem. Besides program errors, the use of PCH can also lead to behavioral changes in the created binary when it comes to inlining. Because of PCHs some compilation units may be able to inline methods even if they do not explicitly include the files which contain the corresponding implementations because the implementation files are included in the PCH file. Without PCHs the compilers will simply emit calls to these functions (and, depending on the toolchain, emit a warning). I'm not familiar with ccache so I can not say if it has similar effects. > So, given that we do need this (NOW! :-) is anyone able and willing to > sponsor this? > Yes, this question remains to be answered :) Regards, Volker > regards, > > > Andrew Dinn > ----------- > From david.holmes at oracle.com Thu Apr 9 09:54:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Apr 2015 19:54:11 +1000 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <55263408.3040200@redhat.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> Message-ID: <55264C43.4060809@oracle.com> On 9/04/2015 6:10 PM, Andrew Dinn wrote: > On 09/04/15 09:02, Erik Joelsson wrote: >> I think that as long as we claim to support building both with and >> without PCH, the automatic testing should test both with and without >> PCH. By adding one or two build targets, or perhaps change an existing >> target, we could increase our test matrix to cover this easily. > > I think this restates Volker's original remarks in redux. > > So, given that we do need this (NOW! :-) is anyone able and willing to > sponsor this? It's an internal issue to modify the JPRT builds and people are looking at it. David > regards, > > > Andrew Dinn > ----------- > From vladimir.x.ivanov at oracle.com Thu Apr 9 14:17:27 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 09 Apr 2015 17:17:27 +0300 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <3AD9FDA1-CB4E-4F08-BC42-F1B311AA8D3A@univ-mlv.fr> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> <3AD9FDA1-CB4E-4F08-BC42-F1B311AA8D3A@univ-mlv.fr> Message-ID: <552689F7.7030605@oracle.com> On 4/9/15 9:10 AM, R?mi Forax wrote: > Hi David, > The problem is that j.l.i.MethodType.toString uses getSimpleName and j.l > i.WrongMethodTypeException uses MethodType.toString. > > So if getSimpleName returns a blank string, you destroy the debuggability of any invokedynamic/methodhandle calls. Debuggability is a different story. MethodType.toString() can produce ambiguous description, since it doesn't print all the details about the structure. Right now, if a MethodType refers to a problematic class, MethodType.toString() throws an InternalError("Malformed class name"). Best regards, Vladimir Ivanov > > regards, > R?mi > > Le 9 avril 2015 04:52:15 CEST, David Holmes a ?crit : >> Hi Vladimir, >> >> On 9/04/2015 1:41 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/jdk >>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/hotspot >>> https://bugs.openjdk.java.net/browse/JDK-8057919 >>> >>> The logic to compute simple name (Class.getSimpleName()) for >>> inner/nested/local classes is tightly coupled with Java naming scheme >>> and sometimes fails for classes generated from non-Java code. >> >> Meta-question: if this is non-Java code then what does/should >> "simpleName" even mean? "Returns the simple name of the underlying >> class >> as given in the source code." If there is no (java) source code does >> this have any meaning? Should it return "" ? >> >>> Instead of parsing class name and try to extract simple name based on >>> JLS rules, the fix I propose is to use InnerClasses attribute from >> the >>> class file. Simple name is already recorded there. >>> >>> JVMS-4.7.6: The InnerClasses Attribute >>> "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the >>> inner_name_index item must be zero. Otherwise, the value of the >>> inner_name_index item must be a valid index into the constant_pool >>> table, and the entry at that index must be a CONSTANT_Utf8_info >>> structure (?4.4.7) that represents the original simple name of C, as >>> given in the source code from which this class file was compiled." >>> >>> Since I consider backporting the fix into 8u60, I'd like to hear >>> opinions about backward compatibility of such change. >>> >>> As an alternative solution, I can restore original logic and consult >>> InnerClasses attribute when class name parsing logic fails. >> >> I think I'd prefer to see the VM call only used as a fallback if the >> regular parsing fails. That would prevent any compatibility issues for >> the 8u backport (ignoring tests that deliberately generate invalidly >> named classes). >> >> Thanks, >> David >> >>> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Thu Apr 9 14:51:06 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 09 Apr 2015 17:51:06 +0300 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <5525E95F.7080306@oracle.com> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> Message-ID: <552691DA.7000604@oracle.com> David, thanks for the feedback! Updated webrev: http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/jdk http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/hotspot I restored original logic and call into VM only if it fails. >> The logic to compute simple name (Class.getSimpleName()) for >> inner/nested/local classes is tightly coupled with Java naming scheme >> and sometimes fails for classes generated from non-Java code. > > Meta-question: if this is non-Java code then what does/should > "simpleName" even mean? "Returns the simple name of the underlying class > as given in the source code." If there is no (java) source code does > this have any meaning? Should it return "" ? My reading of the JVMS is that InnerClasses attribute can be freely used by non-Java compilers to store simple names for classes they generate. The current wording for inner_name_index doesn't mention Java language. Best regards, Vladimir Ivanov >> Instead of parsing class name and try to extract simple name based on >> JLS rules, the fix I propose is to use InnerClasses attribute from the >> class file. Simple name is already recorded there. > > >> JVMS-4.7.6: The InnerClasses Attribute >> "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the >> inner_name_index item must be zero. Otherwise, the value of the >> inner_name_index item must be a valid index into the constant_pool >> table, and the entry at that index must be a CONSTANT_Utf8_info >> structure (?4.4.7) that represents the original simple name of C, as >> given in the source code from which this class file was compiled." >> >> Since I consider backporting the fix into 8u60, I'd like to hear >> opinions about backward compatibility of such change. >> >> As an alternative solution, I can restore original logic and consult >> InnerClasses attribute when class name parsing logic fails. > > I think I'd prefer to see the VM call only used as a fallback if the > regular parsing fails. That would prevent any compatibility issues for > the 8u backport (ignoring tests that deliberately generate invalidly > named classes). > > Thanks, > David > >> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From roland.westrelin at oracle.com Thu Apr 9 14:57:31 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 9 Apr 2015 16:57:31 +0200 Subject: [8u] backport of 8069263: assert(fm == NULL || fm->method_holder() == _participants[n]) failed: sanity In-Reply-To: <552549C0.6050207@oracle.com> References: <9674B27B-9CF3-4254-93E9-EEA9DAA32943@oracle.com> <552549C0.6050207@oracle.com> Message-ID: <2BF6EFE2-F84F-465E-976A-B75BE2556C41@oracle.com> Thanks, Vladimir. Roland. > On Apr 8, 2015, at 5:31 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 4/8/15 6:04 AM, Roland Westrelin wrote: >> 8u backport request. 8069263 was pushed to jdk9 2 weeks ago and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u. >> >> https://bugs.openjdk.java.net/browse/JDK-8069263 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/da130fa0ba00 >> >> Roland. >> From vladimir.kozlov at oracle.com Thu Apr 9 17:32:33 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Apr 2015 10:32:33 -0700 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1428571873.26527.24.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> Message-ID: <5526B7B1.7000702@oracle.com> Hi Edward, In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM. Unless you have configuration without C2. I think it should be dynamic check after you find who generated this _cb. Can you explain what this code does (there is not comment): 80 #ifndef PRODUCT 81 if (fp) 82 if (sp > fp || (fp - sp > 0x100000)) 83 for(;;) 84 asm("nop"); 85 #endif Thanks, Vladimir On 4/9/15 2:31 AM, Edward Nevill wrote: > Hi Zolt?n, > > Thanks for the review. I have updated the patch to take account of your comments. New patch at > > http://cr.openjdk.java.net/~enevill/8075930/webrev.02/ > > Could someone please review this patch and if approved push. > > See inline comments below. > > On Wed, 2015-03-25 at 14:28 +0100, Zolt?n Maj? wrote: >> On 03/25/2015 02:02 PM, Edward Nevill wrote: >>> Hi, >>> >>> The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation. >> >> It seems to me that the C2 compiler currently saves the SP into FP on >> method handle invokes. This functionality is encoded by >> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages >> of FrameMap::method_handle_invoke_SP_save_opr()). > > So, this is an issue for C2 only, since my proposed patch does not affect register usage in C1, so C1 will continue to keep FP as unallocated. > > The change required for C2 is to let the register allocator know that FP will be killed by a methodhandle call. This is accomplished by the following change in aarch64.ad > > const RegMask Matcher::method_handle_invoke_SP_save_mask() { > - return RegMask(); > + return FP_REG_mask(); > } > >> >> Stack walking relies on having the SP saved into FP for method handle >> invokes (e.g., in frame::adjust_unextended_sp()). >> >> Saving the SP into FP is not needed on some architectures (e.g., x86). >> I'm currently working on an enhancement that disables saving the SP into >> FP on x86 (see JDK-8068945). Maybe that could work for aarch64 as well. >> >> Does your change consider this aspect? Maybe running the tests in >> jdk/test/java/lang/invoke/ could trigger some failures that are caused >> by the FP not containing the SP of the caller of a method handle invocation. >> > > I have run the jdk/test/java/lang/invoke tests both with and without the > proposed patch. In bot cases 62 tests out of 62 passed. > > I have also rerun JTreg hotspot and langtools with the following > results:- > > Before:- > > Hotspot: Test results: passed: 596; failed: 190; error: 26 > Langtools: Test results: passed: 3,237; error: 9 > > After:- > > Hotspot: Test results: passed: 596; failed: 190; error: 26 > Langtools: Test results: passed: 3,238; error: 8 > > All the best, > Ed. > > > > From aph at redhat.com Thu Apr 9 17:55:40 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 09 Apr 2015 18:55:40 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5526B7B1.7000702@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> Message-ID: <5526BD1C.6040406@redhat.com> On 04/09/2015 06:32 PM, Vladimir Kozlov wrote: > Can you explain what this code does (there is not comment): > > 80 #ifndef PRODUCT > 81 if (fp) > 82 if (sp > fp || (fp - sp > 0x100000)) > 83 for(;;) > 84 asm("nop"); > 85 #endif It's mine. It's a simple sanity check I put in way before the dawn of time which allows a debugger to be attached to see a corrupt stack.. It was tremendously useful. It can go if it's no longer needed. Andrew. From max.ockner at oracle.com Thu Apr 9 19:11:27 2015 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 09 Apr 2015 15:11:27 -0400 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <55232E90.7060701@oracle.com> References: <551D9AC6.50208@oracle.com> <55232E90.7060701@oracle.com> Message-ID: <5526CEDF.20004@oracle.com> Hi again, After working past some build issues, I have a new webrev. I've changed %x to PTR_FORMAT, and I've removed the modification to thread.cpp New webrev: http://cr.openjdk.java.net/~mockner/8029630.4/ Thanks, Max On 4/6/2015 9:10 PM, David Holmes wrote: > Hi Max, > > On 3/04/2015 5:38 AM, Max Ockner wrote: >> Hello, >> Please review this change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >> Summary: Existing error messages for vm crashes print the decimal >> representation of the current thread id. The message format has been >> changed to print the hex value of the thread id. > > src/share/vm/runtime/thread.cpp > > The change is incorrect and unnecessary. 'this' is a pointer type so > INTPTR_FORMAT seems correct (though it may need p2i(this)?) while %x > assumes 'this' is always 32-bit. Further INTPTR_FORMAT is already hex > not decimal. > > src/share/vm/utilities/vmError.cpp > > As Thomas pointed out%x assumes 32-bit and so is incorrect for intx > type. As intx is a typedef for intptr_t then INTPTR_FORMAT should be > usable here as well. > > David > >> Tested with jtreg runtime to make sure nothing was broken. I tested the >> new functionality separately. I crashed the vm and examined the debugger >> output to make sure the hexadecimal thread id printed in the error >> message matched one of the threads listed by the debugger. >> >> Thanks, >> Max From thomas.stuefe at gmail.com Thu Apr 9 19:44:12 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 9 Apr 2015 21:44:12 +0200 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <5526CEDF.20004@oracle.com> References: <551D9AC6.50208@oracle.com> <55232E90.7060701@oracle.com> <5526CEDF.20004@oracle.com> Message-ID: Hi Max, looks ok and will certainly do what you want. I guess whether you use PTR_FORMAT, INTPTR_FORMAT or SIZE_FORMAT_HEX is mostly a matter of taste. The former two will give you full-width numbers (e.g. 0x00000000000000A1), the last one would give you just 0xA1. Kind Regards, Thomas On Thu, Apr 9, 2015 at 9:11 PM, Max Ockner wrote: > Hi again, > After working past some build issues, I have a new webrev. I've changed > %x to PTR_FORMAT, and I've removed the modification to thread.cpp > > New webrev: http://cr.openjdk.java.net/~mockner/8029630.4/ > > Thanks, > Max > > > On 4/6/2015 9:10 PM, David Holmes wrote: > >> Hi Max, >> >> On 3/04/2015 5:38 AM, Max Ockner wrote: >> >>> Hello, >>> Please review this change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >>> Summary: Existing error messages for vm crashes print the decimal >>> representation of the current thread id. The message format has been >>> changed to print the hex value of the thread id. >>> >> >> src/share/vm/runtime/thread.cpp >> >> The change is incorrect and unnecessary. 'this' is a pointer type so >> INTPTR_FORMAT seems correct (though it may need p2i(this)?) while %x >> assumes 'this' is always 32-bit. Further INTPTR_FORMAT is already hex not >> decimal. >> >> src/share/vm/utilities/vmError.cpp >> >> As Thomas pointed out%x assumes 32-bit and so is incorrect for intx type. >> As intx is a typedef for intptr_t then INTPTR_FORMAT should be usable here >> as well. >> >> David >> >> Tested with jtreg runtime to make sure nothing was broken. I tested the >>> new functionality separately. I crashed the vm and examined the debugger >>> output to make sure the hexadecimal thread id printed in the error >>> message matched one of the threads listed by the debugger. >>> >>> Thanks, >>> Max >>> >> > From david.holmes at oracle.com Thu Apr 9 23:16:50 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Apr 2015 09:16:50 +1000 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <552691DA.7000604@oracle.com> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> <552691DA.7000604@oracle.com> Message-ID: <55270862.9020704@oracle.com> Hi Vladimir, On 10/04/2015 12:51 AM, Vladimir Ivanov wrote: > David, thanks for the feedback! > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/jdk > http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/hotspot > > I restored original logic and call into VM only if it fails. This change seems fine to me, but I think John may prefer to see getSimpleName implemented such that it always returns the name from the innerclass attribute. (Though perhaps with caching if performance is a concern?) >>> The logic to compute simple name (Class.getSimpleName()) for >>> inner/nested/local classes is tightly coupled with Java naming scheme >>> and sometimes fails for classes generated from non-Java code. >> >> Meta-question: if this is non-Java code then what does/should >> "simpleName" even mean? "Returns the simple name of the underlying class >> as given in the source code." If there is no (java) source code does >> this have any meaning? Should it return "" ? > My reading of the JVMS is that InnerClasses attribute can be freely used > by non-Java compilers to store simple names for classes they generate. > The current wording for inner_name_index doesn't mention Java language. True, but it does refer to source code: "represents the original simple name of C, as given in the source code from which this class file was compiled. " which seems misplaced as we're discussing classes for which there is no source code as such. Anyway it just flags to me that perhaps these Class methods need to be generalized a bit given the support for non-Java languages on the JVM. But that's for core-libs folk to decide. Thanks, David > Best regards, > Vladimir Ivanov > >>> Instead of parsing class name and try to extract simple name based on >>> JLS rules, the fix I propose is to use InnerClasses attribute from the >>> class file. Simple name is already recorded there. >> > >>> JVMS-4.7.6: The InnerClasses Attribute >>> "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the >>> inner_name_index item must be zero. Otherwise, the value of the >>> inner_name_index item must be a valid index into the constant_pool >>> table, and the entry at that index must be a CONSTANT_Utf8_info >>> structure (?4.4.7) that represents the original simple name of C, as >>> given in the source code from which this class file was compiled." >>> >>> Since I consider backporting the fix into 8u60, I'd like to hear >>> opinions about backward compatibility of such change. >>> >>> As an alternative solution, I can restore original logic and consult >>> InnerClasses attribute when class name parsing logic fails. >> >> I think I'd prefer to see the VM call only used as a fallback if the >> regular parsing fails. That would prevent any compatibility issues for >> the 8u backport (ignoring tests that deliberately generate invalidly >> named classes). >> >> Thanks, >> David >> >>> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov From david.holmes at oracle.com Fri Apr 10 01:48:10 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Apr 2015 11:48:10 +1000 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <5526CEDF.20004@oracle.com> References: <551D9AC6.50208@oracle.com> <55232E90.7060701@oracle.com> <5526CEDF.20004@oracle.com> Message-ID: <55272BDA.2060908@oracle.com> Hi Max, On 10/04/2015 5:11 AM, Max Ockner wrote: > Hi again, > After working past some build issues, I have a new webrev. I've changed > %x to PTR_FORMAT, and I've removed the modification to thread.cpp > > New webrev: http://cr.openjdk.java.net/~mockner/8029630.4/ I think INTPTR_FORMAT would be more of a semantic match as the thread id is not a pointer type. David > Thanks, > Max > > On 4/6/2015 9:10 PM, David Holmes wrote: >> Hi Max, >> >> On 3/04/2015 5:38 AM, Max Ockner wrote: >>> Hello, >>> Please review this change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >>> Summary: Existing error messages for vm crashes print the decimal >>> representation of the current thread id. The message format has been >>> changed to print the hex value of the thread id. >> >> src/share/vm/runtime/thread.cpp >> >> The change is incorrect and unnecessary. 'this' is a pointer type so >> INTPTR_FORMAT seems correct (though it may need p2i(this)?) while %x >> assumes 'this' is always 32-bit. Further INTPTR_FORMAT is already hex >> not decimal. >> >> src/share/vm/utilities/vmError.cpp >> >> As Thomas pointed out%x assumes 32-bit and so is incorrect for intx >> type. As intx is a typedef for intptr_t then INTPTR_FORMAT should be >> usable here as well. >> >> David >> >>> Tested with jtreg runtime to make sure nothing was broken. I tested the >>> new functionality separately. I crashed the vm and examined the debugger >>> output to make sure the hexadecimal thread id printed in the error >>> message matched one of the threads listed by the debugger. >>> >>> Thanks, >>> Max > From zoltan.majo at oracle.com Fri Apr 10 06:31:39 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Apr 2015 08:31:39 +0200 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1428571873.26527.24.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> Message-ID: <55276E4B.6000604@oracle.com> Hi Ed, this looks good to me (not a *R*eviewer). Thank you and best regards, Zoltan On 04/09/2015 11:31 AM, Edward Nevill wrote: > Hi Zolt?n, > > Thanks for the review. I have updated the patch to take account of your comments. New patch at > > http://cr.openjdk.java.net/~enevill/8075930/webrev.02/ > > Could someone please review this patch and if approved push. > > See inline comments below. > > On Wed, 2015-03-25 at 14:28 +0100, Zolt?n Maj? wrote: >> On 03/25/2015 02:02 PM, Edward Nevill wrote: >>> Hi, >>> >>> The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation. >> It seems to me that the C2 compiler currently saves the SP into FP on >> method handle invokes. This functionality is encoded by >> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages >> of FrameMap::method_handle_invoke_SP_save_opr()). > So, this is an issue for C2 only, since my proposed patch does not affect register usage in C1, so C1 will continue to keep FP as unallocated. > > The change required for C2 is to let the register allocator know that FP will be killed by a methodhandle call. This is accomplished by the following change in aarch64.ad > > const RegMask Matcher::method_handle_invoke_SP_save_mask() { > - return RegMask(); > + return FP_REG_mask(); > } > >> Stack walking relies on having the SP saved into FP for method handle >> invokes (e.g., in frame::adjust_unextended_sp()). >> >> Saving the SP into FP is not needed on some architectures (e.g., x86). >> I'm currently working on an enhancement that disables saving the SP into >> FP on x86 (see JDK-8068945). Maybe that could work for aarch64 as well. >> >> Does your change consider this aspect? Maybe running the tests in >> jdk/test/java/lang/invoke/ could trigger some failures that are caused >> by the FP not containing the SP of the caller of a method handle invocation. >> > I have run the jdk/test/java/lang/invoke tests both with and without the > proposed patch. In bot cases 62 tests out of 62 passed. > > I have also rerun JTreg hotspot and langtools with the following > results:- > > Before:- > > Hotspot: Test results: passed: 596; failed: 190; error: 26 > Langtools: Test results: passed: 3,237; error: 9 > > After:- > > Hotspot: Test results: passed: 596; failed: 190; error: 26 > Langtools: Test results: passed: 3,238; error: 8 > > All the best, > Ed. > > > > From david.holmes at oracle.com Fri Apr 10 07:47:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Apr 2015 17:47:14 +1000 Subject: Replacing syscall(_NR_fork) on linux with syscall(_NR_clone) Message-ID: <55278002.8040705@oracle.com> In os::fork_and_exec we provide a per platform fork/exec implementation for use by the OnError and OnOutOfMemory JVM options. On linux this is implemented with direct syscalls to _NR_fork (sys_fork) and _NR_execve. We already encountered a problem on linux-sparc: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-February/013811.html due to a different register usage for the return value, which is so far restricted to the 7u train but will need addressing in 8u and 9. Further it seems that the fork syscall has actually been deprecated for quite some time and we are now seeing kernels on some platforms which are no longer providing any of the deprecated syscalls - we simply get an error ENOSYS. The fork() library was updated to use clone a long time ago, but as I understand it we can't use the fork() library call because we might be executing in a signal-handling context within the error handler. So I'm considering switching to use the clone syscall for all linux systems. Thoughts/comments? David From roland.westrelin at oracle.com Fri Apr 10 08:09:14 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 10 Apr 2015 10:09:14 +0200 Subject: [8u] backport of 8075587: Compilation of constant array containing different sub classes crashes the JVM In-Reply-To: <55254A82.50109@oracle.com> References: <0DFBD0F8-8112-43F5-B295-BB99BDB18327@oracle.com> <55254A82.50109@oracle.com> Message-ID: <5DD41125-35DB-412C-8BA9-C234DADF13B7@oracle.com> Thanks, Vladimir. Roland. > On Apr 8, 2015, at 5:34 PM, Vladimir Kozlov wrote: > > Okay. > > Thanks, > Vladimir > > On 4/8/15 6:16 AM, Roland Westrelin wrote: >> 8u backport request. 8075587 was pushed to jdk9 1 week ago and it hasn?t caused any new failures during nightly testing. The >> change applies cleanly to 8u (identical change with an offset of -133 lines in file type.cpp). >> >> https://bugs.openjdk.java.net/browse/JDK-8075587 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/215053fb9d59 >> >> Roland. >> From edward.nevill at linaro.org Fri Apr 10 08:54:59 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Fri, 10 Apr 2015 09:54:59 +0100 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5526B7B1.7000702@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> Message-ID: <1428656099.13172.10.camel@mylittlepony.linaroharston> Hi Vladimir, On Thu, 2015-04-09 at 10:32 -0700, Vladimir Kozlov wrote: > Hi Edward, > > In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM. > Unless you have configuration without C2. I think it should be dynamic check after you find who generated this _cb. > Can you explain what this code does (there is not comment): We do build without C2 as part of our testing. However, as Andrew Haley said, this is old debug code, so I propose simply removing it. Its usefulness is rather limited once fp can be allocated as a general purpose register. > > 80 #ifndef PRODUCT > 81 if (fp) > 82 if (sp > fp || (fp - sp > 0x100000)) > 83 for(;;) > 84 asm("nop"); > 85 #endif New webrev removing this code @ http://cr.openjdk.java.net/~enevill/8075930/webrev.03/ All the best, Ed. From aph at redhat.com Fri Apr 10 08:58:07 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Apr 2015 09:58:07 +0100 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1428656099.13172.10.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> Message-ID: <5527909F.70105@redhat.com> On 04/10/2015 09:54 AM, Edward Nevill wrote: > In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM. I've never really understood the reason for this limitation. With a few lines of code it's possible to build a perfectly good client VM. Why should 64-bit systems not be able to build a client VM? Andrew. From thomas.stuefe at gmail.com Fri Apr 10 10:36:19 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 10 Apr 2015 12:36:19 +0200 Subject: Replacing syscall(_NR_fork) on linux with syscall(_NR_clone) In-Reply-To: <55278002.8040705@oracle.com> References: <55278002.8040705@oracle.com> Message-ID: Hi David, it is difficult to understand Linux implementation of os::fork_and_exec() fully. Comment claims fork() would not be async safe for use in signal handler, but I do not see why (maybe I am being slow here): pthread_atfork() handlers get called in the context of the thread calling the fork(). Depending on the pthread_atfork handlers, this may make the code non-reentrant, but async-unsafe? Also the comment above the execve syscall is a bit of a riddle. "execve() will instead kill every thread in the parent process.". I would love to understand why. But if pthread_atfork handlers are the problem, how about just deactivating pthread_atfork handlers for the duration of os::fork_and_exec? Note that the jdk itself does not install pthread_atfork handlers, so this only affects user handlers. Another alternative to using raw syscalls would be to use posix_spawn(), which I believe does not call pthread_atfork handlers. Regards, Thomas On Fri, Apr 10, 2015 at 9:47 AM, David Holmes wrote: > In os::fork_and_exec we provide a per platform fork/exec implementation > for use by the OnError and OnOutOfMemory JVM options. > > On linux this is implemented with direct syscalls to _NR_fork (sys_fork) > and _NR_execve. > > We already encountered a problem on linux-sparc: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/ > 2015-February/013811.html > > due to a different register usage for the return value, which is so far > restricted to the 7u train but will need addressing in 8u and 9. > > Further it seems that the fork syscall has actually been deprecated for > quite some time and we are now seeing kernels on some platforms which are > no longer providing any of the deprecated syscalls - we simply get an error > ENOSYS. > > The fork() library was updated to use clone a long time ago, but as I > understand it we can't use the fork() library call because we might be > executing in a signal-handling context within the error handler. > > So I'm considering switching to use the clone syscall for all linux > systems. > > Thoughts/comments? > > David > > From thomas.stuefe at gmail.com Fri Apr 10 11:25:11 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 10 Apr 2015 13:25:11 +0200 Subject: RFR(xs): 8076475: Misuses of strncpy/strncat In-Reply-To: <55279C36.2000004@oracle.com> References: <552521AF.3060302@oracle.com> <55278DE9.5000600@oracle.com> <55279C36.2000004@oracle.com> Message-ID: .. adding hotspot-dev to attract another reviewer. On Fri, Apr 10, 2015 at 11:47 AM, Dmitry Samersoff < dmitry.samersoff at oracle.com> wrote: > Thomas, > > I can sponsor the push, but you need an official reviewer. > > -Dmitry > > On 2015-04-10 12:31, Thomas St?fe wrote: > > Dmitry, Thanks for the review! > > > > Still need a second review and also a sponsor. > > > > .. Thomas > > > > On Apr 10, 2015 10:46 AM, "Dmitry Samersoff" > > > > wrote: > > > > Thomas, > > > > Looks good for me! > > > > Thank you for doing it. > > > > -Dmitry > > > > On 2015-04-10 10:50, Thomas St?fe wrote: > > > Hi Dimitry, > > > > > > see new version here: > > > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8076475/webrev.01/webrev/ > > > > > > > > > On Wed, Apr 8, 2015 at 2:40 PM, Dmitry Samersoff > > > > > > >> wrote: > > > > > > Thomas, > > > > > > ** agent/src/os/bsd/libproc_impl.c > > > ** agent/src/os/linux/libproc_impl.c > > > > > > newlib->name has the size of (PATH_MAX + NAME_MAX + 1) > > > > > > see ./src/os/bsd/libproc_impl.h:92 > > > > > > So no truncation is actually possible here. > > > > > > To make this code nice-looking it's better to add: > > > > > > if (strlen(libname) > sizeof(newlib->name)) { > > > // Bail out with debug message > > > ... > > > } > > > strcpy(newlib->name, libname); > > > > > > rather than use snprintf here. > > > > > > > > > I changed the coding according to your suggestions. > > > > > > There is still the strlen vs strnlen question Kim mentioned, but > > we use > > > strlen all over the place, and I am not sure if all platforms > > support it > > > (AIX was known to have a broken strnlen implementation, one would > need > > > to check that first before changing strlen to strnlen) > > > > > > > > > ** arguments.cpp:3466 > > > > > > It might be better to use snprintf here. > > > > > > > > > Agree, done > > > > > > > > > ** arguments.cpp:3629 > > > > > > It's better to just replace strncat/strncpy to strcat/strcpy > > > in the original code - as soon as we allocating memory with > > respect to > > > variable lenght, we don't need to check this length again. > > > > > > > > > Sorry, I disagree here - I think using snprintf makes the code more > > > readable. It comes down to a matter of taste, so lets see what > > others think. > > > > > > > > > > > > ** vmError.cpp:222 > > > > > > It's better to keep original code. > > > > > > > > > Agree, done > > > > > > Best Regards, Thomas > > > > > > > > > > > > Other changes looks good for me! > > > -Dmitry > > > > > > > > > On 2015-04-08 11:09, Thomas St?fe wrote: > > > > Hi, > > > > > > > > please review these small fixes around use of > strncpy/strncat. > > > > > > > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8076475 > > > > Webrev: > > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8076475/webrev.00/webrev/ > > > > > > > > Changes in detail are: > > > > > > > > agent/src/os/bsd/libproc_impl.c > > > > agent/src/os/linux/libproc_impl.c: > > > > - missing \0 on truncation. Replaced with > > > snprintf, add > > > > truncation handling > > > > > > > > src/os/bsd/dtrace/libjvm_db.c > > > > src/os/solaris/dtrace/libjvm_db.c > > > > @@ -580,17 +580,18 @@ > > > > - overwrite on truncation > > > > @@ -1093,13 +1094,13 @@ > > > > - overwrite on truncation > > > > > > > > src/share/vm/compiler/compileBroker.hpp > > > > - missing \0 on truncation. > > > > > > > > src/share/tools/hsdis/hsdis.c > > > > - missing \0 > > > > > > > > src/os/bsd/vm/decoder_machO.cpp > > > > - missing \0 on truncation. > > > > > > > > src/share/vm/compiler/compilerOracle.cpp > > > > - Replaced with jio_snprintf, less awkward > and > > > does not > > > > restrict each part to 255 chars each. > > > > > > > > src/share/vm/compiler/disassembler.cpp > > > > - missing \0 on truncation. > > > > > > > > src/share/vm/runtime/arguments.cpp > > > > @@ -2703,11 +2703,11 @@ > > > > - replaced with strdup, easier to read > > > > @@ -3294,12 +3294,11 @@ > > > > - the same > > > > @@ -3627,18 +3626,14 @@ > > > > - replace strncpy/strncat sequence with > > jio_snprintf - > > > > easier to read. > > > > - replace malloc/strncpy with os::strdup > > > > > > > > src/share/vm/utilities/ostream.cpp > > > > - avoid \0 padding > > > > > > > > src/share/vm/utilities/vmError.cp > > > > @@ -219,7 +219,7 @@ > > > > - avoid \0 padding > > > > @@ -463,14 +463,7 @@ > > > > - simplified > > > > > > > > Kind regards, Thomas > > > > > > > > > > > > > -- > > > Dmitry Samersoff > > > Oracle Java development team, Saint Petersburg, Russia > > > * I would love to change the world, but they won't give me the > > sources. > > > > > > > > > > > > -- > > Dmitry Samersoff > > Oracle Java development team, Saint Petersburg, Russia > > * I would love to change the world, but they won't give me the > sources. > > > > > -- > 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 martinrb at google.com Fri Apr 10 14:19:02 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 10 Apr 2015 07:19:02 -0700 Subject: Replacing syscall(_NR_fork) on linux with syscall(_NR_clone) In-Reply-To: <55278002.8040705@oracle.com> References: <55278002.8040705@oracle.com> Message-ID: At Google, we also had trouble with syscall(__NR_fork). We switched to simply calling fork despite the ominous warnings and have had no trouble since. We avoid calling clone - see my old failures with it in UNIXProcess_md.c. Although if we follow the successful precedent of UNIXProcess_md.c we should call vfork instead, but we haven't yet had the need. @@ -6012,8 +6689,15 @@ // separate process to execve. Make a direct syscall to fork process. // On IA64 there's no fork syscall, we have to use fork() and hope for // the best... - pid_t pid = NOT_IA64(syscall(__NR_fork);) - IA64_ONLY(fork();) + // pid_t pid = NOT_IA64(syscall(__NR_fork);) + // IA64_ONLY(fork();) + + // Google Specific: Changing the above code to use the fork glibc call in + // NOT_IA64. This allows the successful execution of the fork in a case where + // the previous syscall hung and hence allows successful OOM exit. + // We believe that fork() is now async-safe and suspect the above note about + // pthread_atfork handlers and resetting the pthread library is outdated. + pid_t pid = fork(); if (pid < 0) { // fork failed @@ -6029,10 +6713,16 @@ // in the new process, so make a system call directly. // IA64 should use normal execve() from glibc to match the glibc fork() // above. - NOT_IA64(syscall(__NR_execve, "/bin/sh", argv, environ);) - IA64_ONLY(execve("/bin/sh", (char* const*)argv, environ);) + // NOT_IA64(syscall(__NR_execve, "/bin/sh", argv, environ);) + // IA64_ONLY(execve("/bin/sh", (char* const*)argv, environ);) + + // Google Specific: Based on fork case above changed this code to use execve + // glibc call in NOT_IA64 case. + execve("/bin/sh", (char* const*)argv, environ); // execve failed + tty->print_cr("execve of OnError command \"/bin/sh -c %s\" failed with errno %d: %s", + cmd, errno, strerror(errno)); _exit(-1); } else { On Fri, Apr 10, 2015 at 12:47 AM, David Holmes wrote: > In os::fork_and_exec we provide a per platform fork/exec implementation > for use by the OnError and OnOutOfMemory JVM options. > > On linux this is implemented with direct syscalls to _NR_fork (sys_fork) > and _NR_execve. > > We already encountered a problem on linux-sparc: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/ > 2015-February/013811.html > > due to a different register usage for the return value, which is so far > restricted to the 7u train but will need addressing in 8u and 9. > > Further it seems that the fork syscall has actually been deprecated for > quite some time and we are now seeing kernels on some platforms which are > no longer providing any of the deprecated syscalls - we simply get an error > ENOSYS. > > The fork() library was updated to use clone a long time ago, but as I > understand it we can't use the fork() library call because we might be > executing in a signal-handling context within the error handler. > > So I'm considering switching to use the clone syscall for all linux > systems. > > Thoughts/comments? > > David > > From vladimir.kozlov at oracle.com Fri Apr 10 14:44:09 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Apr 2015 07:44:09 -0700 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1428656099.13172.10.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> Message-ID: <5527E1B9.5030109@oracle.com> Looks good. Thanks, Vladimir On 4/10/15 1:54 AM, Edward Nevill wrote: > Hi Vladimir, > > On Thu, 2015-04-09 at 10:32 -0700, Vladimir Kozlov wrote: >> Hi Edward, >> >> In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM. >> Unless you have configuration without C2. I think it should be dynamic check after you find who generated this _cb. >> Can you explain what this code does (there is not comment): > > We do build without C2 as part of our testing. However, as Andrew Haley said, this is old debug code, so I propose simply removing it. Its usefulness is rather limited once fp can be allocated as a general purpose register. > >> >> 80 #ifndef PRODUCT >> 81 if (fp) >> 82 if (sp > fp || (fp - sp > 0x100000)) >> 83 for(;;) >> 84 asm("nop"); >> 85 #endif > > New webrev removing this code @ > > http://cr.openjdk.java.net/~enevill/8075930/webrev.03/ > > All the best, > Ed. > > From vladimir.kozlov at oracle.com Fri Apr 10 14:53:50 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Apr 2015 07:53:50 -0700 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5527909F.70105@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527909F.70105@redhat.com> Message-ID: <5527E3FE.1030707@oracle.com> On 4/10/15 1:58 AM, Andrew Haley wrote: > On 04/10/2015 09:54 AM, Edward Nevill wrote: >> In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM. > > I've never really understood the reason for this limitation. With a few > lines of code it's possible to build a perfectly good client VM. Why > should 64-bit systems not be able to build a client VM? > > Andrew. Yes, from technical point of view it could be done. But from financial - we don't see the need to support this configuration (for now). For the same reason, as you noticed, we removed support of 32-bit VM from Solaris (x86 and Sparc). You still can build it but eventually it will rot. Regards, Vladimir From john.r.rose at oracle.com Fri Apr 10 19:15:01 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 10 Apr 2015 12:15:01 -0700 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <55270862.9020704@oracle.com> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> <552691DA.7000604@oracle.com> <55270862.9020704@oracle.com> Message-ID: <38AF71DB-944B-42B8-A955-C5173881BE63@oracle.com> On Apr 9, 2015, at 4:16 PM, David Holmes wrote: > > Hi Vladimir, > > On 10/04/2015 12:51 AM, Vladimir Ivanov wrote: >> David, thanks for the feedback! >> >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/jdk >> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/hotspot >> >> I restored original logic and call into VM only if it fails. > > This change seems fine to me, but I think John may prefer to see getSimpleName implemented such that it always returns the name from the innerclass attribute. (Though perhaps with caching if performance is a concern?) Yes, I do prefer the new logic instead of a combination of old and new. Two concerns: Somebody somewhere might be relying on a bug in the old logic and be frustrated by seeing that bug fixed. This is a fine line to walk, but in this case I think the behavior change (if any) will show up in places where we already have outages. Perhaps someone is post-processing the result of getSimpleName to correct it. If so they may no longer need to do that. Second, the new logic may itself have issues. A typical problem with the InnerClasses attribute is it is broken or stripped, or a related nestmate is missing. (See parallel thread in core-libs-dev on 8076264.) But the proposed change takes effect after a call to Class.getEnclosingClass, which uses InstanceKlass::compute_enclosing_class_impl and accesses the same InnerClasses record. This leads me to a comment: The common code (two uses of InnerClassesIterator with klass_name_at_matches) should be factored out. The factored subroutine should search out the self-record in the InnerClasses attribute. The logic is tricky enough that I'm uncomfortable with it being duplicated. Key issue: We don't want to load any classes doing this lookup. (For bonus points, factor the third use in that file, the one that looks not for self but for children-of-self. Add a boolean flag that varies the test.) Bottom line: The new logic should replace the old. > >>>> The logic to compute simple name (Class.getSimpleName()) for >>>> inner/nested/local classes is tightly coupled with Java naming scheme >>>> and sometimes fails for classes generated from non-Java code. >>> >>> Meta-question: if this is non-Java code then what does/should >>> "simpleName" even mean? "Returns the simple name of the underlying class >>> as given in the source code." If there is no (java) source code does >>> this have any meaning? Should it return "" ? >> My reading of the JVMS is that InnerClasses attribute can be freely used >> by non-Java compilers to store simple names for classes they generate. >> The current wording for inner_name_index doesn't mention Java language. > > True, but it does refer to source code: "represents the original simple name of C, as given in the source code from which this class file was compiled. " which seems misplaced as we're discussing classes for which there is no source code as such. It could be non-Java source code. In any case, the indicated component of the "binary name" of the class is well-defined, whether or not it occurs in source code. Note also that classes might be generated by ASM (no source code per se) but we still have a reasonable expectation of reflecting on them, even though reflection is (mostly) defined in terms of source code constructs. > Anyway it just flags to me that perhaps these Class methods need to be generalized a bit given the support for non-Java languages on the JVM. But that's for core-libs folk to decide. Yes, I think that's the issue. The multi-language folks (like me) would be disappointed to hear that we decided that non-Java languages don't have any needs here; they do. Thanks, ? John > Thanks, > David > >> Best regards, >> Vladimir Ivanov >> >>>> Instead of parsing class name and try to extract simple name based on >>>> JLS rules, the fix I propose is to use InnerClasses attribute from the >>>> class file. Simple name is already recorded there. >>> > >>>> JVMS-4.7.6: The InnerClasses Attribute >>>> "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the >>>> inner_name_index item must be zero. Otherwise, the value of the >>>> inner_name_index item must be a valid index into the constant_pool >>>> table, and the entry at that index must be a CONSTANT_Utf8_info >>>> structure (?4.4.7) that represents the original simple name of C, as >>>> given in the source code from which this class file was compiled." >>>> >>>> Since I consider backporting the fix into 8u60, I'd like to hear >>>> opinions about backward compatibility of such change. >>>> >>>> As an alternative solution, I can restore original logic and consult >>>> InnerClasses attribute when class name parsing logic fails. >>> >>> I think I'd prefer to see the VM call only used as a fallback if the >>> regular parsing fails. That would prevent any compatibility issues for >>> the 8u backport (ignoring tests that deliberately generate invalidly >>> named classes). >>> >>> Thanks, >>> David >>> >>>> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov From serguei.spitsyn at oracle.com Fri Apr 10 20:29:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 Apr 2015 13:29:35 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <5514C2C1.9040302@oracle.com> References: <5514C2C1.9040302@oracle.com> Message-ID: <552832AF.8080204@oracle.com> Hi Coleen and Dan, This is the second class redefinition scalability/optimization fix that is in my queue to push into 9 and 8u60. The approach is similar to the first one but much smaller. For convenience, these are the links to the first scalability fix: Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ Please, let me know if you have any chance to review this. This is the last one that is waiting for your attention! :) Thanks, Serguei On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8073705 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ > > > > Summary: > > This is the 2-nd round of performance/calability fixes in class > redefinition. > This time, the two remaining issues that were left alone in the > first round fix: > - optimized ConstantPoolCache::adjust_method_entries() is used > for previous versions > - the MemberNameTable::adjust_method_entries() has been optimized > too > - some cleanup > > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument, > com/sun/jdi > > > Thanks, > Serguei > From harold.seigel at oracle.com Fri Apr 10 20:44:39 2015 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 10 Apr 2015 16:44:39 -0400 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <5526CEDF.20004@oracle.com> References: <551D9AC6.50208@oracle.com> <55232E90.7060701@oracle.com> <5526CEDF.20004@oracle.com> Message-ID: <55283637.7070607@oracle.com> Hi Max, The change looks good. Harold On 4/9/2015 3:11 PM, Max Ockner wrote: > Hi again, > After working past some build issues, I have a new webrev. I've > changed %x to PTR_FORMAT, and I've removed the modification to thread.cpp > > New webrev: http://cr.openjdk.java.net/~mockner/8029630.4/ > > Thanks, > Max > > On 4/6/2015 9:10 PM, David Holmes wrote: >> Hi Max, >> >> On 3/04/2015 5:38 AM, Max Ockner wrote: >>> Hello, >>> Please review this change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >>> Summary: Existing error messages for vm crashes print the decimal >>> representation of the current thread id. The message format has been >>> changed to print the hex value of the thread id. >> >> src/share/vm/runtime/thread.cpp >> >> The change is incorrect and unnecessary. 'this' is a pointer type so >> INTPTR_FORMAT seems correct (though it may need p2i(this)?) while %x >> assumes 'this' is always 32-bit. Further INTPTR_FORMAT is already hex >> not decimal. >> >> src/share/vm/utilities/vmError.cpp >> >> As Thomas pointed out%x assumes 32-bit and so is incorrect for intx >> type. As intx is a typedef for intptr_t then INTPTR_FORMAT should be >> usable here as well. >> >> David >> >>> Tested with jtreg runtime to make sure nothing was broken. I tested the >>> new functionality separately. I crashed the vm and examined the >>> debugger >>> output to make sure the hexadecimal thread id printed in the error >>> message matched one of the threads listed by the debugger. >>> >>> Thanks, >>> Max > From mikael.vidstedt at oracle.com Sat Apr 11 00:53:17 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 10 Apr 2015 17:53:17 -0700 Subject: RFR(S): 8077524: Enable selective test bundle installation for jprt test targets Message-ID: <5528707D.2060205@oracle.com> Please review this change to the jprt configuration which makes the dependency on the test bundle configurable per test target. Bug: https://bugs.openjdk.java.net/browse/JDK-8077524 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8077524/webrev.00/webrev/ Motivation: Apart from not actually being used for all tests, installation of the test bundle can take significant time on machines with slow I/O. Making the bundle installation optional means the overhead of setting up for testing is reduced. Description: The change introduces two new properties jprt.selective.test.bundle.installation controls whether or not the this new logic should be used, and the jprt.test.bundle.targets property controls which test targets actually require the test bundle to be installed. Specifically, all the jtreg tests in the hotspot and nativesanity testsets are included in the set of test targets which *do* require the test bundle, but the hotspot_{clienttests,servertests,internalvmtests} are not included. I have *not* added the dependency for any other testsets, because at the time this writing none of the corresponding test targets make use of the test bundle. Cheers, Mikael From david.holmes at oracle.com Sun Apr 12 22:52:39 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Apr 2015 08:52:39 +1000 Subject: RFR(S): 8077524: Enable selective test bundle installation for jprt test targets In-Reply-To: <5528707D.2060205@oracle.com> References: <5528707D.2060205@oracle.com> Message-ID: <552AF737.6090108@oracle.com> Looks good Mikael. Thanks, David On 11/04/2015 10:53 AM, Mikael Vidstedt wrote: > > Please review this change to the jprt configuration which makes the > dependency on the test bundle configurable per test target. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8077524 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8077524/webrev.00/webrev/ > > Motivation: > > Apart from not actually being used for all tests, installation of the > test bundle can take significant time on machines with slow I/O. Making > the bundle installation optional means the overhead of setting up for > testing is reduced. > > Description: > > The change introduces two new properties > jprt.selective.test.bundle.installation controls whether or not the this > new logic should be used, and the jprt.test.bundle.targets property > controls which test targets actually require the test bundle to be > installed. Specifically, all the jtreg tests in the hotspot and > nativesanity testsets are included in the set of test targets which *do* > require the test bundle, but the > hotspot_{clienttests,servertests,internalvmtests} are not included. > > I have *not* added the dependency for any other testsets, because at the > time this writing none of the corresponding test targets make use of the > test bundle. > > Cheers, > Mikael > From stefan.karlsson at oracle.com Mon Apr 13 11:57:27 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 Apr 2015 13:57:27 +0200 Subject: RFR; 8077420: Build failure with SS12u4 Message-ID: <552BAF27.5020800@oracle.com> Hi, Please review this fix for a build failure that was encountered during the Solaris Studio compiler upgrade. Two files were missing an include of stack.inline.hpp, which is needed to get the definition of default_segment_size(). This function is used in the stack.hpp, to provide the default value to the constructor. This forces all users of Stacks with the default segment size, to have to include stack.inline.hpp. The default_segment_size() implementation always evaluates to the same value, given the template parameters, so I chose to setup a constant in the header instead of adding the missing stack.inline.hpp files. http://cr.openjdk.java.net/~stefank/8077420/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8077420 Tested with JPRT, and built with SS12u4. Thanks, StefanK From david.holmes at oracle.com Mon Apr 13 12:25:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Apr 2015 22:25:23 +1000 Subject: RFR; 8077420: Build failure with SS12u4 In-Reply-To: <552BAF27.5020800@oracle.com> References: <552BAF27.5020800@oracle.com> Message-ID: <552BB5B3.7090805@oracle.com> Hi Stefan, On 13/04/2015 9:57 PM, Stefan Karlsson wrote: > Hi, > > Please review this fix for a build failure that was encountered during > the Solaris Studio compiler upgrade. So what was it about the compiler upgrade that exposed this ?? > Two files were missing an include of stack.inline.hpp, which is needed > to get the definition of default_segment_size(). This function is used > in the stack.hpp, to provide the default value to the constructor. This > forces all users of Stacks with the default segment size, to have to > include stack.inline.hpp. The default_segment_size() implementation > always evaluates to the same value, given the template parameters, so I > chose to setup a constant in the header instead of adding the missing > stack.inline.hpp files. > > http://cr.openjdk.java.net/~stefank/8077420/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8077420 This seems okay but I have to say I remain very confused about the "right" way to deal with .hpp and .inline.hpp files in general. Thanks, David > Tested with JPRT, and built with SS12u4. > > Thanks, > StefanK From goetz.lindenmaier at sap.com Mon Apr 13 12:51:15 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Apr 2015 12:51:15 +0000 Subject: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. In-Reply-To: <5519B880.20106@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFB8DBE@DEWDFEMB12A.global.corp.sap> <5519B880.20106@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBE19B@DEWDFEMB12A.global.corp.sap> Hi, sorry for letting this sleep two weeks, I've been off ... Vladimir, thanks for the review. I please need a sponsor. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Montag, 30. M?rz 2015 22:57 To: hotspot-dev at openjdk.java.net Subject: Re: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. Good. Thanks, Vladimir On 3/27/15 12:58 AM, Lindenmaier, Goetz wrote: > Hi, > > on Aix, we don't support large pages. > This needs to be manifested in arguments.cpp. > The change simply reuses a #ifdef BSD for AIX, too. > > Please review this tiny change, and I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8076057-aixULP/webrev.00/ > > Best regards, > Goetz. > From stefan.karlsson at oracle.com Mon Apr 13 12:52:10 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 Apr 2015 14:52:10 +0200 Subject: RFR; 8077420: Build failure with SS12u4 In-Reply-To: <552BB5B3.7090805@oracle.com> References: <552BAF27.5020800@oracle.com> <552BB5B3.7090805@oracle.com> Message-ID: <552BBBFA.6090109@oracle.com> Hi David, On 2015-04-13 14:25, David Holmes wrote: > Hi Stefan, > > On 13/04/2015 9:57 PM, Stefan Karlsson wrote: >> Hi, >> >> Please review this fix for a build failure that was encountered during >> the Solaris Studio compiler upgrade. > > So what was it about the compiler upgrade that exposed this ?? I'm not sure, but somehow the function wasn't made available to the compiler/linker. Maybe there's a combination of the inline keyword and template functions that used to work, but doesn't anymore? I don't have access to a SS12u4 setup, so Erik J had to compile with the patch. > >> Two files were missing an include of stack.inline.hpp, which is needed >> to get the definition of default_segment_size(). This function is used >> in the stack.hpp, to provide the default value to the constructor. This >> forces all users of Stacks with the default segment size, to have to >> include stack.inline.hpp. The default_segment_size() implementation >> always evaluates to the same value, given the template parameters, so I >> chose to setup a constant in the header instead of adding the missing >> stack.inline.hpp files. >> >> http://cr.openjdk.java.net/~stefank/8077420/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8077420 > > This seems okay but I have to say I remain very confused about the > "right" way to deal with .hpp and .inline.hpp files in general. OK. One rule to honor, as far as possible, is to _not_ use functions in inline.hpp files from .hpp files. In this case stack.hpp used a function in stack.inline.hpp. Maybe there's a more authoritative place that describes the "right way", but I think this post is worth reading and describes it well enough: http://www.cplusplus.com/forum/articles/10627/ Thanks, StefanK > > Thanks, > David > >> Tested with JPRT, and built with SS12u4. >> >> Thanks, >> StefanK From lois.foltan at oracle.com Mon Apr 13 13:58:40 2015 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 13 Apr 2015 09:58:40 -0400 Subject: RFR; 8077420: Build failure with SS12u4 In-Reply-To: <552BBBFA.6090109@oracle.com> References: <552BAF27.5020800@oracle.com> <552BB5B3.7090805@oracle.com> <552BBBFA.6090109@oracle.com> Message-ID: <552BCB8F.2090908@oracle.com> On 4/13/2015 8:52 AM, Stefan Karlsson wrote: > Hi David, > > On 2015-04-13 14:25, David Holmes wrote: >> Hi Stefan, >> >> On 13/04/2015 9:57 PM, Stefan Karlsson wrote: >>> Hi, >>> >>> Please review this fix for a build failure that was encountered during >>> the Solaris Studio compiler upgrade. >> >> So what was it about the compiler upgrade that exposed this ?? > > I'm not sure, but somehow the function wasn't made available to the > compiler/linker. Maybe there's a combination of the inline keyword and > template functions that used to work, but doesn't anymore? I don't > have access to a SS12u4 setup, so Erik J had to compile with the patch. Stefan, This change looks good. I believe C++ 5.13 (Solaris Studio 12.4) has made several changes to template definition parsing. There are 3 sections in the new features and functionality documentation of interest. Particularly the section 1.1.2.5 that discusses how the "template definitions separate" compilation model is now more strict. See http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyiq Thanks, Lois > >> >>> Two files were missing an include of stack.inline.hpp, which is needed >>> to get the definition of default_segment_size(). This function is used >>> in the stack.hpp, to provide the default value to the constructor. This >>> forces all users of Stacks with the default segment size, to have to >>> include stack.inline.hpp. The default_segment_size() implementation >>> always evaluates to the same value, given the template parameters, so I >>> chose to setup a constant in the header instead of adding the missing >>> stack.inline.hpp files. >>> >>> http://cr.openjdk.java.net/~stefank/8077420/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8077420 >> >> This seems okay but I have to say I remain very confused about the >> "right" way to deal with .hpp and .inline.hpp files in general. > > OK. One rule to honor, as far as possible, is to _not_ use functions > in inline.hpp files from .hpp files. In this case stack.hpp used a > function in stack.inline.hpp. > > Maybe there's a more authoritative place that describes the "right > way", but I think this post is worth reading and describes it well > enough: > http://www.cplusplus.com/forum/articles/10627/ > > Thanks, > StefanK > >> >> Thanks, >> David >> >>> Tested with JPRT, and built with SS12u4. >>> >>> Thanks, >>> StefanK > From stefan.karlsson at oracle.com Mon Apr 13 14:01:18 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 Apr 2015 16:01:18 +0200 Subject: RFR; 8077420: Build failure with SS12u4 In-Reply-To: <552BCB8F.2090908@oracle.com> References: <552BAF27.5020800@oracle.com> <552BB5B3.7090805@oracle.com> <552BBBFA.6090109@oracle.com> <552BCB8F.2090908@oracle.com> Message-ID: <552BCC2E.9000604@oracle.com> Hi Lois, On 2015-04-13 15:58, Lois Foltan wrote: > > On 4/13/2015 8:52 AM, Stefan Karlsson wrote: >> Hi David, >> >> On 2015-04-13 14:25, David Holmes wrote: >>> Hi Stefan, >>> >>> On 13/04/2015 9:57 PM, Stefan Karlsson wrote: >>>> Hi, >>>> >>>> Please review this fix for a build failure that was encountered during >>>> the Solaris Studio compiler upgrade. >>> >>> So what was it about the compiler upgrade that exposed this ?? >> >> I'm not sure, but somehow the function wasn't made available to the >> compiler/linker. Maybe there's a combination of the inline keyword >> and template functions that used to work, but doesn't anymore? I >> don't have access to a SS12u4 setup, so Erik J had to compile with >> the patch. > > Stefan, > > This change looks good. I believe C++ 5.13 (Solaris Studio 12.4) has > made several changes to template definition parsing. There are 3 > sections in the new features and functionality documentation of > interest. Particularly the section 1.1.2.5 that discusses how the > "template definitions separate" compilation model is now more strict. > See http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyiq Thanks for the review and the link! StefanK > > Thanks, > Lois > >> >>> >>>> Two files were missing an include of stack.inline.hpp, which is needed >>>> to get the definition of default_segment_size(). This function is used >>>> in the stack.hpp, to provide the default value to the constructor. >>>> This >>>> forces all users of Stacks with the default segment size, to have to >>>> include stack.inline.hpp. The default_segment_size() implementation >>>> always evaluates to the same value, given the template parameters, >>>> so I >>>> chose to setup a constant in the header instead of adding the missing >>>> stack.inline.hpp files. >>>> >>>> http://cr.openjdk.java.net/~stefank/8077420/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8077420 >>> >>> This seems okay but I have to say I remain very confused about the >>> "right" way to deal with .hpp and .inline.hpp files in general. >> >> OK. One rule to honor, as far as possible, is to _not_ use functions >> in inline.hpp files from .hpp files. In this case stack.hpp used a >> function in stack.inline.hpp. >> >> Maybe there's a more authoritative place that describes the "right >> way", but I think this post is worth reading and describes it well >> enough: >> http://www.cplusplus.com/forum/articles/10627/ >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> David >>> >>>> Tested with JPRT, and built with SS12u4. >>>> >>>> Thanks, >>>> StefanK >> > From christian.tornqvist at oracle.com Mon Apr 13 14:22:59 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 13 Apr 2015 10:22:59 -0400 Subject: RFR(S): 8077608 - [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode Message-ID: <14e901d075f5$58896120$099c2360$@oracle.com> Hi everyone, Please review this small change which enables us to run the Hotspot jtreg tests in agentvm mode. This change also sets JPRT to use this mode. Results when running on my 32-thread Windows machine using a fastdebug build: Othervm (this is what we run today): 4h5m Agentvm (still without concurrency): 1h45m The same speedup can be seen in JPRT across all platforms, I've tested these changes 25-30 times in JPRT. In order to make all the tests work correctly I had to make some small changes: test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java Turns out that the CLASSPATH environment variable has a different value when running with agentvm, it's now appending test.src and test.class.path when creating child processes. This fixed about 40 of the failures. test/sanity/WhiteBox.java Fails to clean out the sun.hotspot.WhiteBox.class on Windows machines, the only reason for cleaning this file out is so that the other tests in /test/sanity doesn't pick up the incorrect WhiteBox.class. Simple workaround is to move the test/sanity/WhiteBox.java into its own directory to prevent the other tests from picking up this class file. test/compiler/uncommontrap/TestUnstableIfTrap.java Intermittent IO problems on Windows when reading the XML files, workaround is to run this to keep running this test in othervm mode. test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java ClassNotFoundException when running in agentvm mode, didn't spend too much time debugging this. Workaround is to keep running this test in othervm mode. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8077608/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8077608 Thanks, Christian From staffan.larsen at oracle.com Mon Apr 13 15:13:16 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Apr 2015 17:13:16 +0200 Subject: RFR(S): 8077608 - [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode In-Reply-To: <14e901d075f5$58896120$099c2360$@oracle.com> References: <14e901d075f5$58896120$099c2360$@oracle.com> Message-ID: <40AC4AD3-94C8-4FA2-8BE1-77F805B5F228@oracle.com> Thanks for doing this work. One comment below. > On 13 apr 2015, at 16:22, Christian Tornqvist wrote: > > Hi everyone, > > > > Please review this small change which enables us to run the Hotspot jtreg > tests in agentvm mode. This change also sets JPRT to use this mode. Results > when running on my 32-thread Windows machine using a fastdebug build: > > > > Othervm (this is what we run today): 4h5m > > Agentvm (still without concurrency): 1h45m > > > > The same speedup can be seen in JPRT across all platforms, I've tested these > changes 25-30 times in JPRT. > > > > In order to make all the tests work correctly I had to make some small > changes: > > > > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java > > Turns out that the CLASSPATH environment variable has a different value when > running with agentvm, it's now appending test.src and test.class.path when > creating child processes. This fixed about 40 of the failures. This looks strange to me. Should we instead add ?-cp {test.class.path}:{test.src}?? /Staffan > > > > test/sanity/WhiteBox.java > > Fails to clean out the sun.hotspot.WhiteBox.class on Windows machines, the > only reason for cleaning this file out is so that the other tests in > /test/sanity doesn't pick up the incorrect WhiteBox.class. Simple workaround > is to move the test/sanity/WhiteBox.java into its own directory to prevent > the other tests from picking up this class file. > > > > test/compiler/uncommontrap/TestUnstableIfTrap.java > > Intermittent IO problems on Windows when reading the XML files, workaround > is to run this to keep running this test in othervm mode. > > > > test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java > > ClassNotFoundException when running in agentvm mode, didn't spend too much > time debugging this. Workaround is to keep running this test in othervm > mode. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8077608/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8077608 > > > > Thanks, > > Christian > > > > > From goetz.lindenmaier at sap.com Mon Apr 13 15:57:39 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Apr 2015 15:57:39 +0000 Subject: RFR(S): 8077618: Move rtmLocking.cpp to shared directory. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBE374@DEWDFEMB12A.global.corp.sap> Hi, we implemented support for Transactional Memory on ppc. For this, we need the file rtmLocking.cpp from subdirectory x86 as is. Therefore I would like to move the file to share/vm/runtime, where the corresponding header is placed. I added a guard around the code in this file. Also, I moved #ifdef x86 from globalDefinitions.hpp to globalDefinitions_x86.hpp which simplifies enabling RTM on PPC. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8077618-mvRTM/webrev.01/ Best regards, Goetz. From vladimir.x.ivanov at oracle.com Mon Apr 13 17:39:44 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 13 Apr 2015 20:39:44 +0300 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <38AF71DB-944B-42B8-A955-C5173881BE63@oracle.com> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> <552691DA.7000604@oracle.com> <55270862.9020704@oracle.com> <38AF71DB-944B-42B8-A955-C5173881BE63@oracle.com> Message-ID: <552BFF60.40803@oracle.com> John, David, thanks for the feedback! What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/hotspot Best regards, Vladimir Ivanov On 4/10/15 10:15 PM, John Rose wrote: > On Apr 9, 2015, at 4:16 PM, David Holmes > wrote: >> >> Hi Vladimir, >> >> On 10/04/2015 12:51 AM, Vladimir Ivanov wrote: >>> David, thanks for the feedback! >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/jdk >>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/hotspot >>> >>> I restored original logic and call into VM only if it fails. >> >> This change seems fine to me, but I think John may prefer to see >> getSimpleName implemented such that it always returns the name from >> the innerclass attribute. (Though perhaps with caching if performance >> is a concern?) > > Yes, I do prefer the new logic instead of a combination of old and new. > > Two concerns: Somebody somewhere might be relying on a bug in the old > logic and be frustrated by seeing that bug fixed. This is a fine line > to walk, but in this case I think the behavior change (if any) will show > up in places where we already have outages. Perhaps someone is > post-processing the result of getSimpleName to correct it. If so they > may no longer need to do that. > > Second, the new logic may itself have issues. A typical problem with > the InnerClasses attribute is it is broken or stripped, or a related > nestmate is missing. (See parallel thread in core-libs-dev on 8076264.) > But the proposed change takes effect after a call to > Class.getEnclosingClass, which uses > InstanceKlass::compute_enclosing_class_impl and accesses the same > InnerClasses record. > > This leads me to a comment: The common code (two uses > of InnerClassesIterator with klass_name_at_matches) should be factored > out. The factored subroutine should search out the self-record in the > InnerClasses attribute. The logic is tricky enough that I'm > uncomfortable with it being duplicated. Key issue: We don't want to > load any classes doing this lookup. > > (For bonus points, factor the third use in that file, the one that looks > not for self but for children-of-self. Add a boolean flag that varies > the test.) > > Bottom line: The new logic should replace the old. >> >>>>> The logic to compute simple name (Class.getSimpleName()) for >>>>> inner/nested/local classes is tightly coupled with Java naming scheme >>>>> and sometimes fails for classes generated from non-Java code. >>>> >>>> Meta-question: if this is non-Java code then what does/should >>>> "simpleName" even mean? "Returns the simple name of the underlying class >>>> as given in the source code." If there is no (java) source code does >>>> this have any meaning? Should it return "" ? >>> My reading of the JVMS is that InnerClasses attribute can be freely used >>> by non-Java compilers to store simple names for classes they generate. >>> The current wording for inner_name_index doesn't mention Java language. >> >> True, but it does refer to source code: "represents the original >> simple name of C, as given in the source code from which this class >> file was compiled. " which seems misplaced as we're discussing classes >> for which there is no source code as such. > > It could be non-Java source code. In any case, the indicated component > of the "binary name" of the class is well-defined, whether or not it > occurs in source code. Note also that classes might be generated by ASM > (no source code per se) but we still have a reasonable expectation of > reflecting on them, even though reflection is (mostly) defined in terms > of source code constructs. > >> Anyway it just flags to me that perhaps these Class methods need to be >> generalized a bit given the support for non-Java languages on the JVM. >> But that's for core-libs folk to decide. > > Yes, I think that's the issue. The multi-language folks (like me) would > be disappointed to hear that we decided that non-Java languages don't > have any needs here; they do. > > Thanks, > ? John > >> Thanks, >> David >> >>> Best regards, >>> Vladimir Ivanov >>> >>>>> Instead of parsing class name and try to extract simple name based on >>>>> JLS rules, the fix I propose is to use InnerClasses attribute from the >>>>> class file. Simple name is already recorded there. >>>> > >>>>> JVMS-4.7.6: The InnerClasses Attribute >>>>> "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the >>>>> inner_name_index item must be zero. Otherwise, the value of the >>>>> inner_name_index item must be a valid index into the constant_pool >>>>> table, and the entry at that index must be a CONSTANT_Utf8_info >>>>> structure (?4.4.7) that represents the original simple name of C, as >>>>> given in the source code from which this class file was compiled." >>>>> >>>>> Since I consider backporting the fix into 8u60, I'd like to hear >>>>> opinions about backward compatibility of such change. >>>>> >>>>> As an alternative solution, I can restore original logic and consult >>>>> InnerClasses attribute when class name parsing logic fails. >>>> >>>> I think I'd prefer to see the VM call only used as a fallback if the >>>> regular parsing fails. That would prevent any compatibility issues for >>>> the 8u backport (ignoring tests that deliberately generate invalidly >>>> named classes). >>>> >>>> Thanks, >>>> David >>>> >>>>> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov > From aph at redhat.com Mon Apr 13 18:00:54 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Apr 2015 19:00:54 +0100 Subject: RFR: 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method Message-ID: <552C0456.1040602@redhat.com> Follows x86, but changed to a more idiomatic AArch64 style for efficiency. I strengthened the regression test. As fasr as I can see it doesn't robustly check a corner case for carry propagation (i.e. when there is a double carry.) This is very easy to get wrong, so I added it. http://cr.openjdk.java.net/~aph/8077615/ Andrew. From aph at redhat.com Mon Apr 13 18:02:08 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Apr 2015 19:02:08 +0100 Subject: RFR: 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method In-Reply-To: <552C0456.1040602@redhat.com> References: <552C0456.1040602@redhat.com> Message-ID: <552C04A0.3060906@redhat.com> While we're looking at this: there was a patch submitted for x86 squareToLen. Is anyone looking at it? Thanks, Andrew. From vladimir.kozlov at oracle.com Mon Apr 13 18:32:06 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Apr 2015 11:32:06 -0700 Subject: RFR: 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method In-Reply-To: <552C04A0.3060906@redhat.com> References: <552C0456.1040602@redhat.com> <552C04A0.3060906@redhat.com> Message-ID: <552C0BA6.2050609@oracle.com> Hi Andrew, What was Subject of that email (with patch for squareToLen)? Thanks, Vladimir On 4/13/15 11:02 AM, Andrew Haley wrote: > While we're looking at this: there was a patch submitted for x86 > squareToLen. Is anyone looking at it? > > Thanks, > Andrew. > From george.triantafillou at oracle.com Mon Apr 13 19:00:11 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Mon, 13 Apr 2015 15:00:11 -0400 Subject: RFR(S): 8077608 - [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode In-Reply-To: <14e901d075f5$58896120$099c2360$@oracle.com> References: <14e901d075f5$58896120$099c2360$@oracle.com> Message-ID: <552C123B.1040907@oracle.com> Christian, This looks good. Thanks for fixing this. -George On 4/13/2015 10:22 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change which enables us to run the Hotspot jtreg > tests in agentvm mode. This change also sets JPRT to use this mode. Results > when running on my 32-thread Windows machine using a fastdebug build: > > > > Othervm (this is what we run today): 4h5m > > Agentvm (still without concurrency): 1h45m > > > > The same speedup can be seen in JPRT across all platforms, I've tested these > changes 25-30 times in JPRT. > > > > In order to make all the tests work correctly I had to make some small > changes: > > > > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java > > Turns out that the CLASSPATH environment variable has a different value when > running with agentvm, it's now appending test.src and test.class.path when > creating child processes. This fixed about 40 of the failures. > > > > test/sanity/WhiteBox.java > > Fails to clean out the sun.hotspot.WhiteBox.class on Windows machines, the > only reason for cleaning this file out is so that the other tests in > /test/sanity doesn't pick up the incorrect WhiteBox.class. Simple workaround > is to move the test/sanity/WhiteBox.java into its own directory to prevent > the other tests from picking up this class file. > > > > test/compiler/uncommontrap/TestUnstableIfTrap.java > > Intermittent IO problems on Windows when reading the XML files, workaround > is to run this to keep running this test in othervm mode. > > > > test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java > > ClassNotFoundException when running in agentvm mode, didn't spend too much > time debugging this. Workaround is to keep running this test in othervm > mode. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8077608/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8077608 > > > > Thanks, > > Christian > > > > > From john.r.rose at oracle.com Mon Apr 13 19:12:06 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 13 Apr 2015 12:12:06 -0700 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <552BFF60.40803@oracle.com> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> <552691DA.7000604@oracle.com> <55270862.9020704@oracle.com> <38AF71DB-944B-42B8-A955-C5173881BE63@oracle.com> <552BFF60.40803@oracle.com> Message-ID: <2888111C-0A1B-4C27-81D4-2E377AE9E63E@oracle.com> It's good. Nice cleanup. ? John On Apr 13, 2015, at 10:39 AM, Vladimir Ivanov wrote: > > John, David, thanks for the feedback! > > What do you think about the following version: > http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk > http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/hotspot > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Mon Apr 13 19:12:36 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Apr 2015 12:12:36 -0700 Subject: RFR: 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method In-Reply-To: <552C0456.1040602@redhat.com> References: <552C0456.1040602@redhat.com> Message-ID: <552C1524.4010701@oracle.com> In the test you removed next line from previous test. Can you restore them?: System.out.println(b1); System.out.println(b2); I have a little problem of mapping code from comments to assembler for multiply_64_x_64_loop(). Extend comments. I think in next comments x_xstart should be used on left side instead of 'product': + umulh(rscratch1, x_xstart, y_idx); // product * y_idx -> rscratch1:product + mul(product, x_xstart, y_idx); + adds(product, product, carry); + adc(carry, rscratch1, zr); // product * y_idx + carry -> carry:product Also why not use BytesPerLong instead of BytesPerWord?: + str(product, offsetted_address(z, kdx, Address::uxtw(LogBytesPerInt), 0, BytesPerWord)); Thanks, Vladimir On 4/13/15 11:00 AM, Andrew Haley wrote: > Follows x86, but changed to a more idiomatic AArch64 style for > efficiency. > > I strengthened the regression test. As far as I can see it doesn't > robustly check a corner case for carry propagation (i.e. when there is > a double carry.) This is very easy to get wrong, so I added it. > > http://cr.openjdk.java.net/~aph/8077615/ > > Andrew. > From vladimir.kozlov at oracle.com Mon Apr 13 19:37:06 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Apr 2015 12:37:06 -0700 Subject: RFR(S): 8077618: Move rtmLocking.cpp to shared directory. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBE374@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBE374@DEWDFEMB12A.global.corp.sap> Message-ID: <552C1AE2.1080007@oracle.com> Looks good to me. Thanks, Vladimir On 4/13/15 8:57 AM, Lindenmaier, Goetz wrote: > Hi, > > we implemented support for Transactional Memory on ppc. For this, we need > the file rtmLocking.cpp from subdirectory x86 as is. > > Therefore I would like to move the file to share/vm/runtime, where the > corresponding header is placed. I added a guard around the code in this file. > > Also, I moved #ifdef x86 from globalDefinitions.hpp to globalDefinitions_x86.hpp > which simplifies enabling RTM on PPC. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8077618-mvRTM/webrev.01/ > > Best regards, > Goetz. > > > > From vladimir.kozlov at oracle.com Mon Apr 13 20:09:07 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Apr 2015 13:09:07 -0700 Subject: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBE19B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFB8DBE@DEWDFEMB12A.global.corp.sap> <5519B880.20106@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBE19B@DEWDFEMB12A.global.corp.sap> Message-ID: <552C2263.10903@oracle.com> In JPRT queue. Vladimir On 4/13/15 5:51 AM, Lindenmaier, Goetz wrote: > Hi, > > sorry for letting this sleep two weeks, I've been off ... > > Vladimir, thanks for the review. > > I please need a sponsor. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Montag, 30. M?rz 2015 22:57 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. > > Good. > > Thanks, > Vladimir > > On 3/27/15 12:58 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> on Aix, we don't support large pages. >> This needs to be manifested in arguments.cpp. >> The change simply reuses a #ifdef BSD for AIX, too. >> >> Please review this tiny change, and I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8076057-aixULP/webrev.00/ >> >> Best regards, >> Goetz. >> From max.ockner at oracle.com Mon Apr 13 20:25:14 2015 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 13 Apr 2015 16:25:14 -0400 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <55272BDA.2060908@oracle.com> References: <551D9AC6.50208@oracle.com> <55232E90.7060701@oracle.com> <5526CEDF.20004@oracle.com> <55272BDA.2060908@oracle.com> Message-ID: <552C262A.1070002@oracle.com> Hello, Modified this again. I defined TID_FORMAT to make it a better semantic match. Webrev: http://cr.openjdk.java.net/~mockner/8029630.8/ Tested with jprt Thanks, Max On 4/9/2015 9:48 PM, David Holmes wrote: > Hi Max, > > On 10/04/2015 5:11 AM, Max Ockner wrote: >> Hi again, >> After working past some build issues, I have a new webrev. I've changed >> %x to PTR_FORMAT, and I've removed the modification to thread.cpp >> >> New webrev: http://cr.openjdk.java.net/~mockner/8029630.4/ > > I think INTPTR_FORMAT would be more of a semantic match as the thread > id is not a pointer type. > > David > >> Thanks, >> Max >> >> On 4/6/2015 9:10 PM, David Holmes wrote: >>> Hi Max, >>> >>> On 3/04/2015 5:38 AM, Max Ockner wrote: >>>> Hello, >>>> Please review this change: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >>>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >>>> Summary: Existing error messages for vm crashes print the decimal >>>> representation of the current thread id. The message format has been >>>> changed to print the hex value of the thread id. >>> >>> src/share/vm/runtime/thread.cpp >>> >>> The change is incorrect and unnecessary. 'this' is a pointer type so >>> INTPTR_FORMAT seems correct (though it may need p2i(this)?) while %x >>> assumes 'this' is always 32-bit. Further INTPTR_FORMAT is already hex >>> not decimal. >>> >>> src/share/vm/utilities/vmError.cpp >>> >>> As Thomas pointed out%x assumes 32-bit and so is incorrect for intx >>> type. As intx is a typedef for intptr_t then INTPTR_FORMAT should be >>> usable here as well. >>> >>> David >>> >>>> Tested with jtreg runtime to make sure nothing was broken. I tested >>>> the >>>> new functionality separately. I crashed the vm and examined the >>>> debugger >>>> output to make sure the hexadecimal thread id printed in the error >>>> message matched one of the threads listed by the debugger. >>>> >>>> Thanks, >>>> Max >> From david.holmes at oracle.com Mon Apr 13 22:56:56 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Apr 2015 08:56:56 +1000 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <552C262A.1070002@oracle.com> References: <551D9AC6.50208@oracle.com> <55232E90.7060701@oracle.com> <5526CEDF.20004@oracle.com> <55272BDA.2060908@oracle.com> <552C262A.1070002@oracle.com> Message-ID: <552C49B8.9070805@oracle.com> Hi Max, On 14/04/2015 6:25 AM, Max Ockner wrote: > Hello, > > Modified this again. I defined TID_FORMAT to make it a better semantic > match. Not sure that actually improves anything. There is no "tid" type. Primarily what we have is a function returning intx and we want to print it as hex. I still think INTPTR_FORMAT suffices. Otherwise INTX_HEX_FORMAT is you really want to introduce something new - but I don't suggest doing that. > Webrev: http://cr.openjdk.java.net/~mockner/8029630.8/ I still see vmError.cpp using PTR_FORMAT ?? Sorry. David > Tested with jprt > > Thanks, > Max > > On 4/9/2015 9:48 PM, David Holmes wrote: >> Hi Max, >> >> On 10/04/2015 5:11 AM, Max Ockner wrote: >>> Hi again, >>> After working past some build issues, I have a new webrev. I've changed >>> %x to PTR_FORMAT, and I've removed the modification to thread.cpp >>> >>> New webrev: http://cr.openjdk.java.net/~mockner/8029630.4/ >> >> I think INTPTR_FORMAT would be more of a semantic match as the thread >> id is not a pointer type. >> >> David >> >>> Thanks, >>> Max >>> >>> On 4/6/2015 9:10 PM, David Holmes wrote: >>>> Hi Max, >>>> >>>> On 3/04/2015 5:38 AM, Max Ockner wrote: >>>>> Hello, >>>>> Please review this change: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >>>>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >>>>> Summary: Existing error messages for vm crashes print the decimal >>>>> representation of the current thread id. The message format has been >>>>> changed to print the hex value of the thread id. >>>> >>>> src/share/vm/runtime/thread.cpp >>>> >>>> The change is incorrect and unnecessary. 'this' is a pointer type so >>>> INTPTR_FORMAT seems correct (though it may need p2i(this)?) while %x >>>> assumes 'this' is always 32-bit. Further INTPTR_FORMAT is already hex >>>> not decimal. >>>> >>>> src/share/vm/utilities/vmError.cpp >>>> >>>> As Thomas pointed out%x assumes 32-bit and so is incorrect for intx >>>> type. As intx is a typedef for intptr_t then INTPTR_FORMAT should be >>>> usable here as well. >>>> >>>> David >>>> >>>>> Tested with jtreg runtime to make sure nothing was broken. I tested >>>>> the >>>>> new functionality separately. I crashed the vm and examined the >>>>> debugger >>>>> output to make sure the hexadecimal thread id printed in the error >>>>> message matched one of the threads listed by the debugger. >>>>> >>>>> Thanks, >>>>> Max >>> > From david.holmes at oracle.com Tue Apr 14 00:47:03 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Apr 2015 10:47:03 +1000 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <552BFF60.40803@oracle.com> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> <552691DA.7000604@oracle.com> <55270862.9020704@oracle.com> <38AF71DB-944B-42B8-A955-C5173881BE63@oracle.com> <552BFF60.40803@oracle.com> Message-ID: <552C6387.20908@oracle.com> On 14/04/2015 3:39 AM, Vladimir Ivanov wrote: > John, David, thanks for the feedback! > > What do you think about the following version: > http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk > http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/hotspot Looks good - thanks. David > Best regards, > Vladimir Ivanov > > On 4/10/15 10:15 PM, John Rose wrote: >> On Apr 9, 2015, at 4:16 PM, David Holmes > > wrote: >>> >>> Hi Vladimir, >>> >>> On 10/04/2015 12:51 AM, Vladimir Ivanov wrote: >>>> David, thanks for the feedback! >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/jdk >>>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/hotspot >>>> >>>> I restored original logic and call into VM only if it fails. >>> >>> This change seems fine to me, but I think John may prefer to see >>> getSimpleName implemented such that it always returns the name from >>> the innerclass attribute. (Though perhaps with caching if performance >>> is a concern?) >> >> Yes, I do prefer the new logic instead of a combination of old and new. >> >> Two concerns: Somebody somewhere might be relying on a bug in the old >> logic and be frustrated by seeing that bug fixed. This is a fine line >> to walk, but in this case I think the behavior change (if any) will show >> up in places where we already have outages. Perhaps someone is >> post-processing the result of getSimpleName to correct it. If so they >> may no longer need to do that. >> >> Second, the new logic may itself have issues. A typical problem with >> the InnerClasses attribute is it is broken or stripped, or a related >> nestmate is missing. (See parallel thread in core-libs-dev on 8076264.) >> But the proposed change takes effect after a call to >> Class.getEnclosingClass, which uses >> InstanceKlass::compute_enclosing_class_impl and accesses the same >> InnerClasses record. >> >> This leads me to a comment: The common code (two uses >> of InnerClassesIterator with klass_name_at_matches) should be factored >> out. The factored subroutine should search out the self-record in the >> InnerClasses attribute. The logic is tricky enough that I'm >> uncomfortable with it being duplicated. Key issue: We don't want to >> load any classes doing this lookup. >> >> (For bonus points, factor the third use in that file, the one that looks >> not for self but for children-of-self. Add a boolean flag that varies >> the test.) >> >> Bottom line: The new logic should replace the old. >>> >>>>>> The logic to compute simple name (Class.getSimpleName()) for >>>>>> inner/nested/local classes is tightly coupled with Java naming scheme >>>>>> and sometimes fails for classes generated from non-Java code. >>>>> >>>>> Meta-question: if this is non-Java code then what does/should >>>>> "simpleName" even mean? "Returns the simple name of the underlying >>>>> class >>>>> as given in the source code." If there is no (java) source code does >>>>> this have any meaning? Should it return "" ? >>>> My reading of the JVMS is that InnerClasses attribute can be freely >>>> used >>>> by non-Java compilers to store simple names for classes they generate. >>>> The current wording for inner_name_index doesn't mention Java language. >>> >>> True, but it does refer to source code: "represents the original >>> simple name of C, as given in the source code from which this class >>> file was compiled. " which seems misplaced as we're discussing classes >>> for which there is no source code as such. >> >> It could be non-Java source code. In any case, the indicated component >> of the "binary name" of the class is well-defined, whether or not it >> occurs in source code. Note also that classes might be generated by ASM >> (no source code per se) but we still have a reasonable expectation of >> reflecting on them, even though reflection is (mostly) defined in terms >> of source code constructs. >> >>> Anyway it just flags to me that perhaps these Class methods need to be >>> generalized a bit given the support for non-Java languages on the JVM. >>> But that's for core-libs folk to decide. >> >> Yes, I think that's the issue. The multi-language folks (like me) would >> be disappointed to hear that we decided that non-Java languages don't >> have any needs here; they do. >> >> Thanks, >> ? John >> >>> Thanks, >>> David >>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>>> Instead of parsing class name and try to extract simple name based on >>>>>> JLS rules, the fix I propose is to use InnerClasses attribute from >>>>>> the >>>>>> class file. Simple name is already recorded there. >>>>> > >>>>>> JVMS-4.7.6: The InnerClasses Attribute >>>>>> "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the >>>>>> inner_name_index item must be zero. Otherwise, the value of the >>>>>> inner_name_index item must be a valid index into the constant_pool >>>>>> table, and the entry at that index must be a CONSTANT_Utf8_info >>>>>> structure (?4.4.7) that represents the original simple name of C, as >>>>>> given in the source code from which this class file was compiled." >>>>>> >>>>>> Since I consider backporting the fix into 8u60, I'd like to hear >>>>>> opinions about backward compatibility of such change. >>>>>> >>>>>> As an alternative solution, I can restore original logic and consult >>>>>> InnerClasses attribute when class name parsing logic fails. >>>>> >>>>> I think I'd prefer to see the VM call only used as a fallback if the >>>>> regular parsing fails. That would prevent any compatibility issues for >>>>> the 8u backport (ignoring tests that deliberately generate invalidly >>>>> named classes). >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >> From david.holmes at oracle.com Tue Apr 14 01:36:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Apr 2015 11:36:30 +1000 Subject: RFR(S): 8077618: Move rtmLocking.cpp to shared directory. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBE374@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBE374@DEWDFEMB12A.global.corp.sap> Message-ID: <552C6F1E.3060102@oracle.com> Hi Goetz, On 14/04/2015 1:57 AM, Lindenmaier, Goetz wrote: > Hi, > > we implemented support for Transactional Memory on ppc. For this, we need > the file rtmLocking.cpp from subdirectory x86 as is. > Therefore I would like to move the file to share/vm/runtime, where the > corresponding header is placed. I added a guard around the code in this file. Not sure if we need the guard in the cpp file - I guess it speeds up compilation a tiny amount :) If we do want it then the copyright date needs updating to "2014, 2015,". > Also, I moved #ifdef x86 from globalDefinitions.hpp to globalDefinitions_x86.hpp > which simplifies enabling RTM on PPC. Copyright date in src/cpu/x86/vm/globalDefinitions_x86.hpp needs updating. > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8077618-mvRTM/webrev.01/ Otherwise looks okay. David > Best regards, > Goetz. > > > > From david.holmes at oracle.com Tue Apr 14 02:04:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Apr 2015 12:04:42 +1000 Subject: RFR; 8077420: Build failure with SS12u4 In-Reply-To: <552BBBFA.6090109@oracle.com> References: <552BAF27.5020800@oracle.com> <552BB5B3.7090805@oracle.com> <552BBBFA.6090109@oracle.com> Message-ID: <552C75BA.8090307@oracle.com> Hi Stefan, On 13/04/2015 10:52 PM, Stefan Karlsson wrote: > Hi David, > > On 2015-04-13 14:25, David Holmes wrote: >> Hi Stefan, >> >> On 13/04/2015 9:57 PM, Stefan Karlsson wrote: >>> Hi, >>> >>> Please review this fix for a build failure that was encountered during >>> the Solaris Studio compiler upgrade. >> >> So what was it about the compiler upgrade that exposed this ?? > > I'm not sure, but somehow the function wasn't made available to the > compiler/linker. Maybe there's a combination of the inline keyword and > template functions that used to work, but doesn't anymore? I don't have > access to a SS12u4 setup, so Erik J had to compile with the patch. Ok. I'm seeing some other weird stuff coming out in relation to SS12u4. :) >> >>> Two files were missing an include of stack.inline.hpp, which is needed >>> to get the definition of default_segment_size(). This function is used >>> in the stack.hpp, to provide the default value to the constructor. This >>> forces all users of Stacks with the default segment size, to have to >>> include stack.inline.hpp. The default_segment_size() implementation >>> always evaluates to the same value, given the template parameters, so I >>> chose to setup a constant in the header instead of adding the missing >>> stack.inline.hpp files. >>> >>> http://cr.openjdk.java.net/~stefank/8077420/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8077420 >> >> This seems okay but I have to say I remain very confused about the >> "right" way to deal with .hpp and .inline.hpp files in general. > > OK. One rule to honor, as far as possible, is to _not_ use functions in > inline.hpp files from .hpp files. In this case stack.hpp used a function > in stack.inline.hpp. That seems reasonable given that if you have a .inline.hpp I would expect that all defined functions should be in there. Having some functions in the .hpp and some in the .inline.hpp seems a recipe for total confusion. :) > Maybe there's a more authoritative place that describes the "right way", > but I think this post is worth reading and describes it well enough: > http://www.cplusplus.com/forum/articles/10627/ It doesn't really address the .inline.hpp, as it never states when/where to include the .inline.hpp file - there is even some discussion in the comments about the problems relating to wanting functions inlined if not in the included header, but no resolution. He also says that including the .hpp in the .inline.hpp is harmless but unnecessary - which suggest he expected client code to include both of them (whereas I think what has been advocated in hotspot lately is for client code to include the .inline.hpp and for the the .inline.hpp to include the .hpp). I did like the simple rules regarding forward declarations versus include dependencies. My C++ introduction was in an environment where forward declarations were seen as a hack to deal with circular dependencies, rather than being a first class mechanism for introducing type names. Cheers, David > Thanks, > StefanK > >> >> Thanks, >> David >> >>> Tested with JPRT, and built with SS12u4. >>> >>> Thanks, >>> StefanK > From vladimir.kozlov at oracle.com Tue Apr 14 02:09:28 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Apr 2015 19:09:28 -0700 Subject: RFR(S): 8077618: Move rtmLocking.cpp to shared directory. In-Reply-To: <552C6F1E.3060102@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBE374@DEWDFEMB12A.global.corp.sap> <552C6F1E.3060102@oracle.com> Message-ID: <552C76D8.8090009@oracle.com> I updated copyright dates as David said and I submitted it to JPRT to push since we have 2 reviews. Thanks, Vladimir On 4/13/15 6:36 PM, David Holmes wrote: > Hi Goetz, > > On 14/04/2015 1:57 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> we implemented support for Transactional Memory on ppc. For this, we >> need >> the file rtmLocking.cpp from subdirectory x86 as is. >> Therefore I would like to move the file to share/vm/runtime, where the >> corresponding header is placed. I added a guard around the code in >> this file. > > Not sure if we need the guard in the cpp file - I guess it speeds up > compilation a tiny amount :) If we do want it then the copyright date > needs updating to "2014, 2015,". > >> Also, I moved #ifdef x86 from globalDefinitions.hpp to >> globalDefinitions_x86.hpp >> which simplifies enabling RTM on PPC. > > Copyright date in src/cpu/x86/vm/globalDefinitions_x86.hpp needs updating. > >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8077618-mvRTM/webrev.01/ > > Otherwise looks okay. > > David > >> Best regards, >> Goetz. >> >> >> >> From david.holmes at oracle.com Tue Apr 14 05:56:18 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Apr 2015 15:56:18 +1000 Subject: Replacing syscall(_NR_fork) on linux with syscall(_NR_clone) In-Reply-To: References: <55278002.8040705@oracle.com> Message-ID: <552CAC02.2010909@oracle.com> Hi Thomas, On 10/04/2015 8:36 PM, Thomas St?fe wrote: > Hi David, > > it is difficult to understand Linux implementation of > os::fork_and_exec() fully. Comment claims fork() would not be async safe > for use in signal handler, but I do not see why (maybe I am being slow > here): pthread_atfork() handlers get called in the context of the thread > calling the fork(). Depending on the pthread_atfork handlers, this may > make the code non-reentrant, but async-unsafe? As the comment says: // fork() in LinuxThreads/NPTL is not async-safe. but I suspect this is an extremely old comment and no longer applicable to NPTL. So I think you and Martin are right that there's no reason not to call fork() and execve() using the glibc calls rather than the direct syscalls. > Also the comment above the execve syscall is a bit of a riddle. > "execve() will instead kill every thread in the parent process.". I > would love to understand why. Again as stated in the comments this was a "feature" of the LinuxThreads implementation. I don't know the details - before my time :) > But if pthread_atfork handlers are the problem, how about just > deactivating pthread_atfork handlers for the duration of > os::fork_and_exec? Note that the jdk itself does not install > pthread_atfork handlers, so this only affects user handlers. I don't think at_fork handlers are specifically an issue - this is not trying to solve every problem in every circumstance. > Another alternative to using raw syscalls would be to use posix_spawn(), > which I believe does not call pthread_atfork handlers. "It is implementation-defined whether the fork handlers are run when posix_spawn() or posix_spawnp() is called." - POSIX Of course Linux may have made a determination one way or another. But given Martin's experience with using fork() and execve() at Google, I would propose just adopting that approach. Aside: it was also suggested that we simply drop this "onError" mechanism and replace it with one that simply halts the VM process and thereby allow the user to run arbitrary external commands. That may be worth an RFE in itself, but I need something in the short term. Thanks, David > Regards, Thomas > > > On Fri, Apr 10, 2015 at 9:47 AM, David Holmes > wrote: > > In os::fork_and_exec we provide a per platform fork/exec > implementation for use by the OnError and OnOutOfMemory JVM options. > > On linux this is implemented with direct syscalls to _NR_fork > (sys_fork) and _NR_execve. > > We already encountered a problem on linux-sparc: > > http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2015-February/013811.html > > > due to a different register usage for the return value, which is so > far restricted to the 7u train but will need addressing in 8u and 9. > > Further it seems that the fork syscall has actually been deprecated > for quite some time and we are now seeing kernels on some platforms > which are no longer providing any of the deprecated syscalls - we > simply get an error ENOSYS. > > The fork() library was updated to use clone a long time ago, but as > I understand it we can't use the fork() library call because we > might be executing in a signal-handling context within the error > handler. > > So I'm considering switching to use the clone syscall for all linux > systems. > > Thoughts/comments? > > David > > From david.holmes at oracle.com Tue Apr 14 05:57:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Apr 2015 15:57:46 +1000 Subject: Replacing syscall(_NR_fork) on linux with syscall(_NR_clone) In-Reply-To: References: <55278002.8040705@oracle.com> Message-ID: <552CAC5A.4020300@oracle.com> On 11/04/2015 12:19 AM, Martin Buchholz wrote: > At Google, we also had trouble with syscall(__NR_fork). We switched to > simply calling fork despite the ominous warnings and have had no trouble > since. We avoid calling clone - see my old failures with it in > UNIXProcess_md.c. Although if we follow the successful precedent of > UNIXProcess_md.c we should call vfork instead, but we haven't yet had > the need. Thanks Martin. As per my reply to Thomas I think following the path you've already trod seems the simplest short-term approach. David > @@ -6012,8 +6689,15 @@ > // separate process to execve. Make a direct syscall to fork process. > // On IA64 there's no fork syscall, we have to use fork() and hope for > // the best... > - pid_t pid = NOT_IA64(syscall(__NR_fork);) > - IA64_ONLY(fork();) > + // pid_t pid = NOT_IA64(syscall(__NR_fork);) > + // IA64_ONLY(fork();) > + > + // Google Specific: Changing the above code to use the fork glibc call in > + // NOT_IA64. This allows the successful execution of the fork in a > case where > + // the previous syscall hung and hence allows successful OOM exit. > + // We believe that fork() is now async-safe and suspect the above > note about > + // pthread_atfork handlers and resetting the pthread library is outdated. > + pid_t pid = fork(); > if (pid < 0) { > // fork failed > @@ -6029,10 +6713,16 @@ > // in the new process, so make a system call directly. > // IA64 should use normal execve() from glibc to match the glibc > fork() > // above. > - NOT_IA64(syscall(__NR_execve, "/bin/sh", argv, environ);) > - IA64_ONLY(execve("/bin/sh", (char* const*)argv, environ);) > + // NOT_IA64(syscall(__NR_execve, "/bin/sh", argv, environ);) > + // IA64_ONLY(execve("/bin/sh", (char* const*)argv, environ);) > + > + // Google Specific: Based on fork case above changed this code to > use execve > + // glibc call in NOT_IA64 case. > + execve("/bin/sh", (char* const*)argv, environ); > // execve failed > + tty->print_cr("execve of OnError command \"/bin/sh -c %s\" failed > with errno %d: %s", > + cmd, errno, strerror(errno)); > _exit(-1); > } else { > > > On Fri, Apr 10, 2015 at 12:47 AM, David Holmes > wrote: > > In os::fork_and_exec we provide a per platform fork/exec > implementation for use by the OnError and OnOutOfMemory JVM options. > > On linux this is implemented with direct syscalls to _NR_fork > (sys_fork) and _NR_execve. > > We already encountered a problem on linux-sparc: > > http://mail.openjdk.java.net/__pipermail/hotspot-runtime-dev/__2015-February/013811.html > > > due to a different register usage for the return value, which is so > far restricted to the 7u train but will need addressing in 8u and 9. > > Further it seems that the fork syscall has actually been deprecated > for quite some time and we are now seeing kernels on some platforms > which are no longer providing any of the deprecated syscalls - we > simply get an error ENOSYS. > > The fork() library was updated to use clone a long time ago, but as > I understand it we can't use the fork() library call because we > might be executing in a signal-handling context within the error > handler. > > So I'm considering switching to use the clone syscall for all linux > systems. > > Thoughts/comments? > > David > > From goetz.lindenmaier at sap.com Tue Apr 14 06:58:32 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Apr 2015 06:58:32 +0000 Subject: RFR(S): 8077618: Move rtmLocking.cpp to shared directory. In-Reply-To: <552C1AE2.1080007@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBE374@DEWDFEMB12A.global.corp.sap> <552C1AE2.1080007@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBE4EA@DEWDFEMB12A.global.corp.sap> Thanks Vladimir! Best regards Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Montag, 13. April 2015 21:37 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8077618: Move rtmLocking.cpp to shared directory. Looks good to me. Thanks, Vladimir On 4/13/15 8:57 AM, Lindenmaier, Goetz wrote: > Hi, > > we implemented support for Transactional Memory on ppc. For this, we need > the file rtmLocking.cpp from subdirectory x86 as is. > > Therefore I would like to move the file to share/vm/runtime, where the > corresponding header is placed. I added a guard around the code in this file. > > Also, I moved #ifdef x86 from globalDefinitions.hpp to globalDefinitions_x86.hpp > which simplifies enabling RTM on PPC. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8077618-mvRTM/webrev.01/ > > Best regards, > Goetz. > > > > From goetz.lindenmaier at sap.com Tue Apr 14 06:59:18 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Apr 2015 06:59:18 +0000 Subject: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. In-Reply-To: <552C2263.10903@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFB8DBE@DEWDFEMB12A.global.corp.sap> <5519B880.20106@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBE19B@DEWDFEMB12A.global.corp.sap> <552C2263.10903@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBE4FB@DEWDFEMB12A.global.corp.sap> Thanks for pushing it, Vladimir! Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Montag, 13. April 2015 22:09 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: Re: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. In JPRT queue. Vladimir On 4/13/15 5:51 AM, Lindenmaier, Goetz wrote: > Hi, > > sorry for letting this sleep two weeks, I've been off ... > > Vladimir, thanks for the review. > > I please need a sponsor. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Montag, 30. M?rz 2015 22:57 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR (XS): 8076057: aix: After 8075506, aix does not support large pages. > > Good. > > Thanks, > Vladimir > > On 3/27/15 12:58 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> on Aix, we don't support large pages. >> This needs to be manifested in arguments.cpp. >> The change simply reuses a #ifdef BSD for AIX, too. >> >> Please review this tiny change, and I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8076057-aixULP/webrev.00/ >> >> Best regards, >> Goetz. >> From goetz.lindenmaier at sap.com Tue Apr 14 07:07:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Apr 2015 07:07:01 +0000 Subject: RFR(S): 8077618: Move rtmLocking.cpp to shared directory. In-Reply-To: <552C6F1E.3060102@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBE374@DEWDFEMB12A.global.corp.sap> <552C6F1E.3060102@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBE518@DEWDFEMB12A.global.corp.sap> Thanks, David! Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 14. April 2015 03:37 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8077618: Move rtmLocking.cpp to shared directory. Hi Goetz, On 14/04/2015 1:57 AM, Lindenmaier, Goetz wrote: > Hi, > > we implemented support for Transactional Memory on ppc. For this, we need > the file rtmLocking.cpp from subdirectory x86 as is. > Therefore I would like to move the file to share/vm/runtime, where the > corresponding header is placed. I added a guard around the code in this file. Not sure if we need the guard in the cpp file - I guess it speeds up compilation a tiny amount :) If we do want it then the copyright date needs updating to "2014, 2015,". > Also, I moved #ifdef x86 from globalDefinitions.hpp to globalDefinitions_x86.hpp > which simplifies enabling RTM on PPC. Copyright date in src/cpu/x86/vm/globalDefinitions_x86.hpp needs updating. > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8077618-mvRTM/webrev.01/ Otherwise looks okay. David > Best regards, > Goetz. > > > > From staffan.larsen at oracle.com Tue Apr 14 07:54:48 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Apr 2015 09:54:48 +0200 Subject: RFR: 8077364 "if( !this )" construct prevents build on Xcode 6.3 Message-ID: <8BA48D50-7BC7-415C-9E76-695E9BB16E3E@oracle.com> Please review this fix for compiling hotspot with clang 6.1. I have verified that the compiler workarounds are still needed for these tests: jdk/test/sun/misc/CopyMemory.java hotspot/test/compiler/c2/5091921/ webrev: http://cr.openjdk.java.net/~sla/8077364/webrev.00 bug: https://bugs.openjdk.java.net/browse/JDK-8077364 Thanks, /Staffan From volker.simonis at gmail.com Tue Apr 14 08:30:48 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Apr 2015 10:30:48 +0200 Subject: RFR: 8077364 "if( !this )" construct prevents build on Xcode 6.3 In-Reply-To: <8BA48D50-7BC7-415C-9E76-695E9BB16E3E@oracle.com> References: <8BA48D50-7BC7-415C-9E76-695E9BB16E3E@oracle.com> Message-ID: Hi Staffan, the change looks good, but the list of compiler versions for which we need a the same workaround seems to get a little bit long. Shouldn't we change that to something like: # Clang <= 6.1 ifeq ($(shell expr $(CC_VER_MAJOR) \< 6 \| \( $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 \) ), 1) OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) OPT_CFLAGS/unsafe.o += -O1 else $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") endif Regards, Volker On Tue, Apr 14, 2015 at 9:54 AM, Staffan Larsen wrote: > Please review this fix for compiling hotspot with clang 6.1. > > I have verified that the compiler workarounds are still needed for these tests: > jdk/test/sun/misc/CopyMemory.java > hotspot/test/compiler/c2/5091921/ > > webrev: http://cr.openjdk.java.net/~sla/8077364/webrev.00 > bug: https://bugs.openjdk.java.net/browse/JDK-8077364 > > Thanks, > /Staffan > From stefan.karlsson at oracle.com Tue Apr 14 08:50:08 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 14 Apr 2015 10:50:08 +0200 Subject: RFR; 8077420: Build failure with SS12u4 In-Reply-To: <552C75BA.8090307@oracle.com> References: <552BAF27.5020800@oracle.com> <552BB5B3.7090805@oracle.com> <552BBBFA.6090109@oracle.com> <552C75BA.8090307@oracle.com> Message-ID: <552CD4C0.7020104@oracle.com> On 2015-04-14 04:04, David Holmes wrote: > Hi Stefan, > > On 13/04/2015 10:52 PM, Stefan Karlsson wrote: >> Hi David, >> >> On 2015-04-13 14:25, David Holmes wrote: >>> Hi Stefan, >>> >>> On 13/04/2015 9:57 PM, Stefan Karlsson wrote: >>>> Hi, >>>> >>>> Please review this fix for a build failure that was encountered during >>>> the Solaris Studio compiler upgrade. >>> >>> So what was it about the compiler upgrade that exposed this ?? >> >> I'm not sure, but somehow the function wasn't made available to the >> compiler/linker. Maybe there's a combination of the inline keyword and >> template functions that used to work, but doesn't anymore? I don't have >> access to a SS12u4 setup, so Erik J had to compile with the patch. > > Ok. I'm seeing some other weird stuff coming out in relation to > SS12u4. :) > >>> >>>> Two files were missing an include of stack.inline.hpp, which is needed >>>> to get the definition of default_segment_size(). This function is used >>>> in the stack.hpp, to provide the default value to the constructor. >>>> This >>>> forces all users of Stacks with the default segment size, to have to >>>> include stack.inline.hpp. The default_segment_size() implementation >>>> always evaluates to the same value, given the template parameters, >>>> so I >>>> chose to setup a constant in the header instead of adding the missing >>>> stack.inline.hpp files. >>>> >>>> http://cr.openjdk.java.net/~stefank/8077420/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8077420 >>> >>> This seems okay but I have to say I remain very confused about the >>> "right" way to deal with .hpp and .inline.hpp files in general. >> >> OK. One rule to honor, as far as possible, is to _not_ use functions in >> inline.hpp files from .hpp files. In this case stack.hpp used a function >> in stack.inline.hpp. > > That seems reasonable given that if you have a .inline.hpp I would > expect that all defined functions should be in there. Having some > functions in the .hpp and some in the .inline.hpp seems a recipe for > total confusion. :) If a function doesn't "have to" be inlined, I would prefer if it was put inside the cpp file instead. Depending on where function definition is placed, we "leak" the includes of dependent header files to code that doesn't need it, which might cause problems like circular dependencies in completely unrelated parts of the code base. If the function definition is put in: 1) cpp - Only the cpp file will include the dependent headers. 2) inline.hpp - All includers of the inline.hpp will transitively include the dependent headers. Usually, only files calling any of the functions in the inline.hpp should include the inline.hpp files. Therefore, we don't want to call functions in inline.hpp files from hpp files, since that will spread the dependent includes to unrelated parts of the code base. 3) hpp - All includers of the hpp files will transitively include the dependent headers. Whereas inline.hpp files should only be included if any of the functions in the file are used, hpp files are needed to get typedefs, macros, class structure, etc. so they are included from more often. So, placing the function definition in the hpp file will most likely spread the dependent includes even more. I thinks we should strive to put function definition into cpp file, unless they are performance critical, then we should consider placing them in inline.hpp files and take the extra maintenance cost of having the inline.hpp file. Putting the definition in the hpp file should be avoided, unless it's small functions like getter/setter, and that those functions don't use functions defined in other files. This also needs to be considered when adding code to an existing function in a hpp file. For example, don't add assert(Univese::heap()->promotion_should_faile(), "sanity"), to a hpp file, since that will bring in the dependent includes assert.hpp, universe.hpp, collectedHeap.inline.hpp. > >> Maybe there's a more authoritative place that describes the "right way", >> but I think this post is worth reading and describes it well enough: >> http://www.cplusplus.com/forum/articles/10627/ > > It doesn't really address the .inline.hpp, as it never states > when/where to include the .inline.hpp file - there is even some > discussion in the comments about the problems relating to wanting > functions inlined if not in the included header, but no resolution. You're right that it doesn't address where to include the inline.hpp file, and it actually suggests that the inline.hpp file should be included at the end of the hpp file. I misread that part. :( > He also says that including the .hpp in the .inline.hpp is harmless > but unnecessary - which suggest he expected client code to include > both of them (whereas I think what has been advocated in hotspot > lately is for client code to include the .inline.hpp and for the the > .inline.hpp to include the .hpp). I think he says it's unnecessary since he is including the inline.hpp into the hpp file. Whereas we (should) only include inline.hpp files in cpp files or other inline.hpp files. Including only the inline.hpp file and not both hpp and inline.hpp files are just a convention that I like to keep the include line lengths down a bit. If it's causing confusions then it might be better if we skip that convention. As an example, the include list in iterator.inline.hpp would then go from: #include "classfile/classLoaderData.hpp" #include "memory/iterator.hpp" #include "oops/klass.hpp" #include "oops/instanceKlass.inline.hpp" #include "oops/instanceMirrorKlass.inline.hpp" #include "oops/instanceClassLoaderKlass.inline.hpp" #include "oops/instanceRefKlass.inline.hpp" #include "oops/objArrayKlass.inline.hpp" #include "oops/typeArrayKlass.inline.hpp" #include "utilities/debug.hpp" to: #include "classfile/classLoaderData.hpp" #include "memory/iterator.hpp" #include "oops/klass.hpp" #include "oops/instanceKlass.hpp" #include "oops/instanceKlass.inline.hpp" #include "oops/instanceMirrorKlass.hpp" #include "oops/instanceMirrorKlass.inline.hpp" #include "oops/instanceClassLoaderKlass.hpp" #include "oops/instanceClassLoaderKlass.inline.hpp" #include "oops/instanceRefKlass.hpp" #include "oops/instanceRefKlass.inline.hpp" #include "oops/objArrayKlass.hpp" #include "oops/objArrayKlass.inline.hpp" #include "oops/typeArrayKlass.hpp" #include "oops/typeArrayKlass.inline.hpp" #include "utilities/debug.hpp" > > I did like the simple rules regarding forward declarations versus > include dependencies. My C++ introduction was in an environment where > forward declarations were seen as a hack to deal with circular > dependencies, rather than being a first class mechanism for > introducing type names. They are a nice way to lower the include dependency in header files. Unfortunately, enums can't be forward declared in C++03. Thanks, StefanK > > Cheers, > David > >> Thanks, >> StefanK >> >>> >>> Thanks, >>> David >>> >>>> Tested with JPRT, and built with SS12u4. >>>> >>>> Thanks, >>>> StefanK >> From stefan.karlsson at oracle.com Tue Apr 14 08:54:58 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 14 Apr 2015 10:54:58 +0200 Subject: RFR: 8077364 "if( !this )" construct prevents build on Xcode 6.3 In-Reply-To: <8BA48D50-7BC7-415C-9E76-695E9BB16E3E@oracle.com> References: <8BA48D50-7BC7-415C-9E76-695E9BB16E3E@oracle.com> Message-ID: <552CD5E2.9020207@oracle.com> Hi Staffan, On 2015-04-14 09:54, Staffan Larsen wrote: > Please review this fix for compiling hotspot with clang 6.1. > > I have verified that the compiler workarounds are still needed for these tests: > jdk/test/sun/misc/CopyMemory.java > hotspot/test/compiler/c2/5091921/ > > webrev: http://cr.openjdk.java.net/~sla/8077364/webrev.00 > bug: https://bugs.openjdk.java.net/browse/JDK-8077364 What about this code that is protected by #ifndef PRODUCT char *PhaseChaitin::dump_register( const Node *n, char *buf ) const { if( !this ) { // Not got anything? sprintf(buf,"N%d",n->_idx); // Then use Node index } Thanks, StefanK > > Thanks, > /Staffan > From staffan.larsen at oracle.com Tue Apr 14 09:19:15 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Apr 2015 11:19:15 +0200 Subject: RFR: 8077364 "if( !this )" construct prevents build on Xcode 6.3 In-Reply-To: <552CD5E2.9020207@oracle.com> References: <8BA48D50-7BC7-415C-9E76-695E9BB16E3E@oracle.com> <552CD5E2.9020207@oracle.com> Message-ID: Stefan, Volker: Thanks for the suggestions and spotting the errors. new webrev: http://cr.openjdk.java.net/~sla/8077364/webrev.01/ Thanks, /Staffan > On 14 apr 2015, at 10:54, Stefan Karlsson wrote: > > Hi Staffan, > > On 2015-04-14 09:54, Staffan Larsen wrote: >> Please review this fix for compiling hotspot with clang 6.1. >> >> I have verified that the compiler workarounds are still needed for these tests: >> jdk/test/sun/misc/CopyMemory.java >> hotspot/test/compiler/c2/5091921/ >> >> webrev: http://cr.openjdk.java.net/~sla/8077364/webrev.00 >> bug: https://bugs.openjdk.java.net/browse/JDK-8077364 > > What about this code that is protected by #ifndef PRODUCT > > char *PhaseChaitin::dump_register( const Node *n, char *buf ) const { > if( !this ) { // Not got anything? > sprintf(buf,"N%d",n->_idx); // Then use Node index > } > > Thanks, > StefanK > >> >> Thanks, >> /Staffan >> > From stefan.karlsson at oracle.com Tue Apr 14 09:31:05 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 14 Apr 2015 11:31:05 +0200 Subject: RFR: 8077364 "if( !this )" construct prevents build on Xcode 6.3 In-Reply-To: References: <8BA48D50-7BC7-415C-9E76-695E9BB16E3E@oracle.com> <552CD5E2.9020207@oracle.com> Message-ID: <552CDE59.1070401@oracle.com> On 2015-04-14 11:19, Staffan Larsen wrote: > Stefan, Volker: Thanks for the suggestions and spotting the errors. > > new webrev: http://cr.openjdk.java.net/~sla/8077364/webrev.01/ The changes to the cpp files look good. I'll let Volker review the make file changes. :) Thanks, StefanK > > Thanks, > /Staffan > >> On 14 apr 2015, at 10:54, Stefan Karlsson wrote: >> >> Hi Staffan, >> >> On 2015-04-14 09:54, Staffan Larsen wrote: >>> Please review this fix for compiling hotspot with clang 6.1. >>> >>> I have verified that the compiler workarounds are still needed for these tests: >>> jdk/test/sun/misc/CopyMemory.java >>> hotspot/test/compiler/c2/5091921/ >>> >>> webrev: http://cr.openjdk.java.net/~sla/8077364/webrev.00 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8077364 >> What about this code that is protected by #ifndef PRODUCT >> >> char *PhaseChaitin::dump_register( const Node *n, char *buf ) const { >> if( !this ) { // Not got anything? >> sprintf(buf,"N%d",n->_idx); // Then use Node index >> } >> >> Thanks, >> StefanK >> >>> Thanks, >>> /Staffan >>> From aph at redhat.com Tue Apr 14 09:54:31 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Apr 2015 10:54:31 +0100 Subject: RFR: 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method In-Reply-To: <552C0BA6.2050609@oracle.com> References: <552C0456.1040602@redhat.com> <552C04A0.3060906@redhat.com> <552C0BA6.2050609@oracle.com> Message-ID: <552CE3D7.4090608@redhat.com> On 04/13/2015 07:32 PM, Vladimir Kozlov wrote: > What was Subject of that email (with patch for squareToLen)? Re: RFR(L): 8069539: RSA acceleration I mean this one: http://cr.openjdk.java.net/~kvn/8069539/webrev.00/ Andrew. From aph at redhat.com Tue Apr 14 10:10:56 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Apr 2015 11:10:56 +0100 Subject: RFR: 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method In-Reply-To: <552C1524.4010701@oracle.com> References: <552C0456.1040602@redhat.com> <552C1524.4010701@oracle.com> Message-ID: <552CE7B0.7010105@redhat.com> On 04/13/2015 08:12 PM, Vladimir Kozlov wrote: > In the test you removed next line from previous test. Can you restore them?: > > System.out.println(b1); > System.out.println(b2); Oops. It was hard to see that in the diff. > I have a little problem of mapping code from comments to assembler for > multiply_64_x_64_loop(). Extend comments. > I think in next comments x_xstart should be used on left side instead of > 'product': Yes. > + umulh(rscratch1, x_xstart, y_idx); // product * y_idx -> > rscratch1:product > + mul(product, x_xstart, y_idx); > + adds(product, product, carry); > + adc(carry, rscratch1, zr); // product * y_idx + carry -> carry:product > > Also why not use BytesPerLong instead of BytesPerWord?: OK. Also, I did a new merge and the port no longer built: /local/aarch64/dev/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp:61:16: error: 'virtual void MacroAssembler::call_VM_leaf_base(address, int, Label&)' was hidden [-Werror=overloaded-virtual] VIRTUAL void call_VM_leaf_base( ^ This is a correct warning message, so I added a using directive to clarify the intent. http://cr.openjdk.java.net/~aph/8077615-1/ Andrew. From vladimir.x.ivanov at oracle.com Tue Apr 14 10:59:53 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Apr 2015 13:59:53 +0300 Subject: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names In-Reply-To: <552C6387.20908@oracle.com> References: <55254C1B.2040603@oracle.com> <5525E95F.7080306@oracle.com> <552691DA.7000604@oracle.com> <55270862.9020704@oracle.com> <38AF71DB-944B-42B8-A955-C5173881BE63@oracle.com> <552BFF60.40803@oracle.com> <552C6387.20908@oracle.com> Message-ID: <552CF329.2070000@oracle.com> David, John, thanks for review! Best regards, Vladimir Ivanov On 4/14/15 3:47 AM, David Holmes wrote: > On 14/04/2015 3:39 AM, Vladimir Ivanov wrote: >> John, David, thanks for the feedback! >> >> What do you think about the following version: >> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk >> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/hotspot > > Looks good - thanks. > > David > >> Best regards, >> Vladimir Ivanov >> >> On 4/10/15 10:15 PM, John Rose wrote: >>> On Apr 9, 2015, at 4:16 PM, David Holmes >> > wrote: >>>> >>>> Hi Vladimir, >>>> >>>> On 10/04/2015 12:51 AM, Vladimir Ivanov wrote: >>>>> David, thanks for the feedback! >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/jdk >>>>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/hotspot >>>>> >>>>> I restored original logic and call into VM only if it fails. >>>> >>>> This change seems fine to me, but I think John may prefer to see >>>> getSimpleName implemented such that it always returns the name from >>>> the innerclass attribute. (Though perhaps with caching if performance >>>> is a concern?) >>> >>> Yes, I do prefer the new logic instead of a combination of old and new. >>> >>> Two concerns: Somebody somewhere might be relying on a bug in the old >>> logic and be frustrated by seeing that bug fixed. This is a fine line >>> to walk, but in this case I think the behavior change (if any) will show >>> up in places where we already have outages. Perhaps someone is >>> post-processing the result of getSimpleName to correct it. If so they >>> may no longer need to do that. >>> >>> Second, the new logic may itself have issues. A typical problem with >>> the InnerClasses attribute is it is broken or stripped, or a related >>> nestmate is missing. (See parallel thread in core-libs-dev on 8076264.) >>> But the proposed change takes effect after a call to >>> Class.getEnclosingClass, which uses >>> InstanceKlass::compute_enclosing_class_impl and accesses the same >>> InnerClasses record. >>> >>> This leads me to a comment: The common code (two uses >>> of InnerClassesIterator with klass_name_at_matches) should be factored >>> out. The factored subroutine should search out the self-record in the >>> InnerClasses attribute. The logic is tricky enough that I'm >>> uncomfortable with it being duplicated. Key issue: We don't want to >>> load any classes doing this lookup. >>> >>> (For bonus points, factor the third use in that file, the one that looks >>> not for self but for children-of-self. Add a boolean flag that varies >>> the test.) >>> >>> Bottom line: The new logic should replace the old. >>>> >>>>>>> The logic to compute simple name (Class.getSimpleName()) for >>>>>>> inner/nested/local classes is tightly coupled with Java naming >>>>>>> scheme >>>>>>> and sometimes fails for classes generated from non-Java code. >>>>>> >>>>>> Meta-question: if this is non-Java code then what does/should >>>>>> "simpleName" even mean? "Returns the simple name of the underlying >>>>>> class >>>>>> as given in the source code." If there is no (java) source code does >>>>>> this have any meaning? Should it return "" ? >>>>> My reading of the JVMS is that InnerClasses attribute can be freely >>>>> used >>>>> by non-Java compilers to store simple names for classes they generate. >>>>> The current wording for inner_name_index doesn't mention Java >>>>> language. >>>> >>>> True, but it does refer to source code: "represents the original >>>> simple name of C, as given in the source code from which this class >>>> file was compiled. " which seems misplaced as we're discussing classes >>>> for which there is no source code as such. >>> >>> It could be non-Java source code. In any case, the indicated component >>> of the "binary name" of the class is well-defined, whether or not it >>> occurs in source code. Note also that classes might be generated by ASM >>> (no source code per se) but we still have a reasonable expectation of >>> reflecting on them, even though reflection is (mostly) defined in terms >>> of source code constructs. >>> >>>> Anyway it just flags to me that perhaps these Class methods need to be >>>> generalized a bit given the support for non-Java languages on the JVM. >>>> But that's for core-libs folk to decide. >>> >>> Yes, I think that's the issue. The multi-language folks (like me) would >>> be disappointed to hear that we decided that non-Java languages don't >>> have any needs here; they do. >>> >>> Thanks, >>> ? John >>> >>>> Thanks, >>>> David >>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>>>> Instead of parsing class name and try to extract simple name >>>>>>> based on >>>>>>> JLS rules, the fix I propose is to use InnerClasses attribute from >>>>>>> the >>>>>>> class file. Simple name is already recorded there. >>>>>> > >>>>>>> JVMS-4.7.6: The InnerClasses Attribute >>>>>>> "inner_name_index: If C is anonymous (JLS ?15.9.5), the value of the >>>>>>> inner_name_index item must be zero. Otherwise, the value of the >>>>>>> inner_name_index item must be a valid index into the constant_pool >>>>>>> table, and the entry at that index must be a CONSTANT_Utf8_info >>>>>>> structure (?4.4.7) that represents the original simple name of C, as >>>>>>> given in the source code from which this class file was compiled." >>>>>>> >>>>>>> Since I consider backporting the fix into 8u60, I'd like to hear >>>>>>> opinions about backward compatibility of such change. >>>>>>> >>>>>>> As an alternative solution, I can restore original logic and consult >>>>>>> InnerClasses attribute when class name parsing logic fails. >>>>>> >>>>>> I think I'd prefer to see the VM call only used as a fallback if the >>>>>> regular parsing fails. That would prevent any compatibility issues >>>>>> for >>>>>> the 8u backport (ignoring tests that deliberately generate invalidly >>>>>> named classes). >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/ >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>> From volker.simonis at gmail.com Tue Apr 14 12:11:20 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Apr 2015 14:11:20 +0200 Subject: RFR: 8077364 "if( !this )" construct prevents build on Xcode 6.3 In-Reply-To: <552CDE59.1070401@oracle.com> References: <8BA48D50-7BC7-415C-9E76-695E9BB16E3E@oracle.com> <552CD5E2.9020207@oracle.com> <552CDE59.1070401@oracle.com> Message-ID: Make changes look good as well. Thanks, Volker On Tue, Apr 14, 2015 at 11:31 AM, Stefan Karlsson wrote: > On 2015-04-14 11:19, Staffan Larsen wrote: >> >> Stefan, Volker: Thanks for the suggestions and spotting the errors. >> >> new webrev: http://cr.openjdk.java.net/~sla/8077364/webrev.01/ >> > > > The changes to the cpp files look good. I'll let Volker review the make file > changes. :) > > Thanks, > StefanK > > >> >> Thanks, >> /Staffan >> >>> On 14 apr 2015, at 10:54, Stefan Karlsson >>> wrote: >>> >>> Hi Staffan, >>> >>> On 2015-04-14 09:54, Staffan Larsen wrote: >>>> >>>> Please review this fix for compiling hotspot with clang 6.1. >>>> >>>> I have verified that the compiler workarounds are still needed for these >>>> tests: >>>> jdk/test/sun/misc/CopyMemory.java >>>> hotspot/test/compiler/c2/5091921/ >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8077364/webrev.00 >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8077364 >>>> >>> >>> What about this code that is protected by #ifndef PRODUCT >>> >>> char *PhaseChaitin::dump_register( const Node *n, char *buf ) const { >>> if( !this ) { // Not got anything? >>> sprintf(buf,"N%d",n->_idx); // Then use Node index >>> } >>> >>> Thanks, >>> StefanK >>> >>>> Thanks, >>>> /Staffan >>>> > From aph at redhat.com Tue Apr 14 12:26:20 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Apr 2015 13:26:20 +0100 Subject: HotSpot workflow Message-ID: <552D076C.20500@redhat.com> I'm having some practical problems with the HotSpot workflow. I usually have several patches on the fly at any time, but webrev and Mercurial don't really help. "hg push" and "hg merge" work on the whole repo, not just a changeset, so I've been manually saving changesets and re-merging them into the master tree, which is very error-prone and has led to some mistakes submitting changes. Also, the need to submit a change as a single changeset makes it awkward to commit regularly as I work on a patch; I can't find any way to merge a set of changes into a single changeset and push that. So, what do you do? Do you keep a source tree checked out for every webrev? Do you regularly commit as you work? Am I missing some tricks? Thanks, Andrew. From claes.redestad at oracle.com Tue Apr 14 12:39:40 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 14 Apr 2015 14:39:40 +0200 Subject: HotSpot workflow In-Reply-To: <552D076C.20500@redhat.com> References: <552D076C.20500@redhat.com> Message-ID: <552D0A8C.2020406@oracle.com> Hi, I'm stuck in the bad(?) habit of using mq: http://mercurial.selenic.com/wiki/MqExtension It's obviously not without it's own faults, and there are some proponents of just committing your in-progress changesets locally and then use hg rebase/histedit to fold it all up into one changeset applied to the tip before pushing remotely: http://mercurial.selenic.com/wiki/RebaseExtension http://mercurial.selenic.com/wiki/HisteditExtension Either way, webrev has support to work across any number of applied changesets (using -r N), which helps ensure folding into one changeset can be deferred until it's time to push. HTH /Claes On 04/14/2015 02:26 PM, Andrew Haley wrote: > I'm having some practical problems with the HotSpot workflow. > > I usually have several patches on the fly at any time, but webrev and > Mercurial don't really help. "hg push" and "hg merge" work on the > whole repo, not just a changeset, so I've been manually saving > changesets and re-merging them into the master tree, which is very > error-prone and has led to some mistakes submitting changes. > > Also, the need to submit a change as a single changeset makes it > awkward to commit regularly as I work on a patch; I can't find any way > to merge a set of changes into a single changeset and push that. > > So, what do you do? Do you keep a source tree checked out for every > webrev? Do you regularly commit as you work? Am I missing > some tricks? > > Thanks, > Andrew. From vladimir.x.ivanov at oracle.com Tue Apr 14 12:45:56 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Apr 2015 15:45:56 +0300 Subject: HotSpot workflow In-Reply-To: <552D076C.20500@redhat.com> References: <552D076C.20500@redhat.com> Message-ID: <552D0C04.4010200@oracle.com> Andrew, mq [1] is part of my workflow. Also, rebase [2] + strip [3] + histedit [4] combo looks like a good alternative. I played with rebase and it enables interactive merge during rebase. AFAIK mq doesn't support that. Best regards, Vladimir Ivanov [1] http://mercurial.selenic.com/wiki/MqExtension My top commands: # Create new patch from uncommitted changes $ hg qnew # Update applied patch on top and edit changeset message $ hg qrefresh -e $ hg qpush $ hg qpush [--move] [] # Fold 2 patches $ hg qfold ... # Commit the patch $ hg qfinish [2] http://mercurial.selenic.com/wiki/RebaseExtension [3] http://mercurial.selenic.com/wiki/StripExtension [4] http://mercurial.selenic.com/wiki/EditingHistory On 4/14/15 3:26 PM, Andrew Haley wrote: > I'm having some practical problems with the HotSpot workflow. > > I usually have several patches on the fly at any time, but webrev and > Mercurial don't really help. "hg push" and "hg merge" work on the > whole repo, not just a changeset, so I've been manually saving > changesets and re-merging them into the master tree, which is very > error-prone and has led to some mistakes submitting changes. > > Also, the need to submit a change as a single changeset makes it > awkward to commit regularly as I work on a patch; I can't find any way > to merge a set of changes into a single changeset and push that. > > So, what do you do? Do you keep a source tree checked out for every > webrev? Do you regularly commit as you work? Am I missing > some tricks? > > Thanks, > Andrew. > From roland.westrelin at oracle.com Tue Apr 14 12:52:00 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 14 Apr 2015 14:52:00 +0200 Subject: HotSpot workflow In-Reply-To: <552D076C.20500@redhat.com> References: <552D076C.20500@redhat.com> Message-ID: <416667B6-EABA-4EE7-B6D0-B04CADFCB707@oracle.com> > I'm having some practical problems with the HotSpot workflow. > > I usually have several patches on the fly at any time, but webrev and > Mercurial don't really help. "hg push" and "hg merge" work on the > whole repo, not just a changeset, so I've been manually saving > changesets and re-merging them into the master tree, which is very > error-prone and has led to some mistakes submitting changes. > > Also, the need to submit a change as a single changeset makes it > awkward to commit regularly as I work on a patch; I can't find any way > to merge a set of changes into a single changeset and push that. > > So, what do you do? Do you keep a source tree checked out for every > webrev? Do you regularly commit as you work? Am I missing > some tricks? I, personally, keep a single hotspot tree with all my work in progress. I use bookmarks to keep track of the various projects/bugs I have in progress. I commit often and use the histedit extension to fold changesets and edit commit messages. I use the rebase extension to rebase after a pull. I make a copy of the repo before I push and have a script that strips every changeset not in the parent repo except the current one, which is the one I?m pushing. I used to use mq but I?ve given up on it. This is what I used as inspiration: http://gregoryszorc.com/blog/2014/06/23/please-stop-using-mq/ I also use revsets a lot: http://www.selenic.com/hg/help/revsets For instance: hg log -r max(not outgoing()) tells me the latest changeset in my repo that is also in the remote repo so I know what to rebase to. Roland. > > Thanks, > Andrew. From volker.simonis at gmail.com Tue Apr 14 12:54:37 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Apr 2015 14:54:37 +0200 Subject: HotSpot workflow In-Reply-To: <552D076C.20500@redhat.com> References: <552D076C.20500@redhat.com> Message-ID: Mercurial Queues (mq) is your friend! I can not imagine imagine OpenJDK development without the MqExtension [1] and so far I managed to convince everybody to use it who was asking the same question like you :) With MqExtension you can easily keep an arbitrary number of Mercurial changes in a so called patch queue (it's located under .hg/patches). These patches can be easily and selectively imported into your actual repository ("hg qpush") or backed out again ("hg qpop"). You can also merge several changes in the patch queue into one change with "hg qfold". My usual wok-flow looks as follows: hg clone / hg pull -u hg qnew -m "My first local change" first.patch hg qrefresh // "other local changes" will go into first.patch hg qnew -m "My second local change" second.patch hg qseries // will show the applied changes from the patch queue second.patch first.patch hg qpop --all // removes all local changes from the repo hg pull -u hg qpush --move first.patch hg qfinish first.patch // removes first.patch from patch queue and makes a 'real' changeset out of it. hg push You can read [1] for more examples and a complete documentation. In particular you can even version your patch queue! Regards, Volker [1] http://mercurial.selenic.com/wiki/MqExtension On Tue, Apr 14, 2015 at 2:26 PM, Andrew Haley wrote: > I'm having some practical problems with the HotSpot workflow. > > I usually have several patches on the fly at any time, but webrev and > Mercurial don't really help. "hg push" and "hg merge" work on the > whole repo, not just a changeset, so I've been manually saving > changesets and re-merging them into the master tree, which is very > error-prone and has led to some mistakes submitting changes. > > Also, the need to submit a change as a single changeset makes it > awkward to commit regularly as I work on a patch; I can't find any way > to merge a set of changes into a single changeset and push that. > > So, what do you do? Do you keep a source tree checked out for every > webrev? Do you regularly commit as you work? Am I missing > some tricks? > > Thanks, > Andrew. From aph at redhat.com Tue Apr 14 13:15:57 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Apr 2015 14:15:57 +0100 Subject: HotSpot workflow In-Reply-To: <552D076C.20500@redhat.com> References: <552D076C.20500@redhat.com> Message-ID: <552D130D.6090802@redhat.com> Thanks, everyone. That's really helpful. I'll look at mq, revsets, and histedit. Thanks again, Andrew. From volker.simonis at gmail.com Tue Apr 14 14:08:18 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Apr 2015 16:08:18 +0200 Subject: HotSpot workflow In-Reply-To: <416667B6-EABA-4EE7-B6D0-B04CADFCB707@oracle.com> References: <552D076C.20500@redhat.com> <416667B6-EABA-4EE7-B6D0-B04CADFCB707@oracle.com> Message-ID: On Tue, Apr 14, 2015 at 2:52 PM, Roland Westrelin wrote: >> I'm having some practical problems with the HotSpot workflow. >> >> I usually have several patches on the fly at any time, but webrev and >> Mercurial don't really help. "hg push" and "hg merge" work on the >> whole repo, not just a changeset, so I've been manually saving >> changesets and re-merging them into the master tree, which is very >> error-prone and has led to some mistakes submitting changes. >> >> Also, the need to submit a change as a single changeset makes it >> awkward to commit regularly as I work on a patch; I can't find any way >> to merge a set of changes into a single changeset and push that. >> >> So, what do you do? Do you keep a source tree checked out for every >> webrev? Do you regularly commit as you work? Am I missing >> some tricks? > > I, personally, keep a single hotspot tree with all my work in progress. I use bookmarks to keep track of the various projects/bugs I have in progress. I commit often and use the histedit extension to fold changesets and edit commit messages. I use the rebase extension to rebase after a pull. I make a copy of the repo before I push and have a script that strips every changeset not in the parent repo except the current one, which is the one I?m pushing. > > I used to use mq but I?ve given up on it. This is what I used as inspiration: > http://gregoryszorc.com/blog/2014/06/23/please-stop-using-mq/ > Thanks for the link - that's really interesting reading! Nevertheless it couldn't yet fully convince me :) What I specially like about mq is the fact that it is really simple and (at least I pretend) that I fully understand what it does. The very fact that it is actually just a list of plain, old patches is a feature for me :) > I also use revsets a lot: > http://www.selenic.com/hg/help/revsets > > For instance: > hg log -r max(not outgoing()) > tells me the latest changeset in my repo that is also in the remote repo so I know what to rebase to. > > Roland. > >> >> Thanks, >> Andrew. > From harold.seigel at oracle.com Tue Apr 14 14:49:13 2015 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 14 Apr 2015 10:49:13 -0400 Subject: RFR (S) JNI Specification Issue: JDK-8034923 JNI: static linking assertions specs are incomplete and are in the wrong section of spec In-Reply-To: <5523C169.6030903@oracle.com> References: <551D0217.7090508@oracle.com> <5523C169.6030903@oracle.com> Message-ID: <552D28E9.9090807@oracle.com> Hi David, The changes look good. Just a couple of nits (that can be ignored): invocation.html: 1. "this applies..." could be a new sentence. Also, remove the word 'even'? +

A native library may be either dynamically linked or statically linked with +the VM. The manner in which the library and VM image are combined is +implementation dependent. A System.loadLibrary or equivalent +API must succeed for a library to be considered loaded,*this applies* to both +dynamically and even statically linked libraries. 2. Change "If dynamically linked library defines ..." to "If *a* dynamically linked library defines ..." 3. Remove the second 'of' +libraries may define load and unload function hooks. Naming of +these*of* functions depends upon whether the library was dynamically or statically +linked.

4. Rephrase "the programmer should be conservative on using Java VM services ..." to "the programmer should *use VM services conservatively* ..." jni-8.html: 1. Change "during class load and unloading." to "during class load*ing* and unloading." 2. Change "will be prohibited to link a library ..." to "will be prohibited *from linking* a library ..." If you decide to use any of these suggestion, there's no need to post a new webrev. Thanks, Harold On 4/7/2015 7:37 AM, David Simms wrote: > > Couple of minor updates to the posted review > > * SINCE: JDK/JRE 1.8 tags on JNI_OnLoad_L and JNI_OnUnload_L > * table mapping SE->JNI should use SE 6/7/8 not 6.0/7.0/8.0 > * jniTOC.html: removed "Changes" link for ch.1. > > > > On 02/04/15 10:47, David Simms wrote: >> >> Greetings, >> >> JDK Bug: https://bugs.openjdk.java.net/browse/JDK-8034923 >> >> Web review: http://cr.openjdk.java.net/~dsimms/jnispec/8034923/ >> >> Original (for HTML comparison): >> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/index.html >> >> >> Summary of changes: >> >> Wholly confined to documentation changes, no code modifications made: >> >> * The "index.html" has named a "JNI version" number which has never >> been consistent. After some initial consultation with Stuart Marks >> and Alex Buckley, we decided to remove version from the document. >> o There are minor clarifications added to "enhancements.html" >> and "GetVersion" function documentation, listing the platform >> release mapped to JNI_VERSION_ constants. >> * Added the missing "JNI_VERSION_1_8" constant to GetVersion >> constants. >> * Moved most of the details regarding static library support (JEP >> 178) from "Design - Compiling, Loading and Linking Native Methods" >> to "Invocation API - Library and Version Management" >> o Rewording to clearly delineate static vs dynamic linked >> library load and unload hooks >> o Emphasis on statically linked libraries requiring >> "JNI_OnLoad_" hook. >> o Typos, function declaration and linkage sections cleaned up. >> * Reinstated the "Enhancements" links to JDK 1.2 & JDK 1.4 changes, >> and added new files for 1.6 and 1.8. >> >> >> Cheers >> /David Simms > From david.simms at oracle.com Tue Apr 14 15:06:32 2015 From: david.simms at oracle.com (David Simms) Date: Tue, 14 Apr 2015 17:06:32 +0200 Subject: RFR (S) JNI Specification Issue: JDK-8034923 JNI: static linking assertions specs are incomplete and are in the wrong section of spec In-Reply-To: <552D28E9.9090807@oracle.com> References: <551D0217.7090508@oracle.com> <5523C169.6030903@oracle.com> <552D28E9.9090807@oracle.com> Message-ID: <552D2CF8.7070608@oracle.com> Thanks Harold, Even after 3 pairs of eyes have been over this, small wording errors leak through, I appreciate the "nit" spotting...will update. Cheers /David Simms On 14/04/2015 4:49 p.m., harold seigel wrote: > Hi David, > > The changes look good. Just a couple of nits (that can be ignored): > > invocation.html: > > 1. "this applies..." could be a new sentence. Also, remove the word > 'even'? > > +

A native library may be either dynamically linked or statically > linked with > +the VM. The manner in which the library and VM image are combined is > +implementation dependent. A System.loadLibrary or > equivalent > +API must succeed for a library to be considered loaded,*this > applies* to both > +dynamically and even statically linked libraries. > > > > 2. Change "If dynamically linked library defines ..." to "If *a* > dynamically linked library defines ..." > > > 3. Remove the second 'of' > > +libraries may define load and unload function hooks. > Naming of > +these*of* functions depends upon whether the library was dynamically > or statically > +linked.

> > > > 4. Rephrase "the programmer should be conservative on using Java VM > services ..." to "the programmer should *use VM services > conservatively* ..." > > > jni-8.html: > > 1. Change "during class load and unloading." to "during class > load*ing* and unloading." > > > 2. Change "will be prohibited to link a library ..." to "will be > prohibited *from linking* a library ..." > > > If you decide to use any of these suggestion, there's no need to post > a new webrev. > > Thanks, Harold > > On 4/7/2015 7:37 AM, David Simms wrote: >> >> Couple of minor updates to the posted review >> >> * SINCE: JDK/JRE 1.8 tags on JNI_OnLoad_L and JNI_OnUnload_L >> * table mapping SE->JNI should use SE 6/7/8 not 6.0/7.0/8.0 >> * jniTOC.html: removed "Changes" link for ch.1. >> >> >> >> On 02/04/15 10:47, David Simms wrote: >>> >>> Greetings, >>> >>> JDK Bug: https://bugs.openjdk.java.net/browse/JDK-8034923 >>> >>> Web review: http://cr.openjdk.java.net/~dsimms/jnispec/8034923/ >>> >>> Original (for HTML comparison): >>> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/index.html >>> >>> >>> Summary of changes: >>> >>> Wholly confined to documentation changes, no code modifications made: >>> >>> * The "index.html" has named a "JNI version" number which has never >>> been consistent. After some initial consultation with Stuart Marks >>> and Alex Buckley, we decided to remove version from the document. >>> o There are minor clarifications added to "enhancements.html" >>> and "GetVersion" function documentation, listing the platform >>> release mapped to JNI_VERSION_ constants. >>> * Added the missing "JNI_VERSION_1_8" constant to GetVersion >>> constants. >>> * Moved most of the details regarding static library support (JEP >>> 178) from "Design - Compiling, Loading and Linking Native Methods" >>> to "Invocation API - Library and Version Management" >>> o Rewording to clearly delineate static vs dynamic linked >>> library load and unload hooks >>> o Emphasis on statically linked libraries requiring >>> "JNI_OnLoad_" hook. >>> o Typos, function declaration and linkage sections cleaned up. >>> * Reinstated the "Enhancements" links to JDK 1.2 & JDK 1.4 changes, >>> and added new files for 1.6 and 1.8. >>> >>> >>> Cheers >>> /David Simms >> > From dmitry.samersoff at oracle.com Tue Apr 14 16:34:00 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 14 Apr 2015 19:34:00 +0300 Subject: HotSpot workflow In-Reply-To: <552D076C.20500@redhat.com> References: <552D076C.20500@redhat.com> Message-ID: <552D4178.9080508@oracle.com> Andrew, I'm the rare person in JDK who doesn't adopt mq ;) Below is my workflow: Typically I have about five-six-ten CRs "in progress" in my pile. It's critical for me to have stable basement for the changes, so I create a separate folder for each problem, clone workspaces there and don't update it until the fix become complete. Right before push I merge my changes into the recent codebase and repeat all tests. I use hg TAG to mark a start of my work, than keep committing changes as necessary (hg ci, hg rollback etc) and at final stage just get a diff between the first and the last changeset using plain hg diff and apply this patch to fresh workspace. -Dmitry On 2015-04-14 15:26, Andrew Haley wrote: > I'm having some practical problems with the HotSpot workflow. > > I usually have several patches on the fly at any time, but webrev and > Mercurial don't really help. "hg push" and "hg merge" work on the > whole repo, not just a changeset, so I've been manually saving > changesets and re-merging them into the master tree, which is very > error-prone and has led to some mistakes submitting changes. > > Also, the need to submit a change as a single changeset makes it > awkward to commit regularly as I work on a patch; I can't find any way > to merge a set of changes into a single changeset and push that. > > So, what do you do? Do you keep a source tree checked out for every > webrev? Do you regularly commit as you work? Am I missing > some tricks? > > Thanks, > Andrew. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vladimir.kozlov at oracle.com Tue Apr 14 17:22:17 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Apr 2015 10:22:17 -0700 Subject: RFR: 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method In-Reply-To: <552CE3D7.4090608@redhat.com> References: <552C0456.1040602@redhat.com> <552C04A0.3060906@redhat.com> <552C0BA6.2050609@oracle.com> <552CE3D7.4090608@redhat.com> Message-ID: <552D4CC9.6010204@oracle.com> We are discussing how and which checks to add into java code which calls intrinsified methods to keep intrinsic simple. Vladimir On 4/14/15 2:54 AM, Andrew Haley wrote: > On 04/13/2015 07:32 PM, Vladimir Kozlov wrote: >> What was Subject of that email (with patch for squareToLen)? > > Re: RFR(L): 8069539: RSA acceleration > > I mean this one: > > http://cr.openjdk.java.net/~kvn/8069539/webrev.00/ > > Andrew. > From vladimir.kozlov at oracle.com Tue Apr 14 17:25:03 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Apr 2015 10:25:03 -0700 Subject: RFR: 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method In-Reply-To: <552CE7B0.7010105@redhat.com> References: <552C0456.1040602@redhat.com> <552C1524.4010701@oracle.com> <552CE7B0.7010105@redhat.com> Message-ID: <552D4D6F.6000307@oracle.com> Looks good. I will push it through JPRT since it has shared code change (test). Thanks, Vladimir On 4/14/15 3:10 AM, Andrew Haley wrote: > On 04/13/2015 08:12 PM, Vladimir Kozlov wrote: >> In the test you removed next line from previous test. Can you restore them?: >> >> System.out.println(b1); >> System.out.println(b2); > > Oops. It was hard to see that in the diff. > >> I have a little problem of mapping code from comments to assembler for >> multiply_64_x_64_loop(). Extend comments. >> I think in next comments x_xstart should be used on left side instead of >> 'product': > > Yes. > >> + umulh(rscratch1, x_xstart, y_idx); // product * y_idx -> >> rscratch1:product >> + mul(product, x_xstart, y_idx); >> + adds(product, product, carry); >> + adc(carry, rscratch1, zr); // product * y_idx + carry -> carry:product >> >> Also why not use BytesPerLong instead of BytesPerWord?: > > OK. > > Also, I did a new merge and the port no longer built: > > /local/aarch64/dev/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp:61:16: error: 'virtual void MacroAssembler::call_VM_leaf_base(address, int, Label&)' was hidden [-Werror=overloaded-virtual] > VIRTUAL void call_VM_leaf_base( > ^ > This is a correct warning message, so I added a using directive to clarify > the intent. > > http://cr.openjdk.java.net/~aph/8077615-1/ > > Andrew. > From aph at redhat.com Tue Apr 14 17:41:20 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Apr 2015 18:41:20 +0100 Subject: RFR: 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method In-Reply-To: <552D4CC9.6010204@oracle.com> References: <552C0456.1040602@redhat.com> <552C04A0.3060906@redhat.com> <552C0BA6.2050609@oracle.com> <552CE3D7.4090608@redhat.com> <552D4CC9.6010204@oracle.com> Message-ID: <552D5140.1060205@redhat.com> On 04/14/2015 06:22 PM, Vladimir Kozlov wrote: > We are discussing how and which checks to add into java code which > calls intrinsified methods to keep intrinsic simple. Yes, good idea. While you're in there, there's a couple of thoughts I'd like to draw your attention to. Montgomery multiplication and squaring are implemented as separate steps, like so: a = multiplyToLen(t, modLen, mult, modLen, a); a = montReduce(a, mod, modLen, inv); a = squareToLen(t, modLen, a); a = montReduce(a, mod, modLen, inv); It is possible to interleave the multiplication and Montgomery reduction, and this can lead to a useful speedup on some architectures. It would be nice if Montgomery multiplication and squaring were factored into separate methods, and then they could be replaced by intrinsics. Also, all these word-reversal and misaligned long stores / loads in the multiplyToLen intrinsic code are a real PITA. If we word-reversed the arrays so that they were in little-endian form we'd have neither misaligned long stores / loads nor repeated word-reversals. We could do the word reversal on the stack: AFAICS it's unusual for multiplyToLen to be called for huge bignums, and I suppose if it did happen for a bignum larger than some threshold we could do the word reversal on the heap. Andrew. From vladimir.kozlov at oracle.com Tue Apr 14 17:58:07 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Apr 2015 10:58:07 -0700 Subject: RFR: 8069539: RSA acceleration In-Reply-To: <552D5140.1060205@redhat.com> References: <552C0456.1040602@redhat.com> <552C04A0.3060906@redhat.com> <552C0BA6.2050609@oracle.com> <552CE3D7.4090608@redhat.com> <552D4CC9.6010204@oracle.com> <552D5140.1060205@redhat.com> Message-ID: <552D552F.9030201@oracle.com> Thank you, Andrew, for suggestions. Vladimir On 4/14/15 10:41 AM, Andrew Haley wrote: > On 04/14/2015 06:22 PM, Vladimir Kozlov wrote: > >> We are discussing how and which checks to add into java code which >> calls intrinsified methods to keep intrinsic simple. > > Yes, good idea. While you're in there, there's a couple of thoughts I'd > like to draw your attention to. > > Montgomery multiplication and squaring are implemented as separate > steps, like so: > > a = multiplyToLen(t, modLen, mult, modLen, a); > a = montReduce(a, mod, modLen, inv); > > a = squareToLen(t, modLen, a); > a = montReduce(a, mod, modLen, inv); > > It is possible to interleave the multiplication and Montgomery > reduction, and this can lead to a useful speedup on some > architectures. It would be nice if Montgomery multiplication and > squaring were factored into separate methods, and then they could be > replaced by intrinsics. > > Also, all these word-reversal and misaligned long stores / loads in > the multiplyToLen intrinsic code are a real PITA. If we word-reversed > the arrays so that they were in little-endian form we'd have neither > misaligned long stores / loads nor repeated word-reversals. We could > do the word reversal on the stack: AFAICS it's unusual for > multiplyToLen to be called for huge bignums, and I suppose if it did > happen for a bignum larger than some threshold we could do the word > reversal on the heap. > > Andrew. > From igor.veresov at oracle.com Tue Apr 14 18:43:14 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 14 Apr 2015 11:43:14 -0700 Subject: [8u] backport of 8076968 and 8062591 Message-ID: I?d like to backport: 8062591: SPARC PICL causes significantly longer startup times JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/aedfc7337448 JBS: https://bugs.openjdk.java.net/browse/JDK-8062591 8076968: PICL based initialization of L2 cache line size on some SPARC systems is incorrect JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/7ac058b59e10 JBS: https://bugs.openjdk.java.net/browse/JDK-8076968 The changes required a little bit of tweaking compared to jdk9, but nothing significant. The reason I want to backport 8062591 is to make 8076968 apply cleanly since it touches the same code. Thanks! igor From vladimir.kozlov at oracle.com Tue Apr 14 19:37:23 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Apr 2015 12:37:23 -0700 Subject: [8u] backport of 8076968 and 8062591 In-Reply-To: References: Message-ID: <552D6C73.3010106@oracle.com> Okay. Thanks, Vladimir On 4/14/15 11:43 AM, Igor Veresov wrote: > I?d like to backport: > > 8062591: SPARC PICL causes significantly longer startup times > JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/aedfc7337448 > JBS: https://bugs.openjdk.java.net/browse/JDK-8062591 > > 8076968: PICL based initialization of L2 cache line size on some SPARC systems is incorrect > JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/7ac058b59e10 > JBS: https://bugs.openjdk.java.net/browse/JDK-8076968 > > > The changes required a little bit of tweaking compared to jdk9, but nothing significant. > The reason I want to backport 8062591 is to make 8076968 apply cleanly since it touches the same code. > > > Thanks! > igor > From igor.veresov at oracle.com Tue Apr 14 19:39:35 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 14 Apr 2015 12:39:35 -0700 Subject: [8u] backport of 8076968 and 8062591 In-Reply-To: <552D6C73.3010106@oracle.com> References: <552D6C73.3010106@oracle.com> Message-ID: <2300BCE6-7A4F-4AEE-8447-F7D9581A42BB@oracle.com> Thanks, Vladimir! igor > On Apr 14, 2015, at 12:37 PM, Vladimir Kozlov wrote: > > Okay. > > Thanks, > Vladimir > > On 4/14/15 11:43 AM, Igor Veresov wrote: >> I?d like to backport: >> >> 8062591: SPARC PICL causes significantly longer startup times >> JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/aedfc7337448 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8062591 >> >> 8076968: PICL based initialization of L2 cache line size on some SPARC systems is incorrect >> JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/7ac058b59e10 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8076968 >> >> >> The changes required a little bit of tweaking compared to jdk9, but nothing significant. >> The reason I want to backport 8062591 is to make 8076968 apply cleanly since it touches the same code. >> >> >> Thanks! >> igor >> From serguei.spitsyn at oracle.com Wed Apr 15 01:06:46 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Apr 2015 18:06:46 -0700 Subject: HotSpot workflow In-Reply-To: <552D4178.9080508@oracle.com> References: <552D076C.20500@redhat.com> <552D4178.9080508@oracle.com> Message-ID: <552DB9A6.4010703@oracle.com> Just to share in hope, someone will find it useful. :) I normally do not use the mq extension and hg merge. My approach is similar to what Dmitry does: - keep one repository for one bug fix - do not commit until the fix is ready for a jprt push - save the current patch with: % hg diff > ../1.patch - to pull the updates: % hg revert -a % hg import ../1.patch - commit before the jprt push - if a conflicting fix discovered in the parent repo just before my jprt push: % hg rollback % hg diff > ../1.patch % hg revert -a % hg pull % hg import ../1.patch % hg commit % The above is a little bit manual but simple and always works like a charm. Thanks, Serguei On 4/14/15 9:34 AM, Dmitry Samersoff wrote: > Andrew, > > I'm the rare person in JDK who doesn't adopt mq ;) > > Below is my workflow: > > Typically I have about five-six-ten CRs "in progress" in my pile. > > It's critical for me to have stable basement for the changes, so I > create a separate folder for each problem, clone workspaces there and > don't update it until the fix become complete. > Right before push I merge my changes into the recent codebase and repeat > all tests. > > I use hg TAG to mark a start of my work, than keep committing changes as > necessary (hg ci, hg rollback etc) and at final stage just get a diff > between the first and the last changeset using plain hg diff and apply > this patch to fresh workspace. > > -Dmitry > > > > On 2015-04-14 15:26, Andrew Haley wrote: >> I'm having some practical problems with the HotSpot workflow. >> >> I usually have several patches on the fly at any time, but webrev and >> Mercurial don't really help. "hg push" and "hg merge" work on the >> whole repo, not just a changeset, so I've been manually saving >> changesets and re-merging them into the master tree, which is very >> error-prone and has led to some mistakes submitting changes. >> >> Also, the need to submit a change as a single changeset makes it >> awkward to commit regularly as I work on a patch; I can't find any way >> to merge a set of changes into a single changeset and push that. >> >> So, what do you do? Do you keep a source tree checked out for every >> webrev? Do you regularly commit as you work? Am I missing >> some tricks? >> >> Thanks, >> Andrew. >> > From ioi.lam at oracle.com Wed Apr 15 01:34:16 2015 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Tue, 14 Apr 2015 18:34:16 -0700 Subject: HotSpot workflow In-Reply-To: <552DB9A6.4010703@oracle.com> References: <552D076C.20500@redhat.com> <552D4178.9080508@oracle.com> <552DB9A6.4010703@oracle.com> Message-ID: I usually keep each change in its own repo, and use mq to keep track of my changes. When I need to sync down, I would use the rebase extension to make sure my changes are always sitting at the tip of the tree, without any merge change sets. The problem with merge change sets is I can never understand what's in them. I.e. What's changed by me and what's changes by others. They are good for the computer to produce the right output. They are horrible for a human to understand what's changed. > On Apr 14, 2015, at 6:06 PM, "serguei.spitsyn at oracle.com" wrote: > > Just to share in hope, someone will find it useful. :) > I normally do not use the mq extension and hg merge. > > My approach is similar to what Dmitry does: > - keep one repository for one bug fix > - do not commit until the fix is ready for a jprt push > - save the current patch with: > % hg diff > ../1.patch > - to pull the updates: > % hg revert -a > > % hg import ../1.patch > - commit before the jprt push > - if a conflicting fix discovered in the parent repo just before my jprt push: > % hg rollback > % hg diff > ../1.patch > % hg revert -a > % hg pull > % hg import ../1.patch > % hg commit > % > > > The above is a little bit manual but simple and always works like a charm. > > Thanks, > Serguei > > >> On 4/14/15 9:34 AM, Dmitry Samersoff wrote: >> Andrew, >> >> I'm the rare person in JDK who doesn't adopt mq ;) >> >> Below is my workflow: >> >> Typically I have about five-six-ten CRs "in progress" in my pile. >> >> It's critical for me to have stable basement for the changes, so I >> create a separate folder for each problem, clone workspaces there and >> don't update it until the fix become complete. >> Right before push I merge my changes into the recent codebase and repeat >> all tests. >> >> I use hg TAG to mark a start of my work, than keep committing changes as >> necessary (hg ci, hg rollback etc) and at final stage just get a diff >> between the first and the last changeset using plain hg diff and apply >> this patch to fresh workspace. >> >> -Dmitry >> >> >> >>> On 2015-04-14 15:26, Andrew Haley wrote: >>> I'm having some practical problems with the HotSpot workflow. >>> >>> I usually have several patches on the fly at any time, but webrev and >>> Mercurial don't really help. "hg push" and "hg merge" work on the >>> whole repo, not just a changeset, so I've been manually saving >>> changesets and re-merging them into the master tree, which is very >>> error-prone and has led to some mistakes submitting changes. >>> >>> Also, the need to submit a change as a single changeset makes it >>> awkward to commit regularly as I work on a patch; I can't find any way >>> to merge a set of changes into a single changeset and push that. >>> >>> So, what do you do? Do you keep a source tree checked out for every >>> webrev? Do you regularly commit as you work? Am I missing >>> some tricks? >>> >>> Thanks, >>> Andrew. > From aph at redhat.com Wed Apr 15 08:01:39 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Apr 2015 09:01:39 +0100 Subject: HotSpot workflow In-Reply-To: <552DB9A6.4010703@oracle.com> References: <552D076C.20500@redhat.com> <552D4178.9080508@oracle.com> <552DB9A6.4010703@oracle.com> Message-ID: <552E1AE3.2060708@redhat.com> On 15/04/15 02:06, serguei.spitsyn at oracle.com wrote: > My approach is similar to what Dmitry does: > - keep one repository for one bug fix > - do not commit until the fix is ready for a jprt push Umm, but does that mean you aren't using hg during development of a patch? Surely you want to commit regularly, no? Andrew. From roland.westrelin at oracle.com Wed Apr 15 10:25:52 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 15 Apr 2015 12:25:52 +0200 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> Message-ID: <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> Hi Vitaly, > Just a couple of notes in passing. > > 1) may be worthwhile to compute mid in a way that avoids possible signed overflow? I'm guessing this class is not used with sizes that large, but just a precaution. > > 2) perhaps store the result of calling f() in a local to avoid calling it twice? Thanks for the suggestions. Here is a new webrev that take them into account: http://cr.openjdk.java.net/~roland/8007986/webrev.01/ Roland. > > $.02 > > sent from my phone > > On Mar 26, 2015 9:34 AM, "Roland Westrelin" wrote: > http://cr.openjdk.java.net/~roland/8007986/webrev.00/ > > The same binary search code on GrowableArray is used in 3 places (in the compilers). This moves that code in GrowableArray. > > Roland. From stefan.karlsson at oracle.com Wed Apr 15 10:49:00 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Apr 2015 12:49:00 +0200 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return Message-ID: <552E421C.1010105@oracle.com> Hi, Today the it's possible for the code to return out from ShouldNotReachHere() calls. This sometimes forces us to add return statements and assignments to parts of the code where it they don't make sense. By telling the compiler that ShouldNotReachHere is a dead end, we can get rid of these unnecessary constructs. For example: 1) We could get rid of return statements after ShouldNotReachHere(): bool is_marked() { // actual code here // Execution path that "should not" happen. ShouldNotReachHere(); return false; } 2) The following code will actually use an uninitialized value today. The compiler will find this if we turn on -Wuninitialized. But if we change ShouldNotReachHere() to not return, the compiler will stop complaining because report(type) will never be called with an uninitialized value: int type; switch (value) { case TYPE_OOP: type = 0; break; case TYPE_KLASS: type = 1; break; default: ShouldNotReachHere(); } report(type) The patch changes the following functions and defines to never return: - fatal(...) - ShouldNotCallThis() - ShouldNotReachHere() - report_vm_out_of_memory(...) - vm_exit_out_of_memory(...) but leaves the following unchanged: - Unimplemented() - Untested(...) - guarantee(...) We might want to change the the behavior of Unimplemented() and Untested(...), but they are used a lot in compiler code, so I've not changed them for this patch. There has been request to leave guarantee(...) unchanged so that they can be turned off in production code. I had to change some instance of ShouldNotReachHere() in destructors, because the VS C++ compiler complained about potential memory leaks. http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8065585 Thanks, StefanK From serguei.spitsyn at oracle.com Wed Apr 15 10:49:18 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Apr 2015 03:49:18 -0700 Subject: HotSpot workflow In-Reply-To: <552E1AE3.2060708@redhat.com> References: <552D076C.20500@redhat.com> <552D4178.9080508@oracle.com> <552DB9A6.4010703@oracle.com> <552E1AE3.2060708@redhat.com> Message-ID: <552E422E.60300@oracle.com> On 4/15/15 1:01 AM, Andrew Haley wrote: > On 15/04/15 02:06, serguei.spitsyn at oracle.com wrote: >> My approach is similar to what Dmitry does: >> - keep one repository for one bug fix >> - do not commit until the fix is ready for a jprt push > Umm, but does that mean you aren't using hg during development of > a patch? Surely you want to commit regularly, no? In my case, there is no point to commit until the reviewers approve the push. And there is no big advantage to accumulate multiple fixes for one push but I understand that can be useful if a development is in active stage. Thanks, Serguei > > Andrew. > From aph at redhat.com Wed Apr 15 10:51:05 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Apr 2015 11:51:05 +0100 Subject: HotSpot workflow In-Reply-To: <552E422E.60300@oracle.com> References: <552D076C.20500@redhat.com> <552D4178.9080508@oracle.com> <552DB9A6.4010703@oracle.com> <552E1AE3.2060708@redhat.com> <552E422E.60300@oracle.com> Message-ID: <552E4299.8060803@redhat.com> On 04/15/2015 11:49 AM, serguei.spitsyn at oracle.com wrote: > On 4/15/15 1:01 AM, Andrew Haley wrote: >> On 15/04/15 02:06, serguei.spitsyn at oracle.com wrote: >>> My approach is similar to what Dmitry does: >>> - keep one repository for one bug fix >>> - do not commit until the fix is ready for a jprt push >> Umm, but does that mean you aren't using hg during development of >> a patch? Surely you want to commit regularly, no? > > In my case, there is no point to commit until the reviewers approve the > push. Oh, right. I use version control so that I can revert when I make a mess. Perhaps I could make messes less often. :-) Thanks, Andrew. From dmitry.samersoff at oracle.com Wed Apr 15 11:33:01 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Apr 2015 14:33:01 +0300 Subject: HotSpot workflow In-Reply-To: <552E1AE3.2060708@redhat.com> References: <552D076C.20500@redhat.com> <552D4178.9080508@oracle.com> <552DB9A6.4010703@oracle.com> <552E1AE3.2060708@redhat.com> Message-ID: <552E4C6D.1020602@oracle.com> On 2015-04-15 11:01, Andrew Haley wrote: > On 15/04/15 02:06, serguei.spitsyn at oracle.com wrote: >> My approach is similar to what Dmitry does: >> - keep one repository for one bug fix >> - do not commit until the fix is ready for a jprt push > > Umm, but does that mean you aren't using hg during development of > a patch? Surely you want to commit regularly, no? Personally, I commit my changes regularly during development. It enforces me to use antideltas if I have to backout part of my changes but it's not a big pain in reality. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From per.liden at oracle.com Wed Apr 15 12:09:36 2015 From: per.liden at oracle.com (Per Liden) Date: Wed, 15 Apr 2015 14:09:36 +0200 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552E421C.1010105@oracle.com> References: <552E421C.1010105@oracle.com> Message-ID: <552E5500.7020801@oracle.com> Hi Stefan, Nice cleanup! Some comments below. On 2015-04-15 12:49, Stefan Karlsson wrote: > Hi, > > Today the it's possible for the code to return out from > ShouldNotReachHere() calls. This sometimes forces us to add return > statements and assignments to parts of the code where it they don't make > sense. By telling the compiler that ShouldNotReachHere is a dead end, we > can get rid of these unnecessary constructs. > > For example: > > 1) We could get rid of return statements after ShouldNotReachHere(): > > bool is_marked() { > // actual code here > > // Execution path that "should not" happen. > ShouldNotReachHere(); > return false; > } > > 2) The following code will actually use an uninitialized value today. > The compiler will find this if we turn on -Wuninitialized. But if we > change ShouldNotReachHere() to not return, the compiler will stop > complaining because report(type) will never be called with an > uninitialized value: > > int type; > switch (value) { > case TYPE_OOP: type = 0; break; > case TYPE_KLASS: type = 1; break; > default: ShouldNotReachHere(); > } > report(type) > > > The patch changes the following functions and defines to never return: > - fatal(...) > - ShouldNotCallThis() > - ShouldNotReachHere() > - report_vm_out_of_memory(...) > - vm_exit_out_of_memory(...) > > but leaves the following unchanged: > - Unimplemented() > - Untested(...) > - guarantee(...) > > We might want to change the the behavior of Unimplemented() and > Untested(...), but they are used a lot in compiler code, so I've not > changed them for this patch. There has been request to leave > guarantee(...) unchanged so that they can be turned off in production code. guarantee() should not have this attribute as it should be able to return. > > I had to change some instance of ShouldNotReachHere() in destructors, > because the VS C++ compiler complained about potential memory leaks. > > http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8065585 Looks good, just a few minor suggestions: - NORETURN_ATTRIBUTE -> ATTRIBUTE_NORETURN, to better match the existing ATTRIBUTE_PRINTF? - Make noreturn_function() static and move it into debug.cpp? cheers, /Per From goetz.lindenmaier at sap.com Wed Apr 15 13:08:42 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 15 Apr 2015 13:08:42 +0000 Subject: RFR(S): 8077843: adlc: allow nodes that use TEMP inputs in expand rules. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBEEE0@DEWDFEMB12A.global.corp.sap> Hi, I have a tiny fix that allows nodes that use TEMP inputs / TEMP effect in expand rules. Currently an assertion fires if you do so. This is harmless, though, as the TEMP node is added in the Expand() of the used node, which is called by the Expand() of the node being expanded. Probably the assertion was meant for the node being expanded. The change simply removed the assertion. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8077843-adlcTEMP/webrev.01/ I need this feature for a change I intend to do in the ppc.ad file. Best regards, Goetz. From max.ockner at oracle.com Wed Apr 15 13:50:04 2015 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 15 Apr 2015 09:50:04 -0400 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <552C49B8.9070805@oracle.com> References: <551D9AC6.50208@oracle.com> <55232E90.7060701@oracle.com> <5526CEDF.20004@oracle.com> <55272BDA.2060908@oracle.com> <552C262A.1070002@oracle.com> <552C49B8.9070805@oracle.com> Message-ID: <552E6C8C.3050607@oracle.com> I had a few things mixed up in the last webrev. Either way, I have changed this, hopefully for the last time. vmError.cpp now uses INTPTR_FORMAT. webrev: http://cr.openjdk.java.net/~mockner/8029630.final/ tested with jprt. Thanks, Max On 4/13/2015 6:56 PM, David Holmes wrote: > Hi Max, > > On 14/04/2015 6:25 AM, Max Ockner wrote: >> Hello, >> >> Modified this again. I defined TID_FORMAT to make it a better semantic >> match. > > Not sure that actually improves anything. There is no "tid" type. > Primarily what we have is a function returning intx and we want to > print it as hex. I still think INTPTR_FORMAT suffices. Otherwise > INTX_HEX_FORMAT is you really want to introduce something new - but I > don't suggest doing that. > >> Webrev: http://cr.openjdk.java.net/~mockner/8029630.8/ > > I still see vmError.cpp using PTR_FORMAT ?? > > Sorry. > > David > >> Tested with jprt >> >> Thanks, >> Max >> >> On 4/9/2015 9:48 PM, David Holmes wrote: >>> Hi Max, >>> >>> On 10/04/2015 5:11 AM, Max Ockner wrote: >>>> Hi again, >>>> After working past some build issues, I have a new webrev. I've >>>> changed >>>> %x to PTR_FORMAT, and I've removed the modification to thread.cpp >>>> >>>> New webrev: http://cr.openjdk.java.net/~mockner/8029630.4/ >>> >>> I think INTPTR_FORMAT would be more of a semantic match as the thread >>> id is not a pointer type. >>> >>> David >>> >>>> Thanks, >>>> Max >>>> >>>> On 4/6/2015 9:10 PM, David Holmes wrote: >>>>> Hi Max, >>>>> >>>>> On 3/04/2015 5:38 AM, Max Ockner wrote: >>>>>> Hello, >>>>>> Please review this change: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >>>>>> Summary: Existing error messages for vm crashes print the decimal >>>>>> representation of the current thread id. The message format has been >>>>>> changed to print the hex value of the thread id. >>>>> >>>>> src/share/vm/runtime/thread.cpp >>>>> >>>>> The change is incorrect and unnecessary. 'this' is a pointer type so >>>>> INTPTR_FORMAT seems correct (though it may need p2i(this)?) while %x >>>>> assumes 'this' is always 32-bit. Further INTPTR_FORMAT is already hex >>>>> not decimal. >>>>> >>>>> src/share/vm/utilities/vmError.cpp >>>>> >>>>> As Thomas pointed out%x assumes 32-bit and so is incorrect for intx >>>>> type. As intx is a typedef for intptr_t then INTPTR_FORMAT should be >>>>> usable here as well. >>>>> >>>>> David >>>>> >>>>>> Tested with jtreg runtime to make sure nothing was broken. I tested >>>>>> the >>>>>> new functionality separately. I crashed the vm and examined the >>>>>> debugger >>>>>> output to make sure the hexadecimal thread id printed in the error >>>>>> message matched one of the threads listed by the debugger. >>>>>> >>>>>> Thanks, >>>>>> Max >>>> >> From stefan.karlsson at oracle.com Wed Apr 15 14:30:30 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Apr 2015 16:30:30 +0200 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552E5500.7020801@oracle.com> References: <552E421C.1010105@oracle.com> <552E5500.7020801@oracle.com> Message-ID: <552E7606.2080506@oracle.com> On 2015-04-15 14:09, Per Liden wrote: > Hi Stefan, > > Nice cleanup! Thanks, Per. > Some comments below. > > On 2015-04-15 12:49, Stefan Karlsson wrote: >> Hi, >> >> Today the it's possible for the code to return out from >> ShouldNotReachHere() calls. This sometimes forces us to add return >> statements and assignments to parts of the code where it they don't make >> sense. By telling the compiler that ShouldNotReachHere is a dead end, we >> can get rid of these unnecessary constructs. >> >> For example: >> >> 1) We could get rid of return statements after ShouldNotReachHere(): >> >> bool is_marked() { >> // actual code here >> >> // Execution path that "should not" happen. >> ShouldNotReachHere(); >> return false; >> } >> >> 2) The following code will actually use an uninitialized value today. >> The compiler will find this if we turn on -Wuninitialized. But if we >> change ShouldNotReachHere() to not return, the compiler will stop >> complaining because report(type) will never be called with an >> uninitialized value: >> >> int type; >> switch (value) { >> case TYPE_OOP: type = 0; break; >> case TYPE_KLASS: type = 1; break; >> default: ShouldNotReachHere(); >> } >> report(type) >> >> >> The patch changes the following functions and defines to never return: >> - fatal(...) >> - ShouldNotCallThis() >> - ShouldNotReachHere() >> - report_vm_out_of_memory(...) >> - vm_exit_out_of_memory(...) >> >> but leaves the following unchanged: >> - Unimplemented() >> - Untested(...) >> - guarantee(...) >> >> We might want to change the the behavior of Unimplemented() and >> Untested(...), but they are used a lot in compiler code, so I've not >> changed them for this patch. There has been request to leave >> guarantee(...) unchanged so that they can be turned off in production >> code. > > guarantee() should not have this attribute as it should be able to > return. Of course. > >> >> I had to change some instance of ShouldNotReachHere() in destructors, >> because the VS C++ compiler complained about potential memory leaks. >> >> http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8065585 > > Looks good, just a few minor suggestions: > > - NORETURN_ATTRIBUTE -> ATTRIBUTE_NORETURN, to better match the > existing ATTRIBUTE_PRINTF? I've gone with your suggestion to rename the define and get rid of the macro function parameter. > > - Make noreturn_function() static and move it into debug.cpp? Done. http://cr.openjdk.java.net/~stefank/8065585/webrev.02.delta/ http://cr.openjdk.java.net/~stefank/8065585/webrev.02/ Thanks, StefanK > > cheers, > /Per From per.liden at oracle.com Wed Apr 15 14:36:25 2015 From: per.liden at oracle.com (Per Liden) Date: Wed, 15 Apr 2015 16:36:25 +0200 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552E7606.2080506@oracle.com> References: <552E421C.1010105@oracle.com> <552E5500.7020801@oracle.com> <552E7606.2080506@oracle.com> Message-ID: <552E7769.5040806@oracle.com> Hi Stefan, On 2015-04-15 16:30, Stefan Karlsson wrote: > On 2015-04-15 14:09, Per Liden wrote: >> Hi Stefan, >> >> Nice cleanup! > > Thanks, Per. > >> Some comments below. >> >> On 2015-04-15 12:49, Stefan Karlsson wrote: >>> Hi, >>> >>> Today the it's possible for the code to return out from >>> ShouldNotReachHere() calls. This sometimes forces us to add return >>> statements and assignments to parts of the code where it they don't make >>> sense. By telling the compiler that ShouldNotReachHere is a dead end, we >>> can get rid of these unnecessary constructs. >>> >>> For example: >>> >>> 1) We could get rid of return statements after ShouldNotReachHere(): >>> >>> bool is_marked() { >>> // actual code here >>> >>> // Execution path that "should not" happen. >>> ShouldNotReachHere(); >>> return false; >>> } >>> >>> 2) The following code will actually use an uninitialized value today. >>> The compiler will find this if we turn on -Wuninitialized. But if we >>> change ShouldNotReachHere() to not return, the compiler will stop >>> complaining because report(type) will never be called with an >>> uninitialized value: >>> >>> int type; >>> switch (value) { >>> case TYPE_OOP: type = 0; break; >>> case TYPE_KLASS: type = 1; break; >>> default: ShouldNotReachHere(); >>> } >>> report(type) >>> >>> >>> The patch changes the following functions and defines to never return: >>> - fatal(...) >>> - ShouldNotCallThis() >>> - ShouldNotReachHere() >>> - report_vm_out_of_memory(...) >>> - vm_exit_out_of_memory(...) >>> >>> but leaves the following unchanged: >>> - Unimplemented() >>> - Untested(...) >>> - guarantee(...) >>> >>> We might want to change the the behavior of Unimplemented() and >>> Untested(...), but they are used a lot in compiler code, so I've not >>> changed them for this patch. There has been request to leave >>> guarantee(...) unchanged so that they can be turned off in production >>> code. >> >> guarantee() should not have this attribute as it should be able to >> return. > > Of course. > >> >>> >>> I had to change some instance of ShouldNotReachHere() in destructors, >>> because the VS C++ compiler complained about potential memory leaks. >>> >>> http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8065585 >> >> Looks good, just a few minor suggestions: >> >> - NORETURN_ATTRIBUTE -> ATTRIBUTE_NORETURN, to better match the >> existing ATTRIBUTE_PRINTF? > > I've gone with your suggestion to rename the define and get rid of the > macro function parameter. > > >> >> - Make noreturn_function() static and move it into debug.cpp? > > Done. > > http://cr.openjdk.java.net/~stefank/8065585/webrev.02.delta/ > http://cr.openjdk.java.net/~stefank/8065585/webrev.02/ Looks good! /Per From stefan.karlsson at oracle.com Wed Apr 15 14:37:05 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Apr 2015 16:37:05 +0200 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552E7769.5040806@oracle.com> References: <552E421C.1010105@oracle.com> <552E5500.7020801@oracle.com> <552E7606.2080506@oracle.com> <552E7769.5040806@oracle.com> Message-ID: <552E7791.7060105@oracle.com> On 2015-04-15 16:36, Per Liden wrote: > Hi Stefan, > > On 2015-04-15 16:30, Stefan Karlsson wrote: >> On 2015-04-15 14:09, Per Liden wrote: >>> Hi Stefan, >>> >>> Nice cleanup! >> >> Thanks, Per. >> >>> Some comments below. >>> >>> On 2015-04-15 12:49, Stefan Karlsson wrote: >>>> Hi, >>>> >>>> Today the it's possible for the code to return out from >>>> ShouldNotReachHere() calls. This sometimes forces us to add return >>>> statements and assignments to parts of the code where it they don't >>>> make >>>> sense. By telling the compiler that ShouldNotReachHere is a dead >>>> end, we >>>> can get rid of these unnecessary constructs. >>>> >>>> For example: >>>> >>>> 1) We could get rid of return statements after ShouldNotReachHere(): >>>> >>>> bool is_marked() { >>>> // actual code here >>>> >>>> // Execution path that "should not" happen. >>>> ShouldNotReachHere(); >>>> return false; >>>> } >>>> >>>> 2) The following code will actually use an uninitialized value today. >>>> The compiler will find this if we turn on -Wuninitialized. But if we >>>> change ShouldNotReachHere() to not return, the compiler will stop >>>> complaining because report(type) will never be called with an >>>> uninitialized value: >>>> >>>> int type; >>>> switch (value) { >>>> case TYPE_OOP: type = 0; break; >>>> case TYPE_KLASS: type = 1; break; >>>> default: ShouldNotReachHere(); >>>> } >>>> report(type) >>>> >>>> >>>> The patch changes the following functions and defines to never return: >>>> - fatal(...) >>>> - ShouldNotCallThis() >>>> - ShouldNotReachHere() >>>> - report_vm_out_of_memory(...) >>>> - vm_exit_out_of_memory(...) >>>> >>>> but leaves the following unchanged: >>>> - Unimplemented() >>>> - Untested(...) >>>> - guarantee(...) >>>> >>>> We might want to change the the behavior of Unimplemented() and >>>> Untested(...), but they are used a lot in compiler code, so I've not >>>> changed them for this patch. There has been request to leave >>>> guarantee(...) unchanged so that they can be turned off in production >>>> code. >>> >>> guarantee() should not have this attribute as it should be able to >>> return. >> >> Of course. >> >>> >>>> >>>> I had to change some instance of ShouldNotReachHere() in destructors, >>>> because the VS C++ compiler complained about potential memory leaks. >>>> >>>> http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8065585 >>> >>> Looks good, just a few minor suggestions: >>> >>> - NORETURN_ATTRIBUTE -> ATTRIBUTE_NORETURN, to better match the >>> existing ATTRIBUTE_PRINTF? >> >> I've gone with your suggestion to rename the define and get rid of the >> macro function parameter. >> >> >>> >>> - Make noreturn_function() static and move it into debug.cpp? >> >> Done. >> >> http://cr.openjdk.java.net/~stefank/8065585/webrev.02.delta/ >> http://cr.openjdk.java.net/~stefank/8065585/webrev.02/ > > Looks good! Thanks! StefanK > > /Per From vitalyd at gmail.com Wed Apr 15 14:52:22 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 15 Apr 2015 10:52:22 -0400 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> Message-ID: Hi Roland, int mid = (int)((uint)max + min) / 2; I'd write this as: int mid = min + (max - min) / 2; I'd change these: assert(min >= 0 && (max+1) >= min, "bad bounds");assert((uint)min <= length() && (uint)(max+1) <= length(), "incorrect bounds"); to: assert(min >= 0 && (max - min) >= 0, "bad bounds"); assert(min <= length() && (length() - max) > 0, "incorrect bounds"); This is pedantic so please feel free to ignore if you think it's not worthwhile. Thanks On Wed, Apr 15, 2015 at 6:25 AM, Roland Westrelin < roland.westrelin at oracle.com> wrote: > Hi Vitaly, > > > Just a couple of notes in passing. > > > > 1) may be worthwhile to compute mid in a way that avoids possible signed > overflow? I'm guessing this class is not used with sizes that large, but > just a precaution. > > > > 2) perhaps store the result of calling f() in a local to avoid calling > it twice? > > Thanks for the suggestions. Here is a new webrev that take them into > account: > > http://cr.openjdk.java.net/~roland/8007986/webrev.01/ > > Roland. > > > > > $.02 > > > > sent from my phone > > > > On Mar 26, 2015 9:34 AM, "Roland Westrelin" > wrote: > > http://cr.openjdk.java.net/~roland/8007986/webrev.00/ > > > > The same binary search code on GrowableArray is used in 3 places (in the > compilers). This moves that code in GrowableArray. > > > > Roland. > > From goetz.lindenmaier at sap.com Wed Apr 15 14:54:28 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 15 Apr 2015 14:54:28 +0000 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552E421C.1010105@oracle.com> References: <552E421C.1010105@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> Hi Stefan, Thanks for doing this fix, I would appreciate this cleanup a lot. I just built it on aix. So far, the attribute unfortunately does not suppress the warnings. I'll investgate this some more ... Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Stefan Karlsson Sent: Mittwoch, 15. April 2015 12:49 To: hotspot-dev Source Developers Subject: RFR: 8065585: Change ShouldNotReachHere() to never return Hi, Today the it's possible for the code to return out from ShouldNotReachHere() calls. This sometimes forces us to add return statements and assignments to parts of the code where it they don't make sense. By telling the compiler that ShouldNotReachHere is a dead end, we can get rid of these unnecessary constructs. For example: 1) We could get rid of return statements after ShouldNotReachHere(): bool is_marked() { // actual code here // Execution path that "should not" happen. ShouldNotReachHere(); return false; } 2) The following code will actually use an uninitialized value today. The compiler will find this if we turn on -Wuninitialized. But if we change ShouldNotReachHere() to not return, the compiler will stop complaining because report(type) will never be called with an uninitialized value: int type; switch (value) { case TYPE_OOP: type = 0; break; case TYPE_KLASS: type = 1; break; default: ShouldNotReachHere(); } report(type) The patch changes the following functions and defines to never return: - fatal(...) - ShouldNotCallThis() - ShouldNotReachHere() - report_vm_out_of_memory(...) - vm_exit_out_of_memory(...) but leaves the following unchanged: - Unimplemented() - Untested(...) - guarantee(...) We might want to change the the behavior of Unimplemented() and Untested(...), but they are used a lot in compiler code, so I've not changed them for this patch. There has been request to leave guarantee(...) unchanged so that they can be turned off in production code. I had to change some instance of ShouldNotReachHere() in destructors, because the VS C++ compiler complained about potential memory leaks. http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8065585 Thanks, StefanK From stefan.karlsson at oracle.com Wed Apr 15 14:58:49 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Apr 2015 16:58:49 +0200 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> Message-ID: <552E7CA9.5020901@oracle.com> Hi Goetz, On 2015-04-15 16:54, Lindenmaier, Goetz wrote: > Hi Stefan, > > Thanks for doing this fix, I would appreciate this cleanup a lot. > I just built it on aix. So far, the attribute unfortunately does not > suppress the warnings. I'll investgate this some more ... Thanks for verifying the patch. What warnings are you getting? Are you running with -Wuninitialized? Thanks, StefanK > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Stefan Karlsson > Sent: Mittwoch, 15. April 2015 12:49 > To: hotspot-dev Source Developers > Subject: RFR: 8065585: Change ShouldNotReachHere() to never return > > Hi, > > Today the it's possible for the code to return out from > ShouldNotReachHere() calls. This sometimes forces us to add return > statements and assignments to parts of the code where it they don't make > sense. By telling the compiler that ShouldNotReachHere is a dead end, we > can get rid of these unnecessary constructs. > > For example: > > 1) We could get rid of return statements after ShouldNotReachHere(): > > bool is_marked() { > // actual code here > > // Execution path that "should not" happen. > ShouldNotReachHere(); > return false; > } > > 2) The following code will actually use an uninitialized value today. > The compiler will find this if we turn on -Wuninitialized. But if we > change ShouldNotReachHere() to not return, the compiler will stop > complaining because report(type) will never be called with an > uninitialized value: > > int type; > switch (value) { > case TYPE_OOP: type = 0; break; > case TYPE_KLASS: type = 1; break; > default: ShouldNotReachHere(); > } > report(type) > > > The patch changes the following functions and defines to never return: > - fatal(...) > - ShouldNotCallThis() > - ShouldNotReachHere() > - report_vm_out_of_memory(...) > - vm_exit_out_of_memory(...) > > but leaves the following unchanged: > - Unimplemented() > - Untested(...) > - guarantee(...) > > We might want to change the the behavior of Unimplemented() and > Untested(...), but they are used a lot in compiler code, so I've not > changed them for this patch. There has been request to leave > guarantee(...) unchanged so that they can be turned off in production code. > > I had to change some instance of ShouldNotReachHere() in destructors, > because the VS C++ compiler complained about potential memory leaks. > > http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8065585 > > Thanks, > StefanK From vitalyd at gmail.com Wed Apr 15 15:10:03 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 15 Apr 2015 11:10:03 -0400 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> Message-ID: Also, if you decide to take my suggestion on calculating mid, probably best to use shift instead of div - I don't think compiler will do that for you unless it proves the signed ints can't be negative. sent from my phone On Apr 15, 2015 10:52 AM, "Vitaly Davidovich" wrote: > Hi Roland, > > int mid = (int)((uint)max + min) / 2; > > I'd write this as: > int mid = min + (max - min) / 2; > > I'd change these: > > assert(min >= 0 && (max+1) >= min, "bad bounds");assert((uint)min <= length() && (uint)(max+1) <= length(), "incorrect bounds"); > > to: > > assert(min >= 0 && (max - min) >= 0, "bad bounds"); > assert(min <= length() && (length() - max) > 0, "incorrect bounds"); > > This is pedantic so please feel free to ignore if you think it's not > worthwhile. > > Thanks > > > On Wed, Apr 15, 2015 at 6:25 AM, Roland Westrelin < > roland.westrelin at oracle.com> wrote: > >> Hi Vitaly, >> >> > Just a couple of notes in passing. >> > >> > 1) may be worthwhile to compute mid in a way that avoids possible >> signed overflow? I'm guessing this class is not used with sizes that large, >> but just a precaution. >> > >> > 2) perhaps store the result of calling f() in a local to avoid calling >> it twice? >> >> Thanks for the suggestions. Here is a new webrev that take them into >> account: >> >> http://cr.openjdk.java.net/~roland/8007986/webrev.01/ >> >> Roland. >> >> > >> > $.02 >> > >> > sent from my phone >> > >> > On Mar 26, 2015 9:34 AM, "Roland Westrelin" < >> roland.westrelin at oracle.com> wrote: >> > http://cr.openjdk.java.net/~roland/8007986/webrev.00/ >> > >> > The same binary search code on GrowableArray is used in 3 places (in >> the compilers). This moves that code in GrowableArray. >> > >> > Roland. >> >> > From bengt.rutisson at oracle.com Wed Apr 15 17:02:11 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 15 Apr 2015 19:02:11 +0200 Subject: RFR (S): JDK-8077873: G1: Remove G1SATBPrintStubs Message-ID: <552E9993.3020904@oracle.com> Hi everyone, Sending this to hotspot-dev since it is a GC change but it touches compiler code in macroAssembler_sparc.cpp. https://bugs.openjdk.java.net/browse/JDK-8077873 http://cr.openjdk.java.net/~brutisso/8077873/webrev.00/ The develop flag G1SATBPrintStubs prints out the generated assembly for the SATB stubs. This is has been around since G1 was integrated in the the hotspot repo. But it was only ever implemented for Sparc and it looks much like debugging code that has just been left in the code base. I have not heard of anyone using this flag lately so rather than generalizing it to all platforms I propose that we remove it. If we need to debug the SATB write barrier generation we can easily add back similar logging. Thanks, Bengt From daniel.smith at oracle.com Wed Apr 15 17:02:04 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 15 Apr 2015 11:02:04 -0600 Subject: Call for Speakers -- 2015 JVM Language Summit Message-ID: CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, AUGUST 2015 We are pleased to announce the 2015 JVM Language Summit to be held at Oracle's Santa Clara campus on August 10-12, 2015. Registration is now open for speaker submissions (presentations and workshops) and will remain open until May 22, 2015. There is no registration fee for speakers. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public via the Oracle Technology Network. This event is being organized by language and JVM engineers; no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 80-100 attendees are expected. As in previous years, we will divide the schedule between traditional presentations and "workshops." Workshops are informal, facilitated discussion groups among smaller, self-selected participants, and should enable deeper "dives" into the subject matter. If there is interest, there will also be impromptu "lightning talks." Traditional presentations (about 7 each day) will be given in a single track, while workshops (2?3 each day) will occur in parallel. Instructions for Speaker Registration If you'd like give a presentation or lead a workshop, please register as a Speaker and include a detailed abstract. There is no fee. You will be notified about whether your proposal has been accepted; if not, you will be able to register as a regular attendee. For a successful presentation or workshop submission, please note the following: - All talks should be deeply technical, given by designers and implementors to designers and implementors. We all speak Code here! - Each talk, we hope and expect, will inform the audience, in detail, about the state of the art of language design and implementation on the JVM, or will explore the present and future capabilities of the JVM itself. (Some will do so indirectly by discussing non-JVM technologies.) - Know your audience: attendees may not be likely to ever use your specific language or tool, but could learn something from your interactions with the JVM. A broad goal of the summit is to inspire us to work together on JVM-based technologies that enable a rich ecosystem at higher layers. We encourage speakers to submit both a presentation and a workshop; we will arrange to schedule the presentation before the workshop, so that the presentation can spark people's interest and the workshop will allow those who are really interested to go deeper into the subject area. Workshop facilitators may, but are not expected to, prepare presentation materials; in any case, they should come prepared to guide a deep technical discussion. To register: regonline.com/jvmls2015 For further information: jvmlangsummit.com Questions: inquire at jvmlangsummit.com We hope to see you in August! From jon.masamitsu at oracle.com Wed Apr 15 18:16:14 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 15 Apr 2015 11:16:14 -0700 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552E421C.1010105@oracle.com> References: <552E421C.1010105@oracle.com> Message-ID: <552EAAEE.8070001@oracle.com> http://cr.openjdk.java.net/~stefank/8065585/webrev.02/src/share/vm/utilities/debug.cpp.frames.html > 210 // A function that never returns. Tells the compilers > 211 // that the control flow stops at the call of this function. > 212 ATTRIBUTE_NORETURN static void noreturn_function() { > 213 while (true) { > 214 os::naked_short_sleep(10); > 215 } > 216 } Did you consider using just os::infinite_sleep() inside of noreturn_function()? It doesn't do a short sleep but I don't know what using the short sleep vs. a longer sleep is meant to do. Not done yet. Jon On 4/15/2015 3:49 AM, Stefan Karlsson wrote: > Hi, > > Today the it's possible for the code to return out from > ShouldNotReachHere() calls. This sometimes forces us to add return > statements and assignments to parts of the code where it they don't > make sense. By telling the compiler that ShouldNotReachHere is a dead > end, we can get rid of these unnecessary constructs. > > For example: > > 1) We could get rid of return statements after ShouldNotReachHere(): > > bool is_marked() { > // actual code here > > // Execution path that "should not" happen. > ShouldNotReachHere(); > return false; > } > > 2) The following code will actually use an uninitialized value today. > The compiler will find this if we turn on -Wuninitialized. But if we > change ShouldNotReachHere() to not return, the compiler will stop > complaining because report(type) will never be called with an > uninitialized value: > > int type; > switch (value) { > case TYPE_OOP: type = 0; break; > case TYPE_KLASS: type = 1; break; > default: ShouldNotReachHere(); > } > report(type) > > > The patch changes the following functions and defines to never return: > - fatal(...) > - ShouldNotCallThis() > - ShouldNotReachHere() > - report_vm_out_of_memory(...) > - vm_exit_out_of_memory(...) > > but leaves the following unchanged: > - Unimplemented() > - Untested(...) > - guarantee(...) > > We might want to change the the behavior of Unimplemented() and > Untested(...), but they are used a lot in compiler code, so I've not > changed them for this patch. There has been request to leave > guarantee(...) unchanged so that they can be turned off in production > code. > > I had to change some instance of ShouldNotReachHere() in destructors, > because the VS C++ compiler complained about potential memory leaks. > > http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8065585 > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Apr 15 18:52:22 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Apr 2015 20:52:22 +0200 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552EAAEE.8070001@oracle.com> References: <552E421C.1010105@oracle.com> <552EAAEE.8070001@oracle.com> Message-ID: <552EB366.20206@oracle.com> On 2015-04-15 20:16, Jon Masamitsu wrote: > http://cr.openjdk.java.net/~stefank/8065585/webrev.02/src/share/vm/utilities/debug.cpp.frames.html > > >> 210 // A function that never returns. Tells the compilers >> 211 // that the control flow stops at the call of this function. >> 212 ATTRIBUTE_NORETURN static void noreturn_function() { >> 213 while (true) { >> 214 os::naked_short_sleep(10); >> 215 } >> 216 } > > Did you consider using just os::infinite_sleep() > inside of noreturn_function()? It doesn't do a > short sleep but I don't know what using the > short sleep vs. a longer sleep is meant to do. I did consider it once, but rejected it for some reason that I can't remember at this point. I could probably get rid of the noreturn_function(), tag infinit_sleep with ATTRIBUTE_NORETURN, and use it instead. Thanks, StefanK > > Not done yet. > > Jon > > > On 4/15/2015 3:49 AM, Stefan Karlsson wrote: >> Hi, >> >> Today the it's possible for the code to return out from >> ShouldNotReachHere() calls. This sometimes forces us to add return >> statements and assignments to parts of the code where it they don't >> make sense. By telling the compiler that ShouldNotReachHere is a dead >> end, we can get rid of these unnecessary constructs. >> >> For example: >> >> 1) We could get rid of return statements after ShouldNotReachHere(): >> >> bool is_marked() { >> // actual code here >> >> // Execution path that "should not" happen. >> ShouldNotReachHere(); >> return false; >> } >> >> 2) The following code will actually use an uninitialized value today. >> The compiler will find this if we turn on -Wuninitialized. But if we >> change ShouldNotReachHere() to not return, the compiler will stop >> complaining because report(type) will never be called with an >> uninitialized value: >> >> int type; >> switch (value) { >> case TYPE_OOP: type = 0; break; >> case TYPE_KLASS: type = 1; break; >> default: ShouldNotReachHere(); >> } >> report(type) >> >> >> The patch changes the following functions and defines to never return: >> - fatal(...) >> - ShouldNotCallThis() >> - ShouldNotReachHere() >> - report_vm_out_of_memory(...) >> - vm_exit_out_of_memory(...) >> >> but leaves the following unchanged: >> - Unimplemented() >> - Untested(...) >> - guarantee(...) >> >> We might want to change the the behavior of Unimplemented() and >> Untested(...), but they are used a lot in compiler code, so I've not >> changed them for this patch. There has been request to leave >> guarantee(...) unchanged so that they can be turned off in production >> code. >> >> I had to change some instance of ShouldNotReachHere() in destructors, >> because the VS C++ compiler complained about potential memory leaks. >> >> http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8065585 >> >> Thanks, >> StefanK > From calvin.cheung at oracle.com Wed Apr 15 19:56:54 2015 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 15 Apr 2015 12:56:54 -0700 Subject: RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol* Message-ID: <552EC286.5000005@oracle.com> Please review this second version of the fix. This version has 2 new functions (equals() and not_equals()) in the Symbol class. It replaces the Symbol* == and != comparisons with those 2 function calls. Pro: It has a much smaller changeset than the first version. Con: Someone may by mistake introduce a new line of (Symbol* == Symbol*). We will mitigate this by enhancing our internal static analysis tool to flag the above code in the future. JBS: https://bugs.openjdk.java.net/browse/JDK-8071627 webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/ Tests: JPRT (almost done) Will do more perf testing after JPRT thanks, Calvin From jon.masamitsu at oracle.com Wed Apr 15 20:44:57 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 15 Apr 2015 13:44:57 -0700 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552EB366.20206@oracle.com> References: <552E421C.1010105@oracle.com> <552EAAEE.8070001@oracle.com> <552EB366.20206@oracle.com> Message-ID: <552ECDC9.6020705@oracle.com> On 4/15/2015 11:52 AM, Stefan Karlsson wrote: > On 2015-04-15 20:16, Jon Masamitsu wrote: >> http://cr.openjdk.java.net/~stefank/8065585/webrev.02/src/share/vm/utilities/debug.cpp.frames.html >> >> >>> 210 // A function that never returns. Tells the compilers >>> 211 // that the control flow stops at the call of this function. >>> 212 ATTRIBUTE_NORETURN static void noreturn_function() { >>> 213 while (true) { >>> 214 os::naked_short_sleep(10); >>> 215 } >>> 216 } >> >> Did you consider using just os::infinite_sleep() >> inside of noreturn_function()? It doesn't do a >> short sleep but I don't know what using the >> short sleep vs. a longer sleep is meant to do. > > I did consider it once, but rejected it for some reason that I can't > remember at this point. I could probably get rid of the > noreturn_function(), tag infinit_sleep with ATTRIBUTE_NORETURN, and > use it instead. From the code readability infinite_sleep() certainly tells you what it's doing. I also like it for the longer sleep times. I recall several times looking at my machine and wondering what was eating up all the cpu. It turned out to be tests that had failed (with fastdebug JVMs) that were spinning in a tight wait loops. It stopped happening shortly after I first noticed it so I didn't look into what had changed. Jon > > Thanks, > StefanK > >> >> Not done yet. >> >> Jon >> >> >> On 4/15/2015 3:49 AM, Stefan Karlsson wrote: >>> Hi, >>> >>> Today the it's possible for the code to return out from >>> ShouldNotReachHere() calls. This sometimes forces us to add return >>> statements and assignments to parts of the code where it they don't >>> make sense. By telling the compiler that ShouldNotReachHere is a >>> dead end, we can get rid of these unnecessary constructs. >>> >>> For example: >>> >>> 1) We could get rid of return statements after ShouldNotReachHere(): >>> >>> bool is_marked() { >>> // actual code here >>> >>> // Execution path that "should not" happen. >>> ShouldNotReachHere(); >>> return false; >>> } >>> >>> 2) The following code will actually use an uninitialized value >>> today. The compiler will find this if we turn on -Wuninitialized. >>> But if we change ShouldNotReachHere() to not return, the compiler >>> will stop complaining because report(type) will never be called with >>> an uninitialized value: >>> >>> int type; >>> switch (value) { >>> case TYPE_OOP: type = 0; break; >>> case TYPE_KLASS: type = 1; break; >>> default: ShouldNotReachHere(); >>> } >>> report(type) >>> >>> >>> The patch changes the following functions and defines to never return: >>> - fatal(...) >>> - ShouldNotCallThis() >>> - ShouldNotReachHere() >>> - report_vm_out_of_memory(...) >>> - vm_exit_out_of_memory(...) >>> >>> but leaves the following unchanged: >>> - Unimplemented() >>> - Untested(...) >>> - guarantee(...) >>> >>> We might want to change the the behavior of Unimplemented() and >>> Untested(...), but they are used a lot in compiler code, so I've not >>> changed them for this patch. There has been request to leave >>> guarantee(...) unchanged so that they can be turned off in >>> production code. >>> >>> I had to change some instance of ShouldNotReachHere() in >>> destructors, because the VS C++ compiler complained about potential >>> memory leaks. >>> >>> http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8065585 >>> >>> Thanks, >>> StefanK >> > From stefan.karlsson at oracle.com Wed Apr 15 21:50:23 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Apr 2015 23:50:23 +0200 Subject: RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: <552EC286.5000005@oracle.com> References: <552EC286.5000005@oracle.com> Message-ID: <552EDD1F.1030308@oracle.com> Hi Calvin, On 2015-04-15 21:56, Calvin Cheung wrote: > Please review this second version of the fix. > > This version has 2 new functions (equals() and not_equals()) in the > Symbol class. > It replaces the Symbol* == and != comparisons with those 2 function > calls. > > Pro: > > It has a much smaller changeset than the first version. > > Con: > > Someone may by mistake introduce a new line of (Symbol* == Symbol*). > > We will mitigate this by enhancing our internal static analysis tool > to flag the > above code in the future. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8071627 > > webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/ This is a much less intrusive change than the previous patch. Thanks. http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/classFileParser.cpp.patch Is there a reason why you added not_equals: - if (name != vmSymbols::object_initializer_name()) { + if (name->not_equals(vmSymbols::object_initializer_name())) { instead of just: + if (!name->equals(vmSymbols::object_initializer_name())) { http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/systemDictionary.cpp.udiff.html ! assert(parsed_name->not_equals(NULL), "Sanity"); You use symbol == NULL but not symbol != NULL, which seems inconsistent to me. http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html *+ inline bool equals(const Symbol* other) const {* *+ if (this && other) { * First, pointers should be checked null checked with == or !=. See: https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-Miscellaneous Second, I recall some discussion that null checking the 'this' pointer is undefined behavior. Though, we do it in other places so this isn't worse, I think. Did you use your previous patch to find all Symbol* compares? Thanks, StefanK > > Tests: > JPRT (almost done) > Will do more perf testing after JPRT > > thanks, > Calvin From kim.barrett at oracle.com Wed Apr 15 23:04:46 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 15 Apr 2015 19:04:46 -0400 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552E421C.1010105@oracle.com> References: <552E421C.1010105@oracle.com> Message-ID: <5C264A91-8B12-4315-BED2-6E524B757798@oracle.com> On Apr 15, 2015, at 6:49 AM, Stefan Karlsson wrote: > > We might want to change the the behavior of Unimplemented() and Untested(...), but they are used a lot in compiler code, so I've not changed them for this patch. There has been request to leave guarantee(...) unchanged so that they can be turned off in production code. > > I had to change some instance of ShouldNotReachHere() in destructors, because the VS C++ compiler complained about potential memory leaks. > > http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8065585 Nice! A few comments: ------------------------------------------------------------------------------ > There has been request to leave guarantee(...) unchanged so that they > can be turned off in production code. Isn't that what assert() is for? I'm not sure whether guarantee() should use noreturn or not. Not, for consistency with assert() and for the same reasons has some appeal. On the other hand, guarantee() is supposed to be for use in production contexts. I'm wondering if guarantee() might be one (and quite possibly the only) place where we might consider making the use of noreturn conditional. This would make use of guarantee() is little trickier, e.g. guarantee(false, ...) is probably not sensible with that sort of configuration. But we ought to be using fatal in such a situation anyway. ------------------------------------------------------------------------------ Many missing copyright updates. ------------------------------------------------------------------------------ src/cpu/x86/vm/x86_32.ad 1212 Unimplemented(); 1213 return 0; // Mute compiler => 1212 fatal("Unimplemented"); Why was this changed? The email describing the change makes me think this shouldn't be part of this change set. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp 895 fatal(err_msg("Unknown dest state: " CSETSTATE_FORMAT, dest.value())); 896 break; Shouldn't the "break" also be unnecessary here? ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1StringDedupThread.cpp 42 guarantee(false, "Should never be destroyed"); guarantee => fatal. ------------------------------------------------------------------------------ src/share/vm/utilities/debug.hpp I think some commentary explaining why assert() and friends do *not* use the noreturn form of error error reporting might be in order. I'm guessing it is to improve the debugging experience for fastdebug builds; if assert used noreturn reporting then interesting values might be dead and optimized away, making them inaccessible in the debugger. ------------------------------------------------------------------------------ src/share/vm/utilities/hashtable.hpp 62 BasicHashtableEntry() { guarantee(false, "Should not be called"); } ... 65 ~BasicHashtableEntry() { guarantee(false, "Should not be called"); } guarantee => fatal. And by the way, this whole mechanism invokes undefined behavior. I suspect someone didn't understand placement new and delete. But that's not a problem with this change set. ------------------------------------------------------------------------------ From calvin.cheung at oracle.com Wed Apr 15 23:25:56 2015 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 15 Apr 2015 16:25:56 -0700 Subject: RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: <552EDD1F.1030308@oracle.com> References: <552EC286.5000005@oracle.com> <552EDD1F.1030308@oracle.com> Message-ID: <552EF384.4040103@oracle.com> Hi Stefan, Thanks for your review. On 4/15/2015 2:50 PM, Stefan Karlsson wrote: > Hi Calvin, > > On 2015-04-15 21:56, Calvin Cheung wrote: >> Please review this second version of the fix. >> >> This version has 2 new functions (equals() and not_equals()) in the >> Symbol class. >> It replaces the Symbol* == and != comparisons with those 2 function >> calls. >> >> Pro: >> >> It has a much smaller changeset than the first version. >> >> Con: >> >> Someone may by mistake introduce a new line of (Symbol* == Symbol*). >> >> We will mitigate this by enhancing our internal static analysis tool >> to flag the >> above code in the future. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8071627 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/ > > This is a much less intrusive change than the previous patch. Thanks. > > > http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/classFileParser.cpp.patch > > Is there a reason why you added not_equals: > - if (name != vmSymbols::object_initializer_name()) { > + if (name->not_equals(vmSymbols::object_initializer_name())) { > > instead of just: > + if (!name->equals(vmSymbols::object_initializer_name())) { We think that it's clearer to have not_equals() than using the ! as in the above. > > http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/systemDictionary.cpp.udiff.html > ! assert(parsed_name->not_equals(NULL), "Sanity"); > > > You use symbol == NULL but not symbol != NULL, which seems > inconsistent to me. I'm not sure I understand this comment. Are you referring to the following section of the udiff? *** 1104,1115 **** --- 1104,1115 ---- Exceptions::_throw_msg(THREAD_AND_LOCATION, vmSymbols::java_lang_SecurityException(), message); } if (!HAS_PENDING_EXCEPTION) { ! assert(parsed_name != NULL, "Sanity"); ! assert(class_name == NULL || class_name == parsed_name, "name mismatch"); ! assert(parsed_name->not_equals(NULL), "Sanity"); ! assert(class_name == NULL || class_name->equals(parsed_name), "name mismatch"); // Verification prevents us from creating names with dots in them, this // asserts that that's the case. assert(is_internal_format(parsed_name), "external class name format used internally"); I don't see anything incorrect there. > > > http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html > > *+ inline bool equals(const Symbol* other) const {* > *+ if (this && other) { > * > First, pointers should be checked null checked with == or !=. See: > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-Miscellaneous I will fix it. > > Second, I recall some discussion that null checking the 'this' pointer > is undefined behavior. Though, we do it in other places so this isn't > worse, I think. > > Did you use your previous patch to find all Symbol* compares? Yes. Essentially comment out the bodies of the == and != operators in SymbolRef. Rebuilding hotspot resulting a lot of "undefined reference to SymbolRef::operator==" link errors. Then go through those error and change a == b to a->equals(b) and a != b to a->not_equals(b). Obviously change SymbolRef back to Symbol*. thanks, Calvin > > Thanks, > StefanK > >> >> Tests: >> JPRT (almost done) >> Will do more perf testing after JPRT >> >> thanks, >> Calvin > From david.holmes at oracle.com Thu Apr 16 02:23:01 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Apr 2015 12:23:01 +1000 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> Message-ID: <552F1D05.40209@oracle.com> Hi Stefan, Stefan Karlsson wrote: > Hi, > > Today the it's possible for the code to return out from > ShouldNotReachHere() calls. This sometimes forces us to add return > statements and assignments to parts of the code where it they don't make > sense. By telling the compiler that ShouldNotReachHere is a dead end, we > can get rid of these unnecessary constructs. > > For example: > > 1) We could get rid of return statements after ShouldNotReachHere(): > > bool is_marked() { > // actual code here > > // Execution path that "should not" happen. > ShouldNotReachHere(); > return false; > } > > 2) The following code will actually use an uninitialized value today. > The compiler will find this if we turn on -Wuninitialized. But if we > change ShouldNotReachHere() to not return, the compiler will stop > complaining because report(type) will never be called with an > uninitialized value: > > int type; > switch (value) { > case TYPE_OOP: type = 0; break; > case TYPE_KLASS: type = 1; break; > default: ShouldNotReachHere(); > } > report(type) > > > The patch changes the following functions and defines to never return: > - fatal(...) > - ShouldNotCallThis() > - ShouldNotReachHere() > - report_vm_out_of_memory(...) You changed the behaviour of this one in the Debugging case - it no longer returns. > - vm_exit_out_of_memory(...) > > but leaves the following unchanged: > - Unimplemented() > - Untested(...) > - guarantee(...) > We might want to change the the behavior of Unimplemented() and > Untested(...), but they are used a lot in compiler code, so I've not > changed them for this patch. There has been request to leave > guarantee(...) unchanged so that they can be turned off in production code. > > I had to change some instance of ShouldNotReachHere() in destructors, > because the VS C++ compiler complained about potential memory leaks. The approach seems inconsistent though - sometimes a switch to a guarantee, sometimes removal of the destructor and making it private (which doesn't quite give the same level of protection). > http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8065585 In summary: The BREAKPOINTs have been moved out of the macros into the functions, and the macros then simplified to direct calls. Ok. Some calls now have the NORETURN_ATTRIBUTE applied. Ok. Calls to functions that have NORETURN_ATTRIBUTE can be cleaned up if they previously allowed for the function returning. Ok. So first question: is this attribute handled correctly by all the compilers we need to consider? Second, more important question: have you examined how this attribute affects the ability to walk the stack? We have already seen issues on some platforms where library functions, like abort(), have the noreturn attribute and as a result the call is optimized in a way that prevents the stack from being walked - see eg: https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 though this: https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 suggests that problem may have been addressed by the libc folk. But it still raises the question as to how our own noreturn functions will be handled and how they will affect stacktrace generation in hs_err logs or via gdb. Thanks, David > > Thanks, > StefanK > From david.holmes at oracle.com Thu Apr 16 02:35:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Apr 2015 12:35:26 +1000 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <552E6C8C.3050607@oracle.com> References: <551D9AC6.50208@oracle.com> <55232E90.7060701@oracle.com> <5526CEDF.20004@oracle.com> <55272BDA.2060908@oracle.com> <552C262A.1070002@oracle.com> <552C49B8.9070805@oracle.com> <552E6C8C.3050607@oracle.com> Message-ID: <552F1FEE.2080105@oracle.com> Thumbs up! Thanks, David On 15/04/2015 11:50 PM, Max Ockner wrote: > I had a few things mixed up in the last webrev. Either way, I have > changed this, hopefully for the last time. vmError.cpp now uses > INTPTR_FORMAT. > > webrev: http://cr.openjdk.java.net/~mockner/8029630.final/ > > tested with jprt. > > > Thanks, > Max > > On 4/13/2015 6:56 PM, David Holmes wrote: >> Hi Max, >> >> On 14/04/2015 6:25 AM, Max Ockner wrote: >>> Hello, >>> >>> Modified this again. I defined TID_FORMAT to make it a better semantic >>> match. >> >> Not sure that actually improves anything. There is no "tid" type. >> Primarily what we have is a function returning intx and we want to >> print it as hex. I still think INTPTR_FORMAT suffices. Otherwise >> INTX_HEX_FORMAT is you really want to introduce something new - but I >> don't suggest doing that. >> >>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.8/ >> >> I still see vmError.cpp using PTR_FORMAT ?? >> >> Sorry. >> >> David >> >>> Tested with jprt >>> >>> Thanks, >>> Max >>> >>> On 4/9/2015 9:48 PM, David Holmes wrote: >>>> Hi Max, >>>> >>>> On 10/04/2015 5:11 AM, Max Ockner wrote: >>>>> Hi again, >>>>> After working past some build issues, I have a new webrev. I've >>>>> changed >>>>> %x to PTR_FORMAT, and I've removed the modification to thread.cpp >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~mockner/8029630.4/ >>>> >>>> I think INTPTR_FORMAT would be more of a semantic match as the thread >>>> id is not a pointer type. >>>> >>>> David >>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 4/6/2015 9:10 PM, David Holmes wrote: >>>>>> Hi Max, >>>>>> >>>>>> On 3/04/2015 5:38 AM, Max Ockner wrote: >>>>>>> Hello, >>>>>>> Please review this change: >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >>>>>>> Summary: Existing error messages for vm crashes print the decimal >>>>>>> representation of the current thread id. The message format has been >>>>>>> changed to print the hex value of the thread id. >>>>>> >>>>>> src/share/vm/runtime/thread.cpp >>>>>> >>>>>> The change is incorrect and unnecessary. 'this' is a pointer type so >>>>>> INTPTR_FORMAT seems correct (though it may need p2i(this)?) while %x >>>>>> assumes 'this' is always 32-bit. Further INTPTR_FORMAT is already hex >>>>>> not decimal. >>>>>> >>>>>> src/share/vm/utilities/vmError.cpp >>>>>> >>>>>> As Thomas pointed out%x assumes 32-bit and so is incorrect for intx >>>>>> type. As intx is a typedef for intptr_t then INTPTR_FORMAT should be >>>>>> usable here as well. >>>>>> >>>>>> David >>>>>> >>>>>>> Tested with jtreg runtime to make sure nothing was broken. I tested >>>>>>> the >>>>>>> new functionality separately. I crashed the vm and examined the >>>>>>> debugger >>>>>>> output to make sure the hexadecimal thread id printed in the error >>>>>>> message matched one of the threads listed by the debugger. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>> >>> > From david.holmes at oracle.com Thu Apr 16 02:39:06 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Apr 2015 12:39:06 +1000 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552F1D05.40209@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> Message-ID: <552F20CA.5070203@oracle.com> Fixing subject so it appears in main thread when sorted by suubject. David On 16/04/2015 12:23 PM, David Holmes wrote: > Hi Stefan, > > Stefan Karlsson wrote: >> Hi, >> >> Today the it's possible for the code to return out from >> ShouldNotReachHere() calls. This sometimes forces us to add return >> statements and assignments to parts of the code where it they don't make >> sense. By telling the compiler that ShouldNotReachHere is a dead end, we >> can get rid of these unnecessary constructs. >> >> For example: >> >> 1) We could get rid of return statements after ShouldNotReachHere(): >> >> bool is_marked() { >> // actual code here >> >> // Execution path that "should not" happen. >> ShouldNotReachHere(); >> return false; >> } >> >> 2) The following code will actually use an uninitialized value today. >> The compiler will find this if we turn on -Wuninitialized. But if we >> change ShouldNotReachHere() to not return, the compiler will stop >> complaining because report(type) will never be called with an >> uninitialized value: >> >> int type; >> switch (value) { >> case TYPE_OOP: type = 0; break; >> case TYPE_KLASS: type = 1; break; >> default: ShouldNotReachHere(); >> } >> report(type) >> >> >> The patch changes the following functions and defines to never return: >> - fatal(...) >> - ShouldNotCallThis() >> - ShouldNotReachHere() >> - report_vm_out_of_memory(...) > > You changed the behaviour of this one in the Debugging case - it no > longer returns. > >> - vm_exit_out_of_memory(...) >> >> but leaves the following unchanged: >> - Unimplemented() >> - Untested(...) >> - guarantee(...) >> We might want to change the the behavior of Unimplemented() and >> Untested(...), but they are used a lot in compiler code, so I've not >> changed them for this patch. There has been request to leave >> guarantee(...) unchanged so that they can be turned off in production >> code. >> >> I had to change some instance of ShouldNotReachHere() in destructors, >> because the VS C++ compiler complained about potential memory leaks. > > The approach seems inconsistent though - sometimes a switch to a > guarantee, sometimes removal of the destructor and making it private > (which doesn't quite give the same level of protection). > >> http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8065585 > > In summary: > > The BREAKPOINTs have been moved out of the macros into the functions, > and the macros then simplified to direct calls. Ok. > > Some calls now have the NORETURN_ATTRIBUTE applied. Ok. > > Calls to functions that have NORETURN_ATTRIBUTE can be cleaned up if > they previously allowed for the function returning. Ok. > > So first question: is this attribute handled correctly by all the > compilers we need to consider? > > Second, more important question: have you examined how this attribute > affects the ability to walk the stack? We have already seen issues on > some platforms where library functions, like abort(), have the noreturn > attribute and as a result the call is optimized in a way that prevents > the stack from being walked - see eg: > > https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 > > > though this: > > https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 > > suggests that problem may have been addressed by the libc folk. But it > still raises the question as to how our own noreturn functions will be > handled and how they will affect stacktrace generation in hs_err logs or > via gdb. > > Thanks, > David > >> >> Thanks, >> StefanK >> From kim.barrett at oracle.com Thu Apr 16 03:44:16 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 15 Apr 2015 23:44:16 -0400 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552F1D05.40209@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> Message-ID: <7D974E6E-D18A-4639-9D4B-A3727DEA2E93@oracle.com> On Apr 15, 2015, at 10:23 PM, David Holmes wrote: > >> I had to change some instance of ShouldNotReachHere() in destructors, >> because the VS C++ compiler complained about potential memory leaks. > > The approach seems inconsistent though - sometimes a switch to a guarantee, sometimes removal of the destructor and making it private (which doesn't quite give the same level of protection). I think those that were made private were also left undefined, so there should be link-time errors if there are any unexpected references. (C++11 would let us declare them ?deleted? so the error would be at compile-time.) From kim.barrett at oracle.com Thu Apr 16 04:47:12 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 16 Apr 2015 00:47:12 -0400 Subject: RFR (S): JDK-8077873: G1: Remove G1SATBPrintStubs In-Reply-To: <552E9993.3020904@oracle.com> References: <552E9993.3020904@oracle.com> Message-ID: <15CE8FCB-781A-41FB-A439-AC8AB5281F7F@oracle.com> On Apr 15, 2015, at 1:02 PM, Bengt Rutisson wrote: > > > Hi everyone, > > Sending this to hotspot-dev since it is a GC change but it touches compiler code in macroAssembler_sparc.cpp. > > https://bugs.openjdk.java.net/browse/JDK-8077873 > http://cr.openjdk.java.net/~brutisso/8077873/webrev.00/ > > The develop flag G1SATBPrintStubs prints out the generated assembly for the SATB stubs. This is has been around since G1 was integrated in the the hotspot repo. But it was only ever implemented for Sparc and it looks much like debugging code that has just been left in the code base. > > I have not heard of anyone using this flag lately so rather than generalizing it to all platforms I propose that we remove it. If we need to debug the SATB write barrier generation we can easily add back similar logging. > > Thanks, > Bengt Looks good. From stefan.karlsson at oracle.com Thu Apr 16 06:02:55 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 16 Apr 2015 08:02:55 +0200 Subject: RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: <552EF384.4040103@oracle.com> References: <552EC286.5000005@oracle.com> <552EDD1F.1030308@oracle.com> <552EF384.4040103@oracle.com> Message-ID: <552F508F.7050809@oracle.com> On 2015-04-16 01:25, Calvin Cheung wrote: > Hi Stefan, > > Thanks for your review. > > On 4/15/2015 2:50 PM, Stefan Karlsson wrote: >> Hi Calvin, >> >> On 2015-04-15 21:56, Calvin Cheung wrote: >>> Please review this second version of the fix. >>> >>> This version has 2 new functions (equals() and not_equals()) in the >>> Symbol class. >>> It replaces the Symbol* == and != comparisons with those 2 function >>> calls. >>> >>> Pro: >>> >>> It has a much smaller changeset than the first version. >>> >>> Con: >>> >>> Someone may by mistake introduce a new line of (Symbol* == Symbol*). >>> >>> We will mitigate this by enhancing our internal static analysis tool >>> to flag the >>> above code in the future. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8071627 >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/ >> >> This is a much less intrusive change than the previous patch. Thanks. >> >> >> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/classFileParser.cpp.patch >> >> Is there a reason why you added not_equals: >> - if (name != vmSymbols::object_initializer_name()) { >> + if (name->not_equals(vmSymbols::object_initializer_name())) { >> >> instead of just: >> + if (!name->equals(vmSymbols::object_initializer_name())) { > We think that it's clearer to have not_equals() than using the ! as in > the above. OK. IMHO, negating boolean expressions with ! is a common construct so I'm not sure not_equals is clearer. >> >> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/systemDictionary.cpp.udiff.html >> ! assert(parsed_name->not_equals(NULL), "Sanity"); >> >> >> You use symbol == NULL but not symbol != NULL, which seems >> inconsistent to me. > I'm not sure I understand this comment. > Are you referring to the following section of the udiff? > *** 1104,1115 **** > --- 1104,1115 ---- > Exceptions::_throw_msg(THREAD_AND_LOCATION, > vmSymbols::java_lang_SecurityException(), message); > } > > if (!HAS_PENDING_EXCEPTION) { > ! assert(parsed_name != NULL, "Sanity"); > ! assert(class_name == NULL || class_name == parsed_name, "name > mismatch"); > ! assert(parsed_name->not_equals(NULL), "Sanity"); > ! assert(class_name == NULL || class_name->equals(parsed_name), > "name mismatch"); > // Verification prevents us from creating names with dots in > them, this > // asserts that that's the case. > assert(is_internal_format(parsed_name), > "external class name format used internally"); > > I don't see anything incorrect there. I'm not talking about being correct or incorrect. I would have expected to see either: 1) Use pointer (in)equality when checking for NULL: class_name == NULL parsed_name != NULL or 2) strictly use the (not_)equals function when checking for NULL: class_name->equals(NULL) parsed_name->not_equals(NULL) or even: class_name->equals(NULL) !parsed_name->equals(NULL)) but not what you have today, where you mix the two ways to NULL check class_name == NULL parsed_name->not_equals(NULL) >> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html >> >> *+ inline bool equals(const Symbol* other) const {* >> *+ if (this && other) { >> * >> First, pointers should be checked null checked with == or !=. See: >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-Miscellaneous > > I will fix it. > >> >> Second, I recall some discussion that null checking the 'this' >> pointer is undefined behavior. Though, we do it in other places so >> this isn't worse, I think. >> >> Did you use your previous patch to find all Symbol* compares? > > Yes. Essentially comment out the bodies of the == and != operators in > SymbolRef. > Rebuilding hotspot resulting a lot of "undefined reference to > SymbolRef::operator==" link errors. > Then go through those error and change a == b to a->equals(b) and a != > b to a->not_equals(b). > Obviously change SymbolRef back to Symbol*. Great. One more thing: http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html *+ if (this->_identity_hash != other->_identity_hash) {* *+ return false;* *+ }* Is this correct? The current code sets up _identity_hash with os::random, so it seems like to Symbols with equal contents would most likely going to get different _identity_hash codes. Or will this be changed later? Thanks, StefanK > > thanks, > Calvin > >> >> Thanks, >> StefanK >> >>> >>> Tests: >>> JPRT (almost done) >>> Will do more perf testing after JPRT >>> >>> thanks, >>> Calvin >> > From stefan.karlsson at oracle.com Thu Apr 16 06:11:08 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 16 Apr 2015 08:11:08 +0200 Subject: RFR: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <5C264A91-8B12-4315-BED2-6E524B757798@oracle.com> References: <552E421C.1010105@oracle.com> <5C264A91-8B12-4315-BED2-6E524B757798@oracle.com> Message-ID: <552F527C.1040803@oracle.com> On 2015-04-16 01:04, Kim Barrett wrote: > On Apr 15, 2015, at 6:49 AM, Stefan Karlsson wrote: >> We might want to change the the behavior of Unimplemented() and Untested(...), but they are used a lot in compiler code, so I've not changed them for this patch. There has been request to leave guarantee(...) unchanged so that they can be turned off in production code. >> >> I had to change some instance of ShouldNotReachHere() in destructors, because the VS C++ compiler complained about potential memory leaks. >> >> http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8065585 > Nice! A few comments: > > ------------------------------------------------------------------------------ >> There has been request to leave guarantee(...) unchanged so that they >> can be turned off in production code. > Isn't that what assert() is for? Support wants to be able to turn of guarantees in a few cases where we actually don't have to shutdown the JVM if the guarantee is hit. > > I'm not sure whether guarantee() should use noreturn or not. Not, for > consistency with assert() and for the same reasons has some appeal. > On the other hand, guarantee() is supposed to be for use in production > contexts. > > I'm wondering if guarantee() might be one (and quite possibly the > only) place where we might consider making the use of noreturn > conditional. This would make use of guarantee() is little trickier, > e.g. guarantee(false, ...) is probably not sensible with that sort of > configuration. But we ought to be using fatal in such a situation > anyway. Since guarantee can, and often will :), return it shouldn't be marked with noreturn. I was thinking about the guarantee(false, ...) use case. > > ------------------------------------------------------------------------------ > Many missing copyright updates. Yes. I usually don't update copyrights when I send out my review requests. > > ------------------------------------------------------------------------------ > src/cpu/x86/vm/x86_32.ad > 1212 Unimplemented(); > 1213 return 0; // Mute compiler > => > 1212 fatal("Unimplemented"); > > Why was this changed? The email describing the change makes me think > this shouldn't be part of this change set. It might be a left-over from when I tried to change Unimplemented. I'll take a look at it. > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp > 895 fatal(err_msg("Unknown dest state: " CSETSTATE_FORMAT, dest.value())); > 896 break; > > Shouldn't the "break" also be unnecessary here? Probably. I'll test. > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1StringDedupThread.cpp > 42 guarantee(false, "Should never be destroyed"); > > guarantee => fatal. No. If I do that change, then the VS C++ compiler complains that we leak memory since we never return from the destructor. But maybe it's better to find a way to turn off that warning? > > ------------------------------------------------------------------------------ > src/share/vm/utilities/debug.hpp > > I think some commentary explaining why assert() and friends do *not* > use the noreturn form of error error reporting might be in order. I'm > guessing it is to improve the debugging experience for fastdebug > builds; if assert used noreturn reporting then interesting values > might be dead and optimized away, making them inaccessible in the > debugger. You can return from assert, that's why it's not marked with noreturn. > > ------------------------------------------------------------------------------ > src/share/vm/utilities/hashtable.hpp > 62 BasicHashtableEntry() { guarantee(false, "Should not be called"); } > ... > 65 ~BasicHashtableEntry() { guarantee(false, "Should not be called"); } > > guarantee => fatal. > > And by the way, this whole mechanism invokes undefined behavior. I > suspect someone didn't understand placement new and delete. But > that's not a problem with this change set. Same comment above about the memory leak. Thanks, StefanK > > ------------------------------------------------------------------------------ > From bengt.rutisson at oracle.com Thu Apr 16 06:02:07 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 16 Apr 2015 08:02:07 +0200 Subject: RFR (S): JDK-8077873: G1: Remove G1SATBPrintStubs In-Reply-To: <15CE8FCB-781A-41FB-A439-AC8AB5281F7F@oracle.com> References: <552E9993.3020904@oracle.com> <15CE8FCB-781A-41FB-A439-AC8AB5281F7F@oracle.com> Message-ID: <552F505F.3020307@oracle.com> On 2015-04-16 06:47, Kim Barrett wrote: > On Apr 15, 2015, at 1:02 PM, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Sending this to hotspot-dev since it is a GC change but it touches compiler code in macroAssembler_sparc.cpp. >> >> https://bugs.openjdk.java.net/browse/JDK-8077873 >> http://cr.openjdk.java.net/~brutisso/8077873/webrev.00/ >> >> The develop flag G1SATBPrintStubs prints out the generated assembly for the SATB stubs. This is has been around since G1 was integrated in the the hotspot repo. But it was only ever implemented for Sparc and it looks much like debugging code that has just been left in the code base. >> >> I have not heard of anyone using this flag lately so rather than generalizing it to all platforms I propose that we remove it. If we need to debug the SATB write barrier generation we can easily add back similar logging. >> >> Thanks, >> Bengt > Looks good. Thanks, Kim! Bengt > From ioi.lam at oracle.com Thu Apr 16 06:13:40 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 15 Apr 2015 23:13:40 -0700 Subject: RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: <552F508F.7050809@oracle.com> References: <552EC286.5000005@oracle.com> <552EDD1F.1030308@oracle.com> <552EF384.4040103@oracle.com> <552F508F.7050809@oracle.com> Message-ID: <552F5314.3070002@oracle.com> On 4/15/15 11:02 PM, Stefan Karlsson wrote: > On 2015-04-16 01:25, Calvin Cheung wrote: >> Hi Stefan, >> >> Thanks for your review. >> >> On 4/15/2015 2:50 PM, Stefan Karlsson wrote: >>> Hi Calvin, >>> >>> On 2015-04-15 21:56, Calvin Cheung wrote: >>>> Please review this second version of the fix. >>>> >>>> This version has 2 new functions (equals() and not_equals()) in the >>>> Symbol class. >>>> It replaces the Symbol* == and != comparisons with those 2 function >>>> calls. >>>> >>>> Pro: >>>> >>>> It has a much smaller changeset than the first version. >>>> >>>> Con: >>>> >>>> Someone may by mistake introduce a new line of (Symbol* == Symbol*). >>>> >>>> We will mitigate this by enhancing our internal static analysis >>>> tool to flag the >>>> above code in the future. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8071627 >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/ >>> >>> This is a much less intrusive change than the previous patch. Thanks. >>> >>> >>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/classFileParser.cpp.patch >>> >>> >>> Is there a reason why you added not_equals: >>> - if (name != vmSymbols::object_initializer_name()) { >>> + if >>> (name->not_equals(vmSymbols::object_initializer_name())) { >>> >>> instead of just: >>> + if >>> (!name->equals(vmSymbols::object_initializer_name())) { >> We think that it's clearer to have not_equals() than using the ! as >> in the above. > > OK. IMHO, negating boolean expressions with ! is a common construct so > I'm not sure not_equals is clearer. > >>> >>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/systemDictionary.cpp.udiff.html >>> >>> ! assert(parsed_name->not_equals(NULL), "Sanity"); >>> >>> >>> You use symbol == NULL but not symbol != NULL, which seems >>> inconsistent to me. >> I'm not sure I understand this comment. >> Are you referring to the following section of the udiff? >> *** 1104,1115 **** >> --- 1104,1115 ---- >> Exceptions::_throw_msg(THREAD_AND_LOCATION, >> vmSymbols::java_lang_SecurityException(), message); >> } >> >> if (!HAS_PENDING_EXCEPTION) { >> ! assert(parsed_name != NULL, "Sanity"); >> ! assert(class_name == NULL || class_name == parsed_name, "name >> mismatch"); >> ! assert(parsed_name->not_equals(NULL), "Sanity"); >> ! assert(class_name == NULL || class_name->equals(parsed_name), >> "name mismatch"); >> // Verification prevents us from creating names with dots in >> them, this >> // asserts that that's the case. >> assert(is_internal_format(parsed_name), >> "external class name format used internally"); >> >> I don't see anything incorrect there. > > I'm not talking about being correct or incorrect. I would have > expected to see either: > > 1) Use pointer (in)equality when checking for NULL: > class_name == NULL > parsed_name != NULL > > or > > 2) strictly use the (not_)equals function when checking for NULL: > class_name->equals(NULL) > parsed_name->not_equals(NULL) > or even: > class_name->equals(NULL) > !parsed_name->equals(NULL)) > > but not what you have today, where you mix the two ways to NULL check > class_name == NULL > parsed_name->not_equals(NULL) > I think it's better to use (symbol == NULL) everywhere. Calling symbol->equals(NULL) while symbol itself is NULL is confusing -- it raises questions like "will this crash in debug mode", so we'd better avoid it. In our static analysis tool, we need to flags checks for (symbol1 == symbol2), but should allow (symbol == NULL). - Ioi > >>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html >>> >>> >>> *+ inline bool equals(const Symbol* other) const {* >>> *+ if (this && other) { >>> * >>> First, pointers should be checked null checked with == or !=. See: >>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-Miscellaneous >>> >> >> I will fix it. >> >>> >>> Second, I recall some discussion that null checking the 'this' >>> pointer is undefined behavior. Though, we do it in other places so >>> this isn't worse, I think. >>> >>> Did you use your previous patch to find all Symbol* compares? >> >> Yes. Essentially comment out the bodies of the == and != operators in >> SymbolRef. >> Rebuilding hotspot resulting a lot of "undefined reference to >> SymbolRef::operator==" link errors. >> Then go through those error and change a == b to a->equals(b) and a >> != b to a->not_equals(b). >> Obviously change SymbolRef back to Symbol*. > > Great. > > One more thing: > http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html > > > *+ if (this->_identity_hash != other->_identity_hash) {* > *+ return false;* > *+ }* > > > Is this correct? The current code sets up _identity_hash with > os::random, so it seems like to Symbols with equal contents would most > likely going to get different _identity_hash codes. Or will this be > changed later? > > Thanks, > StefanK >> >> thanks, >> Calvin >> >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Tests: >>>> JPRT (almost done) >>>> Will do more perf testing after JPRT >>>> >>>> thanks, >>>> Calvin >>> >> > From stefan.karlsson at oracle.com Thu Apr 16 06:31:52 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 16 Apr 2015 08:31:52 +0200 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552F1D05.40209@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> Message-ID: <552F5758.7090004@oracle.com> On 2015-04-16 04:23, David Holmes wrote: > Hi Stefan, > > Stefan Karlsson wrote: >> Hi, >> >> Today the it's possible for the code to return out from >> ShouldNotReachHere() calls. This sometimes forces us to add return >> statements and assignments to parts of the code where it they don't make >> sense. By telling the compiler that ShouldNotReachHere is a dead end, we >> can get rid of these unnecessary constructs. >> >> For example: >> >> 1) We could get rid of return statements after ShouldNotReachHere(): >> >> bool is_marked() { >> // actual code here >> >> // Execution path that "should not" happen. >> ShouldNotReachHere(); >> return false; >> } >> >> 2) The following code will actually use an uninitialized value today. >> The compiler will find this if we turn on -Wuninitialized. But if we >> change ShouldNotReachHere() to not return, the compiler will stop >> complaining because report(type) will never be called with an >> uninitialized value: >> >> int type; >> switch (value) { >> case TYPE_OOP: type = 0; break; >> case TYPE_KLASS: type = 1; break; >> default: ShouldNotReachHere(); >> } >> report(type) >> >> >> The patch changes the following functions and defines to never return: >> - fatal(...) >> - ShouldNotCallThis() >> - ShouldNotReachHere() >> - report_vm_out_of_memory(...) > > You changed the behaviour of this one in the Debugging case - it no > longer returns. Yes. And I changed the behavior for all the others as well. We can't allow Debugging to let us return from the functions if we are going to do this change. > >> - vm_exit_out_of_memory(...) >> >> but leaves the following unchanged: >> - Unimplemented() >> - Untested(...) >> - guarantee(...) >> We might want to change the the behavior of Unimplemented() and >> Untested(...), but they are used a lot in compiler code, so I've not >> changed them for this patch. There has been request to leave >> guarantee(...) unchanged so that they can be turned off in production >> code. >> >> I had to change some instance of ShouldNotReachHere() in destructors, >> because the VS C++ compiler complained about potential memory leaks. > > The approach seems inconsistent though - sometimes a switch to a > guarantee, sometimes removal of the destructor and making it private > (which doesn't quite give the same level of protection). Some times you can't remove the destructor. For example, the g1StringDedupThread code has to provide a destructor, or the linker will complain about a missing vtable entry. > > >> http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8065585 > > In summary: > > The BREAKPOINTs have been moved out of the macros into the functions, > and the macros then simplified to direct calls. Ok. > > Some calls now have the NORETURN_ATTRIBUTE applied. Ok. > > Calls to functions that have NORETURN_ATTRIBUTE can be cleaned up if > they previously allowed for the function returning. Ok. > > So first question: is this attribute handled correctly by all the > compilers we need to consider? It works for the Linux and Windows platforms that are run in JPRT. The Solaris Studio documentation describes it, and it passes JPRT, but I don't remember if the equivalent to -Wreturn-type is on when we compile on Solaris. > > Second, more important question: have you examined how this attribute > affects the ability to walk the stack? We have already seen issues on > some platforms where library functions, like abort(), have the > noreturn attribute and as a result the call is optimized in a way that > prevents the stack from being walked - see eg: > > https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 > > > though this: > > https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 > > suggests that problem may have been addressed by the libc folk. But it > still raises the question as to how our own noreturn functions will be > handled and how they will affect stacktrace generation in hs_err logs > or via gdb. I can do experiments to see if we still can walk the stack. Thanks, StefanK > > Thanks, > David > >> >> Thanks, >> StefanK >> From thomas.schatzl at oracle.com Thu Apr 16 07:15:19 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 16 Apr 2015 09:15:19 +0200 Subject: RFR (S): JDK-8077873: G1: Remove G1SATBPrintStubs In-Reply-To: <552E9993.3020904@oracle.com> References: <552E9993.3020904@oracle.com> Message-ID: <1429168519.3657.1.camel@localhost> Hi, On Wed, 2015-04-15 at 19:02 +0200, Bengt Rutisson wrote: > Hi everyone, > > Sending this to hotspot-dev since it is a GC change but it touches > compiler code in macroAssembler_sparc.cpp. > > https://bugs.openjdk.java.net/browse/JDK-8077873 > http://cr.openjdk.java.net/~brutisso/8077873/webrev.00/ > > The develop flag G1SATBPrintStubs prints out the generated assembly for > the SATB stubs. This is has been around since G1 was integrated in the > the hotspot repo. But it was only ever implemented for Sparc and it > looks much like debugging code that has just been left in the code base. > > I have not heard of anyone using this flag lately so rather than > generalizing it to all platforms I propose that we remove it. If we need > to debug the SATB write barrier generation we can easily add back > similar logging. > looks good. Thomas From bengt.rutisson at oracle.com Thu Apr 16 07:11:05 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 16 Apr 2015 09:11:05 +0200 Subject: RFR (S): JDK-8077873: G1: Remove G1SATBPrintStubs In-Reply-To: <1429168519.3657.1.camel@localhost> References: <552E9993.3020904@oracle.com> <1429168519.3657.1.camel@localhost> Message-ID: <552F6089.7010405@oracle.com> On 2015-04-16 09:15, Thomas Schatzl wrote: > Hi, > > On Wed, 2015-04-15 at 19:02 +0200, Bengt Rutisson wrote: >> Hi everyone, >> >> Sending this to hotspot-dev since it is a GC change but it touches >> compiler code in macroAssembler_sparc.cpp. >> >> https://bugs.openjdk.java.net/browse/JDK-8077873 >> http://cr.openjdk.java.net/~brutisso/8077873/webrev.00/ >> >> The develop flag G1SATBPrintStubs prints out the generated assembly for >> the SATB stubs. This is has been around since G1 was integrated in the >> the hotspot repo. But it was only ever implemented for Sparc and it >> looks much like debugging code that has just been left in the code base. >> >> I have not heard of anyone using this flag lately so rather than >> generalizing it to all platforms I propose that we remove it. If we need >> to debug the SATB write barrier generation we can easily add back >> similar logging. >> > looks good. Thanks, Thomas! Bengt > > Thomas > > From goetz.lindenmaier at sap.com Thu Apr 16 08:50:39 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 Apr 2015 08:50:39 +0000 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552E7CA9.5020901@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552E7CA9.5020901@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBF20D@DEWDFEMB12A.global.corp.sap> Hi Stefan, the IBM docu says that __notreturn__ affects only warnings about uninitialized variables, not about missing returns. It also says that registers are not stored on a call. http://publibfp.boulder.ibm.com/epubs/pdf/c1473260.pdf page 193. Sure I could suppress the warning, but I guess that's not the point of this change. For the compiler flags and warnings I get see the compile output below. I had to fix two precompiled header issues in the build, but then got it through. The "return value" warnings are the only ones I see. Best regards, Goetz bash-4.3$ xlC_r -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0008 bash-4.3$ xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG -I/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/share/vm/prims -I/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/share/vm -I/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/share/vm/precompiled -I/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/cpu/ppc/vm -I/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/os_cpu/aix_ppc/vm -I/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/os/aix/vm -I/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/os/posix/vm -I../generated -DHOTSPOT_BUILD_USER="\"d045726\"" -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -DCOMPILER2 -qpic=large -qnortti -qnoeh -D_REENTRANT -D__STDC_FORMAT_MACROS -q64 -g -q64 -qlanglvl=c99vla -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1500-010 -qsuppress=1540-1639 -qsuppress=1540-1088 -c -qmakedep=gcc -MF ../generated/dependencies/ad_ppc_64.o.d -o ad_ppc_64.o ../generated/adfiles/ad_ppc_64.cpp "/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/share/vm/gc_implementation/g1/ptrQueue.hpp", line 246.3: 1540-1101 (W) A return value of type "bool" is expected. "/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/share/vm/gc_implementation/shared/gcWhen.hpp", line 45.3: 1540-1101 (W) A return value of type "const char *" is expected. "/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/share/vm/gc_interface/gcName.hpp", line 58.3: 1540-1101 (W) A return value of type "const char *" is expected. "/sapmnt/home1/d045726/oJ/8065585-hs-gc/src/share/vm/gc_implementation/g1/g1YCTypes.hpp", line 48.3: 1540-1101 (W) A return value of type "const char *" is expected. -----Original Message----- From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] Sent: Mittwoch, 15. April 2015 16:59 To: Lindenmaier, Goetz; hotspot-dev Source Developers Subject: Re: 8065585: Change ShouldNotReachHere() to never return Hi Goetz, On 2015-04-15 16:54, Lindenmaier, Goetz wrote: > Hi Stefan, > > Thanks for doing this fix, I would appreciate this cleanup a lot. > I just built it on aix. So far, the attribute unfortunately does not > suppress the warnings. I'll investgate this some more ... Thanks for verifying the patch. What warnings are you getting? Are you running with -Wuninitialized? Thanks, StefanK > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Stefan Karlsson > Sent: Mittwoch, 15. April 2015 12:49 > To: hotspot-dev Source Developers > Subject: RFR: 8065585: Change ShouldNotReachHere() to never return > > Hi, > > Today the it's possible for the code to return out from > ShouldNotReachHere() calls. This sometimes forces us to add return > statements and assignments to parts of the code where it they don't make > sense. By telling the compiler that ShouldNotReachHere is a dead end, we > can get rid of these unnecessary constructs. > > For example: > > 1) We could get rid of return statements after ShouldNotReachHere(): > > bool is_marked() { > // actual code here > > // Execution path that "should not" happen. > ShouldNotReachHere(); > return false; > } > > 2) The following code will actually use an uninitialized value today. > The compiler will find this if we turn on -Wuninitialized. But if we > change ShouldNotReachHere() to not return, the compiler will stop > complaining because report(type) will never be called with an > uninitialized value: > > int type; > switch (value) { > case TYPE_OOP: type = 0; break; > case TYPE_KLASS: type = 1; break; > default: ShouldNotReachHere(); > } > report(type) > > > The patch changes the following functions and defines to never return: > - fatal(...) > - ShouldNotCallThis() > - ShouldNotReachHere() > - report_vm_out_of_memory(...) > - vm_exit_out_of_memory(...) > > but leaves the following unchanged: > - Unimplemented() > - Untested(...) > - guarantee(...) > > We might want to change the the behavior of Unimplemented() and > Untested(...), but they are used a lot in compiler code, so I've not > changed them for this patch. There has been request to leave > guarantee(...) unchanged so that they can be turned off in production code. > > I had to change some instance of ShouldNotReachHere() in destructors, > because the VS C++ compiler complained about potential memory leaks. > > http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8065585 > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Apr 16 09:31:43 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 16 Apr 2015 11:31:43 +0200 Subject: RFR: 8077936: Remove the unused java_lang_invoke_CallSite::target_volatile Message-ID: <552F817F.4010101@oracle.com> Hi, Please review this small patch to remove unused code. http://cr.openjdk.java.net/~stefank/8077936/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8077936 Thanks, StefanK From vladimir.x.ivanov at oracle.com Thu Apr 16 10:33:48 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 16 Apr 2015 13:33:48 +0300 Subject: RFR: 8077936: Remove the unused java_lang_invoke_CallSite::target_volatile In-Reply-To: <552F817F.4010101@oracle.com> References: <552F817F.4010101@oracle.com> Message-ID: <552F900C.5040401@oracle.com> Good. Best regards, Vladimir Ivanov On 4/16/15 12:31 PM, Stefan Karlsson wrote: > Hi, > > Please review this small patch to remove unused code. > > http://cr.openjdk.java.net/~stefank/8077936/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8077936 > > Thanks, > StefanK From aph at redhat.com Thu Apr 16 10:56:01 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Apr 2015 11:56:01 +0100 Subject: Places we should use the new ByteBuffer intrinsics In-Reply-To: <55127C35.8000108@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> <55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com> <55127C35.8000108@redhat.com> Message-ID: <552F9541.10903@redhat.com> We discussed where we should be using the new Unsafe unaligned intrinsics. I found these: ByteBufferAs$Type$Buffer. These use slow bytewise accesses, and should be converted. DirectByteBuffer. This probes for unaligned memory support and uses byte-by-byte accesses if it isn't available. We should probably convert it after doing some performance measurements. sun.security.provider.ByteArrayAccess. This uses a lot of hand-carved custom code to handle data which largely duplicates that now in Unsafe, but big-endian platforms (and little-endian ones which don't support unaligned accesses) always use byte-by-byte accesses for unaligned data. Again, we should probably convert it after doing some performance measurements. Andrew. From stefan.karlsson at oracle.com Thu Apr 16 11:42:48 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 16 Apr 2015 13:42:48 +0200 Subject: RFR: 8077936: Remove the unused java_lang_invoke_CallSite::target_volatile In-Reply-To: <552F900C.5040401@oracle.com> References: <552F817F.4010101@oracle.com> <552F900C.5040401@oracle.com> Message-ID: <552FA038.7070106@oracle.com> On 2015-04-16 12:33, Vladimir Ivanov wrote: > Good. Thanks, Vladimir. StefanK > > Best regards, > Vladimir Ivanov > > On 4/16/15 12:31 PM, Stefan Karlsson wrote: >> Hi, >> >> Please review this small patch to remove unused code. >> >> http://cr.openjdk.java.net/~stefank/8077936/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8077936 >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Thu Apr 16 12:07:27 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 16 Apr 2015 14:07:27 +0200 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552F1D05.40209@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> Message-ID: <552FA5FF.7070702@oracle.com> Hi David, On 2015-04-16 04:23, David Holmes wrote: > Hi Stefan, > > Stefan Karlsson wrote: >> Hi, >> >> Today the it's possible for the code to return out from >> ShouldNotReachHere() calls. This sometimes forces us to add return >> statements and assignments to parts of the code where it they don't make >> sense. By telling the compiler that ShouldNotReachHere is a dead end, we >> can get rid of these unnecessary constructs. >> >> For example: >> >> 1) We could get rid of return statements after ShouldNotReachHere(): >> >> bool is_marked() { >> // actual code here >> >> // Execution path that "should not" happen. >> ShouldNotReachHere(); >> return false; >> } >> >> 2) The following code will actually use an uninitialized value today. >> The compiler will find this if we turn on -Wuninitialized. But if we >> change ShouldNotReachHere() to not return, the compiler will stop >> complaining because report(type) will never be called with an >> uninitialized value: >> >> int type; >> switch (value) { >> case TYPE_OOP: type = 0; break; >> case TYPE_KLASS: type = 1; break; >> default: ShouldNotReachHere(); >> } >> report(type) >> >> >> The patch changes the following functions and defines to never return: >> - fatal(...) >> - ShouldNotCallThis() >> - ShouldNotReachHere() >> - report_vm_out_of_memory(...) > > You changed the behaviour of this one in the Debugging case - it no > longer returns. > >> - vm_exit_out_of_memory(...) >> >> but leaves the following unchanged: >> - Unimplemented() >> - Untested(...) >> - guarantee(...) >> We might want to change the the behavior of Unimplemented() and >> Untested(...), but they are used a lot in compiler code, so I've not >> changed them for this patch. There has been request to leave >> guarantee(...) unchanged so that they can be turned off in production >> code. >> >> I had to change some instance of ShouldNotReachHere() in destructors, >> because the VS C++ compiler complained about potential memory leaks. > > The approach seems inconsistent though - sometimes a switch to a > guarantee, sometimes removal of the destructor and making it private > (which doesn't quite give the same level of protection). > >> http://cr.openjdk.java.net/~stefank/8065585/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8065585 > > In summary: > > The BREAKPOINTs have been moved out of the macros into the functions, > and the macros then simplified to direct calls. Ok. > > Some calls now have the NORETURN_ATTRIBUTE applied. Ok. > > Calls to functions that have NORETURN_ATTRIBUTE can be cleaned up if > they previously allowed for the function returning. Ok. > > So first question: is this attribute handled correctly by all the > compilers we need to consider? > > Second, more important question: have you examined how this attribute > affects the ability to walk the stack? We have already seen issues on > some platforms where library functions, like abort(), have the > noreturn attribute and as a result the call is optimized in a way that > prevents the stack from being walked - see eg: > > https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 > > > though this: > > https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 > > suggests that problem may have been addressed by the libc folk. But it > still raises the question as to how our own noreturn functions will be > handled and how they will affect stacktrace generation in hs_err logs > or via gdb. I added a call to fatal(...) in the GC code. I get correct stacktraces in gdb, but the stacktraces in the hs_err files are broken with fastdebug and product builds: Stack: [0x00007f12518d2000,0x00007f12519d3000], sp=0x00007f12519d0eb0, free space=1019k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11db44a] VMError::report_and_die()+0x1ba V [libjvm.so+0x7efb80] report_vm_error(char const*, int, char const*, char const*)+0x90 V [libjvm.so+0x7efc49] report_vm_error_noreturn(char const*, int, char const*, char const*)+0x9 V [libjvm.so+0x7efc63] V [libjvm.so+0xfd7937] V [libjvm.so+0xfeec51] ... Thanks, StefanK > > Thanks, > David > >> >> Thanks, >> StefanK >> From david.holmes at oracle.com Thu Apr 16 12:33:44 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Apr 2015 22:33:44 +1000 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552FA5FF.7070702@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> <552FA5FF.7070702@oracle.com> Message-ID: <552FAC28.2060407@oracle.com> Hi Stefan, trimming ... On 16/04/2015 10:07 PM, Stefan Karlsson wrote: > On 2015-04-16 04:23, David Holmes wrote: >> Second, more important question: have you examined how this attribute >> affects the ability to walk the stack? We have already seen issues on >> some platforms where library functions, like abort(), have the >> noreturn attribute and as a result the call is optimized in a way that >> prevents the stack from being walked - see eg: >> >> https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 >> >> >> though this: >> >> https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 >> >> suggests that problem may have been addressed by the libc folk. But it >> still raises the question as to how our own noreturn functions will be >> handled and how they will affect stacktrace generation in hs_err logs >> or via gdb. > > I added a call to fatal(...) in the GC code. I get correct stacktraces > in gdb, but the stacktraces in the hs_err files are broken with > fastdebug and product builds: Which platforms? > Stack: [0x00007f12518d2000,0x00007f12519d3000], sp=0x00007f12519d0eb0, > free space=1019k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0x11db44a] VMError::report_and_die()+0x1ba > V [libjvm.so+0x7efb80] report_vm_error(char const*, int, char const*, > char const*)+0x90 > V [libjvm.so+0x7efc49] report_vm_error_noreturn(char const*, int, char > const*, char const*)+0x9 > V [libjvm.so+0x7efc63] > V [libjvm.so+0xfd7937] > V [libjvm.so+0xfeec51] > ... So what is the plan: try to get hs_err working again? Or file this under "well it seemed like a good idea"? ;-) Cheers, David > Thanks, > StefanK > > > >> >> Thanks, >> David >> >>> >>> Thanks, >>> StefanK >>> > From paul.sandoz at oracle.com Thu Apr 16 13:25:33 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 Apr 2015 15:25:33 +0200 Subject: Places we should use the new ByteBuffer intrinsics In-Reply-To: <552F9541.10903@redhat.com> References: <550330CE.3030607@redhat.com> <550710BD.5060301@redhat.com> <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com> <5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com> <550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com> <550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com> <550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com> <550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com> <55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com> <55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com> <55127C35.8000108@redhat.com> <552F9541.10903@redhat.com> Message-ID: On Apr 16, 2015, at 12:56 PM, Andrew Haley wrote: > We discussed where we should be using the new Unsafe unaligned > intrinsics. > > I found these: > They look like good candidates. I did a quick search in the JDK src code (usages of getByte/Short/Int/Long) and could not find any others. > ByteBufferAs$Type$Buffer. These use slow bytewise accesses, > and should be converted. > > DirectByteBuffer. This probes for unaligned memory support > and uses byte-by-byte accesses if it isn't available. We > should probably convert it after doing some performance > measurements. > That should be a nice cleanup, i would be surprised if it resulted in any performance issues but it would be good to check as you say. > sun.security.provider.ByteArrayAccess. This uses a lot of > hand-carved custom code to handle data which largely > duplicates that now in Unsafe, but big-endian platforms (and > little-endian ones which don't support unaligned accesses) > always use byte-by-byte accesses for unaligned data. Again, > we should probably convert it after doing some performance > measurements. > There is also an assumption in the following comment in sun.security.provider.ByteArrayAccess.b2lBig that i presume is no longer relevant: // In the current HotSpot memory layout, the first element of a // byte[] is only 32-bit aligned, not 64-bit. // That means we could use getLong() only for offset 4, 12, etc., // which would rarely occur in practice. Instead, we use an // optimization that uses getInt() so that it works for offset 0. Paul. From stefan.karlsson at oracle.com Thu Apr 16 13:32:32 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 16 Apr 2015 15:32:32 +0200 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552FAC28.2060407@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> <552FA5FF.7070702@oracle.com> <552FAC28.2060407@oracle.com> Message-ID: <552FB9F0.1030401@oracle.com> On 2015-04-16 14:33, David Holmes wrote: > Hi Stefan, > > trimming ... > > On 16/04/2015 10:07 PM, Stefan Karlsson wrote: >> On 2015-04-16 04:23, David Holmes wrote: >>> Second, more important question: have you examined how this attribute >>> affects the ability to walk the stack? We have already seen issues on >>> some platforms where library functions, like abort(), have the >>> noreturn attribute and as a result the call is optimized in a way that >>> prevents the stack from being walked - see eg: >>> >>> https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 >>> >>> >>> >>> though this: >>> >>> https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 >>> >>> suggests that problem may have been addressed by the libc folk. But it >>> still raises the question as to how our own noreturn functions will be >>> handled and how they will affect stacktrace generation in hs_err logs >>> or via gdb. >> >> I added a call to fatal(...) in the GC code. I get correct stacktraces >> in gdb, but the stacktraces in the hs_err files are broken with >> fastdebug and product builds: > > Which platforms? On Linux x86 and x86_64. > >> Stack: [0x00007f12518d2000,0x00007f12519d3000], sp=0x00007f12519d0eb0, >> free space=1019k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> V [libjvm.so+0x11db44a] VMError::report_and_die()+0x1ba >> V [libjvm.so+0x7efb80] report_vm_error(char const*, int, char const*, >> char const*)+0x90 >> V [libjvm.so+0x7efc49] report_vm_error_noreturn(char const*, int, char >> const*, char const*)+0x9 >> V [libjvm.so+0x7efc63] >> V [libjvm.so+0xfd7937] >> V [libjvm.so+0xfeec51] >> ... > > So what is the plan: try to get hs_err working again? Or file this > under "well it seemed like a good idea"? ;-) I'm leaning towards "seemed like a good idea", unless someone has an easy fix for these problems. Thanks, StefanK > > Cheers, > David > >> Thanks, >> StefanK >> >> >> >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> StefanK >>>> >> From max.ockner at oracle.com Thu Apr 16 14:15:05 2015 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 16 Apr 2015 10:15:05 -0400 Subject: RFR: 8029630: Print thread id hex representation in error messages. In-Reply-To: <552F1FEE.2080105@oracle.com> References: <551D9AC6.50208@oracle.com> <55232E90.7060701@oracle.com> <5526CEDF.20004@oracle.com> <55272BDA.2060908@oracle.com> <552C262A.1070002@oracle.com> <552C49B8.9070805@oracle.com> <552E6C8C.3050607@oracle.com> <552F1FEE.2080105@oracle.com> Message-ID: <552FC3E9.9040505@oracle.com> Ok, I will commit this. Thanks to David, Harold, Thomas, and Staffan for your help. Max On 4/15/2015 10:35 PM, David Holmes wrote: > Thumbs up! > > Thanks, > David > > On 15/04/2015 11:50 PM, Max Ockner wrote: >> I had a few things mixed up in the last webrev. Either way, I have >> changed this, hopefully for the last time. vmError.cpp now uses >> INTPTR_FORMAT. >> >> webrev: http://cr.openjdk.java.net/~mockner/8029630.final/ >> >> tested with jprt. >> >> >> Thanks, >> Max >> >> On 4/13/2015 6:56 PM, David Holmes wrote: >>> Hi Max, >>> >>> On 14/04/2015 6:25 AM, Max Ockner wrote: >>>> Hello, >>>> >>>> Modified this again. I defined TID_FORMAT to make it a better semantic >>>> match. >>> >>> Not sure that actually improves anything. There is no "tid" type. >>> Primarily what we have is a function returning intx and we want to >>> print it as hex. I still think INTPTR_FORMAT suffices. Otherwise >>> INTX_HEX_FORMAT is you really want to introduce something new - but I >>> don't suggest doing that. >>> >>>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.8/ >>> >>> I still see vmError.cpp using PTR_FORMAT ?? >>> >>> Sorry. >>> >>> David >>> >>>> Tested with jprt >>>> >>>> Thanks, >>>> Max >>>> >>>> On 4/9/2015 9:48 PM, David Holmes wrote: >>>>> Hi Max, >>>>> >>>>> On 10/04/2015 5:11 AM, Max Ockner wrote: >>>>>> Hi again, >>>>>> After working past some build issues, I have a new webrev. I've >>>>>> changed >>>>>> %x to PTR_FORMAT, and I've removed the modification to thread.cpp >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~mockner/8029630.4/ >>>>> >>>>> I think INTPTR_FORMAT would be more of a semantic match as the thread >>>>> id is not a pointer type. >>>>> >>>>> David >>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 4/6/2015 9:10 PM, David Holmes wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> On 3/04/2015 5:38 AM, Max Ockner wrote: >>>>>>>> Hello, >>>>>>>> Please review this change: >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029630 >>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8029630.2/ >>>>>>>> Summary: Existing error messages for vm crashes print the decimal >>>>>>>> representation of the current thread id. The message format has >>>>>>>> been >>>>>>>> changed to print the hex value of the thread id. >>>>>>> >>>>>>> src/share/vm/runtime/thread.cpp >>>>>>> >>>>>>> The change is incorrect and unnecessary. 'this' is a pointer >>>>>>> type so >>>>>>> INTPTR_FORMAT seems correct (though it may need p2i(this)?) >>>>>>> while %x >>>>>>> assumes 'this' is always 32-bit. Further INTPTR_FORMAT is >>>>>>> already hex >>>>>>> not decimal. >>>>>>> >>>>>>> src/share/vm/utilities/vmError.cpp >>>>>>> >>>>>>> As Thomas pointed out%x assumes 32-bit and so is incorrect for intx >>>>>>> type. As intx is a typedef for intptr_t then INTPTR_FORMAT >>>>>>> should be >>>>>>> usable here as well. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Tested with jtreg runtime to make sure nothing was broken. I >>>>>>>> tested >>>>>>>> the >>>>>>>> new functionality separately. I crashed the vm and examined the >>>>>>>> debugger >>>>>>>> output to make sure the hexadecimal thread id printed in the error >>>>>>>> message matched one of the threads listed by the debugger. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>> >>>> >> From daniel.daugherty at oracle.com Thu Apr 16 17:01:29 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Apr 2015 11:01:29 -0600 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <552832AF.8080204@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> Message-ID: <552FEAE9.6020103@oracle.com> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/classfile/javaClasses.cpp No comments. src/share/vm/oops/cpCache.hpp No comments. src/share/vm/oops/cpCache.cpp No comments. src/share/vm/prims/methodHandles.hpp No comments. src/share/vm/prims/methodHandles.cpp Now we get to the meat of the change. :-) Instead of the double iteration loop in the old code, you are now taking advantage of the recent 'orig_method_idnum()' work. So you are not only reducing the iteration count, you are also reducing the number of adjustment calls that need to be made. Cool. src/share/vm/prims/jvmtiRedefineClasses.cpp No comments. Thumbs up. Do you happen to have any info on perf improvements for this fix? No big deal if you don't. Dan On 4/10/15 2:29 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen and Dan, > > This is the second class redefinition scalability/optimization fix > that is in my queue to push into 9 and 8u60. > > The approach is similar to the first one but much smaller. > For convenience, these are the links to the first scalability fix: > Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ > > Please, let me know if you have any chance to review this. > This is the last one that is waiting for your attention! :) > > Thanks, > Serguei > > On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8073705 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >> >> >> >> Summary: >> >> This is the 2-nd round of performance/calability fixes in class >> redefinition. >> This time, the two remaining issues that were left alone in the >> first round fix: >> - optimized ConstantPoolCache::adjust_method_entries() is used >> for previous versions >> - the MemberNameTable::adjust_method_entries() has been >> optimized too >> - some cleanup >> >> >> Testing: >> In progress: nsk redefine classes tests, JTREG >> java/lang/instrument, com/sun/jdi >> >> >> Thanks, >> Serguei >> > From aph at redhat.com Thu Apr 16 17:07:44 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Apr 2015 18:07:44 +0100 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E4FD45.5090106@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <54E457E0.20408@redhat.com> <54E45842.9030102@redhat.com> <54E473D1.8000506@redhat.com> <54E4FD45.5090106@oracle.com> Message-ID: <552FEC60.3060308@redhat.com> On 02/18/2015 08:59 PM, Vladimir Kozlov wrote: > The code which eliminates MemBars for scalarized objects was added in jdk8: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67 Right enough, but it only works with boxed objects. The Precedent of the MemBarNode is needed by MemBarNode::Ideal, and it's checked for: // Eliminate volatile MemBars for scalar replaced objects. if (can_reshape && req() == (Precedent+1)) { ... think about eliminating the MemBar So if there's no Precedent, none of the barrier elimination is done. The only thing that sets the MemBar's Precedent is here: In parse::do_put_xxx // Preserve allocation ptr to create precedent edge to it in membar // generated on exit from constructor. if (C->eliminate_boxing() && adr_type->isa_oopptr() && adr_type->is_oopptr()->is_ptr_to_boxed_value() && AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { set_alloc_with_final(obj); } The barrier is created in parse1, and uses alloc_with_final: if (method()->is_initializer() && (wrote_final() || PPC64_ONLY(wrote_volatile() ||) (AlwaysSafeConstructors && wrote_fields()))) { _exits.insert_mem_bar(Op_MemBarRelease, alloc_with_final()); So, it looks to me as though even the most trivial user-defined constructors with final fields will never eliminate barriers. I don't know what the thinking is here. Why does it matter whether the type being constructed is a boxed value? Andrew. From kim.barrett at oracle.com Thu Apr 16 17:34:10 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 16 Apr 2015 13:34:10 -0400 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBF20D@DEWDFEMB12A.global.corp.sap> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552E7CA9.5020901@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF20D@DEWDFEMB12A.global.corp.sap> Message-ID: <2A911659-4716-42E7-9276-2D8774E49895@oracle.com> On Apr 16, 2015, at 4:50 AM, Lindenmaier, Goetz wrote: > the IBM docu says that __notreturn__ affects only warnings about > uninitialized variables, not about missing returns. I would summarize it as saying it does affect ununitialized variable warnings, and as being silent on the subject of missing returns. > It also says that registers are not stored on a call. > http://publibfp.boulder.ibm.com/epubs/pdf/c1473260.pdf page 193. Actually, it says registers saved by the caller might not be restored before the call. > For the compiler flags and warnings I get see the compile output below. The missing return warnings are quite disappointing, even to the level of a bug. Though the feature documentation is so light, it could arguably do almost anything. XLC appears to provide at least three mechanisms for indicating a function doesn't return. The __attribute__ method has the weakest description: "indicate to the compiler that the function is not intended to return." The others are _Noreturn function attribute (similar to inline) - "declares a function that does not return to its caller." Added by C11 and requires special compiler options to enable. #pragma leaves(function_name, ...) - "Informs the compiler that a named function never returns to the instruction following a call to that function." Goetz, if you have some time (yeah, right), it might be interesting to find out if either of the other two behave any differently with regard to missing return warnings. I will be sad if this proposed change has to be dropped because an otherwise well-reputed compiler was so lame in this respect. I really dislike dummy return statements and not having -Wuninitialized turned on. From kim.barrett at oracle.com Thu Apr 16 17:45:40 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 16 Apr 2015 13:45:40 -0400 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552FA5FF.7070702@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> <552FA5FF.7070702@oracle.com> Message-ID: On Apr 16, 2015, at 8:07 AM, Stefan Karlsson wrote: > > I added a call to fatal(...) in the GC code. I get correct stacktraces in gdb, but the stacktraces in the hs_err files are broken with fastdebug and product builds: > > Stack: [0x00007f12518d2000,0x00007f12519d3000], sp=0x00007f12519d0eb0, free space=1019k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x11db44a] VMError::report_and_die()+0x1ba > V [libjvm.so+0x7efb80] report_vm_error(char const*, int, char const*, char const*)+0x90 > V [libjvm.so+0x7efc49] report_vm_error_noreturn(char const*, int, char const*, char const*)+0x9 > V [libjvm.so+0x7efc63] > V [libjvm.so+0xfd7937] > V [libjvm.so+0xfeec51] > ? > I remember seeing an email thread recently asking about how gdb produced stack traces, because it was successful in some cases where our mechanisms for producing hs_err files was not. So there might already be a bug about it. But that does seem like it makes this whole proposal not work until that problem is fixed. From vladimir.x.ivanov at oracle.com Thu Apr 16 18:12:58 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 16 Apr 2015 21:12:58 +0300 Subject: [9] RFR (S): 8059340: ConstantPool::_resolved_references is missing in heap dump In-Reply-To: <24133E27-C024-41D8-80EF-B5707CFF0D0C@oracle.com> References: <542971DC.2090803@oracle.com> <24133E27-C024-41D8-80EF-B5707CFF0D0C@oracle.com> Message-ID: <552FFBAA.6050103@oracle.com> (sorry for really late response; just got enough time to return to the bug) Coleen, Staffan, Thanks a lot for the feedback! After thinking about the fix more, I don't think that using reserved oop slot in CLASS DUMP for recording _resolved_references is the best thing to do. IMO the change causes too much work for the users (heap dump analysis tools). It needs specification update and then heap dump analyzers should be updated as well. I have 2 alternative approaches (hacky and not-so-hacky :-)): - artificial class static field in the dump ("" + optional id to guarantee unique name); - add j.l.Class::_resolved_references field; Not sure how much overhead (mostly reads from bytecode) the move from ConstantPool to j.l.Class adds, so I propose just to duplicate it for now. What do you think about that? Best regards, Vladimir Ivanov On 10/6/14 11:35 AM, Staffan Larsen wrote: > This looks like a good approach. However, there are a couple of more places that need to be updated. > > The hprof binary format is described in jdk/src/jdk.hprof.agent/share/native/libhprof/manual.html and needs to be updated. It?s also more formally specified in hprof_b_spec.h in the same directory. > > The hprof JVMTI agent in jdk/src/jdk.hprof.agent code would also need to be updated to show this field. Since this is a JVMTI agent it needs to be possible to find the resolved_refrences array via the JVMTI heap walking API. Perhaps that already works? - I haven?t looked. > > Finally, the Serviceability Agent implements yet another hprof binary dumper in hotspot/agent//src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java which also needs to write this reference. > > Thanks, > /Staffan > > On 29 sep 2014, at 16:51, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8059340/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8059340 >> >> VM heap dump doesn't contain ConstantPool::_resolved_references for classes which have resolved references. >> >> ConstantPool::_resolved_references points to an Object[] holding resolved constant pool entries (patches for VM anonymous classes, linked CallSite & MethodType for invokedynamic instructions). >> >> I've decided to use reserved slot in HPROF class header format. >> It requires an update in jhat to correctly display new info. >> >> The other approach I tried was to dump the reference as a fake static field [1], but storing VM internal ConstantPool::_resolved_references among user defined fields looks confusing. >> >> Testing: manual (verified that corresponding arrays are properly linked in Nashorn heap dump). >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://cr.openjdk.java.net/~vlivanov/8059340/static > From christian.tornqvist at oracle.com Thu Apr 16 19:05:19 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 16 Apr 2015 15:05:19 -0400 Subject: RFR(S): 8077608 - [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode In-Reply-To: <40AC4AD3-94C8-4FA2-8BE1-77F805B5F228@oracle.com> References: <14e901d075f5$58896120$099c2360$@oracle.com> <40AC4AD3-94C8-4FA2-8BE1-77F805B5F228@oracle.com> Message-ID: <0f0b01d07878$48c9d5a0$da5d80e0$@oracle.com> Hi Staffan, Thanks for your feedback, I've changed ProcessTools to pass in the classpath using -cp instead, java.class.path seems to contain what we need. Please see the updated webrev at: http://cr.openjdk.java.net/~ctornqvi/webrev/8077608/webrev.01/ Thanks, Christian -----Original Message----- From: Staffan Larsen [mailto:staffan.larsen at oracle.com] Sent: Monday, April 13, 2015 11:13 AM To: Christian Tornqvist Cc: hotspot-dev at openjdk.java.net Developers Subject: Re: RFR(S): 8077608 - [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode Thanks for doing this work. One comment below. > On 13 apr 2015, at 16:22, Christian Tornqvist wrote: > > Hi everyone, > > > > Please review this small change which enables us to run the Hotspot > jtreg tests in agentvm mode. This change also sets JPRT to use this > mode. Results when running on my 32-thread Windows machine using a fastdebug build: > > > > Othervm (this is what we run today): 4h5m > > Agentvm (still without concurrency): 1h45m > > > > The same speedup can be seen in JPRT across all platforms, I've tested > these changes 25-30 times in JPRT. > > > > In order to make all the tests work correctly I had to make some small > changes: > > > > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java > > Turns out that the CLASSPATH environment variable has a different > value when running with agentvm, it's now appending test.src and > test.class.path when creating child processes. This fixed about 40 of the failures. This looks strange to me. Should we instead add ?-cp {test.class.path}:{test.src}?? /Staffan > > > > test/sanity/WhiteBox.java > > Fails to clean out the sun.hotspot.WhiteBox.class on Windows machines, > the only reason for cleaning this file out is so that the other tests > in /test/sanity doesn't pick up the incorrect WhiteBox.class. Simple > workaround is to move the test/sanity/WhiteBox.java into its own > directory to prevent the other tests from picking up this class file. > > > > test/compiler/uncommontrap/TestUnstableIfTrap.java > > Intermittent IO problems on Windows when reading the XML files, > workaround is to run this to keep running this test in othervm mode. > > > > test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java > > ClassNotFoundException when running in agentvm mode, didn't spend too > much time debugging this. Workaround is to keep running this test in > othervm mode. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8077608/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8077608 > > > > Thanks, > > Christian > > > > > From john.r.rose at oracle.com Thu Apr 16 19:34:05 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Apr 2015 12:34:05 -0700 Subject: RFR: 8077936: Remove the unused java_lang_invoke_CallSite::target_volatile In-Reply-To: <552F817F.4010101@oracle.com> References: <552F817F.4010101@oracle.com> Message-ID: <3858C8F2-0154-40B1-8646-8A9856AD5F68@oracle.com> Good, reviewed! On Apr 16, 2015, at 2:31 AM, Stefan Karlsson wrote: > > Hi, > > Please review this small patch to remove unused code. > > http://cr.openjdk.java.net/~stefank/8077936/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8077936 > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Apr 16 19:39:20 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 16 Apr 2015 21:39:20 +0200 Subject: RFR: 8077936: Remove the unused java_lang_invoke_CallSite::target_volatile In-Reply-To: <3858C8F2-0154-40B1-8646-8A9856AD5F68@oracle.com> References: <552F817F.4010101@oracle.com> <3858C8F2-0154-40B1-8646-8A9856AD5F68@oracle.com> Message-ID: <55300FE8.10907@oracle.com> On 2015-04-16 21:34, John Rose wrote: > Good, reviewed! Thanks, John. StefanK > > On Apr 16, 2015, at 2:31 AM, Stefan Karlsson wrote: >> Hi, >> >> Please review this small patch to remove unused code. >> >> http://cr.openjdk.java.net/~stefank/8077936/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8077936 >> >> Thanks, >> StefanK From mark.reinhold at oracle.com Thu Apr 16 22:54:21 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Apr 2015 15:54:21 -0700 (PDT) Subject: JEP 245: Validate JVM Command-Line Flag Arguments Message-ID: <20150416225421.C35DE567AC@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/245 - Mark From vladimir.kozlov at oracle.com Thu Apr 16 23:04:15 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Apr 2015 16:04:15 -0700 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <552FEC60.3060308@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <54E457E0.20408@redhat.com> <54E45842.9030102@redhat.com> <54E473D1.8000506@redhat.com> <54E4FD45.5090106@oracle.com> <552FEC60.3060308@redhat.com> Message-ID: <55303FEF.1010402@oracle.com> Because that code was added and tested only for boxed objects (goal of 6934604) - I wanted to avoid wider effects of those changes. I think we can remove the limitation now in jd9 sources since we have enough time to tests it. Regards, Vladimir On 4/16/15 10:07 AM, Andrew Haley wrote: > On 02/18/2015 08:59 PM, Vladimir Kozlov wrote: >> The code which eliminates MemBars for scalarized objects was added in jdk8: >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67 > > Right enough, but it only works with boxed objects. The > Precedent of the MemBarNode is needed by MemBarNode::Ideal, > and it's checked for: > > // Eliminate volatile MemBars for scalar replaced objects. > if (can_reshape && req() == (Precedent+1)) { > ... think about eliminating the MemBar > > So if there's no Precedent, none of the barrier elimination is done. > > The only thing that sets the MemBar's Precedent is here: > > In parse::do_put_xxx > > // Preserve allocation ptr to create precedent edge to it in membar > // generated on exit from constructor. > if (C->eliminate_boxing() && > adr_type->isa_oopptr() && adr_type->is_oopptr()->is_ptr_to_boxed_value() && > AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { > set_alloc_with_final(obj); > } > > The barrier is created in parse1, and uses alloc_with_final: > > if (method()->is_initializer() && > (wrote_final() || > PPC64_ONLY(wrote_volatile() ||) > (AlwaysSafeConstructors && wrote_fields()))) { > _exits.insert_mem_bar(Op_MemBarRelease, alloc_with_final()); > > So, it looks to me as though even the most trivial user-defined > constructors with final fields will never eliminate barriers. > > I don't know what the thinking is here. Why does it matter whether > the type being constructed is a boxed value? > > Andrew. > From calvin.cheung at oracle.com Thu Apr 16 23:23:05 2015 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 16 Apr 2015 16:23:05 -0700 Subject: RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: <552F5314.3070002@oracle.com> References: <552EC286.5000005@oracle.com> <552EDD1F.1030308@oracle.com> <552EF384.4040103@oracle.com> <552F508F.7050809@oracle.com> <552F5314.3070002@oracle.com> Message-ID: <55304459.7000008@oracle.com> On 4/15/2015 11:13 PM, Ioi Lam wrote: > On 4/15/15 11:02 PM, Stefan Karlsson wrote: >> On 2015-04-16 01:25, Calvin Cheung wrote: >>> Hi Stefan, >>> >>> Thanks for your review. >>> >>> On 4/15/2015 2:50 PM, Stefan Karlsson wrote: >>>> Hi Calvin, >>>> >>>> On 2015-04-15 21:56, Calvin Cheung wrote: >>>>> Please review this second version of the fix. >>>>> >>>>> This version has 2 new functions (equals() and not_equals()) in >>>>> the Symbol class. >>>>> It replaces the Symbol* == and != comparisons with those 2 >>>>> function calls. >>>>> >>>>> Pro: >>>>> >>>>> It has a much smaller changeset than the first version. >>>>> >>>>> Con: >>>>> >>>>> Someone may by mistake introduce a new line of (Symbol* == Symbol*). >>>>> >>>>> We will mitigate this by enhancing our internal static analysis >>>>> tool to flag the >>>>> above code in the future. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8071627 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/ >>>> >>>> This is a much less intrusive change than the previous patch. Thanks. >>>> >>>> >>>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/classFileParser.cpp.patch >>>> >>>> >>>> Is there a reason why you added not_equals: >>>> - if (name != vmSymbols::object_initializer_name()) { >>>> + if >>>> (name->not_equals(vmSymbols::object_initializer_name())) { >>>> >>>> instead of just: >>>> + if >>>> (!name->equals(vmSymbols::object_initializer_name())) { >>> We think that it's clearer to have not_equals() than using the ! as >>> in the above. >> >> OK. IMHO, negating boolean expressions with ! is a common construct >> so I'm not sure not_equals is clearer. >> >>>> >>>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/systemDictionary.cpp.udiff.html >>>> >>>> ! assert(parsed_name->not_equals(NULL), "Sanity"); >>>> >>>> >>>> You use symbol == NULL but not symbol != NULL, which seems >>>> inconsistent to me. >>> I'm not sure I understand this comment. >>> Are you referring to the following section of the udiff? >>> *** 1104,1115 **** >>> --- 1104,1115 ---- >>> Exceptions::_throw_msg(THREAD_AND_LOCATION, >>> vmSymbols::java_lang_SecurityException(), message); >>> } >>> >>> if (!HAS_PENDING_EXCEPTION) { >>> ! assert(parsed_name != NULL, "Sanity"); >>> ! assert(class_name == NULL || class_name == parsed_name, "name >>> mismatch"); >>> ! assert(parsed_name->not_equals(NULL), "Sanity"); >>> ! assert(class_name == NULL || class_name->equals(parsed_name), >>> "name mismatch"); >>> // Verification prevents us from creating names with dots in >>> them, this >>> // asserts that that's the case. >>> assert(is_internal_format(parsed_name), >>> "external class name format used internally"); >>> >>> I don't see anything incorrect there. >> >> I'm not talking about being correct or incorrect. I would have >> expected to see either: >> >> 1) Use pointer (in)equality when checking for NULL: >> class_name == NULL >> parsed_name != NULL >> >> or >> >> 2) strictly use the (not_)equals function when checking for NULL: >> class_name->equals(NULL) >> parsed_name->not_equals(NULL) >> or even: >> class_name->equals(NULL) >> !parsed_name->equals(NULL)) >> >> but not what you have today, where you mix the two ways to NULL check >> class_name == NULL >> parsed_name->not_equals(NULL) >> > > I think it's better to use (symbol == NULL) everywhere. Calling > symbol->equals(NULL) while symbol itself is NULL is confusing -- it > raises questions like "will this crash in debug mode", so we'd better > avoid it. I've fixed all those NULL comparison back to (symbol == NULL) or (symbol != NULL). > > In our static analysis tool, we need to flags checks for (symbol1 == > symbol2), but should allow (symbol == NULL). > > - Ioi > >> >>>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html >>>> >>>> >>>> *+ inline bool equals(const Symbol* other) const {* >>>> *+ if (this && other) { >>>> * >>>> First, pointers should be checked null checked with == or !=. See: >>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-Miscellaneous >>>> >>> >>> I will fix it. >>> >>>> >>>> Second, I recall some discussion that null checking the 'this' >>>> pointer is undefined behavior. Though, we do it in other places so >>>> this isn't worse, I think. >>>> >>>> Did you use your previous patch to find all Symbol* compares? >>> >>> Yes. Essentially comment out the bodies of the == and != operators >>> in SymbolRef. >>> Rebuilding hotspot resulting a lot of "undefined reference to >>> SymbolRef::operator==" link errors. >>> Then go through those error and change a == b to a->equals(b) and a >>> != b to a->not_equals(b). >>> Obviously change SymbolRef back to Symbol*. >> >> Great. >> >> One more thing: >> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html >> >> >> *+ if (this->_identity_hash != other->_identity_hash) {* >> *+ return false;* >> *+ }* >> >> >> Is this correct? The current code sets up _identity_hash with >> os::random, so it seems like to Symbols with equal contents would >> most likely going to get different _identity_hash codes. Or will this >> be changed later? I removed that comparison for now. Updated webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.02/ Files modified since last time: src/share/vm/classfile/classFileParser.cpp src/share/vm/classfile/systemDictionary.cpp src/share/vm/oops/symbol.hpp src/share/vm/prims/methodHandles.cpp thanks, Calvin >> >> Thanks, >> StefanK >>> >>> thanks, >>> Calvin >>> >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Tests: >>>>> JPRT (almost done) >>>>> Will do more perf testing after JPRT >>>>> >>>>> thanks, >>>>> Calvin >>>> >>> >> > From mikael.vidstedt at oracle.com Thu Apr 16 23:54:36 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 16 Apr 2015 16:54:36 -0700 Subject: RFR(S): 8078017: Introduce hotspot_basicvmtest Message-ID: <55304BBC.7080907@oracle.com> Please review this change which introduces a new test target called hotspot_basicvmtest. The new test target runs the union of the hotspot_client, hotspot_minimal and hotspot_server test targets. The change also updates JPRT to use the new target instead of the old ones. Bug: https://bugs.openjdk.java.net/browse/JDK-8078017 Webrev (top repo): http://cr.openjdk.java.net/~mikael/webrevs/8078017/webrev.00/hotspot/webrev/ Webrev (hotspot repo): http://cr.openjdk.java.net/~mikael/webrevs/8078017/webrev.00/top/webrev/ Motivation: Running all the three vm option tests as a single test target reduces the per-test setup cost while still providing the same test coverage. Description: Most of the changes are mechanical changes to the jprt.properties file to use the new makefile target. The new test target is implemented in the hotspot/test/Makefile. It discovers which jvm variants (client, minimal and/or server) are available by looking for the corresponding directories in the JDK under test. The exact directory within JDK where the JVM directories reside differ between the different platforms, but they all follow the same general pattern. Tested locally and in JPRT. Cheers, Mikael From vladimir.kozlov at oracle.com Fri Apr 17 00:27:53 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Apr 2015 17:27:53 -0700 Subject: RFR(S): 8077843: adlc: allow nodes that use TEMP inputs in expand rules. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBEEE0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBEEE0@DEWDFEMB12A.global.corp.sap> Message-ID: <55305389.5020600@oracle.com> Here is what Tom R said during review of TEMP implementation: >> 3. In formssel.cpp you restricted TEMP usage only to instruction >> with match rule, why? What about effect()?: >> + bool InstructForm::has_temps() { >> + if (_matrule) { > >TEMP isn't allowed for instructions which don't have match rules. The >reason is that if an instruct doesn't have a match rule the only way >it can be constructed is by an expand rule. expand rules look like >explicit invocations of encodings but TEMPs are synthetic so you can't >properly write an expand rule to work with TEMP. I mean you could >make it work but I decided not to support it. I'll make this more >explicit. So I am not sure that just removing the assert will be enough. Please, verify. Regards, Vladimir On 4/15/15 6:08 AM, Lindenmaier, Goetz wrote: > Hi, > > I have a tiny fix that allows nodes that use TEMP inputs / TEMP effect in > expand rules. > > Currently an assertion fires if you do so. > This is harmless, though, as the TEMP node is added in the Expand() of the used node, > which is called by the Expand() of the node being expanded. > Probably the assertion was meant for the node being expanded. > > The change simply removed the assertion. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8077843-adlcTEMP/webrev.01/ > > I need this feature for a change I intend to do in the ppc.ad file. > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Fri Apr 17 00:39:21 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Apr 2015 17:39:21 -0700 Subject: RFR(S): 8078017: Introduce hotspot_basicvmtest In-Reply-To: <55304BBC.7080907@oracle.com> References: <55304BBC.7080907@oracle.com> Message-ID: <55305639.3000102@oracle.com> Looks reasonable. Thanks, Vladimir On 4/16/15 4:54 PM, Mikael Vidstedt wrote: > > Please review this change which introduces a new test target called > hotspot_basicvmtest. The new test target runs the union of the > hotspot_client, hotspot_minimal and hotspot_server test targets. The > change also updates JPRT to use the new target instead of the old ones. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8078017 > Webrev (top repo): > http://cr.openjdk.java.net/~mikael/webrevs/8078017/webrev.00/hotspot/webrev/ > > Webrev (hotspot repo): > http://cr.openjdk.java.net/~mikael/webrevs/8078017/webrev.00/top/webrev/ > > Motivation: > > Running all the three vm option tests as a single test target reduces > the per-test setup cost while still providing the same test coverage. > > Description: > > Most of the changes are mechanical changes to the jprt.properties file > to use the new makefile target. The new test target is implemented in > the hotspot/test/Makefile. It discovers which jvm variants (client, > minimal and/or server) are available by looking for the corresponding > directories in the JDK under test. The exact directory within JDK where > the JVM directories reside differ between the different platforms, but > they all follow the same general pattern. > > Tested locally and in JPRT. > > Cheers, > Mikael > From david.holmes at oracle.com Fri Apr 17 04:23:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Apr 2015 14:23:52 +1000 Subject: RFR(S): 8078017: Introduce hotspot_basicvmtest In-Reply-To: <55304BBC.7080907@oracle.com> References: <55304BBC.7080907@oracle.com> Message-ID: <55308AD8.1090506@oracle.com> On 17/04/2015 9:54 AM, Mikael Vidstedt wrote: > > Please review this change which introduces a new test target called > hotspot_basicvmtest. The new test target runs the union of the > hotspot_client, hotspot_minimal and hotspot_server test targets. The > change also updates JPRT to use the new target instead of the old ones. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8078017 > Webrev (top repo): > http://cr.openjdk.java.net/~mikael/webrevs/8078017/webrev.00/hotspot/webrev/ > > Webrev (hotspot repo): > http://cr.openjdk.java.net/~mikael/webrevs/8078017/webrev.00/top/webrev/ Your hotspot and top descriptors are swapped around :) Otherwise "looks" "good" enough ;-) Cheers, David > Motivation: > > Running all the three vm option tests as a single test target reduces > the per-test setup cost while still providing the same test coverage. > > Description: > > Most of the changes are mechanical changes to the jprt.properties file > to use the new makefile target. The new test target is implemented in > the hotspot/test/Makefile. It discovers which jvm variants (client, > minimal and/or server) are available by looking for the corresponding > directories in the JDK under test. The exact directory within JDK where > the JVM directories reside differ between the different platforms, but > they all follow the same general pattern. > > Tested locally and in JPRT. > > Cheers, > Mikael > From staffan.larsen at oracle.com Fri Apr 17 06:33:57 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 17 Apr 2015 08:33:57 +0200 Subject: RFR(S): 8077608 - [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode In-Reply-To: <552C123B.1040907@oracle.com> References: <14e901d075f5$58896120$099c2360$@oracle.com> <552C123B.1040907@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 13 apr 2015, at 21:00, George Triantafillou wrote: > > Christian, > > This looks good. Thanks for fixing this. > > -George > > On 4/13/2015 10:22 AM, Christian Tornqvist wrote: >> Hi everyone, >> >> >> Please review this small change which enables us to run the Hotspot jtreg >> tests in agentvm mode. This change also sets JPRT to use this mode. Results >> when running on my 32-thread Windows machine using a fastdebug build: >> >> >> Othervm (this is what we run today): 4h5m >> >> Agentvm (still without concurrency): 1h45m >> >> >> The same speedup can be seen in JPRT across all platforms, I've tested these >> changes 25-30 times in JPRT. >> >> >> In order to make all the tests work correctly I had to make some small >> changes: >> >> >> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java >> >> Turns out that the CLASSPATH environment variable has a different value when >> running with agentvm, it's now appending test.src and test.class.path when >> creating child processes. This fixed about 40 of the failures. >> >> >> test/sanity/WhiteBox.java >> >> Fails to clean out the sun.hotspot.WhiteBox.class on Windows machines, the >> only reason for cleaning this file out is so that the other tests in >> /test/sanity doesn't pick up the incorrect WhiteBox.class. Simple workaround >> is to move the test/sanity/WhiteBox.java into its own directory to prevent >> the other tests from picking up this class file. >> >> >> test/compiler/uncommontrap/TestUnstableIfTrap.java >> >> Intermittent IO problems on Windows when reading the XML files, workaround >> is to run this to keep running this test in othervm mode. >> >> >> test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java >> >> ClassNotFoundException when running in agentvm mode, didn't spend too much >> time debugging this. Workaround is to keep running this test in othervm >> mode. >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8077608/webrev.00/ >> >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8077608 >> >> >> Thanks, >> >> Christian >> >> >> > From stefan.karlsson at oracle.com Fri Apr 17 06:40:44 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 17 Apr 2015 08:40:44 +0200 Subject: RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: <55304459.7000008@oracle.com> References: <552EC286.5000005@oracle.com> <552EDD1F.1030308@oracle.com> <552EF384.4040103@oracle.com> <552F508F.7050809@oracle.com> <552F5314.3070002@oracle.com> <55304459.7000008@oracle.com> Message-ID: <5530AAEC.5010600@oracle.com> On 2015-04-17 01:23, Calvin Cheung wrote: > On 4/15/2015 11:13 PM, Ioi Lam wrote: >> On 4/15/15 11:02 PM, Stefan Karlsson wrote: >>> On 2015-04-16 01:25, Calvin Cheung wrote: >>>> Hi Stefan, >>>> >>>> Thanks for your review. >>>> >>>> On 4/15/2015 2:50 PM, Stefan Karlsson wrote: >>>>> Hi Calvin, >>>>> >>>>> On 2015-04-15 21:56, Calvin Cheung wrote: >>>>>> Please review this second version of the fix. >>>>>> >>>>>> This version has 2 new functions (equals() and not_equals()) in >>>>>> the Symbol class. >>>>>> It replaces the Symbol* == and != comparisons with those 2 >>>>>> function calls. >>>>>> >>>>>> Pro: >>>>>> >>>>>> It has a much smaller changeset than the first version. >>>>>> >>>>>> Con: >>>>>> >>>>>> Someone may by mistake introduce a new line of (Symbol* == Symbol*). >>>>>> >>>>>> We will mitigate this by enhancing our internal static analysis >>>>>> tool to flag the >>>>>> above code in the future. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8071627 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/ >>>>> >>>>> This is a much less intrusive change than the previous patch. Thanks. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/classFileParser.cpp.patch >>>>> >>>>> >>>>> Is there a reason why you added not_equals: >>>>> - if (name != vmSymbols::object_initializer_name()) { >>>>> + if >>>>> (name->not_equals(vmSymbols::object_initializer_name())) { >>>>> >>>>> instead of just: >>>>> + if >>>>> (!name->equals(vmSymbols::object_initializer_name())) { >>>> We think that it's clearer to have not_equals() than using the ! as >>>> in the above. >>> >>> OK. IMHO, negating boolean expressions with ! is a common construct >>> so I'm not sure not_equals is clearer. >>> >>>>> >>>>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/classfile/systemDictionary.cpp.udiff.html >>>>> >>>>> ! assert(parsed_name->not_equals(NULL), "Sanity"); >>>>> >>>>> >>>>> You use symbol == NULL but not symbol != NULL, which seems >>>>> inconsistent to me. >>>> I'm not sure I understand this comment. >>>> Are you referring to the following section of the udiff? >>>> *** 1104,1115 **** >>>> --- 1104,1115 ---- >>>> Exceptions::_throw_msg(THREAD_AND_LOCATION, >>>> vmSymbols::java_lang_SecurityException(), message); >>>> } >>>> >>>> if (!HAS_PENDING_EXCEPTION) { >>>> ! assert(parsed_name != NULL, "Sanity"); >>>> ! assert(class_name == NULL || class_name == parsed_name, "name >>>> mismatch"); >>>> ! assert(parsed_name->not_equals(NULL), "Sanity"); >>>> ! assert(class_name == NULL || class_name->equals(parsed_name), >>>> "name mismatch"); >>>> // Verification prevents us from creating names with dots in >>>> them, this >>>> // asserts that that's the case. >>>> assert(is_internal_format(parsed_name), >>>> "external class name format used internally"); >>>> >>>> I don't see anything incorrect there. >>> >>> I'm not talking about being correct or incorrect. I would have >>> expected to see either: >>> >>> 1) Use pointer (in)equality when checking for NULL: >>> class_name == NULL >>> parsed_name != NULL >>> >>> or >>> >>> 2) strictly use the (not_)equals function when checking for NULL: >>> class_name->equals(NULL) >>> parsed_name->not_equals(NULL) >>> or even: >>> class_name->equals(NULL) >>> !parsed_name->equals(NULL)) >>> >>> but not what you have today, where you mix the two ways to NULL check >>> class_name == NULL >>> parsed_name->not_equals(NULL) >>> >> >> I think it's better to use (symbol == NULL) everywhere. Calling >> symbol->equals(NULL) while symbol itself is NULL is confusing -- it >> raises questions like "will this crash in debug mode", so we'd better >> avoid it. > I've fixed all those NULL comparison back to (symbol == NULL) or > (symbol != NULL). > >> >> In our static analysis tool, we need to flags checks for (symbol1 == >> symbol2), but should allow (symbol == NULL). >> >> - Ioi >> >>> >>>>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html >>>>> >>>>> >>>>> *+ inline bool equals(const Symbol* other) const {* >>>>> *+ if (this && other) { >>>>> * >>>>> First, pointers should be checked null checked with == or !=. See: >>>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-Miscellaneous >>>>> >>>> >>>> I will fix it. >>>> >>>>> >>>>> Second, I recall some discussion that null checking the 'this' >>>>> pointer is undefined behavior. Though, we do it in other places so >>>>> this isn't worse, I think. >>>>> >>>>> Did you use your previous patch to find all Symbol* compares? >>>> >>>> Yes. Essentially comment out the bodies of the == and != operators >>>> in SymbolRef. >>>> Rebuilding hotspot resulting a lot of "undefined reference to >>>> SymbolRef::operator==" link errors. >>>> Then go through those error and change a == b to a->equals(b) and a >>>> != b to a->not_equals(b). >>>> Obviously change SymbolRef back to Symbol*. >>> >>> Great. >>> >>> One more thing: >>> http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/src/share/vm/oops/symbol.hpp.udiff.html >>> >>> >>> *+ if (this->_identity_hash != other->_identity_hash) {* >>> *+ return false;* >>> *+ }* >>> >>> >>> Is this correct? The current code sets up _identity_hash with >>> os::random, so it seems like to Symbols with equal contents would >>> most likely going to get different _identity_hash codes. Or will >>> this be changed later? > I removed that comparison for now. > > Updated webrev: > http://cr.openjdk.java.net/~ccheung/8071627/webrev.02/ > > Files modified since last time: > src/share/vm/classfile/classFileParser.cpp > src/share/vm/classfile/systemDictionary.cpp > src/share/vm/oops/symbol.hpp > src/share/vm/prims/methodHandles.cpp It's be easier for the reviewers if you also provide webrev with the delta of your patches. You've now taken away the identity hash code check, which I suggested was a bug. I think that might affect the performance. Before the removal the functions almost always exited after the identity hash code and didn't have to do the string compare, but now I think it does the string compare much more often. I'm afraid you will have to redo the performance measurements now. And just a style comment: *+ inline bool equals(const Symbol* other) const {* *+ if ((this != NULL) && (other != NULL)) {* *+ int len = this->utf8_length();* *+ if (len != other->utf8_length()) {* *+ return false;* *+ }* *+ return (strncmp((const char*)(this->base()), (const char*)(other->base()), len) == 0);* *+ } else {* *+ return (this == other);* *+ }* *+ }* *+ inline bool not_equals(const Symbol* other) const {* *+ return !(this->equals(other));* *+ } * There's a large amount of unnecessary parentheses, that really don't aid in the readability of the code, IMHO. Feel free to ignore this, but the code could be written as: * + inline bool equals(const Symbol* other) const { + if (this != NULL && other != NULL) { + int len = this->utf8_length(); + if (len != other->utf8_length()) { + return false; + } + return strncmp((const char*)this->base(), (const char*)other->base(), len) == 0; + } + return this == other; + } + inline bool not_equals(const Symbol* other) const { + return !this->equals(other); + }* Not related to your change, but why are the Symbol::_body defined as a jbyte array instead of a char array? That seems to cause unnecessary casts. Thanks, StefanK > > thanks, > Calvin >>> >>> Thanks, >>> StefanK >>>> >>>> thanks, >>>> Calvin >>>> >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Tests: >>>>>> JPRT (almost done) >>>>>> Will do more perf testing after JPRT >>>>>> >>>>>> thanks, >>>>>> Calvin >>>>> >>>> >>> >> > From goetz.lindenmaier at sap.com Fri Apr 17 07:25:21 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Apr 2015 07:25:21 +0000 Subject: RFR(S): 8077843: adlc: allow nodes that use TEMP inputs in expand rules. In-Reply-To: <55305389.5020600@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBEEE0@DEWDFEMB12A.global.corp.sap> <55305389.5020600@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBF52B@DEWDFEMB12A.global.corp.sap> HI Vladimir, the node generated in the Expand has a match rule itself. I checked, all the TEMPs we use are in nodes with match rules. Anyways, you get a syntax error if not: "Syntax Error: : TEMPs without match rule isn't supported" We use nodes with match rules in expands a lot, as the match rule is required for a lot of things. For example to generate the proper ideal opcode, get it in the array must_clone etc. If we don't want the nodes to be matched, we add predicate(false). In our internal VM, we use nodes with TEMPs in expands on ia64 a lot. For the code generated for the nodes I intend to contribute, see below. Best regards, Goetz. // Card-mark for CMS garbage collection. // This cardmark does an optimization so that it must not always // do a releasing store. For this, it gets the address of // CMSCollectorCardTableModRefBSExt::_requires_release as input. // (Using releaseFieldAddr in the match rule is a hack.) instruct storeCM_CMS(memory mem, iRegLdst releaseFieldAddr, flagsReg crx) %{ match(Set mem (StoreCM mem releaseFieldAddr)); effect(TEMP crx); predicate(false); ins_cost(MEMORY_REF_COST); // See loadConP. ins_cannot_rematerialize(true); format %{ "STB #0, $mem \t// CMS card-mark byte (must be 0!), checking requires_release in [$releaseFieldAddr]" %} ins_encode( enc_cms_card_mark(mem, releaseFieldAddr, crx) ); ins_pipe(pipe_class_memory); %} // Card-mark for CMS garbage collection. // This cardmark does an optimization so that it must not always // do a releasing store. For this, it needs the constant address of // CMSCollectorCardTableModRefBSExt::_requires_release. // This constant address is split off here by expand so we can use // adlc / matcher functionality to load it from the constant section. instruct storeCM_CMS_ExEx(memory mem, immI_0 zero) %{ match(Set mem (StoreCM mem zero)); predicate(UseConcMarkSweepGC); expand %{ immL baseImm %{ 0 /* TODO: PPC port (jlong)CMSCollectorCardTableModRefBSExt::requires_release_address() */ %} iRegLdst releaseFieldAddress; flagsReg crx; loadConL_Ex(releaseFieldAddress, baseImm); storeCM_CMS(mem, releaseFieldAddress, crx); %} %} MachNode* storeCM_CMSNode::Expand(State* state, Node_List& proj_list, Node* mem) { Compile* C = Compile::current(); // Add projection edges for additional defs or kills // TEMP crx MachTempNode *def; def = new MachTempNode(state->MachOperGenerator(FLAGSREG)); add_req(def); return this; } MachNode* storeCM_CMS_ExExNode::Expand(State* state, Node_List& proj_list, Node* mem) { Compile* C = Compile::current(); MachOper *op0 = new immLOper( #line 6571 "/sapmnt/home1/d045726/oJ/8077838-ppc-hs-comp/src/cpu/ppc/vm/ppc.ad" 0 /* TODO: PPC port (jlong)CMSCollectorCardTableModRefBSExt::requires_release_address() */ #line 527 "../generated/adfiles/ad_ppc_64_expand.cpp" ); MachOper *op1 = new iRegLdstOper(); MachOper *op2 = new flagsRegOper(); MachNode *tmp0 = this; MachNode *tmp1 = this; MachNode *tmp2 = this; MachNode *tmp3 = NULL; MachNode *tmp4 = NULL; MachNode *tmp5 = NULL; unsigned num0 = 0; unsigned num1 = opnd_array(1)->num_edges(); unsigned num2 = opnd_array(2)->num_edges(); unsigned idx0 = oper_input_base(); if (mem == (Node*)1) { idx0--; // Adjust base because memory edge hasn't been inserted yet } unsigned idx1 = idx0 + num0; unsigned idx2 = idx1 + num1; unsigned idx3 = idx2 + num2; MachNode *result = NULL; loadConL_ExNode *n0 = new loadConL_ExNode(); n0->add_req(_in[0]); ((MachTypeNode*)n0)->_bottom_type = bottom_type(); n0->set_opnd_array(0, state->MachOperGenerator(IREGLDST)); tmp4 = n0; n0->set_opnd_array(1, op0->clone()); // baseImm if(tmp3 != NULL) n0->add_req(tmp3); result = n0->Expand( state, proj_list, mem ); storeCM_CMSNode *n1 = new storeCM_CMSNode(); n1->add_req(_in[0]); ((MachTypeNode*)n1)->_bottom_type = bottom_type(); n1->set_opnd_array(0, state->MachOperGenerator(UNIVERSE)); if (mem != (Node*)1) { n1->add_req(_in[1]); // Add memory edge } n1->set_opnd_array(1, opnd_array(1)->clone()); // mem if(tmp1 == this) { for(unsigned i = 0; i < num1; i++) { n1->add_req(_in[i + idx1]); } } else n1->add_req(tmp1); tmp1 = n1; n1->set_opnd_array(2, op1->clone()); // releaseFieldAddress if(tmp4 != NULL) n1->add_req(tmp4); n1->set_opnd_array(3, op2->clone()); // crx if(tmp5 != NULL) n1->add_req(tmp5); result = n1->Expand( state, proj_list, mem ); return result; } -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Freitag, 17. April 2015 02:28 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8077843: adlc: allow nodes that use TEMP inputs in expand rules. Here is what Tom R said during review of TEMP implementation: >> 3. In formssel.cpp you restricted TEMP usage only to instruction >> with match rule, why? What about effect()?: >> + bool InstructForm::has_temps() { >> + if (_matrule) { > >TEMP isn't allowed for instructions which don't have match rules. The >reason is that if an instruct doesn't have a match rule the only way >it can be constructed is by an expand rule. expand rules look like >explicit invocations of encodings but TEMPs are synthetic so you can't >properly write an expand rule to work with TEMP. I mean you could >make it work but I decided not to support it. I'll make this more >explicit. So I am not sure that just removing the assert will be enough. Please, verify. Regards, Vladimir On 4/15/15 6:08 AM, Lindenmaier, Goetz wrote: > Hi, > > I have a tiny fix that allows nodes that use TEMP inputs / TEMP effect in > expand rules. > > Currently an assertion fires if you do so. > This is harmless, though, as the TEMP node is added in the Expand() of the used node, > which is called by the Expand() of the node being expanded. > Probably the assertion was meant for the node being expanded. > > The change simply removed the assertion. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8077843-adlcTEMP/webrev.01/ > > I need this feature for a change I intend to do in the ppc.ad file. > > Best regards, > Goetz. > From fredrik.arvidsson at oracle.com Fri Apr 17 07:32:33 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 17 Apr 2015 09:32:33 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... Message-ID: <5530B711.2070009@oracle.com> Hi We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience. The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014: https://bugs.openjdk.java.net/browse/JDK-8046148 During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started. Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward. The time-out led to a modified proposal that can be found here: http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html and with some illustrations here: http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png So what have we changed, and why? In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution. The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand. The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible. Our plan is as follows: After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week. We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase. More information about the sandbox repository name and other practicalities will follow shortly. Cheers Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From mattis.castegren at oracle.com Fri Apr 17 07:55:43 2015 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Fri, 17 Apr 2015 00:55:43 -0700 (PDT) Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530B711.2070009@oracle.com> References: <5530B711.2070009@oracle.com> Message-ID: <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> Hi Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like log("gc,g1,init", )? Also, will all tags be defined in one file so that you can see which modules exists? Kind Regards /Mattis -----Original Message----- From: Fredrik Arvidsson Sent: den 17 april 2015 09:33 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers Subject: Updates to JEP-158: JVM Unified Logging are coming... Hi We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience. The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014: https://bugs.openjdk.java.net/browse/JDK-8046148 During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started. Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward. The time-out led to a modified proposal that can be found here: http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html and with some illustrations here: http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png So what have we changed, and why? In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution. The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand. The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible. Our plan is as follows: After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week. We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase. More information about the sandbox repository name and other practicalities will follow shortly. Cheers Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From fredrik.arvidsson at oracle.com Fri Apr 17 08:13:44 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 17 Apr 2015 10:13:44 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> References: <5530B711.2070009@oracle.com> <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> Message-ID: <5530C0B8.5020701@oracle.com> Hi Mattis The hierarchical structure is gone. Each log line in the code should contain all tags related to the message logged. In your example below the line would be printed just like before since the log call contains the gc tag. All tags will be defined in a single source file. The available tags will just like before be enumerable in runtime. /Fredrik On 2015-04-17 09:55, Mattis Castegren wrote: > Hi > > Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like > log("gc,g1,init", )? > > Also, will all tags be defined in one file so that you can see which modules exists? > > Kind Regards > /Mattis > > -----Original Message----- > From: Fredrik Arvidsson > Sent: den 17 april 2015 09:33 > To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers > Subject: Updates to JEP-158: JVM Unified Logging are coming... > > Hi > > We are planning to release an updated version of JEP-158 very soon. The > work to update this JEP has been going on for some time and we now feel > we are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The > requirements for the API and implementation were heavily influenced by > the logging functionality in JRockit JVM. The JEP was updated and > refined in mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the > chosen API and functionality but the conclusion was that the proposal > would work, and the JEP was targeted for JDK 9 and the implementation > work was started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of the > JEP, this time with greater force. At this point we decided to take a > time-out and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout > to something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found > that some logging can't easily be ordered under a single hierarchical > subject but can belong to multiple subjects/areas. One example of this > is logging in the 'metaspace' code. The functionality in the 'metaspace > area' can be called from both GC and Runtime code. Another example is > class-unloading. There are more examples on this of course, but these > two we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much > from the earlier proposal. We have tried to make it leaner and not as > verbose (functionality wise) as before. The scope of the implementation > has been narrowed down some to enable us to deliver good value as soon > as possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal > we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. > This enables us who are implementing it to work in an efficient way and > at the same time it allows any interested party to try out and follow > the work during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From mattis.castegren at oracle.com Fri Apr 17 08:27:53 2015 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Fri, 17 Apr 2015 01:27:53 -0700 (PDT) Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530C0B8.5020701@oracle.com> References: <5530B711.2070009@oracle.com> <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> <5530C0B8.5020701@oracle.com> Message-ID: <26421508-9c07-45e5-a109-1b148272c862@default> Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc. If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like log ("gc,g1,g1_init", ...) If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..." Kind Regards /Mattis -----Original Message----- From: Fredrik Arvidsson Sent: den 17 april 2015 10:14 To: Mattis Castegren; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers Subject: Re: Updates to JEP-158: JVM Unified Logging are coming... Hi Mattis The hierarchical structure is gone. Each log line in the code should contain all tags related to the message logged. In your example below the line would be printed just like before since the log call contains the gc tag. All tags will be defined in a single source file. The available tags will just like before be enumerable in runtime. /Fredrik On 2015-04-17 09:55, Mattis Castegren wrote: > Hi > > Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like > log("gc,g1,init", )? > > Also, will all tags be defined in one file so that you can see which modules exists? > > Kind Regards > /Mattis > > -----Original Message----- > From: Fredrik Arvidsson > Sent: den 17 april 2015 09:33 > To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers > Subject: Updates to JEP-158: JVM Unified Logging are coming... > > Hi > > We are planning to release an updated version of JEP-158 very soon. The > work to update this JEP has been going on for some time and we now feel > we are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The > requirements for the API and implementation were heavily influenced by > the logging functionality in JRockit JVM. The JEP was updated and > refined in mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the > chosen API and functionality but the conclusion was that the proposal > would work, and the JEP was targeted for JDK 9 and the implementation > work was started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of the > JEP, this time with greater force. At this point we decided to take a > time-out and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout > to something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found > that some logging can't easily be ordered under a single hierarchical > subject but can belong to multiple subjects/areas. One example of this > is logging in the 'metaspace' code. The functionality in the 'metaspace > area' can be called from both GC and Runtime code. Another example is > class-unloading. There are more examples on this of course, but these > two we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much > from the earlier proposal. We have tried to make it leaner and not as > verbose (functionality wise) as before. The scope of the implementation > has been narrowed down some to enable us to deliver good value as soon > as possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal > we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. > This enables us who are implementing it to work in an efficient way and > at the same time it allows any interested party to try out and follow > the work during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From goetz.lindenmaier at sap.com Fri Apr 17 09:13:02 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Apr 2015 09:13:02 +0000 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <2A911659-4716-42E7-9276-2D8774E49895@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552E7CA9.5020901@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF20D@DEWDFEMB12A.global.corp.sap> <2A911659-4716-42E7-9276-2D8774E49895@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBF5B9@DEWDFEMB12A.global.corp.sap> Hi Kim, Stefan, yes, I saw the other two possibilities. I tried both of them. I also tried an example with uninitialized code. I thought that works, but actually xlC never warns about that. I asked our IBM contacts about this. I'll share it in case they come up with a solution. I also tried HP aCC, that shows the very same behaviour as xlC. No warning about uninitialized code, no effect of the attribute on returns. I didn't dig into this, though. (We have a windows/linux/hp ia64 port internally.) So maybe keeping/adding returns is the better solution... Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Donnerstag, 16. April 2015 19:34 To: Lindenmaier, Goetz Cc: Stefan Karlsson; hotspot-dev Source Developers Subject: Re: 8065585: Change ShouldNotReachHere() to never return On Apr 16, 2015, at 4:50 AM, Lindenmaier, Goetz wrote: > the IBM docu says that __notreturn__ affects only warnings about > uninitialized variables, not about missing returns. I would summarize it as saying it does affect ununitialized variable warnings, and as being silent on the subject of missing returns. > It also says that registers are not stored on a call. > http://publibfp.boulder.ibm.com/epubs/pdf/c1473260.pdf page 193. Actually, it says registers saved by the caller might not be restored before the call. > For the compiler flags and warnings I get see the compile output below. The missing return warnings are quite disappointing, even to the level of a bug. Though the feature documentation is so light, it could arguably do almost anything. XLC appears to provide at least three mechanisms for indicating a function doesn't return. The __attribute__ method has the weakest description: "indicate to the compiler that the function is not intended to return." The others are _Noreturn function attribute (similar to inline) - "declares a function that does not return to its caller." Added by C11 and requires special compiler options to enable. #pragma leaves(function_name, ...) - "Informs the compiler that a named function never returns to the instruction following a call to that function." Goetz, if you have some time (yeah, right), it might be interesting to find out if either of the other two behave any differently with regard to missing return warnings. I will be sad if this proposed change has to be dropped because an otherwise well-reputed compiler was so lame in this respect. I really dislike dummy return statements and not having -Wuninitialized turned on. From fredrik.arvidsson at oracle.com Fri Apr 17 09:29:58 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 17 Apr 2015 11:29:58 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <26421508-9c07-45e5-a109-1b148272c862@default> References: <5530B711.2070009@oracle.com> <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> <5530C0B8.5020701@oracle.com> <26421508-9c07-45e5-a109-1b148272c862@default> Message-ID: <5530D296.9000408@oracle.com> Hi Ill try to reply in-line below. On 2015-04-17 10:27, Mattis Castegren wrote: > Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc. Of course there is a risk that people would forget to add a tag. But I can't see that this risk is very high. Logging code has to be put through code review just like any other change and we just have to pay extra attention to this in the beginning i guess. Using the hierarchical scheme there is also a risk that the logging topic is set to the wrong one. There are no recommendations right now on what tags to create or use in the logging code. We will work with all groups trying to establish some guidelines I guess to have tag names consistent. If we see a real need to have 'meta-tags' consisting of several other tags we could introduce something like that I'm sure, but this is just something we have discussed briefly. There will also be a way to list all existing 'tag combinations' used in the code in runtime. This could maybe be used to spot the ones that are potentially wrong? > If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like > > log ("gc,g1,g1_init", ...) > > If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..." Yes, this would be the way to handle missed tags in the code. I can't see that there is another way really :( Cheers /Fredrik > Kind Regards > /Mattis > > -----Original Message----- > From: Fredrik Arvidsson > Sent: den 17 april 2015 10:14 > To: Mattis Castegren; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers > Subject: Re: Updates to JEP-158: JVM Unified Logging are coming... > > Hi Mattis > > The hierarchical structure is gone. Each log line in the code should > contain all tags related to the message logged. > In your example below the line would be printed just like before since > the log call contains the gc tag. > > All tags will be defined in a single source file. The available tags > will just like before be enumerable in runtime. > > /Fredrik > > On 2015-04-17 09:55, Mattis Castegren wrote: >> Hi >> >> Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like >> log("gc,g1,init", )? >> >> Also, will all tags be defined in one file so that you can see which modules exists? >> >> Kind Regards >> /Mattis >> >> -----Original Message----- >> From: Fredrik Arvidsson >> Sent: den 17 april 2015 09:33 >> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers >> Subject: Updates to JEP-158: JVM Unified Logging are coming... >> >> Hi >> >> We are planning to release an updated version of JEP-158 very soon. The >> work to update this JEP has been going on for some time and we now feel >> we are ready to present it to a wider audience. >> >> The JEP for JVM Unified Logging was created back in February 2012. The >> requirements for the API and implementation were heavily influenced by >> the logging functionality in JRockit JVM. The JEP was updated and >> refined in mid 2014 and eventually targeted for JDK 9 in late 2014: >> https://bugs.openjdk.java.net/browse/JDK-8046148 >> >> During the review process of the JEP some concerns were voiced about the >> chosen API and functionality but the conclusion was that the proposal >> would work, and the JEP was targeted for JDK 9 and the implementation >> work was started. >> >> Early 2015 during pre-reviews and presentations of the API and >> implementation concerns were again raised about the formulation of the >> JEP, this time with greater force. At this point we decided to take a >> time-out and investigate our options going forward. >> >> The time-out led to a modified proposal that can be found here: >> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html >> and with some illustrations here: >> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png >> >> So what have we changed, and why? >> In short we have switched from using an hierarchical log subject layout >> to something that could be best described as a tag based solution. >> >> The main reason for the change of the logging API is that we have found >> that some logging can't easily be ordered under a single hierarchical >> subject but can belong to multiple subjects/areas. One example of this >> is logging in the 'metaspace' code. The functionality in the 'metaspace >> area' can be called from both GC and Runtime code. Another example is >> class-unloading. There are more examples on this of course, but these >> two we think are very clear and easy to understand. >> >> The core functionality of the logging framework is not changed that much >> from the earlier proposal. We have tried to make it leaner and not as >> verbose (functionality wise) as before. The scope of the implementation >> has been narrowed down some to enable us to deliver good value as soon >> as possible. >> >> Our plan is as follows: >> After getting initial feedback from the community about the new proposal >> we will update the JEP description. We aim to do this early next week. >> We are planning to use the JDK9 sandbox repository during development. >> This enables us who are implementing it to work in an efficient way and >> at the same time it allows any interested party to try out and follow >> the work during the implementation phase. >> >> More information about the sandbox repository name and other >> practicalities will follow shortly. >> >> Cheers >> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From adinn at redhat.com Fri Apr 17 09:35:14 2015 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 17 Apr 2015 10:35:14 +0100 Subject: RFR: 8076488: AARCH64: jdk9 fails to build from source In-Reply-To: <551C300D.2090005@oracle.com> References: <1427905684.1631.12.camel@mylittlepony.linaroharston> <551C300D.2090005@oracle.com> Message-ID: <5530D3D2.5090505@redhat.com> On 01/04/15 18:51, Vladimir Kozlov wrote: > Looks good to me. As a 2nd review***, yes this patch is good. Is that enough for it to be pushed to jdk9? ***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only and I /am/ an aarch64-port committer/reviewer. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From roland.westrelin at oracle.com Fri Apr 17 09:39:17 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 17 Apr 2015 11:39:17 +0200 Subject: RFR: 8076488: AARCH64: jdk9 fails to build from source In-Reply-To: <5530D3D2.5090505@redhat.com> References: <1427905684.1631.12.camel@mylittlepony.linaroharston> <551C300D.2090005@oracle.com> <5530D3D2.5090505@redhat.com> Message-ID: <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com> >> Looks good to me. > > As a 2nd review***, yes this patch is good. Is that enough for it to be > pushed to jdk9? > > ***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only > and I /am/ an aarch64-port committer/reviewer. In case another review helps: that looks good to me. Roland. From aph at redhat.com Fri Apr 17 09:40:17 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Apr 2015 10:40:17 +0100 Subject: RFR: 8076488: AARCH64: jdk9 fails to build from source In-Reply-To: <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com> References: <1427905684.1631.12.camel@mylittlepony.linaroharston> <551C300D.2090005@oracle.com> <5530D3D2.5090505@redhat.com> <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com> Message-ID: <5530D501.1010004@redhat.com> On 04/17/2015 10:39 AM, Roland Westrelin wrote: >>> Looks good to me. >> >> As a 2nd review***, yes this patch is good. Is that enough for it to be >> pushed to jdk9? >> >> ***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only >> and I /am/ an aarch64-port committer/reviewer. > > In case another review helps: that looks good to me. OK, I'll push it. Andrew. From aph at redhat.com Fri Apr 17 09:43:03 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Apr 2015 10:43:03 +0100 Subject: RFR: 8076488: AARCH64: jdk9 fails to build from source In-Reply-To: <5530D501.1010004@redhat.com> References: <1427905684.1631.12.camel@mylittlepony.linaroharston> <551C300D.2090005@oracle.com> <5530D3D2.5090505@redhat.com> <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com> <5530D501.1010004@redhat.com> Message-ID: <5530D5A7.90105@redhat.com> On 04/17/2015 10:40 AM, Andrew Haley wrote: > On 04/17/2015 10:39 AM, Roland Westrelin wrote: >>>> Looks good to me. >>> >>> As a 2nd review***, yes this patch is good. Is that enough for it to be >>> pushed to jdk9? >>> >>> ***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only >>> and I /am/ an aarch64-port committer/reviewer. >> >> In case another review helps: that looks good to me. > > OK, I'll push it. Ah, no I won't. My patch already fixed this, and (IMO) in a much better way. This patch is already in jprt, and will emerge soon, I hope. diff -r 9c916db4bf3b -r 6463e57d9761 src/cpu/aarch64/vm/interp_masm_aarch64.hpp --- a/src/cpu/aarch64/vm/interp_masm_aarch64.hpp Thu Apr 09 17:38:28 2015 -0700 +++ b/src/cpu/aarch64/vm/interp_masm_aarch64.hpp Tue Apr 14 11:43:18 2015 +0100 @@ -1,6 +1,6 @@ /* * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. - * Copyright (c) 2014, Red Hat Inc. All rights reserved. + * Copyright (c) 2014, 2015, Red Hat Inc. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -40,6 +40,8 @@ protected: // Interpreter specific version of call_VM_base + using MacroAssembler::call_VM_leaf_base; + virtual void call_VM_leaf_base(address entry_point, int number_of_arguments); Andrew. From goetz.lindenmaier at sap.com Fri Apr 17 09:52:56 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Apr 2015 09:52:56 +0000 Subject: RFR(XS): 8078048: Fix non-pch build after "8076457: Fix includes of inline.hpp in GC code" Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBF5E0@DEWDFEMB12A.global.corp.sap> Hi, This change fixes the build without precompiled headers. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8078048-pchBuild/webrev.01/ Best regards, Goetz. From goetz.lindenmaier at sap.com Fri Apr 17 09:58:10 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Apr 2015 09:58:10 +0000 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> Hi, another occurance of this ... please, please add a non-pch build to jprt! https://bugs.openjdk.java.net/browse/JDK-8078048 Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Donnerstag, 9. April 2015 11:35 To: Andrew Dinn Cc: HotSpot Open Source Developers Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn wrote: > On 09/04/15 09:02, Erik Joelsson wrote: >> I think that as long as we claim to support building both with and >> without PCH, the automatic testing should test both with and without >> PCH. By adding one or two build targets, or perhaps change an existing >> target, we could increase our test matrix to cover this easily. > > I think this restates Volker's original remarks in redux. > No, not at all! I don't necessarily want to test more build configurations (that's another topic). My point is that PCH changes the compilation semantics and can hide real program errors. That's because with PCHs, every compilation unit sees the full precompiled header database (i.e. all the headers which are included in the "precompiled.hpp" PCH file). So if somebody forgets to include a dependency X.hpp in A.cpp, A.cpp may still compile with PCH because it includes the precompiled header file "precompiled.hpp" which in turn includes X.hpp. But the compilation of A.cpp will fail on platforms/configurations where we do not use precompiled headers. The two references I gave in my original mail are bugs that resulted from this problem. Besides program errors, the use of PCH can also lead to behavioral changes in the created binary when it comes to inlining. Because of PCHs some compilation units may be able to inline methods even if they do not explicitly include the files which contain the corresponding implementations because the implementation files are included in the PCH file. Without PCHs the compilers will simply emit calls to these functions (and, depending on the toolchain, emit a warning). I'm not familiar with ccache so I can not say if it has similar effects. > So, given that we do need this (NOW! :-) is anyone able and willing to > sponsor this? > Yes, this question remains to be answered :) Regards, Volker > regards, > > > Andrew Dinn > ----------- > From martijnverburg at gmail.com Fri Apr 17 10:12:55 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 17 Apr 2015 12:12:55 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530B711.2070009@oracle.com> References: <5530B711.2070009@oracle.com> Message-ID: Hi Fredrik, Thanks from us (jClarity and some other orgs) for considering the tag based system, we're really glad you've gone in this direction. One quick bit of feedback. Is it possible to add a binary / compressed logging format or an interface/ API to plug one in for high performance Logging? Human readable is nice for looking at logs immediately, but for some of our customers they'd be looking to offload that concern to another process/host. Cheers, Martijn On 17 April 2015 at 09:32, Fredrik Arvidsson wrote: > Hi > > We are planning to release an updated version of JEP-158 very soon. The > work to update this JEP has been going on for some time and we now feel we > are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The > requirements for the API and implementation were heavily influenced by the > logging functionality in JRockit JVM. The JEP was updated and refined in > mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the > chosen API and functionality but the conclusion was that the proposal would > work, and the JEP was targeted for JDK 9 and the implementation work was > started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of the JEP, > this time with greater force. At this point we decided to take a time-out > and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout to > something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found > that some logging can't easily be ordered under a single hierarchical > subject but can belong to multiple subjects/areas. One example of this is > logging in the 'metaspace' code. The functionality in the 'metaspace area' > can be called from both GC and Runtime code. Another example is > class-unloading. There are more examples on this of course, but these two > we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much > from the earlier proposal. We have tried to make it leaner and not as > verbose (functionality wise) as before. The scope of the implementation has > been narrowed down some to enable us to deliver good value as soon as > possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal > we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. > This enables us who are implementing it to work in an efficient way and at > the same time it allows any interested party to try out and follow the work > during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. > From martijnverburg at gmail.com Fri Apr 17 10:19:01 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 17 Apr 2015 12:19:01 +0200 Subject: JEP 245: Validate JVM Command-Line Flag Arguments In-Reply-To: <20150416225421.C35DE567AC@eggemoggin.niobe.net> References: <20150416225421.C35DE567AC@eggemoggin.niobe.net> Message-ID: Hi all, This would be of great benefit to the tools space, we just spent the last couple of days digging into GC flag (invalid) values causing 'interesting' things to happen. Having info messages instead of a JVM crash will also reduce the number of JVM crashes we see out there. WRT to performance tuning this will allow people to rapidly change settings in test with more confidence. Anyhow, thanks for proposing this JEP! Cheers, Martijn On 17 April 2015 at 00:54, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/245 > > - Mark > From david.holmes at oracle.com Fri Apr 17 10:22:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Apr 2015 20:22:43 +1000 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> Message-ID: <5530DEF3.5070301@oracle.com> On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote: > Hi, > > another occurance of this ... please, please add a non-pch build to > jprt! > https://bugs.openjdk.java.net/browse/JDK-8078048 I will. Unfortunately first I have some no-PCH issues to address. And unfortunately they are not top of my priority list right now. Hopefully next week sometime. David > Best regards, > Goetz. > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Donnerstag, 9. April 2015 11:35 > To: Andrew Dinn > Cc: HotSpot Open Source Developers > Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! > > On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn wrote: >> On 09/04/15 09:02, Erik Joelsson wrote: >>> I think that as long as we claim to support building both with and >>> without PCH, the automatic testing should test both with and without >>> PCH. By adding one or two build targets, or perhaps change an existing >>> target, we could increase our test matrix to cover this easily. >> >> I think this restates Volker's original remarks in redux. >> > > No, not at all! I don't necessarily want to test more build > configurations (that's another topic). > > My point is that PCH changes the compilation semantics and can hide > real program errors. That's because with PCHs, every compilation unit > sees the full precompiled header database (i.e. all the headers which > are included in the "precompiled.hpp" PCH file). So if somebody > forgets to include a dependency X.hpp in A.cpp, A.cpp may still > compile with PCH because it includes the precompiled header file > "precompiled.hpp" which in turn includes X.hpp. But the compilation of > A.cpp will fail on platforms/configurations where we do not use > precompiled headers. The two references I gave in my original mail are > bugs that resulted from this problem. > > Besides program errors, the use of PCH can also lead to behavioral > changes in the created binary when it comes to inlining. Because of > PCHs some compilation units may be able to inline methods even if they > do not explicitly include the files which contain the corresponding > implementations because the implementation files are included in the > PCH file. Without PCHs the compilers will simply emit calls to these > functions (and, depending on the toolchain, emit a warning). > > I'm not familiar with ccache so I can not say if it has similar effects. > >> So, given that we do need this (NOW! :-) is anyone able and willing to >> sponsor this? >> > > Yes, this question remains to be answered :) > > Regards, > Volker > >> regards, >> >> >> Andrew Dinn >> ----------- >> From goetz.lindenmaier at sap.com Fri Apr 17 10:35:43 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Apr 2015 10:35:43 +0000 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <5530DEF3.5070301@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> That would be great!! Thanks David, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Freitag, 17. April 2015 12:23 To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn Cc: HotSpot Open Source Developers Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote: > Hi, > > another occurance of this ... please, please add a non-pch build to > jprt! > https://bugs.openjdk.java.net/browse/JDK-8078048 I will. Unfortunately first I have some no-PCH issues to address. And unfortunately they are not top of my priority list right now. Hopefully next week sometime. David > Best regards, > Goetz. > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Donnerstag, 9. April 2015 11:35 > To: Andrew Dinn > Cc: HotSpot Open Source Developers > Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! > > On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn wrote: >> On 09/04/15 09:02, Erik Joelsson wrote: >>> I think that as long as we claim to support building both with and >>> without PCH, the automatic testing should test both with and without >>> PCH. By adding one or two build targets, or perhaps change an existing >>> target, we could increase our test matrix to cover this easily. >> >> I think this restates Volker's original remarks in redux. >> > > No, not at all! I don't necessarily want to test more build > configurations (that's another topic). > > My point is that PCH changes the compilation semantics and can hide > real program errors. That's because with PCHs, every compilation unit > sees the full precompiled header database (i.e. all the headers which > are included in the "precompiled.hpp" PCH file). So if somebody > forgets to include a dependency X.hpp in A.cpp, A.cpp may still > compile with PCH because it includes the precompiled header file > "precompiled.hpp" which in turn includes X.hpp. But the compilation of > A.cpp will fail on platforms/configurations where we do not use > precompiled headers. The two references I gave in my original mail are > bugs that resulted from this problem. > > Besides program errors, the use of PCH can also lead to behavioral > changes in the created binary when it comes to inlining. Because of > PCHs some compilation units may be able to inline methods even if they > do not explicitly include the files which contain the corresponding > implementations because the implementation files are included in the > PCH file. Without PCHs the compilers will simply emit calls to these > functions (and, depending on the toolchain, emit a warning). > > I'm not familiar with ccache so I can not say if it has similar effects. > >> So, given that we do need this (NOW! :-) is anyone able and willing to >> sponsor this? >> > > Yes, this question remains to be answered :) > > Regards, > Volker > >> regards, >> >> >> Andrew Dinn >> ----------- >> From stefan.karlsson at oracle.com Fri Apr 17 10:39:52 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 17 Apr 2015 12:39:52 +0200 Subject: RFR(XS): 8078048: Fix non-pch build after "8076457: Fix includes of inline.hpp in GC code" In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBF5E0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBF5E0@DEWDFEMB12A.global.corp.sap> Message-ID: <5530E2F8.103@oracle.com> On 2015-04-17 11:52, Lindenmaier, Goetz wrote: > > Hi, > > This change fixes the build without precompiled headers. > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8078048-pchBuild/webrev.01/ > > Looks good. I'll push it. Thanks, StefanK > Best regards, > > Goetz. > From mikael.gerdin at oracle.com Fri Apr 17 11:49:13 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 17 Apr 2015 13:49:13 +0200 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <552FB9F0.1030401@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> <552FA5FF.7070702@oracle.com> <552FAC28.2060407@oracle.com> <552FB9F0.1030401@oracle.com> Message-ID: <5530F339.7070004@oracle.com> On 2015-04-16 15:32, Stefan Karlsson wrote: > On 2015-04-16 14:33, David Holmes wrote: >> Hi Stefan, >> >> trimming ... >> >> On 16/04/2015 10:07 PM, Stefan Karlsson wrote: >>> On 2015-04-16 04:23, David Holmes wrote: >>>> Second, more important question: have you examined how this attribute >>>> affects the ability to walk the stack? We have already seen issues on >>>> some platforms where library functions, like abort(), have the >>>> noreturn attribute and as a result the call is optimized in a way that >>>> prevents the stack from being walked - see eg: >>>> >>>> https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 >>>> >>>> >>>> >>>> though this: >>>> >>>> https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 >>>> >>>> suggests that problem may have been addressed by the libc folk. But it >>>> still raises the question as to how our own noreturn functions will be >>>> handled and how they will affect stacktrace generation in hs_err logs >>>> or via gdb. >>> >>> I added a call to fatal(...) in the GC code. I get correct stacktraces >>> in gdb, but the stacktraces in the hs_err files are broken with >>> fastdebug and product builds: >> >> Which platforms? > > On Linux x86 and x86_64. > >> >>> Stack: [0x00007f12518d2000,0x00007f12519d3000], sp=0x00007f12519d0eb0, >>> free space=1019k >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>> C=native code) >>> V [libjvm.so+0x11db44a] VMError::report_and_die()+0x1ba >>> V [libjvm.so+0x7efb80] report_vm_error(char const*, int, char const*, >>> char const*)+0x90 >>> V [libjvm.so+0x7efc49] report_vm_error_noreturn(char const*, int, char >>> const*, char const*)+0x9 >>> V [libjvm.so+0x7efc63] >>> V [libjvm.so+0xfd7937] >>> V [libjvm.so+0xfeec51] >>> ... >> >> So what is the plan: try to get hs_err working again? Or file this >> under "well it seemed like a good idea"? ;-) > > I'm leaning towards "seemed like a good idea", unless someone has an > easy fix for these problems. I've been looking a bit at this. It's not the stack trace per se that is broken, but the decoding of the function names is not working for some of the callers of the noreturn functions. I tried this with report_fatal using -XX:ErrorHandlerTest=5 and got the following: 0x7fb71ccd98d0 : push %rbp 0x7fb71ccd98d1 : mov %rdx,%rcx 0x7fb71ccd98d4 : lea 0x9b4b34(%rip),%rdx 0x7fb71ccd98db : mov %rsp,%rbp 0x7fb71ccd98de : callq 0x7fb71ccd98c0 0x7fb71ccd98e3: data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) So the report_fatal frame has ...98e3 as its return address, but that is actually outside the function and this causes dladdr() to return NULL in dli_saddr and dli_sname. The JVM then attempts to decode using Decoder::decode but I wasn't able to follow that code to understand why that fails. The same appears to happen for the caller of report_fatal (controlled_crash in my case) but there I can't explain why dladdr returns NULL values there. After these two functions the rest of the stack trace appears to be correctly decoded. One approach could be to attempt to inject a "nop" at the end of functions which call a "noreturn" function. This would hopefully make the instruction after the call to the noreturn function part of the caller and would make symbol decoding work. /Mikael > > Thanks, > StefanK > >> >> Cheers, >> David >> >>> Thanks, >>> StefanK >>> >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>> > From goetz.lindenmaier at sap.com Fri Apr 17 12:13:39 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Apr 2015 12:13:39 +0000 Subject: RFR(XS): 8078048: Fix non-pch build after "8076457: Fix includes of inline.hpp in GC code" In-Reply-To: <5530E2F8.103@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBF5E0@DEWDFEMB12A.global.corp.sap> <5530E2F8.103@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBF6F1@DEWDFEMB12A.global.corp.sap> That's great, thanks! Best regards, Goetz. From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] Sent: Freitag, 17. April 2015 12:40 To: Lindenmaier, Goetz; hotspot-dev Source Developers; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(XS): 8078048: Fix non-pch build after "8076457: Fix includes of inline.hpp in GC code" On 2015-04-17 11:52, Lindenmaier, Goetz wrote: Hi, This change fixes the build without precompiled headers. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8078048-pchBuild/webrev.01/ Looks good. I'll push it. Thanks, StefanK Best regards, Goetz. From kedar.mhaswade at gmail.com Fri Apr 17 12:24:03 2015 From: kedar.mhaswade at gmail.com (kedar mhaswade) Date: Fri, 17 Apr 2015 05:24:03 -0700 Subject: JEP 245: Validate JVM Command-Line Flag Arguments In-Reply-To: References: <20150416225421.C35DE567AC@eggemoggin.niobe.net> Message-ID: +1. Will this also make the 'java command line' a public interface of the Java platform? Martijn -- in your case, would the ?examination of the output of the ? flag -XX:+PrintFlagsFinal have helped? But then that flag makes the JVM startup print values of the JVM options as represented by the internals, not how one specified on the command line. (e.g. uintx GCTimeLimit = 98 {product} ). On Fri, Apr 17, 2015 at 3:19 AM, Martijn Verburg wrote: > Hi all, > > This would be of great benefit to the tools space, we just spent the last > couple of days digging into GC flag (invalid) values causing 'interesting' > things to happen. > > Having info messages instead of a JVM crash will also reduce the number of > JVM crashes we see out there. WRT to performance tuning this will allow > people to rapidly change settings in test with more confidence. > > Anyhow, thanks for proposing this JEP! > > > > Cheers, > Martijn > > On 17 April 2015 at 00:54, wrote: > > > New JEP Candidate: http://openjdk.java.net/jeps/245 > > > > - Mark > > > From fredrik.arvidsson at oracle.com Fri Apr 17 12:36:05 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 17 Apr 2015 14:36:05 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: References: <5530B711.2070009@oracle.com> Message-ID: <5530FE35.3010107@oracle.com> Hi Martijn, and the others :) I'm glad you like what we do. We also think the tag based logging is something good, and that it will make the logging in the JVM easier to implement, configure and consume. Regarding 'binary / compressed' log format. We are not planning to add any structured log format to the unified logging framework. It is outside the scope of this JEP. The log data format is a simple string with some well defined decorations. The logs are primarily meant to be read by humans. There will be log output extension points in the framework, but they will not be accessible publicly and they will not support 3rd party extensions in runtime. Even if the output extension API would be made fully accessible, the data fed in to it would still only be a string, since thats what the developers are adding in the code where the logging framework is called. I guess one could add compression of log data as an extension, but I don't think that is really what you are asking for. As you might know, Oracle offers low latency low intrusive structured logging in its Java Flight Recorder product. We are not aiming in this JEP to overlap that functionality more than absolutely needed. Cheers /Fredrik On 2015-04-17 12:12, Martijn Verburg wrote: > Hi Fredrik, > > Thanks from us (jClarity and some other orgs) for considering the tag > based system, we're really glad you've gone in this direction. One > quick bit of feedback. > > Is it possible to add a binary / compressed logging format or an > interface/ API to plug one in for high performance Logging? Human > readable is nice for looking at logs immediately, but for some of our > customers they'd be looking to offload that concern to another > process/host. > > Cheers, > Martijn > > On 17 April 2015 at 09:32, Fredrik Arvidsson > > > wrote: > > Hi > > We are planning to release an updated version of JEP-158 very > soon. The work to update this JEP has been going on for some time > and we now feel we are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. > The requirements for the API and implementation were heavily > influenced by the logging functionality in JRockit JVM. The JEP > was updated and refined in mid 2014 and eventually targeted for > JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced > about the chosen API and functionality but the conclusion was that > the proposal would work, and the JEP was targeted for JDK 9 and > the implementation work was started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of > the JEP, this time with greater force. At this point we decided to > take a time-out and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject > layout to something that could be best described as a tag based > solution. > > The main reason for the change of the logging API is that we have > found that some logging can't easily be ordered under a single > hierarchical subject but can belong to multiple subjects/areas. > One example of this is logging in the 'metaspace' code. The > functionality in the 'metaspace area' can be called from both GC > and Runtime code. Another example is class-unloading. There are > more examples on this of course, but these two we think are very > clear and easy to understand. > > The core functionality of the logging framework is not changed > that much from the earlier proposal. We have tried to make it > leaner and not as verbose (functionality wise) as before. The > scope of the implementation has been narrowed down some to enable > us to deliver good value as soon as possible. > > Our plan is as follows: > After getting initial feedback from the community about the new > proposal we will update the JEP description. We aim to do this > early next week. > We are planning to use the JDK9 sandbox repository during > development. This enables us who are implementing it to work in an > efficient way and at the same time it allows any interested party > to try out and follow the work during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. > > From stefan.karlsson at oracle.com Fri Apr 17 12:52:01 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 17 Apr 2015 14:52:01 +0200 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <5530F339.7070004@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> <552FA5FF.7070702@oracle.com> <552FAC28.2060407@oracle.com> <552FB9F0.1030401@oracle.com> <5530F339.7070004@oracle.com> Message-ID: <553101F1.4010500@oracle.com> On 2015-04-17 13:49, Mikael Gerdin wrote: > On 2015-04-16 15:32, Stefan Karlsson wrote: >> On 2015-04-16 14:33, David Holmes wrote: >>> Hi Stefan, >>> >>> trimming ... >>> >>> On 16/04/2015 10:07 PM, Stefan Karlsson wrote: >>>> On 2015-04-16 04:23, David Holmes wrote: >>>>> Second, more important question: have you examined how this attribute >>>>> affects the ability to walk the stack? We have already seen issues on >>>>> some platforms where library functions, like abort(), have the >>>>> noreturn attribute and as a result the call is optimized in a way >>>>> that >>>>> prevents the stack from being walked - see eg: >>>>> >>>>> https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 >>>>> >>>>> >>>>> >>>>> >>>>> though this: >>>>> >>>>> https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 >>>>> >>>>> suggests that problem may have been addressed by the libc folk. >>>>> But it >>>>> still raises the question as to how our own noreturn functions >>>>> will be >>>>> handled and how they will affect stacktrace generation in hs_err logs >>>>> or via gdb. >>>> >>>> I added a call to fatal(...) in the GC code. I get correct stacktraces >>>> in gdb, but the stacktraces in the hs_err files are broken with >>>> fastdebug and product builds: >>> >>> Which platforms? >> >> On Linux x86 and x86_64. >> >>> >>>> Stack: [0x00007f12518d2000,0x00007f12519d3000], sp=0x00007f12519d0eb0, >>>> free space=1019k >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>> C=native code) >>>> V [libjvm.so+0x11db44a] VMError::report_and_die()+0x1ba >>>> V [libjvm.so+0x7efb80] report_vm_error(char const*, int, char >>>> const*, >>>> char const*)+0x90 >>>> V [libjvm.so+0x7efc49] report_vm_error_noreturn(char const*, int, >>>> char >>>> const*, char const*)+0x9 >>>> V [libjvm.so+0x7efc63] >>>> V [libjvm.so+0xfd7937] >>>> V [libjvm.so+0xfeec51] >>>> ... >>> >>> So what is the plan: try to get hs_err working again? Or file this >>> under "well it seemed like a good idea"? ;-) >> >> I'm leaning towards "seemed like a good idea", unless someone has an >> easy fix for these problems. > > I've been looking a bit at this. It's not the stack trace per se that > is broken, but the decoding of the function names is not working for > some of the callers of the noreturn functions. > > I tried this with report_fatal using -XX:ErrorHandlerTest=5 and got > the following: > > 0x7fb71ccd98d0 : push %rbp > 0x7fb71ccd98d1 : mov %rdx,%rcx > 0x7fb71ccd98d4 : lea 0x9b4b34(%rip),%rdx > 0x7fb71ccd98db : mov %rsp,%rbp > 0x7fb71ccd98de : callq 0x7fb71ccd98c0 > 0x7fb71ccd98e3: data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) > > So the report_fatal frame has ...98e3 as its return address, but that > is actually outside the function and this causes dladdr() to return > NULL in dli_saddr and dli_sname. > > The JVM then attempts to decode using Decoder::decode but I wasn't > able to follow that code to understand why that fails. > > The same appears to happen for the caller of report_fatal > (controlled_crash in my case) but there I can't explain why dladdr > returns NULL values there. > > After these two functions the rest of the stack trace appears to be > correctly decoded. > > One approach could be to attempt to inject a "nop" at the end of > functions which call a "noreturn" function. This would hopefully make > the instruction after the call to the noreturn function part of the > caller and would make symbol decoding work. I found this mail thread: https://sourceware.org/bugzilla/show_bug.cgi?id=6522 which blames the -fcross-jumping optimization. I recompiled hotspot with OPT_CFLAGS/debug.o=-fno-crossjumping, and now I get correct stack traces with fastdebug on Linux 64 bits. StefanK > > /Mikael > >> >> Thanks, >> StefanK >> >>> >>> Cheers, >>> David >>> >>>> Thanks, >>>> StefanK >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>> >> > From karen.kinnear at oracle.com Fri Apr 17 12:56:54 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 17 Apr 2015 08:56:54 -0400 Subject: JEP 245: Validate JVM Command-Line Flag Arguments In-Reply-To: References: <20150416225421.C35DE567AC@eggemoggin.niobe.net> Message-ID: <5E18F132-2753-4E64-AC7F-694DC84177C4@oracle.com> The PrintFlagsFinal is supposed to represent the state of the flags at the end of startup processing which includes both command-line specified and internal values and their interactions. This is intended to increase stability. It is not changing the current java command line conventions. thanks, Karen On Apr 17, 2015, at 8:24 AM, kedar mhaswade wrote: > +1. Will this also make the 'java command line' a public interface of the > Java platform? > > Martijn -- in your case, would the > ?examination of the output of the ? > flag -XX:+PrintFlagsFinal > have helped? But then that flag makes the JVM startup print values of the > JVM options as represented by the internals, not how one specified on the > command line. (e.g. uintx GCTimeLimit = > 98 {product} ). > > > On Fri, Apr 17, 2015 at 3:19 AM, Martijn Verburg > wrote: > >> Hi all, >> >> This would be of great benefit to the tools space, we just spent the last >> couple of days digging into GC flag (invalid) values causing 'interesting' >> things to happen. >> >> Having info messages instead of a JVM crash will also reduce the number of >> JVM crashes we see out there. WRT to performance tuning this will allow >> people to rapidly change settings in test with more confidence. >> >> Anyhow, thanks for proposing this JEP! >> >> >> >> Cheers, >> Martijn >> >> On 17 April 2015 at 00:54, wrote: >> >>> New JEP Candidate: http://openjdk.java.net/jeps/245 >>> >>> - Mark >>> >> From mattis.castegren at oracle.com Fri Apr 17 13:16:32 2015 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Fri, 17 Apr 2015 06:16:32 -0700 (PDT) Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530FE35.3010107@oracle.com> References: <5530B711.2070009@oracle.com> <5530FE35.3010107@oracle.com> Message-ID: I guess it would be a possible later enhancement request to add a new logging tag ?gc_compressed? for example that prints gc output in some easy to parse format. It could be one line of comma separated values per GC for example that you could import to other tools. ? But I agree with Fredrik, we should look at exactly what problems you try to solve, and see if it instead can be solved in JFR. You could make a recording that only gathers GC data, and you could run it for days and still get a pretty small recording (at least smaller than what a corresponding gc log would be). If you then still feel the need to import the data to some other tool, maybe we should add that tool?s functionality to Mission Control? ? Kind Regards /Mattis ? From: Fredrik Arvidsson Sent: den 17 april 2015 14:36 To: Martijn Verburg Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers Subject: Re: Updates to JEP-158: JVM Unified Logging are coming... ? Hi Martijn, and the others :) I'm glad you like what we do. We also think the tag based logging is something good, and that it will make the logging in the JVM easier to implement, configure and consume. Regarding 'binary / compressed' log format. We are not planning to add any structured log format to the unified logging framework. It is outside the scope of this JEP. The log data format is a simple string with some well defined decorations. The logs are primarily meant to be read by humans. There will be log output extension points in the framework, but they will not be accessible publicly and they will not support 3rd party extensions in runtime. Even if the output extension API would be made fully accessible, the data fed in to it would still only be a string, since thats what the developers are adding in the code where the logging framework is called. I guess one could add compression of log data as an extension, but I don't think that is really what you are asking for. As you might know, Oracle offers low latency low intrusive structured logging in its Java Flight Recorder product. We are not aiming in this JEP to overlap that functionality more than absolutely needed. Cheers /Fredrik On 2015-04-17 12:12, Martijn Verburg wrote: Hi Fredrik, ? Thanks from us (jClarity and some other orgs) for considering the tag based system, we're really glad you've gone in this direction.? One quick bit of feedback. ? Is it possible to add a binary / compressed logging format or an interface/ API to plug one in for high performance Logging?? Human readable is nice for looking at logs immediately, but for some of our customers they'd be looking to offload that concern to another process/host. Cheers, Martijn ? On 17 April 2015 at 09:32, Fredrik Arvidsson wrote: Hi We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience. The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014: https://bugs.openjdk.java.net/browse/JDK-8046148 During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started. Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward. The time-out led to a modified proposal that can be found here: HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158.html" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html and with some illustrations here: HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158_Illustration.png" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png So what have we changed, and why? In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution. The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand. The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible. Our plan is as follows: After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week. We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase. More information about the sandbox repository name and other practicalities will follow shortly. Cheers Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. ? ? From mikael.gerdin at oracle.com Fri Apr 17 14:55:22 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 17 Apr 2015 16:55:22 +0200 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <553101F1.4010500@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> <552FA5FF.7070702@oracle.com> <552FAC28.2060407@oracle.com> <552FB9F0.1030401@oracle.com> <5530F339.7070004@oracle.com> <553101F1.4010500@oracle.com> Message-ID: <55311EDA.6090205@oracle.com> On 2015-04-17 14:52, Stefan Karlsson wrote: > > > On 2015-04-17 13:49, Mikael Gerdin wrote: >> On 2015-04-16 15:32, Stefan Karlsson wrote: >>> On 2015-04-16 14:33, David Holmes wrote: >>>> Hi Stefan, >>>> >>>> trimming ... >>>> >>>> On 16/04/2015 10:07 PM, Stefan Karlsson wrote: >>>>> On 2015-04-16 04:23, David Holmes wrote: >>>>>> Second, more important question: have you examined how this attribute >>>>>> affects the ability to walk the stack? We have already seen issues on >>>>>> some platforms where library functions, like abort(), have the >>>>>> noreturn attribute and as a result the call is optimized in a way >>>>>> that >>>>>> prevents the stack from being walked - see eg: >>>>>> >>>>>> https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> though this: >>>>>> >>>>>> https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 >>>>>> >>>>>> suggests that problem may have been addressed by the libc folk. >>>>>> But it >>>>>> still raises the question as to how our own noreturn functions >>>>>> will be >>>>>> handled and how they will affect stacktrace generation in hs_err logs >>>>>> or via gdb. >>>>> >>>>> I added a call to fatal(...) in the GC code. I get correct stacktraces >>>>> in gdb, but the stacktraces in the hs_err files are broken with >>>>> fastdebug and product builds: >>>> >>>> Which platforms? >>> >>> On Linux x86 and x86_64. >>> >>>> >>>>> Stack: [0x00007f12518d2000,0x00007f12519d3000], sp=0x00007f12519d0eb0, >>>>> free space=1019k >>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>> C=native code) >>>>> V [libjvm.so+0x11db44a] VMError::report_and_die()+0x1ba >>>>> V [libjvm.so+0x7efb80] report_vm_error(char const*, int, char >>>>> const*, >>>>> char const*)+0x90 >>>>> V [libjvm.so+0x7efc49] report_vm_error_noreturn(char const*, int, >>>>> char >>>>> const*, char const*)+0x9 >>>>> V [libjvm.so+0x7efc63] >>>>> V [libjvm.so+0xfd7937] >>>>> V [libjvm.so+0xfeec51] >>>>> ... >>>> >>>> So what is the plan: try to get hs_err working again? Or file this >>>> under "well it seemed like a good idea"? ;-) >>> >>> I'm leaning towards "seemed like a good idea", unless someone has an >>> easy fix for these problems. >> >> I've been looking a bit at this. It's not the stack trace per se that >> is broken, but the decoding of the function names is not working for >> some of the callers of the noreturn functions. >> >> I tried this with report_fatal using -XX:ErrorHandlerTest=5 and got >> the following: >> >> 0x7fb71ccd98d0 : push %rbp >> 0x7fb71ccd98d1 : mov %rdx,%rcx >> 0x7fb71ccd98d4 : lea 0x9b4b34(%rip),%rdx >> 0x7fb71ccd98db : mov %rsp,%rbp >> 0x7fb71ccd98de : callq 0x7fb71ccd98c0 >> 0x7fb71ccd98e3: data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) >> >> So the report_fatal frame has ...98e3 as its return address, but that >> is actually outside the function and this causes dladdr() to return >> NULL in dli_saddr and dli_sname. >> >> The JVM then attempts to decode using Decoder::decode but I wasn't >> able to follow that code to understand why that fails. >> >> The same appears to happen for the caller of report_fatal >> (controlled_crash in my case) but there I can't explain why dladdr >> returns NULL values there. >> >> After these two functions the rest of the stack trace appears to be >> correctly decoded. >> >> One approach could be to attempt to inject a "nop" at the end of >> functions which call a "noreturn" function. This would hopefully make >> the instruction after the call to the noreturn function part of the >> caller and would make symbol decoding work. > > I found this mail thread: > https://sourceware.org/bugzilla/show_bug.cgi?id=6522 > > which blames the -fcross-jumping optimization. > > I recompiled hotspot with OPT_CFLAGS/debug.o=-fno-crossjumping, and now > I get correct stack traces with fastdebug on Linux 64 bits. I did a more thorough investigation into this on a slowdebug build, and the reason for the symbols missing appears to be that after the JVM's ELF Decoder runs into an un-decodeable symbol because a return PC points to a nop in-between two symbols (because it's just called a noreturn function) the Decoder sets m_status to FileInvalid and refuses to decode any more symbols. If I comment out the code to set the fail status I get a fairly normal hs err stacktrace: V [libjvm.so+0xf184c8] VMError::report(outputStream*)+0x133c V [libjvm.so+0xf19865] VMError::report_and_die()+0x411 V [libjvm.so+0x7876de] report_vm_error(char const*, int, char const*, char const*)+0xba V [libjvm.so+0x7877d7] report_vm_error_noreturn(char const*, int, char const*, char const*)+0x3d V [libjvm.so+0x78781b] report_should_not_call(char const*, int)+0x0 V [libjvm.so+0x92bfeb] V [libjvm.so+0x6e10ff] GenCollectorPolicy::mem_allocate_work(unsigned long, bool, bool*)+0x283 V [libjvm.so+0x92c049] GenCollectedHeap::mem_allocate(unsigned long, bool*)+0x5d V [libjvm.so+0x45dbe5] CollectedHeap::common_mem_allocate_noinit(KlassHandle, unsigned long, Thread*)+0x103 V [libjvm.so+0x45dda2] CollectedHeap::common_mem_allocate_init(KlassHandle, unsigned long, Thread*)+0x4e V [libjvm.so+0x45e034] CollectedHeap::array_allocate(KlassHandle, int, int, Thread*)+0xac V [libjvm.so+0xed2f04] TypeArrayKlass::allocate_common(int, bool, Thread*)+0xf0 V [libjvm.so+0x44ae3e] TypeArrayKlass::allocate(int, Thread*)+0x3e V [libjvm.so+0xcef2d5] oopFactory::new_typeArray(BasicType, int, Thread*)+0x55 V [libjvm.so+0x9c5aa9] InterpreterRuntime::newarray(JavaThread*, BasicType, int)+0x147 j alloc.AllocArrays.main([Ljava/lang/String;)V+237 v ~StubRoutines::call_stub V [libjvm.so+0x9df121] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b1 V [libjvm.so+0xd091d7] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x41 V [libjvm.so+0x9dea5a] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x86 V [libjvm.so+0xa42306] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x200 V [libjvm.so+0xa5964a] jni_CallStaticVoidMethod+0x353 C [libjli.so+0x86ed] JavaMain+0x93c C [libpthread.so.0+0x80a5] start_thread+0xc5 One problem is the line V [libjvm.so+0x78781b] report_should_not_call(char const*, int)+0x0 I actually added a call to fatal(), but since fatal calls a noreturn function the return pc of that frame accidentally points to the first instruction in the next function, which happens to be report_should_not_call. I wonder if this could be fixed by forcing gcc to empit a nop after the call to report_vm_error_noreturn in report_fatal and friends. __asm__ __volatile__ ("nop" : : :); appears to not be enough. GCC is very aggressive with noreturn, even with -O0. /Mikael > > StefanK >> >> /Mikael >> >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Cheers, >>>> David >>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>> >>> >> > From stefan.karlsson at oracle.com Fri Apr 17 15:03:36 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 17 Apr 2015 17:03:36 +0200 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <55311EDA.6090205@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> <552FA5FF.7070702@oracle.com> <552FAC28.2060407@oracle.com> <552FB9F0.1030401@oracle.com> <5530F339.7070004@oracle.com> <553101F1.4010500@oracle.com> <55311EDA.6090205@oracle.com> Message-ID: <553120C8.8030108@oracle.com> On 2015-04-17 16:55, Mikael Gerdin wrote: > On 2015-04-17 14:52, Stefan Karlsson wrote: >> >> >> On 2015-04-17 13:49, Mikael Gerdin wrote: >>> On 2015-04-16 15:32, Stefan Karlsson wrote: >>>> On 2015-04-16 14:33, David Holmes wrote: >>>>> Hi Stefan, >>>>> >>>>> trimming ... >>>>> >>>>> On 16/04/2015 10:07 PM, Stefan Karlsson wrote: >>>>>> On 2015-04-16 04:23, David Holmes wrote: >>>>>>> Second, more important question: have you examined how this >>>>>>> attribute >>>>>>> affects the ability to walk the stack? We have already seen >>>>>>> issues on >>>>>>> some platforms where library functions, like abort(), have the >>>>>>> noreturn attribute and as a result the call is optimized in a way >>>>>>> that >>>>>>> prevents the stack from being walked - see eg: >>>>>>> >>>>>>> https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> though this: >>>>>>> >>>>>>> https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 >>>>>>> >>>>>>> suggests that problem may have been addressed by the libc folk. >>>>>>> But it >>>>>>> still raises the question as to how our own noreturn functions >>>>>>> will be >>>>>>> handled and how they will affect stacktrace generation in hs_err >>>>>>> logs >>>>>>> or via gdb. >>>>>> >>>>>> I added a call to fatal(...) in the GC code. I get correct >>>>>> stacktraces >>>>>> in gdb, but the stacktraces in the hs_err files are broken with >>>>>> fastdebug and product builds: >>>>> >>>>> Which platforms? >>>> >>>> On Linux x86 and x86_64. >>>> >>>>> >>>>>> Stack: [0x00007f12518d2000,0x00007f12519d3000], >>>>>> sp=0x00007f12519d0eb0, >>>>>> free space=1019k >>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>>> C=native code) >>>>>> V [libjvm.so+0x11db44a] VMError::report_and_die()+0x1ba >>>>>> V [libjvm.so+0x7efb80] report_vm_error(char const*, int, char >>>>>> const*, >>>>>> char const*)+0x90 >>>>>> V [libjvm.so+0x7efc49] report_vm_error_noreturn(char const*, int, >>>>>> char >>>>>> const*, char const*)+0x9 >>>>>> V [libjvm.so+0x7efc63] >>>>>> V [libjvm.so+0xfd7937] >>>>>> V [libjvm.so+0xfeec51] >>>>>> ... >>>>> >>>>> So what is the plan: try to get hs_err working again? Or file this >>>>> under "well it seemed like a good idea"? ;-) >>>> >>>> I'm leaning towards "seemed like a good idea", unless someone has an >>>> easy fix for these problems. >>> >>> I've been looking a bit at this. It's not the stack trace per se that >>> is broken, but the decoding of the function names is not working for >>> some of the callers of the noreturn functions. >>> >>> I tried this with report_fatal using -XX:ErrorHandlerTest=5 and got >>> the following: >>> >>> 0x7fb71ccd98d0 : push %rbp >>> 0x7fb71ccd98d1 : mov %rdx,%rcx >>> 0x7fb71ccd98d4 : lea 0x9b4b34(%rip),%rdx >>> 0x7fb71ccd98db : mov %rsp,%rbp >>> 0x7fb71ccd98de : callq 0x7fb71ccd98c0 >>> 0x7fb71ccd98e3: data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) >>> >>> So the report_fatal frame has ...98e3 as its return address, but that >>> is actually outside the function and this causes dladdr() to return >>> NULL in dli_saddr and dli_sname. >>> >>> The JVM then attempts to decode using Decoder::decode but I wasn't >>> able to follow that code to understand why that fails. >>> >>> The same appears to happen for the caller of report_fatal >>> (controlled_crash in my case) but there I can't explain why dladdr >>> returns NULL values there. >>> >>> After these two functions the rest of the stack trace appears to be >>> correctly decoded. >>> >>> One approach could be to attempt to inject a "nop" at the end of >>> functions which call a "noreturn" function. This would hopefully make >>> the instruction after the call to the noreturn function part of the >>> caller and would make symbol decoding work. >> >> I found this mail thread: >> https://sourceware.org/bugzilla/show_bug.cgi?id=6522 >> >> which blames the -fcross-jumping optimization. >> >> I recompiled hotspot with OPT_CFLAGS/debug.o=-fno-crossjumping, and now >> I get correct stack traces with fastdebug on Linux 64 bits. > > I did a more thorough investigation into this on a slowdebug build, > and the reason for the symbols missing appears to be that after the > JVM's ELF Decoder runs into an un-decodeable symbol because a return > PC points to a nop in-between two symbols (because it's just called a > noreturn function) the Decoder sets m_status to FileInvalid and > refuses to decode any more symbols. > If I comment out the code to set the fail status I get a fairly normal > hs err stacktrace: > > V [libjvm.so+0xf184c8] VMError::report(outputStream*)+0x133c > V [libjvm.so+0xf19865] VMError::report_and_die()+0x411 > V [libjvm.so+0x7876de] report_vm_error(char const*, int, char > const*, char const*)+0xba > V [libjvm.so+0x7877d7] report_vm_error_noreturn(char const*, int, > char const*, char const*)+0x3d > V [libjvm.so+0x78781b] report_should_not_call(char const*, int)+0x0 > V [libjvm.so+0x92bfeb] > V [libjvm.so+0x6e10ff] GenCollectorPolicy::mem_allocate_work(unsigned > long, bool, bool*)+0x283 > V [libjvm.so+0x92c049] GenCollectedHeap::mem_allocate(unsigned long, > bool*)+0x5d > V [libjvm.so+0x45dbe5] > CollectedHeap::common_mem_allocate_noinit(KlassHandle, unsigned long, > Thread*)+0x103 > V [libjvm.so+0x45dda2] > CollectedHeap::common_mem_allocate_init(KlassHandle, unsigned long, > Thread*)+0x4e > V [libjvm.so+0x45e034] CollectedHeap::array_allocate(KlassHandle, > int, int, Thread*)+0xac > V [libjvm.so+0xed2f04] TypeArrayKlass::allocate_common(int, bool, > Thread*)+0xf0 > V [libjvm.so+0x44ae3e] TypeArrayKlass::allocate(int, Thread*)+0x3e > V [libjvm.so+0xcef2d5] oopFactory::new_typeArray(BasicType, int, > Thread*)+0x55 > V [libjvm.so+0x9c5aa9] InterpreterRuntime::newarray(JavaThread*, > BasicType, int)+0x147 > j alloc.AllocArrays.main([Ljava/lang/String;)V+237 > v ~StubRoutines::call_stub > V [libjvm.so+0x9df121] JavaCalls::call_helper(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*)+0x6b1 > V [libjvm.so+0xd091d7] os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, > methodHandle*, JavaCallArguments*, Thread*)+0x41 > V [libjvm.so+0x9dea5a] JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*)+0x86 > V [libjvm.so+0xa42306] jni_invoke_static(JNIEnv_*, JavaValue*, > _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x200 > V [libjvm.so+0xa5964a] jni_CallStaticVoidMethod+0x353 > C [libjli.so+0x86ed] JavaMain+0x93c > C [libpthread.so.0+0x80a5] start_thread+0xc5 > > One problem is the line > V [libjvm.so+0x78781b] report_should_not_call(char const*, int)+0x0 > I actually added a call to fatal(), but since fatal calls a noreturn > function the return pc of that frame accidentally points to the first > instruction in the next function, which happens to be > report_should_not_call. > > I wonder if this could be fixed by forcing gcc to empit a nop after > the call to report_vm_error_noreturn in report_fatal and friends. > __asm__ __volatile__ ("nop" : : :); > appears to not be enough. GCC is very aggressive with noreturn, even > with -O0. And the reason why m_status was set to FileInvalid seems to be the bug in ElfSymbolTable::lookup, which returns true instead of false if it fails to find a symbol!: bool ElfSymbolTable::lookup(address addr, int* stringtableIndex, int* posIndex, int* offset, ElfFuncDescTable* funcDescTable) { ... return true; } The caller will then think that the symbol was found and use the uninitialized output parameters. StefanK > > /Mikael > >> >> StefanK >>> >>> /Mikael >>> >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> StefanK >>>>>>>> >>>>>> >>>> >>> >> From vladimir.kozlov at oracle.com Fri Apr 17 16:50:19 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Apr 2015 09:50:19 -0700 Subject: RFR: 8076488: AARCH64: jdk9 fails to build from source In-Reply-To: <5530D5A7.90105@redhat.com> References: <1427905684.1631.12.camel@mylittlepony.linaroharston> <551C300D.2090005@oracle.com> <5530D3D2.5090505@redhat.com> <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com> <5530D501.1010004@redhat.com> <5530D5A7.90105@redhat.com> Message-ID: <553139CB.8090303@oracle.com> > Ah, no I won't. My patch already fixed this, and (IMO) in a much better > way. This patch is already in jprt, and will emerge soon, I hope. Andrew, do you mean the change pushed few days ago as part of 8077615 changes?: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2a6c4bd248cf Thanks, Vladimir On 4/17/15 2:43 AM, Andrew Haley wrote: > On 04/17/2015 10:40 AM, Andrew Haley wrote: >> On 04/17/2015 10:39 AM, Roland Westrelin wrote: >>>>> Looks good to me. >>>> >>>> As a 2nd review***, yes this patch is good. Is that enough for it to be >>>> pushed to jdk9? >>>> >>>> ***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only >>>> and I /am/ an aarch64-port committer/reviewer. >>> >>> In case another review helps: that looks good to me. >> >> OK, I'll push it. > > Ah, no I won't. My patch already fixed this, and (IMO) in a much better > way. This patch is already in jprt, and will emerge soon, I hope. > > diff -r 9c916db4bf3b -r 6463e57d9761 src/cpu/aarch64/vm/interp_masm_aarch64.hpp > --- a/src/cpu/aarch64/vm/interp_masm_aarch64.hpp Thu Apr 09 17:38:28 2015 -0700 > +++ b/src/cpu/aarch64/vm/interp_masm_aarch64.hpp Tue Apr 14 11:43:18 2015 +0100 > @@ -1,6 +1,6 @@ > /* > * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. > - * Copyright (c) 2014, Red Hat Inc. All rights reserved. > + * Copyright (c) 2014, 2015, Red Hat Inc. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -40,6 +40,8 @@ > > protected: > // Interpreter specific version of call_VM_base > + using MacroAssembler::call_VM_leaf_base; > + > virtual void call_VM_leaf_base(address entry_point, > int number_of_arguments); > > Andrew. > > From aph at redhat.com Fri Apr 17 17:08:50 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Apr 2015 18:08:50 +0100 Subject: RFR: 8076488: AARCH64: jdk9 fails to build from source In-Reply-To: <553139CB.8090303@oracle.com> References: <1427905684.1631.12.camel@mylittlepony.linaroharston> <551C300D.2090005@oracle.com> <5530D3D2.5090505@redhat.com> <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com> <5530D501.1010004@redhat.com> <5530D5A7.90105@redhat.com> <553139CB.8090303@oracle.com> Message-ID: <55313E22.1000800@redhat.com> On 04/17/2015 05:50 PM, Vladimir Kozlov wrote: > > Ah, no I won't. My patch already fixed this, and (IMO) in a much better > > way. This patch is already in jprt, and will emerge soon, I hope. > > Andrew, do you mean the change pushed few days ago as part of 8077615 changes?: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2a6c4bd248cf Yes. Andrew. From vladimir.kozlov at oracle.com Fri Apr 17 19:13:03 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Apr 2015 12:13:03 -0700 Subject: RFR(S): 8077843: adlc: allow nodes that use TEMP inputs in expand rules. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBF52B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBEEE0@DEWDFEMB12A.global.corp.sap> <55305389.5020600@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF52B@DEWDFEMB12A.global.corp.sap> Message-ID: <55315B3F.9020708@oracle.com> Okay. I see. Looks good then. I will push it. Thanks, Vladimir On 4/17/15 12:25 AM, Lindenmaier, Goetz wrote: > HI Vladimir, > > the node generated in the Expand has a match rule itself. > I checked, all the TEMPs we use are in nodes with match rules. > Anyways, you get a syntax error if not: > "Syntax Error: : TEMPs without match rule isn't supported" > > We use nodes with match rules in expands a lot, as the match rule > is required for a lot of things. For example to generate the proper > ideal opcode, get it in the array must_clone etc. > If we don't want the nodes to be matched, we add predicate(false). > In our internal VM, we use nodes with TEMPs in expands on ia64 a lot. > > For the code generated for the nodes I intend to contribute, see > below. > > Best regards, > Goetz. > > > // Card-mark for CMS garbage collection. > // This cardmark does an optimization so that it must not always > // do a releasing store. For this, it gets the address of > // CMSCollectorCardTableModRefBSExt::_requires_release as input. > // (Using releaseFieldAddr in the match rule is a hack.) > instruct storeCM_CMS(memory mem, iRegLdst releaseFieldAddr, flagsReg crx) %{ > match(Set mem (StoreCM mem releaseFieldAddr)); > effect(TEMP crx); > predicate(false); > ins_cost(MEMORY_REF_COST); > > // See loadConP. > ins_cannot_rematerialize(true); > > format %{ "STB #0, $mem \t// CMS card-mark byte (must be 0!), checking requires_release in [$releaseFieldAddr]" %} > ins_encode( enc_cms_card_mark(mem, releaseFieldAddr, crx) ); > ins_pipe(pipe_class_memory); > %} > > // Card-mark for CMS garbage collection. > // This cardmark does an optimization so that it must not always > // do a releasing store. For this, it needs the constant address of > // CMSCollectorCardTableModRefBSExt::_requires_release. > // This constant address is split off here by expand so we can use > // adlc / matcher functionality to load it from the constant section. > instruct storeCM_CMS_ExEx(memory mem, immI_0 zero) %{ > match(Set mem (StoreCM mem zero)); > predicate(UseConcMarkSweepGC); > > expand %{ > immL baseImm %{ 0 /* TODO: PPC port (jlong)CMSCollectorCardTableModRefBSExt::requires_release_address() */ %} > iRegLdst releaseFieldAddress; > flagsReg crx; > loadConL_Ex(releaseFieldAddress, baseImm); > storeCM_CMS(mem, releaseFieldAddress, crx); > %} > %} > > > MachNode* storeCM_CMSNode::Expand(State* state, Node_List& proj_list, Node* mem) { > Compile* C = Compile::current(); > // Add projection edges for additional defs or kills > // TEMP crx > MachTempNode *def; > def = new MachTempNode(state->MachOperGenerator(FLAGSREG)); > add_req(def); > > return this; > } > > MachNode* storeCM_CMS_ExExNode::Expand(State* state, Node_List& proj_list, Node* mem) { > Compile* C = Compile::current(); > MachOper *op0 = new immLOper( > #line 6571 "/sapmnt/home1/d045726/oJ/8077838-ppc-hs-comp/src/cpu/ppc/vm/ppc.ad" > 0 /* TODO: PPC port (jlong)CMSCollectorCardTableModRefBSExt::requires_release_address() */ > #line 527 "../generated/adfiles/ad_ppc_64_expand.cpp" > ); > MachOper *op1 = new iRegLdstOper(); > MachOper *op2 = new flagsRegOper(); > MachNode *tmp0 = this; > MachNode *tmp1 = this; > MachNode *tmp2 = this; > MachNode *tmp3 = NULL; > MachNode *tmp4 = NULL; > MachNode *tmp5 = NULL; > unsigned num0 = 0; > unsigned num1 = opnd_array(1)->num_edges(); > unsigned num2 = opnd_array(2)->num_edges(); > unsigned idx0 = oper_input_base(); > if (mem == (Node*)1) { > idx0--; // Adjust base because memory edge hasn't been inserted yet > } > unsigned idx1 = idx0 + num0; > unsigned idx2 = idx1 + num1; > unsigned idx3 = idx2 + num2; > MachNode *result = NULL; > > loadConL_ExNode *n0 = new loadConL_ExNode(); > n0->add_req(_in[0]); > ((MachTypeNode*)n0)->_bottom_type = bottom_type(); > n0->set_opnd_array(0, state->MachOperGenerator(IREGLDST)); > tmp4 = n0; > n0->set_opnd_array(1, op0->clone()); // baseImm > if(tmp3 != NULL) > n0->add_req(tmp3); > result = n0->Expand( state, proj_list, mem ); > > storeCM_CMSNode *n1 = new storeCM_CMSNode(); > n1->add_req(_in[0]); > ((MachTypeNode*)n1)->_bottom_type = bottom_type(); > n1->set_opnd_array(0, state->MachOperGenerator(UNIVERSE)); > if (mem != (Node*)1) { > n1->add_req(_in[1]); // Add memory edge > } > n1->set_opnd_array(1, opnd_array(1)->clone()); // mem > if(tmp1 == this) { > for(unsigned i = 0; i < num1; i++) { > n1->add_req(_in[i + idx1]); > } > } > else n1->add_req(tmp1); > tmp1 = n1; > n1->set_opnd_array(2, op1->clone()); // releaseFieldAddress > if(tmp4 != NULL) > n1->add_req(tmp4); > n1->set_opnd_array(3, op2->clone()); // crx > if(tmp5 != NULL) > n1->add_req(tmp5); > result = n1->Expand( state, proj_list, mem ); > > > return result; > } > > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Freitag, 17. April 2015 02:28 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8077843: adlc: allow nodes that use TEMP inputs in expand rules. > > Here is what Tom R said during review of TEMP implementation: > > >> 3. In formssel.cpp you restricted TEMP usage only to instruction > >> with match rule, why? What about effect()?: > >> + bool InstructForm::has_temps() { > >> + if (_matrule) { > > > >TEMP isn't allowed for instructions which don't have match rules. The > >reason is that if an instruct doesn't have a match rule the only way > >it can be constructed is by an expand rule. expand rules look like > >explicit invocations of encodings but TEMPs are synthetic so you can't > >properly write an expand rule to work with TEMP. I mean you could > >make it work but I decided not to support it. I'll make this more > >explicit. > > So I am not sure that just removing the assert will be enough. Please, > verify. > > Regards, > Vladimir > > On 4/15/15 6:08 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I have a tiny fix that allows nodes that use TEMP inputs / TEMP effect in >> expand rules. >> >> Currently an assertion fires if you do so. >> This is harmless, though, as the TEMP node is added in the Expand() of the used node, >> which is called by the Expand() of the node being expanded. >> Probably the assertion was meant for the node being expanded. >> >> The change simply removed the assertion. >> >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8077843-adlcTEMP/webrev.01/ >> >> I need this feature for a change I intend to do in the ppc.ad file. >> >> Best regards, >> Goetz. >> From serguei.spitsyn at oracle.com Fri Apr 17 20:04:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Apr 2015 13:04:54 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <552FEAE9.6020103@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <552FEAE9.6020103@oracle.com> Message-ID: <55316766.6080901@oracle.com> On 4/16/15 10:01 AM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ > > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/classfile/javaClasses.cpp > No comments. > > src/share/vm/oops/cpCache.hpp > No comments. > > src/share/vm/oops/cpCache.cpp > No comments. > > src/share/vm/prims/methodHandles.hpp > No comments. > > src/share/vm/prims/methodHandles.cpp > Now we get to the meat of the change. :-) > > Instead of the double iteration loop in the old code, you > are now taking advantage of the recent 'orig_method_idnum()' > work. So you are not only reducing the iteration count, you > are also reducing the number of adjustment calls that need > to be made. Cool. Thanks! > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. > > > Thumbs up. Thanks for the review! > > Do you happen to have any info on perf improvements for this > fix? No big deal if you don't. I do not have any info on perf improvements for this fix. The plan is to ask EM team to check if they still have any scalability issues after both fixes and see what are the improvements. They report that class retransformations in the EM take tens of minutes. Thanks, Serguei > > Dan > > > On 4/10/15 2:29 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen and Dan, >> >> This is the second class redefinition scalability/optimization fix >> that is in my queue to push into 9 and 8u60. >> >> The approach is similar to the first one but much smaller. >> For convenience, these are the links to the first scalability fix: >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> >> Please, let me know if you have any chance to review this. >> This is the last one that is waiting for your attention! :) >> >> Thanks, >> Serguei >> >> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>> >>> >>> Open hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>> >>> >>> >>> Summary: >>> >>> This is the 2-nd round of performance/calability fixes in class >>> redefinition. >>> This time, the two remaining issues that were left alone in the >>> first round fix: >>> - optimized ConstantPoolCache::adjust_method_entries() is used >>> for previous versions >>> - the MemberNameTable::adjust_method_entries() has been >>> optimized too >>> - some cleanup >>> >>> >>> Testing: >>> In progress: nsk redefine classes tests, JTREG >>> java/lang/instrument, com/sun/jdi >>> >>> >>> Thanks, >>> Serguei >>> >> > From eric.mccorkle at oracle.com Fri Apr 17 20:16:27 2015 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 17 Apr 2015 16:16:27 -0400 Subject: Review Request for JDK-8078112: Integrate Selection/Resolution test suite into jtreg tests Message-ID: <55316A1B.5040506@oracle.com> Hello, Please review this patch, which integrates a portion of the selection/resolution test suite into the JTreg test suite. This will integrate the tests in such a way that they are run on every integration. This test suite uses a template-based generation scheme to exercise all aspects of the updated selection/resolution test suite from JVMS 8. It runs a very large number of tests, representing a very wide variety of cases. Extensive javadoc comments are found throughout the test code which describe the suite's functioning in more detail. Note that the tests for abstract method error have been held back for further development. Also note that this suite as already undergone extensive review as part of the development process. The JBS issue is here: https://bugs.openjdk.java.net/browse/JDK-8078112 The webrev is here: http://cr.openjdk.java.net/~emc/8078112/ From kirk at kodewerk.com Fri Apr 17 20:34:16 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 17 Apr 2015 22:34:16 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: References: <5530B711.2070009@oracle.com> <5530FE35.3010107@oracle.com> Message-ID: <3C32C2F5-68F1-4B55-80FD-C62D98A6A996@kodewerk.com> Hi All, I?m very happy for a digital solution. As for solving problems in JFR.. great but that is a commercial solution and thus doesn?t work for OpenJDK. Remember? Plus, with all due respect for JFR, not all of us agree that this is the best way to sort out performance issues ;-) Regards, Kirk On Apr 17, 2015, at 3:16 PM, Mattis Castegren wrote: > I guess it would be a possible later enhancement request to add a new logging tag ?gc_compressed? for example that prints gc output in some easy to parse format. It could be one line of comma separated values per GC for example that you could import to other tools. > > > > But I agree with Fredrik, we should look at exactly what problems you try to solve, and see if it instead can be solved in JFR. You could make a recording that only gathers GC data, and you could run it for days and still get a pretty small recording (at least smaller than what a corresponding gc log would be). If you then still feel the need to import the data to some other tool, maybe we should add that tool?s functionality to Mission Control? > > > > Kind Regards > > /Mattis > > > > From: Fredrik Arvidsson > Sent: den 17 april 2015 14:36 > To: Martijn Verburg > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers > Subject: Re: Updates to JEP-158: JVM Unified Logging are coming... > > > > Hi Martijn, and the others :) > > I'm glad you like what we do. We also think the tag based logging is something good, and that it will make the logging in the JVM easier to implement, configure and consume. > > Regarding 'binary / compressed' log format. We are not planning to add any structured log format to the unified logging framework. It is outside the scope of this JEP. The log data format is a simple string with some well defined decorations. The logs are primarily meant to be read by humans. > > There will be log output extension points in the framework, but they will not be accessible publicly and they will not support 3rd party extensions in runtime. Even if the output extension API would be made fully accessible, the data fed in to it would still only be a string, since thats what the developers are adding in the code where the logging framework is called. I guess one could add compression of log data as an extension, but I don't think that is really what you are asking for. > > As you might know, Oracle offers low latency low intrusive structured logging in its Java Flight Recorder product. We are not aiming in this JEP to overlap that functionality more than absolutely needed. > > Cheers > /Fredrik > > On 2015-04-17 12:12, Martijn Verburg wrote: > > Hi Fredrik, > > > > Thanks from us (jClarity and some other orgs) for considering the tag based system, we're really glad you've gone in this direction. One quick bit of feedback. > > > > Is it possible to add a binary / compressed logging format or an interface/ API to plug one in for high performance Logging? Human readable is nice for looking at logs immediately, but for some of our customers they'd be looking to offload that concern to another process/host. > > > > > Cheers, > Martijn > > > > On 17 April 2015 at 09:32, Fredrik Arvidsson wrote: > > Hi > > We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started. > > Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158.html" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158_Illustration.png" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase. > > More information about the sandbox repository name and other practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. > > > > From kirk at kodewerk.com Fri Apr 17 20:40:15 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 17 Apr 2015 22:40:15 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530D296.9000408@oracle.com> References: <5530B711.2070009@oracle.com> <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> <5530C0B8.5020701@oracle.com> <26421508-9c07-45e5-a109-1b148272c862@default> <5530D296.9000408@oracle.com> Message-ID: On Apr 17, 2015, at 11:29 AM, Fredrik Arvidsson wrote: > Hi > Ill try to reply in-line below. > > On 2015-04-17 10:27, Mattis Castegren wrote: >> Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc. > Of course there is a risk that people would forget to add a tag. But I can't see that this risk is very high. Logging code has to be put through code review just like any other change and we just have to pay extra attention to this in the beginning i guess. Using the hierarchical scheme there is also a risk that the logging topic is set to the wrong one. Indeed! > > There are no recommendations right now on what tags to create or use in the logging code. We will work with all groups trying to establish some guidelines I guess to have tag names consistent. My recommendation to teams has always been to give architectural guidelines or use requirements from operations to define logging. If you leave logging to dev it?s generally useful for dev and no one else. > > If we see a real need to have 'meta-tags' consisting of several other tags we could introduce something like that I'm sure, but this is just something we have discussed briefly. JMS has a spec for managing this type of behavior. > > There will also be a way to list all existing 'tag combinations' used in the code in runtime. This could maybe be used to spot the ones that are potentially wrong? >> If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like >> >> log ("gc,g1,g1_init", ...) >> >> If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..." > Yes, this would be the way to handle missed tags in the code. I can't see that there is another way really :( Make them manageable so if you forget on the command line you can change them on the fly. Regards, Kirk From mikael.vidstedt at oracle.com Fri Apr 17 23:47:59 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 17 Apr 2015 16:47:59 -0700 Subject: RFR(S): 8078017: Introduce hotspot_basicvmtest In-Reply-To: <55308AD8.1090506@oracle.com> References: <55304BBC.7080907@oracle.com> <55308AD8.1090506@oracle.com> Message-ID: <55319BAF.3030001@oracle.com> David/Vladimir - thanks for the reviews! Cheers, Mikael On 2015-04-16 21:23, David Holmes wrote: > On 17/04/2015 9:54 AM, Mikael Vidstedt wrote: >> >> Please review this change which introduces a new test target called >> hotspot_basicvmtest. The new test target runs the union of the >> hotspot_client, hotspot_minimal and hotspot_server test targets. The >> change also updates JPRT to use the new target instead of the old ones. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8078017 >> Webrev (top repo): >> http://cr.openjdk.java.net/~mikael/webrevs/8078017/webrev.00/hotspot/webrev/ >> >> >> Webrev (hotspot repo): >> http://cr.openjdk.java.net/~mikael/webrevs/8078017/webrev.00/top/webrev/ > > Your hotspot and top descriptors are swapped around :) > > Otherwise "looks" "good" enough ;-) > > Cheers, > David > >> Motivation: >> >> Running all the three vm option tests as a single test target reduces >> the per-test setup cost while still providing the same test coverage. >> >> Description: >> >> Most of the changes are mechanical changes to the jprt.properties file >> to use the new makefile target. The new test target is implemented in >> the hotspot/test/Makefile. It discovers which jvm variants (client, >> minimal and/or server) are available by looking for the corresponding >> directories in the JDK under test. The exact directory within JDK where >> the JVM directories reside differ between the different platforms, but >> they all follow the same general pattern. >> >> Tested locally and in JPRT. >> >> Cheers, >> Mikael >> From thomas.stuefe at gmail.com Sat Apr 18 18:02:45 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 18 Apr 2015 20:02:45 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530B711.2070009@oracle.com> References: <5530B711.2070009@oracle.com> Message-ID: Hi Frederik, I like this proposal a lot, especially the abandonment of a hierarchical structure in favor of tags. In the SAPJVM we have a tracing system in many details similar to the one proposed here. We will be probably abandon it and switch to the official logging system once it is implemented in the OpenJDK. Some questions/remarks: 1 Will logging be available from native JDK code too, not only from within the hotspot? 2 Will there a way to cover early logging? One common problem is logging during initialization time of the VM, and there is always the problem whether logging system is already initialized ("I don't see my trace - did I just not hit it or was logging not up yet?"). Would be very nice if this problem were covered, e.g. by capturing output in-memory and writing it out delayed once logging subsystem is up. 3 A similar problem is that logging should use as little VM infrastructure as possible, to make it possible to use it from all VM code. If you agree with (2) and (3), it may make sense to add some explicit requirements to the JEP. 4 "Stretch Goal: Ability to configure in which order decorations should be printed" In our tracing system we also have decorations, and we even added a feature to give the user the ability to format it itself, by adding a format-string like feature (-XtraceFormat="blabla @PID @TID @USER"). This looked like a neat idea, but we found in practice over the years that this feature was very rarely used. So maybe this stretch goal is not needed. 5 Would be nice to have short alternative names for the decorators, maybe even single letters 6 "The different log levels should have guidelines that define the expected performance overhead for the level. " It also may make sense to add guide lines for the expected verbosity of log levels, either in terms of datasize/time or messages/time. I look forward to this logging system in practice! Kind Regards, Thomas On Fri, Apr 17, 2015 at 9:32 AM, Fredrik Arvidsson < fredrik.arvidsson at oracle.com> wrote: > Hi > > We are planning to release an updated version of JEP-158 very soon. The > work to update this JEP has been going on for some time and we now feel we > are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The > requirements for the API and implementation were heavily influenced by the > logging functionality in JRockit JVM. The JEP was updated and refined in > mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the > chosen API and functionality but the conclusion was that the proposal would > work, and the JEP was targeted for JDK 9 and the implementation work was > started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of the JEP, > this time with greater force. At this point we decided to take a time-out > and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout to > something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found > that some logging can't easily be ordered under a single hierarchical > subject but can belong to multiple subjects/areas. One example of this is > logging in the 'metaspace' code. The functionality in the 'metaspace area' > can be called from both GC and Runtime code. Another example is > class-unloading. There are more examples on this of course, but these two > we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much > from the earlier proposal. We have tried to make it leaner and not as > verbose (functionality wise) as before. The scope of the implementation has > been narrowed down some to enable us to deliver good value as soon as > possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal > we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. > This enables us who are implementing it to work in an efficient way and at > the same time it allows any interested party to try out and follow the work > during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. > From david.holmes at oracle.com Mon Apr 20 03:03:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Apr 2015 13:03:46 +1000 Subject: Review Request for JDK-8078112: Integrate Selection/Resolution test suite into jtreg tests In-Reply-To: <55316A1B.5040506@oracle.com> References: <55316A1B.5040506@oracle.com> Message-ID: <55346C92.4070602@oracle.com> Hi Eric, On 18/04/2015 6:16 AM, Eric McCorkle wrote: > Hello, > > Please review this patch, which integrates a portion of the > selection/resolution test suite into the JTreg test suite. This will > integrate the tests in such a way that they are run on every integration. Not sure what you mean by that last part. You've excluded the new tests from the hotspot_runtime group, so they will only be executed if requested. > This test suite uses a template-based generation scheme to exercise all > aspects of the updated selection/resolution test suite from JVMS 8. It > runs a very large number of tests, representing a very wide variety of > cases. Extensive javadoc comments are found throughout the test code > which describe the suite's functioning in more detail. How long do these tests take to run in general? Thanks, David > Note that the tests for abstract method error have been held back for > further development. > > Also note that this suite as already undergone extensive review as part > of the development process. > > The JBS issue is here: > https://bugs.openjdk.java.net/browse/JDK-8078112 > > The webrev is here: > http://cr.openjdk.java.net/~emc/8078112/ > From goetz.lindenmaier at sap.com Mon Apr 20 06:39:21 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Apr 2015 06:39:21 +0000 Subject: RFR(S): 8077843: adlc: allow nodes that use TEMP inputs in expand rules. In-Reply-To: <55315B3F.9020708@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBEEE0@DEWDFEMB12A.global.corp.sap> <55305389.5020600@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF52B@DEWDFEMB12A.global.corp.sap> <55315B3F.9020708@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBFAA2@DEWDFEMB12A.global.corp.sap> Thanks a lot! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Freitag, 17. April 2015 21:13 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8077843: adlc: allow nodes that use TEMP inputs in expand rules. Okay. I see. Looks good then. I will push it. Thanks, Vladimir On 4/17/15 12:25 AM, Lindenmaier, Goetz wrote: > HI Vladimir, > > the node generated in the Expand has a match rule itself. > I checked, all the TEMPs we use are in nodes with match rules. > Anyways, you get a syntax error if not: > "Syntax Error: : TEMPs without match rule isn't supported" > > We use nodes with match rules in expands a lot, as the match rule > is required for a lot of things. For example to generate the proper > ideal opcode, get it in the array must_clone etc. > If we don't want the nodes to be matched, we add predicate(false). > In our internal VM, we use nodes with TEMPs in expands on ia64 a lot. > > For the code generated for the nodes I intend to contribute, see > below. > > Best regards, > Goetz. > > > // Card-mark for CMS garbage collection. > // This cardmark does an optimization so that it must not always > // do a releasing store. For this, it gets the address of > // CMSCollectorCardTableModRefBSExt::_requires_release as input. > // (Using releaseFieldAddr in the match rule is a hack.) > instruct storeCM_CMS(memory mem, iRegLdst releaseFieldAddr, flagsReg crx) %{ > match(Set mem (StoreCM mem releaseFieldAddr)); > effect(TEMP crx); > predicate(false); > ins_cost(MEMORY_REF_COST); > > // See loadConP. > ins_cannot_rematerialize(true); > > format %{ "STB #0, $mem \t// CMS card-mark byte (must be 0!), checking requires_release in [$releaseFieldAddr]" %} > ins_encode( enc_cms_card_mark(mem, releaseFieldAddr, crx) ); > ins_pipe(pipe_class_memory); > %} > > // Card-mark for CMS garbage collection. > // This cardmark does an optimization so that it must not always > // do a releasing store. For this, it needs the constant address of > // CMSCollectorCardTableModRefBSExt::_requires_release. > // This constant address is split off here by expand so we can use > // adlc / matcher functionality to load it from the constant section. > instruct storeCM_CMS_ExEx(memory mem, immI_0 zero) %{ > match(Set mem (StoreCM mem zero)); > predicate(UseConcMarkSweepGC); > > expand %{ > immL baseImm %{ 0 /* TODO: PPC port (jlong)CMSCollectorCardTableModRefBSExt::requires_release_address() */ %} > iRegLdst releaseFieldAddress; > flagsReg crx; > loadConL_Ex(releaseFieldAddress, baseImm); > storeCM_CMS(mem, releaseFieldAddress, crx); > %} > %} > > > MachNode* storeCM_CMSNode::Expand(State* state, Node_List& proj_list, Node* mem) { > Compile* C = Compile::current(); > // Add projection edges for additional defs or kills > // TEMP crx > MachTempNode *def; > def = new MachTempNode(state->MachOperGenerator(FLAGSREG)); > add_req(def); > > return this; > } > > MachNode* storeCM_CMS_ExExNode::Expand(State* state, Node_List& proj_list, Node* mem) { > Compile* C = Compile::current(); > MachOper *op0 = new immLOper( > #line 6571 "/sapmnt/home1/d045726/oJ/8077838-ppc-hs-comp/src/cpu/ppc/vm/ppc.ad" > 0 /* TODO: PPC port (jlong)CMSCollectorCardTableModRefBSExt::requires_release_address() */ > #line 527 "../generated/adfiles/ad_ppc_64_expand.cpp" > ); > MachOper *op1 = new iRegLdstOper(); > MachOper *op2 = new flagsRegOper(); > MachNode *tmp0 = this; > MachNode *tmp1 = this; > MachNode *tmp2 = this; > MachNode *tmp3 = NULL; > MachNode *tmp4 = NULL; > MachNode *tmp5 = NULL; > unsigned num0 = 0; > unsigned num1 = opnd_array(1)->num_edges(); > unsigned num2 = opnd_array(2)->num_edges(); > unsigned idx0 = oper_input_base(); > if (mem == (Node*)1) { > idx0--; // Adjust base because memory edge hasn't been inserted yet > } > unsigned idx1 = idx0 + num0; > unsigned idx2 = idx1 + num1; > unsigned idx3 = idx2 + num2; > MachNode *result = NULL; > > loadConL_ExNode *n0 = new loadConL_ExNode(); > n0->add_req(_in[0]); > ((MachTypeNode*)n0)->_bottom_type = bottom_type(); > n0->set_opnd_array(0, state->MachOperGenerator(IREGLDST)); > tmp4 = n0; > n0->set_opnd_array(1, op0->clone()); // baseImm > if(tmp3 != NULL) > n0->add_req(tmp3); > result = n0->Expand( state, proj_list, mem ); > > storeCM_CMSNode *n1 = new storeCM_CMSNode(); > n1->add_req(_in[0]); > ((MachTypeNode*)n1)->_bottom_type = bottom_type(); > n1->set_opnd_array(0, state->MachOperGenerator(UNIVERSE)); > if (mem != (Node*)1) { > n1->add_req(_in[1]); // Add memory edge > } > n1->set_opnd_array(1, opnd_array(1)->clone()); // mem > if(tmp1 == this) { > for(unsigned i = 0; i < num1; i++) { > n1->add_req(_in[i + idx1]); > } > } > else n1->add_req(tmp1); > tmp1 = n1; > n1->set_opnd_array(2, op1->clone()); // releaseFieldAddress > if(tmp4 != NULL) > n1->add_req(tmp4); > n1->set_opnd_array(3, op2->clone()); // crx > if(tmp5 != NULL) > n1->add_req(tmp5); > result = n1->Expand( state, proj_list, mem ); > > > return result; > } > > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Freitag, 17. April 2015 02:28 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8077843: adlc: allow nodes that use TEMP inputs in expand rules. > > Here is what Tom R said during review of TEMP implementation: > > >> 3. In formssel.cpp you restricted TEMP usage only to instruction > >> with match rule, why? What about effect()?: > >> + bool InstructForm::has_temps() { > >> + if (_matrule) { > > > >TEMP isn't allowed for instructions which don't have match rules. The > >reason is that if an instruct doesn't have a match rule the only way > >it can be constructed is by an expand rule. expand rules look like > >explicit invocations of encodings but TEMPs are synthetic so you can't > >properly write an expand rule to work with TEMP. I mean you could > >make it work but I decided not to support it. I'll make this more > >explicit. > > So I am not sure that just removing the assert will be enough. Please, > verify. > > Regards, > Vladimir > > On 4/15/15 6:08 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I have a tiny fix that allows nodes that use TEMP inputs / TEMP effect in >> expand rules. >> >> Currently an assertion fires if you do so. >> This is harmless, though, as the TEMP node is added in the Expand() of the used node, >> which is called by the Expand() of the node being expanded. >> Probably the assertion was meant for the node being expanded. >> >> The change simply removed the assertion. >> >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8077843-adlcTEMP/webrev.01/ >> >> I need this feature for a change I intend to do in the ppc.ad file. >> >> Best regards, >> Goetz. >> From thomas.stuefe at gmail.com Mon Apr 20 08:58:05 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 20 Apr 2015 10:58:05 +0200 Subject: RFR(xs): 8076475: Misuses of strncpy/strncat In-Reply-To: References: <552521AF.3060302@oracle.com> <55278DE9.5000600@oracle.com> <55279C36.2000004@oracle.com> Message-ID: Hi, could I have an additional reviewer, please? current webrev is: http://cr.openjdk.java.net/~stuefe/webrevs/8076475/webrev.01/webrev/ Thank you! ..Thomas On Fri, Apr 10, 2015 at 1:25 PM, Thomas St?fe wrote: > .. adding hotspot-dev to attract another reviewer. > > On Fri, Apr 10, 2015 at 11:47 AM, Dmitry Samersoff < > dmitry.samersoff at oracle.com> wrote: > >> Thomas, >> >> I can sponsor the push, but you need an official reviewer. >> >> -Dmitry >> >> On 2015-04-10 12:31, Thomas St?fe wrote: >> > Dmitry, Thanks for the review! >> > >> > Still need a second review and also a sponsor. >> > >> > .. Thomas >> > >> > On Apr 10, 2015 10:46 AM, "Dmitry Samersoff" >> > > >> wrote: >> > >> > Thomas, >> > >> > Looks good for me! >> > >> > Thank you for doing it. >> > >> > -Dmitry >> > >> > On 2015-04-10 10:50, Thomas St?fe wrote: >> > > Hi Dimitry, >> > > >> > > see new version here: >> > > >> > > >> http://cr.openjdk.java.net/~stuefe/webrevs/8076475/webrev.01/webrev/ >> > > >> > > >> > > On Wed, Apr 8, 2015 at 2:40 PM, Dmitry Samersoff >> > > >> > > > >> wrote: >> > > >> > > Thomas, >> > > >> > > ** agent/src/os/bsd/libproc_impl.c >> > > ** agent/src/os/linux/libproc_impl.c >> > > >> > > newlib->name has the size of (PATH_MAX + NAME_MAX + 1) >> > > >> > > see ./src/os/bsd/libproc_impl.h:92 >> > > >> > > So no truncation is actually possible here. >> > > >> > > To make this code nice-looking it's better to add: >> > > >> > > if (strlen(libname) > sizeof(newlib->name)) { >> > > // Bail out with debug message >> > > ... >> > > } >> > > strcpy(newlib->name, libname); >> > > >> > > rather than use snprintf here. >> > > >> > > >> > > I changed the coding according to your suggestions. >> > > >> > > There is still the strlen vs strnlen question Kim mentioned, but >> > we use >> > > strlen all over the place, and I am not sure if all platforms >> > support it >> > > (AIX was known to have a broken strnlen implementation, one would >> need >> > > to check that first before changing strlen to strnlen) >> > > >> > > >> > > ** arguments.cpp:3466 >> > > >> > > It might be better to use snprintf here. >> > > >> > > >> > > Agree, done >> > > >> > > >> > > ** arguments.cpp:3629 >> > > >> > > It's better to just replace strncat/strncpy to strcat/strcpy >> > > in the original code - as soon as we allocating memory with >> > respect to >> > > variable lenght, we don't need to check this length again. >> > > >> > > >> > > Sorry, I disagree here - I think using snprintf makes the code >> more >> > > readable. It comes down to a matter of taste, so lets see what >> > others think. >> > > >> > > >> > > >> > > ** vmError.cpp:222 >> > > >> > > It's better to keep original code. >> > > >> > > >> > > Agree, done >> > > >> > > Best Regards, Thomas >> > > >> > > >> > > >> > > Other changes looks good for me! >> > > -Dmitry >> > > >> > > >> > > On 2015-04-08 11:09, Thomas St?fe wrote: >> > > > Hi, >> > > > >> > > > please review these small fixes around use of >> strncpy/strncat. >> > > > >> > > > Bug report: >> https://bugs.openjdk.java.net/browse/JDK-8076475 >> > > > Webrev: >> > > > >> > >> http://cr.openjdk.java.net/~stuefe/webrevs/8076475/webrev.00/webrev/ >> > > > >> > > > Changes in detail are: >> > > > >> > > > agent/src/os/bsd/libproc_impl.c >> > > > agent/src/os/linux/libproc_impl.c: >> > > > - missing \0 on truncation. Replaced with >> > > snprintf, add >> > > > truncation handling >> > > > >> > > > src/os/bsd/dtrace/libjvm_db.c >> > > > src/os/solaris/dtrace/libjvm_db.c >> > > > @@ -580,17 +580,18 @@ >> > > > - overwrite on truncation >> > > > @@ -1093,13 +1094,13 @@ >> > > > - overwrite on truncation >> > > > >> > > > src/share/vm/compiler/compileBroker.hpp >> > > > - missing \0 on truncation. >> > > > >> > > > src/share/tools/hsdis/hsdis.c >> > > > - missing \0 >> > > > >> > > > src/os/bsd/vm/decoder_machO.cpp >> > > > - missing \0 on truncation. >> > > > >> > > > src/share/vm/compiler/compilerOracle.cpp >> > > > - Replaced with jio_snprintf, less awkward >> and >> > > does not >> > > > restrict each part to 255 chars each. >> > > > >> > > > src/share/vm/compiler/disassembler.cpp >> > > > - missing \0 on truncation. >> > > > >> > > > src/share/vm/runtime/arguments.cpp >> > > > @@ -2703,11 +2703,11 @@ >> > > > - replaced with strdup, easier to read >> > > > @@ -3294,12 +3294,11 @@ >> > > > - the same >> > > > @@ -3627,18 +3626,14 @@ >> > > > - replace strncpy/strncat sequence with >> > jio_snprintf - >> > > > easier to read. >> > > > - replace malloc/strncpy with os::strdup >> > > > >> > > > src/share/vm/utilities/ostream.cpp >> > > > - avoid \0 padding >> > > > >> > > > src/share/vm/utilities/vmError.cp >> > > > @@ -219,7 +219,7 @@ >> > > > - avoid \0 padding >> > > > @@ -463,14 +463,7 @@ >> > > > - simplified >> > > > >> > > > Kind regards, Thomas >> > > > >> > > >> > > >> > > -- >> > > Dmitry Samersoff >> > > Oracle Java development team, Saint Petersburg, Russia >> > > * I would love to change the world, but they won't give me the >> > sources. >> > > >> > > >> > >> > >> > -- >> > Dmitry Samersoff >> > Oracle Java development team, Saint Petersburg, Russia >> > * I would love to change the world, but they won't give me the >> sources. >> > >> >> >> -- >> 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 adinn at redhat.com Mon Apr 20 09:03:40 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 20 Apr 2015 10:03:40 +0100 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr Message-ID: <5534C0EC.1070005@redhat.com> The following webrev is submitted for review (n.b. I am not an OpenJDK committer so the patch does not yet have an associated JIRA). http://cr.openjdk.java.net/~adinn/volatilefix/webrev.00 The patch modifies the AArch64 ad file rules to implement volatile loads and stores using load acquire (ldar) and store release (stlr) instructions. The memory barriers normally associated with volatile loads and stores are elided in these cases. http://cr.openjdk.java.net/~adinn/volatilefix/webrev.00/ Just to summarise what is happening here: The patch employs rule predicates to detect specific sequences of membar and memory nodes which are unique to volatile loads and stores. Two predicates control generation of normal vs acquiring loads and normal vs releasing stores. Three predicates control generation vs elision of memory barriers. The comments documenting these predicates provides a full explanation of which node sequences may arise as a result of a volatile load or store, how they can be detected and what alternative instruction encodings may be generated. The patch has successfully passed jcstress on two different AArch64 platforms. It has also successfully run javac and netbeans. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From zoltan.majo at oracle.com Mon Apr 20 13:40:08 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 20 Apr 2015 15:40:08 +0200 Subject: [8u60] Request for approval: Backport of 8067648(S) Message-ID: <553501B8.6010109@oracle.com> Hi, I would like to request the backport of the fix for JDK-8067648 to 8u60. Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8067648 Original changeset: http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/445debb5c61d Unfortunately, the fix does not apply cleanly because the patched file's location is different in 9 and 8u: location in 9: jdk/src/java.base/share/classes/com/sun/crypto/provider/GCTR.java location in 8u: jdk/src/share/classes/com/sun/crypto/provider/GCTR.java Webrev: http://cr.openjdk.java.net/~zmajo/8067648-8u/webrev.00/ Testing: All JPRT tests pass. The fix was pushed last week into 9 and passes two nightly runs. Thank you and best regards, Zoltan From mikael.gerdin at oracle.com Mon Apr 20 14:45:21 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 20 Apr 2015 16:45:21 +0200 Subject: 8065585: Change ShouldNotReachHere() to never return In-Reply-To: <553120C8.8030108@oracle.com> References: <552E421C.1010105@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBEF60@DEWDFEMB12A.global.corp.sap> <552F1D05.40209@oracle.com> <552FA5FF.7070702@oracle.com> <552FAC28.2060407@oracle.com> <552FB9F0.1030401@oracle.com> <5530F339.7070004@oracle.com> <553101F1.4010500@oracle.com> <55311EDA.6090205@oracle.com> <553120C8.8030108@oracle.com> Message-ID: <55351101.7030304@oracle.com> On 2015-04-17 17:03, Stefan Karlsson wrote: > On 2015-04-17 16:55, Mikael Gerdin wrote: >> On 2015-04-17 14:52, Stefan Karlsson wrote: >>> >>> >>> On 2015-04-17 13:49, Mikael Gerdin wrote: >>>> On 2015-04-16 15:32, Stefan Karlsson wrote: >>>>> On 2015-04-16 14:33, David Holmes wrote: >>>>>> Hi Stefan, >>>>>> >>>>>> trimming ... >>>>>> >>>>>> On 16/04/2015 10:07 PM, Stefan Karlsson wrote: >>>>>>> On 2015-04-16 04:23, David Holmes wrote: >>>>>>>> Second, more important question: have you examined how this >>>>>>>> attribute >>>>>>>> affects the ability to walk the stack? We have already seen >>>>>>>> issues on >>>>>>>> some platforms where library functions, like abort(), have the >>>>>>>> noreturn attribute and as a result the call is optimized in a way >>>>>>>> that >>>>>>>> prevents the stack from being walked - see eg: >>>>>>>> >>>>>>>> https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> though this: >>>>>>>> >>>>>>>> https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 >>>>>>>> >>>>>>>> suggests that problem may have been addressed by the libc folk. >>>>>>>> But it >>>>>>>> still raises the question as to how our own noreturn functions >>>>>>>> will be >>>>>>>> handled and how they will affect stacktrace generation in hs_err >>>>>>>> logs >>>>>>>> or via gdb. >>>>>>> >>>>>>> I added a call to fatal(...) in the GC code. I get correct >>>>>>> stacktraces >>>>>>> in gdb, but the stacktraces in the hs_err files are broken with >>>>>>> fastdebug and product builds: >>>>>> >>>>>> Which platforms? >>>>> >>>>> On Linux x86 and x86_64. >>>>> >>>>>> >>>>>>> Stack: [0x00007f12518d2000,0x00007f12519d3000], >>>>>>> sp=0x00007f12519d0eb0, >>>>>>> free space=1019k >>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>>>> C=native code) >>>>>>> V [libjvm.so+0x11db44a] VMError::report_and_die()+0x1ba >>>>>>> V [libjvm.so+0x7efb80] report_vm_error(char const*, int, char >>>>>>> const*, >>>>>>> char const*)+0x90 >>>>>>> V [libjvm.so+0x7efc49] report_vm_error_noreturn(char const*, int, >>>>>>> char >>>>>>> const*, char const*)+0x9 >>>>>>> V [libjvm.so+0x7efc63] >>>>>>> V [libjvm.so+0xfd7937] >>>>>>> V [libjvm.so+0xfeec51] >>>>>>> ... >>>>>> >>>>>> So what is the plan: try to get hs_err working again? Or file this >>>>>> under "well it seemed like a good idea"? ;-) >>>>> >>>>> I'm leaning towards "seemed like a good idea", unless someone has an >>>>> easy fix for these problems. >>>> >>>> I've been looking a bit at this. It's not the stack trace per se that >>>> is broken, but the decoding of the function names is not working for >>>> some of the callers of the noreturn functions. >>>> >>>> I tried this with report_fatal using -XX:ErrorHandlerTest=5 and got >>>> the following: >>>> >>>> 0x7fb71ccd98d0 : push %rbp >>>> 0x7fb71ccd98d1 : mov %rdx,%rcx >>>> 0x7fb71ccd98d4 : lea 0x9b4b34(%rip),%rdx >>>> 0x7fb71ccd98db : mov %rsp,%rbp >>>> 0x7fb71ccd98de : callq 0x7fb71ccd98c0 >>>> 0x7fb71ccd98e3: data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) >>>> >>>> So the report_fatal frame has ...98e3 as its return address, but that >>>> is actually outside the function and this causes dladdr() to return >>>> NULL in dli_saddr and dli_sname. >>>> >>>> The JVM then attempts to decode using Decoder::decode but I wasn't >>>> able to follow that code to understand why that fails. >>>> >>>> The same appears to happen for the caller of report_fatal >>>> (controlled_crash in my case) but there I can't explain why dladdr >>>> returns NULL values there. >>>> >>>> After these two functions the rest of the stack trace appears to be >>>> correctly decoded. >>>> >>>> One approach could be to attempt to inject a "nop" at the end of >>>> functions which call a "noreturn" function. This would hopefully make >>>> the instruction after the call to the noreturn function part of the >>>> caller and would make symbol decoding work. >>> >>> I found this mail thread: >>> https://sourceware.org/bugzilla/show_bug.cgi?id=6522 >>> >>> which blames the -fcross-jumping optimization. >>> >>> I recompiled hotspot with OPT_CFLAGS/debug.o=-fno-crossjumping, and now >>> I get correct stack traces with fastdebug on Linux 64 bits. >> >> I did a more thorough investigation into this on a slowdebug build, >> and the reason for the symbols missing appears to be that after the >> JVM's ELF Decoder runs into an un-decodeable symbol because a return >> PC points to a nop in-between two symbols (because it's just called a >> noreturn function) the Decoder sets m_status to FileInvalid and >> refuses to decode any more symbols. >> If I comment out the code to set the fail status I get a fairly normal >> hs err stacktrace: >> >> V [libjvm.so+0xf184c8] VMError::report(outputStream*)+0x133c >> V [libjvm.so+0xf19865] VMError::report_and_die()+0x411 >> V [libjvm.so+0x7876de] report_vm_error(char const*, int, char >> const*, char const*)+0xba >> V [libjvm.so+0x7877d7] report_vm_error_noreturn(char const*, int, >> char const*, char const*)+0x3d >> V [libjvm.so+0x78781b] report_should_not_call(char const*, int)+0x0 >> V [libjvm.so+0x92bfeb] >> V [libjvm.so+0x6e10ff] GenCollectorPolicy::mem_allocate_work(unsigned >> long, bool, bool*)+0x283 >> V [libjvm.so+0x92c049] GenCollectedHeap::mem_allocate(unsigned long, >> bool*)+0x5d >> V [libjvm.so+0x45dbe5] >> CollectedHeap::common_mem_allocate_noinit(KlassHandle, unsigned long, >> Thread*)+0x103 >> V [libjvm.so+0x45dda2] >> CollectedHeap::common_mem_allocate_init(KlassHandle, unsigned long, >> Thread*)+0x4e >> V [libjvm.so+0x45e034] CollectedHeap::array_allocate(KlassHandle, >> int, int, Thread*)+0xac >> V [libjvm.so+0xed2f04] TypeArrayKlass::allocate_common(int, bool, >> Thread*)+0xf0 >> V [libjvm.so+0x44ae3e] TypeArrayKlass::allocate(int, Thread*)+0x3e >> V [libjvm.so+0xcef2d5] oopFactory::new_typeArray(BasicType, int, >> Thread*)+0x55 >> V [libjvm.so+0x9c5aa9] InterpreterRuntime::newarray(JavaThread*, >> BasicType, int)+0x147 >> j alloc.AllocArrays.main([Ljava/lang/String;)V+237 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x9df121] JavaCalls::call_helper(JavaValue*, >> methodHandle*, JavaCallArguments*, Thread*)+0x6b1 >> V [libjvm.so+0xd091d7] os::os_exception_wrapper(void (*)(JavaValue*, >> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >> methodHandle*, JavaCallArguments*, Thread*)+0x41 >> V [libjvm.so+0x9dea5a] JavaCalls::call(JavaValue*, methodHandle, >> JavaCallArguments*, Thread*)+0x86 >> V [libjvm.so+0xa42306] jni_invoke_static(JNIEnv_*, JavaValue*, >> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x200 >> V [libjvm.so+0xa5964a] jni_CallStaticVoidMethod+0x353 >> C [libjli.so+0x86ed] JavaMain+0x93c >> C [libpthread.so.0+0x80a5] start_thread+0xc5 >> >> One problem is the line >> V [libjvm.so+0x78781b] report_should_not_call(char const*, int)+0x0 >> I actually added a call to fatal(), but since fatal calls a noreturn >> function the return pc of that frame accidentally points to the first >> instruction in the next function, which happens to be >> report_should_not_call. >> >> I wonder if this could be fixed by forcing gcc to empit a nop after >> the call to report_vm_error_noreturn in report_fatal and friends. >> __asm__ __volatile__ ("nop" : : :); >> appears to not be enough. GCC is very aggressive with noreturn, even >> with -O0. > > And the reason why m_status was set to FileInvalid seems to be the bug > in ElfSymbolTable::lookup, which returns true instead of false if it > fails to find a symbol!: > > bool ElfSymbolTable::lookup(address addr, int* stringtableIndex, int* > posIndex, int* offset, ElfFuncDescTable* funcDescTable) { > ... > return true; > } > > The caller will then think that the symbol was found and use the > uninitialized output parameters. Excellent! I've messed around a bit to try to work around the correctness problem of the stack trace and I think I have a solution: By inlining the call to noreturn_function in the macros wrapping report_* the return PC of the calling frame will never point into space between functions at the point of the stack walk operation. The return PC will instead almost always point to a call to noreturn_function, which will always be a part of the correct callee function. Webrev (incremental on Stefan's changes): http://cr.openjdk.java.net/~mgerdin/8065585/webrev.incr/ Full webrev (for completeness): http://cr.openjdk.java.net/~mgerdin/8065585/webrev.full/ I've manually verified that a call to fatal() at nontrivial stack depth will generate a correct stack trace on all Oracle supported platforms. /Mikael > > StefanK > >> >> /Mikael >> >>> >>> StefanK >>>> >>>> /Mikael >>>> >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> StefanK >>>>>>>>> >>>>>>> >>>>> >>>> >>> > From eric.mccorkle at oracle.com Mon Apr 20 16:22:25 2015 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 20 Apr 2015 12:22:25 -0400 Subject: Review Request for JDK-8078112: Integrate Selection/Resolution test suite into jtreg tests In-Reply-To: <55346C92.4070602@oracle.com> References: <55316A1B.5040506@oracle.com> <55346C92.4070602@oracle.com> Message-ID: <553527C1.4080509@oracle.com> On 04/19/2015 11:03 PM, David Holmes wrote: > Hi Eric, > > On 18/04/2015 6:16 AM, Eric McCorkle wrote: >> Hello, >> >> Please review this patch, which integrates a portion of the >> selection/resolution test suite into the JTreg test suite. This will >> integrate the tests in such a way that they are run on every integration. > > Not sure what you mean by that last part. You've excluded the new tests > from the hotspot_runtime group, so they will only be executed if requested. If that's the case, I'll need to fix the files. >> This test suite uses a template-based generation scheme to exercise all >> aspects of the updated selection/resolution test suite from JVMS 8. It >> runs a very large number of tests, representing a very wide variety of >> cases. Extensive javadoc comments are found throughout the test code >> which describe the suite's functioning in more detail. > > How long do these tests take to run in general? About 2-3 minutes total on a laptop. From vladimir.kozlov at oracle.com Mon Apr 20 17:55:35 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Apr 2015 10:55:35 -0700 Subject: [8u60] Request for approval: Backport of 8067648(S) In-Reply-To: <553501B8.6010109@oracle.com> References: <553501B8.6010109@oracle.com> Message-ID: <55353D97.5090304@oracle.com> Looks good. Thanks, Vladimir On 4/20/15 6:40 AM, Zolt?n Maj? wrote: > Hi, > > > I would like to request the backport of the fix for JDK-8067648 to 8u60. > > Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8067648 > Original changeset: http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/445debb5c61d > > Unfortunately, the fix does not apply cleanly because the patched file's location is different in 9 and 8u: > > location in 9: jdk/src/java.base/share/classes/com/sun/crypto/provider/GCTR.java > location in 8u: jdk/src/share/classes/com/sun/crypto/provider/GCTR.java > > Webrev: http://cr.openjdk.java.net/~zmajo/8067648-8u/webrev.00/ > > Testing: All JPRT tests pass. The fix was pushed last week into 9 and passes two nightly runs. > > Thank you and best regards, > > > Zoltan > From coleen.phillimore at oracle.com Mon Apr 20 20:59:49 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 20 Apr 2015 16:59:49 -0400 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> Message-ID: <553568C5.5000202@oracle.com> Can we just switch the default instead? Is that a simple makefile change? Coleen On 4/17/15, 6:35 AM, Lindenmaier, Goetz wrote: > That would be great!! > > Thanks David, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 17. April 2015 12:23 > To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn > Cc: HotSpot Open Source Developers > Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! > > On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> another occurance of this ... please, please add a non-pch build to >> jprt! >> https://bugs.openjdk.java.net/browse/JDK-8078048 > I will. Unfortunately first I have some no-PCH issues to address. And > unfortunately they are not top of my priority list right now. Hopefully > next week sometime. > > David > >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis >> Sent: Donnerstag, 9. April 2015 11:35 >> To: Andrew Dinn >> Cc: HotSpot Open Source Developers >> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >> >> On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn wrote: >>> On 09/04/15 09:02, Erik Joelsson wrote: >>>> I think that as long as we claim to support building both with and >>>> without PCH, the automatic testing should test both with and without >>>> PCH. By adding one or two build targets, or perhaps change an existing >>>> target, we could increase our test matrix to cover this easily. >>> I think this restates Volker's original remarks in redux. >>> >> No, not at all! I don't necessarily want to test more build >> configurations (that's another topic). >> >> My point is that PCH changes the compilation semantics and can hide >> real program errors. That's because with PCHs, every compilation unit >> sees the full precompiled header database (i.e. all the headers which >> are included in the "precompiled.hpp" PCH file). So if somebody >> forgets to include a dependency X.hpp in A.cpp, A.cpp may still >> compile with PCH because it includes the precompiled header file >> "precompiled.hpp" which in turn includes X.hpp. But the compilation of >> A.cpp will fail on platforms/configurations where we do not use >> precompiled headers. The two references I gave in my original mail are >> bugs that resulted from this problem. >> >> Besides program errors, the use of PCH can also lead to behavioral >> changes in the created binary when it comes to inlining. Because of >> PCHs some compilation units may be able to inline methods even if they >> do not explicitly include the files which contain the corresponding >> implementations because the implementation files are included in the >> PCH file. Without PCHs the compilers will simply emit calls to these >> functions (and, depending on the toolchain, emit a warning). >> >> I'm not familiar with ccache so I can not say if it has similar effects. >> >>> So, given that we do need this (NOW! :-) is anyone able and willing to >>> sponsor this? >>> >> Yes, this question remains to be answered :) >> >> Regards, >> Volker >> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> From coleen.phillimore at oracle.com Mon Apr 20 21:22:07 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 20 Apr 2015 17:22:07 -0400 Subject: RFR(xs): 8076475: Misuses of strncpy/strncat In-Reply-To: References: <552521AF.3060302@oracle.com> <55278DE9.5000600@oracle.com> <55279C36.2000004@oracle.com> Message-ID: <55356DFF.5060906@oracle.com> This seems good. Coleen On 4/20/15, 4:58 AM, Thomas St?fe wrote: > Hi, > > could I have an additional reviewer, please? > > current webrev is: > http://cr.openjdk.java.net/~stuefe/webrevs/8076475/webrev.01/webrev/ > > Thank you! > > ..Thomas > > On Fri, Apr 10, 2015 at 1:25 PM, Thomas St?fe > wrote: > >> .. adding hotspot-dev to attract another reviewer. >> >> On Fri, Apr 10, 2015 at 11:47 AM, Dmitry Samersoff < >> dmitry.samersoff at oracle.com> wrote: >> >>> Thomas, >>> >>> I can sponsor the push, but you need an official reviewer. >>> >>> -Dmitry >>> >>> On 2015-04-10 12:31, Thomas St?fe wrote: >>>> Dmitry, Thanks for the review! >>>> >>>> Still need a second review and also a sponsor. >>>> >>>> .. Thomas >>>> >>>> On Apr 10, 2015 10:46 AM, "Dmitry Samersoff" >>>> > >>> wrote: >>>> Thomas, >>>> >>>> Looks good for me! >>>> >>>> Thank you for doing it. >>>> >>>> -Dmitry >>>> >>>> On 2015-04-10 10:50, Thomas St?fe wrote: >>>> > Hi Dimitry, >>>> > >>>> > see new version here: >>>> > >>>> > >>> http://cr.openjdk.java.net/~stuefe/webrevs/8076475/webrev.01/webrev/ >>>> > >>>> > >>>> > On Wed, Apr 8, 2015 at 2:40 PM, Dmitry Samersoff >>>> > >>>> >>> >> wrote: >>>> > >>>> > Thomas, >>>> > >>>> > ** agent/src/os/bsd/libproc_impl.c >>>> > ** agent/src/os/linux/libproc_impl.c >>>> > >>>> > newlib->name has the size of (PATH_MAX + NAME_MAX + 1) >>>> > >>>> > see ./src/os/bsd/libproc_impl.h:92 >>>> > >>>> > So no truncation is actually possible here. >>>> > >>>> > To make this code nice-looking it's better to add: >>>> > >>>> > if (strlen(libname) > sizeof(newlib->name)) { >>>> > // Bail out with debug message >>>> > ... >>>> > } >>>> > strcpy(newlib->name, libname); >>>> > >>>> > rather than use snprintf here. >>>> > >>>> > >>>> > I changed the coding according to your suggestions. >>>> > >>>> > There is still the strlen vs strnlen question Kim mentioned, but >>>> we use >>>> > strlen all over the place, and I am not sure if all platforms >>>> support it >>>> > (AIX was known to have a broken strnlen implementation, one would >>> need >>>> > to check that first before changing strlen to strnlen) >>>> > >>>> > >>>> > ** arguments.cpp:3466 >>>> > >>>> > It might be better to use snprintf here. >>>> > >>>> > >>>> > Agree, done >>>> > >>>> > >>>> > ** arguments.cpp:3629 >>>> > >>>> > It's better to just replace strncat/strncpy to strcat/strcpy >>>> > in the original code - as soon as we allocating memory with >>>> respect to >>>> > variable lenght, we don't need to check this length again. >>>> > >>>> > >>>> > Sorry, I disagree here - I think using snprintf makes the code >>> more >>>> > readable. It comes down to a matter of taste, so lets see what >>>> others think. >>>> > >>>> > >>>> > >>>> > ** vmError.cpp:222 >>>> > >>>> > It's better to keep original code. >>>> > >>>> > >>>> > Agree, done >>>> > >>>> > Best Regards, Thomas >>>> > >>>> > >>>> > >>>> > Other changes looks good for me! >>>> > -Dmitry >>>> > >>>> > >>>> > On 2015-04-08 11:09, Thomas St?fe wrote: >>>> > > Hi, >>>> > > >>>> > > please review these small fixes around use of >>> strncpy/strncat. >>>> > > >>>> > > Bug report: >>> https://bugs.openjdk.java.net/browse/JDK-8076475 >>>> > > Webrev: >>>> > > >>>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8076475/webrev.00/webrev/ >>>> > > >>>> > > Changes in detail are: >>>> > > >>>> > > agent/src/os/bsd/libproc_impl.c >>>> > > agent/src/os/linux/libproc_impl.c: >>>> > > - missing \0 on truncation. Replaced with >>>> > snprintf, add >>>> > > truncation handling >>>> > > >>>> > > src/os/bsd/dtrace/libjvm_db.c >>>> > > src/os/solaris/dtrace/libjvm_db.c >>>> > > @@ -580,17 +580,18 @@ >>>> > > - overwrite on truncation >>>> > > @@ -1093,13 +1094,13 @@ >>>> > > - overwrite on truncation >>>> > > >>>> > > src/share/vm/compiler/compileBroker.hpp >>>> > > - missing \0 on truncation. >>>> > > >>>> > > src/share/tools/hsdis/hsdis.c >>>> > > - missing \0 >>>> > > >>>> > > src/os/bsd/vm/decoder_machO.cpp >>>> > > - missing \0 on truncation. >>>> > > >>>> > > src/share/vm/compiler/compilerOracle.cpp >>>> > > - Replaced with jio_snprintf, less awkward >>> and >>>> > does not >>>> > > restrict each part to 255 chars each. >>>> > > >>>> > > src/share/vm/compiler/disassembler.cpp >>>> > > - missing \0 on truncation. >>>> > > >>>> > > src/share/vm/runtime/arguments.cpp >>>> > > @@ -2703,11 +2703,11 @@ >>>> > > - replaced with strdup, easier to read >>>> > > @@ -3294,12 +3294,11 @@ >>>> > > - the same >>>> > > @@ -3627,18 +3626,14 @@ >>>> > > - replace strncpy/strncat sequence with >>>> jio_snprintf - >>>> > > easier to read. >>>> > > - replace malloc/strncpy with os::strdup >>>> > > >>>> > > src/share/vm/utilities/ostream.cpp >>>> > > - avoid \0 padding >>>> > > >>>> > > src/share/vm/utilities/vmError.cp >>>> > > @@ -219,7 +219,7 @@ >>>> > > - avoid \0 padding >>>> > > @@ -463,14 +463,7 @@ >>>> > > - simplified >>>> > > >>>> > > Kind regards, Thomas >>>> > > >>>> > >>>> > >>>> > -- >>>> > Dmitry Samersoff >>>> > Oracle Java development team, Saint Petersburg, Russia >>>> > * I would love to change the world, but they won't give me the >>>> sources. >>>> > >>>> > >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the >>> sources. >>> >>> -- >>> 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 coleen.phillimore at oracle.com Mon Apr 20 23:34:34 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 20 Apr 2015 19:34:34 -0400 Subject: [9] RFR (S): 8059340: ConstantPool::_resolved_references is missing in heap dump In-Reply-To: <552FFBAA.6050103@oracle.com> References: <542971DC.2090803@oracle.com> <24133E27-C024-41D8-80EF-B5707CFF0D0C@oracle.com> <552FFBAA.6050103@oracle.com> Message-ID: <55358D0A.1020407@oracle.com> Vladimir, I think that changing the format of the heap dump isn't a good idea either. On 4/16/15, 2:12 PM, Vladimir Ivanov wrote: > (sorry for really late response; just got enough time to return to the > bug) I'd forgotten about it! > > Coleen, Staffan, > > Thanks a lot for the feedback! > > After thinking about the fix more, I don't think that using reserved > oop slot in CLASS DUMP for recording _resolved_references is the best > thing to do. IMO the change causes too much work for the users (heap > dump analysis tools). > > It needs specification update and then heap dump analyzers should be > updated as well. > > I have 2 alternative approaches (hacky and not-so-hacky :-)): > > - artificial class static field in the dump ("" > + optional id to guarantee unique name); > > - add j.l.Class::_resolved_references field; > Not sure how much overhead (mostly reads from bytecode) the move > from ConstantPool to j.l.Class adds, so I propose just to duplicate it > for now. I really like this second approach, so much so that I had a prototype for moving resolved_references directly to the j.l.Class object about a year ago. I couldn't find any benefit other than consolidating oops so the GC would have less work to do. If the resolved_references are moved to j.l.C instance, they can not be jobjects and the ClassLoaderData::_handles area wouldn't have to contain them (but there are other things that could go there so don't delete the _handles field yet). The change I had was relatively simple. The only annoying part was that getting to the resolved references has to be in macroAssembler and do: go through method->cpCache->constants->instanceKlass->java_mirror() rather than method->cpCache->constants->resolved_references->jmethod indirection I think it only affects the interpreter so the extra indirection wouldn't affect performance, so don't duplicate it! You don't want to increase space used by j.l.C without taking it out somewhere else! > > What do you think about that? Is this bug worth doing this? I don't know but I'd really like it. Coleen > > Best regards, > Vladimir Ivanov > > On 10/6/14 11:35 AM, Staffan Larsen wrote: >> This looks like a good approach. However, there are a couple of more >> places that need to be updated. >> >> The hprof binary format is described in >> jdk/src/jdk.hprof.agent/share/native/libhprof/manual.html and needs >> to be updated. It?s also more formally specified in hprof_b_spec.h in >> the same directory. >> >> The hprof JVMTI agent in jdk/src/jdk.hprof.agent code would also need >> to be updated to show this field. Since this is a JVMTI agent it >> needs to be possible to find the resolved_refrences array via the >> JVMTI heap walking API. Perhaps that already works? - I haven?t looked. >> >> Finally, the Serviceability Agent implements yet another hprof binary >> dumper in >> hotspot/agent//src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java >> which also needs to write this reference. >> >> Thanks, >> /Staffan >> >> On 29 sep 2014, at 16:51, Vladimir Ivanov >> wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8059340/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8059340 >>> >>> VM heap dump doesn't contain ConstantPool::_resolved_references for >>> classes which have resolved references. >>> >>> ConstantPool::_resolved_references points to an Object[] holding >>> resolved constant pool entries (patches for VM anonymous classes, >>> linked CallSite & MethodType for invokedynamic instructions). >>> >>> I've decided to use reserved slot in HPROF class header format. >>> It requires an update in jhat to correctly display new info. >>> >>> The other approach I tried was to dump the reference as a fake >>> static field [1], but storing VM internal >>> ConstantPool::_resolved_references among user defined fields looks >>> confusing. >>> >>> Testing: manual (verified that corresponding arrays are properly >>> linked in Nashorn heap dump). >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] http://cr.openjdk.java.net/~vlivanov/8059340/static >> From volker.simonis at gmail.com Tue Apr 21 00:14:47 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 Apr 2015 04:14:47 +0400 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <553568C5.5000202@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> Message-ID: Hi Coleen, the default is not to use PCH and I think that's probably OK for most people. If somebody plays with the include files, he should use the '--disable-precompiled-headers' configure option. Making this option the default for the JPRT builds only will guard against the build errors described before while it still allows everybody to do local builds at full speed. Regards, Volker On 4/21/15, Coleen Phillimore wrote: > > Can we just switch the default instead? Is that a simple makefile change? > Coleen > > On 4/17/15, 6:35 AM, Lindenmaier, Goetz wrote: >> That would be great!! >> >> Thanks David, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 17. April 2015 12:23 >> To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn >> Cc: HotSpot Open Source Developers >> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >> >> On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> another occurance of this ... please, please add a non-pch build to >>> jprt! >>> https://bugs.openjdk.java.net/browse/JDK-8078048 >> I will. Unfortunately first I have some no-PCH issues to address. And >> unfortunately they are not top of my priority list right now. Hopefully >> next week sometime. >> >> David >> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf >>> Of Volker Simonis >>> Sent: Donnerstag, 9. April 2015 11:35 >>> To: Andrew Dinn >>> Cc: HotSpot Open Source Developers >>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >>> >>> On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn wrote: >>>> On 09/04/15 09:02, Erik Joelsson wrote: >>>>> I think that as long as we claim to support building both with and >>>>> without PCH, the automatic testing should test both with and without >>>>> PCH. By adding one or two build targets, or perhaps change an existing >>>>> target, we could increase our test matrix to cover this easily. >>>> I think this restates Volker's original remarks in redux. >>>> >>> No, not at all! I don't necessarily want to test more build >>> configurations (that's another topic). >>> >>> My point is that PCH changes the compilation semantics and can hide >>> real program errors. That's because with PCHs, every compilation unit >>> sees the full precompiled header database (i.e. all the headers which >>> are included in the "precompiled.hpp" PCH file). So if somebody >>> forgets to include a dependency X.hpp in A.cpp, A.cpp may still >>> compile with PCH because it includes the precompiled header file >>> "precompiled.hpp" which in turn includes X.hpp. But the compilation of >>> A.cpp will fail on platforms/configurations where we do not use >>> precompiled headers. The two references I gave in my original mail are >>> bugs that resulted from this problem. >>> >>> Besides program errors, the use of PCH can also lead to behavioral >>> changes in the created binary when it comes to inlining. Because of >>> PCHs some compilation units may be able to inline methods even if they >>> do not explicitly include the files which contain the corresponding >>> implementations because the implementation files are included in the >>> PCH file. Without PCHs the compilers will simply emit calls to these >>> functions (and, depending on the toolchain, emit a warning). >>> >>> I'm not familiar with ccache so I can not say if it has similar effects. >>> >>>> So, given that we do need this (NOW! :-) is anyone able and willing to >>>> sponsor this? >>>> >>> Yes, this question remains to be answered :) >>> >>> Regards, >>> Volker >>> >>>> regards, >>>> >>>> >>>> Andrew Dinn >>>> ----------- >>>> > > From christian.thalinger at oracle.com Tue Apr 21 00:22:11 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 20 Apr 2015 17:22:11 -0700 Subject: [9] RFR (S): 8059340: ConstantPool::_resolved_references is missing in heap dump In-Reply-To: <55358D0A.1020407@oracle.com> References: <542971DC.2090803@oracle.com> <24133E27-C024-41D8-80EF-B5707CFF0D0C@oracle.com> <552FFBAA.6050103@oracle.com> <55358D0A.1020407@oracle.com> Message-ID: <21C42551-29AA-44DC-AFE5-6156D681503D@oracle.com> > On Apr 20, 2015, at 4:34 PM, Coleen Phillimore wrote: > > > Vladimir, > > I think that changing the format of the heap dump isn't a good idea either. > > On 4/16/15, 2:12 PM, Vladimir Ivanov wrote: >> (sorry for really late response; just got enough time to return to the bug) > > I'd forgotten about it! >> >> Coleen, Staffan, >> >> Thanks a lot for the feedback! >> >> After thinking about the fix more, I don't think that using reserved oop slot in CLASS DUMP for recording _resolved_references is the best thing to do. IMO the change causes too much work for the users (heap dump analysis tools). >> >> It needs specification update and then heap dump analyzers should be updated as well. >> >> I have 2 alternative approaches (hacky and not-so-hacky :-)): >> >> - artificial class static field in the dump ("" + optional id to guarantee unique name); >> >> - add j.l.Class::_resolved_references field; >> Not sure how much overhead (mostly reads from bytecode) the move from ConstantPool to j.l.Class adds, so I propose just to duplicate it for now. > > I really like this second approach, so much so that I had a prototype for moving resolved_references directly to the j.l.Class object about a year ago. I couldn't find any benefit other than consolidating oops so the GC would have less work to do. If the resolved_references are moved to j.l.C instance, they can not be jobjects and the ClassLoaderData::_handles area wouldn't have to contain them (but there are other things that could go there so don't delete the _handles field yet). > > The change I had was relatively simple. The only annoying part was that getting to the resolved references has to be in macroAssembler and do: > > go through method->cpCache->constants->instanceKlass->java_mirror() rather than > method->cpCache->constants->resolved_references->jmethod indirection > > I think it only affects the interpreter so the extra indirection wouldn't affect performance, so don't duplicate it! You don't want to increase space used by j.l.C without taking it out somewhere else! I like this approach. Can we do this? > >> >> What do you think about that? > > Is this bug worth doing this? I don't know but I'd really like it. > > Coleen > >> >> Best regards, >> Vladimir Ivanov >> >> On 10/6/14 11:35 AM, Staffan Larsen wrote: >>> This looks like a good approach. However, there are a couple of more places that need to be updated. >>> >>> The hprof binary format is described in jdk/src/jdk.hprof.agent/share/native/libhprof/manual.html and needs to be updated. It?s also more formally specified in hprof_b_spec.h in the same directory. >>> >>> The hprof JVMTI agent in jdk/src/jdk.hprof.agent code would also need to be updated to show this field. Since this is a JVMTI agent it needs to be possible to find the resolved_refrences array via the JVMTI heap walking API. Perhaps that already works? - I haven?t looked. >>> >>> Finally, the Serviceability Agent implements yet another hprof binary dumper in hotspot/agent//src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java which also needs to write this reference. >>> >>> Thanks, >>> /Staffan >>> >>> On 29 sep 2014, at 16:51, Vladimir Ivanov wrote: >>> >>>> http://cr.openjdk.java.net/~vlivanov/8059340/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8059340 >>>> >>>> VM heap dump doesn't contain ConstantPool::_resolved_references for classes which have resolved references. >>>> >>>> ConstantPool::_resolved_references points to an Object[] holding resolved constant pool entries (patches for VM anonymous classes, linked CallSite & MethodType for invokedynamic instructions). >>>> >>>> I've decided to use reserved slot in HPROF class header format. >>>> It requires an update in jhat to correctly display new info. >>>> >>>> The other approach I tried was to dump the reference as a fake static field [1], but storing VM internal ConstantPool::_resolved_references among user defined fields looks confusing. >>>> >>>> Testing: manual (verified that corresponding arrays are properly linked in Nashorn heap dump). >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] http://cr.openjdk.java.net/~vlivanov/8059340/static From david.holmes at oracle.com Tue Apr 21 01:31:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Apr 2015 11:31:09 +1000 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> Message-ID: <5535A85D.101@oracle.com> On 21/04/2015 10:14 AM, Volker Simonis wrote: > Hi Coleen, > > the default is not to use PCH and I think that's probably OK for most > people. If somebody plays with the include files, he should use the > '--disable-precompiled-headers' configure option. The default depends on platform. For solaris we never use PCH. For the other platforms I think we always do. Simply switching the default just creates a different problem. Engineers will use PCH locally and so may encounter issues if PCH has not been tested at integration time. I plan to fix this in JPRT by making a few configurations non-PCH. David ----- > Making this option the default for the JPRT builds only will guard > against the build errors described before while it still allows > everybody to do local builds at full speed. > > Regards, > Volker > > On 4/21/15, Coleen Phillimore wrote: >> >> Can we just switch the default instead? Is that a simple makefile change? >> Coleen >> >> On 4/17/15, 6:35 AM, Lindenmaier, Goetz wrote: >>> That would be great!! >>> >>> Thanks David, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Freitag, 17. April 2015 12:23 >>> To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn >>> Cc: HotSpot Open Source Developers >>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >>> >>> On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> another occurance of this ... please, please add a non-pch build to >>>> jprt! >>>> https://bugs.openjdk.java.net/browse/JDK-8078048 >>> I will. Unfortunately first I have some no-PCH issues to address. And >>> unfortunately they are not top of my priority list right now. Hopefully >>> next week sometime. >>> >>> David >>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf >>>> Of Volker Simonis >>>> Sent: Donnerstag, 9. April 2015 11:35 >>>> To: Andrew Dinn >>>> Cc: HotSpot Open Source Developers >>>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >>>> >>>> On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn wrote: >>>>> On 09/04/15 09:02, Erik Joelsson wrote: >>>>>> I think that as long as we claim to support building both with and >>>>>> without PCH, the automatic testing should test both with and without >>>>>> PCH. By adding one or two build targets, or perhaps change an existing >>>>>> target, we could increase our test matrix to cover this easily. >>>>> I think this restates Volker's original remarks in redux. >>>>> >>>> No, not at all! I don't necessarily want to test more build >>>> configurations (that's another topic). >>>> >>>> My point is that PCH changes the compilation semantics and can hide >>>> real program errors. That's because with PCHs, every compilation unit >>>> sees the full precompiled header database (i.e. all the headers which >>>> are included in the "precompiled.hpp" PCH file). So if somebody >>>> forgets to include a dependency X.hpp in A.cpp, A.cpp may still >>>> compile with PCH because it includes the precompiled header file >>>> "precompiled.hpp" which in turn includes X.hpp. But the compilation of >>>> A.cpp will fail on platforms/configurations where we do not use >>>> precompiled headers. The two references I gave in my original mail are >>>> bugs that resulted from this problem. >>>> >>>> Besides program errors, the use of PCH can also lead to behavioral >>>> changes in the created binary when it comes to inlining. Because of >>>> PCHs some compilation units may be able to inline methods even if they >>>> do not explicitly include the files which contain the corresponding >>>> implementations because the implementation files are included in the >>>> PCH file. Without PCHs the compilers will simply emit calls to these >>>> functions (and, depending on the toolchain, emit a warning). >>>> >>>> I'm not familiar with ccache so I can not say if it has similar effects. >>>> >>>>> So, given that we do need this (NOW! :-) is anyone able and willing to >>>>> sponsor this? >>>>> >>>> Yes, this question remains to be answered :) >>>> >>>> Regards, >>>> Volker >>>> >>>>> regards, >>>>> >>>>> >>>>> Andrew Dinn >>>>> ----------- >>>>> >> >> From goetz.lindenmaier at sap.com Tue Apr 21 08:20:42 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Apr 2015 08:20:42 +0000 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> Hi, another include that's missing. This time it breaks aix only, would not have been detected by non-pch build :) taskqueue.hpp calls Stack::push(), thus it must include stack.inline.hpp. Compilation of parallelScavenge/vmPSOperations.cpp failed. Please review this tiny change. I also please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ Best regards, Goetz. From thomas.stuefe at gmail.com Tue Apr 21 09:11:41 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 Apr 2015 11:11:41 +0200 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> Message-ID: Looks fine. ..Thomas On Tue, Apr 21, 2015 at 10:20 AM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > another include that's missing. This time it breaks aix only, would not > have been > detected by non-pch build :) > taskqueue.hpp calls Stack::push(), thus it must include stack.inline.hpp. > > Compilation of parallelScavenge/vmPSOperations.cpp failed. > > Please review this tiny change. I also please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ > > Best regards, > Goetz. > From edward.nevill at linaro.org Tue Apr 21 09:16:37 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 21 Apr 2015 10:16:37 +0100 Subject: aarch64: jdk9: 8078245: fails to build from source Message-ID: <1429607797.4116.11.camel@mylittlepony.linaroharston> Hi, The current jdk9 tip fails to build from source on aarch64 with the following error message /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' collect2: error: ld returned 1 exit status The following webrev gets it building again. http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ Please review and if approved push. See comments below. Thanks, Ed. This was introduced at changeset 11769 changeset: 11769:cb75299d5933 user: azvegint date: Mon Jan 19 20:02:31 2015 +0300 files: src/java.desktop/share/native/libsplashscreen/libpng/CHANGES src/java.desktop/share/native/libsplashscreen/libpng/LICENSE src/java.desktop/share/native/libsplashscreen/libpng/README src/java.desktop/share/native/libsplashscreen/libpng/png.c src/java.desktop/share/native/libsplashscreen/libpng/png.h src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngdebug.h src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c src/java.desktop/share/native/libsplashscreen/libpng/pngget.c src/java.desktop/share/native/libsplashscreen/libpng/pnginfo.h src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c src/java.desktop/share/native/libsplashscreen/libpng/pngpread.c src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h src/java.desktop/share/native/libsplashscreen/libpng/pngread.c src/java.desktop/share/native/libsplashscreen/libpng/pngrio.c src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c src/java.desktop/share/native/libsplashscreen/libpng/pngset.c src/java.desktop/share/native/libsplashscreen/libpng/pngstruct.h src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c description: 8069198: Upgrade image library Reviewed-by: ahgross, bae, mschoene, serb This changeset seems to introduce some ARM Neon optimisations, however I cannot seem to access the associated bug report JDK-8069198 as it seems I do not have suitable privileges to read the report. The problem is that it is also attempting to build this code for AARCH64 resulting in the above undefined symbol. The above webrev fixes this by ensuring that it only attempts to compile this code if defined(__arm__) From goetz.lindenmaier at sap.com Tue Apr 21 09:19:10 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Apr 2015 09:19:10 +0000 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBFFC7@DEWDFEMB12A.global.corp.sap> Thanks Thomas! Best regards, Goetz. From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Dienstag, 21. April 2015 11:12 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. Looks fine. ..Thomas On Tue, Apr 21, 2015 at 10:20 AM, Lindenmaier, Goetz > wrote: Hi, another include that's missing. This time it breaks aix only, would not have been detected by non-pch build :) taskqueue.hpp calls Stack::push(), thus it must include stack.inline.hpp. Compilation of parallelScavenge/vmPSOperations.cpp failed. Please review this tiny change. I also please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ Best regards, Goetz. From edward.nevill at linaro.org Tue Apr 21 09:20:38 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 21 Apr 2015 10:20:38 +0100 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5527E1B9.5030109@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> Message-ID: <1429608038.4116.13.camel@mylittlepony.linaroharston> Hi, If everyone is happy with this patch could someone push it please, Thanks, Ed. On Fri, 2015-04-10 at 07:44 -0700, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 4/10/15 1:54 AM, Edward Nevill wrote: > > Hi Vladimir, > > > > On Thu, 2015-04-09 at 10:32 -0700, Vladimir Kozlov wrote: > >> Hi Edward, > >> > >> In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM. > >> Unless you have configuration without C2. I think it should be dynamic check after you find who generated this _cb. > >> Can you explain what this code does (there is not comment): > > > > We do build without C2 as part of our testing. However, as Andrew Haley said, this is old debug code, so I propose simply removing it. Its usefulness is rather limited once fp can be allocated as a general purpose register. > > > >> > >> 80 #ifndef PRODUCT > >> 81 if (fp) > >> 82 if (sp > fp || (fp - sp > 0x100000)) > >> 83 for(;;) > >> 84 asm("nop"); > >> 85 #endif > > > > New webrev removing this code @ > > > > http://cr.openjdk.java.net/~enevill/8075930/webrev.03/ > > > > All the best, > > Ed. > > > > From thomas.schatzl at oracle.com Tue Apr 21 09:23:14 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 21 Apr 2015 11:23:14 +0200 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> Message-ID: <1429608194.3343.5.camel@oracle.com> Hi Goetz, On Tue, 2015-04-21 at 08:20 +0000, Lindenmaier, Goetz wrote: > Hi, > > another include that?s missing. This time it breaks aix only, would > not have been > detected by non-pch build J > taskqueue.hpp calls Stack::push(), thus it must include > stack.inline.hpp. .inline.hpp files should not be included by .hpp files because this often causes lots of additional files to be included, and is prone to creating include dependency cycles. I think the only option here is to move the inline methods into their own taskqueue.inline.hpp file that is included in the appropriate places. Thanks, Thomas From goetz.lindenmaier at sap.com Tue Apr 21 09:45:03 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Apr 2015 09:45:03 +0000 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <1429608194.3343.5.camel@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> <1429608194.3343.5.camel@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFBFFEE@DEWDFEMB12A.global.corp.sap> Hi Thomas, I know what you are saying. But for taskqueue this would be a major reengineering, which should be done in a separate change. It already includes memory/allocation.inline.hpp and runtime/orderAccess.inline.hpp. This was broken by some previous cleanup, so I really would appreciate this fix for now so that the aix build works again. Best regards, Goetz. -----Original Message----- From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] Sent: Dienstag, 21. April 2015 11:23 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. Hi Goetz, On Tue, 2015-04-21 at 08:20 +0000, Lindenmaier, Goetz wrote: > Hi, > > another include that?s missing. This time it breaks aix only, would > not have been > detected by non-pch build J > taskqueue.hpp calls Stack::push(), thus it must include > stack.inline.hpp. .inline.hpp files should not be included by .hpp files because this often causes lots of additional files to be included, and is prone to creating include dependency cycles. I think the only option here is to move the inline methods into their own taskqueue.inline.hpp file that is included in the appropriate places. Thanks, Thomas From stefan.karlsson at oracle.com Tue Apr 21 10:04:51 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 Apr 2015 12:04:51 +0200 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> Message-ID: <553620C3.7050501@oracle.com> Hi Goetz, On 2015-04-21 10:20, Lindenmaier, Goetz wrote: > > Hi, > > another include that?s missing. This time it breaks aix only, would > not have been > > detected by non-pch build J > > taskqueue.hpp calls Stack::push(), thus it must include stack.inline.hpp. > > Compilation of parallelScavenge/vmPSOperations.cpp failed. > > Please review this tiny change. I also please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ > > I understand that this is an easy fix, but I don't want stack.inline.hpp to be added to the hpp file. The preferred fix would be extract the offending push function out of the taskqueue.hpp file and put it in a new file called taskqueue.inline.hpp. I created a RFE for that a couple of weeks ago: https://bugs.openjdk.java.net/browse/JDK-8076177 - Remove usage of stack.inline.hpp functions from taskqueue.hpp Until someone takes care about 8076177, could you workaround the compile error by including stack.inline.hpp in vmPSOperations.cpp? Do you know what in vmPSOperations.cpp depends on taskqueue.hpp? I can't find anything, but I see that we include psScavenge.inline.hpp, which includes taskqueue.hpp via psPromotionManager.inline.hpp and psPromotionManager.hpp. Maybe you could workaround the problem by removing the "#include .../psScavenge.inline.hpp" line, which isn't needed by vmPSOperations.cpp? Thanks, StefanK > Best regards, > > Goetz. > From aph at redhat.com Tue Apr 21 10:20:21 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Apr 2015 11:20:21 +0100 Subject: RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1429608038.4116.13.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> Message-ID: <55362465.2080805@redhat.com> On 04/21/2015 10:20 AM, Edward Nevill wrote: > If everyone is happy with this patch could someone push it please, I'll do it. Andrew. From stefan.karlsson at oracle.com Tue Apr 21 11:52:34 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 Apr 2015 13:52:34 +0200 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <553620C3.7050501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> <553620C3.7050501@oracle.com> Message-ID: <55363A02.4060008@oracle.com> On 2015-04-21 12:04, Stefan Karlsson wrote: > Hi Goetz, > > On 2015-04-21 10:20, Lindenmaier, Goetz wrote: >> >> Hi, >> >> another include that?s missing. This time it breaks aix only, would >> not have been >> >> detected by non-pch build J >> >> taskqueue.hpp calls Stack::push(), thus it must include >> stack.inline.hpp. >> >> Compilation of parallelScavenge/vmPSOperations.cpp failed. >> >> Please review this tiny change. I also please need a sponsor. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ >> >> > > I understand that this is an easy fix, but I don't want > stack.inline.hpp to be added to the hpp file. The preferred fix would > be extract the offending push function out of the taskqueue.hpp file > and put it in a new file called taskqueue.inline.hpp. I created a RFE > for that a couple of weeks ago: > > https://bugs.openjdk.java.net/browse/JDK-8076177 - Remove usage of > stack.inline.hpp functions from taskqueue.hpp Here's an example of what it would take to move the push functions out to taskqueue.inline.hpp. Only compiled locally on my machine. I had to move some functions from PSParallelCompact to ParCompactionManager to get rid of a circular dependency between the two classes. That would probably be done as a separate RFE. StefanK > > Until someone takes care about 8076177, could you workaround the > compile error by including stack.inline.hpp in vmPSOperations.cpp? Do > you know what in vmPSOperations.cpp depends on taskqueue.hpp? I can't > find anything, but I see that we include psScavenge.inline.hpp, which > includes taskqueue.hpp via psPromotionManager.inline.hpp and > psPromotionManager.hpp. Maybe you could workaround the problem by > removing the "#include .../psScavenge.inline.hpp" line, which isn't > needed by vmPSOperations.cpp? > > Thanks, > StefanK > >> Best regards, >> >> Goetz. >> > From stefan.karlsson at oracle.com Tue Apr 21 11:53:16 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 Apr 2015 13:53:16 +0200 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <55363A02.4060008@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> <553620C3.7050501@oracle.com> <55363A02.4060008@oracle.com> Message-ID: <55363A2C.1080807@oracle.com> On 2015-04-21 13:52, Stefan Karlsson wrote: > On 2015-04-21 12:04, Stefan Karlsson wrote: >> Hi Goetz, >> >> On 2015-04-21 10:20, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> another include that?s missing. This time it breaks aix only, would >>> not have been >>> >>> detected by non-pch build J >>> >>> taskqueue.hpp calls Stack::push(), thus it must include >>> stack.inline.hpp. >>> >>> Compilation of parallelScavenge/vmPSOperations.cpp failed. >>> >>> Please review this tiny change. I also please need a sponsor. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ >>> >>> >>> >> >> I understand that this is an easy fix, but I don't want >> stack.inline.hpp to be added to the hpp file. The preferred fix would >> be extract the offending push function out of the taskqueue.hpp file >> and put it in a new file called taskqueue.inline.hpp. I created a RFE >> for that a couple of weeks ago: >> >> https://bugs.openjdk.java.net/browse/JDK-8076177 - Remove usage of >> stack.inline.hpp functions from taskqueue.hpp > > Here's an example of what it would take to move the push functions out > to taskqueue.inline.hpp. Only compiled locally on my machine. I had to > move some functions from PSParallelCompact to ParCompactionManager to > get rid of a circular dependency between the two classes. That would > probably be done as a separate RFE. And the link: http://cr.openjdk.java.net/~stefank/8076177/webrev.poc.01 StefanK > > > StefanK > >> >> Until someone takes care about 8076177, could you workaround the >> compile error by including stack.inline.hpp in vmPSOperations.cpp? Do >> you know what in vmPSOperations.cpp depends on taskqueue.hpp? I can't >> find anything, but I see that we include psScavenge.inline.hpp, which >> includes taskqueue.hpp via psPromotionManager.inline.hpp and >> psPromotionManager.hpp. Maybe you could workaround the problem by >> removing the "#include .../psScavenge.inline.hpp" line, which isn't >> needed by vmPSOperations.cpp? >> >> Thanks, >> StefanK >> >>> Best regards, >>> >>> Goetz. >>> >> > From goetz.lindenmaier at sap.com Tue Apr 21 12:19:43 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Apr 2015 12:19:43 +0000 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <55363A2C.1080807@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> <553620C3.7050501@oracle.com> <55363A02.4060008@oracle.com> <55363A2C.1080807@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC0075@DEWDFEMB12A.global.corp.sap> Hi Stefan, that's why I want to do a fix of the pure problem first -- this is not a simple change that's easy to be reviewed. And if split in two will take two steps to be committed. I'll add the include to some other file as you proposed. I will come up with a different fix as soon as possible. Best regards, Goetz. -----Original Message----- From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] Sent: Dienstag, 21. April 2015 13:53 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. On 2015-04-21 13:52, Stefan Karlsson wrote: > On 2015-04-21 12:04, Stefan Karlsson wrote: >> Hi Goetz, >> >> On 2015-04-21 10:20, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> another include that's missing. This time it breaks aix only, would >>> not have been >>> >>> detected by non-pch build J >>> >>> taskqueue.hpp calls Stack::push(), thus it must include >>> stack.inline.hpp. >>> >>> Compilation of parallelScavenge/vmPSOperations.cpp failed. >>> >>> Please review this tiny change. I also please need a sponsor. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ >>> >>> >>> >> >> I understand that this is an easy fix, but I don't want >> stack.inline.hpp to be added to the hpp file. The preferred fix would >> be extract the offending push function out of the taskqueue.hpp file >> and put it in a new file called taskqueue.inline.hpp. I created a RFE >> for that a couple of weeks ago: >> >> https://bugs.openjdk.java.net/browse/JDK-8076177 - Remove usage of >> stack.inline.hpp functions from taskqueue.hpp > > Here's an example of what it would take to move the push functions out > to taskqueue.inline.hpp. Only compiled locally on my machine. I had to > move some functions from PSParallelCompact to ParCompactionManager to > get rid of a circular dependency between the two classes. That would > probably be done as a separate RFE. And the link: http://cr.openjdk.java.net/~stefank/8076177/webrev.poc.01 StefanK > > > StefanK > >> >> Until someone takes care about 8076177, could you workaround the >> compile error by including stack.inline.hpp in vmPSOperations.cpp? Do >> you know what in vmPSOperations.cpp depends on taskqueue.hpp? I can't >> find anything, but I see that we include psScavenge.inline.hpp, which >> includes taskqueue.hpp via psPromotionManager.inline.hpp and >> psPromotionManager.hpp. Maybe you could workaround the problem by >> removing the "#include .../psScavenge.inline.hpp" line, which isn't >> needed by vmPSOperations.cpp? >> >> Thanks, >> StefanK >> >>> Best regards, >>> >>> Goetz. >>> >> > From aph at redhat.com Tue Apr 21 12:53:03 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Apr 2015 13:53:03 +0100 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <5534C0EC.1070005@redhat.com> References: <5534C0EC.1070005@redhat.com> Message-ID: <5536482F.3020104@redhat.com> On 04/20/2015 10:03 AM, Andrew Dinn wrote: > The following webrev is submitted for review (n.b. I am not an OpenJDK > committer so the patch does not yet have an associated JIRA). The patch looks good to me. https://bugs.openjdk.java.net/browse/JDK-8078263 Andrew. From goetz.lindenmaier at sap.com Tue Apr 21 13:27:21 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Apr 2015 13:27:21 +0000 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <55363A2C.1080807@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> <553620C3.7050501@oracle.com> <55363A02.4060008@oracle.com> <55363A2C.1080807@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC00E7@DEWDFEMB12A.global.corp.sap> Hi Stefan, removing the include of psScavenge.inline.hpp from vmPSOperations.cpp helps. This is not a real fix of the taskqueue issue, but fine with 8076177 coming up - especially as it reduces dependencies and needs not be reverted with 8076177. http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.02/ Best regards, Goetz. -----Original Message----- From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] Sent: Dienstag, 21. April 2015 13:53 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. On 2015-04-21 13:52, Stefan Karlsson wrote: > On 2015-04-21 12:04, Stefan Karlsson wrote: >> Hi Goetz, >> >> On 2015-04-21 10:20, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> another include that's missing. This time it breaks aix only, would >>> not have been >>> >>> detected by non-pch build J >>> >>> taskqueue.hpp calls Stack::push(), thus it must include >>> stack.inline.hpp. >>> >>> Compilation of parallelScavenge/vmPSOperations.cpp failed. >>> >>> Please review this tiny change. I also please need a sponsor. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ >>> >>> >>> >> >> I understand that this is an easy fix, but I don't want >> stack.inline.hpp to be added to the hpp file. The preferred fix would >> be extract the offending push function out of the taskqueue.hpp file >> and put it in a new file called taskqueue.inline.hpp. I created a RFE >> for that a couple of weeks ago: >> >> https://bugs.openjdk.java.net/browse/JDK-8076177 - Remove usage of >> stack.inline.hpp functions from taskqueue.hpp > > Here's an example of what it would take to move the push functions out > to taskqueue.inline.hpp. Only compiled locally on my machine. I had to > move some functions from PSParallelCompact to ParCompactionManager to > get rid of a circular dependency between the two classes. That would > probably be done as a separate RFE. And the link: http://cr.openjdk.java.net/~stefank/8076177/webrev.poc.01 StefanK > > > StefanK > >> >> Until someone takes care about 8076177, could you workaround the >> compile error by including stack.inline.hpp in vmPSOperations.cpp? Do >> you know what in vmPSOperations.cpp depends on taskqueue.hpp? I can't >> find anything, but I see that we include psScavenge.inline.hpp, which >> includes taskqueue.hpp via psPromotionManager.inline.hpp and >> psPromotionManager.hpp. Maybe you could workaround the problem by >> removing the "#include .../psScavenge.inline.hpp" line, which isn't >> needed by vmPSOperations.cpp? >> >> Thanks, >> StefanK >> >>> Best regards, >>> >>> Goetz. >>> >> > From adinn at redhat.com Tue Apr 21 13:43:04 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 21 Apr 2015 14:43:04 +0100 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <5536482F.3020104@redhat.com> References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com> Message-ID: <553653E8.4020301@redhat.com> On 21/04/15 13:53, Andrew Haley wrote: > On 04/20/2015 10:03 AM, Andrew Dinn wrote: >> The following webrev is submitted for review (n.b. I am not an OpenJDK >> committer so the patch does not yet have an associated JIRA). > > The patch looks good to me. > > https://bugs.openjdk.java.net/browse/JDK-8078263 A new webrev with the commit in standard format (listing JIRA#, sumamry and reviewer) and placed at: http://cr.openjdk.java.net/~adinn/8078263/webrev.01/ regards, Andrew Dinn ----------- From stefan.karlsson at oracle.com Tue Apr 21 14:29:42 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 Apr 2015 16:29:42 +0200 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC00E7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> <553620C3.7050501@oracle.com> <55363A02.4060008@oracle.com> <55363A2C.1080807@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC00E7@DEWDFEMB12A.global.corp.sap> Message-ID: <55365ED6.1020303@oracle.com> On 2015-04-21 15:27, Lindenmaier, Goetz wrote: > Hi Stefan, > > removing the include of psScavenge.inline.hpp from vmPSOperations.cpp > helps. > This is not a real fix of the taskqueue issue, but fine with 8076177 coming up - especially > as it reduces dependencies and needs not be reverted with 8076177. > http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.02/ Looks good, I'll sponsor this. Thanks for using this workaround-fix. Thanks, StefanK > > Best regards, > Goetz. > > > > -----Original Message----- > From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] > Sent: Dienstag, 21. April 2015 13:53 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. > > > > On 2015-04-21 13:52, Stefan Karlsson wrote: >> On 2015-04-21 12:04, Stefan Karlsson wrote: >>> Hi Goetz, >>> >>> On 2015-04-21 10:20, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> another include that's missing. This time it breaks aix only, would >>>> not have been >>>> >>>> detected by non-pch build J >>>> >>>> taskqueue.hpp calls Stack::push(), thus it must include >>>> stack.inline.hpp. >>>> >>>> Compilation of parallelScavenge/vmPSOperations.cpp failed. >>>> >>>> Please review this tiny change. I also please need a sponsor. >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ >>>> >>>> >>>> >>> I understand that this is an easy fix, but I don't want >>> stack.inline.hpp to be added to the hpp file. The preferred fix would >>> be extract the offending push function out of the taskqueue.hpp file >>> and put it in a new file called taskqueue.inline.hpp. I created a RFE >>> for that a couple of weeks ago: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8076177 - Remove usage of >>> stack.inline.hpp functions from taskqueue.hpp >> Here's an example of what it would take to move the push functions out >> to taskqueue.inline.hpp. Only compiled locally on my machine. I had to >> move some functions from PSParallelCompact to ParCompactionManager to >> get rid of a circular dependency between the two classes. That would >> probably be done as a separate RFE. > And the link: > http://cr.openjdk.java.net/~stefank/8076177/webrev.poc.01 > > StefanK > >> >> StefanK >> >>> Until someone takes care about 8076177, could you workaround the >>> compile error by including stack.inline.hpp in vmPSOperations.cpp? Do >>> you know what in vmPSOperations.cpp depends on taskqueue.hpp? I can't >>> find anything, but I see that we include psScavenge.inline.hpp, which >>> includes taskqueue.hpp via psPromotionManager.inline.hpp and >>> psPromotionManager.hpp. Maybe you could workaround the problem by >>> removing the "#include .../psScavenge.inline.hpp" line, which isn't >>> needed by vmPSOperations.cpp? >>> >>> Thanks, >>> StefanK >>> >>>> Best regards, >>>> >>>> Goetz. >>>> From thomas.schatzl at oracle.com Tue Apr 21 14:26:25 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 21 Apr 2015 16:26:25 +0200 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC00E7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> <553620C3.7050501@oracle.com> <55363A02.4060008@oracle.com> <55363A2C.1080807@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC00E7@DEWDFEMB12A.global.corp.sap> Message-ID: <1429626385.3343.38.camel@oracle.com> Hi, On Tue, 2015-04-21 at 13:27 +0000, Lindenmaier, Goetz wrote: > Hi Stefan, > > removing the include of psScavenge.inline.hpp from vmPSOperations.cpp > helps. > This is not a real fix of the taskqueue issue, but fine with 8076177 coming up - especially > as it reduces dependencies and needs not be reverted with 8076177. > http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.02/ > looks good. Thomas From goetz.lindenmaier at sap.com Tue Apr 21 14:46:11 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Apr 2015 14:46:11 +0000 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <55365ED6.1020303@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> <553620C3.7050501@oracle.com> <55363A02.4060008@oracle.com> <55363A2C.1080807@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC00E7@DEWDFEMB12A.global.corp.sap> <55365ED6.1020303@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC0166@DEWDFEMB12A.global.corp.sap> Thanks for sponsoring! Best regards, Goetz. -----Original Message----- From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] Sent: Dienstag, 21. April 2015 16:30 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. On 2015-04-21 15:27, Lindenmaier, Goetz wrote: > Hi Stefan, > > removing the include of psScavenge.inline.hpp from vmPSOperations.cpp > helps. > This is not a real fix of the taskqueue issue, but fine with 8076177 coming up - especially > as it reduces dependencies and needs not be reverted with 8076177. > http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.02/ Looks good, I'll sponsor this. Thanks for using this workaround-fix. Thanks, StefanK > > Best regards, > Goetz. > > > > -----Original Message----- > From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] > Sent: Dienstag, 21. April 2015 13:53 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. > > > > On 2015-04-21 13:52, Stefan Karlsson wrote: >> On 2015-04-21 12:04, Stefan Karlsson wrote: >>> Hi Goetz, >>> >>> On 2015-04-21 10:20, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> another include that's missing. This time it breaks aix only, would >>>> not have been >>>> >>>> detected by non-pch build J >>>> >>>> taskqueue.hpp calls Stack::push(), thus it must include >>>> stack.inline.hpp. >>>> >>>> Compilation of parallelScavenge/vmPSOperations.cpp failed. >>>> >>>> Please review this tiny change. I also please need a sponsor. >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.01/ >>>> >>>> >>>> >>> I understand that this is an easy fix, but I don't want >>> stack.inline.hpp to be added to the hpp file. The preferred fix would >>> be extract the offending push function out of the taskqueue.hpp file >>> and put it in a new file called taskqueue.inline.hpp. I created a RFE >>> for that a couple of weeks ago: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8076177 - Remove usage of >>> stack.inline.hpp functions from taskqueue.hpp >> Here's an example of what it would take to move the push functions out >> to taskqueue.inline.hpp. Only compiled locally on my machine. I had to >> move some functions from PSParallelCompact to ParCompactionManager to >> get rid of a circular dependency between the two classes. That would >> probably be done as a separate RFE. > And the link: > http://cr.openjdk.java.net/~stefank/8076177/webrev.poc.01 > > StefanK > >> >> StefanK >> >>> Until someone takes care about 8076177, could you workaround the >>> compile error by including stack.inline.hpp in vmPSOperations.cpp? Do >>> you know what in vmPSOperations.cpp depends on taskqueue.hpp? I can't >>> find anything, but I see that we include psScavenge.inline.hpp, which >>> includes taskqueue.hpp via psPromotionManager.inline.hpp and >>> psPromotionManager.hpp. Maybe you could workaround the problem by >>> removing the "#include .../psScavenge.inline.hpp" line, which isn't >>> needed by vmPSOperations.cpp? >>> >>> Thanks, >>> StefanK >>> >>>> Best regards, >>>> >>>> Goetz. >>>> From goetz.lindenmaier at sap.com Tue Apr 21 14:46:32 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Apr 2015 14:46:32 +0000 Subject: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. In-Reply-To: <1429626385.3343.38.camel@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFBFF75@DEWDFEMB12A.global.corp.sap> <553620C3.7050501@oracle.com> <55363A02.4060008@oracle.com> <55363A2C.1080807@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC00E7@DEWDFEMB12A.global.corp.sap> <1429626385.3343.38.camel@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC0172@DEWDFEMB12A.global.corp.sap> Thanks Thomas! Best regards, Goetz. -----Original Message----- From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] Sent: Dienstag, 21. April 2015 16:26 To: Lindenmaier, Goetz Cc: Stefan Karlsson; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(XS): 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. Hi, On Tue, 2015-04-21 at 13:27 +0000, Lindenmaier, Goetz wrote: > Hi Stefan, > > removing the include of psScavenge.inline.hpp from vmPSOperations.cpp > helps. > This is not a real fix of the taskqueue issue, but fine with 8076177 coming up - especially > as it reduces dependencies and needs not be reverted with 8076177. > http://cr.openjdk.java.net/~goetz/webrevs/8078243-pchBld2/webrev.02/ > looks good. Thomas From aph at redhat.com Tue Apr 21 15:11:04 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Apr 2015 16:11:04 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1429608038.4116.13.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> Message-ID: <55366888.2040409@redhat.com> On 04/21/2015 10:20 AM, Edward Nevill wrote: > If everyone is happy with this patch could someone push it please, I'm a bit concerned about deoptimization. Here is a call to uncommon_trap before your patch: 308 strw R0, [sp, #0] # spill 30c + strw R24, [sp, #4] # spill 310 call,static 0x000003ffa807f080 // ==> wrapper for: uncommon_trap(reason='unstable_if' action='reinterpret') # Pressure::poo @ bci:482 L[0]=_ L[1]=_ L[2]=_ L[3]=_ L[4]=_ L[5]=_ L[6]=_ L[7]=_ L[8]=_ L[9]=_ L[10]=_ L[11]=_ L[12]=_ L[13]=_ L[14]=_ L[15]=_ L[16]=_ L[17]=_ L[18]=_ L[19]=_ L[20]=_ L[21]=_ L[22]=_ L[23]=sp + #0 STK[0]=sp + #4 and after: 300 movw R29, R0 # shuffle 304 + strw R25, [sp, #0] # spill 308 call,static 0x000003ffa807f080 // ==> wrapper for: uncommon_trap(reason='unstable_if' action='reinterpret') # Pressure::poo @ bci:482 L[0]=_ L[1]=_ L[2]=_ L[3]=_ L[4]=_ L[5]=_ L[6]=_ L[7]=_ L[8]=_ L[9]=_ L[10]=_ L[11]=_ L[12]=_ L[13]=_ L[14]=_ L[15]=_ L[16]=_ L[17]=_ L[18]=_ L[19]=_ L[20]=_ L[21]=_ L[22]=_ L[23]=R29 STK[0]=sp + #0 R29 (i.e. rfp) is marked Save-On-Entry. It is the only allocatable general-purpose register which is. I'm a bit worried that deoptimization might not restore this register correctly if it hasn't been spilled. Maybe we should mark R29 as SOC. On the other hand, if it does work it will be a nice performance improvement: there will be one less spill to the stack at most calls. But AFAIK deoptimization expects everything to be saved in the stack frame. Vladimir, is that right? Andrew. From aph at redhat.com Tue Apr 21 15:15:47 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Apr 2015 16:15:47 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <55366888.2040409@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> Message-ID: <553669A3.8070205@redhat.com> On 04/21/2015 04:11 PM, Andrew Haley wrote: > R29 (i.e. rfp) is marked Save-On-Entry. It is the only allocatable > general-purpose register which is. I'm a bit worried that > deoptimization might not restore this register correctly if it hasn't > been spilled. Maybe we should mark R29 as SOC. On the gripping hand, x86_64 marks RBP, RSI and RDI as SOE registers. So I think I'm worrying about nothing. Andrew. From vladimir.kozlov at oracle.com Tue Apr 21 17:03:33 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Apr 2015 10:03:33 -0700 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <553653E8.4020301@redhat.com> References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com> <553653E8.4020301@redhat.com> Message-ID: <553682E5.9000001@oracle.com> Would it help if we add a new flag to NodeFlags to indicate volatile memory node? Vladimir On 4/21/15 6:43 AM, Andrew Dinn wrote: > On 21/04/15 13:53, Andrew Haley wrote: >> On 04/20/2015 10:03 AM, Andrew Dinn wrote: >>> The following webrev is submitted for review (n.b. I am not an OpenJDK >>> committer so the patch does not yet have an associated JIRA). >> >> The patch looks good to me. >> >> https://bugs.openjdk.java.net/browse/JDK-8078263 > > A new webrev with the commit in standard format (listing JIRA#, sumamry > and reviewer) and placed at: > > http://cr.openjdk.java.net/~adinn/8078263/webrev.01/ > > regards, > > > Andrew Dinn > ----------- > From coleen.phillimore at oracle.com Tue Apr 21 18:08:47 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 21 Apr 2015 14:08:47 -0400 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <5535A85D.101@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> <5535A85D.101@oracle.com> Message-ID: <5536922F.3030204@oracle.com> On 4/20/15, 9:31 PM, David Holmes wrote: > On 21/04/2015 10:14 AM, Volker Simonis wrote: >> Hi Coleen, >> >> the default is not to use PCH and I think that's probably OK for most >> people. If somebody plays with the include files, he should use the >> '--disable-precompiled-headers' configure option. > > The default depends on platform. For solaris we never use PCH. For the > other platforms I think we always do. Yes, my motivation with this comment is that instead of adding JPRT targets or more work to do in JPRT is to simply make linux x64 at least default to non-PCH. It would break less frequently because that's the default and the side benefit is that when you're working and editing a header file, you don't get the whole JVM recompiled. IE. I would prefer if this were the default so I don't have to add yet another option to my configure script. > > Simply switching the default just creates a different problem. > Engineers will use PCH locally and so may encounter issues if PCH has > not been tested at integration time. > It seems that the converse is more likely though. If something compiles without PCH it's very likely to compile with PCH. I'd prefer the default changed and not find whether I broke PCH with JPRT. thanks, Coleen > I plan to fix this in JPRT by making a few configurations non-PCH. > > David > ----- > >> Making this option the default for the JPRT builds only will guard >> against the build errors described before while it still allows >> everybody to do local builds at full speed. >> >> Regards, >> Volker >> >> On 4/21/15, Coleen Phillimore wrote: >>> >>> Can we just switch the default instead? Is that a simple makefile >>> change? >>> Coleen >>> >>> On 4/17/15, 6:35 AM, Lindenmaier, Goetz wrote: >>>> That would be great!! >>>> >>>> Thanks David, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Freitag, 17. April 2015 12:23 >>>> To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn >>>> Cc: HotSpot Open Source Developers >>>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >>>> >>>> On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> another occurance of this ... please, please add a non-pch build to >>>>> jprt! >>>>> https://bugs.openjdk.java.net/browse/JDK-8078048 >>>> I will. Unfortunately first I have some no-PCH issues to address. And >>>> unfortunately they are not top of my priority list right now. >>>> Hopefully >>>> next week sometime. >>>> >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>> Behalf >>>>> Of Volker Simonis >>>>> Sent: Donnerstag, 9. April 2015 11:35 >>>>> To: Andrew Dinn >>>>> Cc: HotSpot Open Source Developers >>>>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >>>>> >>>>> On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn >>>>> wrote: >>>>>> On 09/04/15 09:02, Erik Joelsson wrote: >>>>>>> I think that as long as we claim to support building both with and >>>>>>> without PCH, the automatic testing should test both with and >>>>>>> without >>>>>>> PCH. By adding one or two build targets, or perhaps change an >>>>>>> existing >>>>>>> target, we could increase our test matrix to cover this easily. >>>>>> I think this restates Volker's original remarks in redux. >>>>>> >>>>> No, not at all! I don't necessarily want to test more build >>>>> configurations (that's another topic). >>>>> >>>>> My point is that PCH changes the compilation semantics and can hide >>>>> real program errors. That's because with PCHs, every compilation unit >>>>> sees the full precompiled header database (i.e. all the headers which >>>>> are included in the "precompiled.hpp" PCH file). So if somebody >>>>> forgets to include a dependency X.hpp in A.cpp, A.cpp may still >>>>> compile with PCH because it includes the precompiled header file >>>>> "precompiled.hpp" which in turn includes X.hpp. But the >>>>> compilation of >>>>> A.cpp will fail on platforms/configurations where we do not use >>>>> precompiled headers. The two references I gave in my original mail >>>>> are >>>>> bugs that resulted from this problem. >>>>> >>>>> Besides program errors, the use of PCH can also lead to behavioral >>>>> changes in the created binary when it comes to inlining. Because of >>>>> PCHs some compilation units may be able to inline methods even if >>>>> they >>>>> do not explicitly include the files which contain the corresponding >>>>> implementations because the implementation files are included in the >>>>> PCH file. Without PCHs the compilers will simply emit calls to these >>>>> functions (and, depending on the toolchain, emit a warning). >>>>> >>>>> I'm not familiar with ccache so I can not say if it has similar >>>>> effects. >>>>> >>>>>> So, given that we do need this (NOW! :-) is anyone able and >>>>>> willing to >>>>>> sponsor this? >>>>>> >>>>> Yes, this question remains to be answered :) >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>>> regards, >>>>>> >>>>>> >>>>>> Andrew Dinn >>>>>> ----------- >>>>>> >>> >>> From aleksey.shipilev at oracle.com Tue Apr 21 18:18:22 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 21 Apr 2015 21:18:22 +0300 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <553682E5.9000001@oracle.com> References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com> <553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com> Message-ID: <5536946E.6020809@oracle.com> There is also a pending idea for x86: try to replace volatile stores with "xchg", instead of "mov + lock addl". It would be nice to make sure the way AArch64 does the replacement would help the future x86 code. Thanks, -Aleksey On 21.04.2015 20:03, Vladimir Kozlov wrote: > Would it help if we add a new flag to NodeFlags to indicate volatile > memory node? > > Vladimir > > On 4/21/15 6:43 AM, Andrew Dinn wrote: >> On 21/04/15 13:53, Andrew Haley wrote: >>> On 04/20/2015 10:03 AM, Andrew Dinn wrote: >>>> The following webrev is submitted for review (n.b. I am not an OpenJDK >>>> committer so the patch does not yet have an associated JIRA). >>> >>> The patch looks good to me. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8078263 >> >> A new webrev with the commit in standard format (listing JIRA#, sumamry >> and reviewer) and placed at: >> >> http://cr.openjdk.java.net/~adinn/8078263/webrev.01/ >> >> regards, >> >> >> Andrew Dinn >> ----------- >> From vladimir.x.ivanov at oracle.com Tue Apr 21 18:30:55 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 21 Apr 2015 21:30:55 +0300 Subject: [9] RFR (S): 8059340: ConstantPool::_resolved_references is missing in heap dump In-Reply-To: <21C42551-29AA-44DC-AFE5-6156D681503D@oracle.com> References: <542971DC.2090803@oracle.com> <24133E27-C024-41D8-80EF-B5707CFF0D0C@oracle.com> <552FFBAA.6050103@oracle.com> <55358D0A.1020407@oracle.com> <21C42551-29AA-44DC-AFE5-6156D681503D@oracle.com> Message-ID: <5536975F.60108@oracle.com> Coleen, Chris, I'll proceed with moving ConstantPool::_resolved_references to j.l.Class instance then. Thanks for the feedback. Best regards, Vladimir Ivanov On 4/21/15 3:22 AM, Christian Thalinger wrote: > >> On Apr 20, 2015, at 4:34 PM, Coleen Phillimore >> > >> wrote: >> >> >> Vladimir, >> >> I think that changing the format of the heap dump isn't a good idea >> either. >> >> On 4/16/15, 2:12 PM, Vladimir Ivanov wrote: >>> (sorry for really late response; just got enough time to return to >>> the bug) >> >> I'd forgotten about it! >>> >>> Coleen, Staffan, >>> >>> Thanks a lot for the feedback! >>> >>> After thinking about the fix more, I don't think that using reserved >>> oop slot in CLASS DUMP for recording _resolved_references is the best >>> thing to do. IMO the change causes too much work for the users (heap >>> dump analysis tools). >>> >>> It needs specification update and then heap dump analyzers should be >>> updated as well. >>> >>> I have 2 alternative approaches (hacky and not-so-hacky :-)): >>> >>> - artificial class static field in the dump ("" >>> + optional id to guarantee unique name); >>> >>> - add j.l.Class::_resolved_references field; >>> Not sure how much overhead (mostly reads from bytecode) the move >>> from ConstantPool to j.l.Class adds, so I propose just to duplicate >>> it for now. >> >> I really like this second approach, so much so that I had a prototype >> for moving resolved_references directly to the j.l.Class object about >> a year ago. I couldn't find any benefit other than consolidating oops >> so the GC would have less work to do. If the resolved_references are >> moved to j.l.C instance, they can not be jobjects and the >> ClassLoaderData::_handles area wouldn't have to contain them (but >> there are other things that could go there so don't delete the >> _handles field yet). >> >> The change I had was relatively simple. The only annoying part was >> that getting to the resolved references has to be in macroAssembler >> and do: >> >> go through method->cpCache->constants->instanceKlass->java_mirror() >> rather than >> method->cpCache->constants->resolved_references->jmethod indirection >> >> I think it only affects the interpreter so the extra indirection >> wouldn't affect performance, so don't duplicate it! You don't want to >> increase space used by j.l.C without taking it out somewhere else! > > I like this approach. Can we do this? > >> >>> >>> What do you think about that? >> >> Is this bug worth doing this? I don't know but I'd really like it. >> >> Coleen >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/6/14 11:35 AM, Staffan Larsen wrote: >>>> This looks like a good approach. However, there are a couple of more >>>> places that need to be updated. >>>> >>>> The hprof binary format is described in >>>> jdk/src/jdk.hprof.agent/share/native/libhprof/manual.html and needs >>>> to be updated. It?s also more formally specified in hprof_b_spec.h >>>> in the same directory. >>>> >>>> The hprof JVMTI agent in jdk/src/jdk.hprof.agent code would also >>>> need to be updated to show this field. Since this is a JVMTI agent >>>> it needs to be possible to find the resolved_refrences array via the >>>> JVMTI heap walking API. Perhaps that already works? - I haven?t looked. >>>> >>>> Finally, the Serviceability Agent implements yet another hprof >>>> binary dumper in >>>> hotspot/agent//src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java >>>> which also needs to write this reference. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 29 sep 2014, at 16:51, Vladimir Ivanov >>>> > >>>> wrote: >>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8059340/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8059340 >>>>> >>>>> VM heap dump doesn't contain ConstantPool::_resolved_references for >>>>> classes which have resolved references. >>>>> >>>>> ConstantPool::_resolved_references points to an Object[] holding >>>>> resolved constant pool entries (patches for VM anonymous classes, >>>>> linked CallSite & MethodType for invokedynamic instructions). >>>>> >>>>> I've decided to use reserved slot in HPROF class header format. >>>>> It requires an update in jhat to correctly display new info. >>>>> >>>>> The other approach I tried was to dump the reference as a fake >>>>> static field [1], but storing VM internal >>>>> ConstantPool::_resolved_references among user defined fields looks >>>>> confusing. >>>>> >>>>> Testing: manual (verified that corresponding arrays are properly >>>>> linked in Nashorn heap dump). >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] http://cr.openjdk.java.net/~vlivanov/8059340/static > From john.r.rose at oracle.com Tue Apr 21 18:54:57 2015 From: john.r.rose at oracle.com (John Rose) Date: Tue, 21 Apr 2015 11:54:57 -0700 Subject: [9] RFR (S): 8059340: ConstantPool::_resolved_references is missing in heap dump In-Reply-To: <5536975F.60108@oracle.com> References: <542971DC.2090803@oracle.com> <24133E27-C024-41D8-80EF-B5707CFF0D0C@oracle.com> <552FFBAA.6050103@oracle.com> <55358D0A.1020407@oracle.com> <21C42551-29AA-44DC-AFE5-6156D681503D@oracle.com> <5536975F.60108@oracle.com> Message-ID: <3A7B6B10-CB7B-4A21-8284-E9B7A6F2263C@oracle.com> On Apr 21, 2015, at 11:30 AM, Vladimir Ivanov wrote: > > I'll proceed with moving ConstantPool::_resolved_references to j.l.Class instance then. My $0.02: This feels right. I assume the RR array continues to be an Object[]. ? John From dean.long at oracle.com Tue Apr 21 19:17:48 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 21 Apr 2015 12:17:48 -0700 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <553669A3.8070205@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> Message-ID: <5536A25C.7060402@oracle.com> On 4/21/2015 8:15 AM, Andrew Haley wrote: > On 04/21/2015 04:11 PM, Andrew Haley wrote: >> R29 (i.e. rfp) is marked Save-On-Entry. It is the only allocatable >> general-purpose register which is. I'm a bit worried that >> deoptimization might not restore this register correctly if it hasn't >> been spilled. Maybe we should mark R29 as SOC. > On the gripping hand, x86_64 marks RBP, RSI and RDI as SOE registers. > So I think I'm worrying about nothing. > > Andrew. > Does frame::update_map_with_saved_link() take care of R29 if it hasn't been explicitly spilled? If so, R29 could probably remain marked as NS like before. dl From christian.tornqvist at oracle.com Tue Apr 21 21:51:10 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 21 Apr 2015 17:51:10 -0400 Subject: RFR(S): 8077529 - [TESTBUG] Remove hotspot.internalvmtests from jprt config Message-ID: <01da01d07c7d$47c9ad20$d75d0760$@oracle.com> Hi, Please review this small change that removes the internalvmtests test target from JPRT, these tests are already run numerous times by hotspot/test/sanity/ExecuteInternalVMTests.java in the different jtreg test targets. The time savings from this change ranges from 30sec to 10min per platform. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8077529/webrev.00.root/ http://cr.openjdk.java.net/~ctornqvi/webrev/8077529/webrev.00.hotspot/ Bug: https://bugs.openjdk.java.net/browse/JDK-8077529 Thanks, Christian From mikael.vidstedt at oracle.com Tue Apr 21 21:54:09 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 21 Apr 2015 14:54:09 -0700 Subject: RFR(S): 8077529 - [TESTBUG] Remove hotspot.internalvmtests from jprt config In-Reply-To: <01da01d07c7d$47c9ad20$d75d0760$@oracle.com> References: <01da01d07c7d$47c9ad20$d75d0760$@oracle.com> Message-ID: <5536C701.3040702@oracle.com> Looks good, thanks for fixing this! Cheers, Mikael On 2015-04-21 14:51, Christian Tornqvist wrote: > Hi, > > > > Please review this small change that removes the internalvmtests test target > from JPRT, these tests are already run numerous times by > hotspot/test/sanity/ExecuteInternalVMTests.java in the different jtreg test > targets. > > > > The time savings from this change ranges from 30sec to 10min per platform. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8077529/webrev.00.root/ > > http://cr.openjdk.java.net/~ctornqvi/webrev/8077529/webrev.00.hotspot/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8077529 > > > > Thanks, > > Christian > From daniel.daugherty at oracle.com Wed Apr 22 02:01:43 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Apr 2015 20:01:43 -0600 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <5536922F.3030204@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> <5535A85D.101@oracle.com> <5536922F.3030204@oracle.com> Message-ID: <55370107.6010207@oracle.com> Magnus put this comment in the bug report about two weeks ago: > Is it possible to compile e.g. product builds with PCH and debug > builds without, or vice versa? The impact of not using PCH will be > not so great (since it's still used in 50% of the jobs), and we > will get automatic testing both with and without PCH. David H followed with this comment: > Certainly possible, but it won't give complete coverage of course > (but nothing practical will give complete coverage). > > Quickest fix for JPRT may be to just disable PCH for the embedded > builds: product x86, fastdebug arm, to cover linux and minimal VM. > Maybe throw in a couple of Windows builds (one product, one > fastdebug) for good measure? Personally, I like the idea of not adding any more new JPRT targets and reconfiguring to have fastdebug and/or debug builds run as non-PCH... It's a much simpler policy to explain: If we support PCH builds with a particular toolset then product builds default to PCH and non-product builds default to no-PCH. Dan On 4/21/15 12:08 PM, Coleen Phillimore wrote: > > On 4/20/15, 9:31 PM, David Holmes wrote: >> On 21/04/2015 10:14 AM, Volker Simonis wrote: >>> Hi Coleen, >>> >>> the default is not to use PCH and I think that's probably OK for most >>> people. If somebody plays with the include files, he should use the >>> '--disable-precompiled-headers' configure option. >> >> The default depends on platform. For solaris we never use PCH. For >> the other platforms I think we always do. > > Yes, my motivation with this comment is that instead of adding JPRT > targets or more work to do in JPRT is to simply make linux x64 at > least default to non-PCH. It would break less frequently because > that's the default and the side benefit is that when you're working > and editing a header file, you don't get the whole JVM recompiled. IE. > I would prefer if this were the default so I don't have to add yet > another option to my configure script. > >> >> Simply switching the default just creates a different problem. >> Engineers will use PCH locally and so may encounter issues if PCH has >> not been tested at integration time. >> > > It seems that the converse is more likely though. If something > compiles without PCH it's very likely to compile with PCH. > > I'd prefer the default changed and not find whether I broke PCH with > JPRT. > > thanks, > Coleen > >> I plan to fix this in JPRT by making a few configurations non-PCH. >> >> David >> ----- >> >>> Making this option the default for the JPRT builds only will guard >>> against the build errors described before while it still allows >>> everybody to do local builds at full speed. >>> >>> Regards, >>> Volker >>> >>> On 4/21/15, Coleen Phillimore wrote: >>>> >>>> Can we just switch the default instead? Is that a simple makefile >>>> change? >>>> Coleen >>>> >>>> On 4/17/15, 6:35 AM, Lindenmaier, Goetz wrote: >>>>> That would be great!! >>>>> >>>>> Thanks David, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Freitag, 17. April 2015 12:23 >>>>> To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn >>>>> Cc: HotSpot Open Source Developers >>>>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >>>>> >>>>> On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> another occurance of this ... please, please add a non-pch build to >>>>>> jprt! >>>>>> https://bugs.openjdk.java.net/browse/JDK-8078048 >>>>> I will. Unfortunately first I have some no-PCH issues to address. And >>>>> unfortunately they are not top of my priority list right now. >>>>> Hopefully >>>>> next week sometime. >>>>> >>>>> David >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] >>>>>> On Behalf >>>>>> Of Volker Simonis >>>>>> Sent: Donnerstag, 9. April 2015 11:35 >>>>>> To: Andrew Dinn >>>>>> Cc: HotSpot Open Source Developers >>>>>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >>>>>> >>>>>> On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn >>>>>> wrote: >>>>>>> On 09/04/15 09:02, Erik Joelsson wrote: >>>>>>>> I think that as long as we claim to support building both with and >>>>>>>> without PCH, the automatic testing should test both with and >>>>>>>> without >>>>>>>> PCH. By adding one or two build targets, or perhaps change an >>>>>>>> existing >>>>>>>> target, we could increase our test matrix to cover this easily. >>>>>>> I think this restates Volker's original remarks in redux. >>>>>>> >>>>>> No, not at all! I don't necessarily want to test more build >>>>>> configurations (that's another topic). >>>>>> >>>>>> My point is that PCH changes the compilation semantics and can hide >>>>>> real program errors. That's because with PCHs, every compilation >>>>>> unit >>>>>> sees the full precompiled header database (i.e. all the headers >>>>>> which >>>>>> are included in the "precompiled.hpp" PCH file). So if somebody >>>>>> forgets to include a dependency X.hpp in A.cpp, A.cpp may still >>>>>> compile with PCH because it includes the precompiled header file >>>>>> "precompiled.hpp" which in turn includes X.hpp. But the >>>>>> compilation of >>>>>> A.cpp will fail on platforms/configurations where we do not use >>>>>> precompiled headers. The two references I gave in my original >>>>>> mail are >>>>>> bugs that resulted from this problem. >>>>>> >>>>>> Besides program errors, the use of PCH can also lead to behavioral >>>>>> changes in the created binary when it comes to inlining. Because of >>>>>> PCHs some compilation units may be able to inline methods even if >>>>>> they >>>>>> do not explicitly include the files which contain the corresponding >>>>>> implementations because the implementation files are included in the >>>>>> PCH file. Without PCHs the compilers will simply emit calls to these >>>>>> functions (and, depending on the toolchain, emit a warning). >>>>>> >>>>>> I'm not familiar with ccache so I can not say if it has similar >>>>>> effects. >>>>>> >>>>>>> So, given that we do need this (NOW! :-) is anyone able and >>>>>>> willing to >>>>>>> sponsor this? >>>>>>> >>>>>> Yes, this question remains to be answered :) >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>>> regards, >>>>>>> >>>>>>> >>>>>>> Andrew Dinn >>>>>>> ----------- >>>>>>> >>>> >>>> > > > From aph at redhat.com Wed Apr 22 07:57:43 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Apr 2015 08:57:43 +0100 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <55370107.6010207@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> <5535A85D.101@oracle.com> <5536922F.3030204@oracle.com> <55370107.6010207@oracle.com> Message-ID: <55375477.7020804@redhat.com> On 22/04/15 03:01, Daniel D. Daugherty wrote: > Personally, I like the idea of not adding any more new JPRT targets > and reconfiguring to have fastdebug and/or debug builds run as non-PCH... > It's a much simpler policy to explain: > > If we support PCH builds with a particular toolset then product > builds default to PCH and non-product builds default to no-PCH. But the debug builds are used in development all the time. It's these that really benefit from PCH. Andrew. From adinn at redhat.com Wed Apr 22 09:00:08 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 22 Apr 2015 10:00:08 +0100 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <553682E5.9000001@oracle.com> References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com> <553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com> Message-ID: <55376318.7070604@redhat.com> Hi Vladimir, Thanks for responding. On 21/04/15 18:03, Vladimir Kozlov wrote: > Would it help if we add a new flag to NodeFlags to indicate volatile > memory node? Yes, I think this would provide some benefit although I don't know if it will justify cost of implementing and testing the necessary shared code changes given that the benefit is only partial. Even with such a flag we would still need to do some of the work that this patch does. Also, the flag would not help with a the next optimization we are planning (removing unnecessary barriers from CAS sequences). Your suggestion will /simplify/ the predicates for LoadX/StoreX but will not make much difference to execution time. The current predicates for these nodes, needs_acquiring_load() and needs_releasing_store(), check immediately whether a LoadX is acquiring or a StoreX is releasing. So, we have a quick filter for the /common path/ case where we simply generate an ldr or stlr (I assume volatile ops are relatively rare). However, we cannot rely solely on these existing flags as they are sometimes set in other (non-volatile) cases. Currently, if the acquiring or releasing flag is set the predicates go on to investigate the nodes around the LoadX/StoreX looking for a specific configuration of MemBar_XXX nodes. Adding the volatile flag would remove the need to do this extra work in the /uncommon/ case. Unfortunately, the other half of the patch involves eliding generation of dmb instructions for the MemBar_XXX nodes associated with the a LoadX or StoreX. Three other predicates are used for this purpose, unnecesary_membar_acquire, unnecesary_membar_release and unnecesary_membar_volatile. They search the ideal graph around the membar to see whether it belongs to a signature sequence containing an acquiring load or releasing store. The check involves i) finding a related LoadX or StoreX, ii) checking it is acquiring or releasing and ii) ensuring it is either tailed or bracketed by a node group with a 'signature' shape which includes the MemBar we started from. A volatile flag would not really speed up this check and would not do much to simplify it. The current predicates test for very specific signature configurations. So, in cases where the MemBar node is /not/ part of a signature volatile sequence they detect this very rapidly. In the common case the predicate immediately fails to find the required sort of parent/child node in the tree surrounding the initial MemBar (i.e. one which is not a LoadX/StoreX, Proj or MemBar). If we do arrive at a LoadX/StoreX in the node tree we could, perhaps, check the volatile flag and short-circuit any further graph traversal but the bulk of the work involves traversing from the initial MemBar to the LoadX/StoreX. n.b. I say perhaps because I am not yet certain that we just test the volatile flag. I don't know for sure that we could not arrive at the memory node from a MemBar which was not part of the signature sequence (I /am/ very confident that the current checks correctly identify volatile node sequences and only those sequences). Could we punt this question of providing the volatile flag, considering it as a potential follow-up improvement? I'd prefer to get this AArch64-only change in as is -- or, at least, with some tweaking -- before going on to consider something which requires changes to shared code. Also, I mentioned the CAS case above because that is what I am looking at next and it extends the technique used in the current patch. Currently CAS operations translate to something which looks like this dmb ... retry: ldaxr ... stlxr cbz retry ... dmb The ldaxr/stlxr pair are generated in response to a CompareAndSwapX node and the dmb instructions arise from MemBar nodes. For a CAS AArch64 can safely elide the dmb instructions. So, the next improvement will be to extend the unnecessary_membar_xxx predicates to elide the dmb generation when a suitable configuration of MemBar_XXX and CompareAndSwapX nodes is seen. Of course, this test will not be helped at all by provision of a volatile flag. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From adinn at redhat.com Wed Apr 22 09:05:02 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 22 Apr 2015 10:05:02 +0100 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <55376318.7070604@redhat.com> References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com> <553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com> <55376318.7070604@redhat.com> Message-ID: <5537643E.5070404@redhat.com> On 22/04/15 10:00, Andrew Dinn wrote: > Hi Vladimir, > > Thanks for responding. > > On 21/04/15 18:03, Vladimir Kozlov wrote: >> Would it help if we add a new flag to NodeFlags to indicate volatile >> memory node? > > Yes, I think this would provide some benefit although I don't know if it > will justify cost of implementing and testing the necessary shared code > changes given that the benefit is only partial. Even with such a flag we > would still need to do some of the work that this patch does. Also, the > flag would not help with a the next optimization we are planning > (removing unnecessary barriers from CAS sequences). > > Your suggestion will /simplify/ the predicates for LoadX/StoreX but will > not make much difference to execution time. The current predicates for > these nodes, needs_acquiring_load() and needs_releasing_store(), check > immediately whether a LoadX is acquiring or a StoreX is releasing. So, > we have a quick filter for the /common path/ case where we simply > generate an ldr or stlr (I assume volatile ops are relatively rare). oops ldr or str !!! > However, we cannot rely solely on these existing flags as they are > sometimes set in other (non-volatile) cases. Currently, if the acquiring > or releasing flag is set the predicates go on to investigate the nodes > around the LoadX/StoreX looking for a specific configuration of > MemBar_XXX nodes. Adding the volatile flag would remove the need to do > this extra work in the /uncommon/ case. > > Unfortunately, the other half of the patch involves eliding generation > of dmb instructions for the MemBar_XXX nodes associated with the a LoadX > or StoreX. Three other predicates are used for this purpose, > unnecesary_membar_acquire, unnecesary_membar_release and > unnecesary_membar_volatile. They search the ideal graph around the > membar to see whether it belongs to a signature sequence containing an > acquiring load or releasing store. > > The check involves i) finding a related LoadX or StoreX, ii) checking it > is acquiring or releasing and ii) ensuring it is either tailed or > bracketed by a node group with a 'signature' shape which includes the > MemBar we started from. A volatile flag would not really speed up this > check and would not do much to simplify it. > > The current predicates test for very specific signature configurations. > So, in cases where the MemBar node is /not/ part of a signature volatile > sequence they detect this very rapidly. In the common case the predicate > immediately fails to find the required sort of parent/child node in the > tree surrounding the initial MemBar (i.e. one which is not a > LoadX/StoreX, Proj or MemBar). If we do arrive at a LoadX/StoreX in the > node tree we could, perhaps, check the volatile flag and short-circuit > any further graph traversal but the bulk of the work involves traversing > from the initial MemBar to the LoadX/StoreX. > > n.b. I say perhaps because I am not yet certain that we just test the > volatile flag. I don't know for sure that we could not arrive at the > memory node from a MemBar which was not part of the signature sequence > (I /am/ very confident that the current checks correctly identify > volatile node sequences and only those sequences). > > Could we punt this question of providing the volatile flag, considering > it as a potential follow-up improvement? I'd prefer to get this > AArch64-only change in as is -- or, at least, with some tweaking -- > before going on to consider something which requires changes to shared code. > > Also, I mentioned the CAS case above because that is what I am looking > at next and it extends the technique used in the current patch. > Currently CAS operations translate to something which looks like this > > dmb > ... > retry: > ldaxr > ... > stlxr > cbz retry > ... > dmb > > The ldaxr/stlxr pair are generated in response to a CompareAndSwapX node > and the dmb instructions arise from MemBar nodes. For a CAS AArch64 can > safely elide the dmb instructions. So, the next improvement will be to > extend the unnecessary_membar_xxx predicates to elide the dmb generation > when a suitable configuration of MemBar_XXX and CompareAndSwapX nodes is > seen. Of course, this test will not be helped at all by provision of a > volatile flag. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From staffan.larsen at oracle.com Wed Apr 22 09:08:27 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 11:08:27 +0200 Subject: RFR(S): 8077529 - [TESTBUG] Remove hotspot.internalvmtests from jprt config In-Reply-To: <01da01d07c7d$47c9ad20$d75d0760$@oracle.com> References: <01da01d07c7d$47c9ad20$d75d0760$@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 21 apr 2015, at 23:51, Christian Tornqvist wrote: > > Hi, > > > > Please review this small change that removes the internalvmtests test target > from JPRT, these tests are already run numerous times by > hotspot/test/sanity/ExecuteInternalVMTests.java in the different jtreg test > targets. > > > > The time savings from this change ranges from 30sec to 10min per platform. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8077529/webrev.00.root/ > > http://cr.openjdk.java.net/~ctornqvi/webrev/8077529/webrev.00.hotspot/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8077529 > > > > Thanks, > > Christian > From adinn at redhat.com Wed Apr 22 09:12:10 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 22 Apr 2015 10:12:10 +0100 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <5536946E.6020809@oracle.com> References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com> <553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com> <5536946E.6020809@oracle.com> Message-ID: <553765EA.5060009@redhat.com> On 21/04/15 19:18, Aleksey Shipilev wrote: > There is also a pending idea for x86: try to replace volatile > stores with "xchg", instead of "mov + lock addl". It would be nice > to make sure the way AArch64 does the replacement would help the > future x86 code. I don't know for sure if this is going to be susceptible to the same sort of implementation as I have provided but I think it is very likely. As I understand it the x86 code generates the lock addl instruction in response to a MemBarVolatile node. So, a predicate something like the one I provided could be used to identify that the MemBarVolatile belongs to a volatile load or store and hence that the lock addl can be elided. Similarly, I suspect the rules which generate the mov for normal stores could probably be duplicated and a lower cost variant could use a predicate similar to my needs_releasing_store() and plant an xchg instead of a mov if the predicate decided the store was volatile. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From aph at redhat.com Wed Apr 22 09:15:44 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Apr 2015 10:15:44 +0100 Subject: RFR: 8076488: AARCH64: jdk9 fails to build from source In-Reply-To: <55313E22.1000800@redhat.com> References: <1427905684.1631.12.camel@mylittlepony.linaroharston> <551C300D.2090005@oracle.com> <5530D3D2.5090505@redhat.com> <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com> <5530D501.1010004@redhat.com> <5530D5A7.90105@redhat.com> <553139CB.8090303@oracle.com> <55313E22.1000800@redhat.com> Message-ID: <553766C0.1000007@redhat.com> On 04/17/2015 06:08 PM, Andrew Haley wrote: > On 04/17/2015 05:50 PM, Vladimir Kozlov wrote: >> > Ah, no I won't. My patch already fixed this, and (IMO) in a much better >> > way. This patch is already in jprt, and will emerge soon, I hope. >> >> Andrew, do you mean the change pushed few days ago as part of 8077615 changes?: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2a6c4bd248cf > > Yes. How does this work? Is it that changes are pushed to hs-comp (by JPRT?) tested, and then manually merged at some point in the future? I'm thinking about the workflow. It's now Apr 22, and the patch "Intrinsify ByteBuffer.put" went into hs-comp on Mar 31. This seems like a very long time to wait while developing. It's particularly awkward if we have a bug which breaks the build. I'm not asking for anything to be changed, just trying to understand how I (and other external contributors) should best interact with the HotSpot workflow. Thanks, Andrew. From yekaterina.kantserova at oracle.com Wed Apr 22 09:17:10 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 22 Apr 2015 11:17:10 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests Message-ID: <55376716.10806@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8059047 webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. The old jhat packages have been moved as follows: com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util The source has not been changed except Copyrights year. Thanks, Katja From goetz.lindenmaier at sap.com Wed Apr 22 09:34:49 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 22 Apr 2015 09:34:49 +0000 Subject: RFR(L): 8077838: Recent developments for ppc. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> Hi, this change contains recent changes in the ppc directory mostly made by SAP. It's a ppc-only change. http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ - Recognition of Power 8 processors (by Tiago Sturmer Daitx). - Support for more new Power 8 instructions. - Support for transactional memory. This is implemented but not yet tested thoroughly due to limitiations of the OS support. Not enabled. - java.lang.math.*Exact intrinsics - Some C2 optimizations and fixes: * Handling of flag registers. Some instructions would lead to uncompilable methods due to not allocatable register patterns. * Free some integer registers to use them for allocation. Handle compressed oops base as constant. * Unscaled class compression. - Type profiling fixes. Please review this change. Best regards, Goetz. From edward.nevill at linaro.org Wed Apr 22 09:40:57 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 22 Apr 2015 10:40:57 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5536A25C.7060402@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> Message-ID: <1429695657.29680.7.camel@mylittlepony.linaroharston> On Tue, 2015-04-21 at 12:17 -0700, Dean Long wrote: > On 4/21/2015 8:15 AM, Andrew Haley wrote: > > On 04/21/2015 04:11 PM, Andrew Haley wrote: > >> R29 (i.e. rfp) is marked Save-On-Entry. It is the only allocatable > >> general-purpose register which is. I'm a bit worried that > >> deoptimization might not restore this register correctly if it hasn't > >> been spilled. Maybe we should mark R29 as SOC. > > On the gripping hand, x86_64 marks RBP, RSI and RDI as SOE registers. > > So I think I'm worrying about nothing. > > > > Andrew. > > > > Does frame::update_map_with_saved_link() take care of R29 if it hasn't > been explicitly spilled? If so, R29 could probably remain marked as NS > like before. Hi Dean, Yes, update_map_with_saved_link does take care of R29 and I have stepped through it in gdb to ensure that link_addr is in fact pointing at the saved fp. I made R29 SOE rather than NS because I simply copied what was done on x86 where RBP is marked as SOE. I don't believe it makes any difference to the code generation since we don't support callee saved registers, therefore it won't attempt to save R29 on entry even if it is marked as SOE. However, it may be clearer to mark it as NS. If there is no other feedback shall I prepare a revised patch with R29 marked NS? All the best, Ed. From aph at redhat.com Wed Apr 22 09:54:26 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Apr 2015 10:54:26 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1429695657.29680.7.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> Message-ID: <55376FD2.5000403@redhat.com> On 04/22/2015 10:40 AM, Edward Nevill wrote: > Yes, update_map_with_saved_link does take care of R29 and I have > stepped through it in gdb to ensure that link_addr is in fact > pointing at the saved fp. > > I made R29 SOE rather than NS because I simply copied what was done > on x86 where RBP is marked as SOE. > > I don't believe it makes any difference to the code generation since > we don't support callee saved registers, therefore it won't attempt > to save R29 on entry even if it is marked as SOE. However, it may be > clearer to mark it as NS. > > If there is no other feedback shall I prepare a revised patch with > R29 marked NS? I really want to understand this properly. Are we sure that when deoptimization happens (or when the stack is scanned for GC roots during a safepoint) the R29 saved by our callee (which may be native code) will be correctly processed? As I understand it, garbage collection would have to rewrite the R29 saved by a native code prologue for this to work. But we don't even know where in the frame native functions save FP, so I don't see how this can possibly work. Andrew. From staffan.larsen at oracle.com Wed Apr 22 11:20:15 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 13:20:15 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <55376716.10806@oracle.com> References: <55376716.10806@oracle.com> Message-ID: <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> Looks good! Thanks, /Staffan > On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8059047 > webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ > > This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. > > The old jhat packages have been moved as follows: > com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model > com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser > com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util > > The source has not been changed except Copyrights year. > > Thanks, > Katja From yekaterina.kantserova at oracle.com Wed Apr 22 12:25:05 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 22 Apr 2015 14:25:05 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> Message-ID: <55379321.1090403@oracle.com> Staffan, thank you for the review! This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. // Katja On 04/22/2015 01:20 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >> >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >> >> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >> >> The old jhat packages have been moved as follows: >> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >> >> The source has not been changed except Copyrights year. >> >> Thanks, >> Katja From staffan.larsen at oracle.com Wed Apr 22 13:05:03 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 15:05:03 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <55379321.1090403@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> Message-ID: <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> I think you are missing a "@build jdk.test.lib.hprof..*?. /Staffan > On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote: > > Staffan, thank you for the review! > > This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. > > // Katja > > > > On 04/22/2015 01:20 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >>> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>> >>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>> >>> The old jhat packages have been moved as follows: >>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>> >>> The source has not been changed except Copyrights year. >>> >>> Thanks, >>> Katja > From staffan.larsen at oracle.com Wed Apr 22 13:06:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 15:06:53 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> Message-ID: I also found this test that uses jhat and needs an update: com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh /Staffan > On 22 apr 2015, at 15:05, Staffan Larsen wrote: > > I think you are missing a "@build jdk.test.lib.hprof..*?. > > /Staffan > >> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote: >> >> Staffan, thank you for the review! >> >> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. >> >> // Katja >> >> >> >> On 04/22/2015 01:20 PM, Staffan Larsen wrote: >>> Looks good! >>> >>> Thanks, >>> /Staffan >>> >>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >>>> >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>> >>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>>> >>>> The old jhat packages have been moved as follows: >>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>> >>>> The source has not been changed except Copyrights year. >>>> >>>> Thanks, >>>> Katja >> > From staffan.larsen at oracle.com Wed Apr 22 13:09:30 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 15:09:30 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> Message-ID: <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> Oh, and: serviceability/dcmd/gc/HeapDumpTest.java > On 22 apr 2015, at 15:06, Staffan Larsen wrote: > > I also found this test that uses jhat and needs an update: com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh > > /Staffan > >> On 22 apr 2015, at 15:05, Staffan Larsen wrote: >> >> I think you are missing a "@build jdk.test.lib.hprof..*?. >> >> /Staffan >> >>> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote: >>> >>> Staffan, thank you for the review! >>> >>> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. >>> >>> // Katja >>> >>> >>> >>> On 04/22/2015 01:20 PM, Staffan Larsen wrote: >>>> Looks good! >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could I please have a review of this fix. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>>> >>>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>>>> >>>>> The old jhat packages have been moved as follows: >>>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>>> >>>>> The source has not been changed except Copyrights year. >>>>> >>>>> Thanks, >>>>> Katja >>> >> > From christian.tornqvist at oracle.com Wed Apr 22 13:55:25 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 22 Apr 2015 09:55:25 -0400 Subject: RFR(XS): 8077994 - [TESTBUG] Exclude compiler/floatingpoint/ModNaN.java Message-ID: <000501d07d03$fc85b7a0$f59126e0$@oracle.com> Hi everyone, Please review this small change which excludes the compiler/floatingpoint/ModNaN.java test. The reason for excluding this is that it fails when running through with the interpreter on Windows x64 when Hotspot has been built with VS2013. The root cause for this failure is a changed behavior in fmod() in the x64 version of msvcr120.dll, we are working on a fix for this issue. See https://bugs.openjdk.java.net/browse/JDK-8015396 for more information. Webrev: http://cr.openjdk.java.net/~emc/8078112/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8077994 Thanks, Christian From christian.tornqvist at oracle.com Wed Apr 22 15:01:53 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 22 Apr 2015 11:01:53 -0400 Subject: RFR(XS): 8077994 - [TESTBUG] Exclude compiler/floatingpoint/ModNaN.java In-Reply-To: <000501d07d03$fc85b7a0$f59126e0$@oracle.com> References: <000501d07d03$fc85b7a0$f59126e0$@oracle.com> Message-ID: <002701d07d0d$453bacd0$cfb30670$@oracle.com> Harold pointed out that my webrev link is incorrect, here is the correct one: http://cr.openjdk.java.net/~ctornqvi/webrev/8077994/webrev.00/ Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Christian Tornqvist Sent: Wednesday, April 22, 2015 9:55 AM To: hotspot-dev at openjdk.java.net Subject: RFR(XS): 8077994 - [TESTBUG] Exclude compiler/floatingpoint/ModNaN.java Hi everyone, Please review this small change which excludes the compiler/floatingpoint/ModNaN.java test. The reason for excluding this is that it fails when running through with the interpreter on Windows x64 when Hotspot has been built with VS2013. The root cause for this failure is a changed behavior in fmod() in the x64 version of msvcr120.dll, we are working on a fix for this issue. See https://bugs.openjdk.java.net/browse/JDK-8015396 for more information. Webrev: http://cr.openjdk.java.net/~emc/8078112/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8077994 Thanks, Christian From harold.seigel at oracle.com Wed Apr 22 15:05:24 2015 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 22 Apr 2015 11:05:24 -0400 Subject: RFR(XS): 8077994 - [TESTBUG] Exclude compiler/floatingpoint/ModNaN.java In-Reply-To: <002701d07d0d$453bacd0$cfb30670$@oracle.com> References: <000501d07d03$fc85b7a0$f59126e0$@oracle.com> <002701d07d0d$453bacd0$cfb30670$@oracle.com> Message-ID: <5537B8B4.2000205@oracle.com> Hi Christian, This looks good. Thanks, Harold On 4/22/2015 11:01 AM, Christian Tornqvist wrote: > Harold pointed out that my webrev link is incorrect, here is the correct > one: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8077994/webrev.00/ > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of > Christian Tornqvist > Sent: Wednesday, April 22, 2015 9:55 AM > To: hotspot-dev at openjdk.java.net > Subject: RFR(XS): 8077994 - [TESTBUG] Exclude > compiler/floatingpoint/ModNaN.java > > Hi everyone, > > > > Please review this small change which excludes the > compiler/floatingpoint/ModNaN.java test. The reason for excluding this is > that it fails when running through with the interpreter on Windows x64 when > Hotspot has been built with VS2013. The root cause for this failure is a > changed behavior in fmod() in the x64 version of msvcr120.dll, we are > working on a fix for this issue. See > https://bugs.openjdk.java.net/browse/JDK-8015396 for more information. > > > > Webrev: > > http://cr.openjdk.java.net/~emc/8078112/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8077994 > > > > Thanks, > > Christian > > From vladimir.kozlov at oracle.com Wed Apr 22 15:05:37 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Apr 2015 08:05:37 -0700 Subject: Comp bug due to windows compiler upgrades In-Reply-To: <5537B3B3.6000106@oracle.com> References: <552D4826.3040905@oracle.com> <552D49FD.6010303@oracle.com> <36A5DF14-7ABC-43F2-826E-A2882A4DABC6@oracle.com> <552D4CFB.8050605@oracle.com> <552FFB82.1070404@oracle.com> <0ef001d07871$6446bf20$2cd43d60$@oracle.com> <552FFE16.6020100@oracle.com> <0fdf01d07906$16d2c1e0$447845a0$@oracle.com> <55311F13.60500@oracle.com> <55312753.3040408@oracle.com> <108101d07933$2bfc9190$83f5b4b0$@oracle.com> <5531539C.7030906@oracle.com> <55364BDA.9060905@oracle.com> <55365FB2.5070804@oracle.com> <5537855F.1070002@oracle.com> <5537880F.5070500@oracle.com> <5537B3B3.6000106@oracle.com> Message-ID: <5537B8C1.8080507@oracle.com> 8077590/webrev/ fix looks good. I did not see webrev for 8015396. Thanks, Vladimir On 4/22/15 7:44 AM, Alejandro E Murillo wrote: > Hi Nils, and others, one more thing, > there's not a reviewer in that patch. > to gain sometime here, can any reviewer in this thread review the change > and agree to be added as a reviewer? > > Thanks > Alejandro > > On 4/22/2015 5:37 AM, Alejandro E Murillo wrote: >> >> >> On 4/22/2015 5:26 AM, Nils Eliasson wrote: >>> I started with removing optimization from all sharedRuntime* files as you suggested and it worked. I got a new >>> warning (as error) in sharedRuntime.cpp " overflow in constant arithmetic" >>> https://msdn.microsoft.com/en-us/library/f4s2sw05.aspx. That warning pointed to the high(double) and low(double) >>> functions. So I tested if it was them causing the failure and it worked too. >>> >>> Here is a webrev: http://cr.openjdk.java.net/~neliasso/8077590/webrev/ >>> >>> Alejandro - is it still jdk9/dev I should push to? >> yes, but this need to be pushed via jprt along with Christian's change for JDK-8015396, >> otherwise the jprt job will fail. >> Christian, if you provide me with your committed patch and I can push both patches >> or if you prefer, you can grab Nils patch from the webrev and submit a job with your >> changes along with that to jdk9/dev? just let me know >> >> Thanks! >> Alejandro From alejandro.murillo at oracle.com Wed Apr 22 15:48:54 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 22 Apr 2015 09:48:54 -0600 Subject: Comp bug due to windows compiler upgrades In-Reply-To: <5537B8C1.8080507@oracle.com> References: <552D4826.3040905@oracle.com> <552D49FD.6010303@oracle.com> <36A5DF14-7ABC-43F2-826E-A2882A4DABC6@oracle.com> <552D4CFB.8050605@oracle.com> <552FFB82.1070404@oracle.com> <0ef001d07871$6446bf20$2cd43d60$@oracle.com> <552FFE16.6020100@oracle.com> <0fdf01d07906$16d2c1e0$447845a0$@oracle.com> <55311F13.60500@oracle.com> <55312753.3040408@oracle.com> <108101d07933$2bfc9190$83f5b4b0$@oracle.com> <5531539C.7030906@oracle.com> <55364BDA.9060905@oracle.com> <55365FB2.5070804@oracle.com> <5537855F.1070002@oracle.com> <5537880F.5070500@oracle.com> <5537B3B3.6000106@oracle.com> <5537B8C1.8080507@oracle.com> Message-ID: <5537C2E6.3050604@oracle.com> Thanks Vladimir On 4/22/2015 9:05 AM, Vladimir Kozlov wrote: > 8077590/webrev/ fix looks good. > I did not see webrev for 8015396. this one is still active, Christian provided a patch for the test to be excluded until that one is fixed. Look for this: RFR(XS): 8077994 - [TESTBUG] Exclude compiler/floatingpoint/ModNaN.java Thanks! Alejandro > > Thanks, > Vladimir > > On 4/22/15 7:44 AM, Alejandro E Murillo wrote: >> Hi Nils, and others, one more thing, >> there's not a reviewer in that patch. >> to gain sometime here, can any reviewer in this thread review the >> change >> and agree to be added as a reviewer? >> >> Thanks >> Alejandro >> >> On 4/22/2015 5:37 AM, Alejandro E Murillo wrote: >>> >>> >>> On 4/22/2015 5:26 AM, Nils Eliasson wrote: >>>> I started with removing optimization from all sharedRuntime* files >>>> as you suggested and it worked. I got a new >>>> warning (as error) in sharedRuntime.cpp " overflow in constant >>>> arithmetic" >>>> https://msdn.microsoft.com/en-us/library/f4s2sw05.aspx. That >>>> warning pointed to the high(double) and low(double) >>>> functions. So I tested if it was them causing the failure and it >>>> worked too. >>>> >>>> Here is a webrev: http://cr.openjdk.java.net/~neliasso/8077590/webrev/ >>>> >>>> Alejandro - is it still jdk9/dev I should push to? >>> yes, but this need to be pushed via jprt along with Christian's >>> change for JDK-8015396, >>> otherwise the jprt job will fail. >>> Christian, if you provide me with your committed patch and I can >>> push both patches >>> or if you prefer, you can grab Nils patch from the webrev and submit >>> a job with your >>> changes along with that to jdk9/dev? just let me know >>> >>> Thanks! >>> Alejandro -- Alejandro From calvin.cheung at oracle.com Wed Apr 22 16:37:15 2015 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 22 Apr 2015 09:37:15 -0700 Subject: RFR(XS): 8077994 - [TESTBUG] Exclude compiler/floatingpoint/ModNaN.java In-Reply-To: <5537B8B4.2000205@oracle.com> References: <000501d07d03$fc85b7a0$f59126e0$@oracle.com> <002701d07d0d$453bacd0$cfb30670$@oracle.com> <5537B8B4.2000205@oracle.com> Message-ID: <5537CE3B.2050100@oracle.com> Looks good to me too. thanks, Calvin On 4/22/2015 8:05 AM, harold seigel wrote: > Hi Christian, > > This looks good. > > Thanks, Harold > On 4/22/2015 11:01 AM, Christian Tornqvist wrote: >> Harold pointed out that my webrev link is incorrect, here is the correct >> one: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8077994/webrev.00/ >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of >> Christian Tornqvist >> Sent: Wednesday, April 22, 2015 9:55 AM >> To: hotspot-dev at openjdk.java.net >> Subject: RFR(XS): 8077994 - [TESTBUG] Exclude >> compiler/floatingpoint/ModNaN.java >> >> Hi everyone, >> >> >> Please review this small change which excludes the >> compiler/floatingpoint/ModNaN.java test. The reason for excluding >> this is >> that it fails when running through with the interpreter on Windows >> x64 when >> Hotspot has been built with VS2013. The root cause for this failure is a >> changed behavior in fmod() in the x64 version of msvcr120.dll, we are >> working on a fix for this issue. See >> https://bugs.openjdk.java.net/browse/JDK-8015396 for more information. >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~emc/8078112/webrev.00/ >> >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8077994 >> >> >> Thanks, >> >> Christian >> >> > From aph at redhat.com Wed Apr 22 16:58:01 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Apr 2015 17:58:01 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <55376FD2.5000403@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> <55376FD2.5000403@redhat.com> Message-ID: <5537D319.4010207@redhat.com> Looking at this thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016477.html https://bugs.openjdk.java.net/browse/JDK-8068945 I'm wondering if we should keep FP as a frame pointer. We'd have a slightly more complex method entry sequence, but the profiling and debugging advantages look to be quite considerable. Andrew. From yekaterina.kantserova at oracle.com Wed Apr 22 17:02:13 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 22 Apr 2015 10:02:13 -0700 (PDT) Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests Message-ID: <02db0e73-b01d-4b1a-a963-89e4c956f0bc@default> Thanks for the catch Staffan! I'll go through all of them and send out a new webrev. // Katja ----- Original Message ----- From: staffan.larsen at oracle.com To: staffan.larsen at oracle.com Cc: yekaterina.kantserova at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Wednesday, April 22, 2015 3:09:35 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR(M): 8059047: Extract parser/validator from jhat for use in tests Oh, and: serviceability/dcmd/gc/HeapDumpTest.java > On 22 apr 2015, at 15:06, Staffan Larsen wrote: > > I also found this test that uses jhat and needs an update: com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh > > /Staffan > >> On 22 apr 2015, at 15:05, Staffan Larsen wrote: >> >> I think you are missing a "@build jdk.test.lib.hprof..*?. >> >> /Staffan >> >>> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote: >>> >>> Staffan, thank you for the review! >>> >>> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. >>> >>> // Katja >>> >>> >>> >>> On 04/22/2015 01:20 PM, Staffan Larsen wrote: >>>> Looks good! >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could I please have a review of this fix. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>>> >>>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>>>> >>>>> The old jhat packages have been moved as follows: >>>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>>> >>>>> The source has not been changed except Copyrights year. >>>>> >>>>> Thanks, >>>>> Katja >>> >> > From christian.thalinger at oracle.com Wed Apr 22 17:56:19 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 22 Apr 2015 10:56:19 -0700 Subject: RFR: 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe Message-ID: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8022853 In some native data structures of the VM oops are stored uncompressed even if compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. This additional Unsafe API make the implementation of JEP 243: Java-Level JVM Compiler Interface simpler. http://cr.openjdk.java.net/~twisti/8022853/hotspot/webrev.01/ http://cr.openjdk.java.net/~twisti/8022853/jdk/webrev.01/ From vladimir.kozlov at oracle.com Wed Apr 22 18:02:21 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Apr 2015 11:02:21 -0700 Subject: RFR: 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe In-Reply-To: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> References: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> Message-ID: <5537E22D.3020500@oracle.com> Looks good to me. Vlaidmir On 4/22/15 10:56 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8022853 > > In some native data structures of the VM oops are stored uncompressed even if compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. > > This additional Unsafe API make the implementation of JEP 243: Java-Level JVM Compiler Interface simpler. > > http://cr.openjdk.java.net/~twisti/8022853/hotspot/webrev.01/ > http://cr.openjdk.java.net/~twisti/8022853/jdk/webrev.01/ > From vitalyd at gmail.com Wed Apr 22 18:16:10 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Apr 2015 14:16:10 -0400 Subject: RFR: 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe In-Reply-To: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> References: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> Message-ID: Chris, I think you have a stray '/' here: 185 if (UseCompressedOops) { \ ? On Wed, Apr 22, 2015 at 1:56 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > https://bugs.openjdk.java.net/browse/JDK-8022853 > > In some native data structures of the VM oops are stored uncompressed even > if compressed oops are turned on, for example Klass::_java_mirror. Java > code which is tightly coupled with the VM should have the ability to read > and write such fields. > > This additional Unsafe API make the implementation of JEP 243: Java-Level > JVM Compiler Interface simpler. > > http://cr.openjdk.java.net/~twisti/8022853/hotspot/webrev.01/ > http://cr.openjdk.java.net/~twisti/8022853/jdk/webrev.01/ > > From vitalyd at gmail.com Wed Apr 22 18:16:43 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Apr 2015 14:16:43 -0400 Subject: RFR: 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe In-Reply-To: References: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> Message-ID: stray '\', I meant On Wed, Apr 22, 2015 at 2:16 PM, Vitaly Davidovich wrote: > Chris, I think you have a stray '/' here: > > 185 if (UseCompressedOops) { \ > > ? > > > > On Wed, Apr 22, 2015 at 1:56 PM, Christian Thalinger < > christian.thalinger at oracle.com> wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8022853 >> >> In some native data structures of the VM oops are stored uncompressed >> even if compressed oops are turned on, for example Klass::_java_mirror. >> Java code which is tightly coupled with the VM should have the ability to >> read and write such fields. >> >> This additional Unsafe API make the implementation of JEP 243: Java-Level >> JVM Compiler Interface simpler. >> >> http://cr.openjdk.java.net/~twisti/8022853/hotspot/webrev.01/ >> http://cr.openjdk.java.net/~twisti/8022853/jdk/webrev.01/ >> >> > From christian.thalinger at oracle.com Wed Apr 22 18:28:54 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 22 Apr 2015 11:28:54 -0700 Subject: RFR: 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe In-Reply-To: References: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> Message-ID: <96DF81EE-728D-41CB-A899-61E34EA049BF@oracle.com> > On Apr 22, 2015, at 11:16 AM, Vitaly Davidovich wrote: > > stray '\', I meant > > On Wed, Apr 22, 2015 at 2:16 PM, Vitaly Davidovich > wrote: > >> Chris, I think you have a stray '/' here: >> >> 185 if (UseCompressedOops) { \ >> >> ? I do. Thanks for noticing. >> >> >> >> On Wed, Apr 22, 2015 at 1:56 PM, Christian Thalinger < >> christian.thalinger at oracle.com> wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8022853 >>> >>> In some native data structures of the VM oops are stored uncompressed >>> even if compressed oops are turned on, for example Klass::_java_mirror. >>> Java code which is tightly coupled with the VM should have the ability to >>> read and write such fields. >>> >>> This additional Unsafe API make the implementation of JEP 243: Java-Level >>> JVM Compiler Interface simpler. >>> >>> http://cr.openjdk.java.net/~twisti/8022853/hotspot/webrev.01/ >>> http://cr.openjdk.java.net/~twisti/8022853/jdk/webrev.01/ >>> >>> >> From john.r.rose at oracle.com Wed Apr 22 18:44:55 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Apr 2015 11:44:55 -0700 Subject: RFR: 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe In-Reply-To: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> References: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> Message-ID: <54D1E745-C61B-49C2-9717-5AF69257964D@oracle.com> Reviewed, if you update the javadoc for Unsafe.getUncompressedObject. ? John On Apr 22, 2015, at 10:56 AM, Christian Thalinger wrote: > > https://bugs.openjdk.java.net/browse/JDK-8022853 > > In some native data structures of the VM oops are stored uncompressed even if compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. > > This additional Unsafe API make the implementation of JEP 243: Java-Level JVM Compiler Interface simpler. > > http://cr.openjdk.java.net/~twisti/8022853/hotspot/webrev.01/ > http://cr.openjdk.java.net/~twisti/8022853/jdk/webrev.01/ > From edward.nevill at linaro.org Wed Apr 22 18:58:37 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 22 Apr 2015 19:58:37 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5537D319.4010207@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> <55376FD2.5000403@redhat.com> <5537D319.4010207@redhat.com> Message-ID: On 22 April 2015 at 17:58, Andrew Haley wrote: > Looking at this thread: > > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016477.html > https://bugs.openjdk.java.net/browse/JDK-8068945 > > I'm wondering if we should keep FP as a frame pointer. We'd have a > slightly more complex method entry sequence, but the profiling and > debugging advantages look to be quite considerable. > > Andrew. > Hi, The two are not incompatible. Zolt?n Maj? has been working on a patch to use RBP as a proper frame pointer on x86. See http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017715.html This provides a new flag -XX:+PreserveFramePointer which uses RBP as a proper frame pointer and -XX:-PreserveFramePointer which uses RBP as a general purpose register. I have prepared a mirror patch for this for aarch64. See http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-March/017543.html Once Zolt?n's patch goes in, I can update this for any recent changes and post a RFR. All the best, Ed. From christian.thalinger at oracle.com Wed Apr 22 19:01:44 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 22 Apr 2015 12:01:44 -0700 Subject: RFR: 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe In-Reply-To: <54D1E745-C61B-49C2-9717-5AF69257964D@oracle.com> References: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> <54D1E745-C61B-49C2-9717-5AF69257964D@oracle.com> Message-ID: <0B20C14F-BE2D-4312-824F-03988E53DFD6@oracle.com> > On Apr 22, 2015, at 11:44 AM, John Rose wrote: > > Reviewed, if you update the javadoc for Unsafe.getUncompressedObject. ? John Done. Thanks, I missed that. > On Apr 22, 2015, at 10:56 AM, Christian Thalinger wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8022853 >> >> In some native data structures of the VM oops are stored uncompressed even if compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. >> >> This additional Unsafe API make the implementation of JEP 243: Java-Level JVM Compiler Interface simpler. >> >> http://cr.openjdk.java.net/~twisti/8022853/hotspot/webrev.01/ >> http://cr.openjdk.java.net/~twisti/8022853/jdk/webrev.01/ >> > From coleen.phillimore at oracle.com Wed Apr 22 20:42:47 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Apr 2015 16:42:47 -0400 Subject: RFR: 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe In-Reply-To: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> References: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> Message-ID: <553807C7.4070806@oracle.com> Christian, This looks really good. Thanks!! Coleen On 4/22/15, 1:56 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8022853 > > In some native data structures of the VM oops are stored uncompressed even if compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. > > This additional Unsafe API make the implementation of JEP 243: Java-Level JVM Compiler Interface simpler. > > http://cr.openjdk.java.net/~twisti/8022853/hotspot/webrev.01/ > http://cr.openjdk.java.net/~twisti/8022853/jdk/webrev.01/ > From coleen.phillimore at oracle.com Wed Apr 22 21:11:39 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Apr 2015 17:11:39 -0400 Subject: RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: <552EC286.5000005@oracle.com> References: <552EC286.5000005@oracle.com> Message-ID: <55380E8B.2060904@oracle.com> Hi Calvin, and fellow JVM engineers, I prefer a modification of your first version of this change much better. I really don't like this... It feels very unsafe to me. I don't know how to run any tools to make sure I don't break this! Honestly this seems wrong and there are too many places that compare Symbols even though the changeset is smaller. We triage bugs in the runtime group weekly with SQE. This change will cause bugs that have various symptoms and will be hard to trace to this root cause. The bugs will mostly land in the Runtime component of the JVM because in fact, the Symbol class is mostly used by the runtime component of the JVM. In addition, running internal tools to find these errors *monthly* is too late and running them individually adds overhead and friction to making changes in the JVM. More overhead is the last thing we need! Having to use ->equals() is clunky too. For better or worse, the JVM is written in C++ which has operator overloading for these purposes. Modern C++ programming already avoids raw pointers in favore of smart pointers! The JVM code has historically avoided raw metadata pointers, first because of PermGen but now because the values pointed to have semantics that we want to encapsulate. I admit that it was nice using raw pointers and brought all of us back to a simpler day but they're not safe in general for this sort of system software. In the JVM code, we have Handles: 1. oops => Handle because they may move with garbage collection. 2. Method* => methodHandle because they may get deallocated with class redefinition (same for Klass eventually) 3. Symbol* => SymbolHandle because pointer equality isn't sufficient to ensure equality The other objection for Calvin's first change was that it's a lot of code changed. But there's a lot of other large code changes going forward at this time. This is the simplest of large changes, ie. simple renaming. This feature is needed for others going forward to support our important customers. This amount of code change is justified. Embedded in this mail, if you've read this far, is a suggestion to rename SymbolRef (a name I hate) to SymbolHandle. Because that's what it now is. Thanks, Coleen On 4/15/15, 3:56 PM, Calvin Cheung wrote: > Please review this second version of the fix. > > This version has 2 new functions (equals() and not_equals()) in the > Symbol class. > It replaces the Symbol* == and != comparisons with those 2 function > calls. > > Pro: > > It has a much smaller changeset than the first version. > > Con: > > Someone may by mistake introduce a new line of (Symbol* == Symbol*). > > We will mitigate this by enhancing our internal static analysis tool > to flag the > above code in the future. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8071627 > > webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.01/ > > Tests: > JPRT (almost done) > Will do more perf testing after JPRT > > thanks, > Calvin From christian.thalinger at oracle.com Wed Apr 22 21:23:20 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 22 Apr 2015 14:23:20 -0700 Subject: RFR: 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe In-Reply-To: <553807C7.4070806@oracle.com> References: <7FC10482-F172-4BFE-BD0C-5D4619A80A5A@oracle.com> <553807C7.4070806@oracle.com> Message-ID: <5CC7B04D-9608-4A2C-99A5-2315E02BCA6F@oracle.com> Thank you, Coleen. > On Apr 22, 2015, at 1:42 PM, Coleen Phillimore wrote: > > > Christian, > This looks really good. > Thanks!! > Coleen > > On 4/22/15, 1:56 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8022853 >> >> In some native data structures of the VM oops are stored uncompressed even if compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. >> >> This additional Unsafe API make the implementation of JEP 243: Java-Level JVM Compiler Interface simpler. >> >> http://cr.openjdk.java.net/~twisti/8022853/hotspot/webrev.01/ >> http://cr.openjdk.java.net/~twisti/8022853/jdk/webrev.01/ >> > From kirk.pepperdine at gmail.com Wed Apr 22 22:34:23 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Thu, 23 Apr 2015 00:34:23 +0200 Subject: [9] RFR (S): 8059340: ConstantPool::_resolved_references is missing in heap dump In-Reply-To: <55358D0A.1020407@oracle.com> References: <542971DC.2090803@oracle.com> <24133E27-C024-41D8-80EF-B5707CFF0D0C@oracle.com> <552FFBAA.6050103@oracle.com> <55358D0A.1020407@oracle.com> Message-ID: <1CA46E92-CAA7-43E8-A9AB-BFBD16FAD52C@gmail.com> On Apr 21, 2015, at 1:34 AM, Coleen Phillimore wrote: > > Vladimir, > > I think that changing the format of the heap dump isn't a good idea either. That would break tooling. I think you could change it if the change is really really needed by I think you?d want to do it at a major release (i.e. 9) with some sort of call out.. that shouts, hey, we?re going to break tooling. Regards, Kirk > > On 4/16/15, 2:12 PM, Vladimir Ivanov wrote: >> (sorry for really late response; just got enough time to return to the bug) > > I'd forgotten about it! >> >> Coleen, Staffan, >> >> Thanks a lot for the feedback! >> >> After thinking about the fix more, I don't think that using reserved oop slot in CLASS DUMP for recording _resolved_references is the best thing to do. IMO the change causes too much work for the users (heap dump analysis tools). >> >> It needs specification update and then heap dump analyzers should be updated as well. >> >> I have 2 alternative approaches (hacky and not-so-hacky :-)): >> >> - artificial class static field in the dump ("" + optional id to guarantee unique name); >> >> - add j.l.Class::_resolved_references field; >> Not sure how much overhead (mostly reads from bytecode) the move from ConstantPool to j.l.Class adds, so I propose just to duplicate it for now. > > I really like this second approach, so much so that I had a prototype for moving resolved_references directly to the j.l.Class object about a year ago. I couldn't find any benefit other than consolidating oops so the GC would have less work to do. If the resolved_references are moved to j.l.C instance, they can not be jobjects and the ClassLoaderData::_handles area wouldn't have to contain them (but there are other things that could go there so don't delete the _handles field yet). > > The change I had was relatively simple. The only annoying part was that getting to the resolved references has to be in macroAssembler and do: > > go through method->cpCache->constants->instanceKlass->java_mirror() rather than > method->cpCache->constants->resolved_references->jmethod indirection > > I think it only affects the interpreter so the extra indirection wouldn't affect performance, so don't duplicate it! You don't want to increase space used by j.l.C without taking it out somewhere else! > >> >> What do you think about that? > > Is this bug worth doing this? I don't know but I'd really like it. > > Coleen > >> >> Best regards, >> Vladimir Ivanov >> >> On 10/6/14 11:35 AM, Staffan Larsen wrote: >>> This looks like a good approach. However, there are a couple of more places that need to be updated. >>> >>> The hprof binary format is described in jdk/src/jdk.hprof.agent/share/native/libhprof/manual.html and needs to be updated. It?s also more formally specified in hprof_b_spec.h in the same directory. >>> >>> The hprof JVMTI agent in jdk/src/jdk.hprof.agent code would also need to be updated to show this field. Since this is a JVMTI agent it needs to be possible to find the resolved_refrences array via the JVMTI heap walking API. Perhaps that already works? - I haven?t looked. >>> >>> Finally, the Serviceability Agent implements yet another hprof binary dumper in hotspot/agent//src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java which also needs to write this reference. >>> >>> Thanks, >>> /Staffan >>> >>> On 29 sep 2014, at 16:51, Vladimir Ivanov wrote: >>> >>>> http://cr.openjdk.java.net/~vlivanov/8059340/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8059340 >>>> >>>> VM heap dump doesn't contain ConstantPool::_resolved_references for classes which have resolved references. >>>> >>>> ConstantPool::_resolved_references points to an Object[] holding resolved constant pool entries (patches for VM anonymous classes, linked CallSite & MethodType for invokedynamic instructions). >>>> >>>> I've decided to use reserved slot in HPROF class header format. >>>> It requires an update in jhat to correctly display new info. >>>> >>>> The other approach I tried was to dump the reference as a fake static field [1], but storing VM internal ConstantPool::_resolved_references among user defined fields looks confusing. >>>> >>>> Testing: manual (verified that corresponding arrays are properly linked in Nashorn heap dump). >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] http://cr.openjdk.java.net/~vlivanov/8059340/static >>> > From vladimir.kozlov at oracle.com Wed Apr 22 22:48:02 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Apr 2015 15:48:02 -0700 Subject: RFR: 8076488: AARCH64: jdk9 fails to build from source In-Reply-To: <553766C0.1000007@redhat.com> References: <1427905684.1631.12.camel@mylittlepony.linaroharston> <551C300D.2090005@oracle.com> <5530D3D2.5090505@redhat.com> <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com> <5530D501.1010004@redhat.com> <5530D5A7.90105@redhat.com> <553139CB.8090303@oracle.com> <55313E22.1000800@redhat.com> <553766C0.1000007@redhat.com> Message-ID: <55382522.5010100@oracle.com> Best case scenario: 1. Changes pushed into a Hotspot groups repos (jdk9/hs-comp) using JPRT and we do Nightly testing on them. 2. Each week on Thursday all changes which passed at least one Nightly testing are pushed from all groups repos into main repo (jdk9/hs) using JPRT. 3. Hotspot gatekeeper creates bundles for all platforms from main repo (jdk9/hs) and start PIT testing which is going whole weekend. 4. Monday-Tuesday SQE analyze PIT results and give yes (or no) on merge to jdk9/dev. If 'yes' Hotspot gatekeeper pushes changes to jdk9/dev. So usually it takes one/one-and-half weeks for changes propagate from jdk9/hs-comp to jdk9/dev. What happened in last weeks. As you may notice no Hotspot changes were pushed into jdk9/dev since April 6: http://mail.openjdk.java.net/pipermail/jdk9-dev-changes/2015-April/003119.html We had severe failures on Windows systems and SQE gave 'no' on merge to jdk9/dev. And jdk9/hs-comp was not merged to jdk9/hs between March 31 and April 6 because we had regression in Nightly testing. Note, this and next week there will be no merge to jdk9/dev due to technical issues (we will not be able to run PIT testing). Most likely you will see "Intrinsify ByteBuffer.put" changes in jdk9/dev only in May. My suggestion would be to use one of Hotspot group's repo as base for your work if it includes Hotspot changes. Regards, Vladimir On 4/22/15 2:15 AM, Andrew Haley wrote: > On 04/17/2015 06:08 PM, Andrew Haley wrote: >> On 04/17/2015 05:50 PM, Vladimir Kozlov wrote: >>> > Ah, no I won't. My patch already fixed this, and (IMO) in a much better >>> > way. This patch is already in jprt, and will emerge soon, I hope. >>> >>> Andrew, do you mean the change pushed few days ago as part of 8077615 changes?: >>> >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2a6c4bd248cf >> >> Yes. > > How does this work? Is it that changes are pushed to hs-comp (by > JPRT?) tested, and then manually merged at some point in the future? > > I'm thinking about the workflow. It's now Apr 22, and the patch > "Intrinsify ByteBuffer.put" went into hs-comp on Mar 31. This seems > like a very long time to wait while developing. It's particularly > awkward if we have a bug which breaks the build. > > I'm not asking for anything to be changed, just trying to understand > how I (and other external contributors) should best interact with the > HotSpot workflow. > > Thanks, > Andrew. > From vladimir.kozlov at oracle.com Wed Apr 22 22:59:02 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Apr 2015 15:59:02 -0700 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <55376318.7070604@redhat.com> References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com> <553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com> <55376318.7070604@redhat.com> Message-ID: <553827B6.9000800@oracle.com> First, I am fine with your changes. I thought that may be adding some shared code (flag?) will simplify (reduce) your change. But based on your answer it is not the case. So I am fine with you changes. Thanks, Vladimir On 4/22/15 2:00 AM, Andrew Dinn wrote: > Hi Vladimir, > > Thanks for responding. > > On 21/04/15 18:03, Vladimir Kozlov wrote: >> Would it help if we add a new flag to NodeFlags to indicate volatile >> memory node? > > Yes, I think this would provide some benefit although I don't know if it > will justify cost of implementing and testing the necessary shared code > changes given that the benefit is only partial. Even with such a flag we > would still need to do some of the work that this patch does. Also, the > flag would not help with a the next optimization we are planning > (removing unnecessary barriers from CAS sequences). > > Your suggestion will /simplify/ the predicates for LoadX/StoreX but will > not make much difference to execution time. The current predicates for > these nodes, needs_acquiring_load() and needs_releasing_store(), check > immediately whether a LoadX is acquiring or a StoreX is releasing. So, > we have a quick filter for the /common path/ case where we simply > generate an ldr or stlr (I assume volatile ops are relatively rare). > > However, we cannot rely solely on these existing flags as they are > sometimes set in other (non-volatile) cases. Currently, if the acquiring > or releasing flag is set the predicates go on to investigate the nodes > around the LoadX/StoreX looking for a specific configuration of > MemBar_XXX nodes. Adding the volatile flag would remove the need to do > this extra work in the /uncommon/ case. > > Unfortunately, the other half of the patch involves eliding generation > of dmb instructions for the MemBar_XXX nodes associated with the a LoadX > or StoreX. Three other predicates are used for this purpose, > unnecesary_membar_acquire, unnecesary_membar_release and > unnecesary_membar_volatile. They search the ideal graph around the > membar to see whether it belongs to a signature sequence containing an > acquiring load or releasing store. > > The check involves i) finding a related LoadX or StoreX, ii) checking it > is acquiring or releasing and ii) ensuring it is either tailed or > bracketed by a node group with a 'signature' shape which includes the > MemBar we started from. A volatile flag would not really speed up this > check and would not do much to simplify it. > > The current predicates test for very specific signature configurations. > So, in cases where the MemBar node is /not/ part of a signature volatile > sequence they detect this very rapidly. In the common case the predicate > immediately fails to find the required sort of parent/child node in the > tree surrounding the initial MemBar (i.e. one which is not a > LoadX/StoreX, Proj or MemBar). If we do arrive at a LoadX/StoreX in the > node tree we could, perhaps, check the volatile flag and short-circuit > any further graph traversal but the bulk of the work involves traversing > from the initial MemBar to the LoadX/StoreX. > > n.b. I say perhaps because I am not yet certain that we just test the > volatile flag. I don't know for sure that we could not arrive at the > memory node from a MemBar which was not part of the signature sequence > (I /am/ very confident that the current checks correctly identify > volatile node sequences and only those sequences). > > Could we punt this question of providing the volatile flag, considering > it as a potential follow-up improvement? I'd prefer to get this > AArch64-only change in as is -- or, at least, with some tweaking -- > before going on to consider something which requires changes to shared code. > > Also, I mentioned the CAS case above because that is what I am looking > at next and it extends the technique used in the current patch. > Currently CAS operations translate to something which looks like this > > dmb > ... > retry: > ldaxr > ... > stlxr > cbz retry > ... > dmb > > The ldaxr/stlxr pair are generated in response to a CompareAndSwapX node > and the dmb instructions arise from MemBar nodes. For a CAS AArch64 can > safely elide the dmb instructions. So, the next improvement will be to > extend the unnecessary_membar_xxx predicates to elide the dmb generation > when a suitable configuration of MemBar_XXX and CompareAndSwapX nodes is > seen. Of course, this test will not be helped at all by provision of a > volatile flag. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) > From vladimir.kozlov at oracle.com Wed Apr 22 23:15:35 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Apr 2015 16:15:35 -0700 Subject: RFR(L): 8077838: Recent developments for ppc. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> Message-ID: <55382B97.8080606@oracle.com> Why call methods 'atomic': atomic_inc_ptr() and atomic_ori_int()? Do you really need to change runtime_ppc.cpp only to remove empty line? Looks fine otherwise. Vladimir On 4/22/15 2:34 AM, Lindenmaier, Goetz wrote: > Hi, > > this change contains recent changes in the ppc directory mostly made by SAP. > It's a ppc-only change. > http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ > > - Recognition of Power 8 processors (by Tiago Sturmer Daitx). > - Support for more new Power 8 instructions. > - Support for transactional memory. This is implemented but not yet tested > thoroughly due to limitiations of the OS support. Not enabled. > - java.lang.math.*Exact intrinsics > - Some C2 optimizations and fixes: > * Handling of flag registers. Some instructions would lead to uncompilable > methods due to not allocatable register patterns. > * Free some integer registers to use them for allocation. Handle compressed > oops base as constant. > * Unscaled class compression. > - Type profiling fixes. > > Please review this change. > > Best regards, > Goetz. > > From coleen.phillimore at oracle.com Wed Apr 22 23:42:40 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Apr 2015 19:42:40 -0400 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <55375477.7020804@redhat.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> <5535A85D.101@oracle.com> <5536922F.3030204@oracle.com> <55370107.6010207@oracle.com> <55375477.7020804@redhat.com> Message-ID: <553831F0.70201@oracle.com> On 4/22/15, 3:57 AM, Andrew Haley wrote: > On 22/04/15 03:01, Daniel D. Daugherty wrote: >> Personally, I like the idea of not adding any more new JPRT targets >> and reconfiguring to have fastdebug and/or debug builds run as non-PCH... >> It's a much simpler policy to explain: >> >> If we support PCH builds with a particular toolset then product >> builds default to PCH and non-product builds default to no-PCH. > But the debug builds are used in development all the time. It's > these that really benefit from PCH. I feel like PCH makes development slower. I change a header file and all the files in the system are recompiled because it happens to be in the precompiled file. I wouldn't miss it for debug mode. Coleen > > Andrew. > From david.holmes at oracle.com Thu Apr 23 06:40:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Apr 2015 16:40:31 +1000 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() Message-ID: <553893DF.5060406@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8078470/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8078470 For historical reasons, dating back to LinuxThreads, os::fork_and_exec uses direct syscalls to perform fork and execve functions. The fork syscall has been deprecated on linux for quite some time and some distributions are now shipping with deprecated syscalls removed - this results in a ENOSYS error and the "OnError" commands that utilize os::fork_and_exec no longer work. The problem was discussed here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html It seems the concerns surrounding direct use of glibc fork() and exec() are no longer legitimate and Martin Buchholz reports that Google replaced the syscalls with glibc calls some time ago and have not had any problems. So we propose to apply the same change uniformly on Linux. This is initially going into 8u60 via jdk8u-hs-dev due to time constraints on the 8u60 schedule, and an internal limitation preventing me from pushing this to 9 right now. But it will be "backported" to 9 ASAP. Thanks, David From thomas.stuefe at gmail.com Thu Apr 23 07:24:50 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Apr 2015 09:24:50 +0200 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: <553893DF.5060406@oracle.com> References: <553893DF.5060406@oracle.com> Message-ID: Hi David - would it be possible to use vfork() instead of fork()? Might increase the chance of fork() succeeding in out-of-memory scenarios. The way fork/execve is used here is simple enough for vfork(). - would it be possible to print out errno in case fork fails? Regards, Thomas On Thu, Apr 23, 2015 at 8:40 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8078470/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8078470 > > For historical reasons, dating back to LinuxThreads, os::fork_and_exec > uses direct syscalls to perform fork and execve functions. The fork syscall > has been deprecated on linux for quite some time and some distributions are > now shipping with deprecated syscalls removed - this results in a ENOSYS > error and the "OnError" commands that utilize os::fork_and_exec no longer > work. > > The problem was discussed here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html > > It seems the concerns surrounding direct use of glibc fork() and exec() > are no longer legitimate and Martin Buchholz reports that Google replaced > the syscalls with glibc calls some time ago and have not had any problems. > So we propose to apply the same change uniformly on Linux. > > This is initially going into 8u60 via jdk8u-hs-dev due to time constraints > on the 8u60 schedule, and an internal limitation preventing me from pushing > this to 9 right now. But it will be "backported" to 9 ASAP. > > Thanks, > David > From aph at redhat.com Thu Apr 23 07:40:45 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Apr 2015 08:40:45 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1429695657.29680.7.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> Message-ID: <5538A1FD.3060504@redhat.com> On 22/04/15 10:40, Edward Nevill wrote: > If there is no other feedback shall I prepare a revised patch with R29 marked NS? I think you should. I'm as certain as I can be that the GC root- finding code won't find an OOP saved in R29 and then pushed by native code. Andrew. From aph at redhat.com Thu Apr 23 07:42:55 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Apr 2015 08:42:55 +0100 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <553831F0.70201@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> <5535A85D.101@oracle.com> <5536922F.3030204@oracle.com> <55370107.6010207@oracle.com> <55375477.7020804@redhat.com> <553831F0.70201@oracle.com> Message-ID: <5538A27F.5010705@redhat.com> On 23/04/15 00:42, Coleen Phillimore wrote: > > On 4/22/15, 3:57 AM, Andrew Haley wrote: >> On 22/04/15 03:01, Daniel D. Daugherty wrote: >>> Personally, I like the idea of not adding any more new JPRT targets >>> and reconfiguring to have fastdebug and/or debug builds run as non-PCH... >>> It's a much simpler policy to explain: >>> >>> If we support PCH builds with a particular toolset then product >>> builds default to PCH and non-product builds default to no-PCH. >> But the debug builds are used in development all the time. It's >> these that really benefit from PCH. > > I feel like PCH makes development slower. I change a header file and > all the files in the system are recompiled because it happens to be in > the precompiled file. But that'll happen anyway if the change you made is to one of the common headers. I can't see that it makes any difference. Maybe it depends on what you're working on? Andrew. From david.holmes at oracle.com Thu Apr 23 07:50:56 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Apr 2015 17:50:56 +1000 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: References: <553893DF.5060406@oracle.com> Message-ID: <5538A460.5020902@oracle.com> Hi Thomas, On 23/04/2015 5:24 PM, Thomas St?fe wrote: > Hi David > > - would it be possible to use vfork() instead of fork()? Might increase > the chance of fork() succeeding in out-of-memory scenarios. The way > fork/execve is used here is simple enough for vfork(). I'm reluctant to use vfork() as it is an unknown. The use of fork() has been trialled by Google with no problem. > - would it be possible to print out errno in case fork fails? Sure. Thanks, David > Regards, Thomas > > > On Thu, Apr 23, 2015 at 8:40 AM, David Holmes > wrote: > > webrev: http://cr.openjdk.java.net/~dholmes/8078470/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8078470 > > For historical reasons, dating back to LinuxThreads, > os::fork_and_exec uses direct syscalls to perform fork and execve > functions. The fork syscall has been deprecated on linux for quite > some time and some distributions are now shipping with deprecated > syscalls removed - this results in a ENOSYS error and the "OnError" > commands that utilize os::fork_and_exec no longer work. > > The problem was discussed here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html > > It seems the concerns surrounding direct use of glibc fork() and > exec() are no longer legitimate and Martin Buchholz reports that > Google replaced the syscalls with glibc calls some time ago and have > not had any problems. So we propose to apply the same change > uniformly on Linux. > > This is initially going into 8u60 via jdk8u-hs-dev due to time > constraints on the 8u60 schedule, and an internal limitation > preventing me from pushing this to 9 right now. But it will be > "backported" to 9 ASAP. > > Thanks, > David > > From thomas.stuefe at gmail.com Thu Apr 23 08:00:05 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Apr 2015 10:00:05 +0200 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: <5538A460.5020902@oracle.com> References: <553893DF.5060406@oracle.com> <5538A460.5020902@oracle.com> Message-ID: Hi David, On Thu, Apr 23, 2015 at 9:50 AM, David Holmes wrote: > Hi Thomas, > > On 23/04/2015 5:24 PM, Thomas St?fe wrote: > >> Hi David >> >> - would it be possible to use vfork() instead of fork()? Might increase >> the chance of fork() succeeding in out-of-memory scenarios. The way >> fork/execve is used here is simple enough for vfork(). >> > > I'm reluctant to use vfork() as it is an unknown. The use of fork() has > been trialled by Google with no problem. > > I understand. We use vfork() by default on Linux and HP-UX since 3-4 years for Runtime.exec() without problems (but our implementation differs wildly from the standard one). But then, Runtime.exec does not get called in error situations, so the conditions may be different for os::fork_and_exec(). > - would it be possible to print out errno in case fork fails? >> > > Sure. > > Thanks! ..Thomas > Thanks, > David > > Regards, Thomas >> >> >> On Thu, Apr 23, 2015 at 8:40 AM, David Holmes > > wrote: >> >> webrev: http://cr.openjdk.java.net/~dholmes/8078470/webrev/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8078470 >> >> For historical reasons, dating back to LinuxThreads, >> os::fork_and_exec uses direct syscalls to perform fork and execve >> functions. The fork syscall has been deprecated on linux for quite >> some time and some distributions are now shipping with deprecated >> syscalls removed - this results in a ENOSYS error and the "OnError" >> commands that utilize os::fork_and_exec no longer work. >> >> The problem was discussed here: >> >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html >> >> It seems the concerns surrounding direct use of glibc fork() and >> exec() are no longer legitimate and Martin Buchholz reports that >> Google replaced the syscalls with glibc calls some time ago and have >> not had any problems. So we propose to apply the same change >> uniformly on Linux. >> >> This is initially going into 8u60 via jdk8u-hs-dev due to time >> constraints on the 8u60 schedule, and an internal limitation >> preventing me from pushing this to 9 right now. But it will be >> "backported" to 9 ASAP. >> >> Thanks, >> David >> >> >> From goetz.lindenmaier at sap.com Thu Apr 23 08:27:51 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Apr 2015 08:27:51 +0000 Subject: RFR(L): 8077838: Recent developments for ppc. In-Reply-To: <55382B97.8080606@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> <55382B97.8080606@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC0988@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for the review! These methods actually do an atomic update of a memory location, so the name really describes what is happening. I'll remove the change to interpreter_ppc.cpp and runtime_ppc.cpp. Best regards, Goetz -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Donnerstag, 23. April 2015 01:16 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(L): 8077838: Recent developments for ppc. Why call methods 'atomic': atomic_inc_ptr() and atomic_ori_int()? Do you really need to change runtime_ppc.cpp only to remove empty line? Looks fine otherwise. Vladimir On 4/22/15 2:34 AM, Lindenmaier, Goetz wrote: > Hi, > > this change contains recent changes in the ppc directory mostly made by SAP. > It's a ppc-only change. > http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ > > - Recognition of Power 8 processors (by Tiago Sturmer Daitx). > - Support for more new Power 8 instructions. > - Support for transactional memory. This is implemented but not yet tested > thoroughly due to limitiations of the OS support. Not enabled. > - java.lang.math.*Exact intrinsics > - Some C2 optimizations and fixes: > * Handling of flag registers. Some instructions would lead to uncompilable > methods due to not allocatable register patterns. > * Free some integer registers to use them for allocation. Handle compressed > oops base as constant. > * Unscaled class compression. > - Type profiling fixes. > > Please review this change. > > Best regards, > Goetz. > > From goetz.lindenmaier at sap.com Thu Apr 23 08:35:45 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Apr 2015 08:35:45 +0000 Subject: RFR(S): 8078482: ppc: pass thread to throw_AbstractMethodError Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC09A0@DEWDFEMB12A.global.corp.sap> Hi, this fixes an issue detected by Tiago Sturmer Daitix in the jdk7 ppc port. The thread argument was left out in a call to throw_AbstractMethodError. Please review this change. It needs to go to jdk8u, too. It's ppc only. http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.01/ Best regards, Goetz. From per.liden at oracle.com Thu Apr 23 08:52:21 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 23 Apr 2015 10:52:21 +0200 Subject: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index Message-ID: <5538B2C5.3040404@oracle.com> Hi, (This change affects G1, but it's touching code in C1 so I'd like to ask someone from the compiler team to also reviewed this) Summary: The G1 barriers loads and updates the PrtQueue::_index field. This field is a size_t but the C1 version of these barriers aren't 64-bit clean. The bug has more details. In addition I've massaged the code a little bit, so that the 32-bit and 64-bit sections look more similar (and as a bonus I think we avoid an extra memory load on 32-bit). Webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8013171 Testing: * gc-test-suite on both 32 and 64-bit builds (with -XX:+UseG1GC -XX:+TieredCompilation -XX:TieredStopAtLevel=3 -XX:+VerifyAfterGC) * Passes jprt /Per From dmitry.samersoff at oracle.com Thu Apr 23 10:02:09 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 23 Apr 2015 13:02:09 +0300 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <55370107.6010207@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> <5535A85D.101@oracle.com> <5536922F.3030204@oracle.com> <55370107.6010207@oracle.com> Message-ID: <5538C321.4000708@oracle.com> On 2015-04-22 05:01, Daniel D. Daugherty wrote: > Personally, I like the idea of not adding any more new JPRT targets > and reconfiguring to have fastdebug and/or debug builds run as > non-PCH... > It's a much simpler policy to explain: > > If we support PCH builds with a particular toolset then product > builds default to PCH and non-product builds default to no-PCH. I'm second to it. -Dmitry On 2015-04-22 05:01, Daniel D. Daugherty wrote: > Magnus put this comment in the bug report about two weeks ago: > >> Is it possible to compile e.g. product builds with PCH and debug >> builds without, or vice versa? The impact of not using PCH will be >> not so great (since it's still used in 50% of the jobs), and we >> will get automatic testing both with and without PCH. > > David H followed with this comment: > >> Certainly possible, but it won't give complete coverage of course >> (but nothing practical will give complete coverage). >> >> Quickest fix for JPRT may be to just disable PCH for the embedded >> builds: product x86, fastdebug arm, to cover linux and minimal VM. >> Maybe throw in a couple of Windows builds (one product, one >> fastdebug) for good measure? > > Personally, I like the idea of not adding any more new JPRT targets > and reconfiguring to have fastdebug and/or debug builds run as non-PCH... > It's a much simpler policy to explain: > > If we support PCH builds with a particular toolset then product > builds default to PCH and non-product builds default to no-PCH. > > Dan > > > On 4/21/15 12:08 PM, Coleen Phillimore wrote: >> >> On 4/20/15, 9:31 PM, David Holmes wrote: >>> On 21/04/2015 10:14 AM, Volker Simonis wrote: >>>> Hi Coleen, >>>> >>>> the default is not to use PCH and I think that's probably OK for most >>>> people. If somebody plays with the include files, he should use the >>>> '--disable-precompiled-headers' configure option. >>> >>> The default depends on platform. For solaris we never use PCH. For >>> the other platforms I think we always do. >> >> Yes, my motivation with this comment is that instead of adding JPRT >> targets or more work to do in JPRT is to simply make linux x64 at >> least default to non-PCH. It would break less frequently because >> that's the default and the side benefit is that when you're working >> and editing a header file, you don't get the whole JVM recompiled. IE. >> I would prefer if this were the default so I don't have to add yet >> another option to my configure script. >> >>> >>> Simply switching the default just creates a different problem. >>> Engineers will use PCH locally and so may encounter issues if PCH has >>> not been tested at integration time. >>> >> >> It seems that the converse is more likely though. If something >> compiles without PCH it's very likely to compile with PCH. >> >> I'd prefer the default changed and not find whether I broke PCH with >> JPRT. >> >> thanks, >> Coleen >> >>> I plan to fix this in JPRT by making a few configurations non-PCH. >>> >>> David >>> ----- >>> >>>> Making this option the default for the JPRT builds only will guard >>>> against the build errors described before while it still allows >>>> everybody to do local builds at full speed. >>>> >>>> Regards, >>>> Volker >>>> >>>> On 4/21/15, Coleen Phillimore wrote: >>>>> >>>>> Can we just switch the default instead? Is that a simple makefile >>>>> change? >>>>> Coleen >>>>> >>>>> On 4/17/15, 6:35 AM, Lindenmaier, Goetz wrote: >>>>>> That would be great!! >>>>>> >>>>>> Thanks David, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Freitag, 17. April 2015 12:23 >>>>>> To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn >>>>>> Cc: HotSpot Open Source Developers >>>>>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >>>>>> >>>>>> On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> another occurance of this ... please, please add a non-pch build to >>>>>>> jprt! >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8078048 >>>>>> I will. Unfortunately first I have some no-PCH issues to address. And >>>>>> unfortunately they are not top of my priority list right now. >>>>>> Hopefully >>>>>> next week sometime. >>>>>> >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] >>>>>>> On Behalf >>>>>>> Of Volker Simonis >>>>>>> Sent: Donnerstag, 9. April 2015 11:35 >>>>>>> To: Andrew Dinn >>>>>>> Cc: HotSpot Open Source Developers >>>>>>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! >>>>>>> >>>>>>> On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn >>>>>>> wrote: >>>>>>>> On 09/04/15 09:02, Erik Joelsson wrote: >>>>>>>>> I think that as long as we claim to support building both with and >>>>>>>>> without PCH, the automatic testing should test both with and >>>>>>>>> without >>>>>>>>> PCH. By adding one or two build targets, or perhaps change an >>>>>>>>> existing >>>>>>>>> target, we could increase our test matrix to cover this easily. >>>>>>>> I think this restates Volker's original remarks in redux. >>>>>>>> >>>>>>> No, not at all! I don't necessarily want to test more build >>>>>>> configurations (that's another topic). >>>>>>> >>>>>>> My point is that PCH changes the compilation semantics and can hide >>>>>>> real program errors. That's because with PCHs, every compilation >>>>>>> unit >>>>>>> sees the full precompiled header database (i.e. all the headers >>>>>>> which >>>>>>> are included in the "precompiled.hpp" PCH file). So if somebody >>>>>>> forgets to include a dependency X.hpp in A.cpp, A.cpp may still >>>>>>> compile with PCH because it includes the precompiled header file >>>>>>> "precompiled.hpp" which in turn includes X.hpp. But the >>>>>>> compilation of >>>>>>> A.cpp will fail on platforms/configurations where we do not use >>>>>>> precompiled headers. The two references I gave in my original >>>>>>> mail are >>>>>>> bugs that resulted from this problem. >>>>>>> >>>>>>> Besides program errors, the use of PCH can also lead to behavioral >>>>>>> changes in the created binary when it comes to inlining. Because of >>>>>>> PCHs some compilation units may be able to inline methods even if >>>>>>> they >>>>>>> do not explicitly include the files which contain the corresponding >>>>>>> implementations because the implementation files are included in the >>>>>>> PCH file. Without PCHs the compilers will simply emit calls to these >>>>>>> functions (and, depending on the toolchain, emit a warning). >>>>>>> >>>>>>> I'm not familiar with ccache so I can not say if it has similar >>>>>>> effects. >>>>>>> >>>>>>>> So, given that we do need this (NOW! :-) is anyone able and >>>>>>>> willing to >>>>>>>> sponsor this? >>>>>>>> >>>>>>> Yes, this question remains to be answered :) >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>>> regards, >>>>>>>> >>>>>>>> >>>>>>>> Andrew Dinn >>>>>>>> ----------- >>>>>>>> >>>>> >>>>> >> >> >> > -- 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 sgehwolf at redhat.com Thu Apr 23 10:30:55 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Apr 2015 12:30:55 +0200 Subject: RFR(xs): 8078504: Zero fails to build. Message-ID: <1429785055.3437.6.camel@redhat.com> Hi, Could somebody please review and sponsor this trivial Zero build fix? It concerns files in the zero directory only. Bug: https://bugs.openjdk.java.net/browse/JDK-8078504 Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8078504/webrev.01/ One issue was caused by JDK-8026049 since it added a VM_Version::initialize() function which wasn't declared. The other issue concerned a missing include file. After this change Zero again builds for all variants: release, fastdebug, slowdebug. Thanks, Severin From thomas.schatzl at oracle.com Thu Apr 23 11:16:57 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 23 Apr 2015 13:16:57 +0200 Subject: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index In-Reply-To: <5538B2C5.3040404@oracle.com> References: <5538B2C5.3040404@oracle.com> Message-ID: <1429787817.3334.3.camel@oracle.com> Hi, On Thu, 2015-04-23 at 10:52 +0200, Per Liden wrote: > Hi, > > (This change affects G1, but it's touching code in C1 so I'd like to ask > someone from the compiler team to also reviewed this) > > Summary: The G1 barriers loads and updates the PrtQueue::_index field. > This field is a size_t but the C1 version of these barriers aren't > 64-bit clean. The bug has more details. > > In addition I've massaged the code a little bit, so that the 32-bit and > 64-bit sections look more similar (and as a bonus I think we avoid an > extra memory load on 32-bit). > > Webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8013171 > > Testing: > * gc-test-suite on both 32 and 64-bit builds (with -XX:+UseG1GC > -XX:+TieredCompilation -XX:TieredStopAtLevel=3 -XX:+VerifyAfterGC) > * Passes jprt Looks good, with the following caveats which should be decided by somebody else if they are important as they are micro-opts: - instead of using cmp to compare against zero in a register, it would be better to use the test instruction (e.g. __ testX(tmp, tmp)) as it saves a byte of encoding per instruction with the same effect. - post barrier stub: I would prefer if the 64 bit code did not push/pop the rdx register to free tmp. There are explicit rscratch1/2 registers for temporaries available on that platform. At least rscratch1 (=r8) seems to be used without save/restore in the original code already. This would also remove the need for 64 bit code to push/pop any register it seems to me. - the original code only pushed/popped rbx when there was need to. Now the generated code pushes/pops rdx always. In general, the new code is easier to follow (and unifies 32/64 bit code paths), but seems slightly worse in execution time to me (without testing, just gut feeling). It probably won't matter at the end of the day. Thanks, Thomas From adinn at redhat.com Thu Apr 23 11:37:35 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 23 Apr 2015 12:37:35 +0100 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <553827B6.9000800@oracle.com> References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com> <553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com> <55376318.7070604@redhat.com> <553827B6.9000800@oracle.com> Message-ID: <5538D97F.8080003@redhat.com> On 22/04/15 23:59, Vladimir Kozlov wrote: > First, I am fine with your changes. I thought that may be adding some > shared code (flag?) will simplify (reduce) your change. But based on > your answer it is not the case. So I am fine with you changes. Thanks Vladimir. Andrew (Haley), since this has been reviewed by you as well and is an AArch64 only change does that mean you can now push a patch? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From roland.westrelin at oracle.com Thu Apr 23 11:43:40 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 23 Apr 2015 13:43:40 +0200 Subject: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index In-Reply-To: <5538B2C5.3040404@oracle.com> References: <5538B2C5.3040404@oracle.com> Message-ID: > Webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.0/ movptr is movq/movl, cmpptr is cmpq/cmpl and subptr is subq/subl on 32bits/64bits so you could replace: 1654 #ifdef _LP64 1655 __ movq(tmp, queue_index); 1656 __ cmpq(tmp, 0); 1657 #else 1658 __ movl(tmp, queue_index); 1659 __ cmpl(tmp, 0); 1660 #endif 1661 __ jcc(Assembler::equal, runtime); 1662 #ifdef _LP64 1663 __ subq(tmp, wordSize); 1664 __ movq(queue_index, tmp); 1665 #else 1666 __ subl(tmp, wordSize); 1667 __ movl(queue_index, tmp); 1668 #endif with: __ movptr(tmp, queue_index); __ cmpptr(tmp, 0); __ jcc(Assembler::equal, runtime); __ subptr(tmp, wordSize); __ movptr(queue_index, tmp); even if the quantities that are manipulated are not actual pointers, unless I miss something. Roland. From aph at redhat.com Thu Apr 23 11:57:02 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Apr 2015 12:57:02 +0100 Subject: RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr In-Reply-To: <5538D97F.8080003@redhat.com> References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com> <553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com> <55376318.7070604@redhat.com> <553827B6.9000800@oracle.com> <5538D97F.8080003@redhat.com> Message-ID: <5538DE0E.4090205@redhat.com> On 04/23/2015 12:37 PM, Andrew Dinn wrote: > On 22/04/15 23:59, Vladimir Kozlov wrote: >> First, I am fine with your changes. I thought that may be adding some >> shared code (flag?) will simplify (reduce) your change. But based on >> your answer it is not the case. So I am fine with you changes. > > Thanks Vladimir. > > Andrew (Haley), since this has been reviewed by you as well and is an > AArch64 only change does that mean you can now push a patch? Yes, I will. Andrew. From thomas.stuefe at gmail.com Thu Apr 23 12:15:40 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Apr 2015 14:15:40 +0200 Subject: Do we plan to get rid of LinuxThreads support anytime soon? Message-ID: Hi all, How long do we plan to continue support for LinuxThreads (vs NPTL) Linux variants? There would be some coding in os/linux which could be thrown away if we stopped supporting LinuxThreads. If we do not get rid of it: does Oracle still run tests on Linux variants which use LinuxThreads? Thanks! Regards, Thomas From staffan.larsen at oracle.com Thu Apr 23 12:22:02 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Apr 2015 14:22:02 +0200 Subject: Do we plan to get rid of LinuxThreads support anytime soon? In-Reply-To: References: Message-ID: <2A4EA52D-E53D-457F-8C50-C2AD54569BD0@oracle.com> I don?t think there is any reason to keep the LinuxThreads code anymore. It would be a welcome cleanup. /Staffan > On 23 apr 2015, at 14:15, Thomas St?fe wrote: > > Hi all, > > How long do we plan to continue support for LinuxThreads (vs NPTL) Linux > variants? There would be some coding in os/linux which could be thrown away > if we stopped supporting LinuxThreads. > > If we do not get rid of it: does Oracle still run tests on Linux variants > which use LinuxThreads? > > Thanks! > > Regards, Thomas From thomas.stuefe at gmail.com Thu Apr 23 12:25:01 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Apr 2015 14:25:01 +0200 Subject: Do we plan to get rid of LinuxThreads support anytime soon? In-Reply-To: <2A4EA52D-E53D-457F-8C50-C2AD54569BD0@oracle.com> References: <2A4EA52D-E53D-457F-8C50-C2AD54569BD0@oracle.com> Message-ID: :-) ok then. We will clean this up. ..Thomas On Thu, Apr 23, 2015 at 2:22 PM, Staffan Larsen wrote: > I don?t think there is any reason to keep the LinuxThreads code anymore. > It would be a welcome cleanup. > > /Staffan > > > > On 23 apr 2015, at 14:15, Thomas St?fe wrote: > > > > Hi all, > > > > How long do we plan to continue support for LinuxThreads (vs NPTL) Linux > > variants? There would be some coding in os/linux which could be thrown > away > > if we stopped supporting LinuxThreads. > > > > If we do not get rid of it: does Oracle still run tests on Linux variants > > which use LinuxThreads? > > > > Thanks! > > > > Regards, Thomas > > From volker.simonis at gmail.com Thu Apr 23 12:34:15 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Apr 2015 14:34:15 +0200 Subject: RFR(L): 8077838: Recent developments for ppc. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, this change is huge and not easy to review:) So far I only found one mis-aligned comment in vm_version_ppc.cpp: + a->vand(VR0, VR0, VR0); // code[8] -> vand + a->lqarx_unchecked(R7, R3_ARG1, R4_ARG2, 1); // code[9] -> lqarx_m + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher Besides that, the change looks good. Thanks for taking the effort to do this change! Regards, Volker On Wed, Apr 22, 2015 at 11:34 AM, Lindenmaier, Goetz wrote: > Hi, > > this change contains recent changes in the ppc directory mostly made by SAP. > It's a ppc-only change. > http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ > > - Recognition of Power 8 processors (by Tiago Sturmer Daitx). > - Support for more new Power 8 instructions. > - Support for transactional memory. This is implemented but not yet tested > thoroughly due to limitiations of the OS support. Not enabled. > - java.lang.math.*Exact intrinsics > - Some C2 optimizations and fixes: > * Handling of flag registers. Some instructions would lead to uncompilable > methods due to not allocatable register patterns. > * Free some integer registers to use them for allocation. Handle compressed > oops base as constant. > * Unscaled class compression. > - Type profiling fixes. > > Please review this change. > > Best regards, > Goetz. > > From david.holmes at oracle.com Thu Apr 23 12:34:50 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Apr 2015 22:34:50 +1000 Subject: Do we plan to get rid of LinuxThreads support anytime soon? In-Reply-To: References: Message-ID: <5538E6EA.2010906@oracle.com> On 23/04/2015 10:15 PM, Thomas St?fe wrote: > Hi all, > > How long do we plan to continue support for LinuxThreads (vs NPTL) Linux > variants? There would be some coding in os/linux which could be thrown away > if we stopped supporting LinuxThreads. > > If we do not get rid of it: does Oracle still run tests on Linux variants > which use LinuxThreads? LinuxThreads is "dead". We do not support it at all and have not for a long time. IIRC some LinuxThreads code has been removed in places when other changes have occurred. There was a big clean up of this slated but I don't know what happened to it - I guess adding new features took priority. :( David > Thanks! > > Regards, Thomas > From thomas.stuefe at gmail.com Thu Apr 23 12:46:53 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Apr 2015 14:46:53 +0200 Subject: Do we plan to get rid of LinuxThreads support anytime soon? In-Reply-To: <5538E6EA.2010906@oracle.com> References: <5538E6EA.2010906@oracle.com> Message-ID: Nice to know. Thanks! On Thu, Apr 23, 2015 at 2:34 PM, David Holmes wrote: > On 23/04/2015 10:15 PM, Thomas St?fe wrote: > >> Hi all, >> >> How long do we plan to continue support for LinuxThreads (vs NPTL) Linux >> variants? There would be some coding in os/linux which could be thrown >> away >> if we stopped supporting LinuxThreads. >> >> If we do not get rid of it: does Oracle still run tests on Linux variants >> which use LinuxThreads? >> > > LinuxThreads is "dead". We do not support it at all and have not for a > long time. IIRC some LinuxThreads code has been removed in places when > other changes have occurred. There was a big clean up of this slated but I > don't know what happened to it - I guess adding new features took priority. > :( > > David > > Thanks! >> >> Regards, Thomas >> >> From goetz.lindenmaier at sap.com Thu Apr 23 12:56:43 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Apr 2015 12:56:43 +0000 Subject: RFR(L): 8077838: Recent developments for ppc. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC0AD6@DEWDFEMB12A.global.corp.sap> Thanks fort he review, Volker! I updated the webrev with your and Vladimir's proposals: http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.02/ Best regards, Goetz. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Donnerstag, 23. April 2015 14:34 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(L): 8077838: Recent developments for ppc. Hi Goetz, this change is huge and not easy to review:) So far I only found one mis-aligned comment in vm_version_ppc.cpp: + a->vand(VR0, VR0, VR0); // code[8] -> vand + a->lqarx_unchecked(R7, R3_ARG1, R4_ARG2, 1); // code[9] -> lqarx_m + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher Besides that, the change looks good. Thanks for taking the effort to do this change! Regards, Volker On Wed, Apr 22, 2015 at 11:34 AM, Lindenmaier, Goetz wrote: > Hi, > > this change contains recent changes in the ppc directory mostly made by SAP. > It's a ppc-only change. > http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ > > - Recognition of Power 8 processors (by Tiago Sturmer Daitx). > - Support for more new Power 8 instructions. > - Support for transactional memory. This is implemented but not yet tested > thoroughly due to limitiations of the OS support. Not enabled. > - java.lang.math.*Exact intrinsics > - Some C2 optimizations and fixes: > * Handling of flag registers. Some instructions would lead to uncompilable > methods due to not allocatable register patterns. > * Free some integer registers to use them for allocation. Handle compressed > oops base as constant. > * Unscaled class compression. > - Type profiling fixes. > > Please review this change. > > Best regards, > Goetz. > > From aph at redhat.com Thu Apr 23 12:58:44 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Apr 2015 13:58:44 +0100 Subject: SA doesn't seem to work with dev tree Message-ID: <5538EC84.5050605@redhat.com> This is x86_64, dev tree, just checked out and built. I'm trying to run HSDB. Is this a known bug? Thanks, Andrew. From aph at redhat.com Thu Apr 23 13:01:01 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Apr 2015 14:01:01 +0100 Subject: SA doesn't seem to work with dev tree In-Reply-To: <5538EC84.5050605@redhat.com> References: <5538EC84.5050605@redhat.com> Message-ID: <5538ED0D.3050701@redhat.com> On 04/23/2015 01:58 PM, Andrew Haley wrote: > This is x86_64, dev tree, just checked out and built. > > I'm trying to run HSDB. > > Is this a known bug? The mailing list ate the attached JPEG. The error is: Unable to connect to process java.lang.RuntimeException: Missing property sun.jvm.runtime.VM.saBuildVersion Andrew. From staffan.larsen at oracle.com Thu Apr 23 13:01:25 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Apr 2015 15:01:25 +0200 Subject: SA doesn't seem to work with dev tree In-Reply-To: <5538EC84.5050605@redhat.com> References: <5538EC84.5050605@redhat.com> Message-ID: <08AF5BC3-B4D0-4A87-B2E2-CB8EEABA2339@oracle.com> Can you be more specific - what errors do you see? > On 23 apr 2015, at 14:58, Andrew Haley wrote: > > This is x86_64, dev tree, just checked out and built. > > I'm trying to run HSDB. > > Is this a known bug? > > Thanks, > Andrew. > > From per.liden at oracle.com Thu Apr 23 13:07:22 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 23 Apr 2015 15:07:22 +0200 Subject: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index In-Reply-To: References: <5538B2C5.3040404@oracle.com> Message-ID: <5538EE8A.9010503@oracle.com> Hi Roland, On 2015-04-23 13:43, Roland Westrelin wrote: >> Webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.0/ > > movptr is movq/movl, cmpptr is cmpq/cmpl and subptr is subq/subl on 32bits/64bits so you could replace: > > > 1654 #ifdef _LP64 > 1655 __ movq(tmp, queue_index); > 1656 __ cmpq(tmp, 0); > 1657 #else > 1658 __ movl(tmp, queue_index); > 1659 __ cmpl(tmp, 0); > 1660 #endif > 1661 __ jcc(Assembler::equal, runtime); > 1662 #ifdef _LP64 > 1663 __ subq(tmp, wordSize); > 1664 __ movq(queue_index, tmp); > > 1665 #else > 1666 __ subl(tmp, wordSize); > 1667 __ movl(queue_index, tmp); > > 1668 #endif > > with: > > __ movptr(tmp, queue_index); > __ cmpptr(tmp, 0); > __ jcc(Assembler::equal, runtime); > __ subptr(tmp, wordSize); > __ movptr(queue_index, tmp); > > even if the quantities that are manipulated are not actual pointers, unless I miss something. Thanks for looking at this! Yes, it happens to be the same thing is this case, but bordering on being sloppy given that it's not a pointer. But if this is the preferred way then I can live with that. Updated webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.1/ /Per From mikael.gerdin at oracle.com Thu Apr 23 13:10:42 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 23 Apr 2015 15:10:42 +0200 Subject: SA doesn't seem to work with dev tree In-Reply-To: <5538ED0D.3050701@redhat.com> References: <5538EC84.5050605@redhat.com> <5538ED0D.3050701@redhat.com> Message-ID: <5538EF52.4030105@oracle.com> Andrew, On 2015-04-23 15:01, Andrew Haley wrote: > On 04/23/2015 01:58 PM, Andrew Haley wrote: >> This is x86_64, dev tree, just checked out and built. >> >> I'm trying to run HSDB. >> >> Is this a known bug? > > The mailing list ate the attached JPEG. > > The error is: > > Unable to connect to process > > java.lang.RuntimeException: Missing property > sun.jvm.runtime.VM.saBuildVersion I think you need to "make images" and run SA from the image. It loads the property file as a resource to figure out which build version it should use, but the exploded-image make target does not put the SA property file on the class path. /Mikael > > Andrew. > From aph at redhat.com Thu Apr 23 13:19:34 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Apr 2015 14:19:34 +0100 Subject: SA doesn't seem to work with dev tree In-Reply-To: <5538EF52.4030105@oracle.com> References: <5538EC84.5050605@redhat.com> <5538ED0D.3050701@redhat.com> <5538EF52.4030105@oracle.com> Message-ID: <5538F166.7080704@redhat.com> On 04/23/2015 02:10 PM, Mikael Gerdin wrote: > Andrew, > > On 2015-04-23 15:01, Andrew Haley wrote: >> On 04/23/2015 01:58 PM, Andrew Haley wrote: >>> This is x86_64, dev tree, just checked out and built. >>> >>> I'm trying to run HSDB. >>> >>> Is this a known bug? >> >> The mailing list ate the attached JPEG. >> >> The error is: >> >> Unable to connect to process >> >> java.lang.RuntimeException: Missing property >> sun.jvm.runtime.VM.saBuildVersion > > I think you need to "make images" and run SA from the image. > It loads the property file as a resource to figure out which build > version it should use, but the exploded-image make target does not put > the SA property file on the class path. Ah, I would never have thought of that. Thanks. And indeed it works just fine. Andrew. From staffan.larsen at oracle.com Thu Apr 23 13:21:24 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Apr 2015 15:21:24 +0200 Subject: SA doesn't seem to work with dev tree In-Reply-To: <5538ED0D.3050701@redhat.com> References: <5538EC84.5050605@redhat.com> <5538ED0D.3050701@redhat.com> Message-ID: It works in an ?images? build, but not in the default target. Running with -Dsun.jvm.hotspot.runtime.VM.disableVersionCheck=true on an ?images? works as a workaround. I?m not sure why this happens. /Staffan > On 23 apr 2015, at 15:01, Andrew Haley wrote: > > On 04/23/2015 01:58 PM, Andrew Haley wrote: >> This is x86_64, dev tree, just checked out and built. >> >> I'm trying to run HSDB. >> >> Is this a known bug? > > The mailing list ate the attached JPEG. > > The error is: > > Unable to connect to process > > java.lang.RuntimeException: Missing property > sun.jvm.runtime.VM.saBuildVersion > > Andrew. > From staffan.larsen at oracle.com Thu Apr 23 13:24:02 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Apr 2015 15:24:02 +0200 Subject: SA doesn't seem to work with dev tree In-Reply-To: <5538EF52.4030105@oracle.com> References: <5538EC84.5050605@redhat.com> <5538ED0D.3050701@redhat.com> <5538EF52.4030105@oracle.com> Message-ID: > On 23 apr 2015, at 15:10, Mikael Gerdin wrote: > > Andrew, > > On 2015-04-23 15:01, Andrew Haley wrote: >> On 04/23/2015 01:58 PM, Andrew Haley wrote: >>> This is x86_64, dev tree, just checked out and built. >>> >>> I'm trying to run HSDB. >>> >>> Is this a known bug? >> >> The mailing list ate the attached JPEG. >> >> The error is: >> >> Unable to connect to process >> >> java.lang.RuntimeException: Missing property >> sun.jvm.runtime.VM.saBuildVersion > > I think you need to "make images" and run SA from the image. > It loads the property file as a resource to figure out which build version it should use, but the exploded-image make target does not put the SA property file on the class path. Ah right. I wonder if it was the modularized build that broke this. /Staffan > > /Mikael > >> >> Andrew. From volker.simonis at gmail.com Thu Apr 23 13:32:45 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Apr 2015 15:32:45 +0200 Subject: RFR(xs): 8078504: Zero fails to build. In-Reply-To: <1429785055.3437.6.camel@redhat.com> References: <1429785055.3437.6.camel@redhat.com> Message-ID: Hi Severin, the change looks good. I can sponsor it and push it for you once you get one more review. Regards, Volker On Thu, Apr 23, 2015 at 12:30 PM, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this trivial Zero build fix? It > concerns files in the zero directory only. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8078504 > Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8078504/webrev.01/ > > One issue was caused by JDK-8026049 since it added a > VM_Version::initialize() function which wasn't declared. The other issue > concerned a missing include file. > > After this change Zero again builds for all variants: release, > fastdebug, slowdebug. > > Thanks, > Severin > From roland.westrelin at oracle.com Thu Apr 23 13:32:41 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 23 Apr 2015 15:32:41 +0200 Subject: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index In-Reply-To: <5538EE8A.9010503@oracle.com> References: <5538B2C5.3040404@oracle.com> <5538EE8A.9010503@oracle.com> Message-ID: <33D0E9FE-ADF6-4BEE-8AD2-23D2B3EBA07A@oracle.com> > Yes, it happens to be the same thing is this case, but bordering on being sloppy given that it's not a pointer. But if this is the preferred way then I can live with that. You could add a comment that says you?re using the *ptr variants for non pointer things. I don?t know if it?s the preferred way but that?s what I would do because less #ifdef makes the code easier to read. > Updated webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.1/ That looks good to me. Roland. From sgehwolf at redhat.com Thu Apr 23 13:51:14 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Apr 2015 15:51:14 +0200 Subject: RFR(xs): 8078504: Zero fails to build. In-Reply-To: References: <1429785055.3437.6.camel@redhat.com> Message-ID: <1429797074.3437.12.camel@redhat.com> Hi Volker, On Thu, 2015-04-23 at 15:32 +0200, Volker Simonis wrote: > Hi Severin, > > the change looks good. I can sponsor it and push it for you once you > get one more review. Thank you very much! Could I get a second review, please? Cheers, Severin > Regards, > Volker > > > On Thu, Apr 23, 2015 at 12:30 PM, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review and sponsor this trivial Zero build fix? It > > concerns files in the zero directory only. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8078504 > > Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8078504/webrev.01/ > > > > One issue was caused by JDK-8026049 since it added a > > VM_Version::initialize() function which wasn't declared. The other issue > > concerned a missing include file. > > > > After this change Zero again builds for all variants: release, > > fastdebug, slowdebug. > > > > Thanks, > > Severin > > From staffan.larsen at oracle.com Thu Apr 23 14:18:20 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Apr 2015 16:18:20 +0200 Subject: SA doesn't seem to work with dev tree In-Reply-To: References: <5538EC84.5050605@redhat.com> <5538ED0D.3050701@redhat.com> <5538EF52.4030105@oracle.com> Message-ID: <1207CC55-73A4-4A6C-9904-3E7A7BEA0C7C@oracle.com> Filed https://bugs.openjdk.java.net/browse/JDK-8078519 and sent a review to serviceability-dev. Thanks, /Staffan > On 23 apr 2015, at 15:24, Staffan Larsen wrote: > > >> On 23 apr 2015, at 15:10, Mikael Gerdin wrote: >> >> Andrew, >> >> On 2015-04-23 15:01, Andrew Haley wrote: >>> On 04/23/2015 01:58 PM, Andrew Haley wrote: >>>> This is x86_64, dev tree, just checked out and built. >>>> >>>> I'm trying to run HSDB. >>>> >>>> Is this a known bug? >>> >>> The mailing list ate the attached JPEG. >>> >>> The error is: >>> >>> Unable to connect to process >>> >>> java.lang.RuntimeException: Missing property >>> sun.jvm.runtime.VM.saBuildVersion >> >> I think you need to "make images" and run SA from the image. >> It loads the property file as a resource to figure out which build version it should use, but the exploded-image make target does not put the SA property file on the class path. > > Ah right. I wonder if it was the modularized build that broke this. > > /Staffan > >> >> /Mikael >> >>> >>> Andrew. > From vladimir.kozlov at oracle.com Thu Apr 23 14:24:28 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Apr 2015 07:24:28 -0700 Subject: RFR(L): 8077838: Recent developments for ppc. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC0988@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> <55382B97.8080606@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC0988@DEWDFEMB12A.global.corp.sap> Message-ID: <5539009C.7050101@oracle.com> On 4/23/15 1:27 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for the review! > > These methods actually do an atomic update of a memory location, so the name > really describes what is happening. May be I need some PPC education. There are several instructions and branch. Is that some kind of transaction? Thanks, Vladimir > > I'll remove the change to interpreter_ppc.cpp and runtime_ppc.cpp. > > Best regards, > Goetz > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 23. April 2015 01:16 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(L): 8077838: Recent developments for ppc. > > Why call methods 'atomic': atomic_inc_ptr() and atomic_ori_int()? > > Do you really need to change runtime_ppc.cpp only to remove empty line? > > Looks fine otherwise. > > Vladimir > > On 4/22/15 2:34 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> this change contains recent changes in the ppc directory mostly made by SAP. >> It's a ppc-only change. >> http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ >> >> - Recognition of Power 8 processors (by Tiago Sturmer Daitx). >> - Support for more new Power 8 instructions. >> - Support for transactional memory. This is implemented but not yet tested >> thoroughly due to limitiations of the OS support. Not enabled. >> - java.lang.math.*Exact intrinsics >> - Some C2 optimizations and fixes: >> * Handling of flag registers. Some instructions would lead to uncompilable >> methods due to not allocatable register patterns. >> * Free some integer registers to use them for allocation. Handle compressed >> oops base as constant. >> * Unscaled class compression. >> - Type profiling fixes. >> >> Please review this change. >> >> Best regards, >> Goetz. >> >> From vladimir.kozlov at oracle.com Thu Apr 23 14:26:35 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Apr 2015 07:26:35 -0700 Subject: RFR(S): 8078482: ppc: pass thread to throw_AbstractMethodError In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC09A0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC09A0@DEWDFEMB12A.global.corp.sap> Message-ID: <5539011B.1010300@oracle.com> What is the change in os_linux_ppc.cpp? Vladimir On 4/23/15 1:35 AM, Lindenmaier, Goetz wrote: > Hi, > > this fixes an issue detected by Tiago Sturmer Daitix in the jdk7 ppc port. > The thread argument was left out in a call to throw_AbstractMethodError. > > Please review this change. It needs to go to jdk8u, too. It's ppc only. > http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.01/ > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Thu Apr 23 14:30:33 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Apr 2015 07:30:33 -0700 Subject: RFR(xs): 8078504: Zero fails to build. In-Reply-To: <1429797074.3437.12.camel@redhat.com> References: <1429785055.3437.6.camel@redhat.com> <1429797074.3437.12.camel@redhat.com> Message-ID: <55390209.1010004@oracle.com> Looks good. Vladimir On 4/23/15 6:51 AM, Severin Gehwolf wrote: > Hi Volker, > > On Thu, 2015-04-23 at 15:32 +0200, Volker Simonis wrote: >> Hi Severin, >> >> the change looks good. I can sponsor it and push it for you once you >> get one more review. > > Thank you very much! > > Could I get a second review, please? > > Cheers, > Severin > >> Regards, >> Volker >> >> >> On Thu, Apr 23, 2015 at 12:30 PM, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review and sponsor this trivial Zero build fix? It >>> concerns files in the zero directory only. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078504 >>> Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8078504/webrev.01/ >>> >>> One issue was caused by JDK-8026049 since it added a >>> VM_Version::initialize() function which wasn't declared. The other issue >>> concerned a missing include file. >>> >>> After this change Zero again builds for all variants: release, >>> fastdebug, slowdebug. >>> >>> Thanks, >>> Severin >>> > > > From goetz.lindenmaier at sap.com Thu Apr 23 14:37:55 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Apr 2015 14:37:55 +0000 Subject: RFR(L): 8077838: Recent developments for ppc. In-Reply-To: <5539009C.7050101@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> <55382B97.8080606@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC0988@DEWDFEMB12A.global.corp.sap> <5539009C.7050101@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC0BD6@DEWDFEMB12A.global.corp.sap> Hi Vladimir, Yes, the ldarx and stdcx are a pair. The store is only executed if the memory didn't change since the load was done. Else a condition is set. The condition is used to repeat the sequence. Best regards, Goetz. http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/ldarx.htm%23i806971708sls http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/stdcx_dot.htm%23i807971239sls?lang=en -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 23. April 2015 16:24 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: Re: RFR(L): 8077838: Recent developments for ppc. On 4/23/15 1:27 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for the review! > > These methods actually do an atomic update of a memory location, so the name > really describes what is happening. May be I need some PPC education. There are several instructions and branch. Is that some kind of transaction? Thanks, Vladimir > > I'll remove the change to interpreter_ppc.cpp and runtime_ppc.cpp. > > Best regards, > Goetz > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 23. April 2015 01:16 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(L): 8077838: Recent developments for ppc. > > Why call methods 'atomic': atomic_inc_ptr() and atomic_ori_int()? > > Do you really need to change runtime_ppc.cpp only to remove empty line? > > Looks fine otherwise. > > Vladimir > > On 4/22/15 2:34 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> this change contains recent changes in the ppc directory mostly made by SAP. >> It's a ppc-only change. >> http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ >> >> - Recognition of Power 8 processors (by Tiago Sturmer Daitx). >> - Support for more new Power 8 instructions. >> - Support for transactional memory. This is implemented but not yet tested >> thoroughly due to limitiations of the OS support. Not enabled. >> - java.lang.math.*Exact intrinsics >> - Some C2 optimizations and fixes: >> * Handling of flag registers. Some instructions would lead to uncompilable >> methods due to not allocatable register patterns. >> * Free some integer registers to use them for allocation. Handle compressed >> oops base as constant. >> * Unscaled class compression. >> - Type profiling fixes. >> >> Please review this change. >> >> Best regards, >> Goetz. >> >> From vladimir.kozlov at oracle.com Thu Apr 23 14:38:59 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Apr 2015 07:38:59 -0700 Subject: RFR(L): 8077838: Recent developments for ppc. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC0AD6@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CFC0AD6@DEWDFEMB12A.global.corp.sap> Message-ID: <55390403.1000607@oracle.com> Good. Thanks, Vladimir On 4/23/15 5:56 AM, Lindenmaier, Goetz wrote: > Thanks fort he review, Volker! > > I updated the webrev with your and Vladimir's proposals: > http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.02/ > > Best regards, > Goetz. > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Donnerstag, 23. April 2015 14:34 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(L): 8077838: Recent developments for ppc. > > Hi Goetz, > > this change is huge and not easy to review:) > > So far I only found one mis-aligned comment in vm_version_ppc.cpp: > > + a->vand(VR0, VR0, VR0); // code[8] -> vand > + a->lqarx_unchecked(R7, R3_ARG1, R4_ARG2, 1); // code[9] -> lqarx_m > + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher > > Besides that, the change looks good. > > Thanks for taking the effort to do this change! > > Regards, > Volker > > On Wed, Apr 22, 2015 at 11:34 AM, Lindenmaier, Goetz > wrote: >> Hi, >> >> this change contains recent changes in the ppc directory mostly made by SAP. >> It's a ppc-only change. >> http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ >> >> - Recognition of Power 8 processors (by Tiago Sturmer Daitx). >> - Support for more new Power 8 instructions. >> - Support for transactional memory. This is implemented but not yet tested >> thoroughly due to limitiations of the OS support. Not enabled. >> - java.lang.math.*Exact intrinsics >> - Some C2 optimizations and fixes: >> * Handling of flag registers. Some instructions would lead to uncompilable >> methods due to not allocatable register patterns. >> * Free some integer registers to use them for allocation. Handle compressed >> oops base as constant. >> * Unscaled class compression. >> - Type profiling fixes. >> >> Please review this change. >> >> Best regards, >> Goetz. >> >> From vladimir.kozlov at oracle.com Thu Apr 23 14:40:14 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Apr 2015 07:40:14 -0700 Subject: RFR(L): 8077838: Recent developments for ppc. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC0BD6@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> <55382B97.8080606@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC0988@DEWDFEMB12A.global.corp.sap> <5539009C.7050101@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC0BD6@DEWDFEMB12A.global.corp.sap> Message-ID: <5539044E.2020503@oracle.com> Thank you for explaining. Last webrev looks fine. Vladimir On 4/23/15 7:37 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > Yes, the ldarx and stdcx are a pair. The store is only executed > if the memory didn't change since the load was done. > Else a condition is set. > The condition is used to repeat the sequence. > > Best regards, > Goetz. > > http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/ldarx.htm%23i806971708sls > http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/stdcx_dot.htm%23i807971239sls?lang=en > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Donnerstag, 23. April 2015 16:24 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net > Subject: Re: RFR(L): 8077838: Recent developments for ppc. > > On 4/23/15 1:27 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> These methods actually do an atomic update of a memory location, so the name >> really describes what is happening. > > May be I need some PPC education. There are several instructions and branch. Is that some kind of transaction? > > Thanks, > Vladimir > >> >> I'll remove the change to interpreter_ppc.cpp and runtime_ppc.cpp. >> >> Best regards, >> Goetz >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Donnerstag, 23. April 2015 01:16 >> To: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(L): 8077838: Recent developments for ppc. >> >> Why call methods 'atomic': atomic_inc_ptr() and atomic_ori_int()? >> >> Do you really need to change runtime_ppc.cpp only to remove empty line? >> >> Looks fine otherwise. >> >> Vladimir >> >> On 4/22/15 2:34 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> this change contains recent changes in the ppc directory mostly made by SAP. >>> It's a ppc-only change. >>> http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ >>> >>> - Recognition of Power 8 processors (by Tiago Sturmer Daitx). >>> - Support for more new Power 8 instructions. >>> - Support for transactional memory. This is implemented but not yet tested >>> thoroughly due to limitiations of the OS support. Not enabled. >>> - java.lang.math.*Exact intrinsics >>> - Some C2 optimizations and fixes: >>> * Handling of flag registers. Some instructions would lead to uncompilable >>> methods due to not allocatable register patterns. >>> * Free some integer registers to use them for allocation. Handle compressed >>> oops base as constant. >>> * Unscaled class compression. >>> - Type profiling fixes. >>> >>> Please review this change. >>> >>> Best regards, >>> Goetz. >>> >>> From goetz.lindenmaier at sap.com Thu Apr 23 14:57:17 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Apr 2015 14:57:17 +0000 Subject: RFR(L): 8077838: Recent developments for ppc. In-Reply-To: <5539044E.2020503@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFC0467@DEWDFEMB12A.global.corp.sap> <55382B97.8080606@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC0988@DEWDFEMB12A.global.corp.sap> <5539009C.7050101@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC0BD6@DEWDFEMB12A.global.corp.sap> <5539044E.2020503@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC0C60@DEWDFEMB12A.global.corp.sap> Thanks, Vladimir! Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 23. April 2015 16:40 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: Re: RFR(L): 8077838: Recent developments for ppc. Thank you for explaining. Last webrev looks fine. Vladimir On 4/23/15 7:37 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > Yes, the ldarx and stdcx are a pair. The store is only executed > if the memory didn't change since the load was done. > Else a condition is set. > The condition is used to repeat the sequence. > > Best regards, > Goetz. > > http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/ldarx.htm%23i806971708sls > http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/stdcx_dot.htm%23i807971239sls?lang=en > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Donnerstag, 23. April 2015 16:24 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net > Subject: Re: RFR(L): 8077838: Recent developments for ppc. > > On 4/23/15 1:27 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> These methods actually do an atomic update of a memory location, so the name >> really describes what is happening. > > May be I need some PPC education. There are several instructions and branch. Is that some kind of transaction? > > Thanks, > Vladimir > >> >> I'll remove the change to interpreter_ppc.cpp and runtime_ppc.cpp. >> >> Best regards, >> Goetz >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Donnerstag, 23. April 2015 01:16 >> To: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(L): 8077838: Recent developments for ppc. >> >> Why call methods 'atomic': atomic_inc_ptr() and atomic_ori_int()? >> >> Do you really need to change runtime_ppc.cpp only to remove empty line? >> >> Looks fine otherwise. >> >> Vladimir >> >> On 4/22/15 2:34 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> this change contains recent changes in the ppc directory mostly made by SAP. >>> It's a ppc-only change. >>> http://cr.openjdk.java.net/~goetz/webrevs/8077838-ppc/webrev.01/ >>> >>> - Recognition of Power 8 processors (by Tiago Sturmer Daitx). >>> - Support for more new Power 8 instructions. >>> - Support for transactional memory. This is implemented but not yet tested >>> thoroughly due to limitiations of the OS support. Not enabled. >>> - java.lang.math.*Exact intrinsics >>> - Some C2 optimizations and fixes: >>> * Handling of flag registers. Some instructions would lead to uncompilable >>> methods due to not allocatable register patterns. >>> * Free some integer registers to use them for allocation. Handle compressed >>> oops base as constant. >>> * Unscaled class compression. >>> - Type profiling fixes. >>> >>> Please review this change. >>> >>> Best regards, >>> Goetz. >>> >>> From vladimir.kozlov at oracle.com Thu Apr 23 15:02:32 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Apr 2015 08:02:32 -0700 Subject: RFR(S): 8078482: ppc: pass thread to throw_AbstractMethodError In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC0C3A@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC09A0@DEWDFEMB12A.global.corp.sap> <5539011B.1010300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC0C3A@DEWDFEMB12A.global.corp.sap> Message-ID: <55390988.10805@oracle.com> Okay. Looks good. Thanks, Vladimir On 4/23/15 7:56 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > Oh, I only mentioned that in the bug. > > The SIGSEGV was recognized as a Safepoint, because the check > was not strict enough. It crashed a second time when trying to > handle the safepoint. > > Because of some bug in an old linux we don't check the address > accessed but the instruction doing the access. I made this check > more strict, i.e. I check whether it happened in an nmethod. > > Best regards, > Goetz. > > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 23. April 2015 16:27 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8078482: ppc: pass thread to throw_AbstractMethodError > > What is the change in os_linux_ppc.cpp? > > Vladimir > > On 4/23/15 1:35 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> this fixes an issue detected by Tiago Sturmer Daitix in the jdk7 ppc port. >> The thread argument was left out in a call to throw_AbstractMethodError. >> >> Please review this change. It needs to go to jdk8u, too. It's ppc only. >> http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.01/ >> >> Best regards, >> Goetz. >> From edward.nevill at linaro.org Thu Apr 23 15:13:50 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Thu, 23 Apr 2015 16:13:50 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5538A1FD.3060504@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> <5538A1FD.3060504@redhat.com> Message-ID: <1429802030.17540.37.camel@mylittlepony.linaroharston> On Thu, 2015-04-23 at 08:40 +0100, Andrew Haley wrote: > On 22/04/15 10:40, Edward Nevill wrote: > > If there is no other feedback shall I prepare a revised patch with R29 marked NS? > > I think you should. I'm as certain as I can be that the GC root- > finding code won't find an OOP saved in R29 and then pushed by > native code. Done. http://cr.openjdk.java.net/~enevill/8075930/webrev.04/ However I don't believe it makes any difference to the code generated. C2 will still use R29 as a general purpose register, and will still not spill it on a method call (I have checked). I think that in order to do a GC root scan it must be at a safe point and I don't believe it can be at a safe point in native code. In compiled code it uses the OopMaps, unwinds the stack and finds the OOP in R29. This works for x86. It does exactly the same thing. RBP is available as a general purpose register and RBP is marked as SOE. All the best, Ed. From coleen.phillimore at oracle.com Thu Apr 23 15:19:39 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 23 Apr 2015 11:19:39 -0400 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <5538A27F.5010705@redhat.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> <5535A85D.101@oracle.com> <5536922F.3030204@oracle.com> <55370107.6010207@oracle.com> <55375477.7020804@redhat.com> <553831F0.70201@oracle.com> <5538A27F.5010705@redhat.com> Message-ID: <55390D8B.9090405@oracle.com> On 4/23/15, 3:42 AM, Andrew Haley wrote: > On 23/04/15 00:42, Coleen Phillimore wrote: >> On 4/22/15, 3:57 AM, Andrew Haley wrote: >>> On 22/04/15 03:01, Daniel D. Daugherty wrote: >>>> Personally, I like the idea of not adding any more new JPRT targets >>>> and reconfiguring to have fastdebug and/or debug builds run as non-PCH... >>>> It's a much simpler policy to explain: >>>> >>>> If we support PCH builds with a particular toolset then product >>>> builds default to PCH and non-product builds default to no-PCH. >>> But the debug builds are used in development all the time. It's >>> these that really benefit from PCH. >> I feel like PCH makes development slower. I change a header file and >> all the files in the system are recompiled because it happens to be in >> the precompiled file. > But that'll happen anyway if the change you made is to one of the common > headers. I can't see that it makes any difference. > > Maybe it depends on what you're working on? linkResolver.hpp - maybe it's one that doesn't belong in precompiled.hpp but I suspect a lot of files fall into that category. If PCH doesn't really make builds that much faster, why have it? I'm planning to change my script that calls configure to not use precompiled headers. Thanks, Coleen > > Andrew. > From aph at redhat.com Thu Apr 23 16:22:12 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Apr 2015 17:22:12 +0100 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support Message-ID: <55391C34.3070502@redhat.com> http://cr.openjdk.java.net/~aph/8078521/ Andrew. From per.liden at oracle.com Thu Apr 23 16:40:04 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 23 Apr 2015 18:40:04 +0200 Subject: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index In-Reply-To: <1429787817.3334.3.camel@oracle.com> References: <5538B2C5.3040404@oracle.com> <1429787817.3334.3.camel@oracle.com> Message-ID: Hi Thomas, > On 23 Apr 2015, at 13:16, Thomas Schatzl wrote: > > Hi, > > On Thu, 2015-04-23 at 10:52 +0200, Per Liden wrote: >> Hi, >> >> (This change affects G1, but it's touching code in C1 so I'd like to ask >> someone from the compiler team to also reviewed this) >> >> Summary: The G1 barriers loads and updates the PrtQueue::_index field. >> This field is a size_t but the C1 version of these barriers aren't >> 64-bit clean. The bug has more details. >> >> In addition I've massaged the code a little bit, so that the 32-bit and >> 64-bit sections look more similar (and as a bonus I think we avoid an >> extra memory load on 32-bit). >> >> Webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8013171 >> >> Testing: >> * gc-test-suite on both 32 and 64-bit builds (with -XX:+UseG1GC >> -XX:+TieredCompilation -XX:TieredStopAtLevel=3 -XX:+VerifyAfterGC) >> * Passes jprt > > Looks good, with the following caveats which should be decided by > somebody else if they are important as they are micro-opts: > > - instead of using cmp to compare against zero in a register, it would > be better to use the test instruction (e.g. __ testX(tmp, tmp)) as it saves > a byte of encoding per instruction with the same effect. > > - post barrier stub: I would prefer if the 64 bit code did not > push/pop the rdx register to free tmp. There are explicit rscratch1/2 > registers for temporaries available on that platform. At least rscratch1 > (=r8) seems to be used without save/restore in the original code already. > This would also remove the need for 64 bit code to push/pop any register it > seems to me. > > - the original code only pushed/popped rbx when there was need to. Now > the generated code pushes/pops rdx always. > > In general, the new code is easier to follow (and unifies 32/64 bit code > paths), but seems slightly worse in execution time to me (without testing, > just gut feeling). It probably won't matter at the end of the day. > Thanks for looking at the patch! I don?t think these optimizations will make a difference given the nature of C1, but let?s see if someone has a different opinion. /Per From aph at redhat.com Thu Apr 23 16:46:28 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Apr 2015 17:46:28 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <1429802030.17540.37.camel@mylittlepony.linaroharston> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> <5538A1FD.3060504@redhat.com> <1429802030.17540.37.camel@mylittlepony.linaroharston> Message-ID: <553921E4.5090408@redhat.com> On 04/23/2015 04:13 PM, Edward Nevill wrote: > On Thu, 2015-04-23 at 08:40 +0100, Andrew Haley wrote: >> On 22/04/15 10:40, Edward Nevill wrote: >>> If there is no other feedback shall I prepare a revised patch with R29 marked NS? >> >> I think you should. I'm as certain as I can be that the GC root- >> finding code won't find an OOP saved in R29 and then pushed by >> native code. > > Done. > > http://cr.openjdk.java.net/~enevill/8075930/webrev.04/ Please run webrev after committing, so that the webrev is a proper changeset. Please make sure that the jcheck extension is enabled. http://openjdk.java.net/projects/code-tools/jcheck/ > However I don't believe it makes any difference to the code > generated. C2 will still use R29 as a general purpose register, and > will still not spill it on a method call (I have checked). > > I think that in order to do a GC root scan it must be at a safe > point and I don't believe it can be at a safe point in native code. Sure it can. Native methods are always safepoints, as are calls to the runtime to allocate objects, etc. But all such calls have a wrapper, and it pushes FP, it has an OopMap, so it should be fine. > In compiled code it uses the OopMaps, unwinds the stack and finds > the OOP in R29. Okay, I see. Thanks, Andrew. From per.liden at oracle.com Thu Apr 23 16:52:50 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 23 Apr 2015 18:52:50 +0200 Subject: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index In-Reply-To: <33D0E9FE-ADF6-4BEE-8AD2-23D2B3EBA07A@oracle.com> References: <5538B2C5.3040404@oracle.com> <5538EE8A.9010503@oracle.com> <33D0E9FE-ADF6-4BEE-8AD2-23D2B3EBA07A@oracle.com> Message-ID: > On 23 Apr 2015, at 15:32, Roland Westrelin wrote: > >> Yes, it happens to be the same thing is this case, but bordering on being sloppy given that it's not a pointer. But if this is the preferred way then I can live with that. > > You could add a comment that says you?re using the *ptr variants for non pointer things. > I don?t know if it?s the preferred way but that?s what I would do because less #ifdef makes the code easier to read. > >> Updated webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.1/ > > That looks good to me. > Thanks for reviewing Roland! /Per From dmitry.samersoff at oracle.com Thu Apr 23 17:13:52 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 23 Apr 2015 20:13:52 +0300 Subject: We REALLY nead a NON-PCH build in JPRT NOW! In-Reply-To: <55390D8B.9090405@oracle.com> References: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com> <551EF8EE.8090707@oracle.com> <5526322D.1070008@oracle.com> <55263408.3040200@redhat.com> <4295855A5C1DE049A61835A1887419CC2CFBF607@DEWDFEMB12A.global.corp.sap> <5530DEF3.5070301@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFBF65B@DEWDFEMB12A.global.corp.sap> <553568C5.5000202@oracle.com> <5535A85D.101@oracle.com> <5536922F.3030204@oracle.com> <55370107.6010207@oracle.com> <55375477.7020804@redhat.com> <553831F0.70201@oracle.com> <5538A27F.5010705@redhat.com> <55390D8B.9090405@oracle.com> Message-ID: <55392850.5090508@oracle.com> Everyone, FYI, Did small benchmark for entire JDK clean build on my laptop - linux-xfs, core I5, 8G, SSD, idle. As expected, PCH doesn't really affects a clean build. Numbers below: ** ccache, no pch, no javac Finished building Java(TM) for target 'default' 12079.395u 320.784s 58:20.54 354.2% 0+0k 0+0io 56pf+0w ** no ccache, pch, no javac Finished building Java(TM) for target 'default' 12847.053u 340.212s 59:07.99 371.6% 0+0k 0+0io 0pf+0w ** no ccache, no pch, no javac Finished building Java(TM) for target 'default' 12493.502u 298.802s 54:36.23 390.4% 0+0k 0+0io 17pf+0w -Dmitry On 2015-04-23 18:19, Coleen Phillimore wrote: > > On 4/23/15, 3:42 AM, Andrew Haley wrote: >> On 23/04/15 00:42, Coleen Phillimore wrote: >>> On 4/22/15, 3:57 AM, Andrew Haley wrote: >>>> On 22/04/15 03:01, Daniel D. Daugherty wrote: >>>>> Personally, I like the idea of not adding any more new JPRT targets >>>>> and reconfiguring to have fastdebug and/or debug builds run as >>>>> non-PCH... >>>>> It's a much simpler policy to explain: >>>>> >>>>> If we support PCH builds with a particular toolset then product >>>>> builds default to PCH and non-product builds default to no-PCH. >>>> But the debug builds are used in development all the time. It's >>>> these that really benefit from PCH. >>> I feel like PCH makes development slower. I change a header file and >>> all the files in the system are recompiled because it happens to be in >>> the precompiled file. >> But that'll happen anyway if the change you made is to one of the common >> headers. I can't see that it makes any difference. >> >> Maybe it depends on what you're working on? > > linkResolver.hpp - maybe it's one that doesn't belong in precompiled.hpp > but I suspect a lot of files fall into that category. If PCH doesn't > really make builds that much faster, why have it? I'm planning to > change my script that calls configure to not use precompiled headers. > > Thanks, > Coleen > >> >> Andrew. >> > -- 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 dean.long at oracle.com Thu Apr 23 19:01:01 2015 From: dean.long at oracle.com (Dean Long) Date: Thu, 23 Apr 2015 12:01:01 -0700 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <553921E4.5090408@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> <5538A1FD.3060504@redhat.com> <1429802030.17540.37.camel@mylittlepony.linaroharston> <553921E4.5090408@redhat.com> Message-ID: <5539416D.8000306@oracle.com> On 4/23/2015 9:46 AM, Andrew Haley wrote: > On 04/23/2015 04:13 PM, Edward Nevill wrote: >> On Thu, 2015-04-23 at 08:40 +0100, Andrew Haley wrote: >>> On 22/04/15 10:40, Edward Nevill wrote: >>>> If there is no other feedback shall I prepare a revised patch with R29 marked NS? >>> I think you should. I'm as certain as I can be that the GC root- >>> finding code won't find an OOP saved in R29 and then pushed by >>> native code. >> Done. >> >> http://cr.openjdk.java.net/~enevill/8075930/webrev.04/ > Please run webrev after committing, so that the webrev is a proper > changeset. Please make sure that the jcheck extension is enabled. > > http://openjdk.java.net/projects/code-tools/jcheck/ > >> However I don't believe it makes any difference to the code >> generated. C2 will still use R29 as a general purpose register, and >> will still not spill it on a method call (I have checked). >> >> I think that in order to do a GC root scan it must be at a safe >> point and I don't believe it can be at a safe point in native code. > Sure it can. Native methods are always safepoints, as are calls to > the runtime to allocate objects, etc. But all such calls have a > wrapper, and it pushes FP, it has an OopMap, so it should be fine. What happens at a safepoint polling point in a loop? Will C2 try to keep an oop value in R29 live across the safepoint? If so, I assume the oopmap takes care of that case as well. dl >> In compiled code it uses the OopMaps, unwinds the stack and finds >> the OOP in R29. > Okay, I see. > > Thanks, > Andrew. From michael.haupt at oracle.com Thu Apr 23 19:17:49 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 23 Apr 2015 21:17:49 +0200 Subject: RFR (XS): 8030680: 292 cleanup from default method code assessment Message-ID: Hello, please review and sponsor this change, and ignore the erroneous post on core-libs-dev. RFE: https://bugs.openjdk.java.net/browse/JDK-8030680 Webrev: http://cr.openjdk.java.net/~mhaupt/8030680/webrev.00/ This is a set of simple changes to increase robustness. Tested locally with jtreg for java.lang.invoke, and with JPRT using the hotspot test set. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From karen.kinnear at oracle.com Thu Apr 23 20:08:22 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 23 Apr 2015 16:08:22 -0400 Subject: RFR (XS): 8030680: 292 cleanup from default method code assessment In-Reply-To: References: Message-ID: <47514E27-2AD4-497C-91A1-56704D9CEF2C@oracle.com> Michael, Thank you so much for picking this up. So I had a couple of questions (which I should have asked when I filed the bug :-) 1. In klassVtable::method_count_for_interface: A couple of optional suggestions while you are cleaning this up: If length were initialized to 0, we would not need to have two different return locations. If the ASSERT was right before the return, i.e. not in the if (m->has_itable_index(), we would be checking the return value for all cases and it might be more future proof if someone were to extend the logic. Not sure if we would need the local copy, i.e. nof_methods_copy - but I do appreciate that as also future proofing. 2. init_method_MemberName I would be much more comfortable with conditional if (m.not_null() rather than assert - which only does something in debug mode. 3. A favor - while you are in klassVtable.cpp ? Harold and I were reading the tracing information looking at a different bug today and realized some of the tracing is misleading. 3A: In assign_itable_indices_for_interface it says "Initializing itable for interface" change to "Initializing itable indices for interface" If you read the comments closely, an interface does not actually have an itable, but its methods need to have either a vtable index or an itable index. This code here assigns itable indices to methods that do not already have a vtable index (from j.l.Object) 3B: assign_itable_indices_for_interface if (m->has_vtable_index) ... "itable index %d for method ..." could you possibly change that to "vtable index %d for method" that would help people be less confused debugging this. 4. Testing Thank you for the testing you already did. I realize what you changed is not extensive. I also realize that we often find a surprising interaction in changing runtime code. So - this is what we ask folks to run when they change code in runtime, unless there are reasons to run more or less (i.e. this is the default list - since I think this is your first fix in runtime) run vmsqe (nsk) tests: at least vm.quick.testlist run jck (noninteractive) tests: vm, lang, api run RunThese run jtreg: hotspot run jtreg: jdk run performance tests as needed - from ref workload For this particular change I would ask that in addition to what you already ran you run (with a fastdebug build): - Christian Tornqvist can tell you how to run them vm.quick.testlist default methods tests (default mode and -mode invoke) jtreg java/util/streams (our favorite default method shakers) thanks so much, Karen p.s. I would be happy to sponsor the change - I am happy you made the changes :-) On Apr 23, 2015, at 3:17 PM, Michael Haupt wrote: > Hello, > > please review and sponsor this change, and ignore the erroneous post on core-libs-dev. > RFE: https://bugs.openjdk.java.net/browse/JDK-8030680 > Webrev: http://cr.openjdk.java.net/~mhaupt/8030680/webrev.00/ > > This is a set of simple changes to increase robustness. Tested locally with jtreg for java.lang.invoke, and with JPRT using the hotspot test set. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From dean.long at oracle.com Thu Apr 23 20:23:52 2015 From: dean.long at oracle.com (Dean Long) Date: Thu, 23 Apr 2015 13:23:52 -0700 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <55391C34.3070502@redhat.com> References: <55391C34.3070502@redhat.com> Message-ID: <553954D8.2070506@oracle.com> On 4/23/2015 9:22 AM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8078521/ > > Andrew. Unfortunately, this will cause conflicts with our closed port. I don't know if we should try to address those issues here or in a followup bug. We would need something like the following (still untested) to allow us to map to a different cpu name: diff -r d11fb4e8a82e agent/src/share/classes/sun/jvm/hotspot/utilities/AltPlatformInfo.java --- a/agent/src/share/classes/sun/jvm/hotspot/utilities/AltPlatformInfo.java Tue Mar 24 10:25:09 2015 +0100 +++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/AltPlatformInfo.java Thu Apr 23 16:17:00 2015 -0400 @@ -27,5 +27,5 @@ public interface AltPlatformInfo { // Additional cpu types can be tested via this interface - public boolean knownCPU(String cpu); -} \ No newline at end of file + public String knownCPU(String cpu); +} diff -r d11fb4e8a82e agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java --- a/agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java Tue Mar 24 10:25:09 2015 +0100 +++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java Thu Apr 23 16:17:00 2015 -0400 @@ -57,6 +57,14 @@ is not recognized as supported, an exception is thrown instead. */ public static String getCPU() throws UnsupportedPlatformException { String cpu = System.getProperty("os.arch"); + try { + Class pic = Class.forName("sun.jvm.hotspot.utilities.PlatformInfoClosed"); + AltPlatformInfo api = (AltPlatformInfo)pic.newInstance(); + String newCPU = api.knownCPU(cpu); + if (newCPU != null) { + return cpu; + } + } catch (Exception e) {} if (cpu.equals("i386") || cpu.equals("x86")) { return "x86"; } else if (cpu.equals("sparc") || cpu.equals("sparcv9")) { @@ -64,13 +72,6 @@ } else if (cpu.equals("ia64") || cpu.equals("amd64") || cpu.equals("x86_64") || cpu.equals("ppc64") || cpu.equals("aarch64")) { return cpu; } else { - try { - Class pic = Class.forName("sun.jvm.hotspot.utilities.PlatformInfoClosed"); - AltPlatformInfo api = (AltPlatformInfo)pic.newInstance(); - if (api.knownCPU(cpu)) { - return cpu; - } - } catch (Exception e) {} throw new UnsupportedPlatformException("CPU type " + cpu + " not yet supported"); } } From david.holmes at oracle.com Fri Apr 24 02:03:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Apr 2015 12:03:52 +1000 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: References: <553893DF.5060406@oracle.com> <5538A460.5020902@oracle.com> Message-ID: <5539A488.3070306@oracle.com> Hi Thomas, On 23/04/2015 6:00 PM, Thomas St?fe wrote: > On Thu, Apr 23, 2015 at 9:50 AM, David Holmes > wrote: > On 23/04/2015 5:24 PM, Thomas St?fe wrote: > - would it be possible to use vfork() instead of fork()? Might > increase > the chance of fork() succeeding in out-of-memory scenarios. The way > fork/execve is used here is simple enough for vfork(). > > I'm reluctant to use vfork() as it is an unknown. The use of fork() > has been trialled by Google with no problem. > > I understand. > > We use vfork() by default on Linux and HP-UX since 3-4 years for > Runtime.exec() without problems (but our implementation differs wildly > from the standard one). But then, Runtime.exec does not get called in > error situations, so the conditions may be different for > os::fork_and_exec(). Right - os::fork_and_exec is potentially a lot more fragile given the potential execution context. Which prompted me to add a second test for the general OnError handling case. I also moved the tests to runtime/ErrorHandling to match the directory that exists in JDK 9. Updated webrev: http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ Thanks, David > - would it be possible to print out errno in case fork fails? > > > Sure. > > > Thanks! > > ..Thomas > > Thanks, > David > > Regards, Thomas > > > On Thu, Apr 23, 2015 at 8:40 AM, David Holmes > > >> wrote: > > webrev: http://cr.openjdk.java.net/~dholmes/8078470/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8078470 > > For historical reasons, dating back to LinuxThreads, > os::fork_and_exec uses direct syscalls to perform fork and > execve > functions. The fork syscall has been deprecated on linux > for quite > some time and some distributions are now shipping with > deprecated > syscalls removed - this results in a ENOSYS error and the > "OnError" > commands that utilize os::fork_and_exec no longer work. > > The problem was discussed here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html > > It seems the concerns surrounding direct use of glibc > fork() and > exec() are no longer legitimate and Martin Buchholz reports > that > Google replaced the syscalls with glibc calls some time ago > and have > not had any problems. So we propose to apply the same change > uniformly on Linux. > > This is initially going into 8u60 via jdk8u-hs-dev due to time > constraints on the 8u60 schedule, and an internal limitation > preventing me from pushing this to 9 right now. But it will be > "backported" to 9 ASAP. > > Thanks, > David > > > From david.holmes at oracle.com Fri Apr 24 07:11:10 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Apr 2015 17:11:10 +1000 Subject: aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <1429607797.4116.11.camel@mylittlepony.linaroharston> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> Message-ID: <5539EC8E.1060507@oracle.com> Hi Ed, On 21/04/2015 7:16 PM, Edward Nevill wrote: > Hi, > > The current jdk9 tip fails to build from source on aarch64 with the following error message > > /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': > /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' > collect2: error: ld returned 1 exit status > > The following webrev gets it building again. > > http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm also wondering how we would get __ARM_NEON defined but not __arm__? And looking closer at the original code: 154 # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ we seem to have a stray ) that might be the cause of the problem? Cheers, David Thanks, David > Please review and if approved push. See comments below. > > Thanks, > Ed. > > > This was introduced at changeset 11769 > > changeset: 11769:cb75299d5933 > user: azvegint > date: Mon Jan 19 20:02:31 2015 +0300 > files: src/java.desktop/share/native/libsplashscreen/libpng/CHANGES src/java.desktop/share/native/libsplashscreen/libpng/LICENSE src/java.desktop/share/native/libsplashscreen/libpng/README src/java.desktop/share/native/libsplashscreen/libpng/png.c src/java.desktop/share/native/libsplashscreen/libpng/png.h src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngdebug.h src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c src/java.desktop/share/native/libsplashscreen/libpng/pngget.c src/java.desktop/share/native/libsplashscreen/libpng/pnginfo.h src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c src/java.desktop/share/native/libsplashscreen/libpng/pngpread.c src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h src/java.desktop/share/native/libsplashscreen/libpng/pngread.c src/java.desktop/share/native/libsplashs! creen/li bpng/pngrio.c src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c src/java.desktop/share/native/libsplashscreen/libpng/pngset.c src/java.desktop/share/native/libsplashscreen/libpng/pngstruct.h src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c > description: > 8069198: Upgrade image library > Reviewed-by: ahgross, bae, mschoene, serb > > This changeset seems to introduce some ARM Neon optimisations, however I cannot seem to access the associated bug report JDK-8069198 as it seems I do not have suitable privileges to read the report. > > The problem is that it is also attempting to build this code for AARCH64 resulting in the above undefined symbol. > > The above webrev fixes this by ensuring that it only attempts to compile this code if defined(__arm__) > > From david.holmes at oracle.com Fri Apr 24 07:15:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Apr 2015 17:15:38 +1000 Subject: aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <5539EC8E.1060507@oracle.com> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> Message-ID: <5539ED9A.5030704@oracle.com> On 24/04/2015 5:11 PM, David Holmes wrote: > Hi Ed, > > On 21/04/2015 7:16 PM, Edward Nevill wrote: >> Hi, >> >> The current jdk9 tip fails to build from source on aarch64 with the >> following error message >> >> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: >> In function `png_init_filter_functions': >> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: >> undefined reference to `png_init_filter_functions_neon' >> collect2: error: ld returned 1 exit status >> >> The following webrev gets it building again. >> >> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ > > Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm > also wondering how we would get __ARM_NEON defined but not __arm__? > > And looking closer at the original code: > > 154 # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ > > we seem to have a stray ) that might be the cause of the problem? No that's just my eyes playing tricks on me at the end of the week. David > Cheers, > David > > > Thanks, > David > >> Please review and if approved push. See comments below. >> >> Thanks, >> Ed. >> >> >> This was introduced at changeset 11769 >> >> changeset: 11769:cb75299d5933 >> user: azvegint >> date: Mon Jan 19 20:02:31 2015 +0300 >> files: >> src/java.desktop/share/native/libsplashscreen/libpng/CHANGES >> src/java.desktop/share/native/libsplashscreen/libpng/LICENSE >> src/java.desktop/share/native/libsplashscreen/libpng/README >> src/java.desktop/share/native/libsplashscreen/libpng/png.c >> src/java.desktop/share/native/libsplashscreen/libpng/png.h >> src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h >> src/java.desktop/share/native/libsplashscreen/libpng/pngdebug.h >> src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c >> src/java.desktop/share/native/libsplashscreen/libpng/pngget.c >> src/java.desktop/share/native/libsplashscreen/libpng/pnginfo.h >> src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h >> src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c >> src/java.desktop/share/native/libsplashscreen/libpng/pngpread.c >> src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h >> src/java.desktop/share/native/libsplashscreen/libpng/pngread.c >> src/java.desktop/share/native/libsplashs! > creen/li > bpng/pngrio.c > src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c > src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c > src/java.desktop/share/native/libsplashscreen/libpng/pngset.c > src/java.desktop/share/native/libsplashscreen/libpng/pngstruct.h > src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c > src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c > src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c > src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c > src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c > src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c >> description: >> 8069198: Upgrade image library >> Reviewed-by: ahgross, bae, mschoene, serb >> >> This changeset seems to introduce some ARM Neon optimisations, however >> I cannot seem to access the associated bug report JDK-8069198 as it >> seems I do not have suitable privileges to read the report. >> >> The problem is that it is also attempting to build this code for >> AARCH64 resulting in the above undefined symbol. >> >> The above webrev fixes this by ensuring that it only attempts to >> compile this code if defined(__arm__) >> >> From aph at redhat.com Fri Apr 24 08:33:04 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Apr 2015 09:33:04 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5539416D.8000306@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> <5538A1FD.3060504@redhat.com> <1429802030.17540.37.camel@mylittlepony.linaroharston> <553921E4.5090408@redhat.com> <5539416D.8000306@oracle.com> Message-ID: <5539FFC0.6080302@redhat.com> On 23/04/15 20:01, Dean Long wrote: > On 4/23/2015 9:46 AM, Andrew Haley wrote: >> On 04/23/2015 04:13 PM, Edward Nevill wrote: >>> >>> I think that in order to do a GC root scan it must be at a safe >>> point and I don't believe it can be at a safe point in native code. >> Sure it can. Native methods are always safepoints, as are calls to >> the runtime to allocate objects, etc. But all such calls have a >> wrapper, and it pushes FP, it has an OopMap, so it should be fine. > > What happens at a safepoint polling point in a loop? Will C2 try to > keep an oop value > in R29 live across the safepoint? If so, I assume the oopmap takes care > of that case as > well. I guess so. Ed's argument that this is the same as EBP on x86 is quite persuasive to me. Andrew. From aph at redhat.com Fri Apr 24 08:39:08 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Apr 2015 09:39:08 +0100 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <553954D8.2070506@oracle.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> Message-ID: <553A012C.1070008@redhat.com> On 23/04/15 21:23, Dean Long wrote: > On 4/23/2015 9:22 AM, Andrew Haley wrote: >> http://cr.openjdk.java.net/~aph/8078521/ > > Unfortunately, this will cause conflicts with our closed port. I thought it might. The assumption that a CPU name uniquely identifies a port has turned out not to be true. > I don't know if we should try to address those issues here or in a > followup bug. I think this should be done in a followup bug. IMO there's nothing much wrong with this except that it breaks something externally invisible. > We would need something like the following (still untested) to allow > us to map to a different cpu name: Yes, I see. Andrew. From thomas.stuefe at gmail.com Fri Apr 24 09:00:33 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 24 Apr 2015 11:00:33 +0200 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: <5539A488.3070306@oracle.com> References: <553893DF.5060406@oracle.com> <5538A460.5020902@oracle.com> <5539A488.3070306@oracle.com> Message-ID: Hi David, Unfortunately printing out errno in VMError will not work so well, as it is not clear if it is from fork() or execve(), and it is vulnerable against future changes of os::fork_and_exec(). Also, will not do anything for you on Windows. I do not see a nice solution. Returning errno will not work, or be ugly, because you'd need to return GetLastError for windows, which has a different semantic, and the caller must remember that. On Solaris, os::fork_and_exec() prints a warning if PrintWarning() is on, which in my opinion does not help. That printout is very verbose and you have to remember setting it before starting the process. In some places in error handling (e.g. "check_dump_limits()") we return a string in a caller provided buffer describing the error which then is printed into the error logs. So, that may be a pragmatic solution, especially because we already have the scratch buffer in VMError::report_and_die(). On the other hand, in almost any os::... function we just swallow error details, as we did in os::fork_and_exec() before, so maybe we just leave it at this. Otherwise, change looks fine to me. ..Thomas On Fri, Apr 24, 2015 at 4:03 AM, David Holmes wrote: > Hi Thomas, > > On 23/04/2015 6:00 PM, Thomas St?fe wrote: > >> On Thu, Apr 23, 2015 at 9:50 AM, David Holmes > > wrote: >> On 23/04/2015 5:24 PM, Thomas St?fe wrote: >> - would it be possible to use vfork() instead of fork()? Might >> increase >> the chance of fork() succeeding in out-of-memory scenarios. The >> way >> fork/execve is used here is simple enough for vfork(). >> >> I'm reluctant to use vfork() as it is an unknown. The use of fork() >> has been trialled by Google with no problem. >> >> I understand. >> >> We use vfork() by default on Linux and HP-UX since 3-4 years for >> Runtime.exec() without problems (but our implementation differs wildly >> from the standard one). But then, Runtime.exec does not get called in >> error situations, so the conditions may be different for >> os::fork_and_exec(). >> > > Right - os::fork_and_exec is potentially a lot more fragile given the > potential execution context. Which prompted me to add a second test for the > general OnError handling case. I also moved the tests to > runtime/ErrorHandling to match the directory that exists in JDK 9. > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ > > Thanks, > David > > > - would it be possible to print out errno in case fork fails? >> >> >> Sure. >> >> >> Thanks! >> >> ..Thomas >> >> Thanks, >> David >> >> Regards, Thomas >> >> >> On Thu, Apr 23, 2015 at 8:40 AM, David Holmes >> >> > >> >> wrote: >> >> webrev: http://cr.openjdk.java.net/~dholmes/8078470/webrev/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8078470 >> >> For historical reasons, dating back to LinuxThreads, >> os::fork_and_exec uses direct syscalls to perform fork and >> execve >> functions. The fork syscall has been deprecated on linux >> for quite >> some time and some distributions are now shipping with >> deprecated >> syscalls removed - this results in a ENOSYS error and the >> "OnError" >> commands that utilize os::fork_and_exec no longer work. >> >> The problem was discussed here: >> >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html >> >> It seems the concerns surrounding direct use of glibc >> fork() and >> exec() are no longer legitimate and Martin Buchholz reports >> that >> Google replaced the syscalls with glibc calls some time ago >> and have >> not had any problems. So we propose to apply the same change >> uniformly on Linux. >> >> This is initially going into 8u60 via jdk8u-hs-dev due to >> time >> constraints on the 8u60 schedule, and an internal limitation >> preventing me from pushing this to 9 right now. But it will >> be >> "backported" to 9 ASAP. >> >> Thanks, >> David >> >> >> >> From goetz.lindenmaier at sap.com Fri Apr 24 09:08:27 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 24 Apr 2015 09:08:27 +0000 Subject: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC0F5E@DEWDFEMB12A.global.corp.sap> Hi, runtime/StackGuardPages/testme.sh fails on OSes with default 64K pages. This happens on ppc linux distributions. The test passes -Xss320k to the VM. Fix: increase to -Xss328K. Please review this change of a single character ;) I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8078595-64Kpages/webrev.01/ Best regards, Goetz. From yekaterina.kantserova at oracle.com Fri Apr 24 09:34:38 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 24 Apr 2015 11:34:38 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> Message-ID: <553A0E2E.4090805@oracle.com> Hi, Here comes the updated version. bug: https://bugs.openjdk.java.net/browse/JDK-8059047 webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ One comment about changes in hotspot part. The refactored version of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: 70 /* 71 * Some hprof dumps of all objects contain constantPoolOop references that cannot be resolved, so we ignore 72 * failures about resolving constantPoolOop fields using a negative lookahead 73 */ 74 output.shouldNotMatch(".*WARNING(?!.*Failed to resolve object.*constantPoolOop.*).*"); It depends on that the current version of jdk.test.lib.hprof parser simply write down warnings to stdout. As a result the test needs to invent own logic to parse it. I suggest instead to improve jdk.test.lib.hprof parser as a separate RFE. The parser will collect such information and provide a new method for getting it, e.g. jdk.test.lib.hprof.model.Snapshot.getWarnings(). The serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly when RFE is implemented. Thanks, Katja On 04/22/2015 03:09 PM, Staffan Larsen wrote: > On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: > >>>>> > >>>>>Hi, > >>>>> > >>>>>Could I please have a review of this fix. > >>>>> > >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047 > >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ > >>>>> > >>>>>This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. > >>>>> > >>>>>The old jhat packages have been moved as follows: > >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model > >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser > >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util > >>>>> > >>>>>The source has not been changed except Copyrights year. > >>>>> > >>>>>Thanks, > >>>>>Katja From staffan.larsen at oracle.com Fri Apr 24 10:10:45 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Apr 2015 12:10:45 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <553A0E2E.4090805@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> <553A0E2E.4090805@oracle.com> Message-ID: > On 24 apr 2015, at 11:34, Yekaterina Kantserova wrote: > > Hi, > > Here comes the updated version. > > bug: https://bugs.openjdk.java.net/browse/JDK-8059047 > > webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ > webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java: In main() I think you should change the deleteOnExit() to just delete(). There is no reason to wait with it. Perhaps we should also verify that the file does not already exists before we try to write to it. If it exists, we can delete it. > webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ test/serviceability/dcmd/gc/HeapDumpTest.java: Same thing: call delete() instead of deleteOnExit(). > > > One comment about changes in hotspot part. The refactored version of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: > > 70 /* > 71 * Some hprof dumps of all objects contain constantPoolOop references that cannot be resolved, so we ignore > 72 * failures about resolving constantPoolOop fields using a negative lookahead > 73 */ > 74 output.shouldNotMatch(".*WARNING(?!.*Failed to resolve object.*constantPoolOop.*).*"); > > It depends on that the current version of jdk.test.lib.hprof parser simply write down warnings to stdout. As a result the test needs to invent own logic to parse it. > > I suggest instead to improve jdk.test.lib.hprof parser as a separate RFE. The parser will collect such information and provide a new method for getting it, e.g. jdk.test.lib.hprof.model.Snapshot.getWarnings(). The serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly when RFE is implemented. Sounds right. A quick, hacky solution is to redirect System.out to a stream or file while running the parser? /Staffan > > > Thanks, > Katja > > > > On 04/22/2015 03:09 PM, Staffan Larsen wrote: >> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >> >>>>> >> >>>>>Hi, >> >>>>> >> >>>>>Could I please have a review of this fix. >> >>>>> >> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047 >> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >> >>>>> >> >>>>>This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >> >>>>> >> >>>>>The old jhat packages have been moved as follows: >> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >> >>>>> >> >>>>>The source has not been changed except Copyrights year. >> >>>>> >> >>>>>Thanks, >> >>>>>Katja > From edward.nevill at linaro.org Fri Apr 24 11:10:33 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Fri, 24 Apr 2015 12:10:33 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <553921E4.5090408@redhat.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> <5538A1FD.3060504@redhat.com> <1429802030.17540.37.camel@mylittlepony.linaroharston> <553921E4.5090408@redhat.com> Message-ID: On 23 April 2015 at 17:46, Andrew Haley wrote: > On 04/23/2015 04:13 PM, Edward Nevill wrote: > > On Thu, 2015-04-23 at 08:40 +0100, Andrew Haley wrote: > >> On 22/04/15 10:40, Edward Nevill wrote: > >>> If there is no other feedback shall I prepare a revised patch with R29 > marked NS? > > > > http://cr.openjdk.java.net/~enevill/8075930/webrev.04/ > > Please run webrev after committing, so that the webrev is a proper > changeset. Please make sure that the jcheck extension is enabled. > > http://openjdk.java.net/projects/code-tools/jcheck/ > Done. New webrev @ http://cr.openjdk.java.net/~enevill/8075930/webrev.05 All the best, Ed. From edward.nevill at linaro.org Fri Apr 24 11:35:31 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Fri, 24 Apr 2015 12:35:31 +0100 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: <5539416D.8000306@oracle.com> References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> <5538A1FD.3060504@redhat.com> <1429802030.17540.37.camel@mylittlepony.linaroharston> <553921E4.5090408@redhat.com> <5539416D.8000306@oracle.com> Message-ID: On 23 April 2015 at 20:01, Dean Long wrote: > > What happens at a safepoint polling point in a loop? Will C2 try to keep > an oop value > in R29 live across the safepoint? If so, I assume the oopmap takes care > of that case as > well. Yes. Here is an example of an OopMap at a safepoint in a loop 0x000003ff710efa1c: adrp x10, 0x000003ff79830000 ; OopMap{r14=Oop off=160} ;*goto ; - MethodAtom::execute at 46 (line 35) ; {poll} 0x000003ff710efa20: ldr wzr, [x10] ;*goto ; - MethodAtom::execute at 46 (line 35) ; {poll} 0x000003ff710efa24: ldr w10, [x14,#16] 0x000003ff710efa28: cmp w16, w10 0x000003ff710efa2c: b.ge 0x000003ff710efb74 ;*aload_0 ; - MethodAtom::execute at 12 (line 37) All the best, Ed. From yekaterina.kantserova at oracle.com Fri Apr 24 14:17:41 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 24 Apr 2015 16:17:41 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> <553A0E2E.4090805@oracle.com> Message-ID: <553A5085.10805@oracle.com> All suggestions have been implemented. Please find new webrevs here: webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.02 webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.02 webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.01 // Katja On 04/24/2015 12:10 PM, Staffan Larsen wrote: > >> On 24 apr 2015, at 11:34, Yekaterina Kantserova >> > > wrote: >> >> Hi, >> >> Here comes the updated version. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >> >> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ >> >> webrev jdk: >> http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ >> > > test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java: > > In main() I think you should change the deleteOnExit() to just > delete(). There is no reason to wait with it. > > Perhaps we should also verify that the file does not already exists > before we try to write to it. If it exists, we can delete it. > > > >> webrev hotspot: >> http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ >> > > test/serviceability/dcmd/gc/HeapDumpTest.java: > > Same thing: call delete() instead of deleteOnExit(). > > >> >> >> One comment about changes in hotspot part. The refactored version of >> serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: >> >> 70 /* >> 71 * Some hprof dumps of all objects contain >> constantPoolOop references that cannot be resolved, so we ignore >> 72 * failures about resolving constantPoolOop fields >> using a negative lookahead >> 73 */ >> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to >> resolve object.*constantPoolOop.*).*"); >> >> It depends on that the current version of jdk.test.lib.hprof parser >> simply write down warnings to stdout. As a result the test needs to >> invent own logic to parse it. >> >> I suggest instead to improve jdk.test.lib.hprof parser as a separate >> RFE. The parser will collect such information and provide a new >> method for getting it, e.g. >> jdk.test.lib.hprof.model.Snapshot.getWarnings(). The >> serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly >> when RFE is implemented. > > Sounds right. A quick, hacky solution is to redirect System.out to a > stream or file while running the parser? > > /Staffan > >> >> >> Thanks, >> Katja >> >> >> >> On 04/22/2015 03:09 PM, Staffan Larsen wrote: >>> On 22 apr 2015, at 11:17, Yekaterina >>> Kantserova>> > wrote: >>> >>>>> >>> >>>>>Hi, >>> >>>>> >>> >>>>>Could I please have a review of this fix. >>> >>>>> >>> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047 >>> >>> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>> >>> >>>>> >>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool >>> (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put >>> parser/validator into common test library since the functionality >>> can be useful not only for SVC tools tests but even for some future >>> GC tests. >>> >>>>> >>> >>>>>The old jhat packages have been moved as follows: >>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>> >>>>> >>> >>>>>The source has not been changed except Copyrights year. >>> >>>>> >>> >>>>>Thanks, >>> >>>>>Katja >> > From alexander.kulyakhtin at oracle.com Fri Apr 24 14:33:59 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 24 Apr 2015 07:33:59 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: Hi, Could I, please, have a review of this tests-only change: https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html The change renames com.oracle.java.testlibrary package to jdk.test.lib package: The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, Everywhere in the hotspot/test files import statements have been changed as needed. Best regards, Alex From aph at redhat.com Fri Apr 24 16:00:31 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Apr 2015 17:00:31 +0100 Subject: RFR: 8078621: AARCH64: Fails to build without precompiled headers Message-ID: <553A689F.8030202@redhat.com> http://cr.openjdk.java.net/~aph/8078621/ Andrew. From vladimir.kozlov at oracle.com Fri Apr 24 16:18:38 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Apr 2015 09:18:38 -0700 Subject: RFR: 8078621: AARCH64: Fails to build without precompiled headers In-Reply-To: <553A689F.8030202@redhat.com> References: <553A689F.8030202@redhat.com> Message-ID: <553A6CDE.7030307@oracle.com> Looks good. Vladimir On 4/24/15 9:00 AM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8078621/ > > Andrew. > From thomas.stuefe at gmail.com Fri Apr 24 17:11:00 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 24 Apr 2015 19:11:00 +0200 Subject: RFR(xs): 8078628: linux-zero does not build without precompiled header Message-ID: Hi all, please review this tiny change. Build was broken for zero/slowdebug when building without precompiled header. bug: https://bugs.openjdk.java.net/browse/JDK-8078628 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.00/webrev/ Thank you, Thomas From dean.long at oracle.com Fri Apr 24 18:27:44 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 24 Apr 2015 11:27:44 -0700 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <553A012C.1070008@redhat.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> Message-ID: <553A8B20.9050109@oracle.com> Not a review, but a couple things I noticed: agent/src/os/linux/ps_proc.c: I don't think you need to change this file. There is already PTRACE_GETREGSET support there. agent/src/os/linux/Makefile: + echo FECK The conflict will be handled in a separate bug (8078632). dl On 4/24/2015 1:39 AM, Andrew Haley wrote: > On 23/04/15 21:23, Dean Long wrote: >> On 4/23/2015 9:22 AM, Andrew Haley wrote: >>> http://cr.openjdk.java.net/~aph/8078521/ >> Unfortunately, this will cause conflicts with our closed port. > I thought it might. The assumption that a CPU name uniquely identifies > a port has turned out not to be true. > >> I don't know if we should try to address those issues here or in a >> followup bug. > I think this should be done in a followup bug. IMO there's nothing > much wrong with this except that it breaks something externally > invisible. > >> We would need something like the following (still untested) to allow >> us to map to a different cpu name: > Yes, I see. > > Andrew. From david.holmes at oracle.com Fri Apr 24 21:45:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 Apr 2015 07:45:20 +1000 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: References: <553893DF.5060406@oracle.com> <5538A460.5020902@oracle.com> <5539A488.3070306@oracle.com> Message-ID: <553AB970.9060309@oracle.com> Hi Thomas, Thanks for looking at this. Note to readers: Still need a (R)eviewer for this please. On 24/04/2015 7:00 PM, Thomas St?fe wrote: > Hi David, > > Unfortunately printing out errno in VMError will not work so well, as it > is not clear if it is from fork() or execve(), and it is vulnerable > against future changes of os::fork_and_exec(). Also, will not do > anything for you on Windows. I thought about doing something inside fork_and_exec but decided against it for a couple of reasons: 1. Needs to be done for every platform individually. 2. Far from clear which mechanism would be appropriate given the different contexts in which it can be used - which is also why I did not do something for its use when debugging. As for Windows ... not sure what it will do but I was following existing practice - see os_windows.cpp and perfMemory_windows.cpp. > I do not see a nice solution. Returning errno will not work, or be ugly, > because you'd need to return GetLastError for windows, which has a > different semantic, and the caller must remember that. And a return value, unless encoded, won't tell you which of fork and execve failed. > On Solaris, os::fork_and_exec() prints a warning if PrintWarning() is > on, which in my opinion does not help. That printout is very verbose and > you have to remember setting it before starting the process. > > In some places in error handling (e.g. "check_dump_limits()") we return > a string in a caller provided buffer describing the error which then is > printed into the error logs. So, that may be a pragmatic solution, > especially because we already have the scratch buffer in > VMError::report_and_die(). > > On the other hand, in almost any os::... function we just swallow error > details, as we did in os::fork_and_exec() before, so maybe we just leave > it at this. I'll leave what I have now, pending further comments from anyone. It is better than nothing I think, and would have saved me a bit of time when I first encountered the problem with the missing syscall. > Otherwise, change looks fine to me. Thanks, David > ..Thomas > > > > > On Fri, Apr 24, 2015 at 4:03 AM, David Holmes > wrote: > > Hi Thomas, > > On 23/04/2015 6:00 PM, Thomas St?fe wrote: > > On Thu, Apr 23, 2015 at 9:50 AM, David Holmes > > >> wrote: > On 23/04/2015 5:24 PM, Thomas St?fe wrote: > - would it be possible to use vfork() instead of > fork()? Might > increase > the chance of fork() succeeding in out-of-memory > scenarios. The way > fork/execve is used here is simple enough for vfork(). > > I'm reluctant to use vfork() as it is an unknown. The use > of fork() > has been trialled by Google with no problem. > > I understand. > > We use vfork() by default on Linux and HP-UX since 3-4 years for > Runtime.exec() without problems (but our implementation differs > wildly > from the standard one). But then, Runtime.exec does not get > called in > error situations, so the conditions may be different for > os::fork_and_exec(). > > > Right - os::fork_and_exec is potentially a lot more fragile given > the potential execution context. Which prompted me to add a second > test for the general OnError handling case. I also moved the tests > to runtime/ErrorHandling to match the directory that exists in JDK 9. > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ > > Thanks, > David > > > - would it be possible to print out errno in case fork > fails? > > > Sure. > > > Thanks! > > ..Thomas > > Thanks, > David > > Regards, Thomas > > > On Thu, Apr 23, 2015 at 8:40 AM, David Holmes > > > > > >>> wrote: > > webrev: > http://cr.openjdk.java.net/~dholmes/8078470/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8078470 > > For historical reasons, dating back to LinuxThreads, > os::fork_and_exec uses direct syscalls to perform > fork and > execve > functions. The fork syscall has been deprecated on > linux > for quite > some time and some distributions are now shipping with > deprecated > syscalls removed - this results in a ENOSYS error > and the > "OnError" > commands that utilize os::fork_and_exec no longer > work. > > The problem was discussed here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html > > It seems the concerns surrounding direct use of glibc > fork() and > exec() are no longer legitimate and Martin > Buchholz reports > that > Google replaced the syscalls with glibc calls some > time ago > and have > not had any problems. So we propose to apply the > same change > uniformly on Linux. > > This is initially going into 8u60 via jdk8u-hs-dev > due to time > constraints on the 8u60 schedule, and an internal > limitation > preventing me from pushing this to 9 right now. > But it will be > "backported" to 9 ASAP. > > Thanks, > David > > > > From dean.long at oracle.com Fri Apr 24 22:22:41 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 24 Apr 2015 15:22:41 -0700 Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2 In-Reply-To: References: <1427288528.7353.25.camel@mylittlepony.linaroharston> <5512B817.3080802@oracle.com> <1428571873.26527.24.camel@mylittlepony.linaroharston> <5526B7B1.7000702@oracle.com> <1428656099.13172.10.camel@mylittlepony.linaroharston> <5527E1B9.5030109@oracle.com> <1429608038.4116.13.camel@mylittlepony.linaroharston> <55366888.2040409@redhat.com> <553669A3.8070205@redhat.com> <5536A25C.7060402@oracle.com> <1429695657.29680.7.camel@mylittlepony.linaroharston> <5538A1FD.3060504@redhat.com> <1429802030.17540.37.camel@mylittlepony.linaroharston> <553921E4.5090408@redhat.com> <5539416D.8000306@oracle.com> Message-ID: <553AC231.4090103@oracle.com> On 4/24/2015 4:35 AM, Edward Nevill wrote: > > > On 23 April 2015 at 20:01, Dean Long > wrote: > > > What happens at a safepoint polling point in a loop? Will C2 try > to keep an oop value > in R29 live across the safepoint? If so, I assume the oopmap > takes care of that case as > well. > > > Yes. Here is an example of an OopMap at a safepoint in a loop > > 0x000003ff710efa1c: adrp x10, 0x000003ff79830000 > ; OopMap{r14=Oop off=160} > ;*goto > ; - > MethodAtom::execute at 46 (line 35) > ; {poll} > 0x000003ff710efa20: ldr wzr, [x10] ;*goto > ; - > MethodAtom::execute at 46 (line 35) > ; {poll} > 0x000003ff710efa24: ldr w10, [x14,#16] > 0x000003ff710efa28: cmp w16, w10 > 0x000003ff710efa2c: b.ge 0x000003ff710efb74 ;*aload_0 > ; - > MethodAtom::execute at 12 (line 37) > > All the best, > Ed. > I was expecting to see r29=Oop, but if it works for x86 I don't see why it wouldn't work for aarch64. dl From aph at redhat.com Sat Apr 25 09:13:04 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 25 Apr 2015 10:13:04 +0100 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <553A8B20.9050109@oracle.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> Message-ID: <553B5AA0.4050101@redhat.com> OK, I'll fix those and prepare a new webrev. Andrew. From david.holmes at oracle.com Mon Apr 27 00:38:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2015 10:38:20 +1000 Subject: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC0F5E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC0F5E@DEWDFEMB12A.global.corp.sap> Message-ID: <553D84FC.40200@oracle.com> Hi Goetz, On 24/04/2015 7:08 PM, Lindenmaier, Goetz wrote: > Hi, > > runtime/StackGuardPages/testme.sh fails on OSes with default 64K pages. > This happens on ppc linux distributions. The test passes -Xss320k to the VM. > > Fix: increase to -Xss328K. Why does the test fail? I would have expected a stack size that is a multiple of possible page sizes (up to 64K) to be okay. Thanks, David > Please review this change of a single character ;) I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8078595-64Kpages/webrev.01/ > > Best regards, > Goetz. > From david.holmes at oracle.com Mon Apr 27 00:40:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2015 10:40:52 +1000 Subject: RFR(xs): 8078628: linux-zero does not build without precompiled header In-Reply-To: References: Message-ID: <553D8594.2080803@oracle.com> Hi Thomas, On 25/04/2015 3:11 AM, Thomas St?fe wrote: > Hi all, > > please review this tiny change. Build was broken for zero/slowdebug when > building without precompiled header. > > bug: https://bugs.openjdk.java.net/browse/JDK-8078628 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.00/webrev/ Why the double condition here: 33 #ifdef ZERO 34 #ifdef TARGET_ARCH_zero 35 # include "entry_zero.hpp" 36 #endif 37 #endif ?? Thanks, David > > Thank you, > > Thomas > From david.holmes at oracle.com Mon Apr 27 00:53:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2015 10:53:46 +1000 Subject: RFR: 8078621: AARCH64: Fails to build without precompiled headers In-Reply-To: <553A689F.8030202@redhat.com> References: <553A689F.8030202@redhat.com> Message-ID: <553D889A.5060906@oracle.com> Hi Andrew, On 25/04/2015 2:00 AM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8078621/ src/cpu/aarch64/vm/aarch64.ad This seems to be the only occurrence of a #include in a .ad file. If it works I guess that is okay, but I don't know if it is intended to work. src/cpu/aarch64/vm/macroAssembler_aarch64.cpp I was wondering if the include of the opto headers should be guarded by "#ifdef COMPILER2", but as the code that uses the definitions isn't also guarded then I guess not. Copyright dates need updating before pushing. Thanks, David > Andrew. > From david.holmes at oracle.com Mon Apr 27 01:39:28 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2015 11:39:28 +1000 Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package In-Reply-To: References: Message-ID: <553D9350.3060206@oracle.com> Hi Alex, On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: > Hi, > > Could I, please, have a review of this tests-only change: > > https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package > Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html > > The change renames com.oracle.java.testlibrary package to jdk.test.lib package: I presume this is a first step towards fixing: https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, Did you use "hg rename" for that? The webrev suggests not as it shows deleted and added files rather than moved ones. > Everywhere in the hotspot/test files import statements have been changed as needed. Seems okay based on scanning through the patch. Copyright dates will need updating in many cases. Thanks, David > Best regards, > Alex > > > From goetz.lindenmaier at sap.com Mon Apr 27 07:07:06 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 27 Apr 2015 07:07:06 +0000 Subject: RFR(XS): 8078595: [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC142C@DEWDFEMB12A.global.corp.sap> I forgot to mention the bugid in my first mail ... Sorry, Goetz From: Lindenmaier, Goetz Sent: Freitag, 24. April 2015 11:08 To: hotspot-dev at openjdk.java.net Subject: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. Hi, runtime/StackGuardPages/testme.sh fails on OSes with default 64K pages. This happens on ppc linux distributions. The test passes -Xss320k to the VM. Fix: increase to -Xss328K. Please review this change of a single character ;) I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8078595-64Kpages/webrev.01/ Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Apr 27 07:24:54 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 27 Apr 2015 07:24:54 +0000 Subject: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. In-Reply-To: <553D84FC.40200@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFC0F5E@DEWDFEMB12A.global.corp.sap> <553D84FC.40200@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC1459@DEWDFEMB12A.global.corp.sap> Hi David, that's just because of the stack size computation in os_linux.cpp. It uses Linux::page_size, which is 64K, and Linux::vm_default_page_size(), which is 8K. Red/Yellow/Shadow pages are all set to 1. I already fixed a lot of jtreg tests wrt. the initial stack size. Best regards, Goetz. oJ/8077838-ppc-hs-comp> output-jdk9-fastdebug/images/jdk/bin/java -Xss320K The stack size specified is too small, Specify at least 328k Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 27. April 2015 02:38 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. Hi Goetz, On 24/04/2015 7:08 PM, Lindenmaier, Goetz wrote: > Hi, > > runtime/StackGuardPages/testme.sh fails on OSes with default 64K pages. > This happens on ppc linux distributions. The test passes -Xss320k to the VM. > > Fix: increase to -Xss328K. Why does the test fail? I would have expected a stack size that is a multiple of possible page sizes (up to 64K) to be okay. Thanks, David > Please review this change of a single character ;) I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8078595-64Kpages/webrev.01/ > > Best regards, > Goetz. > From aph at redhat.com Mon Apr 27 07:50:22 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Apr 2015 08:50:22 +0100 Subject: RFR: 8078621: AARCH64: Fails to build without precompiled headers In-Reply-To: <553D889A.5060906@oracle.com> References: <553A689F.8030202@redhat.com> <553D889A.5060906@oracle.com> Message-ID: <553DEA3E.2060208@redhat.com> Hi, On 27/04/15 01:53, David Holmes wrote: > On 25/04/2015 2:00 AM, Andrew Haley wrote: >> http://cr.openjdk.java.net/~aph/8078621/ > > src/cpu/aarch64/vm/aarch64.ad > > This seems to be the only occurrence of a #include in a .ad file. If it > works I guess that is okay, but I don't know if it is intended to work. I did consider that. It's hard to know for sure, but the purpose of that block is "definitions necessary in the rest of the architecture description" so it logically makes sense there. I suppose it could be included in some other machine-dependent header file which is included by aarch64.ad, but that feels to me like something of a kludge. > src/cpu/aarch64/vm/macroAssembler_aarch64.cpp > > I was wondering if the include of the opto headers should be guarded by > "#ifdef COMPILER2", but as the code that uses the definitions isn't also > guarded then I guess not. I have my doubts about "#ifdef COMPILER2" in the back end. I asked why the build didn't support client-only builds on 64-bit systems and was told it's because the cost of supporting it wasn't worthwhile; if we're never going to do client builds "#ifdef COMPILER2" is mere clutter. And of course, if client is never built it will never be tested, so inevitably it'll rot. > Copyright dates need updating before pushing. Sorry, too late; it was already approved and pushed. http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/11b7f6b12521 Thanks, Andrew. From thomas.stuefe at gmail.com Mon Apr 27 07:52:34 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Apr 2015 09:52:34 +0200 Subject: RFR(xs): 8078628: linux-zero does not build without precompiled header In-Reply-To: <553D8594.2080803@oracle.com> References: <553D8594.2080803@oracle.com> Message-ID: Hi David, stupid copy-paste error. I corrected that and the places where I found it: http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.01/webrev/ Kind Regards, Thomas On Mon, Apr 27, 2015 at 2:40 AM, David Holmes wrote: > Hi Thomas, > > > On 25/04/2015 3:11 AM, Thomas St?fe wrote: > >> Hi all, >> >> please review this tiny change. Build was broken for zero/slowdebug when >> building without precompiled header. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8078628 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.00/webrev/ >> > > Why the double condition here: > > 33 #ifdef ZERO > 34 #ifdef TARGET_ARCH_zero > 35 # include "entry_zero.hpp" > 36 #endif > 37 #endif > > ?? > > Thanks, > David > > >> Thank you, >> >> Thomas >> >> From stefan.karlsson at oracle.com Mon Apr 27 08:01:59 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 27 Apr 2015 10:01:59 +0200 Subject: RFR(xs): 8078628: linux-zero does not build without precompiled header In-Reply-To: <553D8594.2080803@oracle.com> References: <553D8594.2080803@oracle.com> Message-ID: <553DECF7.4020403@oracle.com> Hi Thomas, On 2015-04-27 02:40, David Holmes wrote: > Hi Thomas, > > On 25/04/2015 3:11 AM, Thomas St?fe wrote: >> Hi all, >> >> please review this tiny change. Build was broken for zero/slowdebug when >> building without precompiled header. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8078628 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.00/webrev/ The includes are kept sorted in other part of HotSpot, so I think it would be good to have them sorted for the zero code as well: http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.01/webrev/src/share/vm/interpreter/interpreterGenerator.hpp.udiff.html #include "interpreter/cppInterpreter.hpp" +#include "interpreter/interp_masm.hpp" #include "interpreter/cppInterpreterGenerator.hpp" #include "interpreter/templateInterpreter.hpp" #include "interpreter/templateInterpreterGenerator.hpp" http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.01/webrev/src/cpu/zero/vm/nativeInst_zero.cpp.udiff.html #include "precompiled.hpp" #include "assembler_zero.inline.hpp" +#include "interpreter/cppInterpreter.hpp" #include "memory/resourceArea.hpp" #include "nativeInst_zero.hpp" +#include "entry_zero.hpp" #include "oops/oop.inline.hpp" #include "runtime/handles.hpp" #include "runtime/sharedRuntime.hpp" Thanks, StefanK > > Why the double condition here: > > 33 #ifdef ZERO > 34 #ifdef TARGET_ARCH_zero > 35 # include "entry_zero.hpp" > 36 #endif > 37 #endif > > ?? > > Thanks, > David > >> >> Thank you, >> >> Thomas >> From volker.simonis at gmail.com Mon Apr 27 08:29:09 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Apr 2015 10:29:09 +0200 Subject: RFR(S): 8078482: ppc: pass thread to throw_AbstractMethodError In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC09A0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC09A0@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, the change looks good. Please also update the copyright year in interpreter_ppc.cpp. Thank you and best regards, Volker On Thu, Apr 23, 2015 at 10:35 AM, Lindenmaier, Goetz wrote: > Hi, > > this fixes an issue detected by Tiago Sturmer Daitix in the jdk7 ppc port. > The thread argument was left out in a call to throw_AbstractMethodError. > > Please review this change. It needs to go to jdk8u, too. It's ppc only. > http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.01/ > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Mon Apr 27 08:35:38 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 27 Apr 2015 08:35:38 +0000 Subject: RFR(S): 8078482: ppc: pass thread to throw_AbstractMethodError In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFC09A0@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC14B6@DEWDFEMB12A.global.corp.sap> Thanks Volker! I fixed the copyright: http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.02/ Best regards, Goetz. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Montag, 27. April 2015 10:29 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(S): 8078482: ppc: pass thread to throw_AbstractMethodError Hi Goetz, the change looks good. Please also update the copyright year in interpreter_ppc.cpp. Thank you and best regards, Volker On Thu, Apr 23, 2015 at 10:35 AM, Lindenmaier, Goetz wrote: > Hi, > > this fixes an issue detected by Tiago Sturmer Daitix in the jdk7 ppc port. > The thread argument was left out in a call to throw_AbstractMethodError. > > Please review this change. It needs to go to jdk8u, too. It's ppc only. > http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.01/ > > Best regards, > Goetz. > From thomas.stuefe at gmail.com Mon Apr 27 09:25:50 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Apr 2015 11:25:50 +0200 Subject: RFR(xs): 8078628: linux-zero does not build without precompiled header In-Reply-To: <553DECF7.4020403@oracle.com> References: <553D8594.2080803@oracle.com> <553DECF7.4020403@oracle.com> Message-ID: Hi David, Stefan, thanks for reviewing! third webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.02/webrev Ordering includes alphabetically turned up even more not-selfcontained includes. This is a really quite annoying work :-) I wish there were an official non-PCH nightly build. Not only would people notice missing headers, it also would make implementation creep into header files more obvious. Thanks, Thomas On Mon, Apr 27, 2015 at 10:01 AM, Stefan Karlsson < stefan.karlsson at oracle.com> wrote: > Hi Thomas, > > On 2015-04-27 02:40, David Holmes wrote: > >> Hi Thomas, >> >> On 25/04/2015 3:11 AM, Thomas St?fe wrote: >> >>> Hi all, >>> >>> please review this tiny change. Build was broken for zero/slowdebug when >>> building without precompiled header. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8078628 >>> webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.00/webrev/ >>> >> > The includes are kept sorted in other part of HotSpot, so I think it would > be good to have them sorted for the zero code as well: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.01/webrev/src/share/vm/interpreter/interpreterGenerator.hpp.udiff.html > > #include "interpreter/cppInterpreter.hpp" > +#include "interpreter/interp_masm.hpp" > #include "interpreter/cppInterpreterGenerator.hpp" > #include "interpreter/templateInterpreter.hpp" > #include "interpreter/templateInterpreterGenerator.hpp" > > > http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.01/webrev/src/cpu/zero/vm/nativeInst_zero.cpp.udiff.html > > #include "precompiled.hpp" > #include "assembler_zero.inline.hpp" > +#include "interpreter/cppInterpreter.hpp" > #include "memory/resourceArea.hpp" > #include "nativeInst_zero.hpp" > +#include "entry_zero.hpp" > #include "oops/oop.inline.hpp" > #include "runtime/handles.hpp" > #include "runtime/sharedRuntime.hpp" > > Thanks, > StefanK > > > >> Why the double condition here: >> >> 33 #ifdef ZERO >> 34 #ifdef TARGET_ARCH_zero >> 35 # include "entry_zero.hpp" >> 36 #endif >> 37 #endif >> >> ?? >> >> Thanks, >> David >> >> >>> Thank you, >>> >>> Thomas >>> >>> > From david.holmes at oracle.com Mon Apr 27 12:18:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2015 22:18:08 +1000 Subject: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC1459@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC0F5E@DEWDFEMB12A.global.corp.sap> <553D84FC.40200@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC1459@DEWDFEMB12A.global.corp.sap> Message-ID: <553E2900.4070703@oracle.com> On 27/04/2015 5:24 PM, Lindenmaier, Goetz wrote: > Hi David, > > that's just because of the stack size computation in os_linux.cpp. > It uses Linux::page_size, which is 64K, and Linux::vm_default_page_size(), which is 8K. > Red/Yellow/Shadow pages are all set to 1. > > I already fixed a lot of jtreg tests wrt. the initial stack size. > > Best regards, > Goetz. > > oJ/8077838-ppc-hs-comp> output-jdk9-fastdebug/images/jdk/bin/java -Xss320K > The stack size specified is too small, Specify at least 328k > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. Ah I see - just a case of minimal stack size being too small. Please add this info to the bug report. Thanks, David > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 27. April 2015 02:38 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. > > Hi Goetz, > > On 24/04/2015 7:08 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> runtime/StackGuardPages/testme.sh fails on OSes with default 64K pages. >> This happens on ppc linux distributions. The test passes -Xss320k to the VM. >> >> Fix: increase to -Xss328K. > > Why does the test fail? I would have expected a stack size that is a > multiple of possible page sizes (up to 64K) to be okay. > > Thanks, > David > >> Please review this change of a single character ;) I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8078595-64Kpages/webrev.01/ >> >> Best regards, >> Goetz. >> From goetz.lindenmaier at sap.com Mon Apr 27 13:13:08 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 27 Apr 2015 13:13:08 +0000 Subject: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. In-Reply-To: <553E2900.4070703@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFC0F5E@DEWDFEMB12A.global.corp.sap> <553D84FC.40200@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC1459@DEWDFEMB12A.global.corp.sap> <553E2900.4070703@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC15B2@DEWDFEMB12A.global.corp.sap> Hi David, Yep, it's only 8k missing. I added some more explanation to the bug. https://bugs.openjdk.java.net/browse/JDK-8078595 Best regards, Goetz -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 27. April 2015 14:18 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. On 27/04/2015 5:24 PM, Lindenmaier, Goetz wrote: > Hi David, > > that's just because of the stack size computation in os_linux.cpp. > It uses Linux::page_size, which is 64K, and Linux::vm_default_page_size(), which is 8K. > Red/Yellow/Shadow pages are all set to 1. > > I already fixed a lot of jtreg tests wrt. the initial stack size. > > Best regards, > Goetz. > > oJ/8077838-ppc-hs-comp> output-jdk9-fastdebug/images/jdk/bin/java -Xss320K > The stack size specified is too small, Specify at least 328k > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. Ah I see - just a case of minimal stack size being too small. Please add this info to the bug report. Thanks, David > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 27. April 2015 02:38 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. > > Hi Goetz, > > On 24/04/2015 7:08 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> runtime/StackGuardPages/testme.sh fails on OSes with default 64K pages. >> This happens on ppc linux distributions. The test passes -Xss320k to the VM. >> >> Fix: increase to -Xss328K. > > Why does the test fail? I would have expected a stack size that is a > multiple of possible page sizes (up to 64K) to be okay. > > Thanks, > David > >> Please review this change of a single character ;) I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8078595-64Kpages/webrev.01/ >> >> Best regards, >> Goetz. >> From nils.eliasson at oracle.com Mon Apr 27 14:10:38 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 27 Apr 2015 16:10:38 +0200 Subject: RFR (S): Failure after windows compiler upgrade Message-ID: <553E435E.7000302@oracle.com> Hi, Please review this patch. The bug is caused by the instruction sequence generated by the visual studio compiler when casting a long to a float. Visual Studio 2013 has a new behavior where it defaults to generating code targeting SSE2 (and avoids x87). Compiling for a 64-bit target gives the same result as before. Compiling for 32bit VS2013 generates a call to _ltod3 (long2double) and then uses a sse2 instruction to cast it to a float. Casting the long to a double and then to a float gives a different result than casting directly to a float. This is true on all tested configurations. It is unclear why they just didn't use a MOVQ to load the long to an XMM register and then use the same cvtsi2ss as in the other configurations. To fix this we need to add the /arch:IA32 flag to all i586 windows builds. It looks like the IA32 option is ignored on 64-bit builds but we shouldn't count on that. A drawback is that this option also prevents any usage of SSE on the i586 platform. Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 Webrev: http://cr.openjdk.java.net/~neliasso/8077590/webrev.03/ Regards Nils From sgehwolf at redhat.com Mon Apr 27 14:33:15 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 27 Apr 2015 16:33:15 +0200 Subject: Why does a fastdebug build compile with -O3 *and* -O0? Message-ID: <1430145195.3349.23.camel@redhat.com> Hi, I've noticed that a fastdebug build of recent hs-rt compiles objects with -O3 *and* -O0. Is this a bug or a feature? If it's a feature, what's the rationale? I'm not sure what GCC does with that, but it appears it just uses -O0 (last seen option?). Example: /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DCHECK_UNHANDLED_OOPS -I. -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_BUILD_USER="\"sgehwolf\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O3 -O0 -fstack-protector-all --param ssp-buffer-size=1 -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual -Wtype-limits -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/virtualMemoryTracker.o.d -fpch-deps -o virtualMemoryTracker.o /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/services/virtualMemoryTracker.cpp Compiling /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/runtime/virtualspace.cpp Cheers, Severin From michael.haupt at oracle.com Mon Apr 27 15:08:03 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 27 Apr 2015 17:08:03 +0200 Subject: RFR (XS): 8030680: 292 cleanup from default method code assessment In-Reply-To: <47514E27-2AD4-497C-91A1-56704D9CEF2C@oracle.com> References: <47514E27-2AD4-497C-91A1-56704D9CEF2C@oracle.com> Message-ID: <4D282D36-0F73-4562-B986-6A344C68A5A3@oracle.com> Hi Karen, thank you very much for your comments. My responses are below. > Am 23.04.2015 um 22:08 schrieb Karen Kinnear : > 1. In klassVtable::method_count_for_interface: > A couple of optional suggestions while you are cleaning this up: > > If length were initialized to 0, we would not need to have two different return locations. > If the ASSERT was right before the return, i.e. not in the if (m->has_itable_index(), > we would be checking the return value for all cases and it might be more future proof > if someone were to extend the logic. That's a good suggestion; thanks. I've refactored the method to have one return statement only, and moved the ASSERT block to just before that. > Not sure if we would need the local copy, i.e. nof_methods_copy - but I do > appreciate that as also future proofing. It's more defensive now - I don't think debugging code should change local state, even if that's directly before a return. > 2. init_method_MemberName > I would be much more comfortable with conditional if (m.not_null() rather > than assert - which only does something in debug mode. All of the checks of this sort in this method use assert() - and there are many places throughout the file (and other files) that use assert() in similar cases as well. If this should be changed to if-plus-raise-error, then that should be the case for all other similar uses of assert(), or the two that were introduced in the change are somehow special. Is this the case? > 3. A favor - while you are in klassVtable.cpp ? > Harold and I were reading the tracing information looking at a different bug today > and realized some of the tracing is misleading. > > 3A: In assign_itable_indices_for_interface it says > "Initializing itable for interface" > change to > "Initializing itable indices for interface" > > If you read the comments closely, an interface does not actually have an itable, but > its methods need to have either a vtable index or an itable index. This code here > assigns itable indices to methods that do not already have a vtable index (from j.l.Object) > > 3B: > assign_itable_indices_for_interface > if (m->has_vtable_index) ... "itable index %d for method ..." > could you possibly change that to "vtable index %d for method" > > that would help people be less confused debugging this. Both applied. > 4. Testing > Thank you for the testing you already did. > ... > For this particular change I would ask that in addition to what you already ran > you run (with a fastdebug build): - Christian Tornqvist can tell you how to run them > vm.quick.testlist > default methods tests (default mode and -mode invoke) > jtreg java/util/streams (our favorite default method shakers) Thanks for the heads-up about testing for rt changes. I've applied the changes as described above and am now working on the testing. Will upload a revised webrev once that's successful. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From christian.thalinger at oracle.com Mon Apr 27 16:20:52 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Apr 2015 09:20:52 -0700 Subject: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index In-Reply-To: References: <5538B2C5.3040404@oracle.com> <1429787817.3334.3.camel@oracle.com> Message-ID: > On Apr 23, 2015, at 9:40 AM, Per Liden wrote: > > Hi Thomas, > >> On 23 Apr 2015, at 13:16, Thomas Schatzl wrote: >> >> Hi, >> >> On Thu, 2015-04-23 at 10:52 +0200, Per Liden wrote: >>> Hi, >>> >>> (This change affects G1, but it's touching code in C1 so I'd like to ask >>> someone from the compiler team to also reviewed this) >>> >>> Summary: The G1 barriers loads and updates the PrtQueue::_index field. >>> This field is a size_t but the C1 version of these barriers aren't >>> 64-bit clean. The bug has more details. >>> >>> In addition I've massaged the code a little bit, so that the 32-bit and >>> 64-bit sections look more similar (and as a bonus I think we avoid an >>> extra memory load on 32-bit). >>> >>> Webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.0/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8013171 >>> >>> Testing: >>> * gc-test-suite on both 32 and 64-bit builds (with -XX:+UseG1GC >>> -XX:+TieredCompilation -XX:TieredStopAtLevel=3 -XX:+VerifyAfterGC) >>> * Passes jprt >> >> Looks good, with the following caveats which should be decided by >> somebody else if they are important as they are micro-opts: >> >> - instead of using cmp to compare against zero in a register, it would >> be better to use the test instruction (e.g. __ testX(tmp, tmp)) as it saves >> a byte of encoding per instruction with the same effect. Tighter code is always better. For barriers it might be important in tight loops to better fit in the cache. >> >> - post barrier stub: I would prefer if the 64 bit code did not >> push/pop the rdx register to free tmp. There are explicit rscratch1/2 >> registers for temporaries available on that platform. At least rscratch1 >> (=r8) seems to be used without save/restore in the original code already. >> This would also remove the need for 64 bit code to push/pop any register it >> seems to me. Sounds like a good suggestion if it doesn?t complicate the code too much. >> >> - the original code only pushed/popped rbx when there was need to. Now >> the generated code pushes/pops rdx always. >> >> In general, the new code is easier to follow (and unifies 32/64 bit code >> paths), but seems slightly worse in execution time to me (without testing, >> just gut feeling). It probably won't matter at the end of the day. >> > > Thanks for looking at the patch! > > I don?t think these optimizations will make a difference given the nature of C1, but let?s see if someone has a different opinion. > > /Per > From christian.thalinger at oracle.com Mon Apr 27 16:26:57 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Apr 2015 09:26:57 -0700 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <553E435E.7000302@oracle.com> References: <553E435E.7000302@oracle.com> Message-ID: <8638000E-4730-434F-B4E7-4C3A5008E6A3@oracle.com> Looks good. Is this one particular file we are seeing the problem in or is it all over the place? > On Apr 27, 2015, at 7:10 AM, Nils Eliasson wrote: > > Hi, > > Please review this patch. > > The bug is caused by the instruction sequence generated by the visual studio compiler when casting a long to a float. > > Visual Studio 2013 has a new behavior where it defaults to generating code targeting SSE2 (and avoids x87). Compiling for a 64-bit target gives the same result as before. Compiling for 32bit VS2013 generates a call to _ltod3 (long2double) and then uses a sse2 instruction to cast it to a float. Casting the long to a double and then to a float gives a different result than casting directly to a float. This is true on all tested configurations. It is unclear why they just didn't use a MOVQ to load the long to an XMM register and then use the same cvtsi2ss as in the other configurations. > > To fix this we need to add the /arch:IA32 flag to all i586 windows builds. It looks like the IA32 option is ignored on 64-bit builds but we shouldn't count on that. A drawback is that this option also prevents any usage of SSE on the i586 platform. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 > Webrev: http://cr.openjdk.java.net/~neliasso/8077590/webrev.03/ > > Regards > Nils > > > > From nils.eliasson at oracle.com Mon Apr 27 17:26:41 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 27 Apr 2015 19:26:41 +0200 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <8638000E-4730-434F-B4E7-4C3A5008E6A3@oracle.com> References: <553E435E.7000302@oracle.com> <8638000E-4730-434F-B4E7-4C3A5008E6A3@oracle.com> Message-ID: <553E7151.50803@oracle.com> The problem could be in any file, but are in practice quite rare, and the edge cases where it matters even more so. The patch applies the /arch:IA32 switch to all files in hotspot to be on the safe side. //Nils On 2015-04-27 18:26, Christian Thalinger wrote: > Looks good. Is this one particular file we are seeing the problem in or is it all over the place? > >> On Apr 27, 2015, at 7:10 AM, Nils Eliasson wrote: >> >> Hi, >> >> Please review this patch. >> >> The bug is caused by the instruction sequence generated by the visual studio compiler when casting a long to a float. >> >> Visual Studio 2013 has a new behavior where it defaults to generating code targeting SSE2 (and avoids x87). Compiling for a 64-bit target gives the same result as before. Compiling for 32bit VS2013 generates a call to _ltod3 (long2double) and then uses a sse2 instruction to cast it to a float. Casting the long to a double and then to a float gives a different result than casting directly to a float. This is true on all tested configurations. It is unclear why they just didn't use a MOVQ to load the long to an XMM register and then use the same cvtsi2ss as in the other configurations. >> >> To fix this we need to add the /arch:IA32 flag to all i586 windows builds. It looks like the IA32 option is ignored on 64-bit builds but we shouldn't count on that. A drawback is that this option also prevents any usage of SSE on the i586 platform. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 >> Webrev: http://cr.openjdk.java.net/~neliasso/8077590/webrev.03/ >> >> Regards >> Nils >> >> >> >> From coleen.phillimore at oracle.com Mon Apr 27 17:49:56 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 27 Apr 2015 13:49:56 -0400 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <552832AF.8080204@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> Message-ID: <553E76C4.6090401@oracle.com> Serguei, This looks nice. I thought this change was going to delay calling AdjustCpoolCacheAndVtable until the end of the redefinition, rather than for each class, so was a bit confused by the change. Your change is a nice cleanup and improves MethodHandle method replacement performance. Your backport may not be simple for jdk8 because PreviousVersionNode is another type and not an InstanceKlass. Maybe you've convinced me that it's worth backporting those changes too. Let me know. Thanks, Coleen On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen and Dan, > > This is the second class redefinition scalability/optimization fix > that is in my queue to push into 9 and 8u60. > > The approach is similar to the first one but much smaller. > For convenience, these are the links to the first scalability fix: > Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ > > Please, let me know if you have any chance to review this. > This is the last one that is waiting for your attention! :) > > Thanks, > Serguei > > On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8073705 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >> >> >> >> Summary: >> >> This is the 2-nd round of performance/calability fixes in class >> redefinition. >> This time, the two remaining issues that were left alone in the >> first round fix: >> - optimized ConstantPoolCache::adjust_method_entries() is used >> for previous versions >> - the MemberNameTable::adjust_method_entries() has been >> optimized too >> - some cleanup >> >> >> Testing: >> In progress: nsk redefine classes tests, JTREG >> java/lang/instrument, com/sun/jdi >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Mon Apr 27 20:05:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2015 13:05:54 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <553E76C4.6090401@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <553E76C4.6090401@oracle.com> Message-ID: <553E96A2.3050000@oracle.com> Hi Coleen, Thank you for the review! On 4/27/15 10:49 AM, Coleen Phillimore wrote: > > Serguei, > > This looks nice. I thought this change was going to delay calling > AdjustCpoolCacheAndVtable until the end of the redefinition, rather > than for each class, so was a bit confused by the change. I consider this for as a next round of optimizations which is more risky. We need to decide when we are Ok to take this risk. My guess is that it is better to do it together with the constant pool merge elimination. > > Your change is a nice cleanup and improves MethodHandle method > replacement performance. Thanks! > > Your backport may not be simple for jdk8 because PreviousVersionNode > is another type and not an InstanceKlass. Maybe you've convinced me > that it's worth backporting those changes too. Let me know. I've already backported the first chunk where this problem was hit. It seems, this one should not be harder to backport. Thanks! Serguei > > Thanks, > Coleen > > On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen and Dan, >> >> This is the second class redefinition scalability/optimization fix >> that is in my queue to push into 9 and 8u60. >> >> The approach is similar to the first one but much smaller. >> For convenience, these are the links to the first scalability fix: >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> >> Please, let me know if you have any chance to review this. >> This is the last one that is waiting for your attention! :) >> >> Thanks, >> Serguei >> >> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>> >>> >>> Open hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>> >>> >>> >>> Summary: >>> >>> This is the 2-nd round of performance/calability fixes in class >>> redefinition. >>> This time, the two remaining issues that were left alone in the >>> first round fix: >>> - optimized ConstantPoolCache::adjust_method_entries() is used >>> for previous versions >>> - the MemberNameTable::adjust_method_entries() has been >>> optimized too >>> - some cleanup >>> >>> >>> Testing: >>> In progress: nsk redefine classes tests, JTREG >>> java/lang/instrument, com/sun/jdi >>> >>> >>> Thanks, >>> Serguei >>> >> > From serguei.spitsyn at oracle.com Mon Apr 27 20:25:08 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2015 13:25:08 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <553E96A2.3050000@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <553E76C4.6090401@oracle.com> <553E96A2.3050000@oracle.com> Message-ID: <553E9B24.3080809@oracle.com> On 4/27/15 1:05 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Thank you for the review! > > On 4/27/15 10:49 AM, Coleen Phillimore wrote: >> >> Serguei, >> >> This looks nice. I thought this change was going to delay calling >> AdjustCpoolCacheAndVtable until the end of the redefinition, rather >> than for each class, so was a bit confused by the change. > > I consider this for as a next round of optimizations which is more risky. > We need to decide when we are Ok to take this risk. > My guess is that it is better to do it together with the constant pool > merge elimination. Sorry, I forgot to tell that my plan is to open another bug that should cover moving all this adjustments to the end of redefinition. This was a source of the confusion! Thanks, Serguei > >> >> Your change is a nice cleanup and improves MethodHandle method >> replacement performance. > > Thanks! > >> >> Your backport may not be simple for jdk8 because PreviousVersionNode >> is another type and not an InstanceKlass. Maybe you've convinced me >> that it's worth backporting those changes too. Let me know. > > I've already backported the first chunk where this problem was hit. > It seems, this one should not be harder to backport. > > Thanks! > Serguei > >> >> Thanks, >> Coleen >> >> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen and Dan, >>> >>> This is the second class redefinition scalability/optimization fix >>> that is in my queue to push into 9 and 8u60. >>> >>> The approach is similar to the first one but much smaller. >>> For convenience, these are the links to the first scalability fix: >>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >>> >>> Please, let me know if you have any chance to review this. >>> This is the last one that is waiting for your attention! :) >>> >>> Thanks, >>> Serguei >>> >>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>>> >>>> >>>> Open hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> This is the 2-nd round of performance/calability fixes in class >>>> redefinition. >>>> This time, the two remaining issues that were left alone in the >>>> first round fix: >>>> - optimized ConstantPoolCache::adjust_method_entries() is used >>>> for previous versions >>>> - the MemberNameTable::adjust_method_entries() has been >>>> optimized too >>>> - some cleanup >>>> >>>> >>>> Testing: >>>> In progress: nsk redefine classes tests, JTREG >>>> java/lang/instrument, com/sun/jdi >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > From kim.barrett at oracle.com Mon Apr 27 21:07:18 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Apr 2015 17:07:18 -0400 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <553E435E.7000302@oracle.com> References: <553E435E.7000302@oracle.com> Message-ID: <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> On Apr 27, 2015, at 10:10 AM, Nils Eliasson wrote: > > A drawback is that this option also prevents any usage of SSE on the i586 platform. That could be a pretty severe drawback. For example, I?ve been working on some GC performance optimizations that can take advantage of SSE when available. I think this change would mean that the relevant code would require compile-time disable and could not use a runtime configuration test (which would succeed and permit SSE usage on anything other than low end embedded or very ancient hardware). From serguei.spitsyn at oracle.com Mon Apr 27 21:12:59 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2015 14:12:59 -0700 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception Message-ID: <553EA65B.6080805@oracle.com> Please, review the jdk 9 fix for: https://bugs.openjdk.java.net/browse/JDK-8076579 9 hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 Summary: This bug is a regression that was introduced but the fix of: https://bugs.openjdk.java.net/browse/JDK-7187554 The bug is in the InterpreterRuntime::member_name_arg_or_null() function that does not return NULL if there is no invokestatic appendix argument (MemberName). It is why the _remove_activation_preserving_args is trying to to restore unexisting appendix argument when a pop instruction is executed by a debugger in the debuggee VM. The fix is to correctly set NULL in the thread vm_result when it is necessary: thread->set_vm_result(NULL); Testing in progress: In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests, JTREG com/sun/jdi tests, ad-hog ExceptionBug.java test from the bug report Thanks, Serguei From serguei.spitsyn at oracle.com Tue Apr 28 04:27:46 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2015 21:27:46 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <553E9B24.3080809@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <553E76C4.6090401@oracle.com> <553E96A2.3050000@oracle.com> <553E9B24.3080809@oracle.com> Message-ID: <553F0C42.4060000@oracle.com> On 4/27/15 1:25 PM, serguei.spitsyn at oracle.com wrote: > On 4/27/15 1:05 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Thank you for the review! >> >> On 4/27/15 10:49 AM, Coleen Phillimore wrote: >>> >>> Serguei, >>> >>> This looks nice. I thought this change was going to delay calling >>> AdjustCpoolCacheAndVtable until the end of the redefinition, rather >>> than for each class, so was a bit confused by the change. >> >> I consider this for as a next round of optimizations which is more >> risky. >> We need to decide when we are Ok to take this risk. >> My guess is that it is better to do it together with the constant >> pool merge elimination. > > Sorry, I forgot to tell that my plan is to open another bug that should > cover moving all this adjustments to the end of redefinition. > This was a source of the confusion! I've filed a separate bug report for the above: https://bugs.openjdk.java.net/browse/JDK-8078725 Thanks, Serguei > > Thanks, > Serguei > >> >>> >>> Your change is a nice cleanup and improves MethodHandle method >>> replacement performance. >> >> Thanks! >> >>> >>> Your backport may not be simple for jdk8 because PreviousVersionNode >>> is another type and not an InstanceKlass. Maybe you've convinced me >>> that it's worth backporting those changes too. Let me know. >> >> I've already backported the first chunk where this problem was hit. >> It seems, this one should not be harder to backport. >> >> Thanks! >> Serguei >> >>> >>> Thanks, >>> Coleen >>> >>> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen and Dan, >>>> >>>> This is the second class redefinition scalability/optimization fix >>>> that is in my queue to push into 9 and 8u60. >>>> >>>> The approach is similar to the first one but much smaller. >>>> For convenience, these are the links to the first scalability fix: >>>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >>>> >>>> Please, let me know if you have any chance to review this. >>>> This is the last one that is waiting for your attention! :) >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>>>> >>>>> >>>>> Open hotspot webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This is the 2-nd round of performance/calability fixes in class >>>>> redefinition. >>>>> This time, the two remaining issues that were left alone in the >>>>> first round fix: >>>>> - optimized ConstantPoolCache::adjust_method_entries() is >>>>> used for previous versions >>>>> - the MemberNameTable::adjust_method_entries() has been >>>>> optimized too >>>>> - some cleanup >>>>> >>>>> >>>>> Testing: >>>>> In progress: nsk redefine classes tests, JTREG >>>>> java/lang/instrument, com/sun/jdi >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >>> >> > From david.holmes at oracle.com Tue Apr 28 04:50:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Apr 2015 14:50:26 +1000 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: <553AB970.9060309@oracle.com> References: <553893DF.5060406@oracle.com> <5538A460.5020902@oracle.com> <5539A488.3070306@oracle.com> <553AB970.9060309@oracle.com> Message-ID: <553F1192.60309@oracle.com> Ping: still need a (R)eviewer please. Thanks, David On 25/04/2015 7:45 AM, David Holmes wrote: > Hi Thomas, > > Thanks for looking at this. > > Note to readers: Still need a (R)eviewer for this please. > > On 24/04/2015 7:00 PM, Thomas St?fe wrote: >> Hi David, >> >> Unfortunately printing out errno in VMError will not work so well, as it >> is not clear if it is from fork() or execve(), and it is vulnerable >> against future changes of os::fork_and_exec(). Also, will not do >> anything for you on Windows. > > I thought about doing something inside fork_and_exec but decided against > it for a couple of reasons: > > 1. Needs to be done for every platform individually. > 2. Far from clear which mechanism would be appropriate given the > different contexts in which it can be used - which is also why I did not > do something for its use when debugging. > > As for Windows ... not sure what it will do but I was following existing > practice - see os_windows.cpp and perfMemory_windows.cpp. > >> I do not see a nice solution. Returning errno will not work, or be ugly, >> because you'd need to return GetLastError for windows, which has a >> different semantic, and the caller must remember that. > > And a return value, unless encoded, won't tell you which of fork and > execve failed. > >> On Solaris, os::fork_and_exec() prints a warning if PrintWarning() is >> on, which in my opinion does not help. That printout is very verbose and >> you have to remember setting it before starting the process. >> >> In some places in error handling (e.g. "check_dump_limits()") we return >> a string in a caller provided buffer describing the error which then is >> printed into the error logs. So, that may be a pragmatic solution, >> especially because we already have the scratch buffer in >> VMError::report_and_die(). >> >> On the other hand, in almost any os::... function we just swallow error >> details, as we did in os::fork_and_exec() before, so maybe we just leave >> it at this. > > I'll leave what I have now, pending further comments from anyone. It is > better than nothing I think, and would have saved me a bit of time when > I first encountered the problem with the missing syscall. > >> Otherwise, change looks fine to me. > > Thanks, > David > >> ..Thomas >> >> >> >> >> On Fri, Apr 24, 2015 at 4:03 AM, David Holmes > > wrote: >> >> Hi Thomas, >> >> On 23/04/2015 6:00 PM, Thomas St?fe wrote: >> >> On Thu, Apr 23, 2015 at 9:50 AM, David Holmes >> >> > >> wrote: >> On 23/04/2015 5:24 PM, Thomas St?fe wrote: >> - would it be possible to use vfork() instead of >> fork()? Might >> increase >> the chance of fork() succeeding in out-of-memory >> scenarios. The way >> fork/execve is used here is simple enough for vfork(). >> >> I'm reluctant to use vfork() as it is an unknown. The use >> of fork() >> has been trialled by Google with no problem. >> >> I understand. >> >> We use vfork() by default on Linux and HP-UX since 3-4 years for >> Runtime.exec() without problems (but our implementation differs >> wildly >> from the standard one). But then, Runtime.exec does not get >> called in >> error situations, so the conditions may be different for >> os::fork_and_exec(). >> >> >> Right - os::fork_and_exec is potentially a lot more fragile given >> the potential execution context. Which prompted me to add a second >> test for the general OnError handling case. I also moved the tests >> to runtime/ErrorHandling to match the directory that exists in JDK 9. >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ >> >> Thanks, >> David >> >> >> - would it be possible to print out errno in case fork >> fails? >> >> >> Sure. >> >> >> Thanks! >> >> ..Thomas >> >> Thanks, >> David >> >> Regards, Thomas >> >> >> On Thu, Apr 23, 2015 at 8:40 AM, David Holmes >> > > > >> > >> >> > >>> wrote: >> >> webrev: >> http://cr.openjdk.java.net/~dholmes/8078470/webrev/ >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8078470 >> >> For historical reasons, dating back to >> LinuxThreads, >> os::fork_and_exec uses direct syscalls to perform >> fork and >> execve >> functions. The fork syscall has been deprecated on >> linux >> for quite >> some time and some distributions are now >> shipping with >> deprecated >> syscalls removed - this results in a ENOSYS error >> and the >> "OnError" >> commands that utilize os::fork_and_exec no longer >> work. >> >> The problem was discussed here: >> >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html >> >> It seems the concerns surrounding direct use of >> glibc >> fork() and >> exec() are no longer legitimate and Martin >> Buchholz reports >> that >> Google replaced the syscalls with glibc calls some >> time ago >> and have >> not had any problems. So we propose to apply the >> same change >> uniformly on Linux. >> >> This is initially going into 8u60 via jdk8u-hs-dev >> due to time >> constraints on the 8u60 schedule, and an internal >> limitation >> preventing me from pushing this to 9 right now. >> But it will be >> "backported" to 9 ASAP. >> >> Thanks, >> David >> >> >> >> From david.holmes at oracle.com Tue Apr 28 05:20:18 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Apr 2015 15:20:18 +1000 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> References: <553E435E.7000302@oracle.com> <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> Message-ID: <553F1892.4000506@oracle.com> Hi Nils, On 28/04/2015 7:07 AM, Kim Barrett wrote: > On Apr 27, 2015, at 10:10 AM, Nils Eliasson wrote: >> >> A drawback is that this option also prevents any usage of SSE on the i586 platform. > > That could be a pretty severe drawback. > > For example, I?ve been working on some GC performance optimizations that can take advantage of SSE when available. I think this change would mean that the relevant code would require compile-time disable and could not use a runtime configuration test (which would succeed and permit SSE usage on anything other than low end embedded or very ancient hardware). I agree with Kim, this seems an extreme solution for a very specific problem (seems like the FP equivalent of compiling for i486 rather than i686 :( ). Where is the code that gets compiled to use the _ltod3 ? The VS docs on this flag allude to problems using SEE instructions due to the mix of precision that can result, and that it can be avoided by intermediate assignments: https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx So I'm wondering if: a) we can fix this in the source code?; or b) we can fix this by adding the flag only for specific files?; or c) we can fix this by modifying the FP control word to give SSE and x87 the same settings? Also we have the problem reported in https://bugs.openjdk.java.net/browse/JDK-8015396 regarding unexpected NaNs. Is it related to the same underlying problem of using SSE/SSE2 instead of x87, or by mixing them? I'd accept the current fix as a temporary workaround to get the tests passing again. Thanks, David From nils.eliasson at oracle.com Tue Apr 28 07:15:52 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 28 Apr 2015 09:15:52 +0200 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <553F1892.4000506@oracle.com> References: <553E435E.7000302@oracle.com> <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> <553F1892.4000506@oracle.com> Message-ID: <553F33A8.9050807@oracle.com> Hi David, On 2015-04-28 07:20, David Holmes wrote: > Hi Nils, > > On 28/04/2015 7:07 AM, Kim Barrett wrote: >> On Apr 27, 2015, at 10:10 AM, Nils Eliasson >> wrote: >>> >>> A drawback is that this option also prevents any usage of SSE on the >>> i586 platform. >> >> That could be a pretty severe drawback. >> >> For example, I?ve been working on some GC performance optimizations >> that can take advantage of SSE when available. I think this change >> would mean that the relevant code would require compile-time disable >> and could not use a runtime configuration test (which would succeed >> and permit SSE usage on anything other than low end embedded or very >> ancient hardware). > > I agree with Kim, this seems an extreme solution for a very specific > problem (seems like the FP equivalent of compiling for i486 rather > than i686 :( ). > > Where is the code that gets compiled to use the _ltod3 ? The VS docs > on this flag allude to problems using SEE instructions due to the mix > of precision that can result, and that it can be avoided by > intermediate assignments: A cast of a long to a float. In any place calling l2f() for example. In happens regardless of optimization level. The problem with vs2013 is that it emits an intermediate assignment we shouldn't have. > https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx > > So I'm wondering if: > a) we can fix this in the source code?; or No. > b) we can fix this by adding the flag only for specific files?; or Yes but I haven't seen any preparations for that in our makefiles. It would be a bit fragile solution. > c) we can fix this by modifying the FP control word to give SSE and > x87 the same settings? No, it is the choice of instructions that is wrong. They explicitly cast the long to a double first and then to the float. > > Also we have the problem reported in > > https://bugs.openjdk.java.net/browse/JDK-8015396 > > regarding unexpected NaNs. Is it related to the same underlying > problem of using SSE/SSE2 instead of x87, or by mixing them? That is a separate problem. > > I'd accept the current fix as a temporary workaround to get the tests > passing again. > > Thanks, > David ok, Thanks, Nils From david.holmes at oracle.com Tue Apr 28 07:22:02 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Apr 2015 17:22:02 +1000 Subject: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC15B2@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC0F5E@DEWDFEMB12A.global.corp.sap> <553D84FC.40200@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC1459@DEWDFEMB12A.global.corp.sap> <553E2900.4070703@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFC15B2@DEWDFEMB12A.global.corp.sap> Message-ID: <553F351A.8090002@oracle.com> Thanks Goetz. As this is a trivial fix I can push it for you with only my review. David On 27/04/2015 11:13 PM, Lindenmaier, Goetz wrote: > Hi David, > > Yep, it's only 8k missing. > > I added some more explanation to the bug. > https://bugs.openjdk.java.net/browse/JDK-8078595 > > Best regards, > Goetz > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 27. April 2015 14:18 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. > > On 27/04/2015 5:24 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> that's just because of the stack size computation in os_linux.cpp. >> It uses Linux::page_size, which is 64K, and Linux::vm_default_page_size(), which is 8K. >> Red/Yellow/Shadow pages are all set to 1. >> >> I already fixed a lot of jtreg tests wrt. the initial stack size. >> >> Best regards, >> Goetz. >> >> oJ/8077838-ppc-hs-comp> output-jdk9-fastdebug/images/jdk/bin/java -Xss320K >> The stack size specified is too small, Specify at least 328k >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. > > Ah I see - just a case of minimal stack size being too small. Please add > this info to the bug report. > > Thanks, > David > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Montag, 27. April 2015 02:38 >> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XS): [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages. >> >> Hi Goetz, >> >> On 24/04/2015 7:08 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> runtime/StackGuardPages/testme.sh fails on OSes with default 64K pages. >>> This happens on ppc linux distributions. The test passes -Xss320k to the VM. >>> >>> Fix: increase to -Xss328K. >> >> Why does the test fail? I would have expected a stack size that is a >> multiple of possible page sizes (up to 64K) to be okay. >> >> Thanks, >> David >> >>> Please review this change of a single character ;) I please need a sponsor. >>> http://cr.openjdk.java.net/~goetz/webrevs/8078595-64Kpages/webrev.01/ >>> >>> Best regards, >>> Goetz. >>> From dmitry.samersoff at oracle.com Tue Apr 28 08:06:36 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 28 Apr 2015 11:06:36 +0300 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: <553F1192.60309@oracle.com> References: <553893DF.5060406@oracle.com> <5538A460.5020902@oracle.com> <5539A488.3070306@oracle.com> <553AB970.9060309@oracle.com> <553F1192.60309@oracle.com> Message-ID: <553F3F8C.9080901@oracle.com> David, http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ Looks good for me. Not a *R*eviewer. -Dmitry On 2015-04-28 07:50, David Holmes wrote: > Ping: still need a (R)eviewer please. > > Thanks, > David > > On 25/04/2015 7:45 AM, David Holmes wrote: >> Hi Thomas, >> >> Thanks for looking at this. >> >> Note to readers: Still need a (R)eviewer for this please. >> >> On 24/04/2015 7:00 PM, Thomas St?fe wrote: >>> Hi David, >>> >>> Unfortunately printing out errno in VMError will not work so well, as it >>> is not clear if it is from fork() or execve(), and it is vulnerable >>> against future changes of os::fork_and_exec(). Also, will not do >>> anything for you on Windows. >> >> I thought about doing something inside fork_and_exec but decided against >> it for a couple of reasons: >> >> 1. Needs to be done for every platform individually. >> 2. Far from clear which mechanism would be appropriate given the >> different contexts in which it can be used - which is also why I did not >> do something for its use when debugging. >> >> As for Windows ... not sure what it will do but I was following existing >> practice - see os_windows.cpp and perfMemory_windows.cpp. >> >>> I do not see a nice solution. Returning errno will not work, or be ugly, >>> because you'd need to return GetLastError for windows, which has a >>> different semantic, and the caller must remember that. >> >> And a return value, unless encoded, won't tell you which of fork and >> execve failed. >> >>> On Solaris, os::fork_and_exec() prints a warning if PrintWarning() is >>> on, which in my opinion does not help. That printout is very verbose and >>> you have to remember setting it before starting the process. >>> >>> In some places in error handling (e.g. "check_dump_limits()") we return >>> a string in a caller provided buffer describing the error which then is >>> printed into the error logs. So, that may be a pragmatic solution, >>> especially because we already have the scratch buffer in >>> VMError::report_and_die(). >>> >>> On the other hand, in almost any os::... function we just swallow error >>> details, as we did in os::fork_and_exec() before, so maybe we just leave >>> it at this. >> >> I'll leave what I have now, pending further comments from anyone. It is >> better than nothing I think, and would have saved me a bit of time when >> I first encountered the problem with the missing syscall. >> >>> Otherwise, change looks fine to me. >> >> Thanks, >> David >> >>> ..Thomas >>> >>> >>> >>> >>> On Fri, Apr 24, 2015 at 4:03 AM, David Holmes >> > wrote: >>> >>> Hi Thomas, >>> >>> On 23/04/2015 6:00 PM, Thomas St?fe wrote: >>> >>> On Thu, Apr 23, 2015 at 9:50 AM, David Holmes >>> >>> >> >> wrote: >>> On 23/04/2015 5:24 PM, Thomas St?fe wrote: >>> - would it be possible to use vfork() instead of >>> fork()? Might >>> increase >>> the chance of fork() succeeding in out-of-memory >>> scenarios. The way >>> fork/execve is used here is simple enough for vfork(). >>> >>> I'm reluctant to use vfork() as it is an unknown. The use >>> of fork() >>> has been trialled by Google with no problem. >>> >>> I understand. >>> >>> We use vfork() by default on Linux and HP-UX since 3-4 years for >>> Runtime.exec() without problems (but our implementation differs >>> wildly >>> from the standard one). But then, Runtime.exec does not get >>> called in >>> error situations, so the conditions may be different for >>> os::fork_and_exec(). >>> >>> >>> Right - os::fork_and_exec is potentially a lot more fragile given >>> the potential execution context. Which prompted me to add a second >>> test for the general OnError handling case. I also moved the tests >>> to runtime/ErrorHandling to match the directory that exists in >>> JDK 9. >>> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ >>> >>> Thanks, >>> David >>> >>> >>> - would it be possible to print out errno in case fork >>> fails? >>> >>> >>> Sure. >>> >>> >>> Thanks! >>> >>> ..Thomas >>> >>> Thanks, >>> David >>> >>> Regards, Thomas >>> >>> >>> On Thu, Apr 23, 2015 at 8:40 AM, David Holmes >>> >> >> > >>> >> >>> >>> >> >>> wrote: >>> >>> webrev: >>> http://cr.openjdk.java.net/~dholmes/8078470/webrev/ >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8078470 >>> >>> For historical reasons, dating back to >>> LinuxThreads, >>> os::fork_and_exec uses direct syscalls to perform >>> fork and >>> execve >>> functions. The fork syscall has been deprecated on >>> linux >>> for quite >>> some time and some distributions are now >>> shipping with >>> deprecated >>> syscalls removed - this results in a ENOSYS error >>> and the >>> "OnError" >>> commands that utilize os::fork_and_exec no longer >>> work. >>> >>> The problem was discussed here: >>> >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html >>> >>> >>> It seems the concerns surrounding direct use of >>> glibc >>> fork() and >>> exec() are no longer legitimate and Martin >>> Buchholz reports >>> that >>> Google replaced the syscalls with glibc calls some >>> time ago >>> and have >>> not had any problems. So we propose to apply the >>> same change >>> uniformly on Linux. >>> >>> This is initially going into 8u60 via jdk8u-hs-dev >>> due to time >>> constraints on the 8u60 schedule, and an internal >>> limitation >>> preventing me from pushing this to 9 right now. >>> But it will be >>> "backported" to 9 ASAP. >>> >>> Thanks, >>> David >>> >>> >>> >>> -- 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 alexander.kulyakhtin at oracle.com Tue Apr 28 08:55:42 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 28 Apr 2015 01:55:42 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: Hi, Could someone, please, comment on the proposed renaming from com.oracle.java.testlibrary to jdk.test.lib in the hotspot repo? The changes have been verified by running all the hotspot tests and making sure there are no compilation or other errors related to the change. Best regards, Alexander ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Friday, April 24, 2015 5:34:22 PM GMT +03:00 Iraq Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Hi, Could I, please, have a review of this tests-only change: https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html The change renames com.oracle.java.testlibrary package to jdk.test.lib package: The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, Everywhere in the hotspot/test files import statements have been changed as needed. Best regards, Alex From mikael.gerdin at oracle.com Tue Apr 28 08:55:56 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 28 Apr 2015 10:55:56 +0200 Subject: Why does a fastdebug build compile with -O3 *and* -O0? In-Reply-To: <1430145195.3349.23.camel@redhat.com> References: <1430145195.3349.23.camel@redhat.com> Message-ID: <553F4B1C.4070207@oracle.com> Severin, On 2015-04-27 16:33, Severin Gehwolf wrote: > Hi, > > I've noticed that a fastdebug build of recent hs-rt compiles objects > with -O3 *and* -O0. Is this a bug or a feature? If it's a feature, > what's the rationale? This does not appear to be the case when I build on my machine. I also don't get "-fstack-protector-all --param ssp-buffer-size=1" Those appear to be set in DEBUG_CFLAGS in gcc.make. The first line of fastdebug.make uses an interesting hack to set FASTDEBUG_CFLAGS to DEBUG_CFLAGS unless FASTDEBUG_CFLAGS is already set. FASTDEBUG_CFLAGS is only set in gcc.make if ENABLE_FULL_DEBUG_SYMBOLS is 0. So I tried with: hs-rt-open/hotspot$ make -C make/ ALT_BOOTDIR=/usr/lib/jvm/jdk-8-oracle-x64 HOTSPOT_BUILD_JOBS=24 ARCH_DATA_MODEL=64 ENABLE_FULL_DEBUG_SYMBOLS=0 fastdebug And that reproduces your problem. This is most certainly a bug in the build system. The hotspot makefiles are horrible. /Mikael > > I'm not sure what GCC does with that, but it appears it just uses -O0 > (last seen option?). > > Example: > /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DCHECK_UNHANDLED_OOPS -I. -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_BUILD_USER="\"sgehwolf\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGE! T_COMPILER _gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O3 -O0 -fstack-protector-all --param ssp-buffer-size=1 -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual -Wtype-limits -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/virtualMemoryTracker.o.d -fpch-deps -o virtualMemoryTracker.o /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/services/virtualMemoryTracker.cpp > Compiling /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/runtime/virtualspace.cpp > > Cheers, > Severin > From sgehwolf at redhat.com Tue Apr 28 09:41:32 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 28 Apr 2015 11:41:32 +0200 Subject: Why does a fastdebug build compile with -O3 *and* -O0? In-Reply-To: <553F4B1C.4070207@oracle.com> References: <1430145195.3349.23.camel@redhat.com> <553F4B1C.4070207@oracle.com> Message-ID: <1430214092.3399.18.camel@redhat.com> Hi Mikael, Adding in build-dev for input. On Tue, 2015-04-28 at 10:55 +0200, Mikael Gerdin wrote: > Severin, > > On 2015-04-27 16:33, Severin Gehwolf wrote: > > Hi, > > > > I've noticed that a fastdebug build of recent hs-rt compiles objects > > with -O3 *and* -O0. Is this a bug or a feature? If it's a feature, > > what's the rationale? > > This does not appear to be the case when I build on my machine. > I also don't get "-fstack-protector-all --param ssp-buffer-size=1" > Those appear to be set in DEBUG_CFLAGS in gcc.make. > The first line of fastdebug.make uses an interesting hack to set > FASTDEBUG_CFLAGS to DEBUG_CFLAGS unless FASTDEBUG_CFLAGS is already set. > FASTDEBUG_CFLAGS is only set in gcc.make if ENABLE_FULL_DEBUG_SYMBOLS is 0. > So I tried with: > hs-rt-open/hotspot$ make -C make/ > ALT_BOOTDIR=/usr/lib/jvm/jdk-8-oracle-x64 HOTSPOT_BUILD_JOBS=24 > ARCH_DATA_MODEL=64 ENABLE_FULL_DEBUG_SYMBOLS=0 fastdebug > > And that reproduces your problem. This is most certainly a bug in the > build system. OK, thanks. Any suggestions as to how to fix this? FWIW, I don't see this problem for JDK 8 fastdebug builds. Example: /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DCHECK_UNHANDLED_OOPS -I. -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.60-b12\"" -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"sgehwolf\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O3 -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/asParNewGeneration.o.d -fpch-deps -o asParNewGeneration.o /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp My make invocation does indeed have ENABLE_FULL_DEBUG_SYMBOLS=0. The full make command line is (the comment says it all, but may be outdated since it's a recurring issue for us distro people): # In order to get correct debug symbols in libjvm.so we need # DEBUG_BINARIES=true ENABLE_FULL_DEBUG_SYMBOLS=0 POST_STRIP_CMD="" make \ SCTP_WERROR= \ DEBUG_BINARIES=true \ ENABLE_FULL_DEBUG_SYMBOLS=0 \ POST_STRIP_CMD="" \ DISABLE_INTREE_EC=true \ LOG=debug images The rationale for DEBUG_BINARIES=true ENABLE_FULL_DEBUG_SYMBOLS=0 POST_STRIP_CMD="" is here (short version: we want full debug symbols in object files and leave the stripping to rpm): http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012039.html Thread started here: http://mail.openjdk.java.net/pipermail/build-dev/2014-February/012019.html A somewhat related bug I've filed about this a while ago: https://bugs.openjdk.java.net/browse/JDK-8073461 If we could fix this proper, then we wouldn't have to use those non-standard make variables... Cheers, Severin > The hotspot makefiles are horrible. > > /Mikael > > > > > > I'm not sure what GCC does with that, but it appears it just uses -O0 > > (last seen option?). > > > > Example: > > /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DCHECK_UNHANDLED_OOPS -I. -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_BUILD_USER="\"sgehwolf\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGE! > T_COMPILER > _gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O3 -O0 -fstack-protector-all --param ssp-buffer-size=1 -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual -Wtype-limits -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/virtualMemoryTracker.o.d -fpch-deps -o virtualMemoryTracker.o /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/services/virtualMemoryTracker.cpp > > Compiling /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/runtime/virtualspace.cpp > > > > Cheers, > > Severin > > From david.holmes at oracle.com Tue Apr 28 10:50:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Apr 2015 20:50:09 +1000 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <553F33A8.9050807@oracle.com> References: <553E435E.7000302@oracle.com> <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> <553F1892.4000506@oracle.com> <553F33A8.9050807@oracle.com> Message-ID: <553F65E1.3000500@oracle.com> Hi Nils, On 28/04/2015 5:15 PM, Nils Eliasson wrote: > Hi David, > > On 2015-04-28 07:20, David Holmes wrote: >> Hi Nils, >> >> On 28/04/2015 7:07 AM, Kim Barrett wrote: >>> On Apr 27, 2015, at 10:10 AM, Nils Eliasson >>> wrote: >>>> >>>> A drawback is that this option also prevents any usage of SSE on the >>>> i586 platform. >>> >>> That could be a pretty severe drawback. >>> >>> For example, I?ve been working on some GC performance optimizations >>> that can take advantage of SSE when available. I think this change >>> would mean that the relevant code would require compile-time disable >>> and could not use a runtime configuration test (which would succeed >>> and permit SSE usage on anything other than low end embedded or very >>> ancient hardware). >> >> I agree with Kim, this seems an extreme solution for a very specific >> problem (seems like the FP equivalent of compiling for i486 rather >> than i686 :( ). >> >> Where is the code that gets compiled to use the _ltod3 ? The VS docs >> on this flag allude to problems using SEE instructions due to the mix >> of precision that can result, and that it can be avoided by >> intermediate assignments: > > A cast of a long to a float. In any place calling l2f() for example. In > happens regardless of optimization level. Do we do that a lot? If we can change l2f() wouldn't that suffice? > The problem with vs2013 is that it emits an intermediate assignment we > shouldn't have. > >> https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx >> >> So I'm wondering if: >> a) we can fix this in the source code?; or > No. >> b) we can fix this by adding the flag only for specific files?; or > > Yes but I haven't seen any preparations for that in our makefiles. It > would be a bit fragile solution. Windows build doesn't support the CFLAGS/BYFILE construct. >> c) we can fix this by modifying the FP control word to give SSE and >> x87 the same settings? > > No, it is the choice of instructions that is wrong. They explicitly cast > the long to a double first and then to the float. So really this is a VS compiler bug? (not that that helps us in any way). >> >> Also we have the problem reported in >> >> https://bugs.openjdk.java.net/browse/JDK-8015396 >> >> regarding unexpected NaNs. Is it related to the same underlying >> problem of using SSE/SSE2 instead of x87, or by mixing them? > > That is a separate problem. But presumably related. Thanks, David >> >> I'd accept the current fix as a temporary workaround to get the tests >> passing again. >> >> Thanks, >> David > > ok, > > Thanks, > Nils From alexander.kulyakhtin at oracle.com Tue Apr 28 11:08:54 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 28 Apr 2015 04:08:54 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: Hi David, Thank you very much for your comments. > I presume this is a first step towards fixing: > https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? Yes, this is correct > Did you use "hg rename" for that? The webrev suggests not as it shows No, I used hg add and hg delete. I'm going to fix this now by doing hg rename > Copyright dates will need updating in many cases. I'm going to update the copyrights I'll send out the updated webrev as soon as I'm done. Best regards, Alex ----- Original Message ----- From: david.holmes at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Hi Alex, On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: > Hi, > > Could I, please, have a review of this tests-only change: > > https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package > Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html > > The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, deleted and added files rather than moved ones. > Everywhere in the hotspot/test files import statements have been changed as needed. Seems okay based on scanning through the patch. Copyright dates will need updating in many cases. Thanks, David > Best regards, > Alex > > > From staffan.larsen at oracle.com Tue Apr 28 12:05:43 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 Apr 2015 14:05:43 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <553A5085.10805@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> <553A0E2E.4090805@oracle.com> <553A5085.10805@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 24 apr 2015, at 16:17, Yekaterina Kantserova wrote: > > All suggestions have been implemented. Please find new webrevs here: > > webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.02 > webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.02 > webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.01 > > // Katja > > > > On 04/24/2015 12:10 PM, Staffan Larsen wrote: >> >>> On 24 apr 2015, at 11:34, Yekaterina Kantserova > wrote: >>> >>> Hi, >>> >>> Here comes the updated version. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>> >>> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ >>> webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ >> >> test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java: >> >> In main() I think you should change the deleteOnExit() to just delete(). There is no reason to wait with it. >> >> Perhaps we should also verify that the file does not already exists before we try to write to it. If it exists, we can delete it. >> >> >> >>> webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ >> >> test/serviceability/dcmd/gc/HeapDumpTest.java: >> >> Same thing: call delete() instead of deleteOnExit(). >> >> >>> >>> >>> One comment about changes in hotspot part. The refactored version of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: >>> >>> 70 /* >>> 71 * Some hprof dumps of all objects contain constantPoolOop references that cannot be resolved, so we ignore >>> 72 * failures about resolving constantPoolOop fields using a negative lookahead >>> 73 */ >>> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to resolve object.*constantPoolOop.*).*"); >>> >>> It depends on that the current version of jdk.test.lib.hprof parser simply write down warnings to stdout. As a result the test needs to invent own logic to parse it. >>> >>> I suggest instead to improve jdk.test.lib.hprof parser as a separate RFE. The parser will collect such information and provide a new method for getting it, e.g. jdk.test.lib.hprof.model.Snapshot.getWarnings(). The serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly when RFE is implemented. >> >> Sounds right. A quick, hacky solution is to redirect System.out to a stream or file while running the parser? >> >> /Staffan >> >>> >>> >>> Thanks, >>> Katja >>> >>> >>> >>> On 04/22/2015 03:09 PM, Staffan Larsen wrote: >>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova> wrote: >>>> >>>>> >>>> >>>>>Hi, >>>> >>>>> >>>> >>>>>Could I please have a review of this fix. >>>> >>>>> >>>> >>>>>bug:https:// bugs.openjdk.java.net/browse/JDK-8059047 >>>> >>>>>webrev:http:// cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>> >>>>> >>>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039 ). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>>> >>>>> >>>> >>>>>The old jhat packages have been moved as follows: >>>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>> >>>>> >>>> >>>>>The source has not been changed except Copyrights year. >>>> >>>>> >>>> >>>>>Thanks, >>>> >>>>>Katja >>> >> > From yekaterina.kantserova at oracle.com Tue Apr 28 12:11:38 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 28 Apr 2015 14:11:38 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> <553A0E2E.4090805@oracle.com> <553A5085.10805@oracle.com> Message-ID: <553F78FA.3090202@oracle.com> Staffan, Thanks for the review! // Katja On 04/28/2015 02:05 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 24 apr 2015, at 16:17, Yekaterina Kantserova >> > > wrote: >> >> All suggestions have been implemented. Please find new webrevs here: >> >> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.02 >> webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.02 >> webrev hotspot: >> http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.01 >> >> // Katja >> >> >> >> On 04/24/2015 12:10 PM, Staffan Larsen wrote: >>> >>>> On 24 apr 2015, at 11:34, Yekaterina Kantserova >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> Here comes the updated version. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>>> >>>> webrev root: >>>> http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ >>>> >>>> webrev jdk: >>>> http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ >>>> >>> >>> test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java: >>> >>> In main() I think you should change the deleteOnExit() to just >>> delete(). There is no reason to wait with it. >>> >>> Perhaps we should also verify that the file does not already exists >>> before we try to write to it. If it exists, we can delete it. >>> >>> >>> >>>> webrev hotspot: >>>> http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ >>>> >>> >>> test/serviceability/dcmd/gc/HeapDumpTest.java: >>> >>> Same thing: call delete() instead of deleteOnExit(). >>> >>> >>>> >>>> >>>> One comment about changes in hotspot part. The refactored version >>>> of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: >>>> >>>> 70 /* >>>> 71 * Some hprof dumps of all objects contain >>>> constantPoolOop references that cannot be resolved, so we ignore >>>> 72 * failures about resolving constantPoolOop fields >>>> using a negative lookahead >>>> 73 */ >>>> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to >>>> resolve object.*constantPoolOop.*).*"); >>>> >>>> It depends on that the current version of jdk.test.lib.hprof parser >>>> simply write down warnings to stdout. As a result the test needs to >>>> invent own logic to parse it. >>>> >>>> I suggest instead to improve jdk.test.lib.hprof parser as a >>>> separate RFE. The parser will collect such information and provide >>>> a new method for getting it, e.g. >>>> jdk.test.lib.hprof.model.Snapshot.getWarnings(). The >>>> serviceability/dcmd/gc/HeapDumpTest.java will be changed >>>> accordingly when RFE is implemented. >>> >>> Sounds right. A quick, hacky solution is to redirect System.out to a >>> stream or file while running the parser? >>> >>> /Staffan >>> >>>> >>>> >>>> Thanks, >>>> Katja >>>> >>>> >>>> >>>> On 04/22/2015 03:09 PM, Staffan Larsen wrote: >>>>> On 22 apr 2015, at 11:17, Yekaterina >>>>> Kantserova>>>> > wrote: >>>>> >>>>> >>>>> >>>>>Hi, >>>>> >>>>> >>>>> >>>>>Could I please have a review of this fix. >>>>> >>>>> >>>>> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047 >>>>> >>>>> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>>> >>>>> >>>>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool >>>>> (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to >>>>> put parser/validator into common test library since the >>>>> functionality can be useful not only for SVC tools tests but even >>>>> for some future GC tests. >>>>> >>>>> >>>>> >>>>>The old jhat packages have been moved as follows: >>>>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>>> >>>>> >>>>> >>>>>The source has not been changed except Copyrights year. >>>>> >>>>> >>>>> >>>>>Thanks, >>>>> >>>>>Katja >>>> >>> >> > From nils.eliasson at oracle.com Tue Apr 28 12:29:03 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 28 Apr 2015 14:29:03 +0200 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> References: <553E435E.7000302@oracle.com> <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> Message-ID: <553F7D0F.7010208@oracle.com> Hi Kim, Which platforms did you ues SSE instructions on? It looks like the default for windows ia32 with VS2010 equals VS2013 with /arch:IA32 flag. Regards, Nils On 2015-04-27 23:07, Kim Barrett wrote: > On Apr 27, 2015, at 10:10 AM, Nils Eliasson wrote: >> A drawback is that this option also prevents any usage of SSE on the i586 platform. > That could be a pretty severe drawback. > > For example, I?ve been working on some GC performance optimizations that can take advantage of SSE when available. I think this change would mean that the relevant code would require compile-time disable and could not use a runtime configuration test (which would succeed and permit SSE usage on anything other than low end embedded or very ancient hardware). > From jesper.wilhelmsson at oracle.com Tue Apr 28 12:52:21 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 28 Apr 2015 14:52:21 +0200 Subject: RFR: CODETOOLS-7901397 - Flag -b is ignored in webrev In-Reply-To: <5535157D.4040105@oracle.com> References: <5535157D.4040105@oracle.com> Message-ID: <553F8285.3020900@oracle.com> Widening the audience since I didn't get any replies on webrev-dev. Is anyone reading that list? Thanks, /Jesper Jesper Wilhelmsson skrev den 20/4/15 17:04: > Hi, > > Please review this fix to make webrev care about the -b flag and make it > possible to produce diffs with whitespace changes. > > Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901397 > Webrev: http://cr.openjdk.java.net/~jwilhelm/CT-7901397/webrev.00/ > > I will also need a sponsor to push this change. > > Thanks, > /Jesper From christian.tornqvist at oracle.com Tue Apr 28 12:55:36 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 28 Apr 2015 08:55:36 -0400 Subject: RFR(XS): 8078558 - [TESTBUG] Merge hotspot_wbapitest with existing jtreg jprt job Message-ID: <00c201d081b2$9f338560$dd9a9020$@oracle.com> Hi everyone, Please review this small change which removes the hotspot_wbapitest test target from jprt and adds the /sanity folder to the hotspot_runtime test group. In /sanity there are 3 tests, ExecuteInternalVMTests.java is already run by other groups, including hotspot_runtime. The remaining 2 test takes less than a second to run. The time saved by this change is somewhere between 1 and 6min per binary tested. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8078558/webrev.hotspot.00/ http://cr.openjdk.java.net/~ctornqvi/webrev/8078558/webrev.root.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8078558 Thanks, Christian From alexander.kulyakhtin at oracle.com Tue Apr 28 13:09:43 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 28 Apr 2015 06:09:43 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> Hi, I've updated the webrev in accordance with David's comments. Could you, please, review the changes: > https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package > Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html Best regards, Alex ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net Cc: serviceability-dev at openjdk.java.net Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Hi David, Thank you very much for your comments. > I presume this is a first step towards fixing: > https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? Yes, this is correct > Did you use "hg rename" for that? The webrev suggests not as it shows No, I used hg add and hg delete. I'm going to fix this now by doing hg rename > Copyright dates will need updating in many cases. I'm going to update the copyrights I'll send out the updated webrev as soon as I'm done. Best regards, Alex ----- Original Message ----- From: david.holmes at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Hi Alex, On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: > Hi, > > Could I, please, have a review of this tests-only change: > > https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package > Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html > > The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, deleted and added files rather than moved ones. > Everywhere in the hotspot/test files import statements have been changed as needed. Seems okay based on scanning through the patch. Copyright dates will need updating in many cases. Thanks, David > Best regards, > Alex > > > From jesper.wilhelmsson at oracle.com Tue Apr 28 13:36:15 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 28 Apr 2015 15:36:15 +0200 Subject: RFR: CODETOOLS-7901397 - Flag -b is ignored in webrev In-Reply-To: <553F879C.1030304@oracle.com> References: <5535157D.4040105@oracle.com> <553F8285.3020900@oracle.com> <553F879C.1030304@oracle.com> Message-ID: <553F8CCF.3070208@oracle.com> Thanks for the review! /Jesper Daniel Fuchs skrev den 28/4/15 15:14: > On 28/04/15 14:52, Jesper Wilhelmsson wrote: >> Widening the audience since I didn't get any replies on webrev-dev. Is >> anyone reading that list? > > Sorry Jesper, > > I intended to reply - but got distracted by other things :-( > > I have looked at your patch and it looks good to me. > > I have also used it for a while (without passing the -b flag > however) - and my webrevs have been looking good to me. > > I am however not a Reviewer for CODE-TOOLS/webrev... > > best regards, > > -- daniel > >> >> Thanks, >> /Jesper >> >> >> Jesper Wilhelmsson skrev den 20/4/15 17:04: >>> Hi, >>> >>> Please review this fix to make webrev care about the -b flag and make it >>> possible to produce diffs with whitespace changes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901397 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/CT-7901397/webrev.00/ >>> >>> I will also need a sponsor to push this change. >>> >>> Thanks, >>> /Jesper > From boris.molodenkov at oracle.com Tue Apr 28 13:31:28 2015 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Tue, 28 Apr 2015 16:31:28 +0300 Subject: [8u60] Request for approval: backport of JDK-8058846 Message-ID: <553F8BB0.7050302@oracle.com> Hi All, I would like to backport fix for JDK-8058846 to 8u60. Bug id: https://bugs.openjdk.java.net/browse/JDK-8058846 Webrev: http://cr.openjdk.java.net/~bmoloden/8058846/webrev.00/ Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4d1463933e28 Review thread for original fix: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-November/016382.html testing: manual with jtreg Thanks, Boris From boris.molodenkov at oracle.com Tue Apr 28 13:32:25 2015 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Tue, 28 Apr 2015 16:32:25 +0300 Subject: [8u60] Request for approval: backport of JDK-8050486 Message-ID: <553F8BE9.7090004@oracle.com> Hi All, I would like to backport fix for JDK-8050486 to 8u60. Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 Webrev: http://cr.openjdk.java.net/~bmoloden/8050486/webrev.00/ Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2f8520599d39 Review thread for original fix: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016754.html testing: manual with jtreg Thanks, Boris From harold.seigel at oracle.com Tue Apr 28 13:40:18 2015 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 28 Apr 2015 09:40:18 -0400 Subject: RFR(XS): 8078558 - [TESTBUG] Merge hotspot_wbapitest with existing jtreg jprt job In-Reply-To: <00c201d081b2$9f338560$dd9a9020$@oracle.com> References: <00c201d081b2$9f338560$dd9a9020$@oracle.com> Message-ID: <553F8DC2.1090701@oracle.com> Hi Christian, This looks good! Thanks, Harold On 4/28/2015 8:55 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change which removes the hotspot_wbapitest test > target from jprt and adds the /sanity folder to the hotspot_runtime test > group. > > > > In /sanity there are 3 tests, ExecuteInternalVMTests.java is already run by > other groups, including hotspot_runtime. The remaining 2 test takes less > than a second to run. > > > > The time saved by this change is somewhere between 1 and 6min per binary > tested. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8078558/webrev.hotspot.00/ > > http://cr.openjdk.java.net/~ctornqvi/webrev/8078558/webrev.root.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8078558 > > > > Thanks, > > Christian > From daniel.daugherty at oracle.com Tue Apr 28 13:48:16 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Apr 2015 07:48:16 -0600 Subject: RFR: CODETOOLS-7901397 - Flag -b is ignored in webrev In-Reply-To: <553F8285.3020900@oracle.com> References: <5535157D.4040105@oracle.com> <553F8285.3020900@oracle.com> Message-ID: <553F8FA0.4050201@oracle.com> > Webrev: http://cr.openjdk.java.net/~jwilhelm/CT-7901397/webrev.00/ webrev.ksh No comments. I have a similar change to a much older version of webrev that I've been fixing relative to /java/devtools/share/bin/webrev so this looks good to me. I'll have to check out that project since I've done webrev fixes in the past. Dan On 4/28/15 6:52 AM, Jesper Wilhelmsson wrote: > Widening the audience since I didn't get any replies on webrev-dev. Is > anyone reading that list? > > Thanks, > /Jesper > > > Jesper Wilhelmsson skrev den 20/4/15 17:04: >> Hi, >> >> Please review this fix to make webrev care about the -b flag and make it >> possible to produce diffs with whitespace changes. >> >> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901397 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/CT-7901397/webrev.00/ >> >> I will also need a sponsor to push this change. >> >> Thanks, >> /Jesper From george.triantafillou at oracle.com Tue Apr 28 13:50:16 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 28 Apr 2015 09:50:16 -0400 Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package In-Reply-To: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> References: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> Message-ID: <553F9018.8010202@oracle.com> Hi Alex, Looks good. -George On 4/28/2015 9:09 AM, Alexander Kulyakhtin wrote: > Hi, > > I've updated the webrev in accordance with David's comments. > > Could you, please, review the changes: > >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html > Best regards, > Alex > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi David, > > Thank you very much for your comments. > >> I presume this is a first step towards fixing: >> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > Yes, this is correct > >> Did you use "hg rename" for that? The webrev suggests not as it shows > No, I used hg add and hg delete. > I'm going to fix this now by doing hg rename > >> Copyright dates will need updating in many cases. > I'm going to update the copyrights > > I'll send out the updated webrev as soon as I'm done. > > Best regards, > Alex > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi Alex, > > On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could I, please, have a review of this tests-only change: >> >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html >> >> The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > > >> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, > deleted and added files rather than moved ones. > >> Everywhere in the hotspot/test files import statements have been changed as needed. > Seems okay based on scanning through the patch. > > Copyright dates will need updating in many cases. > > Thanks, > David > >> Best regards, >> Alex >> >> >> From lois.foltan at oracle.com Tue Apr 28 13:53:18 2015 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 28 Apr 2015 09:53:18 -0400 Subject: RFR(XS): 8078558 - [TESTBUG] Merge hotspot_wbapitest with existing jtreg jprt job In-Reply-To: <00c201d081b2$9f338560$dd9a9020$@oracle.com> References: <00c201d081b2$9f338560$dd9a9020$@oracle.com> Message-ID: <553F90CE.3030806@oracle.com> Looks good. Lois On 4/28/2015 8:55 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change which removes the hotspot_wbapitest test > target from jprt and adds the /sanity folder to the hotspot_runtime test > group. > > > > In /sanity there are 3 tests, ExecuteInternalVMTests.java is already run by > other groups, including hotspot_runtime. The remaining 2 test takes less > than a second to run. > > > > The time saved by this change is somewhere between 1 and 6min per binary > tested. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8078558/webrev.hotspot.00/ > > http://cr.openjdk.java.net/~ctornqvi/webrev/8078558/webrev.root.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8078558 > > > > Thanks, > > Christian > From jesper.wilhelmsson at oracle.com Tue Apr 28 13:56:49 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 28 Apr 2015 15:56:49 +0200 Subject: RFR: CODETOOLS-7901397 - Flag -b is ignored in webrev In-Reply-To: <553F8FA0.4050201@oracle.com> References: <5535157D.4040105@oracle.com> <553F8285.3020900@oracle.com> <553F8FA0.4050201@oracle.com> Message-ID: <553F91A1.3060405@oracle.com> Thanks for reviewing! I will also need a sponsor since I'm not a committer in the Code-tools project. Thanks, /Jesper Daniel D. Daugherty skrev den 28/4/15 15:48: > > Webrev: http://cr.openjdk.java.net/~jwilhelm/CT-7901397/webrev.00/ > > webrev.ksh > No comments. > > > I have a similar change to a much older version of webrev that I've > been fixing relative to /java/devtools/share/bin/webrev so this > looks good to me. > > I'll have to check out that project since I've done webrev fixes > in the past. > > Dan > > > > > On 4/28/15 6:52 AM, Jesper Wilhelmsson wrote: >> Widening the audience since I didn't get any replies on webrev-dev. Is anyone >> reading that list? >> >> Thanks, >> /Jesper >> >> >> Jesper Wilhelmsson skrev den 20/4/15 17:04: >>> Hi, >>> >>> Please review this fix to make webrev care about the -b flag and make it >>> possible to produce diffs with whitespace changes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901397 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/CT-7901397/webrev.00/ >>> >>> I will also need a sponsor to push this change. >>> >>> Thanks, >>> /Jesper > From coleen.phillimore at oracle.com Tue Apr 28 13:58:46 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Apr 2015 09:58:46 -0400 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <553F0C42.4060000@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <553E76C4.6090401@oracle.com> <553E96A2.3050000@oracle.com> <553E9B24.3080809@oracle.com> <553F0C42.4060000@oracle.com> Message-ID: <553F9216.6080106@oracle.com> On 4/28/15, 12:27 AM, serguei.spitsyn at oracle.com wrote: > On 4/27/15 1:25 PM, serguei.spitsyn at oracle.com wrote: >> On 4/27/15 1:05 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> Thank you for the review! >>> >>> On 4/27/15 10:49 AM, Coleen Phillimore wrote: >>>> >>>> Serguei, >>>> >>>> This looks nice. I thought this change was going to delay calling >>>> AdjustCpoolCacheAndVtable until the end of the redefinition, rather >>>> than for each class, so was a bit confused by the change. >>> >>> I consider this for as a next round of optimizations which is more >>> risky. >>> We need to decide when we are Ok to take this risk. >>> My guess is that it is better to do it together with the constant >>> pool merge elimination. >> >> Sorry, I forgot to tell that my plan is to open another bug that should >> cover moving all this adjustments to the end of redefinition. >> This was a source of the confusion! > > I've filed a separate bug report for the above: > https://bugs.openjdk.java.net/browse/JDK-8078725 This is good. I'll watch this next bug. Yes, the optimizations are more risky here but I think they would still use the same code. But it definitely needs more testing. Coleen > > > Thanks, > Serguei > >> >> Thanks, >> Serguei >> >>> >>>> >>>> Your change is a nice cleanup and improves MethodHandle method >>>> replacement performance. >>> >>> Thanks! >>> >>>> >>>> Your backport may not be simple for jdk8 because >>>> PreviousVersionNode is another type and not an InstanceKlass. Maybe >>>> you've convinced me that it's worth backporting those changes too. >>>> Let me know. >>> >>> I've already backported the first chunk where this problem was hit. >>> It seems, this one should not be harder to backport. >>> >>> Thanks! >>> Serguei >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Coleen and Dan, >>>>> >>>>> This is the second class redefinition scalability/optimization fix >>>>> that is in my queue to push into 9 and 8u60. >>>>> >>>>> The approach is similar to the first one but much smaller. >>>>> For convenience, these are the links to the first scalability fix: >>>>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >>>>> >>>>> Please, let me know if you have any chance to review this. >>>>> This is the last one that is waiting for your attention! :) >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>>>>> >>>>>> >>>>>> Open hotspot webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> This is the 2-nd round of performance/calability fixes in >>>>>> class redefinition. >>>>>> This time, the two remaining issues that were left alone in >>>>>> the first round fix: >>>>>> - optimized ConstantPoolCache::adjust_method_entries() is >>>>>> used for previous versions >>>>>> - the MemberNameTable::adjust_method_entries() has been >>>>>> optimized too >>>>>> - some cleanup >>>>>> >>>>>> >>>>>> Testing: >>>>>> In progress: nsk redefine classes tests, JTREG >>>>>> java/lang/instrument, com/sun/jdi >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Tue Apr 28 14:28:20 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Apr 2015 10:28:20 -0400 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory Message-ID: <553F9904.602@oracle.com> This saves me 6 backspaces every time I try to edit this file. Tested with no precompiled headers (my default now) and JPRT. I'll update the copyrights when I commit the changes. open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ bug link https://bugs.openjdk.java.net/browse/JDK-8068352 Thanks, Coleen From bengt.rutisson at oracle.com Tue Apr 28 14:39:52 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 28 Apr 2015 16:39:52 +0200 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553F9904.602@oracle.com> References: <553F9904.602@oracle.com> Message-ID: <553F9BB8.1050109@oracle.com> Hi Coleen, On 28/04/15 16:28, Coleen Phillimore wrote: > This saves me 6 backspaces every time I try to edit this file. :) > > Tested with no precompiled headers (my default now) and JPRT. > I'll update the copyrights when I commit the changes. > > open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ > bug link https://bugs.openjdk.java.net/browse/JDK-8068352 Looks good. Thanks, Bengt > > Thanks, > Coleen From sgehwolf at redhat.com Tue Apr 28 14:40:58 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 28 Apr 2015 16:40:58 +0200 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553F9904.602@oracle.com> References: <553F9904.602@oracle.com> Message-ID: <1430232058.3399.38.camel@redhat.com> Hi, Disclaimer: Not a *R*eviewer. On Tue, 2015-04-28 at 10:28 -0400, Coleen Phillimore wrote: > This saves me 6 backspaces every time I try to edit this file. > > Tested with no precompiled headers (my default now) and JPRT. > I'll update the copyrights when I commit the changes. > > open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ > bug link https://bugs.openjdk.java.net/browse/JDK-8068352 One nit. In src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp includes are not alphabetically sorted. Cheers, Severin > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Apr 28 14:44:41 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Apr 2015 10:44:41 -0400 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <1430232058.3399.38.camel@redhat.com> References: <553F9904.602@oracle.com> <1430232058.3399.38.camel@redhat.com> Message-ID: <553F9CD9.40906@oracle.com> On 4/28/15, 10:40 AM, Severin Gehwolf wrote: > Hi, > > Disclaimer: Not a *R*eviewer. > > On Tue, 2015-04-28 at 10:28 -0400, Coleen Phillimore wrote: >> This saves me 6 backspaces every time I try to edit this file. >> >> Tested with no precompiled headers (my default now) and JPRT. >> I'll update the copyrights when I commit the changes. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8068352 > One nit. In > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp includes are not alphabetically sorted. Oh, thanks, I thought I'd gotten them all. Coleen > > Cheers, > Severin > >> Thanks, >> Coleen > > From karen.kinnear at oracle.com Tue Apr 28 14:46:24 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 28 Apr 2015 10:46:24 -0400 Subject: RFR (XS): 8030680: 292 cleanup from default method code assessment In-Reply-To: <4D282D36-0F73-4562-B986-6A344C68A5A3@oracle.com> References: <47514E27-2AD4-497C-91A1-56704D9CEF2C@oracle.com> <4D282D36-0F73-4562-B986-6A344C68A5A3@oracle.com> Message-ID: <9B62CB5C-FC50-4F1B-A621-B6D92E59587A@oracle.com> Michael, I am good with all of your responses. Thanks for the updates and additional testing. many thanks, Karen On Apr 27, 2015, at 11:08 AM, Michael Haupt wrote: > Hi Karen, > > thank you very much for your comments. My responses are below. > >> Am 23.04.2015 um 22:08 schrieb Karen Kinnear : >> 1. In klassVtable::method_count_for_interface: >> A couple of optional suggestions while you are cleaning this up: >> >> If length were initialized to 0, we would not need to have two different return locations. >> If the ASSERT was right before the return, i.e. not in the if (m->has_itable_index(), >> we would be checking the return value for all cases and it might be more future proof >> if someone were to extend the logic. > > That's a good suggestion; thanks. I've refactored the method to have one return statement only, and moved the ASSERT block to just before that. > >> Not sure if we would need the local copy, i.e. nof_methods_copy - but I do >> appreciate that as also future proofing. > > It's more defensive now - I don't think debugging code should change local state, even if that's directly before a return. > >> 2. init_method_MemberName >> I would be much more comfortable with conditional if (m.not_null() rather >> than assert - which only does something in debug mode. > > All of the checks of this sort in this method use assert() - and there are many places throughout the file (and other files) that use assert() in similar cases as well. If this should be changed to if-plus-raise-error, then that should be the case for all other similar uses of assert(), or the two that were introduced in the change are somehow special. Is this the case? I guess the assumption is that we have generated this code internally and so this should not cause a problem. > >> 3. A favor - while you are in klassVtable.cpp ? >> Harold and I were reading the tracing information looking at a different bug today >> and realized some of the tracing is misleading. >> >> 3A: In assign_itable_indices_for_interface it says >> "Initializing itable for interface" >> change to >> "Initializing itable indices for interface" >> >> If you read the comments closely, an interface does not actually have an itable, but >> its methods need to have either a vtable index or an itable index. This code here >> assigns itable indices to methods that do not already have a vtable index (from j.l.Object) >> >> 3B: >> assign_itable_indices_for_interface >> if (m->has_vtable_index) ... "itable index %d for method ..." >> could you possibly change that to "vtable index %d for method" >> >> that would help people be less confused debugging this. > > Both applied. > >> 4. Testing >> Thank you for the testing you already did. >> ... >> For this particular change I would ask that in addition to what you already ran >> you run (with a fastdebug build): - Christian Tornqvist can tell you how to run them >> vm.quick.testlist >> default methods tests (default mode and -mode invoke) >> jtreg java/util/streams (our favorite default method shakers) > > Thanks for the heads-up about testing for rt changes. I've applied the changes as described above and am now working on the testing. Will upload a revised webrev once that's successful. > > Best, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From staffan.larsen at oracle.com Tue Apr 28 15:09:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 Apr 2015 17:09:53 +0200 Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package In-Reply-To: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> References: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> Message-ID: Looks good! Thanks, /Staffan > On 28 apr 2015, at 15:09, Alexander Kulyakhtin wrote: > > Hi, > > I've updated the webrev in accordance with David's comments. > > Could you, please, review the changes: > >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html > > Best regards, > Alex > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi David, > > Thank you very much for your comments. > >> I presume this is a first step towards fixing: >> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > Yes, this is correct > >> Did you use "hg rename" for that? The webrev suggests not as it shows > No, I used hg add and hg delete. > I'm going to fix this now by doing hg rename > >> Copyright dates will need updating in many cases. > I'm going to update the copyrights > > I'll send out the updated webrev as soon as I'm done. > > Best regards, > Alex > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi Alex, > > On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could I, please, have a review of this tests-only change: >> >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html >> >> The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > > > >> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, > > deleted and added files rather than moved ones. > >> Everywhere in the hotspot/test files import statements have been changed as needed. > > Seems okay based on scanning through the patch. > > Copyright dates will need updating in many cases. > > Thanks, > David > >> Best regards, >> Alex >> >> >> From stefan.karlsson at oracle.com Tue Apr 28 15:29:08 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 28 Apr 2015 17:29:08 +0200 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553F9904.602@oracle.com> References: <553F9904.602@oracle.com> Message-ID: <553FA744.9090505@oracle.com> On 2015-04-28 16:28, Coleen Phillimore wrote: > This saves me 6 backspaces every time I try to edit this file. > > Tested with no precompiled headers (my default now) and JPRT. > I'll update the copyrights when I commit the changes. > > open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ > bug link https://bugs.openjdk.java.net/browse/JDK-8068352 What about the SA agent? :D agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualSpace.java Thanks, StefanK > > Thanks, > Coleen From alexander.kulyakhtin at oracle.com Tue Apr 28 15:39:26 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 28 Apr 2015 08:39:26 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: Hi Staffan, Thank you very much for the reviewing. Best regards, Alex ----- Original Message ----- From: staffan.larsen at oracle.com To: alexander.kulyakhtin at oracle.com Cc: david.holmes at oracle.com, hotspot-dev at openjdk.java.net, serviceability-dev at openjdk.java.net Sent: Tuesday, April 28, 2015 6:09:55 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Looks good! Thanks, /Staffan > On 28 apr 2015, at 15:09, Alexander Kulyakhtin wrote: > > Hi, > > I've updated the webrev in accordance with David's comments. > > Could you, please, review the changes: > >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html > > Best regards, > Alex > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi David, > > Thank you very much for your comments. > >> I presume this is a first step towards fixing: >> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > Yes, this is correct > >> Did you use "hg rename" for that? The webrev suggests not as it shows > No, I used hg add and hg delete. > I'm going to fix this now by doing hg rename > >> Copyright dates will need updating in many cases. > I'm going to update the copyrights > > I'll send out the updated webrev as soon as I'm done. > > Best regards, > Alex > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi Alex, > > On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could I, please, have a review of this tests-only change: >> >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html >> >> The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > > > >> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, > > deleted and added files rather than moved ones. > >> Everywhere in the hotspot/test files import statements have been changed as needed. > > Seems okay based on scanning through the patch. > > Copyright dates will need updating in many cases. > > Thanks, > David > >> Best regards, >> Alex >> >> >> From daniel.daugherty at oracle.com Tue Apr 28 16:04:15 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Apr 2015 10:04:15 -0600 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: <553F1192.60309@oracle.com> References: <553893DF.5060406@oracle.com> <5538A460.5020902@oracle.com> <5539A488.3070306@oracle.com> <553AB970.9060309@oracle.com> <553F1192.60309@oracle.com> Message-ID: <553FAF7F.7050109@oracle.com> > http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ src/os/linux/vm/os_linux.cpp So much cleaner now! src/share/vm/utilities/vmError.cpp L1017: out.print_cr("os::fork_and_exec failed: %s", strerror(errno)); L1104: tty->print_cr("os::fork_and_exec failed: %s", strerror(errno)); So how about adding the 'errno' value in parens: "(%d)" just in case strerror() can't handle the 'errno' param? test/runtime/ErrorHandling/TestOnError.java L38: if (!Platform.isDebugBuild()) { Should this be the new @requires tag instead? L63: output.stdoutShouldMatch("^" + msg); // match start of line only Is the 'OnError' handler serialized? In other words, do we have some assurance that the OnError output will be on a line by itself and not mixed with other "crashing VM" output? test/runtime/ErrorHandling/TestOnOutOfMemoryError.java L67: output.stdoutShouldMatch("^" + msg); // match start of line only Same question about output interleaving. I don't think any of my comments are critical so you can choose to make the changes or not. Thumbs up. Dan On 4/27/15 10:50 PM, David Holmes wrote: > Ping: still need a (R)eviewer please. > > Thanks, > David > > On 25/04/2015 7:45 AM, David Holmes wrote: >> Hi Thomas, >> >> Thanks for looking at this. >> >> Note to readers: Still need a (R)eviewer for this please. >> >> On 24/04/2015 7:00 PM, Thomas St?fe wrote: >>> Hi David, >>> >>> Unfortunately printing out errno in VMError will not work so well, >>> as it >>> is not clear if it is from fork() or execve(), and it is vulnerable >>> against future changes of os::fork_and_exec(). Also, will not do >>> anything for you on Windows. >> >> I thought about doing something inside fork_and_exec but decided against >> it for a couple of reasons: >> >> 1. Needs to be done for every platform individually. >> 2. Far from clear which mechanism would be appropriate given the >> different contexts in which it can be used - which is also why I did not >> do something for its use when debugging. >> >> As for Windows ... not sure what it will do but I was following existing >> practice - see os_windows.cpp and perfMemory_windows.cpp. >> >>> I do not see a nice solution. Returning errno will not work, or be >>> ugly, >>> because you'd need to return GetLastError for windows, which has a >>> different semantic, and the caller must remember that. >> >> And a return value, unless encoded, won't tell you which of fork and >> execve failed. >> >>> On Solaris, os::fork_and_exec() prints a warning if PrintWarning() is >>> on, which in my opinion does not help. That printout is very verbose >>> and >>> you have to remember setting it before starting the process. >>> >>> In some places in error handling (e.g. "check_dump_limits()") we return >>> a string in a caller provided buffer describing the error which then is >>> printed into the error logs. So, that may be a pragmatic solution, >>> especially because we already have the scratch buffer in >>> VMError::report_and_die(). >>> >>> On the other hand, in almost any os::... function we just swallow error >>> details, as we did in os::fork_and_exec() before, so maybe we just >>> leave >>> it at this. >> >> I'll leave what I have now, pending further comments from anyone. It is >> better than nothing I think, and would have saved me a bit of time when >> I first encountered the problem with the missing syscall. >> >>> Otherwise, change looks fine to me. >> >> Thanks, >> David >> >>> ..Thomas >>> >>> >>> >>> >>> On Fri, Apr 24, 2015 at 4:03 AM, David Holmes >> > wrote: >>> >>> Hi Thomas, >>> >>> On 23/04/2015 6:00 PM, Thomas St?fe wrote: >>> >>> On Thu, Apr 23, 2015 at 9:50 AM, David Holmes >>> >>> >> >> wrote: >>> On 23/04/2015 5:24 PM, Thomas St?fe wrote: >>> - would it be possible to use vfork() instead of >>> fork()? Might >>> increase >>> the chance of fork() succeeding in out-of-memory >>> scenarios. The way >>> fork/execve is used here is simple enough for vfork(). >>> >>> I'm reluctant to use vfork() as it is an unknown. The use >>> of fork() >>> has been trialled by Google with no problem. >>> >>> I understand. >>> >>> We use vfork() by default on Linux and HP-UX since 3-4 years >>> for >>> Runtime.exec() without problems (but our implementation differs >>> wildly >>> from the standard one). But then, Runtime.exec does not get >>> called in >>> error situations, so the conditions may be different for >>> os::fork_and_exec(). >>> >>> >>> Right - os::fork_and_exec is potentially a lot more fragile given >>> the potential execution context. Which prompted me to add a second >>> test for the general OnError handling case. I also moved the tests >>> to runtime/ErrorHandling to match the directory that exists in >>> JDK 9. >>> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ >>> >>> Thanks, >>> David >>> >>> >>> - would it be possible to print out errno in case fork >>> fails? >>> >>> >>> Sure. >>> >>> >>> Thanks! >>> >>> ..Thomas >>> >>> Thanks, >>> David >>> >>> Regards, Thomas >>> >>> >>> On Thu, Apr 23, 2015 at 8:40 AM, David Holmes >>> >> >>> >> > >>> >> >>> >>> >> >>> wrote: >>> >>> webrev: >>> http://cr.openjdk.java.net/~dholmes/8078470/webrev/ >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8078470 >>> >>> For historical reasons, dating back to >>> LinuxThreads, >>> os::fork_and_exec uses direct syscalls to perform >>> fork and >>> execve >>> functions. The fork syscall has been >>> deprecated on >>> linux >>> for quite >>> some time and some distributions are now >>> shipping with >>> deprecated >>> syscalls removed - this results in a ENOSYS error >>> and the >>> "OnError" >>> commands that utilize os::fork_and_exec no longer >>> work. >>> >>> The problem was discussed here: >>> >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html >>> >>> >>> It seems the concerns surrounding direct use of >>> glibc >>> fork() and >>> exec() are no longer legitimate and Martin >>> Buchholz reports >>> that >>> Google replaced the syscalls with glibc calls >>> some >>> time ago >>> and have >>> not had any problems. So we propose to apply the >>> same change >>> uniformly on Linux. >>> >>> This is initially going into 8u60 via >>> jdk8u-hs-dev >>> due to time >>> constraints on the 8u60 schedule, and an internal >>> limitation >>> preventing me from pushing this to 9 right now. >>> But it will be >>> "backported" to 9 ASAP. >>> >>> Thanks, >>> David >>> >>> >>> >>> From kim.barrett at oracle.com Tue Apr 28 16:25:08 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Apr 2015 12:25:08 -0400 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <553F7D0F.7010208@oracle.com> References: <553E435E.7000302@oracle.com> <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> <553F7D0F.7010208@oracle.com> Message-ID: <94D83595-5337-43D3-B3D4-697719D5AB92@oracle.com> On Apr 28, 2015, at 8:29 AM, Nils Eliasson wrote: > > Which platforms did you ues SSE instructions on? It looks like the default for windows ia32 with VS2010 equals VS2013 with /arch:IA32 flag. I haven?t actually written the code I was alluding to. I am working on card table scanning performance as a sort of background task, and research uncovered that there are ways to make use of SSE2 to get potentially significant gains. I was expecting to need a runtime test to decide whether to use that approach; the point where that test would occur would make it not have any impact on scanning performance. I think only 32bit (x86 obviously) platforms would require the runtime check, as SSE2 is (I think) always present for 64bit x86. From mikael.vidstedt at oracle.com Tue Apr 28 17:03:06 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 28 Apr 2015 10:03:06 -0700 Subject: RFR(XS): 8078558 - [TESTBUG] Merge hotspot_wbapitest with existing jtreg jprt job In-Reply-To: <00c201d081b2$9f338560$dd9a9020$@oracle.com> References: <00c201d081b2$9f338560$dd9a9020$@oracle.com> Message-ID: <553FBD4A.1080003@oracle.com> Looks good! Cheers, Mikael On 2015-04-28 05:55, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change which removes the hotspot_wbapitest test > target from jprt and adds the /sanity folder to the hotspot_runtime test > group. > > > > In /sanity there are 3 tests, ExecuteInternalVMTests.java is already run by > other groups, including hotspot_runtime. The remaining 2 test takes less > than a second to run. > > > > The time saved by this change is somewhere between 1 and 6min per binary > tested. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8078558/webrev.hotspot.00/ > > http://cr.openjdk.java.net/~ctornqvi/webrev/8078558/webrev.root.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8078558 > > > > Thanks, > > Christian > From daniel.fuchs at oracle.com Tue Apr 28 13:14:04 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 28 Apr 2015 15:14:04 +0200 Subject: RFR: CODETOOLS-7901397 - Flag -b is ignored in webrev In-Reply-To: <553F8285.3020900@oracle.com> References: <5535157D.4040105@oracle.com> <553F8285.3020900@oracle.com> Message-ID: <553F879C.1030304@oracle.com> On 28/04/15 14:52, Jesper Wilhelmsson wrote: > Widening the audience since I didn't get any replies on webrev-dev. Is > anyone reading that list? Sorry Jesper, I intended to reply - but got distracted by other things :-( I have looked at your patch and it looks good to me. I have also used it for a while (without passing the -b flag however) - and my webrevs have been looking good to me. I am however not a Reviewer for CODE-TOOLS/webrev... best regards, -- daniel > > Thanks, > /Jesper > > > Jesper Wilhelmsson skrev den 20/4/15 17:04: >> Hi, >> >> Please review this fix to make webrev care about the -b flag and make it >> possible to produce diffs with whitespace changes. >> >> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901397 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/CT-7901397/webrev.00/ >> >> I will also need a sponsor to push this change. >> >> Thanks, >> /Jesper From coleen.phillimore at oracle.com Tue Apr 28 17:50:01 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Apr 2015 13:50:01 -0400 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553FA744.9090505@oracle.com> References: <553F9904.602@oracle.com> <553FA744.9090505@oracle.com> Message-ID: <553FC849.4060103@oracle.com> On 4/28/15, 11:29 AM, Stefan Karlsson wrote: > On 2015-04-28 16:28, Coleen Phillimore wrote: >> This saves me 6 backspaces every time I try to edit this file. >> >> Tested with no precompiled headers (my default now) and JPRT. >> I'll update the copyrights when I commit the changes. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8068352 > > What about the SA agent? :D Oh, Stefan, you know how to make my day. I'll move that too and retest. Coleen > > agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualSpace.java > > Thanks, > StefanK > >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Tue Apr 28 18:18:44 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Apr 2015 14:18:44 -0400 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553FC849.4060103@oracle.com> References: <553F9904.602@oracle.com> <553FA744.9090505@oracle.com> <553FC849.4060103@oracle.com> Message-ID: <553FCF04.9080400@oracle.com> Thanks to Stefan. Moved and fixed SA VirtualSpace.java also. I reran the sajdi tests. open webrev at http://cr.openjdk.java.net/~coleenp/8068352.02/ thanks, Coleen On 4/28/15, 1:50 PM, Coleen Phillimore wrote: > > On 4/28/15, 11:29 AM, Stefan Karlsson wrote: >> On 2015-04-28 16:28, Coleen Phillimore wrote: >>> This saves me 6 backspaces every time I try to edit this file. >>> >>> Tested with no precompiled headers (my default now) and JPRT. >>> I'll update the copyrights when I commit the changes. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8068352 >> >> What about the SA agent? :D > > Oh, Stefan, you know how to make my day. I'll move that too and retest. > > Coleen >> >> agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualSpace.java >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> Coleen >> > From vladimir.kozlov at oracle.com Tue Apr 28 18:45:59 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Apr 2015 11:45:59 -0700 Subject: [8u60] Request for approval: backport of JDK-8058846 In-Reply-To: <553F8BB0.7050302@oracle.com> References: <553F8BB0.7050302@oracle.com> Message-ID: <553FD567.7020009@oracle.com> Looks good. Thanks, Vladimir On 4/28/15 6:31 AM, Boris Molodenkov wrote: > Hi All, > > I would like to backport fix for JDK-8058846 to 8u60. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8058846 > Webrev: http://cr.openjdk.java.net/~bmoloden/8058846/webrev.00/ > Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4d1463933e28 > Review thread for original fix: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-November/016382.html > > testing: manual with jtreg > > Thanks, > Boris > From nils.eliasson at oracle.com Tue Apr 28 18:44:37 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 28 Apr 2015 20:44:37 +0200 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <94D83595-5337-43D3-B3D4-697719D5AB92@oracle.com> References: <553E435E.7000302@oracle.com> <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> <553F7D0F.7010208@oracle.com> <94D83595-5337-43D3-B3D4-697719D5AB92@oracle.com> Message-ID: <553FD515.9030501@oracle.com> After some further investigation - vs2013 with the /arch:IA32 flag generates similar code to what vs2010 generated before. (Emitting x87 instructions only.) We should not expect any performance regression. //Nils On 2015-04-28 18:25, Kim Barrett wrote: > On Apr 28, 2015, at 8:29 AM, Nils Eliasson wrote: >> Which platforms did you ues SSE instructions on? It looks like the default for windows ia32 with VS2010 equals VS2013 with /arch:IA32 flag. > I haven?t actually written the code I was alluding to. I am working on card table scanning performance as a sort of background task, and research uncovered that there are ways to make use of SSE2 to get potentially significant gains. I was expecting to need a runtime test to decide whether to use that approach; the point where that test would occur would make it not have any impact on scanning performance. I think only 32bit (x86 obviously) platforms would require the runtime check, as SSE2 is (I think) always present for 64bit x86. > > From vladimir.kozlov at oracle.com Tue Apr 28 18:51:10 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Apr 2015 11:51:10 -0700 Subject: [8u60] Request for approval: backport of JDK-8050486 In-Reply-To: <553F8BE9.7090004@oracle.com> References: <553F8BE9.7090004@oracle.com> Message-ID: <553FD69E.1040202@oracle.com> Good. Was there other changes in RTMTestBase.java which were not backported? Changes are different in that file from jdk9 (but the resulting flags are the same). Thanks, Vladimir On 4/28/15 6:32 AM, Boris Molodenkov wrote: > Hi All, > > I would like to backport fix for JDK-8050486 to 8u60. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 > Webrev: http://cr.openjdk.java.net/~bmoloden/8050486/webrev.00/ > Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2f8520599d39 > Review thread for original fix: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016754.html > > testing: manual with jtreg > > Thanks, > Boris > From vladimir.kozlov at oracle.com Tue Apr 28 18:55:58 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Apr 2015 11:55:58 -0700 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <553E435E.7000302@oracle.com> References: <553E435E.7000302@oracle.com> Message-ID: <553FD7BE.8070302@oracle.com> Looks good. Thanks, Vladimir On 4/27/15 7:10 AM, Nils Eliasson wrote: > Hi, > > Please review this patch. > > The bug is caused by the instruction sequence generated by the visual studio compiler when casting a long to a float. > > Visual Studio 2013 has a new behavior where it defaults to generating code targeting SSE2 (and avoids x87). Compiling > for a 64-bit target gives the same result as before. Compiling for 32bit VS2013 generates a call to _ltod3 (long2double) > and then uses a sse2 instruction to cast it to a float. Casting the long to a double and then to a float gives a > different result than casting directly to a float. This is true on all tested configurations. It is unclear why they > just didn't use a MOVQ to load the long to an XMM register and then use the same cvtsi2ss as in the other configurations. > > To fix this we need to add the /arch:IA32 flag to all i586 windows builds. It looks like the IA32 option is ignored on > 64-bit builds but we shouldn't count on that. A drawback is that this option also prevents any usage of SSE on the i586 > platform. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 > Webrev: http://cr.openjdk.java.net/~neliasso/8077590/webrev.03/ > > Regards > Nils > > > > From aph at redhat.com Tue Apr 28 18:56:12 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Apr 2015 19:56:12 +0100 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <553A8B20.9050109@oracle.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> Message-ID: <553FD7CC.9050000@redhat.com> On 04/24/2015 07:27 PM, Dean Long wrote: > Not a review, but a couple things I noticed: > > agent/src/os/linux/ps_proc.c: > > I don't think you need to change this file. There is already > PTRACE_GETREGSET support there. > > > > agent/src/os/linux/Makefile: > > + echo FECK > > The conflict will be handled in a separate bug (8078632). http://cr.openjdk.java.net/~aph/8078521-2/ Andrew. From vladimir.kozlov at oracle.com Tue Apr 28 19:07:03 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Apr 2015 12:07:03 -0700 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <553FD515.9030501@oracle.com> References: <553E435E.7000302@oracle.com> <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> <553F7D0F.7010208@oracle.com> <94D83595-5337-43D3-B3D4-697719D5AB92@oracle.com> <553FD515.9030501@oracle.com> Message-ID: <553FDA57.50502@oracle.com> Kim, First, correctness fix is overweight performance benefits. Second, this is very urgent issue since we can't promote Hotspot for more then 3 weeks now. Third, thank you, Nils, for verifying that the code is the same with this flags as before with vs2010. It means we did not introduced any regressions. Fourth, we can implement more complex fix (per file flags which currently is not supported on windows as David said) later if GC does not care about float point rounding results. But it will take a lot more efforts and testing than current simple fix. You don't want to be flooded by Mincraft bugs :) File RFE. Fifth, 32-bit java on Windows is not as important as 64-bit version which is current mainstream. I don't know why you want to optimize it when it is slower than 64-bit anyway (which has more general registers and other benefits). Regards, Vladimir On 4/28/15 11:44 AM, Nils Eliasson wrote: > After some further investigation - vs2013 with the /arch:IA32 flag generates similar code to what vs2010 generated > before. (Emitting x87 instructions only.) We should not expect any performance regression. > > //Nils > > > > On 2015-04-28 18:25, Kim Barrett wrote: >> On Apr 28, 2015, at 8:29 AM, Nils Eliasson wrote: >>> Which platforms did you ues SSE instructions on? It looks like the default for windows ia32 with VS2010 equals VS2013 >>> with /arch:IA32 flag. >> I haven?t actually written the code I was alluding to. I am working on card table scanning performance as a sort of >> background task, and research uncovered that there are ways to make use of SSE2 to get potentially significant gains. >> I was expecting to need a runtime test to decide whether to use that approach; the point where that test would occur >> would make it not have any impact on scanning performance. I think only 32bit (x86 obviously) platforms would require >> the runtime check, as SSE2 is (I think) always present for 64bit x86. >> >> > From dean.long at oracle.com Tue Apr 28 19:52:40 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 28 Apr 2015 12:52:40 -0700 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <553FD7CC.9050000@redhat.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <553FD7CC.9050000@redhat.com> Message-ID: <553FE508.8060203@oracle.com> On 4/28/2015 11:56 AM, Andrew Haley wrote: > On 04/24/2015 07:27 PM, Dean Long wrote: >> Not a review, but a couple things I noticed: >> >> agent/src/os/linux/ps_proc.c: >> >> I don't think you need to change this file. There is already >> PTRACE_GETREGSET support there. >> >> >> >> agent/src/os/linux/Makefile: >> >> + echo FECK >> >> The conflict will be handled in a separate bug (8078632). > http://cr.openjdk.java.net/~aph/8078521-2/ > > Andrew. > Should serviceability-dev at openjdk.java.net be included? dl From kim.barrett at oracle.com Tue Apr 28 20:26:37 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Apr 2015 16:26:37 -0400 Subject: RFR (S): Failure after windows compiler upgrade In-Reply-To: <553FDA57.50502@oracle.com> References: <553E435E.7000302@oracle.com> <2797424C-241E-490E-BE49-BEA81BE2C743@oracle.com> <553F7D0F.7010208@oracle.com> <94D83595-5337-43D3-B3D4-697719D5AB92@oracle.com> <553FD515.9030501@oracle.com> <553FDA57.50502@oracle.com> Message-ID: <0D947F0D-7731-4446-A4A5-C88A7FF3C6C2@oracle.com> On Apr 28, 2015, at 3:07 PM, Vladimir Kozlov wrote: > > Kim, > > First, correctness fix is overweight performance benefits. > Second, this is very urgent issue since we can't promote Hotspot for more then 3 weeks now. I agree with David Holmes: "I'd accept the current fix as a temporary workaround to get the tests passing again.? That isn?t how it?s been presented so far. A CR for followup would address that concern. > Fifth, 32-bit java on Windows is not as important as 64-bit version which is current mainstream. ?not as important? is very different from ?not important?. Disabling the use of SSE may have widespread effects. I know that gcc uses SSE in all sorts of not necessarily expected places when that feature is enabled. > I don't know why you want to optimize it when it is slower than 64-bit anyway (which has more general registers and other benefits). For the same reason we support it at all? From serguei.spitsyn at oracle.com Tue Apr 28 20:28:42 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Apr 2015 13:28:42 -0700 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553FCF04.9080400@oracle.com> References: <553F9904.602@oracle.com> <553FA744.9090505@oracle.com> <553FC849.4060103@oracle.com> <553FCF04.9080400@oracle.com> Message-ID: <553FED7A.80009@oracle.com> It looks good. It was nice catch with the SA. I hope, the test results will be good. Thanks, Serguei On 4/28/15 11:18 AM, Coleen Phillimore wrote: > > Thanks to Stefan. Moved and fixed SA VirtualSpace.java also. I reran > the sajdi tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8068352.02/ > > thanks, > Coleen > > On 4/28/15, 1:50 PM, Coleen Phillimore wrote: >> >> On 4/28/15, 11:29 AM, Stefan Karlsson wrote: >>> On 2015-04-28 16:28, Coleen Phillimore wrote: >>>> This saves me 6 backspaces every time I try to edit this file. >>>> >>>> Tested with no precompiled headers (my default now) and JPRT. >>>> I'll update the copyrights when I commit the changes. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8068352 >>> >>> What about the SA agent? :D >> >> Oh, Stefan, you know how to make my day. I'll move that too and >> retest. >> >> Coleen >>> >>> agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualSpace.java >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Coleen >>> >> > From coleen.phillimore at oracle.com Tue Apr 28 20:50:43 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Apr 2015 16:50:43 -0400 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553FED7A.80009@oracle.com> References: <553F9904.602@oracle.com> <553FA744.9090505@oracle.com> <553FC849.4060103@oracle.com> <553FCF04.9080400@oracle.com> <553FED7A.80009@oracle.com> Message-ID: <553FF2A3.8040309@oracle.com> Thanks Serguei, the SA tests all pass. Coleen On 4/28/15, 4:28 PM, serguei.spitsyn at oracle.com wrote: > It looks good. > It was nice catch with the SA. > I hope, the test results will be good. > > Thanks, > Serguei > > On 4/28/15 11:18 AM, Coleen Phillimore wrote: >> >> Thanks to Stefan. Moved and fixed SA VirtualSpace.java also. I >> reran the sajdi tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8068352.02/ >> >> thanks, >> Coleen >> >> On 4/28/15, 1:50 PM, Coleen Phillimore wrote: >>> >>> On 4/28/15, 11:29 AM, Stefan Karlsson wrote: >>>> On 2015-04-28 16:28, Coleen Phillimore wrote: >>>>> This saves me 6 backspaces every time I try to edit this file. >>>>> >>>>> Tested with no precompiled headers (my default now) and JPRT. >>>>> I'll update the copyrights when I commit the changes. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8068352 >>>> >>>> What about the SA agent? :D >>> >>> Oh, Stefan, you know how to make my day. I'll move that too and >>> retest. >>> >>> Coleen >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualSpace.java >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> > From coleen.phillimore at oracle.com Tue Apr 28 20:51:08 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Apr 2015 16:51:08 -0400 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553F9BB8.1050109@oracle.com> References: <553F9904.602@oracle.com> <553F9BB8.1050109@oracle.com> Message-ID: <553FF2BC.3070108@oracle.com> Thanks, Bengt! Coleen On 4/28/15, 10:39 AM, Bengt Rutisson wrote: > > Hi Coleen, > > On 28/04/15 16:28, Coleen Phillimore wrote: >> This saves me 6 backspaces every time I try to edit this file. > > :) > >> >> Tested with no precompiled headers (my default now) and JPRT. >> I'll update the copyrights when I commit the changes. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8068352 > > Looks good. > > Thanks, > Bengt > >> >> Thanks, >> Coleen > From stefan.karlsson at oracle.com Tue Apr 28 21:01:17 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 28 Apr 2015 23:01:17 +0200 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553FCF04.9080400@oracle.com> References: <553F9904.602@oracle.com> <553FA744.9090505@oracle.com> <553FC849.4060103@oracle.com> <553FCF04.9080400@oracle.com> Message-ID: <553FF51D.4010607@oracle.com> On 2015-04-28 20:18, Coleen Phillimore wrote: > > Thanks to Stefan. Moved and fixed SA VirtualSpace.java also. I reran > the sajdi tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8068352.02/ Looks good. StefanK > > thanks, > Coleen > > On 4/28/15, 1:50 PM, Coleen Phillimore wrote: >> >> On 4/28/15, 11:29 AM, Stefan Karlsson wrote: >>> On 2015-04-28 16:28, Coleen Phillimore wrote: >>>> This saves me 6 backspaces every time I try to edit this file. >>>> >>>> Tested with no precompiled headers (my default now) and JPRT. >>>> I'll update the copyrights when I commit the changes. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8068352 >>> >>> What about the SA agent? :D >> >> Oh, Stefan, you know how to make my day. I'll move that too and >> retest. >> >> Coleen >>> >>> agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualSpace.java >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Coleen >>> >> > From coleen.phillimore at oracle.com Tue Apr 28 20:59:44 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Apr 2015 16:59:44 -0400 Subject: RFR (simple) 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory In-Reply-To: <553FF51D.4010607@oracle.com> References: <553F9904.602@oracle.com> <553FA744.9090505@oracle.com> <553FC849.4060103@oracle.com> <553FCF04.9080400@oracle.com> <553FF51D.4010607@oracle.com> Message-ID: <553FF4C0.8030705@oracle.com> On 4/28/15, 5:01 PM, Stefan Karlsson wrote: > On 2015-04-28 20:18, Coleen Phillimore wrote: >> >> Thanks to Stefan. Moved and fixed SA VirtualSpace.java also. I >> reran the sajdi tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8068352.02/ > > Looks good. Thanks! Thanks for finding the SA omission. Coleen > > StefanK > >> >> thanks, >> Coleen >> >> On 4/28/15, 1:50 PM, Coleen Phillimore wrote: >>> >>> On 4/28/15, 11:29 AM, Stefan Karlsson wrote: >>>> On 2015-04-28 16:28, Coleen Phillimore wrote: >>>>> This saves me 6 backspaces every time I try to edit this file. >>>>> >>>>> Tested with no precompiled headers (my default now) and JPRT. >>>>> I'll update the copyrights when I commit the changes. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8068352/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8068352 >>>> >>>> What about the SA agent? :D >>> >>> Oh, Stefan, you know how to make my day. I'll move that too and >>> retest. >>> >>> Coleen >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualSpace.java >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> > From mark.reinhold at oracle.com Tue Apr 28 22:02:11 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 28 Apr 2015 15:02:11 -0700 (PDT) Subject: JEP 248: Make G1 the Default Garbage Collector Message-ID: <20150428220211.4355960845@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/248 - Mark From kirk at kodewerk.com Wed Apr 29 07:10:53 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 29 Apr 2015 08:10:53 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <20150428220211.4355960845@eggemoggin.niobe.net> References: <20150428220211.4355960845@eggemoggin.niobe.net> Message-ID: <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> Hi all, Is the G1 ready for this? I see many people moving to G1 but also I?m not sure that we?ve got the tunable correct. I?ve been sorting through a number of recent tuning engagements and my conclusion is that I would like the collector to be aggressive about collecting tenured regions at the beginning of a JVM?s life time but then become less aggressive over time. The reason is the residual waste that I see left behind because certain regions never hit the threshold needed to be included in the CSET. But, on aggregate, the number of regions in this state does start to retain a significant about of dead data. The only way to see the effects is to run regular Full GCs.. which of course you don?t really want to do. However, the problem seems to settle down a wee bit over time which is why I was thinking that being aggressive about what is collected in the early stages of a JVMs life should lead to better packing and hence less waste. Note, I don?t really care about the memory waste, only it?s effect on cycle frequencies and pause times. Sorry but I don?t have anything formal about this as I (and I believe many others) are still sorting out what to make of the G1 in prod. Generally the overall results are good but sometimes it?s not that way up front and how to improve things is sometimes challenging. On a side note, the move to Tiered in 8 has also caused a bit of grief. Metaspace has caused a bit of grief and even parallelStream, which works, has come with some interesting side effect. Everyone has been so enamored with Lambdas (rightfully so) that the other stuff has been completely forgotten and some of it has surprised people. I guess I?ll be submitting a talk for J1 on some of the field experience I?ve had with the other stuff. Regards, Kirk On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/248 > > - Mark From sgehwolf at redhat.com Wed Apr 29 07:35:22 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 29 Apr 2015 09:35:22 +0200 Subject: RFR(xs): 8078628: linux-zero does not build without precompiled header In-Reply-To: References: <553D8594.2080803@oracle.com> <553DECF7.4020403@oracle.com> Message-ID: <1430292922.3356.4.camel@redhat.com> Hi Thomas, On Mon, 2015-04-27 at 11:25 +0200, Thomas St?fe wrote: > Hi David, Stefan, > > thanks for reviewing! > > third webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.02/webrev > > Ordering includes alphabetically turned up even more not-selfcontained > includes. This is a really quite annoying work :-) > > I wish there were an official non-PCH nightly build. Not only would people > notice missing headers, it also would make implementation creep into header > files more obvious. This looks good to me (not a *R*eviewer). All variants (release/fastdebug/slowdebug) were broken with PCH disabled. Fixed post-patch. Thanks a lot for fixing it! I'll be sure to add a CI job to the Zero builders which have PCH disabled. Cheers, Severin > Thanks, Thomas > > > On Mon, Apr 27, 2015 at 10:01 AM, Stefan Karlsson < > stefan.karlsson at oracle.com> wrote: > > > Hi Thomas, > > > > On 2015-04-27 02:40, David Holmes wrote: > > > >> Hi Thomas, > >> > >> On 25/04/2015 3:11 AM, Thomas St?fe wrote: > >> > >>> Hi all, > >>> > >>> please review this tiny change. Build was broken for zero/slowdebug when > >>> building without precompiled header. > >>> > >>> bug: https://bugs.openjdk.java.net/browse/JDK-8078628 > >>> webrev: > >>> http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.00/webrev/ > >>> > >> > > The includes are kept sorted in other part of HotSpot, so I think it would > > be good to have them sorted for the zero code as well: > > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.01/webrev/src/share/vm/interpreter/interpreterGenerator.hpp.udiff.html > > > > #include "interpreter/cppInterpreter.hpp" > > +#include "interpreter/interp_masm.hpp" > > #include "interpreter/cppInterpreterGenerator.hpp" > > #include "interpreter/templateInterpreter.hpp" > > #include "interpreter/templateInterpreterGenerator.hpp" > > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.01/webrev/src/cpu/zero/vm/nativeInst_zero.cpp.udiff.html > > > > #include "precompiled.hpp" > > #include "assembler_zero.inline.hpp" > > +#include "interpreter/cppInterpreter.hpp" > > #include "memory/resourceArea.hpp" > > #include "nativeInst_zero.hpp" > > +#include "entry_zero.hpp" > > #include "oops/oop.inline.hpp" > > #include "runtime/handles.hpp" > > #include "runtime/sharedRuntime.hpp" > > > > Thanks, > > StefanK > > > > > > > >> Why the double condition here: > >> > >> 33 #ifdef ZERO > >> 34 #ifdef TARGET_ARCH_zero > >> 35 # include "entry_zero.hpp" > >> 36 #endif > >> 37 #endif > >> > >> ?? > >> > >> Thanks, > >> David > >> > >> > >>> Thank you, > >>> > >>> Thomas > >>> > >>> > > From sgehwolf at redhat.com Wed Apr 29 07:56:43 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 29 Apr 2015 09:56:43 +0200 Subject: RFR(xs): 8078666: JVM fastdebug build compiled with GCC 5 asserts with "widen increases" In-Reply-To: <1430144315.3349.17.camel@redhat.com> References: <1430144315.3349.17.camel@redhat.com> Message-ID: <1430294203.3356.9.camel@redhat.com> Hi, Adding hotspot-dev for wider audience. IMHO hotspot should not rely on undefined behaviour (overflow on signed int/long is undefined) and this should get fixed. --Severin On Mon, 2015-04-27 at 16:18 +0200, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor the following patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8078666 > Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8078666/webrev.02/ > > We've discovered this issue in Fedora where we were seeing a strange > memory leak issue of an OpenJDK build with GCC 5. More info in the bug. > > As it turns out, current hotspot relies on undefined behaviour in > normalize_int_widen()/normalize_long_widen() where an integer overflow > can occur on some inputs. > > The fix is to do the math on the unsigned type where overflows are well > defined. > > Thanks, > Severin > > > From aph at redhat.com Wed Apr 29 08:05:13 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Apr 2015 09:05:13 +0100 Subject: RFR(xs): 8078666: JVM fastdebug build compiled with GCC 5 asserts with "widen increases" In-Reply-To: <1430294203.3356.9.camel@redhat.com> References: <1430144315.3349.17.camel@redhat.com> <1430294203.3356.9.camel@redhat.com> Message-ID: <554090B9.2050306@redhat.com> On 29/04/15 08:56, Severin Gehwolf wrote: > Adding hotspot-dev for wider audience. IMHO hotspot should not rely on > undefined behaviour (overflow on signed int/long is undefined) and this > should get fixed. Absolutely so. This looks like a good patch. Andrew. From goetz.lindenmaier at sap.com Wed Apr 29 09:36:15 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 29 Apr 2015 09:36:15 +0000 Subject: [8u60] Request for approval: backport of 8078482: ppc: pass thread to throw_AbstractMethodError Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC2DF4@DEWDFEMB12A.global.corp.sap> Hi, I would like to backport "8078482: ppc: pass thread to throw_AbstractMethodError". This fixes a fatal error in the ppc port. It touches only ppc files. The jdk9 change applies cleanly except for a whitespace diff: http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.03.jdk8/ The original change: http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.02/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/331b38ef0db3 I can push this myself, because it's ppc port only. But where do I need to push it to get it into 8u60? jdk8u/hs-dev/hotspot? Thanks and best regards, Goetz. From serguei.spitsyn at oracle.com Wed Apr 29 09:48:43 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Apr 2015 02:48:43 -0700 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception In-Reply-To: <553EA65B.6080805@oracle.com> References: <553EA65B.6080805@oracle.com> Message-ID: <5540A8FB.4010101@oracle.com> Ping... Just wanted to tell that it is a very safe and simple one-liner so that I assumed it to be reviewed in a couple of days, not weeks! :) Thanks! Serguei On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8076579 > > > 9 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 > > > > Summary: > > This bug is a regression that was introduced but the fix of: > https://bugs.openjdk.java.net/browse/JDK-7187554 > > The bug is in the InterpreterRuntime::member_name_arg_or_null() > function that > does not return NULL if there is no invokestatic appendix argument > (MemberName). > It is why the _remove_activation_preserving_args is trying to to > restore unexisting > appendix argument when a pop instruction is executed by a debugger > in the debuggee VM. > The fix is to correctly set NULL in the thread vm_result when it is > necessary: > thread->set_vm_result(NULL); > > > Testing in progress: > In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests, > JTREG com/sun/jdi tests, > ad-hog ExceptionBug.java test from the bug report > > > Thanks, > Serguei From michael.haupt at oracle.com Wed Apr 29 10:41:51 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 29 Apr 2015 12:41:51 +0200 Subject: RFR (XS): 8030680: 292 cleanup from default method code assessment In-Reply-To: <9B62CB5C-FC50-4F1B-A621-B6D92E59587A@oracle.com> References: <47514E27-2AD4-497C-91A1-56704D9CEF2C@oracle.com> <4D282D36-0F73-4562-B986-6A344C68A5A3@oracle.com> <9B62CB5C-FC50-4F1B-A621-B6D92E59587A@oracle.com> Message-ID: <165C8D18-4950-47B2-B4A1-8B2B6FFE2BFA@oracle.com> Hi Karen, the new webrev is at http://cr.openjdk.java.net/~mhaupt/8030680/webrev.01 - all changes applied as discussed below. Tested with: * jtreg (java.lang.invoke, java.util.stream); * vm.quick.testlist, vm.defmeth.testlist; * JPRT (HotSpot testset). Best, Michael > Am 28.04.2015 um 16:46 schrieb Karen Kinnear : > > Michael, > > I am good with all of your responses. Thanks for the updates and additional testing. > > many thanks, > Karen > > On Apr 27, 2015, at 11:08 AM, Michael Haupt wrote: > >> Hi Karen, >> >> thank you very much for your comments. My responses are below. >> >>> Am 23.04.2015 um 22:08 schrieb Karen Kinnear : >>> 1. In klassVtable::method_count_for_interface: >>> A couple of optional suggestions while you are cleaning this up: >>> >>> If length were initialized to 0, we would not need to have two different return locations. >>> If the ASSERT was right before the return, i.e. not in the if (m->has_itable_index(), >>> we would be checking the return value for all cases and it might be more future proof >>> if someone were to extend the logic. >> >> That's a good suggestion; thanks. I've refactored the method to have one return statement only, and moved the ASSERT block to just before that. >> >>> Not sure if we would need the local copy, i.e. nof_methods_copy - but I do >>> appreciate that as also future proofing. >> >> It's more defensive now - I don't think debugging code should change local state, even if that's directly before a return. >> >>> 2. init_method_MemberName >>> I would be much more comfortable with conditional if (m.not_null() rather >>> than assert - which only does something in debug mode. >> >> All of the checks of this sort in this method use assert() - and there are many places throughout the file (and other files) that use assert() in similar cases as well. If this should be changed to if-plus-raise-error, then that should be the case for all other similar uses of assert(), or the two that were introduced in the change are somehow special. Is this the case? > I guess the assumption is that we have generated this code internally and so this should not cause a problem. >> >>> 3. A favor - while you are in klassVtable.cpp ? >>> Harold and I were reading the tracing information looking at a different bug today >>> and realized some of the tracing is misleading. >>> >>> 3A: In assign_itable_indices_for_interface it says >>> "Initializing itable for interface" >>> change to >>> "Initializing itable indices for interface" >>> >>> If you read the comments closely, an interface does not actually have an itable, but >>> its methods need to have either a vtable index or an itable index. This code here >>> assigns itable indices to methods that do not already have a vtable index (from j.l.Object) >>> >>> 3B: >>> assign_itable_indices_for_interface >>> if (m->has_vtable_index) ... "itable index %d for method ..." >>> could you possibly change that to "vtable index %d for method" >>> >>> that would help people be less confused debugging this. >> >> Both applied. >> >>> 4. Testing >>> Thank you for the testing you already did. >>> ... >>> For this particular change I would ask that in addition to what you already ran >>> you run (with a fastdebug build): - Christian Tornqvist can tell you how to run them >>> vm.quick.testlist >>> default methods tests (default mode and -mode invoke) >>> jtreg java/util/streams (our favorite default method shakers) >> >> Thanks for the heads-up about testing for rt changes. I've applied the changes as described above and am now working on the testing. Will upload a revised webrev once that's successful. >> >> Best, >> >> Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From edward.nevill at linaro.org Wed Apr 29 10:52:30 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 29 Apr 2015 11:52:30 +0100 Subject: aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <5539EC8E.1060507@oracle.com> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> Message-ID: <1430304750.8394.56.camel@mylittlepony.linaroharston> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote: > Hi Ed, > > On 21/04/2015 7:16 PM, Edward Nevill wrote: > > Hi, > > > > The current jdk9 tip fails to build from source on aarch64 with the following error message > > > > /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': > > /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' > > collect2: error: ld returned 1 exit status > > > > The following webrev gets it building again. > > > > http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ > > Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm > also wondering how we would get __ARM_NEON defined but not __arm__? On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds. On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is. However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again. A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64). The failing code in pngpriv.h reads #ifndef PNG_ARM_NEON_OPT ... # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ defined(PNG_ALIGNED_MEMORY_SUPPORTED) # define PNG_ARM_NEON_OPT 2 # else # define PNG_ARM_NEON_OPT 0 # endif #endif So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above. The following patch webrev does this:- http://cr.openjdk.java.net/~enevill/8078245/webrev.01/ If you are happy with this and if I could have another reviewer I will push this. All the best, Ed. From david.holmes at oracle.com Wed Apr 29 11:23:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Apr 2015 21:23:00 +1000 Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package In-Reply-To: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> References: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> Message-ID: <5540BF14.1070606@oracle.com> On 28/04/2015 11:09 PM, Alexander Kulyakhtin wrote: > Hi, > > I've updated the webrev in accordance with David's comments. > > Could you, please, review the changes: > >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html Looks good. Aside: test/compiler/c2/8005956/PolynomialRoot.java doesn't have an OpenJDK copyright header. (Added by JDK-8017510) Thanks, David > Best regards, > Alex > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi David, > > Thank you very much for your comments. > >> I presume this is a first step towards fixing: >> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > Yes, this is correct > >> Did you use "hg rename" for that? The webrev suggests not as it shows > No, I used hg add and hg delete. > I'm going to fix this now by doing hg rename > >> Copyright dates will need updating in many cases. > I'm going to update the copyrights > > I'll send out the updated webrev as soon as I'm done. > > Best regards, > Alex > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi Alex, > > On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could I, please, have a review of this tests-only change: >> >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html >> >> The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > > > >> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, > > deleted and added files rather than moved ones. > >> Everywhere in the hotspot/test files import statements have been changed as needed. > > Seems okay based on scanning through the patch. > > Copyright dates will need updating in many cases. > > Thanks, > David > >> Best regards, >> Alex >> >> >> From alexander.kulyakhtin at oracle.com Wed Apr 29 11:38:22 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 29 Apr 2015 04:38:22 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: <9fdd6c47-776d-4d04-89b4-a74d05a8337f@default> David, Thank you very much for your approval. I've created https://bugs.openjdk.java.net/browse/JDK-8078962 to add the missing copyright to the said file and will fix it today. Best regards, Alexander ----- Original Message ----- From: david.holmes at oracle.com To: alexander.kulyakhtin at oracle.com, hotspot-dev at openjdk.java.net Cc: serviceability-dev at openjdk.java.net Sent: Wednesday, April 29, 2015 2:23:00 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package On 28/04/2015 11:09 PM, Alexander Kulyakhtin wrote: > Hi, > > I've updated the webrev in accordance with David's comments. > > Could you, please, review the changes: > >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html Looks good. Aside: test/compiler/c2/8005956/PolynomialRoot.java doesn't have an OpenJDK copyright header. (Added by JDK-8017510) Thanks, David > Best regards, > Alex > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi David, > > Thank you very much for your comments. > >> I presume this is a first step towards fixing: >> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > Yes, this is correct > >> Did you use "hg rename" for that? The webrev suggests not as it shows > No, I used hg add and hg delete. > I'm going to fix this now by doing hg rename > >> Copyright dates will need updating in many cases. > I'm going to update the copyrights > > I'll send out the updated webrev as soon as I'm done. > > Best regards, > Alex > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi Alex, > > On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could I, please, have a review of this tests-only change: >> >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html >> >> The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > > > >> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, > > deleted and added files rather than moved ones. > >> Everywhere in the hotspot/test files import statements have been changed as needed. > > Seems okay based on scanning through the patch. > > Copyright dates will need updating in many cases. > > Thanks, > David > >> Best regards, >> Alex >> >> >> From per.liden at oracle.com Wed Apr 29 12:00:12 2015 From: per.liden at oracle.com (Per Liden) Date: Wed, 29 Apr 2015 14:00:12 +0200 Subject: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index In-Reply-To: References: <5538B2C5.3040404@oracle.com> <1429787817.3334.3.camel@oracle.com> Message-ID: <5540C7CC.2080209@oracle.com> Hi, On 2015-04-27 18:20, Christian Thalinger wrote: > >> On Apr 23, 2015, at 9:40 AM, Per Liden wrote: >> >> Hi Thomas, >> >>> On 23 Apr 2015, at 13:16, Thomas Schatzl wrote: >>> >>> Hi, >>> >>> On Thu, 2015-04-23 at 10:52 +0200, Per Liden wrote: >>>> Hi, >>>> >>>> (This change affects G1, but it's touching code in C1 so I'd like to ask >>>> someone from the compiler team to also reviewed this) >>>> >>>> Summary: The G1 barriers loads and updates the PrtQueue::_index field. >>>> This field is a size_t but the C1 version of these barriers aren't >>>> 64-bit clean. The bug has more details. >>>> >>>> In addition I've massaged the code a little bit, so that the 32-bit and >>>> 64-bit sections look more similar (and as a bonus I think we avoid an >>>> extra memory load on 32-bit). >>>> >>>> Webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.0/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8013171 >>>> >>>> Testing: >>>> * gc-test-suite on both 32 and 64-bit builds (with -XX:+UseG1GC >>>> -XX:+TieredCompilation -XX:TieredStopAtLevel=3 -XX:+VerifyAfterGC) >>>> * Passes jprt >>> >>> Looks good, with the following caveats which should be decided by >>> somebody else if they are important as they are micro-opts: >>> >>> - instead of using cmp to compare against zero in a register, it would >>> be better to use the test instruction (e.g. __ testX(tmp, tmp)) as it saves >>> a byte of encoding per instruction with the same effect. > > Tighter code is always better. For barriers it might be important in tight loops to better fit in the cache. I'll make it a testprt(). > >>> >>> - post barrier stub: I would prefer if the 64 bit code did not >>> push/pop the rdx register to free tmp. There are explicit rscratch1/2 >>> registers for temporaries available on that platform. At least rscratch1 >>> (=r8) seems to be used without save/restore in the original code already. >>> This would also remove the need for 64 bit code to push/pop any register it >>> seems to me. > > Sounds like a good suggestion if it doesn?t complicate the code too much. I'd like to avoid reintroducing different code paths for 32 and 64-bit, which I think complicates the code. However, I can defer the pushing of tmp until it's actually needed, which essentially gets us to the same situation as before this change in terms of register usage for 64-bit. Updated webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.2/ cheers, /Per From coleen.phillimore at oracle.com Wed Apr 29 12:32:37 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Apr 2015 08:32:37 -0400 Subject: RFR (XS): 8030680: 292 cleanup from default method code assessment In-Reply-To: <165C8D18-4950-47B2-B4A1-8B2B6FFE2BFA@oracle.com> References: <47514E27-2AD4-497C-91A1-56704D9CEF2C@oracle.com> <4D282D36-0F73-4562-B986-6A344C68A5A3@oracle.com> <9B62CB5C-FC50-4F1B-A621-B6D92E59587A@oracle.com> <165C8D18-4950-47B2-B4A1-8B2B6FFE2BFA@oracle.com> Message-ID: <5540CF65.3020505@oracle.com> I didn't really review this but shouldn't there be a ResourceMark in the first TraceItables? and it would be better on more than one line with {}s. http://cr.openjdk.java.net/~mhaupt/8030680/webrev.01/src/share/vm/oops/klassVtable.cpp.udiff.html thanks, Coleen On 4/29/15, 6:41 AM, Michael Haupt wrote: > Hi Karen, > > the new webrev is at http://cr.openjdk.java.net/~mhaupt/8030680/webrev.01 - all changes applied as discussed below. > > Tested with: > * jtreg (java.lang.invoke, java.util.stream); > * vm.quick.testlist, vm.defmeth.testlist; > * JPRT (HotSpot testset). > > Best, > > Michael > >> Am 28.04.2015 um 16:46 schrieb Karen Kinnear : >> >> Michael, >> >> I am good with all of your responses. Thanks for the updates and additional testing. >> >> many thanks, >> Karen >> >> On Apr 27, 2015, at 11:08 AM, Michael Haupt wrote: >> >>> Hi Karen, >>> >>> thank you very much for your comments. My responses are below. >>> >>>> Am 23.04.2015 um 22:08 schrieb Karen Kinnear : >>>> 1. In klassVtable::method_count_for_interface: >>>> A couple of optional suggestions while you are cleaning this up: >>>> >>>> If length were initialized to 0, we would not need to have two different return locations. >>>> If the ASSERT was right before the return, i.e. not in the if (m->has_itable_index(), >>>> we would be checking the return value for all cases and it might be more future proof >>>> if someone were to extend the logic. >>> That's a good suggestion; thanks. I've refactored the method to have one return statement only, and moved the ASSERT block to just before that. >>> >>>> Not sure if we would need the local copy, i.e. nof_methods_copy - but I do >>>> appreciate that as also future proofing. >>> It's more defensive now - I don't think debugging code should change local state, even if that's directly before a return. >>> >>>> 2. init_method_MemberName >>>> I would be much more comfortable with conditional if (m.not_null() rather >>>> than assert - which only does something in debug mode. >>> All of the checks of this sort in this method use assert() - and there are many places throughout the file (and other files) that use assert() in similar cases as well. If this should be changed to if-plus-raise-error, then that should be the case for all other similar uses of assert(), or the two that were introduced in the change are somehow special. Is this the case? >> I guess the assumption is that we have generated this code internally and so this should not cause a problem. >>>> 3. A favor - while you are in klassVtable.cpp ? >>>> Harold and I were reading the tracing information looking at a different bug today >>>> and realized some of the tracing is misleading. >>>> >>>> 3A: In assign_itable_indices_for_interface it says >>>> "Initializing itable for interface" >>>> change to >>>> "Initializing itable indices for interface" >>>> >>>> If you read the comments closely, an interface does not actually have an itable, but >>>> its methods need to have either a vtable index or an itable index. This code here >>>> assigns itable indices to methods that do not already have a vtable index (from j.l.Object) >>>> >>>> 3B: >>>> assign_itable_indices_for_interface >>>> if (m->has_vtable_index) ... "itable index %d for method ..." >>>> could you possibly change that to "vtable index %d for method" >>>> >>>> that would help people be less confused debugging this. >>> Both applied. >>> >>>> 4. Testing >>>> Thank you for the testing you already did. >>>> ... >>>> For this particular change I would ask that in addition to what you already ran >>>> you run (with a fastdebug build): - Christian Tornqvist can tell you how to run them >>>> vm.quick.testlist >>>> default methods tests (default mode and -mode invoke) >>>> jtreg java/util/streams (our favorite default method shakers) >>> Thanks for the heads-up about testing for rt changes. I've applied the changes as described above and am now working on the testing. Will upload a revised webrev once that's successful. >>> >>> Best, >>> >>> Michael > From coleen.phillimore at oracle.com Wed Apr 29 12:44:34 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Apr 2015 08:44:34 -0400 Subject: RFR (XS): 8030680: 292 cleanup from default method code assessment In-Reply-To: <5540CF65.3020505@oracle.com> References: <47514E27-2AD4-497C-91A1-56704D9CEF2C@oracle.com> <4D282D36-0F73-4562-B986-6A344C68A5A3@oracle.com> <9B62CB5C-FC50-4F1B-A621-B6D92E59587A@oracle.com> <165C8D18-4950-47B2-B4A1-8B2B6FFE2BFA@oracle.com> <5540CF65.3020505@oracle.com> Message-ID: <5540D232.5000902@oracle.com> Sorry, I realized you need another reviewer so I looked more closely. This looks fine to me. Coleen On 4/29/15, 8:32 AM, Coleen Phillimore wrote: > > I didn't really review this but shouldn't there be a ResourceMark in > the first TraceItables? and it would be better on more than one line > with {}s. > > http://cr.openjdk.java.net/~mhaupt/8030680/webrev.01/src/share/vm/oops/klassVtable.cpp.udiff.html > > > thanks, > Coleen > > On 4/29/15, 6:41 AM, Michael Haupt wrote: >> Hi Karen, >> >> the new webrev is at >> http://cr.openjdk.java.net/~mhaupt/8030680/webrev.01 - all changes >> applied as discussed below. >> >> Tested with: >> * jtreg (java.lang.invoke, java.util.stream); >> * vm.quick.testlist, vm.defmeth.testlist; >> * JPRT (HotSpot testset). >> >> Best, >> >> Michael >> >>> Am 28.04.2015 um 16:46 schrieb Karen Kinnear >>> : >>> >>> Michael, >>> >>> I am good with all of your responses. Thanks for the updates and >>> additional testing. >>> >>> many thanks, >>> Karen >>> >>> On Apr 27, 2015, at 11:08 AM, Michael Haupt wrote: >>> >>>> Hi Karen, >>>> >>>> thank you very much for your comments. My responses are below. >>>> >>>>> Am 23.04.2015 um 22:08 schrieb Karen Kinnear >>>>> : >>>>> 1. In klassVtable::method_count_for_interface: >>>>> A couple of optional suggestions while you are cleaning this up: >>>>> >>>>> If length were initialized to 0, we would not need to have two >>>>> different return locations. >>>>> If the ASSERT was right before the return, i.e. not in the if >>>>> (m->has_itable_index(), >>>>> we would be checking the return value for all cases and it might >>>>> be more future proof >>>>> if someone were to extend the logic. >>>> That's a good suggestion; thanks. I've refactored the method to >>>> have one return statement only, and moved the ASSERT block to just >>>> before that. >>>> >>>>> Not sure if we would need the local copy, i.e. nof_methods_copy - >>>>> but I do >>>>> appreciate that as also future proofing. >>>> It's more defensive now - I don't think debugging code should >>>> change local state, even if that's directly before a return. >>>> >>>>> 2. init_method_MemberName >>>>> I would be much more comfortable with conditional if (m.not_null() >>>>> rather >>>>> than assert - which only does something in debug mode. >>>> All of the checks of this sort in this method use assert() - and >>>> there are many places throughout the file (and other files) that >>>> use assert() in similar cases as well. If this should be changed to >>>> if-plus-raise-error, then that should be the case for all other >>>> similar uses of assert(), or the two that were introduced in the >>>> change are somehow special. Is this the case? >>> I guess the assumption is that we have generated this code >>> internally and so this should not cause a problem. >>>>> 3. A favor - while you are in klassVtable.cpp ? >>>>> Harold and I were reading the tracing information looking at a >>>>> different bug today >>>>> and realized some of the tracing is misleading. >>>>> >>>>> 3A: In assign_itable_indices_for_interface it says >>>>> "Initializing itable for interface" >>>>> change to >>>>> "Initializing itable indices for interface" >>>>> >>>>> If you read the comments closely, an interface does not actually >>>>> have an itable, but >>>>> its methods need to have either a vtable index or an itable index. >>>>> This code here >>>>> assigns itable indices to methods that do not already have a >>>>> vtable index (from j.l.Object) >>>>> >>>>> 3B: >>>>> assign_itable_indices_for_interface >>>>> if (m->has_vtable_index) ... "itable index %d for method ..." >>>>> could you possibly change that to "vtable index %d for method" >>>>> >>>>> that would help people be less confused debugging this. >>>> Both applied. >>>> >>>>> 4. Testing >>>>> Thank you for the testing you already did. >>>>> ... >>>>> For this particular change I would ask that in addition to what >>>>> you already ran >>>>> you run (with a fastdebug build): - Christian Tornqvist can tell >>>>> you how to run them >>>>> vm.quick.testlist >>>>> default methods tests (default mode and -mode invoke) >>>>> jtreg java/util/streams (our favorite default method shakers) >>>> Thanks for the heads-up about testing for rt changes. I've applied >>>> the changes as described above and am now working on the testing. >>>> Will upload a revised webrev once that's successful. >>>> >>>> Best, >>>> >>>> Michael >> > From filipp.zhinkin at gmail.com Wed Apr 29 13:01:06 2015 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Wed, 29 Apr 2015 16:01:06 +0300 Subject: [8u60] Request for approval: backport of JDK-8050486 In-Reply-To: <553F8BE9.7090004@oracle.com> References: <553F8BE9.7090004@oracle.com> Message-ID: Hi Boris, you have to backport JDK-8068272 [1] first, because this (JDK-8050486) fix relies on it. Regards, Filipp. [1] https://bugs.openjdk.java.net/browse/JDK-8068272 On Tue, Apr 28, 2015 at 4:32 PM, Boris Molodenkov wrote: > Hi All, > > I would like to backport fix for JDK-8050486 to 8u60. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 > Webrev: http://cr.openjdk.java.net/~bmoloden/8050486/webrev.00/ > Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2f8520599d39 > Review thread for original fix: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016754.html > > testing: manual with jtreg > > Thanks, > Boris > From coleen.phillimore at oracle.com Wed Apr 29 13:01:19 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Apr 2015 09:01:19 -0400 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception In-Reply-To: <5540A8FB.4010101@oracle.com> References: <553EA65B.6080805@oracle.com> <5540A8FB.4010101@oracle.com> Message-ID: <5540D61F.6010100@oracle.com> Serguei, The bug says JSR292 and PopFrame! I think we are all scared of it. The fix looks good. Nit: I would have coded it in an 'else' statement instead. I did check that this is the only interpreter runtime function without all paths setting vm_result. You are going to have to get someone from the compiler team who knows JSR292 to also review it. thanks, Coleen On 4/29/15, 5:48 AM, serguei.spitsyn at oracle.com wrote: > Ping... > Just wanted to tell that it is a very safe and simple one-liner so that > I assumed it to be reviewed in a couple of days, not weeks! :) > > Thanks! > Serguei > > On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8076579 >> >> >> 9 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 >> >> >> >> Summary: >> >> This bug is a regression that was introduced but the fix of: >> https://bugs.openjdk.java.net/browse/JDK-7187554 >> >> The bug is in the InterpreterRuntime::member_name_arg_or_null() >> function that >> does not return NULL if there is no invokestatic appendix argument >> (MemberName). >> It is why the _remove_activation_preserving_args is trying to to >> restore unexisting >> appendix argument when a pop instruction is executed by a debugger >> in the debuggee VM. >> The fix is to correctly set NULL in the thread vm_result when it is >> necessary: >> thread->set_vm_result(NULL); >> >> >> Testing in progress: >> In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame >> tests, JTREG com/sun/jdi tests, >> ad-hog ExceptionBug.java test from the bug report >> >> >> Thanks, >> Serguei > From stefan.johansson at oracle.com Wed Apr 29 13:03:05 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 29 Apr 2015 15:03:05 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> Message-ID: <5540D689.6020407@oracle.com> Hi Kirk, A lot of effort is put into G1, it has been continuously improving over the last couple of years and we now believe that G1 is ready to become the default. G1 will not improve all use case, but the same is true for the other collectors. For users where throughput is the main concern, Parallel GC can still be used by specifying -XX:+UseParallelGC on the command-line. Regards, Stefan On 2015-04-29 09:10, Kirk Pepperdine wrote: > Hi all, > > Is the G1 ready for this? I see many people moving to G1 but also I?m not sure that we?ve got the tunable correct. I?ve been sorting through a number of recent tuning engagements and my conclusion is that I would like the collector to be aggressive about collecting tenured regions at the beginning of a JVM?s life time but then become less aggressive over time. The reason is the residual waste that I see left behind because certain regions never hit the threshold needed to be included in the CSET. But, on aggregate, the number of regions in this state does start to retain a significant about of dead data. The only way to see the effects is to run regular Full GCs.. which of course you don?t really want to do. However, the problem seems to settle down a wee bit over time which is why I was thinking that being aggressive about what is collected in the early stages of a JVMs life should lead to better packing and hence less waste. > > Note, I don?t really care about the memory waste, only it?s effect on cycle frequencies and pause times. > > Sorry but I don?t have anything formal about this as I (and I believe many others) are still sorting out what to make of the G1 in prod. Generally the overall results are good but sometimes it?s not that way up front and how to improve things is sometimes challenging. > > On a side note, the move to Tiered in 8 has also caused a bit of grief. Metaspace has caused a bit of grief and even parallelStream, which works, has come with some interesting side effect. Everyone has been so enamored with Lambdas (rightfully so) that the other stuff has been completely forgotten and some of it has surprised people. I guess I?ll be submitting a talk for J1 on some of the field experience I?ve had with the other stuff. > > Regards, > Kirk > > > On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: > >> New JEP Candidate: http://openjdk.java.net/jeps/248 >> >> - Mark From boris.molodenkov at oracle.com Wed Apr 29 13:57:32 2015 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Wed, 29 Apr 2015 16:57:32 +0300 Subject: [8u60] Request for approval: backport of JDK-8050486 In-Reply-To: References: <553F8BE9.7090004@oracle.com> Message-ID: <5540E34C.8060308@oracle.com> Hi Filipp, Thank you! I'll do it. On 04/29/2015 04:01 PM, Filipp Zhinkin wrote: > Hi Boris, > > you have to backport JDK-8068272 [1] first, because this (JDK-8050486) > fix relies on it. > > Regards, > Filipp. > > [1] https://bugs.openjdk.java.net/browse/JDK-8068272 > > On Tue, Apr 28, 2015 at 4:32 PM, Boris Molodenkov > wrote: >> Hi All, >> >> I would like to backport fix for JDK-8050486 to 8u60. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 >> Webrev: http://cr.openjdk.java.net/~bmoloden/8050486/webrev.00/ >> Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2f8520599d39 >> Review thread for original fix: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016754.html >> >> testing: manual with jtreg >> >> Thanks, >> Boris >> From serguei.spitsyn at oracle.com Wed Apr 29 14:25:00 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Apr 2015 07:25:00 -0700 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception In-Reply-To: <5540D61F.6010100@oracle.com> References: <553EA65B.6080805@oracle.com> <5540A8FB.4010101@oracle.com> <5540D61F.6010100@oracle.com> Message-ID: <5540E9BC.8000707@oracle.com> Coleen, Thank you a lot for review! On 4/29/15 6:01 AM, Coleen Phillimore wrote: > > Serguei, > > The bug says JSR292 and PopFrame! I think we are all scared of it. That is true. I know about it. :) > > The fix looks good. Nit: I would have coded it in an 'else' statement > instead. Selected this way of fix to make it a one-liner to be easier for reviewers! :) I really do not have any personal preference. > I did check that this is the only interpreter runtime function without > all paths setting vm_result. I admit, this was my mistake in the first place. > > You are going to have to get someone from the compiler team who knows > JSR292 to also review it. Sure. My plan was to ask Christian T. to take a brief look. Thanks, Serguei > > thanks, > Coleen > > On 4/29/15, 5:48 AM, serguei.spitsyn at oracle.com wrote: >> Ping... >> Just wanted to tell that it is a very safe and simple one-liner so that >> I assumed it to be reviewed in a couple of days, not weeks! :) >> >> Thanks! >> Serguei >> >> On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 9 fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8076579 >>> >>> >>> 9 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 >>> >>> >>> >>> Summary: >>> >>> This bug is a regression that was introduced but the fix of: >>> https://bugs.openjdk.java.net/browse/JDK-7187554 >>> >>> The bug is in the InterpreterRuntime::member_name_arg_or_null() >>> function that >>> does not return NULL if there is no invokestatic appendix argument >>> (MemberName). >>> It is why the _remove_activation_preserving_args is trying to to >>> restore unexisting >>> appendix argument when a pop instruction is executed by a debugger >>> in the debuggee VM. >>> The fix is to correctly set NULL in the thread vm_result when it >>> is necessary: >>> thread->set_vm_result(NULL); >>> >>> >>> Testing in progress: >>> In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame >>> tests, JTREG com/sun/jdi tests, >>> ad-hog ExceptionBug.java test from the bug report >>> >>> >>> Thanks, >>> Serguei >> > From boris.molodenkov at oracle.com Wed Apr 29 15:41:29 2015 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Wed, 29 Apr 2015 18:41:29 +0300 Subject: [8u60] Request for approval: backport of JDK-8068272 Message-ID: <5540FBA9.6060606@oracle.com> Hi All, I would like to backport fix for JDK-8068272 to 8u60. Bug id: https://bugs.openjdk.java.net/browse/JDK-8068272 Webrev: http://cr.openjdk.java.net/~bmoloden/8068272/webrev.00/ Changesets: http://hg.openjdk.java.net/jdk9/jdk9/rev/a09f9fd80f87 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2025390834c6 Review thread for original fix: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016751.html testing: jprt Thanks, Boris From michael.haupt at oracle.com Wed Apr 29 15:43:58 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 29 Apr 2015 17:43:58 +0200 Subject: RFR (XS): 8030680: 292 cleanup from default method code assessment In-Reply-To: <5540D232.5000902@oracle.com> References: <47514E27-2AD4-497C-91A1-56704D9CEF2C@oracle.com> <4D282D36-0F73-4562-B986-6A344C68A5A3@oracle.com> <9B62CB5C-FC50-4F1B-A621-B6D92E59587A@oracle.com> <165C8D18-4950-47B2-B4A1-8B2B6FFE2BFA@oracle.com> <5540CF65.3020505@oracle.com> <5540D232.5000902@oracle.com> Message-ID: <5F67D941-74B0-476C-890F-4F948712401C@oracle.com> Hi Coleen, thank you. Best, Michael > Am 29.04.2015 um 14:44 schrieb Coleen Phillimore : > > > Sorry, I realized you need another reviewer so I looked more closely. This looks fine to me. > Coleen -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From boris.molodenkov at oracle.com Wed Apr 29 15:44:14 2015 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Wed, 29 Apr 2015 18:44:14 +0300 Subject: [8u60] Request for approval: backport of JDK-8050486 In-Reply-To: <553FD69E.1040202@oracle.com> References: <553F8BE9.7090004@oracle.com> <553FD69E.1040202@oracle.com> Message-ID: <5540FC4E.4000707@oracle.com> On 04/28/2015 09:51 PM, Vladimir Kozlov wrote: > Good. Was there other changes in RTMTestBase.java which were not > backported? Changes are different in that file from jdk9 (but the > resulting flags are the same). There are not other changes in RTMTestBase.java. Changes are different because initial versions of RTMTestBase.java in jdk9 and jdk8 slightly differ. Thanks, Boris > > Thanks, > Vladimir > > On 4/28/15 6:32 AM, Boris Molodenkov wrote: >> Hi All, >> >> I would like to backport fix for JDK-8050486 to 8u60. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 >> Webrev: http://cr.openjdk.java.net/~bmoloden/8050486/webrev.00/ >> Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2f8520599d39 >> Review thread for original fix: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016754.html >> >> >> testing: manual with jtreg >> >> Thanks, >> Boris >> From christian.thalinger at oracle.com Wed Apr 29 16:42:11 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 29 Apr 2015 09:42:11 -0700 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception In-Reply-To: <5540E9BC.8000707@oracle.com> References: <553EA65B.6080805@oracle.com> <5540A8FB.4010101@oracle.com> <5540D61F.6010100@oracle.com> <5540E9BC.8000707@oracle.com> Message-ID: > On Apr 29, 2015, at 7:25 AM, serguei.spitsyn at oracle.com wrote: > > Coleen, > > Thank you a lot for review! > > > On 4/29/15 6:01 AM, Coleen Phillimore wrote: >> >> Serguei, >> >> The bug says JSR292 and PopFrame! I think we are all scared of it. > > That is true. I know about it. :) > >> >> The fix looks good. Nit: I would have coded it in an 'else' statement instead. > > Selected this way of fix to make it a one-liner to be easier for reviewers! :) > I really do not have any personal preference. The fix looks good and I also would like to see an else. > >> I did check that this is the only interpreter runtime function without all paths setting vm_result. > > I admit, this was my mistake in the first place. > >> >> You are going to have to get someone from the compiler team who knows JSR292 to also review it. > > Sure. > My plan was to ask Christian T. to take a brief look. > > Thanks, > Serguei > >> >> thanks, >> Coleen >> >> On 4/29/15, 5:48 AM, serguei.spitsyn at oracle.com wrote: >>> Ping... >>> Just wanted to tell that it is a very safe and simple one-liner so that >>> I assumed it to be reviewed in a couple of days, not weeks! :) >>> >>> Thanks! >>> Serguei >>> >>> On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the jdk 9 fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8076579 >>>> >>>> >>>> 9 hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 >>>> >>>> >>>> Summary: >>>> >>>> This bug is a regression that was introduced but the fix of: >>>> https://bugs.openjdk.java.net/browse/JDK-7187554 >>>> >>>> The bug is in the InterpreterRuntime::member_name_arg_or_null() function that >>>> does not return NULL if there is no invokestatic appendix argument (MemberName). >>>> It is why the _remove_activation_preserving_args is trying to to restore unexisting >>>> appendix argument when a pop instruction is executed by a debugger in the debuggee VM. >>>> The fix is to correctly set NULL in the thread vm_result when it is necessary: >>>> thread->set_vm_result(NULL); >>>> >>>> >>>> Testing in progress: >>>> In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests, JTREG com/sun/jdi tests, >>>> ad-hog ExceptionBug.java test from the bug report >>>> >>>> >>>> Thanks, >>>> Serguei >>> >> > From vladimir.kozlov at oracle.com Wed Apr 29 16:48:58 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Apr 2015 09:48:58 -0700 Subject: [8u60] Request for approval: backport of JDK-8050486 In-Reply-To: <5540FC4E.4000707@oracle.com> References: <553F8BE9.7090004@oracle.com> <553FD69E.1040202@oracle.com> <5540FC4E.4000707@oracle.com> Message-ID: <55410B7A.4020308@oracle.com> Okay. Thank you for explaining the difference. Vladimir On 4/29/15 8:44 AM, Boris Molodenkov wrote: > On 04/28/2015 09:51 PM, Vladimir Kozlov wrote: >> Good. Was there other changes in RTMTestBase.java which were not backported? Changes are different in that file from >> jdk9 (but the resulting flags are the same). > There are not other changes in RTMTestBase.java. Changes are different because initial versions of RTMTestBase.java in > jdk9 and jdk8 slightly differ. > > Thanks, > Boris >> >> Thanks, >> Vladimir >> >> On 4/28/15 6:32 AM, Boris Molodenkov wrote: >>> Hi All, >>> >>> I would like to backport fix for JDK-8050486 to 8u60. >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 >>> Webrev: http://cr.openjdk.java.net/~bmoloden/8050486/webrev.00/ >>> Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2f8520599d39 >>> Review thread for original fix: >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016754.html >>> >>> testing: manual with jtreg >>> >>> Thanks, >>> Boris >>> > From thomas.stuefe at gmail.com Wed Apr 29 19:00:57 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 29 Apr 2015 21:00:57 +0200 Subject: RFR(xs): 8078628: linux-zero does not build without precompiled header In-Reply-To: References: Message-ID: Hi, I still need a second reviewer and a sponsor. Thanks, Thomas On Friday, April 24, 2015, Thomas St?fe wrote: > Hi all, > > please review this tiny change. Build was broken for zero/slowdebug when > building without precompiled header. > > bug: https://bugs.openjdk.java.net/browse/JDK-8078628 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.00/webrev/ > > > Thank you, > > Thomas > From boris.molodenkov at oracle.com Wed Apr 29 19:24:36 2015 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Wed, 29 Apr 2015 22:24:36 +0300 Subject: [8u60] Request for approval: backport of JDK-8068272 In-Reply-To: <55410B55.4000708@oracle.com> References: <5540FBA9.6060606@oracle.com> <55410B55.4000708@oracle.com> Message-ID: <55412FF4.8020305@oracle.com> On 04/29/2015 07:48 PM, Vladimir Kozlov wrote: > Looks fine. But don't forget to push jdk changes - you did not pointed > webrev for it. Does jdk8u need it? Whitebox.java was not moved to root repository for jdk8. So all changes are located in hotspot. Thank you for review! Boris > > Thanks, > Vladimir > > On 4/29/15 8:41 AM, Boris Molodenkov wrote: >> Hi All, >> >> I would like to backport fix for JDK-8068272 to 8u60. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8068272 >> Webrev: http://cr.openjdk.java.net/~bmoloden/8068272/webrev.00/ >> Changesets: >> http://hg.openjdk.java.net/jdk9/jdk9/rev/a09f9fd80f87 >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2025390834c6 >> Review thread for original fix: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016751.html >> >> >> testing: jprt >> >> Thanks, >> Boris >> From boris.molodenkov at oracle.com Wed Apr 29 19:25:48 2015 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Wed, 29 Apr 2015 22:25:48 +0300 Subject: [8u60] Request for approval: backport of JDK-8050486 In-Reply-To: <55410B7A.4020308@oracle.com> References: <553F8BE9.7090004@oracle.com> <553FD69E.1040202@oracle.com> <5540FC4E.4000707@oracle.com> <55410B7A.4020308@oracle.com> Message-ID: <5541303C.1030603@oracle.com> Thank you for review! Boris On 04/29/2015 07:48 PM, Vladimir Kozlov wrote: > Okay. Thank you for explaining the difference. > > Vladimir > > On 4/29/15 8:44 AM, Boris Molodenkov wrote: >> On 04/28/2015 09:51 PM, Vladimir Kozlov wrote: >>> Good. Was there other changes in RTMTestBase.java which were not >>> backported? Changes are different in that file from >>> jdk9 (but the resulting flags are the same). >> There are not other changes in RTMTestBase.java. Changes are >> different because initial versions of RTMTestBase.java in >> jdk9 and jdk8 slightly differ. >> >> Thanks, >> Boris >>> >>> Thanks, >>> Vladimir >>> >>> On 4/28/15 6:32 AM, Boris Molodenkov wrote: >>>> Hi All, >>>> >>>> I would like to backport fix for JDK-8050486 to 8u60. >>>> >>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 >>>> Webrev: http://cr.openjdk.java.net/~bmoloden/8050486/webrev.00/ >>>> Changeset: >>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2f8520599d39 >>>> Review thread for original fix: >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016754.html >>>> >>>> >>>> testing: manual with jtreg >>>> >>>> Thanks, >>>> Boris >>>> >> From boris.molodenkov at oracle.com Wed Apr 29 19:26:25 2015 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Wed, 29 Apr 2015 22:26:25 +0300 Subject: [8u60] Request for approval: backport of JDK-8058846 In-Reply-To: <553FD567.7020009@oracle.com> References: <553F8BB0.7050302@oracle.com> <553FD567.7020009@oracle.com> Message-ID: <55413061.2060104@oracle.com> Thank you for review! Boris On 04/28/2015 09:45 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 4/28/15 6:31 AM, Boris Molodenkov wrote: >> Hi All, >> >> I would like to backport fix for JDK-8058846 to 8u60. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8058846 >> Webrev: http://cr.openjdk.java.net/~bmoloden/8058846/webrev.00/ >> Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4d1463933e28 >> Review thread for original fix: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-November/016382.html >> >> >> testing: manual with jtreg >> >> Thanks, >> Boris >> From coleen.phillimore at oracle.com Wed Apr 29 20:08:57 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Apr 2015 16:08:57 -0400 Subject: RFR(xs): 8078628: linux-zero does not build without precompiled header In-Reply-To: References: Message-ID: <55413A59.3070506@oracle.com> This looks fine. I'll sponsor it. Can you make an hg export for me? thanks, Coleen On 4/29/15, 3:00 PM, Thomas St?fe wrote: > Hi, I still need a second reviewer and a sponsor. > > Thanks, Thomas > > On Friday, April 24, 2015, Thomas St?fe wrote: > >> Hi all, >> >> please review this tiny change. Build was broken for zero/slowdebug when >> building without precompiled header. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8078628 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8078628/webrev.00/webrev/ >> >> >> Thank you, >> >> Thomas >> From serguei.spitsyn at oracle.com Wed Apr 29 20:26:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Apr 2015 13:26:54 -0700 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception In-Reply-To: References: <553EA65B.6080805@oracle.com> <5540A8FB.4010101@oracle.com> <5540D61F.6010100@oracle.com> <5540E9BC.8000707@oracle.com> Message-ID: <55413E8E.90807@oracle.com> On 4/29/15 9:42 AM, Christian Thalinger wrote: >> On Apr 29, 2015, at 7:25 AM, serguei.spitsyn at oracle.com wrote: >> >> Coleen, >> >> Thank you a lot for review! >> >> >> On 4/29/15 6:01 AM, Coleen Phillimore wrote: >>> Serguei, >>> >>> The bug says JSR292 and PopFrame! I think we are all scared of it. >> That is true. I know about it. :) >> >>> The fix looks good. Nit: I would have coded it in an 'else' statement instead. >> Selected this way of fix to make it a one-liner to be easier for reviewers! :) >> I really do not have any personal preference. > The fix looks good and I also would like to see an else. I was going to satisfy this advice from Coleen. With an else it looks more clean and consistent with other fragments. Thanks a lot, Christian! Serguei > >>> I did check that this is the only interpreter runtime function without all paths setting vm_result. >> I admit, this was my mistake in the first place. >> >>> You are going to have to get someone from the compiler team who knows JSR292 to also review it. >> Sure. >> My plan was to ask Christian T. to take a brief look. >> >> Thanks, >> Serguei >> >>> thanks, >>> Coleen >>> >>> On 4/29/15, 5:48 AM, serguei.spitsyn at oracle.com wrote: >>>> Ping... >>>> Just wanted to tell that it is a very safe and simple one-liner so that >>>> I assumed it to be reviewed in a couple of days, not weeks! :) >>>> >>>> Thanks! >>>> Serguei >>>> >>>> On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the jdk 9 fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8076579 >>>>> >>>>> >>>>> 9 hotspot webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This bug is a regression that was introduced but the fix of: >>>>> https://bugs.openjdk.java.net/browse/JDK-7187554 >>>>> >>>>> The bug is in the InterpreterRuntime::member_name_arg_or_null() function that >>>>> does not return NULL if there is no invokestatic appendix argument (MemberName). >>>>> It is why the _remove_activation_preserving_args is trying to to restore unexisting >>>>> appendix argument when a pop instruction is executed by a debugger in the debuggee VM. >>>>> The fix is to correctly set NULL in the thread vm_result when it is necessary: >>>>> thread->set_vm_result(NULL); >>>>> >>>>> >>>>> Testing in progress: >>>>> In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests, JTREG com/sun/jdi tests, >>>>> ad-hog ExceptionBug.java test from the bug report >>>>> >>>>> >>>>> Thanks, >>>>> Serguei From david.holmes at oracle.com Wed Apr 29 23:25:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Apr 2015 09:25:27 +1000 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: <553FAF7F.7050109@oracle.com> References: <553893DF.5060406@oracle.com> <5538A460.5020902@oracle.com> <5539A488.3070306@oracle.com> <553AB970.9060309@oracle.com> <553F1192.60309@oracle.com> <553FAF7F.7050109@oracle.com> Message-ID: <55416867.6000501@oracle.com> Hi Dan, Thanks for the Review! On 29/04/2015 2:04 AM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ > > src/os/linux/vm/os_linux.cpp > So much cleaner now! > > src/share/vm/utilities/vmError.cpp > L1017: out.print_cr("os::fork_and_exec failed: %s", strerror(errno)); > L1104: tty->print_cr("os::fork_and_exec failed: %s", strerror(errno)); > So how about adding the 'errno' value in parens: "(%d)" > just in case strerror() can't handle the 'errno' param? Will add. > test/runtime/ErrorHandling/TestOnError.java > L38: if (!Platform.isDebugBuild()) { > Should this be the new @requires tag instead? I don't see that existing yet: http://openjdk.java.net/jtreg/tag-spec.html#requires_names ? > L63: output.stdoutShouldMatch("^" + msg); // match start of line only > Is the 'OnError' handler serialized? In other words, do we > have some assurance that the OnError output will be on a line > by itself and not mixed with other "crashing VM" output? In the test yes - we trigger a synchronous crash during VM startup, and the error handler is serialized. > test/runtime/ErrorHandling/TestOnOutOfMemoryError.java > L67: output.stdoutShouldMatch("^" + msg); // match start of line only > Same question about output interleaving. Again given the nature of the test (simple trigger by impossible array size) the error handler will be called synchronously. Nothing else should be happening to trigger other output. Probably not impossible but seems very unlikely. > > I don't think any of my comments are critical so you can choose > to make the changes or not. Thanks. I'll make the (%d) change and push for 8u. Will revisit for 9 "backport" if @require changes show up. David > Thumbs up. > > Dan > > > On 4/27/15 10:50 PM, David Holmes wrote: >> Ping: still need a (R)eviewer please. >> >> Thanks, >> David >> >> On 25/04/2015 7:45 AM, David Holmes wrote: >>> Hi Thomas, >>> >>> Thanks for looking at this. >>> >>> Note to readers: Still need a (R)eviewer for this please. >>> >>> On 24/04/2015 7:00 PM, Thomas St?fe wrote: >>>> Hi David, >>>> >>>> Unfortunately printing out errno in VMError will not work so well, >>>> as it >>>> is not clear if it is from fork() or execve(), and it is vulnerable >>>> against future changes of os::fork_and_exec(). Also, will not do >>>> anything for you on Windows. >>> >>> I thought about doing something inside fork_and_exec but decided against >>> it for a couple of reasons: >>> >>> 1. Needs to be done for every platform individually. >>> 2. Far from clear which mechanism would be appropriate given the >>> different contexts in which it can be used - which is also why I did not >>> do something for its use when debugging. >>> >>> As for Windows ... not sure what it will do but I was following existing >>> practice - see os_windows.cpp and perfMemory_windows.cpp. >>> >>>> I do not see a nice solution. Returning errno will not work, or be >>>> ugly, >>>> because you'd need to return GetLastError for windows, which has a >>>> different semantic, and the caller must remember that. >>> >>> And a return value, unless encoded, won't tell you which of fork and >>> execve failed. >>> >>>> On Solaris, os::fork_and_exec() prints a warning if PrintWarning() is >>>> on, which in my opinion does not help. That printout is very verbose >>>> and >>>> you have to remember setting it before starting the process. >>>> >>>> In some places in error handling (e.g. "check_dump_limits()") we return >>>> a string in a caller provided buffer describing the error which then is >>>> printed into the error logs. So, that may be a pragmatic solution, >>>> especially because we already have the scratch buffer in >>>> VMError::report_and_die(). >>>> >>>> On the other hand, in almost any os::... function we just swallow error >>>> details, as we did in os::fork_and_exec() before, so maybe we just >>>> leave >>>> it at this. >>> >>> I'll leave what I have now, pending further comments from anyone. It is >>> better than nothing I think, and would have saved me a bit of time when >>> I first encountered the problem with the missing syscall. >>> >>>> Otherwise, change looks fine to me. >>> >>> Thanks, >>> David >>> >>>> ..Thomas >>>> >>>> >>>> >>>> >>>> On Fri, Apr 24, 2015 at 4:03 AM, David Holmes >>> > wrote: >>>> >>>> Hi Thomas, >>>> >>>> On 23/04/2015 6:00 PM, Thomas St?fe wrote: >>>> >>>> On Thu, Apr 23, 2015 at 9:50 AM, David Holmes >>>> >>>> >>> >> wrote: >>>> On 23/04/2015 5:24 PM, Thomas St?fe wrote: >>>> - would it be possible to use vfork() instead of >>>> fork()? Might >>>> increase >>>> the chance of fork() succeeding in out-of-memory >>>> scenarios. The way >>>> fork/execve is used here is simple enough for vfork(). >>>> >>>> I'm reluctant to use vfork() as it is an unknown. The use >>>> of fork() >>>> has been trialled by Google with no problem. >>>> >>>> I understand. >>>> >>>> We use vfork() by default on Linux and HP-UX since 3-4 years >>>> for >>>> Runtime.exec() without problems (but our implementation differs >>>> wildly >>>> from the standard one). But then, Runtime.exec does not get >>>> called in >>>> error situations, so the conditions may be different for >>>> os::fork_and_exec(). >>>> >>>> >>>> Right - os::fork_and_exec is potentially a lot more fragile given >>>> the potential execution context. Which prompted me to add a second >>>> test for the general OnError handling case. I also moved the tests >>>> to runtime/ErrorHandling to match the directory that exists in >>>> JDK 9. >>>> >>>> Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8078470/webrev.v2/ >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> - would it be possible to print out errno in case fork >>>> fails? >>>> >>>> >>>> Sure. >>>> >>>> >>>> Thanks! >>>> >>>> ..Thomas >>>> >>>> Thanks, >>>> David >>>> >>>> Regards, Thomas >>>> >>>> >>>> On Thu, Apr 23, 2015 at 8:40 AM, David Holmes >>>> >>> >>>> >>> > >>>> >>> >>>> >>>> >>> >>> wrote: >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~dholmes/8078470/webrev/ >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8078470 >>>> >>>> For historical reasons, dating back to >>>> LinuxThreads, >>>> os::fork_and_exec uses direct syscalls to perform >>>> fork and >>>> execve >>>> functions. The fork syscall has been >>>> deprecated on >>>> linux >>>> for quite >>>> some time and some distributions are now >>>> shipping with >>>> deprecated >>>> syscalls removed - this results in a ENOSYS error >>>> and the >>>> "OnError" >>>> commands that utilize os::fork_and_exec no longer >>>> work. >>>> >>>> The problem was discussed here: >>>> >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017916.html >>>> >>>> >>>> It seems the concerns surrounding direct use of >>>> glibc >>>> fork() and >>>> exec() are no longer legitimate and Martin >>>> Buchholz reports >>>> that >>>> Google replaced the syscalls with glibc calls >>>> some >>>> time ago >>>> and have >>>> not had any problems. So we propose to apply the >>>> same change >>>> uniformly on Linux. >>>> >>>> This is initially going into 8u60 via >>>> jdk8u-hs-dev >>>> due to time >>>> constraints on the 8u60 schedule, and an internal >>>> limitation >>>> preventing me from pushing this to 9 right now. >>>> But it will be >>>> "backported" to 9 ASAP. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> >>>> > From kim.barrett at oracle.com Wed Apr 29 23:33:47 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 Apr 2015 19:33:47 -0400 Subject: [8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() In-Reply-To: <55416867.6000501@oracle.com> References: <553893DF.5060406@oracle.com> <5538A460.5020902@oracle.com> <5539A488.3070306@oracle.com> <553AB970.9060309@oracle.com> <553F1192.60309@oracle.com> <553FAF7F.7050109@oracle.com> <55416867.6000501@oracle.com> Message-ID: On Apr 29, 2015, at 7:25 PM, David Holmes wrote: > >> test/runtime/ErrorHandling/TestOnError.java >> L38: if (!Platform.isDebugBuild()) { >> Should this be the new @requires tag instead? > > I don't see that existing yet: > > http://openjdk.java.net/jtreg/tag-spec.html#requires_names https://bugs.openjdk.java.net/browse/CODETOOLS-7901086 Tests with non-product options should require a non-product build Not yet resolved. From david.holmes at oracle.com Thu Apr 30 05:15:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Apr 2015 15:15:11 +1000 Subject: [8u60] Request for approval: backport of 8078482: ppc: pass thread to throw_AbstractMethodError In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFC2DF4@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFC2DF4@DEWDFEMB12A.global.corp.sap> Message-ID: <5541BA5F.6080300@oracle.com> Hi Goetz, On 29/04/2015 7:36 PM, Lindenmaier, Goetz wrote: > Hi, > > I would like to backport "8078482: ppc: pass thread to throw_AbstractMethodError". > This fixes a fatal error in the ppc port. It touches only ppc files. > > The jdk9 change applies cleanly except for a whitespace diff: > http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.03.jdk8/ > > The original change: > http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.02/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/331b38ef0db3 > > I can push this myself, because it's ppc port only. But where do I need to > push it to get it into 8u60? jdk8u/hs-dev/hotspot? Yes. Approved. Thanks, David > Thanks and best regards, > Goetz. > From goetz.lindenmaier at sap.com Thu Apr 30 06:26:49 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 30 Apr 2015 06:26:49 +0000 Subject: [8u60] Request for approval: backport of 8078482: ppc: pass thread to throw_AbstractMethodError In-Reply-To: <5541BA5F.6080300@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFC2DF4@DEWDFEMB12A.global.corp.sap> <5541BA5F.6080300@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFC39A0@DEWDFEMB12A.global.corp.sap> Thanks David! Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Thursday, April 30, 2015 7:15 AM To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: Re: [8u60] Request for approval: backport of 8078482: ppc: pass thread to throw_AbstractMethodError Hi Goetz, On 29/04/2015 7:36 PM, Lindenmaier, Goetz wrote: > Hi, > > I would like to backport "8078482: ppc: pass thread to throw_AbstractMethodError". > This fixes a fatal error in the ppc port. It touches only ppc files. > > The jdk9 change applies cleanly except for a whitespace diff: > http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.03.jdk8/ > > The original change: > http://cr.openjdk.java.net/~goetz/webrevs/8078482-fixAME/webrev.02/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/331b38ef0db3 > > I can push this myself, because it's ppc port only. But where do I need to > push it to get it into 8u60? jdk8u/hs-dev/hotspot? Yes. Approved. Thanks, David > Thanks and best regards, > Goetz. > From david.holmes at oracle.com Thu Apr 30 05:26:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Apr 2015 15:26:34 +1000 Subject: aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <1430304750.8394.56.camel@mylittlepony.linaroharston> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> <1430304750.8394.56.camel@mylittlepony.linaroharston> Message-ID: <5541BD0A.3090305@oracle.com> Hi Nevill, Just realized this was sent to hotspot-dev (attempting bcc) but is not a hotspot issue. With your new approach this is a build issue so cc'ing build-dev. The new approach seems better to me but build folk need to confirm the placement. Thanks, David On 29/04/2015 8:52 PM, Edward Nevill wrote: > On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote: >> Hi Ed, >> >> On 21/04/2015 7:16 PM, Edward Nevill wrote: >>> Hi, >>> >>> The current jdk9 tip fails to build from source on aarch64 with the following error message >>> >>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': >>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' >>> collect2: error: ld returned 1 exit status >>> >>> The following webrev gets it building again. >>> >>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ >> >> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm >> also wondering how we would get __ARM_NEON defined but not __arm__? > > On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds. > > On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is. > > However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again. > > A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64). > > The failing code in pngpriv.h reads > > #ifndef PNG_ARM_NEON_OPT > > ... > > # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ > defined(PNG_ALIGNED_MEMORY_SUPPORTED) > # define PNG_ARM_NEON_OPT 2 > # else > # define PNG_ARM_NEON_OPT 0 > # endif > #endif > > So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above. > > The following patch webrev does this:- > > http://cr.openjdk.java.net/~enevill/8078245/webrev.01/ > > If you are happy with this and if I could have another reviewer I will push this. > > All the best, > Ed. > > From kirk at kodewerk.com Thu Apr 30 11:18:17 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 30 Apr 2015 13:18:17 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <5540D689.6020407@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> Message-ID: <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> Hi Stefan, Indeed, the improvements have been amazing. I have been getting many clients to bench with it and although the results have been mixed, overall many have been able to move forward. However I still would not recommend G1 to anyone who can?t move to 1.8.0_40. Of course this change will obviously come post _40 but still, the recent emergence of the G1 as a viable production ready collector suggests that making it a default maybe a wee bit optimistic. The change is based on the assumption that limiting latency is often more important than maximizing throughput. If this assumption is incorrect then this change might need to be reconsidered. I would agree with this assumption. In most cases latency is more important. However G1 doesn?t always provide lowest latency especially in smaller heaps. G1 is seen as a robust and well-tested collector. It is not expected to have stability problems, but becoming the default collector will increase its visibility and may reveal previously-unknown issues. I not sure it?s prudent to treat the entire Java eco-system as guinea pigs. I believe it?s more prudent to have the willing take that first step rather than have it unwittingly dropped on everyone At the end of the day, I don?t have any say in any of this (as it should be). All I can do is let you know what I?m seeing through my straw with the hope that you?ll find the information useful. From what I see, there is not nearly enough experience in the tuning the G1 in that is especially true in the general population to make this type of change at this point in time. I?m also not sure that we have all the tuning options we need to ensure "happy apps" in the wild. For example, I think the incremental accumulated waste in tenured regions is a problem that I?m not sure we have the tools to solve. I?m not even sure if it?s a recognized problem. In fact I?m not even sure it?s a real problem as at the moment it?s only a theory based on observations I?m making by looking at numbers of GC logs produced by applications using recent releases of the G1. I would suggest that for Tiered the default config for 8 is was also a bit premature. I?ve had to have a number of clients have to roll back off of it. ? Kirk On Apr 29, 2015, at 3:03 PM, Stefan Johansson wrote: > Hi Kirk, > > A lot of effort is put into G1, it has been continuously improving over the last couple of years and we now believe that G1 is ready to become the default. G1 will not improve all use case, but the same is true for the other collectors. For users where throughput is the main concern, Parallel GC can still be used by specifying -XX:+UseParallelGC on the command-line. > > Regards, > Stefan > > On 2015-04-29 09:10, Kirk Pepperdine wrote: >> Hi all, >> >> Is the G1 ready for this? I see many people moving to G1 but also I?m not sure that we?ve got the tunable correct. I?ve been sorting through a number of recent tuning engagements and my conclusion is that I would like the collector to be aggressive about collecting tenured regions at the beginning of a JVM?s life time but then become less aggressive over time. The reason is the residual waste that I see left behind because certain regions never hit the threshold needed to be included in the CSET. But, on aggregate, the number of regions in this state does start to retain a significant about of dead data. The only way to see the effects is to run regular Full GCs.. which of course you don?t really want to do. However, the problem seems to settle down a wee bit over time which is why I was thinking that being aggressive about what is collected in the early stages of a JVMs life should lead to better packing and hence less waste. >> >> Note, I don?t really care about the memory waste, only it?s effect on cycle frequencies and pause times. >> >> Sorry but I don?t have anything formal about this as I (and I believe many others) are still sorting out what to make of the G1 in prod. Generally the overall results are good but sometimes it?s not that way up front and how to improve things is sometimes challenging. >> >> On a side note, the move to Tiered in 8 has also caused a bit of grief. Metaspace has caused a bit of grief and even parallelStream, which works, has come with some interesting side effect. Everyone has been so enamored with Lambdas (rightfully so) that the other stuff has been completely forgotten and some of it has surprised people. I guess I?ll be submitting a talk for J1 on some of the field experience I?ve had with the other stuff. >> >> Regards, >> Kirk >> >> >> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >> >>> New JEP Candidate: http://openjdk.java.net/jeps/248 >>> >>> - Mark > > From mattis.castegren at oracle.com Thu Apr 30 12:27:32 2015 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Thu, 30 Apr 2015 05:27:32 -0700 (PDT) Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> Message-ID: Hi. I also work with customers but I would like to give an argument FOR changing the default. I don't think we will ever come to a point where G1 is better for ALL users. Even with a near perfect G1 implementation there may be cases where the parallel collector gives better throughput. Right now, I think G1 will be better for most users. There are probably also corner cases where G1 COULD be better, but where small issues reduces performance. By changing the default to G1, we will be able to easier find these as we will expose more users to G1. Finally, there will be a set of users who only care about throughput, and who will see a performance regression. In those cases, they can go back to using parallel. But hopefully, there will be far fewer users who need to tune their application to run with parallel GC than there are users who have to (or should) tune their application to run with G1. In the case of huge, business critical, applications, we will always introduce a risk by changing default collectors. This is true if we change to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We know that the collector we will focus on going forward is G1, so we should let as many people use it as possible. Of course we should document this a lot, so that users who go up to JDK 9 and see performance regressions can at least try to run with Parallel to see if it is due to the GC. Kind Regards /Mattis -----Original Message----- From: Kirk Pepperdine [mailto:kirk at kodewerk.com] Sent: den 30 april 2015 13:18 To: Stefan Johansson Cc: hotspot-dev at openjdk.java.net Source Developers Subject: Re: JEP 248: Make G1 the Default Garbage Collector Hi Stefan, Indeed, the improvements have been amazing. I have been getting many clients to bench with it and although the results have been mixed, overall many have been able to move forward. However I still would not recommend G1 to anyone who can't move to 1.8.0_40. Of course this change will obviously come post _40 but still, the recent emergence of the G1 as a viable production ready collector suggests that making it a default maybe a wee bit optimistic. The change is based on the assumption that limiting latency is often more important than maximizing throughput. If this assumption is incorrect then this change might need to be reconsidered. I would agree with this assumption. In most cases latency is more important. However G1 doesn't always provide lowest latency especially in smaller heaps. G1 is seen as a robust and well-tested collector. It is not expected to have stability problems, but becoming the default collector will increase its visibility and may reveal previously-unknown issues. I not sure it's prudent to treat the entire Java eco-system as guinea pigs. I believe it's more prudent to have the willing take that first step rather than have it unwittingly dropped on everyone At the end of the day, I don't have any say in any of this (as it should be). All I can do is let you know what I'm seeing through my straw with the hope that you'll find the information useful. From what I see, there is not nearly enough experience in the tuning the G1 in that is especially true in the general population to make this type of change at this point in time. I'm also not sure that we have all the tuning options we need to ensure "happy apps" in the wild. For example, I think the incremental accumulated waste in tenured regions is a problem that I'm not sure we have the tools to solve. I'm not even sure if it's a recognized problem. In fact I'm not even sure it's a real problem as at the moment it's only a theory based on observations I'm making by looking at numbers of GC logs produced by applications using recent releases of the G1. I would suggest that for Tiered the default config for 8 is was also a bit premature. I've had to have a number of clients have to roll back off of it. - Kirk On Apr 29, 2015, at 3:03 PM, Stefan Johansson wrote: > Hi Kirk, > > A lot of effort is put into G1, it has been continuously improving over the last couple of years and we now believe that G1 is ready to become the default. G1 will not improve all use case, but the same is true for the other collectors. For users where throughput is the main concern, Parallel GC can still be used by specifying -XX:+UseParallelGC on the command-line. > > Regards, > Stefan > > On 2015-04-29 09:10, Kirk Pepperdine wrote: >> Hi all, >> >> Is the G1 ready for this? I see many people moving to G1 but also I'm not sure that we've got the tunable correct. I've been sorting through a number of recent tuning engagements and my conclusion is that I would like the collector to be aggressive about collecting tenured regions at the beginning of a JVM's life time but then become less aggressive over time. The reason is the residual waste that I see left behind because certain regions never hit the threshold needed to be included in the CSET. But, on aggregate, the number of regions in this state does start to retain a significant about of dead data. The only way to see the effects is to run regular Full GCs.. which of course you don't really want to do. However, the problem seems to settle down a wee bit over time which is why I was thinking that being aggressive about what is collected in the early stages of a JVMs life should lead to better packing and hence less waste. >> >> Note, I don't really care about the memory waste, only it's effect on cycle frequencies and pause times. >> >> Sorry but I don't have anything formal about this as I (and I believe many others) are still sorting out what to make of the G1 in prod. Generally the overall results are good but sometimes it's not that way up front and how to improve things is sometimes challenging. >> >> On a side note, the move to Tiered in 8 has also caused a bit of grief. Metaspace has caused a bit of grief and even parallelStream, which works, has come with some interesting side effect. Everyone has been so enamored with Lambdas (rightfully so) that the other stuff has been completely forgotten and some of it has surprised people. I guess I'll be submitting a talk for J1 on some of the field experience I've had with the other stuff. >> >> Regards, >> Kirk >> >> >> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >> >>> New JEP Candidate: http://openjdk.java.net/jeps/248 >>> >>> - Mark > > From christian.tornqvist at oracle.com Thu Apr 30 13:11:35 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 30 Apr 2015 09:11:35 -0400 Subject: Review Request for JDK-8078112: Integrate Selection/Resolution test suite into jtreg tests In-Reply-To: <55316A1B.5040506@oracle.com> References: <55316A1B.5040506@oracle.com> Message-ID: <012d01d08347$33e07890$9ba169b0$@oracle.com> Hi Eric, Can you move all the common code into runtime/SelectionResolution/lib and add '@library lib' to the tests. runtime/SelectionResolution/InvokeVirtualICCE.java also needs a longer timeout than the default 120s (took 142s to run on my fairly modern laptop), this can be done by changing the @run to '@run main/timeout=300 InvokeVirtualICCE' Also, there's a significant performance issue when running these tests with a fastdebug/debug build (goes from 4min to 2h30m+), could you add code to skip running these on fastdebug/debug builds for now? You can use com.oracle.java.testlibrary.Platform.isDebugBuild() to accomplish this. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Eric McCorkle Sent: Friday, April 17, 2015 4:16 PM To: hotspot-dev at openjdk.java.net Subject: Review Request for JDK-8078112: Integrate Selection/Resolution test suite into jtreg tests Hello, Please review this patch, which integrates a portion of the selection/resolution test suite into the JTreg test suite. This will integrate the tests in such a way that they are run on every integration. This test suite uses a template-based generation scheme to exercise all aspects of the updated selection/resolution test suite from JVMS 8. It runs a very large number of tests, representing a very wide variety of cases. Extensive javadoc comments are found throughout the test code which describe the suite's functioning in more detail. Note that the tests for abstract method error have been held back for further development. Also note that this suite as already undergone extensive review as part of the development process. The JBS issue is here: https://bugs.openjdk.java.net/browse/JDK-8078112 The webrev is here: http://cr.openjdk.java.net/~emc/8078112/ From charlie.hunt at oracle.com Thu Apr 30 13:17:42 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Thu, 30 Apr 2015 08:17:42 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> Message-ID: Fwiw, we should not forget that anyone who is currently specifying an explicit GC to use in his or her JVM command line args will not experience any difference in behavior. They will still get the collector they specify to use. The (potential) impact will be on those who do not specify a GC to use. What I would like to hear from Kirk and others who frequently work with customers on GC, what?s the percentage of Java applications they have worked with that do not explicitly specify a GC? And, of those, what percentage of those apps fall into the categories of small heap and desire low latency, or desire high throughput even at the cost of frequent full GCs? thanks, charlie > On Apr 30, 2015, at 7:27 AM, Mattis Castegren wrote: > > Hi. > > I also work with customers but I would like to give an argument FOR changing the default. > > I don't think we will ever come to a point where G1 is better for ALL users. Even with a near perfect G1 implementation there may be cases where the parallel collector gives better throughput. > > Right now, I think G1 will be better for most users. There are probably also corner cases where G1 COULD be better, but where small issues reduces performance. By changing the default to G1, we will be able to easier find these as we will expose more users to G1. > > Finally, there will be a set of users who only care about throughput, and who will see a performance regression. In those cases, they can go back to using parallel. But hopefully, there will be far fewer users who need to tune their application to run with parallel GC than there are users who have to (or should) tune their application to run with G1. > > In the case of huge, business critical, applications, we will always introduce a risk by changing default collectors. This is true if we change to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We know that the collector we will focus on going forward is G1, so we should let as many people use it as possible. > > Of course we should document this a lot, so that users who go up to JDK 9 and see performance regressions can at least try to run with Parallel to see if it is due to the GC. > > Kind Regards > /Mattis > > -----Original Message----- > From: Kirk Pepperdine [mailto:kirk at kodewerk.com] > Sent: den 30 april 2015 13:18 > To: Stefan Johansson > Cc: hotspot-dev at openjdk.java.net Source Developers > Subject: Re: JEP 248: Make G1 the Default Garbage Collector > > Hi Stefan, > > Indeed, the improvements have been amazing. I have been getting many clients to bench with it and although the results have been mixed, overall many have been able to move forward. However I still would not recommend G1 to anyone who can't move to 1.8.0_40. Of course this change will obviously come post _40 but still, the recent emergence of the G1 as a viable production ready collector suggests that making it a default maybe a wee bit optimistic. > > The change is based on the assumption that limiting latency is often more important than maximizing throughput. If this assumption is incorrect then this change might need to be reconsidered. > > I would agree with this assumption. In most cases latency is more important. However G1 doesn't always provide lowest latency especially in smaller heaps. > > > G1 is seen as a robust and well-tested collector. It is not expected to have stability problems, but becoming the default collector will increase its visibility and may reveal previously-unknown issues. > I not sure it's prudent to treat the entire Java eco-system as guinea pigs. I believe it's more prudent to have the willing take that first step rather than have it unwittingly dropped on everyone > > > > At the end of the day, I don't have any say in any of this (as it should be). All I can do is let you know what I'm seeing through my straw with the hope that you'll find the information useful. From what I see, there is not nearly enough experience in the tuning the G1 in that is especially true in the general population to make this type of change at this point in time. I'm also not sure that we have all the tuning options we need to ensure "happy apps" in the wild. For example, I think the incremental accumulated waste in tenured regions is a problem that I'm not sure we have the tools to solve. I'm not even sure if it's a recognized problem. In fact I'm not even sure it's a real problem as at the moment it's only a theory based on observations I'm making by looking at numbers of GC logs produced by applications using recent releases of the G1. > > I would suggest that for Tiered the default config for 8 is was also a bit premature. I've had to have a number of clients have to roll back off of it. > > - Kirk > > On Apr 29, 2015, at 3:03 PM, Stefan Johansson wrote: > >> Hi Kirk, >> >> A lot of effort is put into G1, it has been continuously improving over the last couple of years and we now believe that G1 is ready to become the default. G1 will not improve all use case, but the same is true for the other collectors. For users where throughput is the main concern, Parallel GC can still be used by specifying -XX:+UseParallelGC on the command-line. >> >> Regards, >> Stefan >> >> On 2015-04-29 09:10, Kirk Pepperdine wrote: >>> Hi all, >>> >>> Is the G1 ready for this? I see many people moving to G1 but also I'm not sure that we've got the tunable correct. I've been sorting through a number of recent tuning engagements and my conclusion is that I would like the collector to be aggressive about collecting tenured regions at the beginning of a JVM's life time but then become less aggressive over time. The reason is the residual waste that I see left behind because certain regions never hit the threshold needed to be included in the CSET. But, on aggregate, the number of regions in this state does start to retain a significant about of dead data. The only way to see the effects is to run regular Full GCs.. which of course you don't really want to do. However, the problem seems to settle down a wee bit over time which is why I was thinking that being aggressive about what is collected in the early stages of a JVMs life should lead to better packing and hence less waste. >>> >>> Note, I don't really care about the memory waste, only it's effect on cycle frequencies and pause times. >>> >>> Sorry but I don't have anything formal about this as I (and I believe many others) are still sorting out what to make of the G1 in prod. Generally the overall results are good but sometimes it's not that way up front and how to improve things is sometimes challenging. >>> >>> On a side note, the move to Tiered in 8 has also caused a bit of grief. Metaspace has caused a bit of grief and even parallelStream, which works, has come with some interesting side effect. Everyone has been so enamored with Lambdas (rightfully so) that the other stuff has been completely forgotten and some of it has surprised people. I guess I'll be submitting a talk for J1 on some of the field experience I've had with the other stuff. >>> >>> Regards, >>> Kirk >>> >>> >>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >>> >>>> New JEP Candidate: http://openjdk.java.net/jeps/248 >>>> >>>> - Mark >> >> > From monica at beckwithclan.com Thu Apr 30 13:55:16 2015 From: monica at beckwithclan.com (Monica Beckwith) Date: Thu, 30 Apr 2015 08:55:16 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> Message-ID: <55423444.7040009@beckwithclan.com> I am also FOR the change in the default GC. Charlie and Mattis bring up great points. It's about time G1 gets put out there (as the default GC) since most of the development work is going into G1. As for documentation, we not only need to document the change in the default collector but also the defaults for the collector; that are enabled as soon as G1 is employed - e.g. MaxGCPauseMillis, IHOP, etc. With more and more input coming in, G1 is only going to get better and hopefully more adaptive :) And as for Charlie's question - I don't remember the last time that I didn't see an explicit GC mentioned on the command line (even if it was the default GC). These are just my two cents. -Monica On 4/30/15 8:17 AM, charlie hunt wrote: > Fwiw, we should not forget that anyone who is currently specifying an explicit GC to use in his or her JVM command line args will not experience any difference in behavior. They will still get the collector they specify to use. The (potential) impact will be on those who do not specify a GC to use. > > What I would like to hear from Kirk and others who frequently work with customers on GC, what?s the percentage of Java applications they have worked with that do not explicitly specify a GC? And, of those, what percentage of those apps fall into the categories of small heap and desire low latency, or desire high throughput even at the cost of frequent full GCs? > > thanks, > > charlie > >> On Apr 30, 2015, at 7:27 AM, Mattis Castegren wrote: >> >> Hi. >> >> I also work with customers but I would like to give an argument FOR changing the default. >> >> I don't think we will ever come to a point where G1 is better for ALL users. Even with a near perfect G1 implementation there may be cases where the parallel collector gives better throughput. >> >> Right now, I think G1 will be better for most users. There are probably also corner cases where G1 COULD be better, but where small issues reduces performance. By changing the default to G1, we will be able to easier find these as we will expose more users to G1. >> >> Finally, there will be a set of users who only care about throughput, and who will see a performance regression. In those cases, they can go back to using parallel. But hopefully, there will be far fewer users who need to tune their application to run with parallel GC than there are users who have to (or should) tune their application to run with G1. >> >> In the case of huge, business critical, applications, we will always introduce a risk by changing default collectors. This is true if we change to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We know that the collector we will focus on going forward is G1, so we should let as many people use it as possible. >> >> Of course we should document this a lot, so that users who go up to JDK 9 and see performance regressions can at least try to run with Parallel to see if it is due to the GC. >> >> Kind Regards >> /Mattis >> >> -----Original Message----- >> From: Kirk Pepperdine [mailto:kirk at kodewerk.com] >> Sent: den 30 april 2015 13:18 >> To: Stefan Johansson >> Cc: hotspot-dev at openjdk.java.net Source Developers >> Subject: Re: JEP 248: Make G1 the Default Garbage Collector >> >> Hi Stefan, >> >> Indeed, the improvements have been amazing. I have been getting many clients to bench with it and although the results have been mixed, overall many have been able to move forward. However I still would not recommend G1 to anyone who can't move to 1.8.0_40. Of course this change will obviously come post _40 but still, the recent emergence of the G1 as a viable production ready collector suggests that making it a default maybe a wee bit optimistic. >> >> The change is based on the assumption that limiting latency is often more important than maximizing throughput. If this assumption is incorrect then this change might need to be reconsidered. >> >> I would agree with this assumption. In most cases latency is more important. However G1 doesn't always provide lowest latency especially in smaller heaps. >> >> >> G1 is seen as a robust and well-tested collector. It is not expected to have stability problems, but becoming the default collector will increase its visibility and may reveal previously-unknown issues. >> I not sure it's prudent to treat the entire Java eco-system as guinea pigs. I believe it's more prudent to have the willing take that first step rather than have it unwittingly dropped on everyone >> >> >> >> At the end of the day, I don't have any say in any of this (as it should be). All I can do is let you know what I'm seeing through my straw with the hope that you'll find the information useful. From what I see, there is not nearly enough experience in the tuning the G1 in that is especially true in the general population to make this type of change at this point in time. I'm also not sure that we have all the tuning options we need to ensure "happy apps" in the wild. For example, I think the incremental accumulated waste in tenured regions is a problem that I'm not sure we have the tools to solve. I'm not even sure if it's a recognized problem. In fact I'm not even sure it's a real problem as at the moment it's only a theory based on observations I'm making by looking at numbers of GC logs produced by applications using recent releases of the G1. >> >> I would suggest that for Tiered the default config for 8 is was also a bit premature. I've had to have a number of clients have to roll back off of it. >> >> - Kirk >> >> On Apr 29, 2015, at 3:03 PM, Stefan Johansson wrote: >> >>> Hi Kirk, >>> >>> A lot of effort is put into G1, it has been continuously improving over the last couple of years and we now believe that G1 is ready to become the default. G1 will not improve all use case, but the same is true for the other collectors. For users where throughput is the main concern, Parallel GC can still be used by specifying -XX:+UseParallelGC on the command-line. >>> >>> Regards, >>> Stefan >>> >>> On 2015-04-29 09:10, Kirk Pepperdine wrote: >>>> Hi all, >>>> >>>> Is the G1 ready for this? I see many people moving to G1 but also I'm not sure that we've got the tunable correct. I've been sorting through a number of recent tuning engagements and my conclusion is that I would like the collector to be aggressive about collecting tenured regions at the beginning of a JVM's life time but then become less aggressive over time. The reason is the residual waste that I see left behind because certain regions never hit the threshold needed to be included in the CSET. But, on aggregate, the number of regions in this state does start to retain a significant about of dead data. The only way to see the effects is to run regular Full GCs.. which of course you don't really want to do. However, the problem seems to settle down a wee bit over time which is why I was thinking that being aggressive about what is collected in the early stages of a JVMs life should lead to better packing and hence less waste. >>>> >>>> Note, I don't really care about the memory waste, only it's effect on cycle frequencies and pause times. >>>> >>>> Sorry but I don't have anything formal about this as I (and I believe many others) are still sorting out what to make of the G1 in prod. Generally the overall results are good but sometimes it's not that way up front and how to improve things is sometimes challenging. >>>> >>>> On a side note, the move to Tiered in 8 has also caused a bit of grief. Metaspace has caused a bit of grief and even parallelStream, which works, has come with some interesting side effect. Everyone has been so enamored with Lambdas (rightfully so) that the other stuff has been completely forgotten and some of it has surprised people. I guess I'll be submitting a talk for J1 on some of the field experience I've had with the other stuff. >>>> >>>> Regards, >>>> Kirk >>>> >>>> >>>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >>>> >>>>> New JEP Candidate: http://openjdk.java.net/jeps/248 >>>>> >>>>> - Mark >>> From kirk.pepperdine at gmail.com Thu Apr 30 14:11:30 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Thu, 30 Apr 2015 16:11:30 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> Message-ID: <14B76A8D-474B-440E-B0DA-D3B26F0E5109@gmail.com> Hi Charlie, > Fwiw, we should not forget that anyone who is currently specifying an explicit GC to use in his or her JVM command line args will not experience any difference in behavior. True? I would say that this group would mostly include those that use CMS. Those are the people I?m finding that I?m helping move along. > They will still get the collector they specify to use. The (potential) impact will be on those who do not specify a GC to use. > > What I would like to hear from Kirk and others who frequently work with customers on GC, what?s the percentage of Java applications they have worked with that do not explicitly specify a GC? Good question. I think that most of the people I work with stumble into the GC problem and then after mucking about for a bit call me. So it?s not a very good data sample. > And, of those, what percentage of those apps fall into the categories of small heap and desire low latency, or desire high throughput even at the cost of frequent full GCs? Difficult to say. No one I know wants a GC pause. That said, the majority of people I deal with are those where the pause is interfering with some aspect of their business so again, a very biased sample. I appreciate the bandaid analogy and what I can say is that I certainly wouldn?t want anyone ripping off the bandaid on my mission critical application. Don?t forget 9 is going to give them a good rap across the knuckles as it is. I have spoken about the changes that will come with Java 9 at JavaLand, JAX-Mainz, JAX-Finance, and Istanbul Tech-talks. I?ll give a rough estimate of most than 1500 developers and I would say that the vast majority were clearly unaware of the planned changes in 9, unaware that they could start testing against 9 today, unaware of tiered compilation and unaware that it?s the default setting in 8. Say what you like but that seems to the norm AFAICT. My final note on this subject is; I don?t think we need to be reminded that this is a widely used platform. That said, my position isn?t based in resistance to the G1, it based on the need for decisions to be conservative. Should the G1 be the default collector? I still think it?s a bit early to answer that question but I?m sure by 10 if things process as they have it won?t be. Regards, Kirk > > thanks, > > charlie > >> On Apr 30, 2015, at 7:27 AM, Mattis Castegren wrote: >> >> Hi. >> >> I also work with customers but I would like to give an argument FOR changing the default. >> >> I don't think we will ever come to a point where G1 is better for ALL users. Even with a near perfect G1 implementation there may be cases where the parallel collector gives better throughput. >> >> Right now, I think G1 will be better for most users. There are probably also corner cases where G1 COULD be better, but where small issues reduces performance. By changing the default to G1, we will be able to easier find these as we will expose more users to G1. >> >> Finally, there will be a set of users who only care about throughput, and who will see a performance regression. In those cases, they can go back to using parallel. But hopefully, there will be far fewer users who need to tune their application to run with parallel GC than there are users who have to (or should) tune their application to run with G1. >> >> In the case of huge, business critical, applications, we will always introduce a risk by changing default collectors. This is true if we change to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We know that the collector we will focus on going forward is G1, so we should let as many people use it as possible. >> >> Of course we should document this a lot, so that users who go up to JDK 9 and see performance regressions can at least try to run with Parallel to see if it is due to the GC. >> >> Kind Regards >> /Mattis >> >> -----Original Message----- >> From: Kirk Pepperdine [mailto:kirk at kodewerk.com] >> Sent: den 30 april 2015 13:18 >> To: Stefan Johansson >> Cc: hotspot-dev at openjdk.java.net Source Developers >> Subject: Re: JEP 248: Make G1 the Default Garbage Collector >> >> Hi Stefan, >> >> Indeed, the improvements have been amazing. I have been getting many clients to bench with it and although the results have been mixed, overall many have been able to move forward. However I still would not recommend G1 to anyone who can't move to 1.8.0_40. Of course this change will obviously come post _40 but still, the recent emergence of the G1 as a viable production ready collector suggests that making it a default maybe a wee bit optimistic. >> >> The change is based on the assumption that limiting latency is often more important than maximizing throughput. If this assumption is incorrect then this change might need to be reconsidered. >> >> I would agree with this assumption. In most cases latency is more important. However G1 doesn't always provide lowest latency especially in smaller heaps. >> >> >> G1 is seen as a robust and well-tested collector. It is not expected to have stability problems, but becoming the default collector will increase its visibility and may reveal previously-unknown issues. >> I not sure it's prudent to treat the entire Java eco-system as guinea pigs. I believe it's more prudent to have the willing take that first step rather than have it unwittingly dropped on everyone >> >> >> >> At the end of the day, I don't have any say in any of this (as it should be). All I can do is let you know what I'm seeing through my straw with the hope that you'll find the information useful. From what I see, there is not nearly enough experience in the tuning the G1 in that is especially true in the general population to make this type of change at this point in time. I'm also not sure that we have all the tuning options we need to ensure "happy apps" in the wild. For example, I think the incremental accumulated waste in tenured regions is a problem that I'm not sure we have the tools to solve. I'm not even sure if it's a recognized problem. In fact I'm not even sure it's a real problem as at the moment it's only a theory based on observations I'm making by looking at numbers of GC logs produced by applications using recent releases of the G1. >> >> I would suggest that for Tiered the default config for 8 is was also a bit premature. I've had to have a number of clients have to roll back off of it. >> >> - Kirk >> >> On Apr 29, 2015, at 3:03 PM, Stefan Johansson wrote: >> >>> Hi Kirk, >>> >>> A lot of effort is put into G1, it has been continuously improving over the last couple of years and we now believe that G1 is ready to become the default. G1 will not improve all use case, but the same is true for the other collectors. For users where throughput is the main concern, Parallel GC can still be used by specifying -XX:+UseParallelGC on the command-line. >>> >>> Regards, >>> Stefan >>> >>> On 2015-04-29 09:10, Kirk Pepperdine wrote: >>>> Hi all, >>>> >>>> Is the G1 ready for this? I see many people moving to G1 but also I'm not sure that we've got the tunable correct. I've been sorting through a number of recent tuning engagements and my conclusion is that I would like the collector to be aggressive about collecting tenured regions at the beginning of a JVM's life time but then become less aggressive over time. The reason is the residual waste that I see left behind because certain regions never hit the threshold needed to be included in the CSET. But, on aggregate, the number of regions in this state does start to retain a significant about of dead data. The only way to see the effects is to run regular Full GCs.. which of course you don't really want to do. However, the problem seems to settle down a wee bit over time which is why I was thinking that being aggressive about what is collected in the early stages of a JVMs life should lead to better packing and hence less waste. >>>> >>>> Note, I don't really care about the memory waste, only it's effect on cycle frequencies and pause times. >>>> >>>> Sorry but I don't have anything formal about this as I (and I believe many others) are still sorting out what to make of the G1 in prod. Generally the overall results are good but sometimes it's not that way up front and how to improve things is sometimes challenging. >>>> >>>> On a side note, the move to Tiered in 8 has also caused a bit of grief. Metaspace has caused a bit of grief and even parallelStream, which works, has come with some interesting side effect. Everyone has been so enamored with Lambdas (rightfully so) that the other stuff has been completely forgotten and some of it has surprised people. I guess I'll be submitting a talk for J1 on some of the field experience I've had with the other stuff. >>>> >>>> Regards, >>>> Kirk >>>> >>>> >>>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >>>> >>>>> New JEP Candidate: http://openjdk.java.net/jeps/248 >>>>> >>>>> - Mark >>> >>> >> > From vitalyd at gmail.com Thu Apr 30 14:21:40 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 30 Apr 2015 10:21:40 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <14B76A8D-474B-440E-B0DA-D3B26F0E5109@gmail.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <14B76A8D-474B-440E-B0DA-D3B26F0E5109@gmail.com> Message-ID: My $.02 on the issue ... Undoubtedly, making G1 the default collector will uncover some cases that aren't handled well by it ... but that's a good thing! First, it's impossible for Oracle to test G1 across the same variety of workloads that exist in the wild. Asking developers to move to G1 voluntarily is good, but there will be a large audience that will not be reached. Second, as noted, Java 9 migration is already going to require folks to test against it, and if they're performance sensitive, then presumably there will be performance tests done prior to production deployment. If they find regressions, there's an easy flag to enable old behavior, and they can move on if they're not interested in digging deeper. Luckily, GC introspection/monitoring is pretty good, so performance anomalies of consequence should be fairly easily spotted (not necessarily the root cause though!). This is different from, say, tiered compilation which is a bit more difficult to introspect/monitor/analyze/etc. I think for the greater good of G1, this should be done. If Java 9 is released without it being default, yes, Oracle will have a couple more years of lab time + sporadic field feedback to tune/change things further, but the same unforeseen issues are almost as likely to creep up in Java 10 if it's made default then -- this is just kicking the can down the road, and I don't see the point. On Thu, Apr 30, 2015 at 10:11 AM, Kirk Pepperdine wrote: > Hi Charlie, > > > > Fwiw, we should not forget that anyone who is currently specifying an > explicit GC to use in his or her JVM command line args will not experience > any difference in behavior. > > True? I would say that this group would mostly include those that use CMS. > Those are the people I?m finding that I?m helping move along. > > > > They will still get the collector they specify to use. The (potential) > impact will be on those who do not specify a GC to use. > > > > What I would like to hear from Kirk and others who frequently work with > customers on GC, what?s the percentage of Java applications they have > worked with that do not explicitly specify a GC? > > Good question. I think that most of the people I work with stumble into > the GC problem and then after mucking about for a bit call me. So it?s not > a very good data sample. > > > And, of those, what percentage of those apps fall into the categories > of small heap and desire low latency, or desire high throughput even at the > cost of frequent full GCs? > > Difficult to say. No one I know wants a GC pause. That said, the majority > of people I deal with are those where the pause is interfering with some > aspect of their business so again, a very biased sample. > > I appreciate the bandaid analogy and what I can say is that I certainly > wouldn?t want anyone ripping off the bandaid on my mission critical > application. Don?t forget 9 is going to give them a good rap across the > knuckles as it is. I have spoken about the changes that will come with Java > 9 at JavaLand, JAX-Mainz, JAX-Finance, and Istanbul Tech-talks. I?ll give a > rough estimate of most than 1500 developers and I would say that the vast > majority were clearly unaware of the planned changes in 9, unaware that > they could start testing against 9 today, unaware of tiered compilation and > unaware that it?s the default setting in 8. Say what you like but that > seems to the norm AFAICT. > > My final note on this subject is; I don?t think we need to be reminded > that this is a widely used platform. That said, my position isn?t based in > resistance to the G1, it based on the need for decisions to be > conservative. Should the G1 be the default collector? I still think it?s a > bit early to answer that question but I?m sure by 10 if things process as > they have it won?t be. > > Regards, > Kirk > > > > > thanks, > > > > charlie > > > >> On Apr 30, 2015, at 7:27 AM, Mattis Castegren < > mattis.castegren at oracle.com> wrote: > >> > >> Hi. > >> > >> I also work with customers but I would like to give an argument FOR > changing the default. > >> > >> I don't think we will ever come to a point where G1 is better for ALL > users. Even with a near perfect G1 implementation there may be cases where > the parallel collector gives better throughput. > >> > >> Right now, I think G1 will be better for most users. There are probably > also corner cases where G1 COULD be better, but where small issues reduces > performance. By changing the default to G1, we will be able to easier find > these as we will expose more users to G1. > >> > >> Finally, there will be a set of users who only care about throughput, > and who will see a performance regression. In those cases, they can go back > to using parallel. But hopefully, there will be far fewer users who need to > tune their application to run with parallel GC than there are users who > have to (or should) tune their application to run with G1. > >> > >> In the case of huge, business critical, applications, we will always > introduce a risk by changing default collectors. This is true if we change > to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We know > that the collector we will focus on going forward is G1, so we should let > as many people use it as possible. > >> > >> Of course we should document this a lot, so that users who go up to JDK > 9 and see performance regressions can at least try to run with Parallel to > see if it is due to the GC. > >> > >> Kind Regards > >> /Mattis > >> > >> -----Original Message----- > >> From: Kirk Pepperdine [mailto:kirk at kodewerk.com] > >> Sent: den 30 april 2015 13:18 > >> To: Stefan Johansson > >> Cc: hotspot-dev at openjdk.java.net Source Developers > >> Subject: Re: JEP 248: Make G1 the Default Garbage Collector > >> > >> Hi Stefan, > >> > >> Indeed, the improvements have been amazing. I have been getting many > clients to bench with it and although the results have been mixed, overall > many have been able to move forward. However I still would not recommend G1 > to anyone who can't move to 1.8.0_40. Of course this change will obviously > come post _40 but still, the recent emergence of the G1 as a viable > production ready collector suggests that making it a default maybe a wee > bit optimistic. > >> > >> The change is based on the assumption that limiting latency is often > more important than maximizing throughput. If this assumption is incorrect > then this change might need to be reconsidered. > >> > >> I would agree with this assumption. In most cases latency is more > important. However G1 doesn't always provide lowest latency especially in > smaller heaps. > >> > >> > >> G1 is seen as a robust and well-tested collector. It is not expected to > have stability problems, but becoming the default collector will increase > its visibility and may reveal previously-unknown issues. > >> I not sure it's prudent to treat the entire Java eco-system as guinea > pigs. I believe it's more prudent to have the willing take that first step > rather than have it unwittingly dropped on everyone > >> > >> > >> > >> At the end of the day, I don't have any say in any of this (as it > should be). All I can do is let you know what I'm seeing through my straw > with the hope that you'll find the information useful. From what I see, > there is not nearly enough experience in the tuning the G1 in that is > especially true in the general population to make this type of change at > this point in time. I'm also not sure that we have all the tuning options > we need to ensure "happy apps" in the wild. For example, I think the > incremental accumulated waste in tenured regions is a problem that I'm not > sure we have the tools to solve. I'm not even sure if it's a recognized > problem. In fact I'm not even sure it's a real problem as at the moment > it's only a theory based on observations I'm making by looking at numbers > of GC logs produced by applications using recent releases of the G1. > >> > >> I would suggest that for Tiered the default config for 8 is was also a > bit premature. I've had to have a number of clients have to roll back off > of it. > >> > >> - Kirk > >> > >> On Apr 29, 2015, at 3:03 PM, Stefan Johansson < > stefan.johansson at oracle.com> wrote: > >> > >>> Hi Kirk, > >>> > >>> A lot of effort is put into G1, it has been continuously improving > over the last couple of years and we now believe that G1 is ready to become > the default. G1 will not improve all use case, but the same is true for the > other collectors. For users where throughput is the main concern, Parallel > GC can still be used by specifying -XX:+UseParallelGC on the command-line. > >>> > >>> Regards, > >>> Stefan > >>> > >>> On 2015-04-29 09:10, Kirk Pepperdine wrote: > >>>> Hi all, > >>>> > >>>> Is the G1 ready for this? I see many people moving to G1 but also I'm > not sure that we've got the tunable correct. I've been sorting through a > number of recent tuning engagements and my conclusion is that I would like > the collector to be aggressive about collecting tenured regions at the > beginning of a JVM's life time but then become less aggressive over time. > The reason is the residual waste that I see left behind because certain > regions never hit the threshold needed to be included in the CSET. But, on > aggregate, the number of regions in this state does start to retain a > significant about of dead data. The only way to see the effects is to run > regular Full GCs.. which of course you don't really want to do. However, > the problem seems to settle down a wee bit over time which is why I was > thinking that being aggressive about what is collected in the early stages > of a JVMs life should lead to better packing and hence less waste. > >>>> > >>>> Note, I don't really care about the memory waste, only it's effect on > cycle frequencies and pause times. > >>>> > >>>> Sorry but I don't have anything formal about this as I (and I believe > many others) are still sorting out what to make of the G1 in prod. > Generally the overall results are good but sometimes it's not that way up > front and how to improve things is sometimes challenging. > >>>> > >>>> On a side note, the move to Tiered in 8 has also caused a bit of > grief. Metaspace has caused a bit of grief and even parallelStream, which > works, has come with some interesting side effect. Everyone has been so > enamored with Lambdas (rightfully so) that the other stuff has been > completely forgotten and some of it has surprised people. I guess I'll be > submitting a talk for J1 on some of the field experience I've had with the > other stuff. > >>>> > >>>> Regards, > >>>> Kirk > >>>> > >>>> > >>>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: > >>>> > >>>>> New JEP Candidate: http://openjdk.java.net/jeps/248 > >>>>> > >>>>> - Mark > >>> > >>> > >> > > > > From uschindler at apache.org Thu Apr 30 14:29:09 2015 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 30 Apr 2015 16:29:09 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> Message-ID: <016d01d08352$08376770$18a63650$@apache.org> Hi Kirk, hi Mark, the Lucene/Solr/Elasticsearch people still recommend to their users to not use G1GC, although for this type of application (full text search with the requirement for very low response times and no pauses) is a good candidate for G1GC. On the other hand, heap sizes for typical Lucene applications should not be too high, because most of the processing is done on memory mapped files off-heap. So heaps should be at most 1/4 of the physical RAM available, because Lucene relies on the fact that the index files reside in file system cache (too large heaps are contra-productive here). See also our recommendations for Apache Solr and Elasticsearch: http://wiki.apache.org/solr/ShawnHeisey#GC_Tuning_for_Solr http://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html Currently Lucene's indexing sometimes caused serious data corruption with G1GC - leading to data loss, which was mainly caused by some bugs around G1GC and its use of additional memory barriers and the very close interaction with Hotspot, that seemed to broke some optimizations. We had (only in combination with G1GC during our test suites) simple "assert" statements *sometimes* failing that should never fail unless there is a bug in the JVM. We are aware that Java 8u40 declared G1GC as "production ready", so we are still looking at failures in our extensive testing infrastructure. Indeed, I have no seen any G1GC related problems recently, but that is not necessarily a sign for correctness. Uwe P.S.: It was nice to meet you last week on JAX! ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Kirk Pepperdine > Sent: Wednesday, April 29, 2015 9:11 AM > To: hotspot-dev at openjdk.java.net Source Developers > Subject: Re: JEP 248: Make G1 the Default Garbage Collector > > Hi all, > > Is the G1 ready for this? I see many people moving to G1 but also I?m not > sure that we?ve got the tunable correct. I?ve been sorting through a number > of recent tuning engagements and my conclusion is that I would like the > collector to be aggressive about collecting tenured regions at the beginning > of a JVM?s life time but then become less aggressive over time. The reason is > the residual waste that I see left behind because certain regions never hit > the threshold needed to be included in the CSET. But, on aggregate, the > number of regions in this state does start to retain a significant about of dead > data. The only way to see the effects is to run regular Full GCs.. which of > course you don?t really want to do. However, the problem seems to settle > down a wee bit over time which is why I was thinking that being aggressive > about what is collected in the early stages of a JVMs life should lead to better > packing and hence less waste. > > Note, I don?t really care about the memory waste, only it?s effect on cycle > frequencies and pause times. > > Sorry but I don?t have anything formal about this as I (and I believe many > others) are still sorting out what to make of the G1 in prod. Generally the > overall results are good but sometimes it?s not that way up front and how to > improve things is sometimes challenging. > > On a side note, the move to Tiered in 8 has also caused a bit of grief. > Metaspace has caused a bit of grief and even parallelStream, which works, > has come with some interesting side effect. Everyone has been so enamored > with Lambdas (rightfully so) that the other stuff has been completely > forgotten and some of it has surprised people. I guess I?ll be submitting a talk > for J1 on some of the field experience I?ve had with the other stuff. > > Regards, > Kirk > > > On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: > > > New JEP Candidate: http://openjdk.java.net/jeps/248 > > > > - Mark From aaron.grunthal at infinite-source.de Thu Apr 30 14:33:13 2015 From: aaron.grunthal at infinite-source.de (Aaron Grunthal) Date: Thu, 30 Apr 2015 16:33:13 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> Message-ID: <55423D29.8000809@infinite-source.de> Lucene devs still advise against using G1GC[1] because it causes spurious crashes while CMS does not. And unless something has changed since march this still seems to be up-to-date information[2] [1] https://wiki.apache.org/lucene-java/JavaBugs [2] https://issues.apache.org/jira/browse/LUCENE-5168#comment-14344694 On 29.04.2015 09:10, Kirk Pepperdine wrote: > Hi all, > > Is the G1 ready for this? I see many people moving to G1 but also I?m not sure that we?ve got the tunable correct. I?ve been sorting through a number of recent tuning engagements and my conclusion is that I would like the collector to be aggressive about collecting tenured regions at the beginning of a JVM?s life time but then become less aggressive over time. The reason is the residual waste that I see left behind because certain regions never hit the threshold needed to be included in the CSET. But, on aggregate, the number of regions in this state does start to retain a significant about of dead data. The only way to see the effects is to run regular Full GCs.. which of course you don?t really want to do. However, the problem seems to settle down a wee bit over time which is why I was thinking that being aggressive about what is collected in the early stages of a JVMs life should lead to better packing and hence less waste. > > Note, I don?t really care about the memory waste, only it?s effect on cycle frequencies and pause times. > > Sorry but I don?t have anything formal about this as I (and I believe many others) are still sorting out what to make of the G1 in prod. Generally the overall results are good but sometimes it?s not that way up front and how to improve things is sometimes challenging. > > On a side note, the move to Tiered in 8 has also caused a bit of grief. Metaspace has caused a bit of grief and even parallelStream, which works, has come with some interesting side effect. Everyone has been so enamored with Lambdas (rightfully so) that the other stuff has been completely forgotten and some of it has surprised people. I guess I?ll be submitting a talk for J1 on some of the field experience I?ve had with the other stuff. > > Regards, > Kirk > > > On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: > >> New JEP Candidate: http://openjdk.java.net/jeps/248 >> >> - Mark > > From kirk at kodewerk.com Thu Apr 30 14:44:45 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 30 Apr 2015 16:44:45 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <016d01d08352$08376770$18a63650$@apache.org> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <016d01d08352$08376770$18a63650$@apache.org> Message-ID: Hi Uwe, I?m currently dealing with a customer trying to use Lucene/Solr/Elasticsearch and I expected that would be a perfect candidate for the G1 but.... I think that other ?off-heap? solutions might also suffer. And, as you now know, it takes a serious amount of digging to sort these problems out. I am certain there are very few dev teams with the talent on board to work through the diagnostic process. Regards, Kirk PS, yes it was indeed nice to meet you @ JAX. On Apr 30, 2015, at 4:29 PM, Uwe Schindler wrote: > Hi Kirk, hi Mark, > > the Lucene/Solr/Elasticsearch people still recommend to their users to not use G1GC, although for this type of application (full text search with the requirement for very low response times and no pauses) is a good candidate for G1GC. On the other hand, heap sizes for typical Lucene applications should not be too high, because most of the processing is done on memory mapped files off-heap. So heaps should be at most 1/4 of the physical RAM available, because Lucene relies on the fact that the index files reside in file system cache (too large heaps are contra-productive here). > > See also our recommendations for Apache Solr and Elasticsearch: > http://wiki.apache.org/solr/ShawnHeisey#GC_Tuning_for_Solr > http://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html > > Currently Lucene's indexing sometimes caused serious data corruption with G1GC - leading to data loss, which was mainly caused by some bugs around G1GC and its use of additional memory barriers and the very close interaction with Hotspot, that seemed to broke some optimizations. We had (only in combination with G1GC during our test suites) simple "assert" statements *sometimes* failing that should never fail unless there is a bug in the JVM. > > We are aware that Java 8u40 declared G1GC as "production ready", so we are still looking at failures in our extensive testing infrastructure. Indeed, I have no seen any G1GC related problems recently, but that is not necessarily a sign for correctness. > > Uwe > > P.S.: It was nice to meet you last week on JAX! > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Kirk Pepperdine >> Sent: Wednesday, April 29, 2015 9:11 AM >> To: hotspot-dev at openjdk.java.net Source Developers >> Subject: Re: JEP 248: Make G1 the Default Garbage Collector >> >> Hi all, >> >> Is the G1 ready for this? I see many people moving to G1 but also I?m not >> sure that we?ve got the tunable correct. I?ve been sorting through a number >> of recent tuning engagements and my conclusion is that I would like the >> collector to be aggressive about collecting tenured regions at the beginning >> of a JVM?s life time but then become less aggressive over time. The reason is >> the residual waste that I see left behind because certain regions never hit >> the threshold needed to be included in the CSET. But, on aggregate, the >> number of regions in this state does start to retain a significant about of dead >> data. The only way to see the effects is to run regular Full GCs.. which of >> course you don?t really want to do. However, the problem seems to settle >> down a wee bit over time which is why I was thinking that being aggressive >> about what is collected in the early stages of a JVMs life should lead to better >> packing and hence less waste. >> >> Note, I don?t really care about the memory waste, only it?s effect on cycle >> frequencies and pause times. >> >> Sorry but I don?t have anything formal about this as I (and I believe many >> others) are still sorting out what to make of the G1 in prod. Generally the >> overall results are good but sometimes it?s not that way up front and how to >> improve things is sometimes challenging. >> >> On a side note, the move to Tiered in 8 has also caused a bit of grief. >> Metaspace has caused a bit of grief and even parallelStream, which works, >> has come with some interesting side effect. Everyone has been so enamored >> with Lambdas (rightfully so) that the other stuff has been completely >> forgotten and some of it has surprised people. I guess I?ll be submitting a talk >> for J1 on some of the field experience I?ve had with the other stuff. >> >> Regards, >> Kirk >> >> >> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >> >>> New JEP Candidate: http://openjdk.java.net/jeps/248 >>> >>> - Mark > From per.liden at oracle.com Thu Apr 30 14:46:05 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 30 Apr 2015 16:46:05 +0200 Subject: RFR(s): 8079148: Fix incorrect include guards Message-ID: <5542402D.1050407@oracle.com> Small cleanup of incorrect/misspelled/missing include guards. Affects the following GC and runtime files: src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp src/share/vm/gc_implementation/g1/evacuationInfo.hpp src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp src/share/vm/gc_implementation/g1/g1RootProcessor.hpp src/share/vm/gc_implementation/g1/heapRegionBounds.inline.hpp src/share/vm/gc_implementation/shared/objectCountEventSender.hpp src/share/vm/memory/guardedMemory.hpp src/share/vm/memory/metaspaceChunkFreeListSummary.hpp src/share/vm/memory/metaspaceGCThresholdUpdater.hpp src/share/vm/memory/metaspaceShared.hpp src/share/vm/memory/metaspaceTracer.hpp src/share/vm/memory/padded.inline.hpp src/share/vm/memory/referenceType.hpp Webrev: http://cr.openjdk.java.net/~pliden/8079148/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8079148 /Per From stefan.karlsson at oracle.com Thu Apr 30 14:55:25 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 30 Apr 2015 16:55:25 +0200 Subject: RFR(s): 8079148: Fix incorrect include guards In-Reply-To: <5542402D.1050407@oracle.com> References: <5542402D.1050407@oracle.com> Message-ID: <5542425D.5070309@oracle.com> On 2015-04-30 16:46, Per Liden wrote: > Small cleanup of incorrect/misspelled/missing include guards. Affects > the following GC and runtime files: > > src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp > src/share/vm/gc_implementation/g1/evacuationInfo.hpp > src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp > src/share/vm/gc_implementation/g1/g1RootProcessor.hpp > src/share/vm/gc_implementation/g1/heapRegionBounds.inline.hpp > src/share/vm/gc_implementation/shared/objectCountEventSender.hpp > src/share/vm/memory/guardedMemory.hpp > src/share/vm/memory/metaspaceChunkFreeListSummary.hpp > src/share/vm/memory/metaspaceGCThresholdUpdater.hpp > src/share/vm/memory/metaspaceShared.hpp > src/share/vm/memory/metaspaceTracer.hpp > src/share/vm/memory/padded.inline.hpp > src/share/vm/memory/referenceType.hpp > > Webrev: http://cr.openjdk.java.net/~pliden/8079148/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8079148 Looks good. StefanK > > /Per From per.liden at oracle.com Thu Apr 30 14:56:49 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 30 Apr 2015 16:56:49 +0200 Subject: RFR(s): 8079148: Fix incorrect include guards In-Reply-To: <5542425D.5070309@oracle.com> References: <5542402D.1050407@oracle.com> <5542425D.5070309@oracle.com> Message-ID: <554242B1.8060008@oracle.com> On 2015-04-30 16:55, Stefan Karlsson wrote: > On 2015-04-30 16:46, Per Liden wrote: >> Small cleanup of incorrect/misspelled/missing include guards. Affects >> the following GC and runtime files: >> >> src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp >> src/share/vm/gc_implementation/g1/evacuationInfo.hpp >> src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp >> src/share/vm/gc_implementation/g1/g1RootProcessor.hpp >> src/share/vm/gc_implementation/g1/heapRegionBounds.inline.hpp >> src/share/vm/gc_implementation/shared/objectCountEventSender.hpp >> src/share/vm/memory/guardedMemory.hpp >> src/share/vm/memory/metaspaceChunkFreeListSummary.hpp >> src/share/vm/memory/metaspaceGCThresholdUpdater.hpp >> src/share/vm/memory/metaspaceShared.hpp >> src/share/vm/memory/metaspaceTracer.hpp >> src/share/vm/memory/padded.inline.hpp >> src/share/vm/memory/referenceType.hpp >> >> Webrev: http://cr.openjdk.java.net/~pliden/8079148/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8079148 > > Looks good. > > StefanK Thanks Stefan! /Per From erik.helin at oracle.com Thu Apr 30 15:06:22 2015 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 30 Apr 2015 17:06:22 +0200 Subject: RFR(s): 8079148: Fix incorrect include guards In-Reply-To: <5542402D.1050407@oracle.com> References: <5542402D.1050407@oracle.com> Message-ID: <20150430150622.GH23731@ehelin.jrpg.bea.com> On 2015-04-30, Per Liden wrote: > Small cleanup of incorrect/misspelled/missing include guards. Affects the > following GC and runtime files: > > src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp > src/share/vm/gc_implementation/g1/evacuationInfo.hpp > src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp > src/share/vm/gc_implementation/g1/g1RootProcessor.hpp > src/share/vm/gc_implementation/g1/heapRegionBounds.inline.hpp > src/share/vm/gc_implementation/shared/objectCountEventSender.hpp > src/share/vm/memory/guardedMemory.hpp > src/share/vm/memory/metaspaceChunkFreeListSummary.hpp > src/share/vm/memory/metaspaceGCThresholdUpdater.hpp > src/share/vm/memory/metaspaceShared.hpp > src/share/vm/memory/metaspaceTracer.hpp > src/share/vm/memory/padded.inline.hpp > src/share/vm/memory/referenceType.hpp > > Webrev: http://cr.openjdk.java.net/~pliden/8079148/webrev.0/ Looks good, Reviewed. Erik > Bug: https://bugs.openjdk.java.net/browse/JDK-8079148 > > /Per From christian.thalinger at oracle.com Thu Apr 30 15:06:25 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 30 Apr 2015 08:06:25 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <016d01d08352$08376770$18a63650$@apache.org> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <016d01d08352$08376770$18a63650$@apache.org> Message-ID: <83C3A041-F74B-4C2F-9EBF-C45F6839FC0C@oracle.com> > On Apr 30, 2015, at 7:29 AM, Uwe Schindler wrote: > > Hi Kirk, hi Mark, > > the Lucene/Solr/Elasticsearch people still recommend to their users to not use G1GC, although for this type of application (full text search with the requirement for very low response times and no pauses) is a good candidate for G1GC. On the other hand, heap sizes for typical Lucene applications should not be too high, because most of the processing is done on memory mapped files off-heap. So heaps should be at most 1/4 of the physical RAM available, because Lucene relies on the fact that the index files reside in file system cache (too large heaps are contra-productive here). > > See also our recommendations for Apache Solr and Elasticsearch: > http://wiki.apache.org/solr/ShawnHeisey#GC_Tuning_for_Solr > http://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html > > Currently Lucene's indexing sometimes caused serious data corruption with G1GC - leading to data loss, which was mainly caused by some bugs around G1GC and its use of additional memory barriers and the very close interaction with Hotspot, that seemed to broke some optimizations. We had (only in combination with G1GC during our test suites) simple "assert" statements *sometimes* failing that should never fail unless there is a bug in the JVM. In fact there was a bug with asserts triggering when they shouldn?t: https://bugs.openjdk.java.net/browse/JDK-8006960 > > We are aware that Java 8u40 declared G1GC as "production ready", so we are still looking at failures in our extensive testing infrastructure. Indeed, I have no seen any G1GC related problems recently, but that is not necessarily a sign for correctness. > > Uwe > > P.S.: It was nice to meet you last week on JAX! > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Kirk Pepperdine >> Sent: Wednesday, April 29, 2015 9:11 AM >> To: hotspot-dev at openjdk.java.net Source Developers >> Subject: Re: JEP 248: Make G1 the Default Garbage Collector >> >> Hi all, >> >> Is the G1 ready for this? I see many people moving to G1 but also I?m not >> sure that we?ve got the tunable correct. I?ve been sorting through a number >> of recent tuning engagements and my conclusion is that I would like the >> collector to be aggressive about collecting tenured regions at the beginning >> of a JVM?s life time but then become less aggressive over time. The reason is >> the residual waste that I see left behind because certain regions never hit >> the threshold needed to be included in the CSET. But, on aggregate, the >> number of regions in this state does start to retain a significant about of dead >> data. The only way to see the effects is to run regular Full GCs.. which of >> course you don?t really want to do. However, the problem seems to settle >> down a wee bit over time which is why I was thinking that being aggressive >> about what is collected in the early stages of a JVMs life should lead to better >> packing and hence less waste. >> >> Note, I don?t really care about the memory waste, only it?s effect on cycle >> frequencies and pause times. >> >> Sorry but I don?t have anything formal about this as I (and I believe many >> others) are still sorting out what to make of the G1 in prod. Generally the >> overall results are good but sometimes it?s not that way up front and how to >> improve things is sometimes challenging. >> >> On a side note, the move to Tiered in 8 has also caused a bit of grief. >> Metaspace has caused a bit of grief and even parallelStream, which works, >> has come with some interesting side effect. Everyone has been so enamored >> with Lambdas (rightfully so) that the other stuff has been completely >> forgotten and some of it has surprised people. I guess I?ll be submitting a talk >> for J1 on some of the field experience I?ve had with the other stuff. >> >> Regards, >> Kirk >> >> >> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >> >>> New JEP Candidate: http://openjdk.java.net/jeps/248 >>> >>> - Mark > From per.liden at oracle.com Thu Apr 30 15:11:06 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 30 Apr 2015 17:11:06 +0200 Subject: RFR(s): 8079148: Fix incorrect include guards In-Reply-To: <20150430150622.GH23731@ehelin.jrpg.bea.com> References: <5542402D.1050407@oracle.com> <20150430150622.GH23731@ehelin.jrpg.bea.com> Message-ID: <5542460A.2010701@oracle.com> On 2015-04-30 17:06, Erik Helin wrote: > On 2015-04-30, Per Liden wrote: >> Small cleanup of incorrect/misspelled/missing include guards. Affects the >> following GC and runtime files: >> >> src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp >> src/share/vm/gc_implementation/g1/evacuationInfo.hpp >> src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp >> src/share/vm/gc_implementation/g1/g1RootProcessor.hpp >> src/share/vm/gc_implementation/g1/heapRegionBounds.inline.hpp >> src/share/vm/gc_implementation/shared/objectCountEventSender.hpp >> src/share/vm/memory/guardedMemory.hpp >> src/share/vm/memory/metaspaceChunkFreeListSummary.hpp >> src/share/vm/memory/metaspaceGCThresholdUpdater.hpp >> src/share/vm/memory/metaspaceShared.hpp >> src/share/vm/memory/metaspaceTracer.hpp >> src/share/vm/memory/padded.inline.hpp >> src/share/vm/memory/referenceType.hpp >> >> Webrev: http://cr.openjdk.java.net/~pliden/8079148/webrev.0/ > > Looks good, Reviewed. > > Erik Thanks Erik! /Per From kedar.mhaswade at gmail.com Thu Apr 30 16:44:16 2015 From: kedar.mhaswade at gmail.com (kedar mhaswade) Date: Thu, 30 Apr 2015 09:44:16 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <83C3A041-F74B-4C2F-9EBF-C45F6839FC0C@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <016d01d08352$08376770$18a63650$@apache.org> <83C3A041-F74B-4C2F-9EBF-C45F6839FC0C@oracle.com> Message-ID: The JEP says it's slated for default on JDK9, which is at least a year away. People's adoption of JDK9 will happen even more slowly. Should we further delay G1's being the default GC if most of the development occurs on improving G1? On Thu, Apr 30, 2015 at 8:06 AM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > > On Apr 30, 2015, at 7:29 AM, Uwe Schindler > wrote: > > > > Hi Kirk, hi Mark, > > > > the Lucene/Solr/Elasticsearch people still recommend to their users to > not use G1GC, although for this type of application (full text search with > the requirement for very low response times and no pauses) is a good > candidate for G1GC. On the other hand, heap sizes for typical Lucene > applications should not be too high, because most of the processing is done > on memory mapped files off-heap. So heaps should be at most 1/4 of the > physical RAM available, because Lucene relies on the fact that the index > files reside in file system cache (too large heaps are contra-productive > here). > > > > See also our recommendations for Apache Solr and Elasticsearch: > > http://wiki.apache.org/solr/ShawnHeisey#GC_Tuning_for_Solr > > > http://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html > > > > Currently Lucene's indexing sometimes caused serious data corruption > with G1GC - leading to data loss, which was mainly caused by some bugs > around G1GC and its use of additional memory barriers and the very close > interaction with Hotspot, that seemed to broke some optimizations. We had > (only in combination with G1GC during our test suites) simple "assert" > statements *sometimes* failing that should never fail unless there is a bug > in the JVM. > > In fact there was a bug with asserts triggering when they shouldn?t: > > https://bugs.openjdk.java.net/browse/JDK-8006960 < > https://bugs.openjdk.java.net/browse/JDK-8006960> > > > > > We are aware that Java 8u40 declared G1GC as "production ready", so we > are still looking at failures in our extensive testing infrastructure. > Indeed, I have no seen any G1GC related problems recently, but that is not > necessarily a sign for correctness. > > > > Uwe > > > > P.S.: It was nice to meet you last week on JAX! > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > ASF Member, Apache Lucene PMC / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >> Behalf Of Kirk Pepperdine > >> Sent: Wednesday, April 29, 2015 9:11 AM > >> To: hotspot-dev at openjdk.java.net Source Developers > >> Subject: Re: JEP 248: Make G1 the Default Garbage Collector > >> > >> Hi all, > >> > >> Is the G1 ready for this? I see many people moving to G1 but also I?m > not > >> sure that we?ve got the tunable correct. I?ve been sorting through a > number > >> of recent tuning engagements and my conclusion is that I would like the > >> collector to be aggressive about collecting tenured regions at the > beginning > >> of a JVM?s life time but then become less aggressive over time. The > reason is > >> the residual waste that I see left behind because certain regions never > hit > >> the threshold needed to be included in the CSET. But, on aggregate, the > >> number of regions in this state does start to retain a significant > about of dead > >> data. The only way to see the effects is to run regular Full GCs.. > which of > >> course you don?t really want to do. However, the problem seems to settle > >> down a wee bit over time which is why I was thinking that being > aggressive > >> about what is collected in the early stages of a JVMs life should lead > to better > >> packing and hence less waste. > >> > >> Note, I don?t really care about the memory waste, only it?s effect on > cycle > >> frequencies and pause times. > >> > >> Sorry but I don?t have anything formal about this as I (and I believe > many > >> others) are still sorting out what to make of the G1 in prod. Generally > the > >> overall results are good but sometimes it?s not that way up front and > how to > >> improve things is sometimes challenging. > >> > >> On a side note, the move to Tiered in 8 has also caused a bit of grief. > >> Metaspace has caused a bit of grief and even parallelStream, which > works, > >> has come with some interesting side effect. Everyone has been so > enamored > >> with Lambdas (rightfully so) that the other stuff has been completely > >> forgotten and some of it has surprised people. I guess I?ll be > submitting a talk > >> for J1 on some of the field experience I?ve had with the other stuff. > >> > >> Regards, > >> Kirk > >> > >> > >> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: > >> > >>> New JEP Candidate: http://openjdk.java.net/jeps/248 > >>> > >>> - Mark > > > > From john.r.rose at oracle.com Thu Apr 30 19:42:47 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 30 Apr 2015 12:42:47 -0700 Subject: RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol* In-Reply-To: <55380E8B.2060904@oracle.com> References: <552EC286.5000005@oracle.com> <55380E8B.2060904@oracle.com> Message-ID: <804BDA1C-1318-4D27-B9CC-42CB21004AE3@oracle.com> I have a few followup points on this question. Actually, it reminds me a lot of some struggles in Java with object references and their sometimes-broken == operation. Calvin's V2 patch shows that there are about 200 of the risky Symbol*::== operations. It introduces 347 new lines to fix them. With high confidence it finds all the the risky operations (because he started with handles). As you point out, Coleen, our confidence about introducing new bugs is not so good. But I like the patch because it is relatively localized. Though it is not as localized as I had hoped, since 200 is not a small count. Calvin's V1 patch, by comparison, has 1530 new lines, four times more than V2. Nearly all of those are trivial changes from Symbol* to SymbolRef (or maybe SymbolHandle in V3). If we go with that then we invest in more FooHandles instead of Foo* types. The change to a class incrementally increases the cost of working with the code. TempNewSymbol did this, and was painful though worth it (and hard to get right) because it helped us get our reference counting right. Will SymbolHandle be worth it enough? This is a real question, because C++ programmers know that some pointer operations are just tricky, and so they already have a certain amount of defensiveness about expressions like p==q (oh, was that strcmp I wanted?) or p++ (oh, wait, I wanted p->increment()). Given that defensiveness, the incremental benefit of adding more defenses is? debatable. (Hence this debate.) On Apr 22, 2015, at 2:11 PM, Coleen Phillimore wrote: > > Hi Calvin, and fellow JVM engineers, > > I prefer a modification of your first version of this change much better. > > I really don't like this... It feels very unsafe to me. I don't know how to run any tools to make sure I don't break this! Honestly this seems wrong and there are too many places that compare Symbols even though the changeset is smaller. > > We triage bugs in the runtime group weekly with SQE. This change will cause bugs that have various symptoms and will be hard to trace to this root cause. The bugs will mostly land in the Runtime component of the JVM because in fact, the Symbol class is mostly used by the runtime component of the JVM. In addition, running internal tools to find these errors *monthly* is too late and running them individually adds overhead and friction to making changes in the JVM. More overhead is the last thing we need! I'm talking with the Parfait folks today about whether their tools can be configured to diagnose suspicious uses of Symbol*::==, and also things like char*::== and Foo*::+(int) and Foo*::-(Foo*). I think they can. Would that help, say, if we had nightly scans to find problems that escape programmer diligence? The programmer diligence is always the first line of defense though: There is no excuse for not knowing how C pointers work. > Having to use ->equals() is clunky too. It's clunky but in thousands fewer places, if you agree with me that SymbolHandle is clunky also. > For better or worse, the JVM is written in C++ which has operator overloading for these purposes. Modern C++ programming already avoids raw pointers in favore of smart pointers! This, and the previous point about access to tools, is the strongest point in your argument, IMO. > The JVM code has historically avoided raw metadata pointers, first because of PermGen but now because the values pointed to have semantics that we want to encapsulate. I admit that it was nice using raw pointers and brought all of us back to a simpler day but they're not safe in general for this sort of system software. > > In the JVM code, we have Handles: > > 1. oops => Handle because they may move with garbage collection. > 2. Method* => methodHandle because they may get deallocated with class redefinition (same for Klass eventually) > 3. Symbol* => SymbolHandle because pointer equality isn't sufficient to ensure equality > > The other objection for Calvin's first change was that it's a lot of code changed. But there's a lot of other large code changes going forward at this time. This is the simplest of large changes, ie. simple renaming. This feature is needed for others going forward to support our important customers. This amount of code change is justified. > > Embedded in this mail, if you've read this far, is a suggestion to rename SymbolRef (a name I hate) to SymbolHandle. Because that's what it now is. I am leaning towards agreeing, despite the thousands of lines of noisy changes required, because we won't need tooling support if we bite the bullet and dump the Symbol pointers. But I keep coming back to this: Where does it stop? How many of our object classes need auxiliary handle classes? Are all of our pointer types just bugs waiting to happen? If so, why are we fixating on Symbol*::==? If not, why is Symbol*::== such a uniquely bad problem? Thanks, Coleen. ? John > Thanks, > Coleen > > > On 4/15/15, 3:56 PM, Calvin Cheung wrote: >> Please review this second version of the fix. >> >> This version has 2 new functions (equals() and not_equals()) in the Symbol class. >> It replaces the Symbol* == and != comparisons with those 2 function calls. From dawid.weiss at gmail.com Thu Apr 30 19:43:53 2015 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 30 Apr 2015 21:43:53 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <83C3A041-F74B-4C2F-9EBF-C45F6839FC0C@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <016d01d08352$08376770$18a63650$@apache.org> <83C3A041-F74B-4C2F-9EBF-C45F6839FC0C@oracle.com> Message-ID: Hi folks, I'm the guy who tried to get to the bottom of the G1GC byteslice assert issue. It's not a false assert, it's a true miscompilation that somehow misses variable update. I know because I live-debugged it on assembly level... I also tried to help Vladimir Kozlov to pinpoint the issue but without much success. The buggy scenario is really fragile, not always reproducible and the compiled method is huge. Life. I haven't tried with any recent Java release. I will try to, time permitting -- it's my id?e fixe to find out what's happening. Dawid