RE: RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames
Thank you very much, Dmitry for the review. I have created a new webrev with a launchJStack() method in BasicLauncherTest.java. The exit value is 0, despite the error -- so that does not help. Please do take a look at the modified webrev: http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.01/ Thanks, -Jini. > -Original Message- > From: Dmitry Samersoff > Sent: Wednesday, August 10, 2016 1:42 PM > To: Jini Susan George; serviceability-dev@openjdk.java.net; Lindenmaier, > Goetz > Subject: Re: RFR: JDK-8163143: illegal bci error with interpreted frames in > SA due to mirror being stored in interpreted frames > > Jini, > > Code changes looks good for me. > > CC'in Goetz for PPC changes. > > > BasicLauncherTest.java: > > I'm not sure we need two extra parameters to launch() just to check for > jstack Assertion Failure. > > Please either create a separate launchJStack method or just check exit > code of jhsdb jstack. > > -Dmitry > > On 2016-08-10 10:10, Jini Susan George wrote: > > Hi all, > > > > > > > > Please do review the changes for the SA defect: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8163143 > > > > > > > > The webrev is at: > > > > > > > > http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.00/ > > > > > > > > Need testing with PPC64 for this. I have implemented the changes but > > have not tested on PPC64. > > > > > > > > Thank you, > > > > - Jini Susan George > > > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources.
Re: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap
Hi Yasumasa, Adding in GC folk. I agree with the need to override the printOn method, but can't comment on the details of what you are actually printing. Thanks, David On 10/08/2016 10:20 PM, Yasumasa Suenaga wrote: Hi all, When I chose "Heap Parameters" menu in HSDB, I got following value: Heap Parameters: unknown subtype of CollectedHeap @ 0x7f4d4c030510 (0x0006c6e0,0x0007c000) I think it should not be "unknown subtype". This value is shown by sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). This method is overrided in ParallelScavengeHeap and GenCollectedHeap. However, G1CollectedHeap does not override. I think G1CollectedHeap should override this method. I uploaded a webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa
Re: RFR: JDK-8163580: Cannot get Monitor Cache Dump in HSDB
Hi Yasumasa, On 10/08/2016 10:18 PM, Yasumasa Suenaga wrote: Hi all, When I chose "Monitor Cache Dump" menu in HSDB, I saw an Exception as below: Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError at sun.jvm.hotspot.ui.MonitorCacheDumpPanel.dumpOn(jdk.hotspot.agent@9-internal/MonitorCacheDumpPanel.java:92) at sun.jvm.hotspot.ui.MonitorCacheDumpPanel.(jdk.hotspot.agent@9-internal/MonitorCacheDumpPanel.java:59) at sun.jvm.hotspot.HSDB.showMonitorCacheDumpPanel(jdk.hotspot.agent@9-internal/HSDB.java:1534) : Caused by: java.lang.ArithmeticException: / by zero at sun.jvm.hotspot.runtime.ObjectSynchronizer.initialize(jdk.hotspot.agent@9-internal/ObjectSynchronizer.java:55) : ObjectSynchronizer finds DEFAULT_CACHE_LINE_SIZE value from VMStructs, however, it is not contained. This value is added by JDK-8049737. DEFAULT_CACHE_LINE_SIZE is macro. When we set macro value to VMStructs, we have to use declare_preprocessor_constant macro. However this change uses declare_constant macro. It is the cause of this exception. I uploaded a webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8163580/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. I agree with your analysis and fix. I will sponsor this under the 'trivial change' rules. Thanks, David Thanks, Yasumasa
Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly
On 10/08/2016 8:46 PM, Amit Sapre wrote: Hello, Well for some reason, unknown to me, JNI code checker is not complaining for exception thrown by SetObjectArrayElement. It complains for any pending exceptions before calling SetObjectArrayElement. I have added exceptions checks after calling SetObjectArrayElement. The updated changes are in this webrev. http://cr.openjdk.java.net/~sballal/sponsorship/8162530/webrev.02/ This looks fine to me. Thanks, David Thanks, Amit -Original Message- From: David Holmes Sent: Wednesday, August 03, 2016 5:50 AM To: Amit Sapre; serviceability-dev Subject: Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly Hi Amit, On 2/08/2016 7:49 PM, Amit Sapre wrote: Hello, I have made changes as David suggested. Here is the new webrev link. http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/ If the changes are required to pass a JNI code checker then you will also need to check for exceptions from SetObjectArrayElement. While ArrayStoreException should not be possible in this code, I can't tell for certain that the passed in arrays are ensured to have the required lengths. Thanks, David Thanks, Amit -Original Message- From: David Holmes Sent: Monday, August 01, 2016 12:33 PM To: Amit Sapre; serviceability-dev Subject: Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly Hi Amit, On 1/08/2016 4:10 PM, Amit Sapre wrote: Hello, Please review JNI exception handling related changes. Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ Sorry but that's wrong way to fix this. We should never just blindly clear exceptions and continue as if they never happened. If an exception is pending after one of these JNI calls the method should return immediately and allow the exception to propagate to the java code. Thanks, David Thanks, Amit
RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap
Hi all, When I chose "Heap Parameters" menu in HSDB, I got following value: Heap Parameters: unknown subtype of CollectedHeap @ 0x7f4d4c030510 (0x0006c6e0,0x0007c000) I think it should not be "unknown subtype". This value is shown by sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). This method is overrided in ParallelScavengeHeap and GenCollectedHeap. However, G1CollectedHeap does not override. I think G1CollectedHeap should override this method. I uploaded a webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa
RFR: JDK-8163580: Cannot get Monitor Cache Dump in HSDB
Hi all, When I chose "Monitor Cache Dump" menu in HSDB, I saw an Exception as below: Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError at sun.jvm.hotspot.ui.MonitorCacheDumpPanel.dumpOn(jdk.hotspot.agent@9-internal/MonitorCacheDumpPanel.java:92) at sun.jvm.hotspot.ui.MonitorCacheDumpPanel.(jdk.hotspot.agent@9-internal/MonitorCacheDumpPanel.java:59) at sun.jvm.hotspot.HSDB.showMonitorCacheDumpPanel(jdk.hotspot.agent@9-internal/HSDB.java:1534) : Caused by: java.lang.ArithmeticException: / by zero at sun.jvm.hotspot.runtime.ObjectSynchronizer.initialize(jdk.hotspot.agent@9-internal/ObjectSynchronizer.java:55) : ObjectSynchronizer finds DEFAULT_CACHE_LINE_SIZE value from VMStructs, however, it is not contained. This value is added by JDK-8049737. DEFAULT_CACHE_LINE_SIZE is macro. When we set macro value to VMStructs, we have to use declare_preprocessor_constant macro. However this change uses declare_constant macro. It is the cause of this exception. I uploaded a webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8163580/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa
RE: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly
Hello, Well for some reason, unknown to me, JNI code checker is not complaining for exception thrown by SetObjectArrayElement. It complains for any pending exceptions before calling SetObjectArrayElement. I have added exceptions checks after calling SetObjectArrayElement. The updated changes are in this webrev. http://cr.openjdk.java.net/~sballal/sponsorship/8162530/webrev.02/ Thanks, Amit -Original Message- From: David Holmes Sent: Wednesday, August 03, 2016 5:50 AM To: Amit Sapre; serviceability-dev Subject: Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly Hi Amit, On 2/08/2016 7:49 PM, Amit Sapre wrote: > Hello, > I have made changes as David suggested. > > Here is the new webrev link. > http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/ If the changes are required to pass a JNI code checker then you will also need to check for exceptions from SetObjectArrayElement. While ArrayStoreException should not be possible in this code, I can't tell for certain that the passed in arrays are ensured to have the required lengths. Thanks, David > Thanks, > Amit > > -Original Message- > From: David Holmes > Sent: Monday, August 01, 2016 12:33 PM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR : JDK-8162530 : > src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c > doesn't handle JNI exceptions properly > > Hi Amit, > > On 1/08/2016 4:10 PM, Amit Sapre wrote: >> Hello, >> >> >> >> Please review JNI exception handling related changes. >> >> Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 >> >> Webrev : >> http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ > > Sorry but that's wrong way to fix this. We should never just blindly clear > exceptions and continue as if they never happened. If an exception is pending > after one of these JNI calls the method should return immediately and allow > the exception to propagate to the java code. > > Thanks, > David > >> >> >> Thanks, >> >> Amit >>
Re: RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames
Jini, Code changes looks good for me. CC'in Goetz for PPC changes. BasicLauncherTest.java: I'm not sure we need two extra parameters to launch() just to check for jstack Assertion Failure. Please either create a separate launchJStack method or just check exit code of jhsdb jstack. -Dmitry On 2016-08-10 10:10, Jini Susan George wrote: > Hi all, > > > > Please do review the changes for the SA defect: > > > > https://bugs.openjdk.java.net/browse/JDK-8163143 > > > > The webrev is at: > > > > http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.00/ > > > > Need testing with PPC64 for this. I have implemented the changes but > have not tested on PPC64. > > > > Thank you, > > - Jini Susan George > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout.
Sharath, As soon as you request a heap dump of LingeredApp, LingeredApp should contains the object with extended characters in it's name. So please: 1. Inherit LingeredApp (See LingeredAppWithDeadlock as an example) and add public static int \u00CB = 1; 2. Copy BasicLauncherTest to HeapDumpWitExtCharsTest.java and change it according to you needs (i.e. remove everything but heapDumpTest) 3. Remove Test8028623.java -Dmitry On 2016-08-08 12:37, Sharath Ballal wrote: > Hello, > > Pls review the following fix for modifying the testcase > jmap-hashcode/Test8028623.java to use LingeredApp. > > > > http://cr.openjdk.java.net/~sballal/8163346/webrev.00/ > > > > Link to bug: https://bugs.openjdk.java.net/browse/JDK-8163346 > > > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames
Hi all, Please do review the changes for the SA defect: https://bugs.openjdk.java.net/browse/JDK-8163143 The webrev is at: http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.00/ Need testing with PPC64 for this. I have implemented the changes but have not tested on PPC64. Thank you, - Jini Susan George
