Re: RFR (S): 6461635: [TESTBUG] BasicTests.sh test fails intermittently

/browse/JDK-6461635 -- Leonid Mesnik JVM SQE

Re: RFR (S): 6461635: [TESTBUG] BasicTests.sh test fails intermittently

expected exit codes. Thanks, Mattias Webrev: http://cr.openjdk.java.net/~miauno/6461635/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-6461635 -- Leonid Mesnik JVM SQE

Re: RFR (S): 6461635: [TESTBUG] BasicTests.sh test fails intermittently

/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-6461635 -- Leonid Mesnik JVM SQE -- Leonid Mesnik JVM SQE

Re: Review quest for JDK-7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently

. I need to see the webrev to provide further feedback. Mandy -- Leonid Mesnik JVM SQE

Re: Review quest for JDK-7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently

On 11/28/2013 04:33 PM, Staffan Larsen wrote: On 28 nov 2013, at 11:16, Leonid Mesnik leonid.mes...@oracle.com mailto:leonid.mes...@oracle.com wrote: Eric, Mandy Sorry that I looping on very late step. It is not a review just suggestion. We have whitebox API in Hotspot which includes

Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing

: https://bugs.openjdk.java.net/browse/JDK-8030628 Mattias -- Leonid Mesnik JVM SQE

Re: RFR: 8027230: Overflow in java.lang.instrument.Instrumentation.getObjectSize() method

Peter 35 * @run main/othervm -Xmx4000m -javaagent:agent.jar GetObjectSizeOverflowAgent I think that -Xmx4000m cause test failure for 32-bit VM. It would be better to use another 1 process builder. Also I think you need to add your test into need_jdk because you use jar. Could you please

Re: RFR: 8027230: Overflow in java.lang.instrument.Instrumentation.getObjectSize() method

david.hol...@oracle.com wrote: On 21/05/2014 1:19 AM, Leonid Mesnik wrote: Peter 35 * @run main/othervm -Xmx4000m -javaagent:agent.jar GetObjectSizeOverflowAgent I think that -Xmx4000m cause test failure for 32-bit VM. It would be better to use another 1 process builder. If you need a 4GB heap

Re: RFR (M): 8054278: Refactor jps utility tests

Katya I am not reviewing tests, just have small comment. I think it would be better to use '@run driver' instead of '@run main' in these tests. Leonid On 14.08.2014 15:40, Yekaterina Kantserova wrote: Hi, Could I please have a review of this fix.

Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

Hi I don't think that sleep is a good way to ensure that thread is started. It is not reliable on the slow host / VM under stress and just waste of time on fast host. Is it possible just to add any explicit synchronization to ensure that NamedThread is started? Leonid On 05.04.2016 13:23,

Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

: Leonid Mesnik Sent: Tuesday, April 05, 2016 7:00 PM To: Cheleswer Sahu; hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Hi I don't think that sleep is a good way

RFR(XXS): 8156777: [TESTBUG] test/testlibrary_tests/SimpleClassFileLoadHookTest.java requires non minimal VM

Hi Could you please review this extra small fix which add @requires to the single test. This test is not compatible with minimal VM even it doesn't require any specific modules outside compact2. So I've just added corresponding @requires.

Re: RFR(XXS): 8156777: [TESTBUG] test/testlibrary_tests/SimpleClassFileLoadHookTest.java requires non minimal VM

Chris, Misha, George Thank you for review. Leonid On 12.05.2016 14:21, Christian Tornqvist wrote: Hi Leonid, Change looks good. Thanks, Christian On May 11, 2016, at 12:36 PM, Leonid Mesnik <leonid.mes...@oracle.com <mailto:leonid.mes...@oracle.com>> wrote: Hi Could you p

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

Please use following alias for compiler tests (hotspot/test/compiler): hotspot-compiler-...@openjdk.java.net Leonid On 08.08.2016 17:09, Harsha wardhana B wrote: Gentle Reminder !! On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: Hello All, Please review the below simple test fix for the

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

As I know compact groups are not used in JDK9 testing. Leonid On 02.09.2016 15:29, Christian Tornqvist wrote: Do we still need the compact groups? I thought the @modules selection in jtreg will make sure that we don't run tests where the module isn't available. -Original Message-

Re: RFR(XS): 8155570: serviceability/tmtools/jstat/GcTest02.java fails with parallel GC

Let me put following comment in eatMetaspaceAndHeap method: @Override public void eatMetaspaceAndHeap(float targetMemoryUsagePercent) { +// Metaspace should be filled before Java Heap to prevent unexpected OOME +// in the Java Heap while filling Metaspace +

RFR(XS): 8155570: serviceability/tmtools/jstat/GcTest02.java fails with parallel GC

Hi Could you please review following fix: Webrev: http://cr.openjdk.java.net/~lmesnik/8155570/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8155570 Test filled java heap up to 70% and then failed with OOME in the java

Re: RFR(XS): 8155570: serviceability/tmtools/jstat/GcTest02.java fails with parallel GC

Thank you for review! Still waiting for official 'R'eview. Leonid On 04.10.2016 16:36, Dmitry Fazunenko wrote: Hi Leonid, The fix looks good to me. Thanks, Dima On 04.10.2016 11:23, Leonid Mesnik wrote: Hi Could you please review following fix: Webrev: http://cr.openjdk.java.net

RFR: 8203491: [TESTBUG] Port heapdump tests into java

Hi Could you please review following patch which rewrite vmTestbase/heapdump tests as a jtreg java tests. These heapdump tests were developed as a shell tests which verify heapdump functionality in JDK 5. They work fine but needs some refactoring. webrev:

Re: RFR: 8203491: [TESTBUG] Port heapdump tests into java

ing HEAP_OOME = "heap"; >public static String METASPACE_OOME = "metaspace"; > > These could be declared as public static final String. > > Thanks, > Jini. > > > > On 5/25/2018 4:37 AM, Leonid Mesnik wrote: >> Hi >> Thanks for feedback. It

Re: RFR: 8203491: [TESTBUG] Port heapdump tests into java

wrote: > > Hi Leonid, > > My comments inline. > > On 5/24/2018 12:09 AM, Leonid Mesnik wrote: > >> I am not sure that JMapMetaspaceCore provides any additional coverage. The >> test just fill 64M of metaspace and then send signal to dump core. So I >>

Re: RFR: 8203491: [TESTBUG] Port heapdump tests into java

> a good idea as we lose atomicity of test results/executions. could you please > split TestHeapDumpOnOutOfMemoryError into independent tests? > > -- Igor > >> On May 24, 2018, at 10:54 AM, Leonid Mesnik <leonid.mes...@oracle.com> wrote: >> >> Hi >>

Re: RFR: 8203491: [TESTBUG] Port heapdump tests into java

tps://bugs.openjdk.java.net/browse/JDK-8023376 > > https://bugs.openjdk.java.net/browse/JDK-8051445 > > Corresponding tests were excluded for a long time so there are no any > > results for them. I also see comments in bugs with unsuccessful attempts > > to reproduce issues.

RFR(XXS): 8204103: Mark test serviceability/dcmd/compiler/CompilerQueueTest.java as intermittent and exclude it from tier1

Hi Please review following tiny fix which marks test serviceability/dcmd/compiler/CompilerQueueTest.java as intermittent and exclude it from tier1. The test intermittently fails (1-2 times in 1000 runs) because of https://bugs.openjdk.java.net/browse/JDK-8158374

Re: RFR(XXS): 8204103: Mark test serviceability/dcmd/compiler/CompilerQueueTest.java as intermittent and exclude it from tier1

Thanks, > Vladimir > > On 5/31/18 10:11 AM, Leonid Mesnik wrote: >> Hi >> Please review following tiny fix which marks test >> serviceability/dcmd/compiler/CompilerQueueTest.java as intermittent and >> exclude it from tier1. >> The test intermitt

Re: RFR(XXS): 8204103: Mark test serviceability/dcmd/compiler/CompilerQueueTest.java as intermittent and exclude it from tier1

Thank you. Leonid > On Jun 4, 2018, at 5:09 PM, jesper.wilhelms...@oracle.com wrote: > > Looks good. > I'll sponsor this change. > /Jesper > >> On 31 May 2018, at 19:59, Leonid Mesnik wrote: >> >> Thank you for review. >> >> It becomes

Re: RFR(XS): 8200187: Exclude 3 long-running tests from tier1

wever during testing like PIT we might just run whole hotspot_[component] team even some subset was run always in CI. Leonid > thanks, > > Chris > > On 3/26/18 4:32 PM, Leonid Mesnik wrote: >> Hi >> >> There is no strict rules and time budgets for hotspot tiers

Re: RFR(XS): 8200187: Exclude 3 long-running tests from tier1

PM, David Holmes <david.hol...@oracle.com> wrote: > > Hi Leonid, > > On 24/03/2018 9:31 AM, Leonid Mesnik wrote: >> Hi >> Could you please review following fix which exclude following tests from >> tier1 testing: >> serviceability/sa/ClhsdbScanOops.java >&g

RFR(XS): 8200187: Exclude 3 long-running tests from tier1

Hi Could you please review following fix which exclude following tests from tier1 testing: serviceability/sa/ClhsdbScanOops.java serviceability/sa/TestHeapDumpForLargeArray.java gc/g1/ihop/TestIHOPErgo.java Each of them takes more then 5 minutes to complete and significantly increase overall

Re: For-Test: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks

iting threads >>>> and if vm thread is running an VM op."); // fatal/guarantee >>>> SkipGCALot sgcalot(t);// avoid re-entrant attempts to gc-a-lot >>>> >>>> >>>> >>>> >>>> >>>>>>> >>>>

RFR(XXS): 8214462: Add serviceability/sa/ClhsdbInspect.java to ProblemList.txt

Hi Could you please review following trivial fix which just exclude test ClhsdbInspect.java from execution on Windows where it might hang because of https://bugs.openjdk.java.net/browse/JDK-8213457. bug: https://bugs.openjdk.java.net/browse/JDK-8214462 diff: diff -r 1d520c376105

RFR(XS): 8215042: Move serviceability/sa tests from tier1 to tier3.

Hi Could you please review following fix which moves SA tests from tier1 to tier3. There are some bugs which cause intermittent failures of any test. SA tests fail intermittently are not stable enough for tier1. However failures are not very frequent. Also I don't think that putting all test

Re: RFR(XS): 8215042: Move serviceability/sa tests from tier1 to tier3.

o get these tests in). > > Thank you, > Jini. > > On 12/8/2018 4:48 PM, David Holmes wrote: >> Hi Leonid, >> My concern here, if we care about keeping the SA operational, is that in >> tier3 these tests will not be covered by the jdk/submit testing proc

Re: RFR(XS): 8215042: Move serviceability/sa tests from tier1 to tier3.

am > mistaken. We will work on fixing that issue faster. > > Thanks, > Jini. > > On 12/10/2018 12:51 PM, Leonid Mesnik wrote: >> David, Jini >> I understand your concerns. But the original idea of tiered testing is that >> tier1 failures are treated as urgent i

Re: RFR (round 5), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi The shared tests changes looks good for me. Thank you for fixing and testing different combinations. Leonid > On Dec 3, 2018, at 11:10 PM, Roman Kennke wrote: > > Round 5 of Shenandoah review includes: > - A fix for the @requires tag in TestFullGCCountTest.java. It should be > correct

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi I looked at the tests changes only. It seems that  a some tests might start failing if JDK built without Shenandoah GC. Also some test are not going to be selected as expected. Unfortunately logic of '@requires' and @run in jtreg tests doesn't always work well for specific cases of

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Thank you for your fixes and additional testing. I'll check new version  in the round-2. Leonid On 11/28/18 10:36 AM, Roman Kennke wrote: Hi Leonid, I looked at the tests changes only. It seems that  a some tests might start failing if JDK built without Shenandoah GC. Also some test

Re: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out

gt; > On 1/4/2019 2:38 AM, Chris Plummer wrote: >> On 1/3/19 11:37 AM, Leonid Mesnik wrote: >>> >>>> On Jan 3, 2019, at 10:26 AM, Jini George wrote: >>>> >>>> Thank you very much, Chris, for taking a look. I will modify the timeout >>>&g

Re: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out

> On Jan 3, 2019, at 10:26 AM, Jini George wrote: > > Thank you very much, Chris, for taking a look. I will modify the timeout > value to be 480 ==> 8 minutes ==> 32 minutes for tier1. Sounds good ? > I think it makes a sense to move this test out of tier1. It takes too long time for

Re: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes

Gary Just want to add that following code 68 } catch (OutOfMemoryError me) { 69 me.printStackTrace(); 70 } might throw another OOME in printStackTrace(). If you want to do something after OOME it is needed to free some before trying to allocate. Leonid >

Re: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes

rms. > Please add this information into bug, to make clear that this change was intentional. > Please let me know what you'd like the description to say to bring it up to > date. I think that it is enough just to change PermGen to Metaspace. Leonid > > On 3/7/19, 4:06 PM, Leonid Mesni

Re: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes

Hi The problemlist http://cr.openjdk.java.net/~gadams/8218128/webrev.00/test/hotspot/jtreg/ProblemList.txt.udiff.html Tests are excluded because of https://bugs.openjdk.java.net/browse/JDK-6606767 which is not fixed yet. Why do you want to remove them from problemlist? Also I think it is a

RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash.

Hi Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 passed. webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ bug:

Re: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash.

> > Hi Leonid, > > It looks good to me. > One minor comment on the src/hotspot/share/services/diagnosticCommand.?pp > + DCmdArgument _granularity; > > I'm curios if using size_t instead of jlong as in other files would be more > unified. > > Thanks, > Serguei >

Re: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash.

no CSR is needed for this small help update. Any advise is welcome. Leonid > On Jun 7, 2019, at 9:48 AM, serguei.spit...@oracle.com wrote: > > Okay then. > I wonder now, if a CSR needs to be filed for this change. > > Thanks, > Serguei > > > On 6/7/19 09:10, Leonid

Re: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash.

Thank you for review. Leonid > On Jun 7, 2019, at 11:29 AM, serguei.spit...@oracle.com wrote: > > On 6/7/19 11:23, Leonid Mesnik wrote: >> I read documentation about CRS on following wiki >> https://wiki.openjdk.java.net/display/csr >> <https://wiki.openjdk.

Re: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash.

Thanks, > Tobias > > On 07.06.19 02:36, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix which verify parameter for >> Compiler.CodeHeap_Analytics >> command. So jcmd just exits instead of crashing target VM. Regression test >> was ad

Re: A Bug about the JVM Attach mechanism

I think it is https://bugs.openjdk.java.net/browse/JDK-8225193 The jcmd failed to attach if /tmp/.java_pid* is removed. It doesn't find file which is used as listener socket and send signal to start attach listener. (It suppose that listener

Re: RFR: 8229957: Harden pid verification in attach mechanism

Thank you. Leonid On 8/21/19 4:47 PM, Yasumasa Suenaga wrote: Looks good! Yasumasa (ysuenaga) 2019年8月22日(木) 2:38 Leonid Mesnik <mailto:leonid.mes...@oracle.com>>: Yasumasa, Severin Thank you, I updated condition. Agree that pid might be equal 1 for java in c

Re: RFR: 8229957: Harden pid verification in attach mechanism

Yasumasa, Severin Thank you, I updated condition. Agree that pid might be equal 1 for java in containers on linux and also might be for some specific configuration with other OS. Se let just check that it is at least positive. http://cr.openjdk.java.net/~lmesnik/8229957/webrev.01/ Leonid

RFR: 8229957: Harden pid verification in attach mechanism

Hi Could you review following fix which add sanity check of pid value in attach mechanism on *nix based platforms. PID for java process is always positive on affected OS. Hotspot internally uses signal (SIGQUIT) while attaching. So using negative numbers as pid might cause very unexpected

Re: RFR: 8230830: No required ResourceMark in src/hotspot/share/prims/jvmtiImpl.cpp:JvmtiSuspendControl::print()

Hi It is still needed for vframe *vf = vframeFor(java_thread, depth); Leonid > On Sep 11, 2019, at 5:56 AM, Daniel D. Daugherty > wrote: > > On 9/11/19 1:06 AM, Leonid Mesnik wrote: >> Hi >> >> Thank you for feedback. >> >>> On Sep 10, 2019, a

Re: RFR: 8230830: No required ResourceMark in src/hotspot/share/prims/jvmtiImpl.cpp:JvmtiSuspendControl::print()

David, Daniel, Serguei, Chris Thank you for review. Leonid > On Sep 11, 2019, at 4:38 PM, Daniel D. Daugherty > wrote: > > Thanks for chasing that down. I'm good with your change. > > Dan > > > On 9/11/19 6:45 PM, Leonid Mesnik wrote: >> Hi >> &

RFR: 8230881: serviceability/sa/TestJmapCore tests fail with java.lang.RuntimeException: Could not find dump file

Hi Could you please verify following fix which update core filename patterns. Some hosts are configured to compress core files during core dump. In such cases tests should throw skipped exception instead of failing reading compressed cores. Fixing all tests to support unpacking core.pid.gz

Re: RFR: 8230830: No required ResourceMark in src/hotspot/share/prims/jvmtiImpl.cpp:JvmtiSuspendControl::print()

Hi Thank you for feedback. > On Sep 10, 2019, at 10:03 PM, David Holmes wrote: > > Hi Leonid, > > On 11/09/2019 12:03 pm, Leonid Mesnik wrote: >> Hi >> Could you please review following tiny fix which just add ResourceMark in >> JvmtiSuspendControl

RFR: 8230830: No required ResourceMark in src/hotspot/share/prims/jvmtiImpl.cpp:JvmtiSuspendControl::print()

Hi Could you please review following tiny fix which just add ResourceMark in JvmtiSuspendControl::print() method. The method jvmtiSuspendControl::print() might used in custom builds only for debugging purposes. So I don't know when it was used last time. I found that it crashes when I tried

Re: RFR: 8230881: serviceability/sa/TestJmapCore tests fail with java.lang.RuntimeException: Could not find dump file

racle.com wrote: > > Hi Leonid, > > +1 > > Thanks, > Serguei > > On 9/12/19 4:46 PM, David Holmes wrote: >> Looks good! >> >> Thanks for fixing. >> >> David >> >> On 13/09/2019 2:56 am, Leonid Mesnik wrote: >>>

RFR: 8230942: Support compressed cores in SA tests

Hi Some hosts used for JDK testing have customized core dump settings. They compress core files saved in current directory on-the-fly to reduce required disk space. This fix adopt several SA tests, trying to unpack core.pid.gz before test process it with jhsdb. It affects only execution in the

Re: RFR: 8230942: Support compressed cores in SA tests

comments: http://cr.openjdk.java.net/~lmesnik/8230942/webrev.01/ <http://cr.openjdk.java.net/~lmesnik/8230942/webrev.01/> Leonid > On Sep 26, 2019, at 7:00 PM, David Holmes wrote: > > Hi Leonid, > > On 27/09/2019 7:18 am, Leonid Mesnik wrote: >> Hi >> Some hosts use

Re: [UNVERIFIED SENDER] RFR(XXS): 8231768: Remove duplicate if/else in vmTestbase/nsk/share/jdi/Binder.java

Thank you for review. Leonid > On Oct 2, 2019, at 11:14 AM, Hohensee, Paul wrote: > > Looks good. > > Paul > > From: serviceability-dev <mailto:serviceability-dev-boun...@openjdk.java.net>> on behalf of Leonid > Mesnik mailto:leonid.mes...@oracle.com>

RFR(XXS): 8231768: Remove duplicate if/else in vmTestbase/nsk/share/jdi/Binder.java

Hi Could you please review following tiny and trivial fix which just remove duplicated if/else branch in nsk/share/jdi/Binder class. Verified that all tests still pass locally. webrev: http://cr.openjdk.java.net/~lmesnik/8231768/webrev.00/

Re: RFR(XXS): 8231768: Remove duplicate if/else in vmTestbase/nsk/share/jdi/Binder.java

Thank you, I updated copyright. Leonid > On Oct 2, 2019, at 12:48 PM, Chris Plummer wrote: > > Looks good. Please update the copyright. > > thanks, > > Chris > > On 10/2/19 11:11 AM, Leonid Mesnik wrote: >> Hi >> >> Could you please review fol

Re: ClhsdbCDSCore jtreg test fails on OSX

Hi The location of core files depends on system configuration. So test tries to find core files using test output and searching core files in current directory. See details here: http://hg.openjdk.java.net/jdk/jdk/file/6f98d0173a72/test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java#l206

Re: ClhsdbCDSCore jtreg test fails on OSX

inding core files. Also, there's some partial logic for looking up core > files under test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java. Maybe > these should be consolidated into the test library? > > Thanks > - Ioi > > On 11/4/19 9:46 AM, Leonid Mesnik wrote: >>

Re: RFC 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement

the vm.opt.TieredCompilation != true requirement. I've done the changes in place. Thanks, Richard. -Original Message- From: hotspot-compiler-dev On Behalf Of Leonid Mesnik Sent: Dienstag, 12. November 2019 20:34 To: hotspot-compiler-...@openjdk.java.net Subject: Re: RFC 8233915: JVMTI FollowReferences

Re: RFR: 8235530: Removed duplicated threadByName methods in nsk/jdi tests

RuntimeException, but that's a different issue. Thanks, David On 8/12/2019 2:30 pm, serguei.spit...@oracle.com wrote: Hi Leonid, The fix looks good. Thank you for taking care about it! I agree, it is an awful duplication. Thanks, Serguei On 12/7/19 18:17, Leonid Mesnik wrote: Hi Could you please

RFR: 8235530: Removed duplicated threadByName methods in nsk/jdi tests

Hi Could you please review following fix which just remove duplicated threadByName methods and JDITestRuntimeException exceptions in nsk/jdi tests. I don't see any reason to have so many copies of them. The method threadByName is added nsk.share.jdi.Debugee class as 'threadByNameOrThrow'

Re: RFR (XS) 8236917: TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match"

Hi The fix looks good itself (you still need 'R'eview). However I see about 20 other SA/ tests where lingeredApp is still executed with vm.opts only. Even it doesn't cause any failures it means that tests silently ignore java.opts set by user. I think it makes sense to fix them also or file

Re: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean

Thank you for review. Filed https://bugs.openjdk.java.net/browse/JDK-8242328 Leonid On 4/7/20 4:31 PM, Igor Ignatyev wrote: On Apr 7, 2020, at 4:26 PM, Leonid Mesnik <mailto:leonid.mes...@oracle.com>> wrote: I didn't want to touch unrelated files and spread this fix outside v

RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean

Hi Could you please review following fix which just moves content of ThreadMBean back into ThreadMXBean. webrev: http://cr.openjdk.java.net/~lmesnik/8242295/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8242295

Re: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean

ThreadMBean w/ ThreadMXBean in test descriptions, e.g. at L#33 of test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001/TestDescription.java? Thanks, -- Igor On Apr 7, 2020, at 2:46 PM, Leonid Mesnik <mailto:leonid.mes...@oracle.com>> wr

Re: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean

occurrences, other files just one) -- Igor On Apr 7, 2020, at 3:56 PM, Leonid Mesnik <mailto:leonid.mes...@oracle.com>> wrote: Sure I've updated ThreadMBean to ThreadMXBean in test descriptions for ThreadMXBean tests . http://cr.openjdk.java.net/~lmesnik/8242295/webrev.01/ Leonid On 4/

Re: RFR(XS) 8242265: serviceability/sa/ClhsdbScanOops.java fails due to bad @requires expression

Looks good, thank you for fixing this. Leonid > On Apr 7, 2020, at 9:57 PM, Chris Plummer wrote: > > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242265 > > diff --git a/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java >

Re: RFR(XS) 8242168: ClhsdbFindPC.java failed due to "RuntimeException: 'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr"

Looks good (not a Reviewer). Leonid On 4/5/20 11:49 PM, Chris Plummer wrote: [Sorry about the resend. Subject wasn't quite right the first time.] Hello, Please help review the following: https://bugs.openjdk.java.net/browse/JDK-8242168

Re: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

t;, because it's too alike the other concept. Some suggestions:  startAppJavaOptions  startAppUsingJavaOptions  startAppWithJavaOptions  startAppExactJavaOptions  startAppJvmOptions Thanks, StefanK Thanks, -- Igor On Mar 25, 2020, at 8:55 AM, Leonid Mesnik wrote: Hi Could you please review fol

Re: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

ks, StefanK Thanks, -- Igor On Mar 25, 2020, at 8:55 AM, Leonid Mesnik wrote: Hi Could you please review following fix which change LingeredApp to prepend vm options to java/vm.test.opts when startApp is used and provide startAppVmOpts to override options completely. The intention is to avoid

Re: RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization

On 3/26/20 4:06 PM, David Holmes wrote: Hi Leonid, On 27/03/2020 7:39 am, Leonid Mesnik wrote: Replying with correct summary. Leonid On 3/23/20 8:55 PM, Leonid Mesnik wrote: Hi Could you please review following fix which update ThreadsRunner to use AtomicInteger/spinOnWait instead

RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization

Replying with correct summary. Leonid On 3/23/20 8:55 PM, Leonid Mesnik wrote: Hi Could you please review following fix which update ThreadsRunner to use AtomicInteger/spinOnWait instead of Wicket to synchronize starting of stress test threads. Failing tests allocated all memory by earlier

Re: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

lmesnik/8240698/webrev.02/test/hotspot/jtreg/serviceability/sa/ClhsdbJstack.java.udiff.html Leonid Thanks, -- Igor On Mar 25, 2020, at 2:31 PM, Leonid Mesnik <mailto:leonid.mes...@oracle.com>> wrote: Igor, Stefan, Ioi Thank you for your feedback. Filed https://bugs.openjdk.jav

Re: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

svc tests continue to do that they were supposed to, so I'd prefer for someone from svc team to chime in. Thanks, -- Igor On Mar 25, 2020, at 12:01 PM, Leonid Mesnik <mailto:leonid.mes...@oracle.com>> wrote: Added Ioi, who also proposed new version of startAppVmOpts. Please fin

Re: RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization

On 3/26/20 4:29 PM, David Holmes wrote: On 27/03/2020 9:16 am, Leonid Mesnik wrote: On 3/26/20 4:06 PM, David Holmes wrote: Hi Leonid, On 27/03/2020 7:39 am, Leonid Mesnik wrote: Replying with correct summary. Leonid On 3/23/20 8:55 PM, Leonid Mesnik wrote: Hi Could you please review

Re: RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization

Thank you for review. I still waiting for one more review. Leonid On 4/1/20 9:18 PM, David Holmes wrote: Looks good - thanks Leonid. David On 2/04/2020 12:17 pm, Leonid Mesnik wrote: Find new version (updated webrev.00 by mistake) http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00

Re: RFR: JDK-8237572: Combine the two LingeredApp classes

Looks good Leonid > On Apr 2, 2020, at 4:20 PM, Alex Menkov wrote: > > Hi all, > > please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8237572 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/jpsLingeredApp/webrev/ > > verified all test which use LangeredApp pass. > >

RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

Hi Could you please review following fix which change LingeredApp to prepend vm options to java/vm.test.opts when startApp is used and provide startAppVmOpts to override options completely. The intention is to avoid issue like in this bug where test/jtreg options were ignored by tests. Also

Re: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

explicitly. Switching to prepending will fix it. Leonid thanks, Chris On 3/25/20 2:31 PM, Leonid Mesnik wrote: Igor, Stefan, Ioi Thank you for your feedback. Filed https://bugs.openjdk.java.net/browse/JDK-8241624 To change @run main... to @run driver. Test ClhsdbJstack.java is updated. Sti

Re: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

Hi On 3/30/20 9:43 PM, Chris Plummer wrote: Hi Leonid, On 3/30/20 5:42 PM, Leonid Mesnik wrote: Hi See my comments inline. I will update webrev after go through all your comments. On 3/30/20 11:39 AM, Chris Plummer wrote: Hi Leonid, I haven't gone through all the tests yet.  I've

Re: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

b/apps/LingeredApp.java.udiff.html <http://cr.openjdk.java.net/~lmesnik/8240698/webrev.03/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html> Leonid > On Mar 31, 2020, at 1:32 PM, Chris Plummer wrote: > > On 3/31/20 12:09 PM, Leonid Mesnik wrote: >> Hi >> >> On 3/30/

Re: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

t; Looks good. Thanks for cleaning this up! > > Chris > > On 3/31/20 4:12 PM, Leonid Mesnik wrote: >> Here is new webrev: >> http://cr.openjdk.java.net/~lmesnik/8240698/webrev.03/ >> <http://cr.openjdk.java.net/~lmesnik/8240698/webrev.03/> >> >&g

Re: RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization

Find new version (updated webrev.00 by mistake) http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ The moving lock.lock() outside of try is required to don't get IllegalStateException. And avoiding locks in ThreadRunner is needed to avoid OOME. Leonid On 3/26/20 4:41 PM, Leonid Mesnik

Re: RFR (L): 8241807: JDWP needs update for hidden classes

s.5/> <http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.5/> Please, see my comments below. On 4/24/20 13:20, Leonid Mesnik wrote: Hi I have several comments about coding and desing. These tests might be used as examples for new JDI tests based on this framewor

Re: RFR (L): 8241807: JDWP needs update for hidden classes

Hi I have several comments about coding and desing. These tests might be used as examples for new JDI tests based on this framework so I think it would be better to polish them. General comment: 1. You often check results (not null, exactly one result). It makes sense to use

Re: RFR: 8244133: Refactor nsk/jdi tests to reduce code duplication in settingBreakpoint communication

, at 4:05 PM, Chris Plummer wrote: > > On 5/1/20 3:42 PM, Leonid Mesnik wrote: >> Hi >> >>> On May 1, 2020, at 1:12 PM, Chris Plummer >> <mailto:chris.plum...@oracle.com>> wrote: >>> >>> Hi Leonid, >>> >>> Overall lo

Re: RFR: 8244133: Refactor nsk/jdi tests to reduce code duplication in settingBreakpoint communication

ts with strange formatting, so I am going to add them separately. I just don't want to put all this in single change. So diff contains mostly removal of same lines and it is easier to check it. Leonid > thanks, > > Chris > > On 4/29/20 4:45 PM, Leonid Mesnik wrote: >>

Re: RFR: 8244133: Refactor nsk/jdi tests to reduce code duplication in settingBreakpoint communication

throw new JDITestRuntimeException("** TIMEOUT while waiting for event **"); 147 } 148 //jdiHelper.log2(" eventIterator = eventSet.eventIterator;"); Otherwise, looks good. No need in new webrev if you fix it. Thanks, Serguei On 5/1/20 1

Re: RFR: 8244133: Refactor nsk/jdi tests to reduce code duplication in settingBreakpoint communication

spaces. I'm also ok if you want to leave the comment out. I don't need to see another webrev. thanks, Chris On 5/1/20 4:51 PM, Leonid Mesnik wrote: Yes, the protected should be enough. I've made all non constant fields and methods protected and remove comment. The updated webrev (JDIBase only

RFR: 8244267: Improve serviceability task definitions in CI

Hi Could you please review following fix which add all quick and stable serviceability tests in tier1. The tier1_serviceability still takes less than 15 minutes on 2 cores i5. The tests with @intermittent key are not included. bug: https://bugs.openjdk.java.net/browse/JDK-8244267 diff -r

Re: RFR (S): 8242237: Improve JVM TI HiddenClasses tests

Looks good. The small nit (optional). New function 287 static void JNICALL 288 ClassPrepare(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jclass klass) { is very similar to ClassLoad, and verification of signature might be moved into common function. Leonid > On Apr 24, 2020, at 11:31 AM,

Re: RFR(S/T) : 8243568 : serviceability/logging/TestLogRotation.java uses 'test.java.opts' and not 'test.vm.opts'

Looks good. (Need a 'R'eview.) Leonid. > On Apr 24, 2020, at 3:30 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >> 8 lines changed: 0 ins; 6 del; 2 mod; > > Hi all, > > could you please review this small and trivial patch which updates >

Re: RFR: JDK-8242522: Minor LingeredApp improvements

Looks good. (Not a 'R'eview though.) Leonid. > On Apr 24, 2020, at 3:17 PM, Alex Menkov wrote: > > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8242522 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/ > > The fix contains

RFR: 8244133: Refactor nsk/jdi tests to reduce code duplication in settingBreakpoint communication

Hi Could you please review following fix which remove code duplication by moving methods BreakpointRequest settingBreakpoint, getEventSet, breakpointForCommunication and log1,2,3 in base class. The fix is huge but pretty straight forward, I tried to keep changes as small as possible so most

  1   2   3   4   >