RFR: JDK-8191324: SA cleanup -- part 2

Hello, Here's requesting reviews for some SA code cleanup. ID: https://bugs.openjdk.java.net/browse/JDK-8191324 Webrev: http://cr.openjdk.java.net/~jgeorge/8191324/webrev.00/index.html The changes here are primarily to: 1. Remove unused IA64 SA code. 2. Make changes to avoid error-prone

Re: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler

Hi Sharath, Since StartFlightRecording and UseAppCDS are closed only flags currently, these would fail for testing with open only builds. It might be prudent to remove the checking of these flags too. Other than this, the changes look good. Thank you, Jini. On 11/20/2017 2:54 PM, Sharath

Re: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type

Thank you very much, David. - Jini. On 11/16/2017 8:16 AM, David Holmes wrote: On 15/11/2017 3:27 PM, Jini George wrote: Thank you, Sharath and David. The revised webrev after addressing the comments are at: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.03/ Please put all

Re: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type

int exitValue = p.exitValue(); You may want to add few more strings in the defaultOutputStrings. Thanks, Sharath (not a reviewer) -Original Message- From: Jini George Sent: Tuesday, November 14, 2017 2:19 PM To: David Holmes; serviceability-dev@openjdk.java.net Subject: Re: RFR

Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands

Hi Sharath, Your changes look fine to me. One nit: http://cr.openjdk.java.net/~sballal/8190198/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.html * You should be able to remove the following line: 26 import java.util.HashMap; Thanks, Jini (Not a (R)eviewer). On

Re: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type

hangs due to the output stream buffer not being consumed. (Thanks, Sharath!) Thanks, Jini. On 11/6/2017 12:58 PM, David Holmes wrote: Hi Jini, On 3/11/2017 8:51 PM, Jini George wrote: Here is the updated webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ I have made changes

Re: PING: RFR: 8185796: jstack and clhsdb jstack should show lock objects

how all locks like a my first webrev [1]. webrev.04 is implemented to follow HotSpot implementation. Thanks, Yasumasa [1] http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.00/ On 2017/11/09 2:19, Jini George wrote: Hi Yasumasa, Your changes look good to me overall. Some nits: *

Re: PING: RFR: 8185796: jstack and clhsdb jstack should show lock objects

sdb jstack` and jstack command on `jhsdb clhsdb`. Yasumasa On 2017/08/24 18:01, Jini George wrote: Apologize for the late reply, Yasumasa. I think so, but I guess it is difficult. For example, test for CLHSDB command is provided as test/serviceability/sa/TestPrintMdo.java . Bu

Re: RFR: SA: JDK-8189798: SA cleanup - part 1

getting and storing the __value__ of the Field rather than the Field itself. Hence, I feel it might make more sense to not have 'Field' in this name. Thanks, Jini. Rest of the changes look ok. Thanks, Sharath (not a reviewer) -Original Message----- From: Jini George Sent: Thursday, Novemb

Re: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type

Here is the updated webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ I have made changes to validate the test results of each command separately, done away with the asserts and have added some more comments. Thank you, Jini. On 10/31/2017 12:32 PM, Jini George wrote: Thank

Re: RFR: SA: JDK-8189798: SA cleanup - part 1

Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: Thank you very much, Serguei. -Jini. On 10/27/2017 2:22 PM, serguei.spit...@oracle.com wrote: Hi Jini, The fix looks good to me. Thanks, Serguei On 10/24/17 00:31, Jini George

Re: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type

utput.contains("type G1CollectedHeap CollectedHeap")); Same comment about assuming G1. Thanks, David -- On 30/10/2017 1:44 PM, Jini George wrote: Hello, We have been working on writing sanity tests for the various jhsdb clhsdb commands of the SA to improve the robustness of the SA. As a

RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type

Hello, We have been working on writing sanity tests for the various jhsdb clhsdb commands of the SA to improve the robustness of the SA. As a part of this, here is a webrev for sanity tests for 3 of the clhsdb commands: Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190307 webrev:

Re: RFR: SA: JDK-8189798: SA cleanup - part 1

Thank you very much, Serguei. -Jini. On 10/27/2017 2:22 PM, serguei.spit...@oracle.com wrote: Hi Jini, The fix looks good to me. Thanks, Serguei On 10/24/17 00:31, Jini George wrote: Adding hotspot-dev too. Thanks, Jini. On 10/24/2017 12:05 PM, Jini George wrote: Hello, As a part

Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass

Hi Roman, The SA portion looks good to me. Thank you, Jini (not a Reviewer). On 10/19/2017 10:09 PM, Roman Kennke wrote: Am 18.10.2017 um 22:41 schrieb Kim Barrett: On Oct 18, 2017, at 4:04 PM, Roman Kennke wrote: Am 18.10.2017 um 20:41 schrieb Kim Barrett: On Oct 18,

RFR: SA: JDK-8189798: SA cleanup - part 1

Adding hotspot-dev too. Thanks, Jini. On 10/24/2017 12:05 PM, Jini George wrote: Hello, As a part of SA next, I am working on writing a test case which compares the fields and the types of the fields of the SA java classes with the corresponding entries in the vmStructs tables

RFR: SA: JDK-8189798: SA cleanup - part 1

Hello, As a part of SA next, I am working on writing a test case which compares the fields and the types of the fields of the SA java classes with the corresponding entries in the vmStructs tables. This, to some extent, would help in preventing errors in SA due to the changes in hotspot. As

Re: RFR: JDK-8189061 - serviceability/sa/TestInstanceKlassSize.java - Unable to find instance klass for null

Your fix looks good to me, Sharath. Thanks, Jini (Not a Reviewer). On 10/23/2017 10:49 AM, Sharath Ballal wrote: Hello, Pls review this simple fix for excluding sun.util.PreHashedMap from TestInstanceKlassSize.java. sun.util.PreHashedMap can be lazily loaded due to JDK-8186517

Re: RFR: 8189373: jmap -heap exited with error code

Your changes look good to me, Roman. Nit: Please do change the copyright year to 2017 in CollectedHeapName.java. Thank you, Jini (not a Reviewer). On 10/18/2017 11:59 PM, Roman Kennke wrote: My recent CMSHeap extraction has broken the JVM servicability agent. It looks like I actually need a

Re: RFR: 8189069: regression after push of 8187403: "AssertionFailure: addr should be OopHandle"

Hi Yasumasa, The changes look fine. Thanks, Jini (not a Reviewer). On 10/10/2017 7:40 AM, serguei.spit...@oracle.com wrote: Hi Yasumasa, Thank you for the quick fix! It looks good. I'll sponsor your fix after we get at least one more review. Thanks, Serguei On 10/9/17 19:03, Yasumasa

Re: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

Thank you, David and Serguei. - Jini. On 10/10/2017 9:48 AM, serguei.spit...@oracle.com wrote: Hi Jini, +1 Thanks, Serguei On 10/9/17 20:31, David Holmes wrote: Thanks for your patience on this one Jini! The change looks good. Thanks, David On 10/10/2017 2:15 AM, Jini George wrote: Hi

Re: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

On 18/08/2017 8:00 PM, Jini George wrote: Hi all, Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ Problem gist: The deprecated ptrace() command, PT_ATTACH was changed to PT_ATTACHEXC, which causes mach

Re: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB

Your changes look good, Yasumasa. Thanks, Jini (Not a Reviewer). On 9/29/2017 2:49 PM, Yasumasa Suenaga wrote: Thanks Serguei, I'm waiting another reviewer. Yasumasa 2017/09/29 午後6:00 "serguei.spit...@oracle.com "

Re: PING: RFR: 8187401: Java Stack cannot be shown on HSDB

One point I want to make is that we have the enum BasicTypeSize redefined in SA as public static final values, I will update BasicTypeSize in new webrev. Sorry Yasumasa, I meant BasicType only. Thanks, Jini.

Re: PING: RFR: 8187401: Java Stack cannot be shown on HSDB

Hi Yasumasa, Your changes look good. One point I want to make is that we have the enum BasicTypeSize redefined in SA as public static final values, and this makes it error prone when existing enum values change, just as in this case. An ideal solution would be to include this in vmStructs.cpp

Re: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB

issue, but we cannot control compile level (TieredCompilation) AFAIK. 2. If JShell implementation is changed in the future, this testcase might not verify this bug. I will merge your testcase to the webrev if these concerns can be ignored. Thanks, Yasumasa 2017/10/02 0:51 "J

Re: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB

-8187402) and JDK-8187403 are too difficult to crate test cases because they are problems in Stack Memory window in HSDB. Can we add noreg-hard label to JBS? Thanks, Yasumasa On 2017/09/27 2:36, Jini George wrote: Hi Yasumasa, The changes look fine, but please do include the test case also

Re: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB

Hi Yasumasa, The changes look fine, but please do include the test case also for this. In general, it would be great if you could provide test cases also along with the code changes while sending for review. Thank you, Jini. On 9/26/2017 8:19 PM, Yasumasa Suenaga wrote: Hi all, I uploaded

Re: PING: RFR: 8175816: SA: HSDB: Compute Liveness results in java.lang.IndexOutOfBoundsException

Hi Yasumasa, Your change looks good. But please do add in a test case for this. Thanks, Jini (not a Reviewer). On 9/21/2017 4:18 AM, Yasumasa Suenaga wrote: PING: Have you checked this issue? http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ Yasumasa On 2017/09/11 22:47,

Re: jdk9 can not load sa.js automatically in jhsdb

Hi Liu Xin, No, this is not a wrong usage on your part. You are facing the following issue: https://bugs.openjdk.java.net/browse/JDK-8157947 So, at this point, till this is fixed, you would face issues if you try to run commands based on the the javascript interface with jhsdb. Thanks,

Re: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

too. Thanks, Jini. Thanks, Poonam On 9/14/2017 8:17 PM, Jini George wrote: Thanks much, Dan. -Jini. On 9/15/2017 4:18 AM, Daniel D. Daugherty wrote: On 8/18/17 4:00 AM, Jini George wrote: Hi all, Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 Webrev: htt

Re: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

Thanks much, Dan. -Jini. On 9/15/2017 4:18 AM, Daniel D. Daugherty wrote: On 8/18/17 4:00 AM, Jini George wrote: Hi all, Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ hotspot/src/jdk.hotspot.agent

Re: 4 issues for HSDB

Hi Yasumasa, I have assigned https://bugs.openjdk.java.net/browse/JDK-8175816 to you. Thanks, Jini. On 9/10/2017 6:52 PM, Yasumasa Suenaga wrote: PING: Have you checked these issues? I want to know I can file them to JBS and can send webrev. Yasumasa On 2017/08/31 23:49, Yasumasa Suenaga

Re: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

be nice to hear why it is not good. How much would it break the fix of the JDK-8182299? Thanks, Serguei Just my 2c. Cheers, David On 18/08/2017 8:00 PM, Jini George wrote: Hi all, Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 Webrev: http://cr.openjdk.java.net

Re: [10] RFR: 8185796: jstack and clhsdb jstack should show lock objects

Apologize for the late reply, Yasumasa. I think so, but I guess it is difficult. For example, test for CLHSDB command is provided as test/serviceability/sa/TestPrintMdo.java . But target process seems to be fixed to "LingeredApp". Can we change it to another program which generates lock

Re: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

be the quick way forward instead of trying to rush in something like this. Just my 2c. Cheers, David On 18/08/2017 8:00 PM, Jini George wrote: Hi all, Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ Problem

RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

Hi all, Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ Problem gist: The deprecated ptrace() command, PT_ATTACH was changed to PT_ATTACHEXC, which causes mach exceptions (and not UNIX signals) to be

Re: [10] RFR: 8185796: jstack and clhsdb jstack should show lock objects

Hi Yasumasa, This is helpful, but looks like 'locked' is printed even when a thread is waiting for the monitor entry, or has unlocked a lock. For a simple test program, we would have: "Thread-1" #11 prio=5 tid=0x7f393845 nid=0x6be4 waiting for monitor entry [0x7f391501]

Re: [10] RFR 8181647: jhsdb jstack could not output thread name

startHsdbJstack(false); +} +} Regards, Chihiro On 2017/06/08 18:04, chihiro ito wrote: Hi Jini, Thank you for your advices. I try to add the test case and modify the copyright year to 2017. Basically, I agree with your idea, but I think that the separator line should finally be the

Re: [10] RFR 8181647: jhsdb jstack could not output thread name

Hi Chihiro, Thank you for making this useful change. Your changes look good. It would be great though if you could add a test case for this. Could you also modify the copyright year to 2017 ? One additional suggestion: The addition of the thread name makes the separator lines unaligned in

Re: RFR: JDK-6760477 - Update SA to include stack traces in the heap dump

Hi Sharath, Looks good. A few nits. * Looks like the stackTraces array list is unused. * HeapHprofBinWriter.java: Line 764: It might be better to replace 2 * 4 and similar instances with 2 * INT_SIZE. Thanks, Jini. On 5/29/2017 4:14 PM, Sharath Ballal wrote: Hi, Pls review the fix for

Re: RFR: [SA testbug]: JDK-8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1

Thank you, Serguei! -jini On 2/27/2017 3:03 PM, serguei.spit...@oracle.com wrote: +1 Thanks, Serguei On 2/26/17 21:43, Dmitry Samersoff wrote: Looks good to me! On 2017-02-27 08:01, Jini George wrote: Requesting a review for the one line fix for the following testbug: https

Re: RFR: [SA testbug]: JDK-8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1

Thank you, Dmitry! -jini On 2/27/2017 11:13 AM, Dmitry Samersoff wrote: Looks good to me! On 2017-02-27 08:01, Jini George wrote: Requesting a review for the one line fix for the following testbug: https://bugs.openjdk.java.net/browse/JDK-8175512 Webrev: http://cr.openjdk.java.net/~jgeorge

RFR: [SA testbug]: JDK-8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1

Requesting a review for the one line fix for the following testbug: https://bugs.openjdk.java.net/browse/JDK-8175512 Webrev: http://cr.openjdk.java.net/~jgeorge/8175512/webrev.00/ Thanks, Jini.

Re: RFR: JDK-8162504: [SA testbug] TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS

Thank you, Serguei. - jini. On 2/22/2017 12:58 PM, serguei.spit...@oracle.com wrote: Hi Jini, It looks good. Thanks, Serguei On 2/21/17 07:48, Jini George wrote: Requesting reviews for the following SA testbug: https://bugs.openjdk.java.net/browse/JDK-8162504 Webrev: http

Re: RFR: JDK-8162504: [SA testbug] TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS

Thank you, Dmitry. Could I get one more review for this ? -Jini. On 2/21/2017 9:51 PM, Dmitry Samersoff wrote: Jini, Looks good to me. -Dmitry On 2017-02-21 18:48, Jini George wrote: Requesting reviews for the following SA testbug: https://bugs.openjdk.java.net/browse/JDK-8162504 Webrev

RFR: JDK-8162504: [SA testbug] TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS

Requesting reviews for the following SA testbug: https://bugs.openjdk.java.net/browse/JDK-8162504 Webrev: http://cr.openjdk.java.net/~jgeorge/8162504/webrev.00/ Thank you, Jini.

Re: RFR: JDK-8175054: Move new TestPrintMdo.java to hotspot/test directory

Thanks, David. -jini On 2/16/2017 1:08 PM, David Holmes wrote: Reviewed. Thanks, David On 16/02/2017 3:15 PM, Jini George wrote: Hi, Could I pls get a quick review for the following minor change to correct an incorrect push wrt the file path of a new test case added ? Bug: https

RFR: JDK-8175054: Move new TestPrintMdo.java to hotspot/test directory

Hi, Could I pls get a quick review for the following minor change to correct an incorrect push wrt the file path of a new test case added ? Bug: https://bugs.openjdk.java.net/browse/JDK-8175054 Webrev: http://cr.openjdk.java.net/~jgeorge/8175054/webrev/ Thanks, Jini.

Re: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client

Thank you, Serguei! -jini On 2/14/2017 9:51 AM, serguei.spit...@oracle.com wrote: Hi Jini, Looks good. Thank you for the update! Thanks, Serguei On 2/13/17 04:47, Jini George wrote: Thank you, Serguei, for the review. I have addressed your comments and have a revised webrev at: http

Re: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client

Thank you very much, Dmitry! -Jini. On 2/13/2017 5:32 PM, Dmitry Samersoff wrote: Jini, The fix looks good to me. -Dmitry On 2017-02-11 15:32, Jini George wrote: Could I pls get reviews done for the SA testbug: https://bugs.openjdk.java.net/browse/JDK-8173896 Webrev: http

Re: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client

s line looks strange as the variable of type OutputStream is called "input": 127 OutputStream input = p.getOutputStream(); Adding a comment explaining why is that would be nice. Thanks, Serguei On 2/11/17 04:32, Jini George wrote: Could I pls get reviews done for the SA

RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client

Could I pls get reviews done for the SA testbug: https://bugs.openjdk.java.net/browse/JDK-8173896 Webrev: http://cr.openjdk.java.net/~jgeorge/8173896/webrev.00/ Thanks, Jini.

Re: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow

Thank you, David. -Jini. On 1/27/2017 11:26 AM, David Holmes wrote: Updates looks good to me too Jini! Thanks, David On 27/01/2017 2:49 PM, Jini George wrote: Thank you very much, Dmitry, for the review. I am addressing all your comments, except for the @ignore in the test. -jini On 1/26

Re: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow

@ignore to this test with a proper comments and run it manually if we see a problem with SA dumper (but it's just an opinion - I'm OK to leave it as is). -Dmitry On 2017-01-26 11:26, Jini George wrote: Modified webrev: <http://cr.openjdk.java.net/%7Ejgeorge/8171084/webrev.01/index.html>http://cr

Re: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow

Modified webrev: http://cr.openjdk.java.net/~jgeorge/8171084/webrev.01/index.html <http://cr.openjdk.java.net/%7Ejgeorge/8171084/webrev.01/index.html> Requesting one more Reviewer also to take a look at this. Thank you, Jini. On 1/23/2017 2:10 PM, Jini George wrote: Thank

Re: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow

Thanks much for the review, David. My answers inline: 870 protected void writeInstance(Instance instance, int length) throws IOException { seems incorrect. It adds a length parameter that is unused and also creates an overload, rather than override of the inherited version. As a

RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow

Hi, Requesting for reviews for the following SA issue: https://bugs.openjdk.java.net/browse/JDK-8171084 Webrev:http://cr.openjdk.java.net/~jgeorge/8171084/webrev.00/ Thanks, Jini.

RE: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test)

15, 2016 3:21 PM To: Jini George; serviceability-dev@openjdk.java.net Subject: Re: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) Hi Jini, Some questions. Is the call of the method alignSize(size) necessary? It seems

PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test)

Hi, Gentle Reminder! Thanks, Jini. From: Jini George Sent: Tuesday, July 05, 2016 9:54 PM To: serviceability-dev@openjdk.java.net Subject: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) Hi all, Please review

RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test)

Hi all, Please review the fix in Serviceability Agent (SA) for: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8145627"JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) The webrev is at:

RE: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

Please hold off on this review (since I might have some modifications to the changes). Regds, Jini. From: Jini George Sent: Monday, April 25, 2016 2:29 PM To: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: RE: RFR: JDK-8043571: com/sun/jdi

RE: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

Adding hotspot-runtime as well since this includes runtime changes. Regards, Jini. From: Jini George Sent: Monday, April 25, 2016 1:23 PM To: serviceability-dev@openjdk.java.net Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert

RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

Hello, Please review the fix for the JVMTI bug: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync https://bugs.openjdk.java.net/browse/JDK-8043571 Webrev:

RE: RFR(S): JDK-7041183 Improve error handling in Improve error handling in src/share/vm/services/management.cpp

Since no one else had any further comments on this, JDK-7041183 has been closed as No-change. Thanks, Jini. > > If we have not identified legitimate reasons for the pool being invalid > then I would close this as not a bug. > > Cheers, > David > - >

RE: RFR(S): JDK-7041183 Improve error handling in Improve error handling in src/share/vm/services/management.cpp

close the bug as no change. Thanks, Jini. > -Original Message- > From: David Holmes > Sent: Monday, November 23, 2015 12:14 PM > To: Jini George; serviceability-dev@openjdk.java.net; Dmitry Samersoff > Subject: Re: RFR(S): JDK-7041183 Improve error handling in Improve >

RE: RFR(S): JDK-7041183 Improve error handling in Improve error handling in src/share/vm/services/management.cpp

nal Message- > > On 30/10/2015 9:01 PM, Dmitry Samersoff wrote: > > Everybody, > > > > (* On behalf of Jini George <jini.geo...@oracle.com> *) > > > > Please review the fix > > > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/

<    1   2   3