Re: CFV: New Serviceability Group Lead: Serguei Spitsyn

Vote: yes On Tue, 4 Apr 2017 at 16:03 Tim Bell wrote: > Vote: yes > > Tim > > On 04/04/17 06:46, Daniel D. Daugherty wrote: > > I hereby nominate Serguei Spitsyn to Serviceability Group Lead > >

Re: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received!

Spurious wakeups can cause wait() to finish early in which case the while loop is needed. But the timeout to wait() doesn’t add anything. And if the while loop is there the next statement is not needed: 112 if (li.received < 1) { 113 throw new RuntimeException("No notif rece

Re: RFR(S): 8168305 GC.class_stats should not require -XX:+UnlockDiagnosticVMOptions

Thanks Ioi! > On 27 Oct 2016, at 19:21, Ioi Lam wrote: > > Looks good. > > Thanks > - Ioi > > On 10/27/16 2:41 AM, Marcus Larsson wrote: >> Hi Staffan, >> >> >> On 2016-10-27 10:36, Staffan Larsen wrote: >>> All, >>> >

Re: RFR(S): 8168305 GC.class_stats should not require -XX:+UnlockDiagnosticVMOptions

> On 27 Oct 2016, at 20:15, David Holmes wrote: > > On 27/10/2016 6:36 PM, Staffan Larsen wrote: >> All, >> >> Please review this small patch to remove the requirement >> -XX:+UnlockDiagnosticVMOptions when running the GC.class_stats diagnostic >> co

Re: RFR(S): 8168305 GC.class_stats should not require -XX:+UnlockDiagnosticVMOptions

> On 27 Oct 2016, at 11:41, Marcus Larsson wrote: > > Hi Staffan, > > > On 2016-10-27 10:36, Staffan Larsen wrote: >> All, >> >> Please review this small patch to remove the requirement >> -XX:+UnlockDiagnosticVMOptions when running the GC.clas

RFR(S): 8168305 GC.class_stats should not require -XX:+UnlockDiagnosticVMOptions

All, Please review this small patch to remove the requirement -XX:+UnlockDiagnosticVMOptions when running the GC.class_stats diagnostic command. Diagnostic commands are used for diagnosing problems and should not require restarting the JVM with a different command line flag if this can be avoi

Re: RFR: JDK-8168397 : sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build

Looks good! Thanks, /Staffan > On 27 Oct 2016, at 06:57, Sharath Ballal wrote: > > Hello, > After the fix for JDK-8160376 > - DebuggerException: Can't > attach symbolicator to the process, > I have removed BasicLauncherTest.java & HeapDump

Re: RFR: 8168479: Backout the changes for JDK-8168478

Looks good! Thanks, /Staffan > On 21 Oct 2016, at 15:25, Alexander Kulyakhtin > wrote: > > Hi Dmitry, > > Thank you very much for the review/ I've changed the CR title. > > Waiting for a (R)eviwer to approve this trivial one-line quarantine. > > Best regards, > Alexander > > - Origina

Re: RFR: 8164501: Uninitialised memory in byteArrayToPacket of SharedMemoryConnection.c

t; On 10/21/2016 01:11 PM, Robbin Ehn wrote: >> Hi Staffan, thanks for having a look. >> >> On 10/21/2016 11:28 AM, Staffan Larsen wrote: >>> Can you change: >>> >>> 185 if (total_length < 11) { >>> >>> to >>> &g

Re: RFR: 8164501: Uninitialised memory in byteArrayToPacket of SharedMemoryConnection.c

Can you change: 185 if (total_length < 11) { to 185 if (total_length < sizeof(pktHeader) { ? > On 21 Oct 2016, at 09:41, Robbin Ehn wrote: > > Hi all, please review! > > This patch makes sure pktHeader is not used uninitialized and that > total_length is at least 11. > The bug is

Re: RFR: JDK-8165114: stale reference to hotspot test Test8028623.java

Looks good! Thanks, /Staffan > On 1 sep. 2016, at 10:00, Sharath Ballal wrote: > > Hello, > Please review this fix to remove stale test reference: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8165114 > > Webrev: http://cr.openjdk.jav

Re: [PING] RFR: 8150894: Unused -Xlog tag sequences are silently ignored.

Looks ok to me. /Staffan > On 25 aug. 2016, at 09:51, Marcus Larsson wrote: > > > On 08/23/2016 01:17 PM, Marcus Larsson wrote: >> Hi, >> >> Still looking for a Reviewer for this. (Rebased webrev in-place.) >> >> Thanks, >> Marcus >> >> >> On 04/12/2016 04:14 PM, Marcus Larsson wrote: >>>

Re: RFR: 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22"

Looks good. Thanks, /Staffan > On 23 aug. 2016, at 19:36, Jini Susan George wrote: > > I need one more reviewer, please ! > > Thanks, > Jini. > >> -Original Message- >> From: Jini Susan George >> Sent: Tuesday, August 23, 2016 11:48 AM >> To: Dmitry Samersoff; serviceability-dev@openj

Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly

Looks good! Thanks, /Staffan > On 18 aug. 2016, at 07:53, Amit Sapre wrote: > > Guys, > I need one more person to review these changes. Kindly help with the review. > Thanks, > Amit > > -Original Message- > From: David Holmes > Sent: Thursday, August 11, 2016 5:55 AM > To: Amit Sapre;

Re: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found

s. :) > > Thanks, > David > > On 16/08/2016 4:15 AM, Staffan Larsen wrote: >> All, >> >> Please review this fix for a test that starting failing after recent changes >> to java.lang.invoke. >> >> The test instructs jdb to break on all exc

Re: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot

Ok. Reviewed. /Staffan > On 16 aug. 2016, at 08:15, Harsha Wardhana B > wrote: > > Yes. assertEQorGTE can be used. But using assertEQorLTE is better suited as > it increase code readability. So I would like to leave that in place. > > > On Saturday 13 August 2016

Re: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found

Thank you! > On 15 aug. 2016, at 20:27, Dmitry Samersoff > wrote: > > Staffan, > > Looks good for me! > > -Dmitry > > > On 2016-08-15 21:15, Staffan Larsen wrote: >> All, >> >> Please review this fix for a test that starting f

RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found

All, Please review this fix for a test that starting failing after recent changes to java.lang.invoke. The test instructs jdb to break on all exceptions matching "java.lang.I*" (that's a capital 'i'). The semantics of that operation actually means "break on all exceptions which have a class n

Re: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot

brev incorporating Staffan's comments. > > http://cr.openjdk.java.net/~hb/8151345/webrev.01/ > > Thanks > Harsha > > On Friday 12 August 2016 01:59 PM, Staffan Larsen wrote: >> Harsha, >> >> Thanks for the explanation! With that in mind the new code looks co

Re: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot

Harsha, Thanks for the explanation! With that in mind the new code looks correct, although I would probably make it even more obvious in which order getUsage() and getPeakUsage() is executed by calling them on separate lines before the call to assertEQorLTE() instead of relying on the order met

Re: RFR: JDK-8159155 Loading the class "sun.tools.jconsole.OutputViewer" shows a modal dialog

> On 13 juni 2016, at 10:11, Alan Bateman wrote: > > On 13/06/2016 08:57, Staffan Larsen wrote: > >> Please review the small diff below - see the bug for details. This change >> will cause OutputViewer to misbehave if init() is called more than once. But >> sinc

RFR: JDK-8159155 Loading the class "sun.tools.jconsole.OutputViewer" shows a modal dialog

Please review the small diff below - see the bug for details. This change will cause OutputViewer to misbehave if init() is called more than once. But since this is an internal class in jconsole, that restriction is not a problem bug: https://bugs.openjdk.java.net/browse/JDK-8159155

Re: RFR: 8072440: serviceability/dcmd/ tests timeout

Looks good! Thanks, /Staffan > On 10 juni 2016, at 09:27, Robbin Ehn wrote: > > Hi all, > > I can not reproduce running the tests mutiple times on mutiple platforms. > And I can not see anything particular in test code. > So I'm removing the @ignore flag for these. > > Bug: https://bugs.openj

Re: RFR: 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly

Looks good! Thanks, /Staffan > On 2 juni 2016, at 11:41, Robbin Ehn wrote: > > Hi Dmitry, thanks for looking at this. > > On 06/01/2016 07:59 PM, Dmitry Samersoff wrote: >> Robbin, >> >> ProcessArgumentMatcher.java:61 >> >>What is the reason of keeping singlePid as a string. It might be

Re: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode

t; > timeout_factor=`echo $TESTTIMEOUTFACTOR | > awk '{printf "%3.0f\n", $1}'` > > It uses the same synax as the rest of script and round value rather than > truncate it. > > -Dmitry > > On 2016-05-23 12:17, Staffan Larsen wrote: >>

Re: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode

> On 24 maj 2016, at 09:06, serguei.spit...@oracle.com wrote: > > On 5/24/16 00:01, serguei.spit...@oracle.com > <mailto:serguei.spit...@oracle.com> wrote: >> On 5/23/16 23:35, Staffan Larsen wrote: >>> >>>> On 23 maj 2016, at 23:39, >>

Re: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode

the jtreg tests. It is set by jtreg. See: http://openjdk.java.net/jtreg/tag-spec.html#testvars > > Thanks, > Serguei > > > On 5/23/16 02:17, Staffan Larsen wrote: >> This is my second attempt at fixing this timeout by taking the jtreg timeout >> factor into ac

RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode

This is my second attempt at fixing this timeout by taking the jtreg timeout factor into account in the tests. The first fix [1] looked at the wrong environment variable, and also would have caused the test to run unnecessarily slow since it set sleep_seconds to a higher value instead of changin

Re: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception

>> gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with >> java.lang.Exception >> >> Staffan, >> >>> The GC.heap_info Diagnostic Command should really be updated to >>> contain a lot more information (similar to what SA produces). >>

Re: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception

Looks good! The GC.heap_info Diagnostic Command should really be updated to contain a lot more information (similar to what SA produces). Should we file an enhancement for that? Thanks, /Staffan > On 12 maj 2016, at 15:25, Dmitry Samersoff > wrote: > > Everybody, > > Please review test ch

Re: 8154985: Add the ability to use main class as lookup (as jcmd) to jinfo, jmap, jstack

Looks good! Thanks, /Staffan > On 9 maj 2016, at 16:10, Robbin Ehn wrote: > > Hi all, > > Please review this enhancement for jinfo, jstack and jmap. > > It is based on top of "8155091: Remove SA related functions from tmtools" > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-M

Re: RFR(M): v.05, 8155091: Remove SA related functions from tmtools

Looks good! Thanks, /Staffan > On 6 maj 2016, at 15:18, Dmitry Samersoff wrote: > > Everybody, > > Please, see updated webrev. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ > > Removed ToolProvider interface. run(String ... args) function removed or > renamed to runWithAr

Re: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely

This is > 85 // not an error, and we just ignore it. > 86 } > 87 } > 88 if (message != null) { > 89 MessageOutput.lnprint(message); > 90 MessageOutput.println(); > 91 } > 92 System.exit(0); > 93 } > > > -Sharath Ballal > > > From: Staffan Larsen >

Re: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely

Hi Sharath, Can you explain more how this help with the problem in the bug? It looks like you are trying to avoid a race by not printing the "Input stream closed.” message while shutting down. You added this: 136 ((TTY)notifier).setShuttingDown(true); 137 Env.shutdown(

Re: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on()

Looks good! Thanks, /Staffan > On 20 apr. 2016, at 13:47, Robbin Ehn wrote: > > Hi all, please review! > > print() method was changed in 8154041 to have outputStream argument, this > renames print to print_on. > Since JvmtiBreakpoint extends GrowableElement print_on already exists as a > vir

Re: bug in JVMTI

What bug is this on bugs.openjdk.java.net ? > On 18 apr. 2016, at 20:09, k...@kodewerk.com wrote: > > Hi all, > > For almost a year (j)VisualVM (jFluid) has been running into this JVMTI bug. > > # Problematic frame: > # V [libjvm.dylib+0x44691c] > Method::check

Re: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump

Looks good! Thanks, /Staffan > On 12 apr. 2016, at 18:05, Andreas Eriksson > wrote: > > Hi, > > Please review this fix for 8153641: assert(thread_state == _thread_in_native) > failed: Assumed thread_in_native while heap dump > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153641 >

Re: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1

r bad, what other dependencies there are on sun.java.command and what the impact will be... > > -Dmitry > > > On 2016-04-12 22:06, Staffan Larsen wrote: >> Thanks for the explanation. The change looks good. >> >> Do you know if the change in jps output was inten

Re: RFR: 8154064: JVMTI trace event crashes

Looks good! Thanks, /Staffan > On 13 apr. 2016, at 07:50, Robbin Ehn wrote: > > Hi all, > > Please review this bug fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154064 > > Test with tonga. (the 5 crashed tonga test no longer crashes) > > Thanks! > > /Robbin > > diff -r 4823056a5

Re: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1

Thanks for the explanation. The change looks good. Do you know if the change in jps output was intentional or caused by something else? > On 12 apr. 2016, at 16:32, Dmitry Samersoff > wrote: > > Staffan, > > On 2016-04-12 16:32, Staffan Larsen wrote: >> Can you

Re: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1

Can you explain what is going on here? It looks like the old code looked for the TTY process, whereas the new code accepts any process. What am I missing? > On 12 apr. 2016, at 14:28, Dmitry Samersoff > wrote: > > Everybody, > > Please review a small fix. > > http://cr.openjdk.java.net/~dsam

Re: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing

en fail. > > -Dmitry > > On 2016-04-08 11:10, Staffan Larsen wrote: >> Why did this test start failing? >> >>> On 7 apr. 2016, at 20:35, serguei.spit...@oracle.com wrote: >>> >>> Dmitry, >>> >>> I agree with Tim. >>> T

Re: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing

Why did this test start failing? > On 7 apr. 2016, at 20:35, serguei.spit...@oracle.com wrote: > > Dmitry, > > I agree with Tim. > The message at L85 should not be alarming but look similar to the one at L107. > Something, like this: > 85System.out.println("This test is not expected to

Re: RFR (S): 8153174: Remove trailing comma from log configuration listings

Looks good! Thanks, /Staffan > On 31 mars 2016, at 12:40, Marcus Larsson wrote: > > Hi, > > Please review the following small patch to avoid adding a trailing comma in > the tagset and level listings in the configuration string for log outputs. > Removing this comma allows the string to be u

Re: javaone 2012 presentation on Diagnosing Your Application on the JVM : Question on attach on Windows

> On 30 mars 2016, at 09:40, Bacchu, Anjan wrote: > > Hi Staffan, > > I just now saw the presentation slides at > http://www.slideshare.net/stalar/diagnosing-your-application-on-the-jvm > . > > On Slide 16 of th

Re: RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies

Thanks Serguei! > On 22 mars 2016, at 19:10, serguei.spit...@oracle.com wrote: > > On 3/22/16 11:09, Staffan Larsen wrote: >> >>> On 22 mars 2016, at 18:15, >>> <mailto:serguei.spit...@oracle.com>serguei.spit...@oracle.com >>> <mailto:ser

Re: RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies

Thread.sleep(sleepSeconds * 1000); > Or an increase is because of the "test.timeout.factor" property? Yes, the increase will be because outside systems will set the timeout factor. /Staffan > Thanks, Serguei On 3/22/16 07:14, Staffan Larsen wrote: &

Re: RFR(S): JDK-8151444 JDP not working on some windows configurations

Looks good! Thanks, /Staffan > On 22 mars 2016, at 12:51, Dmitry Samersoff > wrote: > > Everybody, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8151444/webrev.01/ > > Removed code attempts to set IP_MULTICAST_IF to enforce sending of JDP > packets to all availab

Re: RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies

Anyone up for a review of this change? > On 21 mars 2016, at 09:16, Staffan Larsen wrote: > > Hi, > > For a while we have had various timeout related problem in the JDI tests. The > root cause of this seems to be the Indy String Concatenation work which makes > stepping

Re: RFR: 8151887 com/sun/jdi/RedefineClearBreakpoint.sh failed with timeout

re testing code paths that are different from what our users will see. /Staffan > > -Dmitry > > > On 2016-03-21 11:22, Staffan Larsen wrote: >> Hi, >> >> See the JIRA issue or my recent review request of JDK-7153107 for a >> discussion about the ca

Re: RFR : JDK-8151797 - java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent results

; > -Harsha > > On Friday 18 March 2016 05:01 PM, Staffan Larsen wrote: >> You should move the Arrays.stream trigger call to before the >> ManagementFactory.getThreadMXBean, otherwise the threads you get from >> ThreadMXBean will not match the threads you get from the Thr

RFR: 8151887 com/sun/jdi/RedefineClearBreakpoint.sh failed with timeout

Hi, See the JIRA issue or my recent review request of JDK-7153107 for a discussion about the cause of this timeout. In this change I am changing the ShellScaffold to take the jtreg timeoutfactor into account. This allow more time for these tests on slower platforms. The timeoutfactor is a flo

RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies

Hi, For a while we have had various timeout related problem in the JDI tests. The root cause of this seems to be the Indy String Concatenation work which makes stepping over the first string concatenation horrendously slow in debug version of the jdk. It is not ISC itself that is to blame, inst

Re: RFR : JDK-8151797 - java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent results

You should move the Arrays.stream trigger call to before the ManagementFactory.getThreadMXBean, otherwise the threads you get from ThreadMXBean will not match the threads you get from the ThreadGroups. > On 18 mars 2016, at 12:17, Harsha Wardhana B > wrote: > > Hello All, > > Please review f

Re: RFR: JDK-8151196 Several tests fail due to test library not found

ev > [mailto:serviceability-dev-boun...@openjdk.java.net] On Behalf Of Staffan > Larsen > Sent: Wednesday, March 9, 2016 5:03 AM > To: Bengt Rutisson > Cc: serviceability-dev@openjdk.java.net; hotspot-gc-...@openjdk.java.net > Subject: Re: RFR: JDK-8151196 Several tests fail due to test l

Re: RFR: JDK-8151196 Several tests fail due to test library not found

too... > > Thanks, > Bengt > > On 2016-03-09 10:47, Staffan Larsen wrote: >> Please review this small fix to some tests with the wrong paths in them. >> Tested locally with jtreg 4.1 b12 and b13. >> >> Thanks, >> /Staffan >> >> >> $

RFR: JDK-8151196 Several tests fail due to test library not found

Please review this small fix to some tests with the wrong paths in them. Tested locally with jtreg 4.1 b12 and b13. Thanks, /Staffan $ hg diff diff --git a/test/gc/g1/plab/TestPLABPromotion.java b/test/gc/g1/plab/TestPLABPromotion.java --- a/test/gc/g1/plab/TestPLABPromotion.java +++ b/test/gc

Re: JDK-6291341: jstat: FGC counter confusing when CMS GC is used

The jdk changes look good to me. Jon, if you integrate the JVM changes you can do the jdk changes at the same time in the hs-rt repo. Thanks, /Staffan > On 8 mars 2016, at 23:08, Jon Masamitsu wrote: > > Yasumasa, > > We're discussing this. > > What would the result be if the GC team made t

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

Looks good! Thanks, /Staffan > On 19 feb. 2016, at 03:57, Jaroslav Bachorik > wrote: > > 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/managemen

Re: RFR:8150067:Quarantine serviceability/tmtools/jstat/GcCapacityTest.java test

Looks good! Thanks, /Staffan > On 17 feb. 2016, at 16:54, Alexander Kulyakhtin > wrote: > > Hi, > > Could you, please, review this trivial test-only change (quarantining the > test): > > CR: https://bugs.openjdk.java.net/browse/JDK-8150067 > Webrev: > http://cr.openjdk.java.net/~akulyakh/8

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

Looks good! Thanks, /Staffan > On 5 feb. 2016, at 13:14, Alexander Kulyakhtin > wrote: > > Hi, > > Could I, please, have any feedback on this trivial tests-only review? > > Best regards, > Alexander > > - Forwarded Message - > From: alexander.kulyakh...@oracle.com > To: serviceabili

Re: RFR(xs): 8144916: Decrease PerfDataMemorySize back to 32K

Looks good! Thanks, /Staffan > On 3 feb. 2016, at 16:55, Robbin Ehn wrote: > > Hi, please review. > > This sets PerfDataMemorySize back to 32k and > removes "-XX:PerfDataMemorySize=64k" in PrologSizeSanityCheck test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144916 > Webrev: http://c

Re: RFR: JDK-8147447: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails

gt;> Please, let me know if I'm missing something. >> >> Best regards, >> Alexandr >> >> - Original Message - >> From: daniel.daughe...@oracle.com >> To: staffan.lar...@oracle.com, alexander.kulyakh...@oracle.com >> Cc: serviceabi

Re: RFR(S, TESTONLY): JDK-8148315 Create a basic reproducer for JDI issues

eproducer, find it helpful, and > would like to have it in the test library. > > -Dmitry > > > On 2016-01-27 10:23, Staffan Larsen wrote: >> Can you explain more? There is very little information here or in the >> bug about what problem you are trying to solve. Why are

Re: RFR: 8147348: LogTagLevelExpression not properly initialized in configure_stdout

Looks good! Thanks, /Staffan > On 21 jan. 2016, at 11:42, Marcus Larsson wrote: > > Hi, > > Please review the following patch to fix an initialization error in > LogTagLevelExpression. If not using the parse() method (as is the case in > LogConfiguration::configure_stdout) instances of the c

Re: RFR(S, TESTONLY): JDK-8148315 Create a basic reproducer for JDI issues

Can you explain more? There is very little information here or in the bug about what problem you are trying to solve. Why aren’t the current JDI tests (jdk/test/com/sun/jdi) sufficient? I have not read your code, and I would like more background before I do so. > On 26 jan. 2016, at 22:53, Dmit

Re: RFR(xs): 8148053: Remove unused log tags

Looks good! Thanks, /Staffan > On 22 jan. 2016, at 16:00, Robbin Ehn wrote: > > Hi, > > Please review, this removes unused tags in UL. > > Testing: > Passed RBT build > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148053 > Webrev: http://cr.openjdk.java.net/~mlarsson/rehn/8148053/ > > T

Re: RFR: 8146009: "pure virtual method called" with using new GC logging mechanism

> On 22 jan. 2016, at 13:21, David Holmes wrote: > > On 22/01/2016 3:00 AM, Thomas Stüfe wrote: >> Hi, >> >> On Wed, Jan 20, 2016 at 2:01 PM, k...@kodewerk.com >> > > wrote: >> >> >>> On Jan 20, 2016, at 5:20 AM, David Holmes >

Re: RFR: JDK-8147388: Add diagnostic commands to attach JVMTI agent.

llvm.org/compatibility.html#vla > >> <http://clang.llvm.org/compatibility.html#vla> > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >> On 2016/01/18 19:38

Re: RFR: JDK-8147447: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails

: JDK-8147447: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails > > On 1/21/16 8:11 AM, Staffan Larsen wrote: >>> On 21 jan. 2016, at 15:33, Alexander Kulyakhtin >>> wrote: >>> >>> Staffan, >>> >>> Would i

Re: RFR: JDK-8147447: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails

> On 21 jan. 2016, at 15:33, Alexander Kulyakhtin > wrote: > > Staffan, > > Would it be sufficient to modify the code so that isCompMode() returns true > if and only if the -Xcomp option is present and is not followed by the > -Xmixed option? Maybe, but that looks fragile. What if there is

Re: RFR: JDK-8147447: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails

isCompMode() will fail if the VM is started with both -Xcomp and -Xmixed. We need to find a better way to check if compiled mode is being used. Perhaps System.getProperty("java.vm.info").contains("compiled”) ? /Staffan > On 19 jan. 2016, at 11:59, Alexander Kulyakhtin > wrote: > > Hi, > > C

Re: RFR: 8147848: tmtools tests ported to JTREG need to be quarantined

Looks good! Thanks, /Staffan > On 20 jan. 2016, at 17:50, Alexander Kulyakhtin > wrote: > > Hi, > > Could you, please, review this quarantine request: > > CR: https://bugs.openjdk.java.net/browse/JDK-8147848 > "https://bugs.openjdk.java.net/browse/JDK-8147848"; > Webrev: http://cr.openjdk.j

Re: RFR: JDK-8147388: Add diagnostic commands to attach JVMTI agent.

will add it. However, I note you that _libpath is given >>>>>>>> mandatory flag. >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-January/018661.html >>>>>>>> >>>>>>>> >>&g

Re: RFR: JDK-8147388: Add diagnostic commands to attach JVMTI agent.

This is a good improvement overall. The new diagnostic commands need to have proper permissions set: static const JavaPermission permission() { JavaPermission p = {"java.lang.management.ManagementPermission", “control", NULL}; return p; } And as David sa

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

Looks good! Thanks, /Staffan > On 8 jan. 2016, at 09:57, Jaroslav Bachorik > wrote: > > 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 t

Re: [PING] RFR: 8145294: TestLogRotation.java triggers a race in the UL framework

Looks good! Thanks, /Staffan > On 18 dec. 2015, at 14:01, Marcus Larsson wrote: > > > > On 2015-12-16 09:46, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to fix a race in file rotations with UL. >> >> Summary: >> freopen and fwrite are not safe to use concurrently an

Re: RFR: 8141211: Convert TraceExceptions to Unified Logging

> On 18 dec. 2015, at 14:06, David Holmes wrote: > > On 18/12/2015 7:14 PM, Bengt Rutisson wrote: >> >> >> On 2015-12-18 06:44, David Holmes wrote: >>> On 17/12/2015 6:41 PM, Bengt Rutisson wrote: On 2015-12-16 22:43, Coleen Phillimore wrote: > On 12/16/15 4:01 PM, John Rose wrote: >>

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

Looks good! Thanks, /Staffan > On 16 dec. 2015, at 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" > Web

Re: [PING] RFR: 8144220: UL does not support full path names for log files on windows

Looks good! Thanks, /Staffan > On 11 dec. 2015, at 13:49, Marcus Larsson wrote: > > Need another review for this. > > On 2015-12-03 11:11, Marcus Larsson wrote: >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.ne

Re: RFR: JDK-8145099 Better error message when SA can't attach to a process

orking on that. > > OK. > >> It should get filled in in the ptrace_attach() call. > > if ph->pid == thr->lwp_id at ll. 409 the function return NULL but > doesn't touch err_buf. if ph->pid == thr->lwp_id the if-statement is skipped and we continue in the

Re: RFR: JDK-8145099 Better error message when SA can't attach to a process

rno from ptrace_attach/Pgrab is > available there. > > (except calloc case, but if we can't allocate couple of bytes for struct > ps_prochandle we most likely will not see the error anyway). > > > -Dmitry > > > On 2015-12-10 18:10, Staffan Larsen wrote

Re: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot)

or the hotspot > sub-patch for this webrev and commit-message, to not sideeffect-close the > main-issue in the JBS. > > -- > Sebastian > > > On 12/10/2015 03:56 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >&

Re: RFR: JDK-8145099 Better error message when SA can't attach to a process

Thanks! > On 10 dec. 2015, at 15:26, Jaroslav Bachorik > wrote: > > On 10.12.2015 15:22, Staffan Larsen wrote: >> Hi Thommas, >> >>> On 10 dec. 2015, at 14:49, Thomas Stüfe >> <mailto:thomas.stu...@gmail.com>> wrote: >>> >>&g

Re: RFR: JDK-8145099 Better error message when SA can't attach to a process

Thanks! > On 10 dec. 2015, at 15:56, Thomas Stüfe wrote: > > Hi Staffan, > > this looks fine now, thanks! > > ..Thomas > > On Thu, Dec 10, 2015 at 3:42 PM, Staffan Larsen <mailto:staffan.lar...@oracle.com>> wrote: > Hi Thomas, >

Re: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot)

Looks good! Thanks, /Staffan > On 10 dec. 2015, at 15:44, Coleen Phillimore > wrote: > > > Adding serviceability-dev. They work on this code. > Coleen > > > On 12/10/15 12:38 AM, Sebastian Sickelmann wrote: >> @Adding hotspot-runtime-dev >> >> Hi, >> >> a want to restart a discussion/rev

Re: RFR: JDK-8145099 Better error message when SA can't attach to a process

check the return value for NULL, though). Updated here: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.03/ <http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.03/> Thanks, /Staffan > > sorry for this piecemeal review. > > Kind Regards, Thomas > > &

Re: RFR: JDK-8145099 Better error message when SA can't attach to a process

n, at least on posix platforms. Good point. I was just being overly cautious without thinking. Updated webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ <http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/> Thanks, /Staffan > > Otherwise this looks good. > &

RFR: JDK-8145099 Better error message when SA can't attach to a process

Please review this patch to add a better error message to SA when it fails to attach to a process on linux. Currently the error says "Can't attach to the process”. After this change the message will look something like: "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 28417: Op

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

Looks good! Thanks, /Staffan > On 10 dec. 2015, at 12:07, Jaroslav Bachorik > wrote: > > 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 har

Re: RFR: 8144146: Unified Logging tags cannot be reserved keywords

Looks good! Thanks, /Staffan > On 4 dec. 2015, at 15:46, Marcus Larsson wrote: > > Hi, > > Please review the following patch to allow C++ reserved keywords to be used > as UL tags. This allows usage of a 'class' tag, for example. > > Tags are now automatically prefixed with underscores by th

Re: RFR 8144308: com/sun/jdi/SuspendThreadTest.java failed with "transport error 202: send failed: Broken pipe"

Looks good! Thanks, /Staffan > On 1 dec. 2015, at 18:33, Jaroslav Bachorik > wrote: > > Please, review the following simple test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8144308 > Webrev: http://cr.openjdk.java.net/~jbachorik/8144308/webrev.00 > > The test keeps the debugg

Re: PING: RFR: JDK-8140556: Add force rotation option to VM.log jcmd

Looks good! Thanks, /Staffan > On 3 dec. 2015, at 04:33, Yasumasa Suenaga wrote: > > PING: Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ > > I need reviewer and sponsor. > > Thanks, > > Yasumasa > > 2015/11/15 21:50 "Yasumasa Suenaga" : >> >> PING: Cou

Re: RFR : JDK-8139985: JNI exception pending in jdk/src/jdk/hprof/agent/share/native/libhprof/

Looks good! Thanks, /Staffan > On 2 dec. 2015, at 04:33, Jini George wrote: > > Hi all, > > This is a review request for the following defect related to Parfait cleanup: > > https://bugs.openjdk.java.net/browse/JDK-8139985 > (JNI exception

Re: RFR: 8142952: Unified Logging framework does not allow multiple -Xlog: arguments

Looks good! Thanks, /Staffan > On 26 nov. 2015, at 16:17, Marcus Larsson wrote: > > Hi, > > New webrev after offline review with Bengt and Staffan: > http://cr.openjdk.java.net/~mlarsson/8142952/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8142952/webrev.00-01/ > > Chan

Re: RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot

A couple of comments: debug.cpp: - When exiting due to ExitOnOutOfMemoryError I think we should print that we are exiting to tty. - Perhaps the exit value should be made unique so that one can see the cause of the exit? TestCrashOnOutOfMemoryError.java - L33: nit: Don’t use * imports, list all

Re: RFR 8043138: Attach API should not require jvmstat rmi protocol

> On 24 nov. 2015, at 17:03, Jaroslav Bachorik > wrote: > > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8043138 > Webrevs: > * top level: http://cr.openjdk.java.net/~jbachorik/8043138/webrev.00/top > * jdk: http://cr.openjdk.java.net/~jbachorik/8043

Re: JDK 9 RFR of JDK-8143583: Several tests don't work with latest jtreg due to non-existing files in @build

Looks good! Thanks, /Staffan > On 23 nov. 2015, at 08:10, Amy Lu wrote: > > Below tests failed with latest nightly jtreg due to non-existing files in > @build > > com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java > sun/tools/jmap/BasicJMapTest.java > com/sun/jdi/DoubleAgentTest.java >

Re: [PING] RFR (XS): 8142483: Unified logging log instances cause warnings on windows when only static functions are used

Looks good! Thanks, /Staffan > On 20 nov. 2015, at 13:29, Marcus Larsson wrote: > > Need another review for this! > > Thanks, > Marcus > > On 2015-11-13 10:20, Marcus Larsson wrote: >> Hi, >> >> Please review the following small patch to avoid 'unused variable' warnings >> on windows when o

Re: Technical question about the Java Dependency Analysis Tool

Hi Richard, I think a better list for this question is either core-libs-dev@ or jigsaw-dev@. Thanks /Staffan > On 6 nov. 2015, at 12:11, Richard Callahan wrote: > > Hi, > > I have a specific question about the output from the Java Dependency Analysis > Tool (JDeps), released with Open JDK 8

  1   2   3   4   5   6   7   8   9   10   >