Re: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect

On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - > TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid

Integrated: 8283849: AsyncGetCallTrace may crash JVM on guarantee

On Thu, 5 May 2022 11:28:14 GMT, Jaroslav Bachorik wrote: > A gist of the fix is to allow relaxed special handling of code blob lookup > when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which > is still on stack. While this

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12]

On Wed, 18 May 2022 05:30:53 GMT, Thomas Stuefe wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Change comment wording > > src/hotspot/share/code/codeCache.cpp line 662: >

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v13]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]

On Tue, 17 May 2022 15:23:04 GMT, Johannes Bechberger wrote: > thought that "this approach" referred to the approach of this PR (possibly > renaming the flag) ^ this But still, I would prefer to defer any further improvements into a separate PR. - PR:

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]

On Tue, 17 May 2022 12:52:30 GMT, Johannes Bechberger wrote: >> @dholmes-ora Oh, you are only objecting to the RAII mark, not to the fact >> that we store the state in Thread? Ok, sure. In my view, a mark prevents the >> "on" state from escaping the frame, e.g. if stray return calls sneak in

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11]

On Tue, 17 May 2022 13:01:36 GMT, Johannes Bechberger wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove ASGCTMark > > src/hotspot/share/prims/forte.cpp line 594:

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]

On Tue, 17 May 2022 12:23:56 GMT, David Holmes wrote: >> Hi David, >> >>> You can't call `JavaThread::current()` in any of this code as it is not >>> safe from a signal handling context. (There is an existing use in ASGCT >>> that is also unsafe.) I suggest not having the no-arg constructor

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]

On Tue, 17 May 2022 05:38:01 GMT, David Holmes wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Restore the original find_blob behavior regarding dead blobs > > src/hotspot

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v10]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]

On Sat, 7 May 2022 04:59:44 GMT, Thomas Stuefe wrote: >> Jaroslav Bachorik has refreshed the contents of this pull request, and >> previous commits have been removed. The incremental views will show >> differences compared to the previous content of the PR. The pull reques

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v8]

On Mon, 16 May 2022 08:49:40 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup >> when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which >> is still on st

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v8]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v7]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]

On Fri, 6 May 2022 10:08:09 GMT, David Holmes wrote: >> Jaroslav Bachorik has refreshed the contents of this pull request, and >> previous commits have been removed. The incremental views will show >> differences compared to the previous content of the PR. The pull request &

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]

On Fri, 6 May 2022 01:18:21 GMT, David Holmes wrote: >> I will have to do check/cast in `CodeCache::find_blob()` as that may get >> called from any thread, not just Java threads. >> I would assume that having this flag defined at Thread level is a lesser of >> the evils - or am I wrong here? >

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v5]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

On Fri, 6 May 2022 01:30:35 GMT, David Holmes wrote: >> Ok, moved it a bit around - now the bool field is after an int field which >> should make things slightly better, I guess. > > At the start of JavaThread we have: > > private: > bool _on_thread_list;// Is set

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

On Thu, 5 May 2022 13:21:39 GMT, Johannes Bechberger wrote: >> I had tried identifying any gaps I might use but found none. Not saying they >> are none but it is rather difficult to spot anything with all the Thread >> related attributes spread across many lines, interspersed with the method

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

On Thu, 5 May 2022 12:20:41 GMT, Jaroslav Bachorik wrote: >> src/hotspot/share/runtime/thread.hpp line 649: >> >>> 647: // support ASGCT >>> 648: private: >>> 649: bool _in_asgct; >> >> The position of this field may be significant. See

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v4]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]

On Thu, 5 May 2022 12:13:49 GMT, David Holmes wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Naming and comments cleanup > > src/hotspot/share/runtime/thread.hpp line 649: >

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

On Thu, 5 May 2022 12:00:49 GMT, David Holmes wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Make sure the code blob result check is correct > > src/hotspot/share/runtime/

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]

rash > other that testing in our production where the crash is happening > sporadically. > However, thanks to @parttimenerd and his [ASGCT stress > test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be > reproduced quite reliably. > > > > _N

RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee

A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in

Re: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v5]

On Thu, 5 May 2022 10:29:07 GMT, Johannes Bechberger wrote: >> Calling JavaThread::thread_from_jni_environment for a terminated thread in >> AsyncGetCallTrace might cause the acquisition of a lock, making >> AsyncGetCallTrace non-signal-safe. >> >> AsyncGetCallTrace can only be called for

Re: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6]

On Thu, 14 Apr 2022 13:06:58 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and >> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` >> like it is done in >>

Re: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4]

On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and >> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` >> like it is done in >>

Re: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4]

On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and >> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` >> like it is done in >>

Re: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing

On Wed, 13 Apr 2022 15:29:00 GMT, Thomas Stuefe wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and >> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` >> like it is done in >>

Re: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing

On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger wrote: > Move the AsyncGetCallTrace method implementation into a separate method and > wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` > like it is done in >

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks [v4]

On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry wrote: >> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime >> stub (like arraycopy), a vtable stub, or the prolog of a compiled method, >> it wouldn't be able to detect the sender (caller) frame for multiple >> reasons.

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks [v2]

On Thu, 10 Jun 2021 07:50:57 GMT, Ludovic Henry wrote: >> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime >> stub (like arraycopy), a vtable stub, or the prolog of a compiled method, >> it wouldn't be able to detect the sender (caller) frame for multiple >> reasons.

Re: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation

Hi Jini, 'null' seems to be a valid value for 'data' field in both of the places you are using 'data.clone()' - you should guard for null and call 'clone()' only if the passed in value is non-null. Cheers, -JB- On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George wrote:

Re: RFR(S): JDK-8152950 BasicLauncherTest.java fails due to type error

Hi Dmitry, # http://cr.openjdk.java.net/~dsamersoff/JDK-8152950/webrev.03/hotspot_webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html L1752 - wording 'some commands is not available' -> 'some commands will not be available' #

Re: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException

a.net/~hb/8154166/webrev.02/ > > -Harsha > > > On Friday 29 April 2016 02:15 PM, Jaroslav Bachorik wrote: > > > > On Fri, Apr 29, 2016 at 6:20 AM, Harsha Wardhana B < > <harsha.wardhan...@oracle.com>harsha.wardhan...@oracle.com> wrote: > >>

Re: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException

in place unless it is > causing any side-effects. > No objections here. It does not break anything and makes the test intentions clearer. -JB- > > Thanks > Harsha > > > On Tuesday 26 April 2016 04:05 PM, Jaroslav Bachorik wrote: > > > > On Mon, Apr

Re: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException

ic and can intermittently fail. -JB- > > -Harsha > > > On Sunday 24 April 2016 03:17 PM, Jaroslav Bachorik wrote: > > The reproducer would be very time sensitive as with the provided > 'ExplicitGCInvokesConcurrent' it will run GC concurrently with the invoker. > Otherwise, in th

Re: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException

we start measuring memory. > Without the patch, GC might or might not happen. > > -Harsha > > > On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote: > > Hi, > > On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B < > <harsha.wardhan...@oracle.com>harsha.

Re: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException

Hi, On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B < harsha.wardhan...@oracle.com> wrote: > Hi, > > Please review the below simple fix for issue, > > issue : https://bugs.openjdk.java.net/browse/JDK-8154166 > webrev : >

Re: RFR(S, TESTONLY): JDK-8150318 serviceability/dcmd/jvmti/LoadAgentDcmdTest.java - Could not find JDK_DIR/lib/x86_64/libinstrument.so

Hi, On 29.2.2016 17:12, Dmitry Samersoff wrote: Everybody, Please review test changes: http://cr.openjdk.java.net/~dsamersoff/JDK-8150318/webrev.01/ Looks good - just a few nits. Please, update the copyright years accordingly.

RFR 8147987: Remove sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from problemList

Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8147987 Webrev: http://cr.openjdk.java.net/~jbachorik/8147987/webrev.00 This change removes sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from the ProblemList.txt. The fix for the issue

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

. Thanks for reviewing this! -JB- best regards, -- daniel On 18/02/16 09:48, Jaroslav Bachorik wrote: Hi, On 17.2.2016 14:41, Daniel Fuchs wrote: Thanks Jaroslav, that's great! If these certificates have an expiration date then it's possible that we will have to regenerate them from time

Re: RFR(xs): 8147442: Event-based tracing to allow for tracing Klass creation

Good to go! -JB- On 15.1.2016 10:52, Markus Gronlund wrote: Greetings, Please review this small change in order to allow for the Event-based tracing framework to trace the creation of Klass’es. Bug: https://bugs.openjdk.java.net/browse/JDK-8147442 Webrev:

Re: RFR : JDK-8147610 - javax/management/mxbean/MXBeanLoadingTest1.java assumes URLClassLoader

Looks good! -JB- On 9.2.2016 07:30, Harsha Wardhana B wrote: Hi All, I request you to review fix for, Issue : JDK-8147610 - javax/management/mxbean/MXBeanLoadingTest1.java assumes URLClassLoader Webrev : http://cr.openjdk.java.net/~hb/8147610/werev.00/ The fix is simple and

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

- cheers, -- daniel On 17/02/16 13:13, Jaroslav Bachorik wrote: On 16.2.2016 11:56, Daniel Fuchs wrote: Hi Jaroslav, I have no objection to this change. Could you add a comment somewhere to explain how you generated the truststore and keystore - in case we need to tweak that again

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

. http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03 -JB- best regards, -- daniel On 16/02/16 10:41, Jaroslav Bachorik wrote: On 11.2.2016 11:39, Jaroslav Bachorik wrote: Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 Webrev: http

[ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

On 11.2.2016 11:39, Jaroslav Bachorik wrote: Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02 The previous attempt to fix this problem was focused on the fact that the test tend

RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02 The previous attempt to fix this problem was focused on the fact that the test tend to fail on ARM64 platforms. This is no more

Re: [PING] Re: RFR (S): 8149112: configure_stdout test depends on VM arguments

Looks good! -JB- On 9.2.2016 10:33, Marcus Larsson wrote: On 02/05/2016 01:07 PM, Marcus Larsson wrote: Hi, Please review the following patch to make the configure_stdout internalvmtest independent on VM arguments for UL. Without this fix the test fails if run while logging to a file

Re: RFR(XS): JDK-8149099 jcmd -help mention non-existent option

On 5.2.2016 11:53, Dmitry Samersoff wrote: Everybody, Please, review typo fix provided by Kubota Yuji http://cr.openjdk.java.net/~dsamersoff/sponsorship/kubota.yuji/JDK-8149099/webrev.01/ Looks good! -JB- -Dmitry

Re: Fwd: RFR:8147847: (re-review) serviceability/tmtools/jstat tests are failing with -XX:+ExplicitGCInvokesConcurrent

On 5.2.2016 13:14, Alexander Kulyakhtin wrote: Hi, Could I, please, have any feedback on this trivial tests-only review? Thumbs up! -JB- Best regards, Alexander - Forwarded Message - From: alexander.kulyakh...@oracle.com To: serviceability-dev@openjdk.java.net Sent: Wednesday,

Re: RFR:8147847:serviceability/tmtools/jstat tests are failing with -XX:+ExplicitGCInvokesConcurrent

On 1.2.2016 13:59, Alexander Kulyakhtin wrote: Hi, Could you, please, review this trivial tests-only fix: CR: https://bugs.openjdk.java.net/browse/JDK-8147847 "serviceability/tmtools/jstat tests are failing with -XX:+ExplicitGCInvokesConcurrent" Webrev:

Re: JDK-8031753 : Review request

obably this is acceptable. I would welcome more comments and discussions around this change. Please do review and let me know your thoughts. (R)eviewed. Thanks! -JB- Thanks Harsha On Wednesday 27 January 2016 03:47 PM, Jaroslav Bachorik wrote: Hi Harsha, On 27.1.2016 11:09, Harsha Wardhana B

Re: JDK-8031753 : Review request

wrote: Gentle reminder :) On Monday 11 January 2016 02:51 PM, Jaroslav Bachorik wrote: [adding JMX dev list] On 8.1.2016 10:44, Harsha Wardhana B wrote: Hi All, Please review the fix for, Issue : JDK-8031753 <http://JDK-8031753> - JMXServiceURL should not use getLocalHost or its

Re: RFR(S): JDK-8148104 HSDB could not terminate when launched on CLI.

wrote: Hi Dmitry and Jaroslav, 2016-01-25 18:11 GMT+09:00 Jaroslav Bachorik <jaroslav.bacho...@oracle.com>: On 23.1.2016 12:13, Dmitry Samersoff wrote: Solution: Create frame before we initialize agent. While this solution will work in this case I think it would be better to dae

Re: RFR(S): JDK-8148104 HSDB could not terminate when launched on CLI.

On 23.1.2016 12:13, Dmitry Samersoff wrote: Everybody, Here is a small patch provided by KUBOTA Yuji. http://cr.openjdk.java.net/~dsamersoff/sponsorship/kubota.yuji/JDK-8148104/webrev.01/ The problem: Running HSDB by jhsdb on CLI i.e. without x11 display, HSDB could not terminate after

Re: jmx-dev [8] RFR(S): 8147857: RMIConnector logs attribute names incorrectly

On 22.1.2016 17:49, Seán Coffey wrote: On 22/01/16 15:58, Andrew Hughes wrote: >Yes - please fix this issue in JDK 9 first as per rule 1: >http://openjdk.java.net/projects/jdk8u/groundrules.html > >In a nutshell, produce a JDK 9 webrev, send it to >serviceability-dev@openjdk.java.net for

Re: [8] RFR(S): 8147857: RMIConnector logs attribute names incorrectly

On 21.1.2016 11:30, Severin Gehwolf wrote: Hi, Could somebody please review and sponsor this small 8u bugfix? This bug has been introduced with the January 2016 CPU fixes (JDK-8130710) and I've not seen this code in JDK 9 (yet?). Hence, posting this here. Bug:

Re: RFR: 8147609: Correct the @build statements in the serviceability/dcmd/gc/HeapDumpAllTest.java and HeapDumpTest.java tests

On 19.1.2016 16:32, Alexander Kulyakhtin wrote: Hi, Could you, please, review this trivial test-only change: CR: https://bugs.openjdk.java.net/browse/JDK-8147609 "Correct the @build statements in the serviceability/dcmd/gc/HeapDumpAllTest.java and HeapDumpTest.java tests" Webrev:

Re: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory

: Thursday, January 07, 2016 7:43 PM To: Sharath Ballal; Jaroslav Bachorik; serviceability-dev@openjdk.java.net Subject: Re: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory Hi, 524 * An application remotely accessing the platform MXBeans using

Re: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

On 14.1.2016 17:23, Severin Gehwolf wrote: Hi, On Wed, 2016-01-13 at 10:51 -0800, serguei.spit...@oracle.com wrote: > On 1/13/16 03:16, Jaroslav Bachorik wrote: >> On 12.1.2016 12:55, serguei.spit...@oracle.com wrote: >>> On 1/12/16 03:49, Jaroslav Bachorik wrote: >&

Re: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

On 15.1.2016 10:24, Severin Gehwolf wrote: Hi, On Fri, 2016-01-15 at 09:50 +0100, Jaroslav Bachorik wrote: Sorry for being late in the game with this. +private static List getAddressesForLocalHost() { + try { -addrs = InetAddress.getAllByName("loca

Re: RFR (XS): 8147079: Add serviceability/logging folder to hotspot_serviceability test group

Ship it! -JB- On 14.1.2016 16:09, Marcus Larsson wrote: Hi, Please review the following patch to add the serviceability/logging folder to the hotspot_serviceability test group. This will include the UL tests for JPRT runs. Webrev: http://cr.openjdk.java.net/~mlarsson/8147079/webrev.00/

Re: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

On 12.1.2016 12:55, serguei.spit...@oracle.com wrote: On 1/12/16 03:49, Jaroslav Bachorik wrote: On 12.1.2016 11:47, serguei.spit...@oracle.com wrote: On 1/7/16 08:40, Daniel Fuchs wrote: Hi, This looks OK to me. I'm not sure I understand the full impact of the changes

Re: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

On 13.1.2016 13:00, Daniel Fuchs wrote: On 13/01/16 12:16, Jaroslav Bachorik wrote: Thanks. I've added the explanation and also disambiguated the method name a bit. http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 It looks like no one else is going to jump in and verify

Re: RFR: JDK-8130063: Refactoring tmtools jstat and jstack tests to jtreg

Hi Alexander, On 12.1.2016 15:22, Alexander Kulyakhtin wrote: Hi, Could you, please, review the following test-only change CR: https://bugs.openjdk.java.net/browse/JDK-8130063 "Refactoring tmtools jstat and jstack tests to jtreg" WebRev: http://cr.openjdk.java.net/~akulyakh/8130063_01/ The

Re: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

st regards, -- daniel On 07/01/16 16:02, Jaroslav Bachorik wrote: On 5.1.2016 15:30, Jaroslav Bachorik wrote: On 4.1.2016 10:05, Jaroslav Bachorik wrote: Gentle reminder ... On 23.12.2015 11:26, Jaroslav Bachorik wrote: Please, review the following test change Issue : https://bugs.openjdk.java.

Re: JDK-8031753 : Review request

[adding JMX dev list] On 8.1.2016 10:44, Harsha Wardhana B wrote: Hi All, Please review the fix for, Issue : JDK-8031753 - JMXServiceURL should not use getLocalHost or its usage should be enhanced Webrev :

RFR 8146620: CodelistTest.java fails with "Test failed on: jdk.internal.misc.Unsafe.getUnsafe()Ljdk/internal/misc/Unsafe;"

Please, review the following simple test fix Issue : https://bugs.openjdk.java.net/rest/api/latest/issue/JDK-8146620 Webrev: http://cr.openjdk.java.net/~jbachorik/8146620/webrev.00 The test is treating the 'sun.misc.Unsafe.getUnsafe()' entry from the code list in a specific way - but since now

Re: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials

On 7.1.2016 17:32, Daniel Fuchs wrote: On 06/01/16 12:23, Jaroslav Bachorik wrote: On 6.1.2016 12:19, David Holmes wrote: On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 Webrev: http

Re: RFR 8146620: CodelistTest.java fails with "Test failed on: jdk.internal.misc.Unsafe.getUnsafe()Ljdk/internal/misc/Unsafe;"

On 8.1.2016 10:06, Staffan Larsen wrote: Looks good! Thanks! Thanks, /Staffan On 8 jan. 2016, at 09:57, Jaroslav Bachorik <jaroslav.bacho...@oracle.com> wrote: Please, review the following simple test fix Issue : https://bugs.openjdk.java.net/browse/JDK-8146620 Webrev

[ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

On 5.1.2016 15:30, Jaroslav Bachorik wrote: On 4.1.2016 10:05, Jaroslav Bachorik wrote: Gentle reminder ... On 23.12.2015 11:26, Jaroslav Bachorik wrote: Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 Webrev: http://cr.openjdk.java.net

Re: RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java

://cr.openjdk.java.net/~jbachorik/8143047/webrev.01 -JB- Éamonn 2016-01-05 5:52 GMT-08:00 Jaroslav Bachorik <jaroslav.bacho...@oracle.com <mailto:jaroslav.bacho...@oracle.com>>: On 4.1.2016 21:26, Eamonn McManus wrote: I think this test should either be deleted or reduced to a

RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials

Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 On AArch64 machines running multiple test rounds involving SSL connections in rapid succession leads to error during SSL handshake.

Re: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java

On 5.1.2016 15:00, Alan Bateman wrote: On 05/01/2016 13:52, Jaroslav Bachorik wrote: On 4.1.2016 21:26, Eamonn McManus wrote: I think this test should either be deleted or reduced to a simple check that the MBeanServerDelegate's ImplementationVersion attribute is equal to System.getProperty

[pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

On 4.1.2016 10:05, Jaroslav Bachorik wrote: Gentle reminder ... On 23.12.2015 11:26, Jaroslav Bachorik wrote: Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 The test fails

Re: RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java

references to 'sun.boot.class.path' for jigsaw. -JB- Éamonn 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik <jaroslav.bacho...@oracle.com <mailto:jaroslav.bacho...@oracle.com>>: Please, review the following simple change Issue : https://bugs.openjdk.java.net/browse/JDK-81

RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java

Please, review the following simple change Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 The patch removes the special path taken when jmxrmi.jar is present on the bootclasspath. There are two reasons for this cleanup:

[ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

Gentle reminder ... On 23.12.2015 11:26, Jaroslav Bachorik wrote: Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 The test fails for IPv6 addresses since the RMI expects an IPv6

Re: [PING] Potential infinite waiting at JMXConnection#createConnection

Hi Yuji, On 4.1.2016 15:14, KUBOTA Yuji wrote: Hi all, Could you please review this patch? Sorry for the long delay. Shanliang has not been present for some time and probably this slipped the attention of the others. However, core-libs mailing list might be more appropriate place to

Re: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java

On 4.1.2016 12:09, Alan Bateman wrote: On 04/01/2016 10:20, Jaroslav Bachorik wrote: Please, review the following simple change Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 The patch removes the special path taken

Re: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory

On 28.12.2015 18:01, Sharath Ballal wrote: Hi, Kindly review the changes for bug https://bugs.openjdk.java.net/browse/JDK-6659240 Webrev: http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.00/ Looks good! -JB- CCC request for the same is being raised in parallel. -Sharath

RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 The test fails for IPv6 addresses since the RMI expects an IPv6 address to be properly wrapped in '[]'. In addition to that the

Re: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the modular source layout

Hi, looks good, modulo the problems you are mentioning (docs will need update to refer to correct locations; the same might be true for the textual output from scripts). I believe the tests are still passing. Supposing the remaining problems are covered by CR you can consider this reviewed.

RFR 8145982: JMXInterfaceBindingTest is failing intermittently

Please, review this trivial test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145982 Webrev: http://cr.openjdk.java.net/~jbachorik/8145982/webrev.00 The test calls System.exit(0) in case when it is not applicable (due to HW configuration). This call is forbidden by the test harness

Re: JDK 9 RFR of JDK-8145869: Mark test JMXStartStopTest.java and TestJstatdServer.java as intermittently failing

Looks good! -JB- On 21.12.2015 05:53, Amy Lu wrote: sun/management/jmxremote/startstop/JMXStartStopTest.java sun/tools/jstatd/TestJstatdServer.java Above tests are known to fail intermittently, this patch is to mark the test accordingly with keyword 'intermittent'. bug:

[bump] Re: RFR 8145417: JInfoSanityTest failed with Error attaching to remote server: java.rmi.ConnectException: Connection refused

On 16.12.2015 15:36, Jaroslav Bachorik wrote: Please, review the following simple test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145417 Webrev: http://cr.openjdk.java.net/~jbachorik/8145417/webrev.00 The affected tests check for 'Unknown host' in stderr. In some situations

Re: RFR: JDK-8058865 JMX Test Refactoring

Hi, On 15.12.2015 19:19, olivier.lagn...@oracle.com wrote: Hi, Please review the following changes for task "JDK-8058865 : JMX Test Refactoring" Issue: https://bugs.openjdk.java.net/browse/JDK-8058865 Webrev: http://cr.openjdk.java.net/~olagneau/8058865/webrev.06/ Issue Description: " The

RFR 8145417: JInfoSanityTest failed with Error attaching to remote server: java.rmi.ConnectException: Connection refused

Please, review the following simple test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145417 Webrev: http://cr.openjdk.java.net/~jbachorik/8145417/webrev.00 The affected tests check for 'Unknown host' in stderr. In some situations this line may not appear, although an alternative

Re: RFR: 8145408: "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found"

On 16.12.2015 13:05, Alexander Kulyakhtin wrote: Hi, Could you, please, review this small test-only fix: CR: https://bugs.openjdk.java.net/browse/JDK-8145408 "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" Webrev:

Re: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management)

On 15.12.2015 08:03, Alan Bateman wrote: On 14/12/2015 16:55, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 The problem is that the class

Re: RFR : JDK-6744127 - NullPointerException at com.sun.tools.jdi.EventRequestManagerImpl.request

Hi, On 14.12.2015 08:32, Harsha Wardhana B wrote: Hi All, Please review the fix for bug, Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 Webrev : http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.00 The fix synchronizes access to requestList of

RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management)

Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 The problem is that the class UsageTrackerClient is accessing RuntimeMXBean.getInputArguments() method via reflection to avoid static

[ding] Re: jmx-dev RFR 8142398: ManagementAgent.status diagnostic command only outputs the specifically set properties

On 11.11.2015 16:52, Jaroslav Bachorik wrote: Please, review the following change Pretty please - it's been sitting here unnoticed for almost 30 days despite regular pings. Shouldn't be that hard ... -JB- Issue : https://bugs.openjdk.java.net/browse/JDK-8142398 Webrev: http

  1   2   3   4   5   6   7   8   9   >