From matthias.baesken at sap.com Wed Mar 9 17:01:07 2016 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 9 Mar 2016 17:01:07 +0000 Subject: jdk9 : forcing inlining in src/share/vm/oops/instanceKlass.inline.hpp for xlc Message-ID: <63dad1e5ed7945439306b95a7ac48571@DEWDFE13DE02.global.corp.sap> Hello , CR 8075955: "Replace the macro based implementation of oop_oop_iterate with a template based solution" changed src/share/vm/oops/instanceKlass.inline.hpp and replaced macro based oop iteration by templates. For performance reason, the change (and a follow up change for Oracle Studio) introduced forcing of inlining for some places in src/share/vm/oops/instanceKlass.inline.hpp , see http://hg.openjdk.java.net/jdk9/dev/hotspot/file/797e6aac6d53/src/share/vm/oops/instanceKlass.inline.hpp .... // The iteration over the oops in objects is a hot path in the GC code. // By force inlining the following functions, we get similar GC performance // as the previous macro based implementation. #ifdef TARGET_COMPILER_visCPP #define INLINE __forceinline #elif defined(TARGET_COMPILER_sparcWorks) #define INLINE __attribute__((always_inline)) #else #define INLINE inline #endif .... (which is compiler dependent) Should we do this for the AIX port too ? http://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm.xlc121.aix.doc/language_ref/function_attributes.html?lang=en describes the function attributes of xlc which can be used. Diff to instanceKlass.inline.hpp : 43,44d42 < #elif defined(TARGET_COMPILER_xlc) < #define INLINE __attribute__((always_inline)) Regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Mar 10 08:12:53 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Mar 2016 09:12:53 +0100 Subject: jdk9 : forcing inlining in src/share/vm/oops/instanceKlass.inline.hpp for xlc In-Reply-To: <63dad1e5ed7945439306b95a7ac48571@DEWDFE13DE02.global.corp.sap> References: <63dad1e5ed7945439306b95a7ac48571@DEWDFE13DE02.global.corp.sap> Message-ID: Hi Matthias, thanks for reporting this. I've opened "8151593: AIX: add support for xlC 'always_inline' compiler attribute" (https://bugs.openjdk.java.net/browse/JDK-8151593) to track this issue. Regards, Volker On Wed, Mar 9, 2016 at 6:01 PM, Baesken, Matthias wrote: > Hello , > > CR 8075955: "Replace the macro based implementation of oop_oop_iterate with > a template based solution" > > > > changed src/share/vm/oops/instanceKlass.inline.hpp > > > > and replaced macro based oop iteration by templates. > > For performance reason, the change (and a follow up change for Oracle > Studio) introduced forcing of inlining for some places in > > src/share/vm/oops/instanceKlass.inline.hpp , see > > > > > > http://hg.openjdk.java.net/jdk9/dev/hotspot/file/797e6aac6d53/src/share/vm/oops/instanceKlass.inline.hpp > > > > .... > > // The iteration over the oops in objects is a hot path in the GC code. > > // By force inlining the following functions, we get similar GC performance > > // as the previous macro based implementation. > > #ifdef TARGET_COMPILER_visCPP > > #define INLINE __forceinline > > #elif defined(TARGET_COMPILER_sparcWorks) > > #define INLINE __attribute__((always_inline)) > > #else > > #define INLINE inline > > #endif > > .... > > > > (which is compiler dependent) > > Should we do this for the AIX port too ? > > > > http://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm.xlc121.aix.doc/language_ref/function_attributes.html?lang=en > > > > > > describes the function attributes of xlc which can be used. > > Diff to instanceKlass.inline.hpp : > > > > 43,44d42 > > < #elif defined(TARGET_COMPILER_xlc) > > < #define INLINE __attribute__((always_inline)) > > > > > > Regards, Matthias From gromero at linux.vnet.ibm.com Thu Mar 17 14:00:59 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 17 Mar 2016 11:00:59 -0300 Subject: JVM 24.95 SIGSEGV on C2 Compiler Thread Message-ID: <56EAB89B.9050206@linux.vnet.ibm.com> Hi Martin, I'm facing a problem with a JVM 24.95 when running an application. However it's being hard to reproduce it, ie many times C2 will optimize the method fine and the application terminates fine. Just after many complete runs, one of them will crash. Apparently it is related to https://bugs.openjdk.java.net/browse/JDK-7068051 bug, but it was fixed in hs22 and as I could not isolate it on PPC64, I can't tell if it still exists upstream on PPC64. Do you have any clue on how to isolate/debug this problem? Hotspot error log: http://hastebin.com/raw/pepajuwepu Backtrace from the thread that caused the segfault: http://hastebin.com/raw/zirelokuto Thank you! Best regards, Gustavo From tobias.hartmann at oracle.com Thu Mar 17 14:30:43 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 17 Mar 2016 15:30:43 +0100 Subject: JVM 24.95 SIGSEGV on C2 Compiler Thread In-Reply-To: <56EAB89B.9050206@linux.vnet.ibm.com> References: <56EAB89B.9050206@linux.vnet.ibm.com> Message-ID: <56EABF93.2070707@oracle.com> Hi Gustavo, just a wild guess, but this could be one of https://bugs.openjdk.java.net/browse/JDK-6675699 https://bugs.openjdk.java.net/browse/JDK-8027388 Both were not backported to 7. Did you try to reproduce this with 8? Best regards, Tobias On 17.03.2016 15:00, Gustavo Romero wrote: > Hi Martin, > > I'm facing a problem with a JVM 24.95 when running an application. > However it's being hard to reproduce it, ie many times C2 will > optimize the method fine and the application terminates fine. Just > after many complete runs, one of them will crash. Apparently it is > related to https://bugs.openjdk.java.net/browse/JDK-7068051 bug, > but it was fixed in hs22 and as I could not isolate it on PPC64, > I can't tell if it still exists upstream on PPC64. > > Do you have any clue on how to isolate/debug this problem? > > Hotspot error log: > http://hastebin.com/raw/pepajuwepu > > Backtrace from the thread that caused the segfault: > http://hastebin.com/raw/zirelokuto > > Thank you! > > Best regards, > Gustavo > From gromero at linux.vnet.ibm.com Thu Mar 17 15:10:35 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 17 Mar 2016 12:10:35 -0300 Subject: JVM 24.95 SIGSEGV on C2 Compiler Thread In-Reply-To: <56EABF93.2070707@oracle.com> References: <56EAB89B.9050206@linux.vnet.ibm.com> <56EABF93.2070707@oracle.com> Message-ID: <56EAC8EB.9020609@linux.vnet.ibm.com> Hi Tobias, I'll try to reproduce it with 8 on PPC64 and let you know about the result. Thank you. Regards, Gustavo On 17-03-2016 11:30, Tobias Hartmann wrote: > Hi Gustavo, > > just a wild guess, but this could be one of > https://bugs.openjdk.java.net/browse/JDK-6675699 > https://bugs.openjdk.java.net/browse/JDK-8027388 > > Both were not backported to 7. Did you try to reproduce this with 8? > > Best regards, > Tobias > > On 17.03.2016 15:00, Gustavo Romero wrote: >> Hi Martin, >> >> I'm facing a problem with a JVM 24.95 when running an application. >> However it's being hard to reproduce it, ie many times C2 will >> optimize the method fine and the application terminates fine. Just >> after many complete runs, one of them will crash. Apparently it is >> related to https://bugs.openjdk.java.net/browse/JDK-7068051 bug, >> but it was fixed in hs22 and as I could not isolate it on PPC64, >> I can't tell if it still exists upstream on PPC64. >> >> Do you have any clue on how to isolate/debug this problem? >> >> Hotspot error log: >> http://hastebin.com/raw/pepajuwepu >> >> Backtrace from the thread that caused the segfault: >> http://hastebin.com/raw/zirelokuto >> >> Thank you! >> >> Best regards, >> Gustavo >> >