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 > >

Resigning as Serviceability Group Lead

Hi, Since I have recently changed jobs, I will no longer have time to engage in the serviceability side of OpenJDK. Thus I herby resign as the Serviceability Group Lead. Regards, /Staffan

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

/serviceability/sa/TestInstanceKlassSizeForInterface.java bug: https://bugs.openjdk.java.net/browse/JDK-8168305 webrev: http://cr.openjdk.java.net/~sla/8168305/webrev.01/ Thanks, /Staffan

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 > <https://bugs.openjdk.java.net/browse/JDK-8160376> - DebuggerException: Can't > attach symbolicator to the process, > I hav

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. &

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

Looks good! Thanks, /Staffan > On 21 Oct 2016, at 14:01, Robbin Ehn wrote: > > Hi again. > > Correct http webrev location should be: > http://cr.openjdk.java.net/~rehn/8164501/01/webrev/ > http://cr.openjdk.java.net/~rehn/8164501/01_inc/webrev/ > > /Robbin > &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 > <https://bugs.openjdk.java.net/browse/JDK

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 >>

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 >

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,

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

the filter, the exception is reported to the debugger. When using patterns for matching, the debugger sets up such filters for all classes that match the pattern (this does sound a bit inefficient). /Staffan > On 15 aug. 2016, at 22:46, David Holmes wrote: > > Hi Staffan, >

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

g.Il* cmd catch all java.lang.Ind* This will still match the exception types the test is looking for (IllegalArgumentException, IllegalMonitorStateException, and IndexOutOfBoundsException), but it will not match IncompatibleClassChangeError. Thanks, /Staffan diff --git a/test/com/su

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

method parameters are evaluated. Relying on the order of evaluation is correct, but doing explicit calls would make it a lot more obvious that the order is important. Thanks, /Staffan > On 12 aug. 2016, at 10:07, Harsha Wardhana B > wrote: > > Hello, > > I forgot to put-

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

tps://bugs.openjdk.java.net/browse/JDK-8159155> Thanks, /Staffan diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/OutputViewer.java b/src/jdk.jconsole/share/classes/sun/tools/jconsole/OutputViewer.java --- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/OutputViewer.java +++

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

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

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

Yes, that would have been a little better. Unfortunately I have already pushed the change. Let me know if you think it is important enough to fix. /Staffan > On 24 maj 2016, at 10:42, Dmitry Samersoff > wrote: > > Staffan, > > 37: It's better to write it as: &g

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

> On 23 maj 2016, at 23:39, serguei.spit...@oracle.com wrote: > > Staffan, > > I do not see any issues, the fix looks good to me. Thanks! > One question though. > > Where does the TESTTIMEOUTFACTOR environment variable come from? > I do not see it used anywhere in

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

-8157555 <https://bugs.openjdk.java.net/browse/JDK-8157555>webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ <http://cr.openjdk.java.net/~sla/8157555/webrev.00/> Thanks, /Staffan [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc

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

gt; - Original Message - >> From: dmitry.samers...@oracle.com >> To: staffan.lar...@oracle.com >> Cc: serviceability-dev@openjdk.java.net, hotspot-gc-...@openjdk.java.net >> Sent: Thursday, May 12, 2016 5:30:26 PM GMT +03:00 Iraq >> Subject: Re: RFR(S): JDK-8156769

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, > >

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

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) funct

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

Hi Sharath, Ah, I see: it is the call to System.exit() that is causing readLine to return. That makes sense, and I now understand the fix. Reviewed. Thanks, /Staffan > On 28 apr. 2016, at 10:25, Sharath Ballal wrote: > > Hi Staffan, > The root cause of this pro

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

tdown(shutdownMessageKey); The call on line 137 will result in a System.exit(0) call if I am reading the code right. So adding the shutdown flag to line 136 will maybe make the race smaller, but isn’t really solving it? What kind of testing have you run this fix through? Thanks, /Staffan &g

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_o

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.

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

> On 13 apr. 2016, at 11:06, Dmitry Samersoff > wrote: > > Staffan, > >> Do you know if the change in jps output was intentional or caused by >> something else? > > Sorry, I don't know what change jps output. The problem is that the sun.java.command pr

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) > >

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

I see - thanks! > On 8 apr. 2016, at 11:54, Dmitry Samersoff > wrote: > > Staffan, > > I suspect its because of root/non-root. OS X attach doesn't work for > non-root user. Test check it and skips silently. But if the test run > under root, it tries to run and th

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 al

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 > <http://www.slideshare.net/stalar/diagnosing-your-application-on-the-jv

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

> On 22 mars 2016, at 18:15, serguei.spit...@oracle.com wrote: > > Hi Staffan, > > It looks good. > One question though. > > I do not see that the timeout is increased in the > com/sun/jdi/InterruptHangTest.java. > It remains 20 sec as was before. > > +

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 s

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

On 21 mars 2016, at 09:47, Dmitry Samersoff wrote: > > Staffan, > > Looks good for me. Thanks! > > You may also consider to add -XDstringConcat=inline to javac options in > ShellScaffold I have considered it, but I’m reluctant to do it since it would mean that we a

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

Looks good! Thanks, /Staffan > On 21 mars 2016, at 05:10, Harsha Wardhana B > wrote: > > Hello, > > Please review the new patch located at, > > http://cr.openjdk.java.net/~hb/8151797/webrev.01/ > <http://cr.openjdk.java.net/%7Ehb/8151797/webrev.01/> >

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

://cr.openjdk.java.net/~sla/8151887/webrev.00/test/com/sun/jdi/ShellScaffold.sh.sdiff.html bug: https://bugs.openjdk.java.net/browse/JDK-8151887 Thanks, /Staffan

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

://cr.openjdk.java.net/~sla/7153107/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-7153107 Thanks, /Staffan

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

Christian, Bengt: Thanks for the reviews. Pushing now. > On 9 mars 2016, at 11:29, Christian Tornqvist > wrote: > > Hi Staffan, > > Looks good, thanks for fixing this. > > Thanks, > Christian > > -Original Message- > From: serviceability-d

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

t; | vm.gc=="null" * @requires vm.opt.FlightRecorder != true - * @library /testlibrary /../../test/lib / + * @library /testlibrary /test/lib / * @modules java.management * @build ClassFileInstaller *sun.hotspot.WhiteBox > On 9 mars 2016, at 10:54, Bengt Rutisson wr

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

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 res

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 > >

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: > htt

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:

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

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

Looks good! I assume you have tested this with -Xcomp and -Xint. Thanks, /Staffan > On 28 jan. 2016, at 11:20, Alexander Kulyakhtin > wrote: > > Hi Staffan, > > I've changed the test fix for > https://bugs.openjdk.java.net/browse/JDK-8147447 > &

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

Have you looked at the com/sun/jdi test framework? The java framework is quite good and stable. The shell script framework should be removed. /Staffan > On 27 jan. 2016, at 13:02, Dmitry Samersoff > wrote: > > Staffan, > > 1. This is one more small step forward to remo

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_std

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.openjd

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.

> -- > > If you think that this code should NOT be available in dcmd, I will remove > vm_exit_out_of_memory() from it. Yes, please remove it and use output()->print() to signal an error instead. /Staffan > > > Thanks, > > Yasumasa > > > 2016-01-2

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

the option specified last > takes precedence. I think it would be fine to always assume -Xmixed mode and succeed if any of the frames matches. It would make the code simpler and easier to maintain. /Staffan > > Please, let me know if I'm missing something. > > Best regar

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 f

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

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/bro

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.

} And as David said: tests! See hotspot/test/serviceability/dcmd/jvmti. Thanks, /Staffan > On 14 jan. 2016, at 15:00, Yasumasa Suenaga wrote: > > Hi all, > > We can use Attach API to attach JVMTI agent to live process. > However, we have to write Java code for it. > >

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/webre

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: >>

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: Req

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

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

> On 11 dec. 2015, at 11:54, Dmitry Samersoff > wrote: > > Staffan, > >> This is all platform specific code - and all the platforms are >> different. Of course, it would be good if all platforms reported good >> error message always - and we can continue w

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

> On 10 dec. 2015, at 23:20, Dmitry Samersoff > wrote: > > Staffan, > > 1. > > strerror_r comes in two versions - returning string (GNU) and returning > int (XSI) > > To make developers live more interesting GNU version doesn't guarantee > to fill

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

> On 10 dec. 2015, at 17:58, Sebastian Sickelmann > wrote: > > Thanks for the reviews so far. > > I am not sure how the serviceability thing need to be handled. Should > there be a review-result of a serviceability-member? > I think nether david or staffan are membe

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 >> >&

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

Hi Thomas, > On 10 dec. 2015, at 15:27, Thomas Stüfe wrote: > > Hi Staffan, > > thanks! > > It also just occurred to me that strerror is not considered threadsafe. Maybe > strerror_r() would a better option (depending on the version you use you > would have to

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

..) failed for 28417: Operation not permitted” webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ <http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 <https://bugs.openjdk.java.net/browse/JDK-8145099> Thanks, /Staffan

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 >

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 automati

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 &g

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

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 > <https://bugs.openjdk.java.net

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/~ml

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

“@run driver” mode. - L41: If -Xmx is set high enough, this allocation will succeed (or is my math wrong?). You should set an explicit -Xmx value on L46 when starting the JVM. Thanks, /Staffan > On 25 nov. 2015, at 13:40, cheleswer sahu wrote: > > Hi, > > Please review the c

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/

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 

  1   2   3   4   5   6   7   8   9   10   >