- ppc-aix-port-dev - openjdk.org

Re: JEP 163: Enable NUMA Mode by Default When Appropriate
by Gustavo Romero 27 Aug '18

27 Aug '18

Hi Swati, On 08/27/2018 09:10 AM, Swati Sharma wrote: > I was going through this JEP 163: Enable NUMA Mode by Default When Appropriate(http://openjdk.java.net/jeps/163). > > Can we make UseNUMA flag by default ON after detecting that if process runs on multiple NUMA nodes.So after that user don't need to specify the UseNUMA flag and JVM will auto detect and switch ON the flag. The last time I tested SPECjvm with +UseNUMA I recall a slight better performance on PPC64 and no regressions. However I recall that IBM performance team reported at least one regression when using +UseNUMA for a Apache Hadoop YARN workload. They also reported that they were able to get better results when manually tuning the JVM using a numactl approach, for instance. At that occasion they recorded ~24% of numa misses when using +UseNUMA whilst only ~4% when using their numactl approach. That was on OpenJDK 8, but I understand based on changes from 8 to 12 that it didn't change much. So I'm not convinced that the currently +UseNUMA will help in the majority of cases and won't hurt badly some important workload for us. That JEP was create a long time ago (2012) and was updated on 2016, so _maybe_ community lost interest on that as the OS NUMA balancers evolved over the years, helping most workloads / scenarios. So in summing up, at least from a PPC64 perspective, I vouch for not enabling -XX:+UseNUMA by default at the moment without further investigation. I also see the JEP as "draft" so I CC:ed Jesper in case he has any insights about the history and the current / future state of that JEP. Anyway, others might want to comment on that, so let's wait for further comments. > Note : If we can then I can provide the implementaion for this JEP. BTW, https://bugs.openjdk.java.net/browse/JDK-7179517 mentions a patch contributed by Eric, probably the one discussed in this thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004691.html but it looks like that change never got pushed to 8. Best regards, Gustavo

1 0

Re: Using C++11+ in hotspot
by Martin Buchholz 11 Aug '18

11 Aug '18

OK, it looks like -fno-strict-aliasing is here to stay. Casting freely between pointers to different types is pervasive in the source code, and there's insufficient discipline in the culture to try to fix it. And I'm not volunteering. static void pd_arrayof_conjoint_jlongs(const HeapWord* from, HeapWord* to, size_t count) { #ifdef AMD64 _Copy_arrayof_conjoint_jlongs(from, to, count); #else pd_conjoint_jlongs_atomic((const jlong*)from, (jlong*)to, count); #endif // AMD64 } static void pd_arrayof_conjoint_oops(const HeapWord* from, HeapWord* to, size_t count) { #ifdef AMD64 assert(BytesPerLong == BytesPerOop, "jlongs and oops must be the same size"); _Copy_arrayof_conjoint_jlongs(from, to, count); #else pd_conjoint_oops_atomic((const oop*)from, (oop*)to, count); #endif // AMD64 } On Fri, Aug 10, 2018 at 5:59 AM, Andrew Haley <aph(a)redhat.com> wrote: > On 08/08/2018 08:51 PM, Martin Buchholz wrote: > > I'd like to see hotspot stop using the -fno-strict-aliasing curtch, > > replacing it with union and/or may_alias, but this is a serious > investment. > > It's a serious investment, and we'd risk breaking stuff. At least the > entire > heap would have to be an array with elements which are a union of all of > the > possible types, and there'd be a byte array overlaid on top of that. It > would > not be pretty.

1 0

Re: Using C++11+ in hotspot
by Martin Buchholz 09 Aug '18

09 Aug '18

On Fri, Aug 3, 2018 at 3:14 PM, Mikael Vidstedt <mikael.vidstedt(a)oracle.com> wrote: > > Martin Buchholz suggested the topic and Mikael signed up to lead the > session. Martin gave an introduction. He had observed some issues recently > (“impossible null pointer exceptions”) which after investigation turned out > to be caused by a toolchain upgrade and in turn revealed the fact that some > code in hotspot requires atomicity but does not make this requirement very > explicit and in the end assumes that the C++ compiler will produce suitable > code to guarantee atomicity. Martin also observed that (on linux) hotspot > is compiled targeting the c++98 standard, which is old enough to not even > mention the concept of threads. Mikael also added that for extra fun the > story is different on different platforms and toolchains. > I was surprised to hear that IBM AIX xlc compilers might not support C++11 - it's not the IBM way. But from reading the tea leaves at https://www-01.ibm.com/support/docview.wss?uid=swg27007322&aid=1 I concluded that IBM is a Linux company now! Even for IBM, AIX is a niche legacy platform and they just couldn't keep up with the evolution of C++ (who can blame them?). Meanwhile gcc is available for AIX and can/should be used to build openjdk. Has anyone tried? Here's one example of code that actually did go wrong with Google's latest internal toolchain, because the copy was not in fact word-atomic. Thanks to whoever added the comment long ago. static inline void copy_table(address* from, address* to, int size) { // Copy non-overlapping tables. The copy has to occur word wise for MT safety. while (size-- > 0) *to++ = *from++; } Recommendation: target C++11 for jdk12; use gcc to build openjdk on AIX.

3 4

Re: Using C++11+ in hotspot
by Martin Buchholz 08 Aug '18

08 Aug '18

On Wed, Aug 8, 2018 at 7:02 AM, Andrew Haley <aph(a)redhat.com> wrote: > On 08/08/2018 07:51 AM, Erik Osterlund wrote: > > > So basically, my answer to your question is: no we do not and should > > not care. And that message ought to be documented somewhere to > > remove all uncertainty and inconsistency around that reoccuring > > question. > > That sounds sensible. I guess that if we use -fno-strict-aliasing > then we can cast *T to *atomic<T>. I can ask on gcc@ to be sure. > A difficulty might arise if the representation of atomic<T> is different from T, as might happen if the arch has no atomic instructions for a type of that size and so a lock must be allocated somewhere. I don't know how gcc's atomic builtins deal with that problem.

2 1

Re: Using C++11+ in hotspot
by Erik Osterlund 08 Aug '18

08 Aug '18

Hi Andrew, This question is very important and deserves highlighting. I have been thinking for some time that there ought to be a document describing ”allowed C++ sins in HotSpot”. And I would put aliasing rules at the top of said document. Today we rely on compilers being tamed not to be tempted to exploit aliasing rules (e.g. -fno-strict-aliasing). The reliance on this in our code base goes so deep that we will arguably never be able to stop relying on it. And why would we want to, more than to find more interesting ways of tormenting ourselves? This is something we should embrace. By embracing this and putting it in a document that this is allowed, we would have the following benefits: 1) All reoccuring discussions whether we should or should not care about aliasing would come to quick ends, and decisions would not have to be taken (inconsistently) over and over again on a case by case basis. 2) Porters would know what requirements HotSpot has on compiler taming to safely run HotSpot. If they can not tame the compiler to ignore aliasing rules, then they can not use HotSpot. 3) By embracing aliasing violations as an allowed C++ sin, time will be saved for everyone involved, not having to invent complicated solutions circumventing it. Spending time honoring these rules seems like a waste of time and resources unless we fully commit to removing all such behaviour and hence can flip the compiler switches and hence remove our reliance on this. And we will never be able to do that. Nor should we if we could. 4) It seems like the problem being discussed in this thread before I hijacked it would have simple solutions. So basically, my answer to your question is: no we do not and should not care. And that message ought to be documented somewhere to remove all uncertainty and inconsistency around that reoccuring question. Thanks, /Erik > On 7 Aug 2018, at 16:00, Andrew Haley <aph(a)redhat.com> wrote: > >> On 08/07/2018 06:48 AM, John Rose wrote: >>> On Aug 6, 2018, at 9:54 PM, Martin Buchholz <martinrb(a)google.com> wrote: >>> >>> I don't know what is actually being copied here, but can't the underlying >>> type be atomic<address*> ? >> >> Yes, if we are allowed to cast some random sequence of metadata >> words to atomic<address*>[]. > > We're not. Well, we sort-of are because we use -fno-strict-aliasing, but that's > not standard C++11. Do we care? :-) > > GCC builtins do what we need when we're using GCC, but then we don't need C++11. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. <https://www.redhat.com> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

2 1

Re: Using C++11+ in hotspot
by Martin Buchholz 07 Aug '18

07 Aug '18

On Mon, Aug 6, 2018 at 1:16 AM, Andrew Haley <aph(a)redhat.com> wrote: > On 08/05/2018 04:30 PM, Martin Buchholz wrote: > > Here's one example of code that actually did go wrong with Google's > latest > > internal toolchain, because the copy was not in fact word-atomic. Thanks > > to whoever added the comment long ago. > > > > static inline void copy_table(address* from, address* to, int size) { > > // Copy non-overlapping tables. The copy has to occur word wise for MT > > safety. > > while (size-- > 0) *to++ = *from++; > > } > > > > Recommendation: target C++11 for jdk12; > I don't think that helps. There's no legal way AFAICS to force an atomic > access to non-atomic types in C++11. > Ohh... perhaps that's the idea behind atomic_ref https://en.cppreference.com/w/cpp/atomic/atomic_ref we only have to wait one more decade for that to become available. I don't know what is actually being copied here, but can't the underlying type be atomic<address*> ?

2 1

Re: Using C++11+ in hotspot
by David Holmes 07 Aug '18

07 Aug '18

On 6/08/2018 6:16 PM, Andrew Haley wrote: > On 08/05/2018 04:30 PM, Martin Buchholz wrote: >> Here's one example of code that actually did go wrong with Google's latest >> internal toolchain, because the copy was not in fact word-atomic. Thanks >> to whoever added the comment long ago. >> >> static inline void copy_table(address* from, address* to, int size) { >> // Copy non-overlapping tables. The copy has to occur word wise for MT >> safety. >> while (size-- > 0) *to++ = *from++; >> } >> >> Recommendation: target C++11 for jdk12; > I don't think that helps. There's no legal way AFAICS to force an atomic > access to non-atomic types in C++11. I would agree. We implicitly rely on compilers doing the obvious/natural thing as long as the variables are suitable aligned. We're outside the language here with regards to "atomic access".** David

1 0

Base64 encoding algorithm enhancements for ppc64 ?
by Baesken, Matthias 24 Jul '18

24 Jul '18

Hello, when looking into some jtreg test issues I came across that for x86_64 some enhancements to Base64 encoding were contributed recently . Please see : JDK-8205528<https://bugs.openjdk.java.net/browse/JDK-8205528> : Base64 encoding algorithm using AVX512 instructions https://bugs.openjdk.java.net/browse/JDK-8205528 http://hg.openjdk.java.net/jdk/jdk/rev/480a96a43b62 Do we have something similar for ppc64 ? If not do you think it's worth doing it for this architecture as well ? Best regards , Matthias

2 2

RFR(xs): 8205578: jtreg: Fix failing TestRTMAbortRatio on PPC64
by Gustavo Romero 18 Jul '18

18 Jul '18

Hi, Could the following simple change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205578 webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/ Currently native method pageSize() is used to cause deliberate transactional aborts. However in test TestRTMAbortRatio pageSize() is not marked to be compilable and as a consequence it's never called through the code path of SharedRuntime::generate_native_wrapper(). As that code path is never exercised no 'tabort' on JNI call is executed and the test fails on Power because of fewer aborts than expected by the test. I can't say for sure why that test is getting the correct number of aborts on x86. Nonetheless I can confirm that even on x86 the aborts do not come from the native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). I suspect the aborts on x86 are occurring a bit latter when the native function is called and a "Far Call" is executed in the native method by chance and not in a controlled way. As far as I know there is no way to inspect the exact address when a transaction failed on Intel as it's possible on Power. Anyway, marking pageSize() as compilable does not cause any regression on Intel (at the same time it starts to exercise the generate_native_wrapper code path) and makes the test pass on Power as expected. So it fixes the following test on Power: +Passed: compiler/rtm/locking/TestRTMAbortRatio.java Thank you and best regards, Gustavo

3 6

RFR(xs): 8205390: jtreg: Fix failing TestRTMSpinLoopCount on PPC64
by Gustavo Romero 18 Jul '18

18 Jul '18

Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205390 webrev: http://cr.openjdk.java.net/~gromero/8205390/v1/ It adds a new throttling sequence for PPC64 because the last value on current sequence does not fit on PPC64. By using the new sequence the following test is fixed: +Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java Thank you and best regards, Gustavo

3 5