RFR (S) 8216352: SA: ClhsdbLauncher should throw errors on Unrecognized commands

Hi, Please review a tiny change to handle unrecognized command options for ClhsdbLauncher test. This patch is already proposed by Gary Adams in comments section. JBS: https://bugs.openjdk.java.net/browse/JDK-8216352 Webrev: http://cr.openjdk.java.net/~fmatte/8216352/webrev.00/ Thanks, Fairoz

RE: RFR (S) 8216352: SA: ClhsdbLauncher should throw errors on Unrecognized commands

Hi Chris, Thanks for the review, do you want me to cover this with regression test? I suspect that it was not required. Thanks, Fairoz -Original Message- From: Chris Plummer Sent: Thursday, October 3, 2019 9:55 PM To: Fairoz Matte ; serviceability-dev Subject: Re: RFR (S) 8216352

RE: RFR (S) 8216352: SA: ClhsdbLauncher should throw errors on Unrecognized commands

Hi Serguei, Thanks for the review. Thanks, Fairoz -Original Message- From: Serguei Spitsyn Sent: Thursday, October 3, 2019 10:26 PM To: Fairoz Matte ; serviceability-dev Subject: Re: RFR (S) 8216352: SA: ClhsdbLauncher should throw errors on Unrecognized commands Hi Fairoz, Looks

RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled

Hi, Please review this small change, Updating error handling, to make sure "lib_base_diff = 0" is still a valid scenario even after calc_prelinked_load_address() call. JBS - https://bugs.openjdk.java.net/browse/JDK-8235637 Webrev - http://cr.openjdk.java.net/~fmatte/8235637/webrev.00/ This pat

RE: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled

Hi Yasumasa, Thanks for the review. Sure, I will get them on 8u and 11u. Thanks, Fairoz > -Original Message- > From: Yasumasa Suenaga > Sent: Thursday, December 12, 2019 9:14 AM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: RFR: 823563

RE: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled

Sent: Thursday, December 12, 2019 9:48 PM To: Fairoz Matte ; serviceability-dev@openjdk.java.net Subject: Re: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled Can you use a macro for -1L? Maybe INAVLID_LOAD_ADDRESS or LOAD_ADDRESS_ERROR. Chris On 12/11/19 7:

RE: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled

Thanks Chris, > -Original Message- > From: Chris Plummer > Sent: Friday, December 13, 2019 11:09 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if > prelink is enabled &g

RE: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled

Oh yes, Thanks Kevin for the review. Corrected the same - http://cr.openjdk.java.net/~fmatte/8235637/webrev.02 Thanks, Fairoz -Original Message- From: Kevin Walls Sent: Monday, December 16, 2019 8:44 PM To: Fairoz Matte ; Chris Plummer ; serviceability-dev@openjdk.java.net Subject: Re

RE: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled

Walls ; Fairoz Matte ; serviceability-dev@openjdk.java.net Subject: Re: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled +1 On 12/16/19 8:35 AM, Kevin Walls wrote: > Great! 8-) > > On 16/12/2019 15:36, Fairoz Matte wrote: >> Oh yes, >> T

RFR (S) 8239055: Wrong implementation of VMState.hasListener

Hi, Please review a tiny change to correct the VMState.hasListener implementation. JBS: https://bugs.openjdk.java.net/browse/JDK-8239055 Webrev: http://cr.openjdk.java.net/~fmatte/8239055/webrev.00/ Thanks, Fairoz

RE: RFR (S) 8239055: Wrong implementation of VMState.hasListener

Hi Serguei, Thanks for the review. Thanks, Fairoz From: Serguei Spitsyn Sent: Wednesday, February 19, 2020 1:57 AM To: Fairoz Matte ; serviceability-dev@openjdk.java.net Subject: Re: RFR (S) 8239055: Wrong implementation of VMState.hasListener Hi Fairoz, Looks good. Thanks, Serguei On 2/13

RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Hi, Please review this small test infra change to identify at runtime the JFR is active or not. JBS - https://bugs.openjdk.java.net/browse/JDK-8243451 Webrev - http://cr.openjdk.java.net/~fmatte/8243451/webrev.00/ Thanks, Fairoz

RE: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Hi Erik, Thanks for your quick response, Below is the updated webrev to handle if jfr module is not present http://cr.openjdk.java.net/~fmatte/8243451/webrev.01/ Thanks, Fairoz > -Original Message- > From: Erik Gahlin > Sent: Monday, June 1, 2020 2:31 PM > To: Fairoz

RE: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Hi Erik, Thanks for the review, below is the updated webrev. http://cr.openjdk.java.net/~fmatte/8243451/webrev.02/ Thanks, Fairoz > -Original Message- > From: Erik Gahlin > Sent: Monday, June 1, 2020 4:26 PM > To: Fairoz Matte > Cc: serviceability-dev@openjdk.java.ne

RE: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

: Fairoz Matte ; Erik Gahlin Cc: serviceability-dev@openjdk.java.net Subject: Re: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken   On 6/1/20 12:30, HYPERLINK "mailto:serguei.spit...@oracle.com"serguei.spit...@oracle.com

RE: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Hi Serguei, Thanks for the clarifications, I have incorporated the 2nd suggestion, below is the webrev, http://cr.openjdk.java.net/~fmatte/8243451/webrev.09/ Thanks, Fairoz From: Serguei Spitsyn Sent: Monday, June 8, 2020 10:34 PM To: Fairoz Matte ; Erik Gahlin Cc: serviceability-dev

RE: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Hi Leonid, The call isJFRActive() need to be executed on HeapwalkingDebuggee side. This is what my understanding is. Thanks, Fairoz > -Original Message- > From: Leonid Mesnik > Sent: Wednesday, June 10, 2020 1:16 AM > To: Serguei Spitsyn ; Fairoz Matte > ; Er

RE: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Hi Serguei, Thanks for the clarification. I will work on to move isJFRActive () method from the TestDebuggerType2 to HeapWalkingDebugger Thanks, Fairoz > -Original Message- > From: Serguei Spitsyn > Sent: Wednesday, June 10, 2020 11:42 AM > To: Fairoz Matte ; Leonid Mes

RE: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Thanks Serguei, Leonid for the reviews. Thanks, Fairoz > -Original Message- > From: Leonid Mesnik > Sent: Wednesday, June 10, 2020 10:19 PM > To: Fairoz Matte > Cc: Serguei Spitsyn ; Erik Gahlin > ; serviceability-dev@openjdk.java.net > Subject

RFR(s): 8236042: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java fails with -Xcomp -XX:TieredStopAtLevel=1

Hi, Please review this small test change to consider the scenario when there is no "printmdo" output JBS - https://bugs.openjdk.java.net/browse/JDK-8236042 Webrev - http://cr.openjdk.java.net/~fmatte/8236042/webrev.00/ Thanks, Fairoz

RE: RFR(s): 8236042: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java fails with -Xcomp -XX:TieredStopAtLevel=1

Thanks Chris, for the review comments. I have updated the suggested change. Thanks, Fairoz > -Original Message- > From: Chris Plummer > Sent: Wednesday, July 8, 2020 3:38 AM > To: Fairoz Matte ; hotspot-compiler- > d...@openjdk.java.net; serviceability-dev@openjdk.java.ne

RE: RFR(s): 8236042: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java fails with -Xcomp -XX:TieredStopAtLevel=1

Thanks Vladimir for the review. Thanks for mentioning the reasons for MDO's not being generated, I have added them as comment in bug for future reference. Thanks, Fairoz > -Original Message- > From: Vladimir Kozlov > Sent: Saturday, July 11, 2020 5:36 AM > To: Fai

RFR(s): 8248295: serviceability/jvmti/CompiledMethodLoad/Zombie.java failure with Graal

Hi, Please review this small test change to work with Graal. Background: Graal require more code cache compared to c1/c2. but the test case always set it to 20MB. This may not be sufficient when running graal. Default configuration for ReservedCodeCacheSize = 250MB With graal enabled,

RE: RFR(s): 8248295: serviceability/jvmti/CompiledMethodLoad/Zombie.java failure with Graal

er" 2. Issues observed 0/300 runs, ReservedCodeCacheSize=30m with "-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler" Thanks, Fairoz > -Original Message- > From: Vladimir Kozlov > Sent: Monday, August 17, 2020 11:22 PM > To: Fair

RE: RFR(s): 8248295: serviceability/jvmti/CompiledMethodLoad/Zombie.java failure with Graal

0Kb used=5677Kb max_used=5688Kb free=14803Kb > > - > > I also forgot to ask you to update test's Copyright year. I have updated the copyright year. Updated webrev for the reference - http://cr.openjdk.java.net/~fmatte/8248295/webrev.01/ Thanks, F

RE: RFR(s): 8248295: serviceability/jvmti/CompiledMethodLoad/Zombie.java failure with Graal

Thanks Vladimir and Serguei for the reviews. Thanks, Fairoz > -Original Message- > From: Serguei Spitsyn > Sent: Thursday, August 20, 2020 1:45 AM > To: Vladimir Kozlov ; Fairoz Matte > ; hotspot-compiler-...@openjdk.java.net; > serviceability-dev@openjdk.java.net >

RE: [8u-backport] RFR: JDK-8163083: SocketListeningConnector does not allow invocations with port 0

Thanks Daniil... > -Original Message- > From: Daniil Titov > Sent: Thursday, October 04, 2018 9:15 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8163083: SocketListeningConnector does > not allow invocation

[8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation

Hi, Kindly review the backport of "JDK-8193879: Java debugger hangs on method invocation" to 8u Code is almost cleanly applied, test case has been modified to fit into the JDK8 test framework. Webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.00/ JBS bug - https://bugs.openjdk.java.n

RE: [8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation

Thanks Serguei for the review... > -Original Message- > From: Serguei Spitsyn > Sent: Thursday, October 11, 2018 10:41 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8193879: Java debugger hangs on > method invo

RE: [8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation

/webrev.01/ Thanks, Fairoz From: JC Beyler Sent: Thursday, October 11, 2018 9:23 PM To: Fairoz Matte Cc: serviceability-dev@openjdk.java.net Subject: Re: [8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation Hi Fairoz, The backport looks good to me (not a reviewer though) but

[8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash

Hi, Kindly review the backport of "8211909: JDWP Transport Listener: dt_socket thread crash" to 8u code is almost cleanly applied. Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8211909 JDK12 changeset - http://hg.openjdk.

RE: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash

Thanks David, for the review... > -Original Message- > From: David Holmes > Sent: Thursday, October 18, 2018 1:20 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket > thread

RE: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash

Thanks Jc for the review..   From: JC Beyler Sent: Thursday, October 18, 2018 9:41 PM To: Fairoz Matte Cc: David Holmes ; serviceability-dev@openjdk.java.net Subject: Re: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash   Hi Fairoz,   I compared the original

RFR: 8225715: jhsdb jmap fails to write binary heap dump of a jshell process

Hi, Please review a fix that potentially handle NPE and allow heap to dump from a process were we get source file name as null. Background: For taking heap dump of JShell process, we get getSourceFileName() as null. Current implementation doesn't have null check. This fix will handle the null

RE: RFR: 8225715: jhsdb jmap fails to write binary heap dump of a jshell process

Hi Chris, Thanks for the review. Thanks, Fairoz > -Original Message- > From: Chris Plummer > Sent: Monday, July 01, 2019 11:21 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: RFR: 8225715: jhsdb jmap fails to write binary heap dump of

RE: RFR: 8225715: jhsdb jmap fails to write binary heap dump of a jshell process

Hi Kevin, > -Original Message- > From: Kevin Walls > Sent: Tuesday, July 02, 2019 2:18 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: RFR: 8225715: jhsdb jmap fails to write binary heap dump of a > jshell process > > Hi Fairoz

RFR: JDK-8173664: Typo in https://java.net/downloads/heap-snapshot/hprof-binary-format.html

Hi, Kindly review the small typo fix, applicable only for JDK8 BugID: https://bugs.openjdk.java.net/browse/JDK-8173664 Webrev: http://cr.openjdk.java.net/~rpatil/8173664/webrev/ Thanks, Fairoz

RE: RFR: JDK-8173664: Typo in https://java.net/downloads/heap-snapshot/hprof-binary-format.html

Hi David, > -Original Message- > From: David Holmes > Sent: Wednesday, May 10, 2017 3:26 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: RFR: JDK-8173664: Typo in https://java.net/downloads/heap- > snapshot/hprof-binary-format.html >

RE: RFR: JDK-8173664: Typo in https://java.net/downloads/heap-snapshot/hprof-binary-format.html

airoz > -Original Message- > From: David Holmes > Sent: Thursday, May 11, 2017 7:52 AM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: RFR: JDK-8173664: Typo in https://java.net/downloads/heap- > snapshot/hprof-binary-format.html > >

RE: RFR: JDK-8173664: Typo in https://java.net/downloads/heap-snapshot/hprof-binary-format.html

Hi, Please find the updated webrev with suggested changes Webrev - http://cr.openjdk.java.net/~rpatil/8173664/webrev.01/ BugID: https://bugs.openjdk.java.net/browse/JDK-8173664 Thanks, Fairoz > -Original Message- > From: Fairoz Matte > Sent: Thursday, May 11, 2017 9:05 AM &g

[8u-backport] RFR: JDK-8191948: jdb error: InvalidTypeException: Can't assign double[][][] to double[][][]

Hi, Kindly review the backport of "JDK-8191948: jdb error: InvalidTypeException: Can't assign double[][][] to double[][][]" to 8u Webrev - http://cr.openjdk.java.net/~fmatte/8191948/webrev.00/ JDK 11 bug - https://bugs.openjdk.java.net/browse/JDK-8191948 JDK 11 changeset - http://hg.openj

RE: [8u-backport] RFR: JDK-8191948: jdb error: InvalidTypeException: Can't assign double[][][] to double[][][]

Hi Chris and Serguei, Thanks for the review, I will add the appropriate noreg label. Thanks, Fairoz From: Serguei Spitsyn Sent: Wednesday, July 25, 2018 11:24 PM To: Chris Plummer ; Fairoz Matte ; serviceability-dev@openjdk.java.net Subject: Re: [8u-backport] RFR: JDK-8191948: jdb error

[8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core

Hi, Kindly review the backport of "JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core" to 8u Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 JDK9 changeset - http://hg.openjdk.java.net/jdk9/jdk9/hotsp

RE: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core

Hi Jini, Thanks for the review. Thanks, Fairoz > -Original Message- > From: Jini George > Sent: Friday, September 21, 2018 4:07 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris

RE: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core

Hi Jini, > -Original Message- > From: Jini George > Sent: Friday, September 21, 2018 4:07 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 > when loading dumped core >

RE: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core

> Sent: Tuesday, September 25, 2018 3:48 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 > when loading dumped core > > Hi Fairoz, > > I took a better look at the changes

RE: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core

Hi Jini, thanks for the review. May I get one more review for this? Thanks, Fairoz > -Original Message- > From: Jini George > Sent: Friday, September 28, 2018 10:37 AM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-816

RE: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core

Hi Serguei, Thanks for the review. Thanks, Fairoz > -Original Message- > From: Serguei Spitsyn > Sent: Tuesday, October 02, 2018 11:21 AM > To: Fairoz Matte ; Jini Susan George > ; serviceability-dev@openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : j

[8u-backport] RFR: JDK-8163083: SocketListeningConnector does not allow invocations with port 0

Hi, Kindly review the backport of "JDK-8163083: SocketListeningConnector does not allow invocations with port 0" to 8u Webrev - http://cr.openjdk.java.net/~fmatte/8163083/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8163083 JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk

[7u] RFR: JDK-6626412: jstack using SA prints some info messages into err stream

Hi, Please review the backport of bug: "JDK-6626412: jstack using SA prints some info messages into err stream" Webrev: http://cr.openjdk.java.net/~shshahma/6626412/webrev/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-6626412 jdk9 changeset:http://hg.openjdk.java.net/hsx/hsx25/hotspot

RE: [7u] RFR: JDK-6626412: jstack using SA prints some info messages into err stream

; From: Fairoz Matte > Sent: Friday, June 17, 2016 3:02 PM > To: serviceability-dev@openjdk.java.net > Subject: [7u] RFR: JDK-6626412: jstack using SA prints some info > messages into err stream > > Hi, > > Please review the backport of bug: "JDK-6626412: jstack using

RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][]

findComponentType() logic is wrong. In findComponentType() method, We always get vm.classesByName() retruns empty list list = vm.classesByName(parser.typeName()); We have "parser.typeName()" retruns " double[][]" vm.classesByName("") is expecting the fully qualified name example "java.lang.Double

Re: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][]

On Tue, 27 Apr 2021 23:47:26 GMT, Chris Plummer wrote: >> findComponentType() logic is wrong. In findComponentType() method, We always >> get vm.classesByName() retruns empty list >> list = vm.classesByName(parser.typeName()); >> We have "parser.typeName()" retruns " double[][]" >> vm.classesByN

Re: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] [v2]

shakov from JetBrains, I am proposing > the same to get this fix. I have verified the patch with required testing it > works fine. Fairoz Matte has updated the pull request incrementally with two additional commits since the last revision: - Update ArrayReferenceImpl.java - Update ArrayT

Re: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] [v2]

On Thu, 29 Apr 2021 04:31:35 GMT, Chris Plummer wrote: >> Hi Chris, >> >> Thanks for looking into this, >> >>>Do we even need findComponentType() any more? Isn't >>>ReferenceTypeImpl.findType() sufficient. >> >> We still need findComponentType(), >> Difference between findType() and findCo

Re: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] [v2]

On Thu, 29 Apr 2021 07:58:26 GMT, Fairoz Matte wrote: >> findComponentType() logic is wrong. In findComponentType() method, We always >> get vm.classesByName() retruns empty list >> list = vm.classesByName(parser.typeName()); >> We have "parser

Re: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] [v2]

On Thu, 29 Apr 2021 07:58:26 GMT, Fairoz Matte wrote: >> findComponentType() logic is wrong. In findComponentType() method, We always >> get vm.classesByName() retruns empty list >> list = vm.classesByName(parser.typeName()); >> We have "parser

Integrated: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][]

On Fri, 23 Apr 2021 15:03:42 GMT, Fairoz Matte wrote: > findComponentType() logic is wrong. In findComponentType() method, We always > get vm.classesByName() retruns empty list > list = vm.classesByName(parser.typeName()); > We have "parser.typeName()" retruns " dou

Re: RFR: 8273575: memory leak in appendBootClassPath(), paths must be deallocated

On Wed, 15 Sep 2021 01:05:10 GMT, Serguei Spitsyn wrote: > The memory allocated and hold in the paths local variable of function > appendBootClassPath() is never deallocated: > splitPathList(pathList, &count, &paths); > So, it is a memory leak which needs to be fixed. > The fix is to add one

RFR: 8206438: com/sun/jdi/FieldWatchpoints.java timeout intermittently

8206438: com/sun/jdi/FieldWatchpoints.java timeout intermittently - Commit messages: - 8206438: com/sun/jdi/FieldWatchpoints.java timeout intermittently Changes: https://git.openjdk.java.net/jdk/pull/5598/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5598&range=00 I

Re: RFR: 8206438: com/sun/jdi/FieldWatchpoints.java timeout intermittently

On Tue, 21 Sep 2021 07:40:01 GMT, Fairoz Matte wrote: > 8206438: com/sun/jdi/FieldWatchpoints.java timeout intermittently Thanks Leonid and Chris for looking into this. I couldn't reproduce the issue locally and none of the issues observed on mach5 have the active links for logs https