RFR: 8287200: Test java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after JDK-8287103

[Leonid Mesnik]

Need to use proper synchronization.

The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So 
it should not confuse existing checks.

-

Commit messages:
 - 8287200

Changes: https://git.openjdk.java.net/jdk/pull/8874/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8874=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287200
  Stats: 9 lines in 1 file changed: 4 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8874.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8874/head:pull/8874

PR: https://git.openjdk.java.net/jdk/pull/8874

RFR: 8287103: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp

[Leonid Mesnik]

Sync improved in test

-

Commit messages:
 - 8287103: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails 
with Xcomp

Changes: https://git.openjdk.java.net/jdk/pull/8821/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8821=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287103
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8821.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8821/head:pull/8821

PR: https://git.openjdk.java.net/jdk/pull/8821

Re: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2]

[Leonid Mesnik]

On Fri, 13 May 2022 14:39:44 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to fix the failure 
>> handler command `dmesg` on macOS?
>> 
>> As noted in the JBS issue, the command currently fails with permission 
>> error. The commit in this PR uses `sudo` as suggested in the man pages of 
>> that command.
>> 
>> Tested locally on macOS by running:
>> 
>> 
>> cd test/failure_handler
>> make clean
>> make test
>> 
>> Then checked the generated environment.html files for the dmesg command 
>> output. Looks fine after this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   copyright year

Looks reasonable.

-

Marked as reviewed by lmesnik (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8703

Re: RFR: 8286368: Cleanup problem lists after loom integration [v2]

[Leonid Mesnik]

On Mon, 16 May 2022 01:23:09 GMT, David Holmes  wrote:

>> Leonid Mesnik has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge
>>  - 8286368: Cleanup problem lists after loom integration
>
> test/hotspot/jtreg/ProblemList-Xcomp.txt line 38:
> 
>> 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64
>> 37: 
>> 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all
> 
> @lmesnik This line should not have been removed!

It might be a merge problem. My PR was submitted before 8286442. I remereged 
changes, however my merge commit also doesn't have removal of this line:
https://github.com/openjdk/jdk/pull/8604/commits/8255e760ff1a2ff616f00f559de29e66d7036b39

So I am really confused and can't understand how I managed to introduce this 
problem.

-

PR: https://git.openjdk.java.net/jdk/pull/8604

Integrated: 8286368: Cleanup problem lists after loom integration

[Leonid Mesnik]

On Mon, 9 May 2022 18:17:13 GMT, Leonid Mesnik  wrote:

> 8286368: Cleanup problem lists after loom integration

This pull request has now been integrated.

Changeset: dcec1d2a
Author:    Leonid Mesnik 
URL:   
https://git.openjdk.java.net/jdk/commit/dcec1d2a68e2c82e27174c3dc52bb17316530966
Stats: 29 lines in 4 files changed: 1 ins; 22 del; 6 mod

8286368: Cleanup problem lists after loom integration

Reviewed-by: alanb

-

PR: https://git.openjdk.java.net/jdk/pull/8604

Re: RFR: 8286368: Cleanup problem lists after loom integration [v2]

[Leonid Mesnik]

> 8286368: Cleanup problem lists after loom integration

Leonid Mesnik has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains two commits:

 - Merge
 - 8286368: Cleanup problem lists after loom integration

-

Changes: https://git.openjdk.java.net/jdk/pull/8604/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8604=01
  Stats: 29 lines in 4 files changed: 1 ins; 22 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8604.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8604/head:pull/8604

PR: https://git.openjdk.java.net/jdk/pull/8604

Re: RFR: 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with -Xcomp -XX:+DeoptimizeALot [v2]

[Leonid Mesnik]

> Test executes method recursively and works too long.
> 
> It the same issue as 
> [JDK-8139875](https://bugs.openjdk.java.net/browse/JDK-8139875)
> 
> The test shouldn't be run with DeoptimizeALot

Leonid Mesnik has updated the pull request incrementally with one additional 
commit since the last revision:

  Rename Read2.jav` to Read2.java
  
  reverted renaming

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8602/files
  - new: https://git.openjdk.java.net/jdk/pull/8602/files/84a75c5c..900deb58

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8602=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8602=00-01

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8602/head:pull/8602

PR: https://git.openjdk.java.net/jdk/pull/8602

RFR: 8286438: Add jhsdb jstack processing without --mixed in efh

[Leonid Mesnik]

The default is required only to set the same depth level in the tree on HTML 
page for default and mixed mode.

-

Commit messages:
 - 8286438: Add jhsdb jstack processing without --mixed in efh

Changes: https://git.openjdk.java.net/jdk/pull/8610/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8610=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286438
  Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8610.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8610/head:pull/8610

PR: https://git.openjdk.java.net/jdk/pull/8610

RFR: 8286368: Cleanup problem lists after loom integration

[Leonid Mesnik]

8286368: Cleanup problem lists after loom integration

-

Commit messages:
 - 8286368: Cleanup problem lists after loom integration

Changes: https://git.openjdk.java.net/jdk/pull/8604/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8604=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286368
  Stats: 27 lines in 4 files changed: 1 ins; 20 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8604.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8604/head:pull/8604

PR: https://git.openjdk.java.net/jdk/pull/8604

Integrated: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out

[Leonid Mesnik]

On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik  wrote:

> …resulting in failure to produce a stack when a test times out

This pull request has now been integrated.

Changeset: 40470d83
Author:    Leonid Mesnik 
URL:   
https://git.openjdk.java.net/jdk/commit/40470d83e4d8d4a48eb87e6bf4d221460bddfd75
Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod

8284550: test failure_handler is not properly invoking jhsdb jstack, resulting 
in failure to produce a stack when a test times out

Reviewed-by: dholmes, alanb

-

PR: https://git.openjdk.java.net/jdk/pull/8588

RFR: 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with -Xcomp -XX:+DeoptimizeALot

[Leonid Mesnik]

Test executes method recursively and works too long.

It the same issue as 
[JDK-8139875](https://bugs.openjdk.java.net/browse/JDK-8139875)

The test shouldn't be run with DeoptimizeALot

-

Commit messages:
 - copyrights fixed
 - 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with 
-Xcomp -XX:+DeoptimizeALot

Changes: https://git.openjdk.java.net/jdk/pull/8602/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8602=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284980
  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8602/head:pull/8602

PR: https://git.openjdk.java.net/jdk/pull/8602

Withdrawn: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out

[Leonid Mesnik]

On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik  wrote:

> …resulting in failure to produce a stack when a test times out

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jdk/pull/8588

RFR: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out

[Leonid Mesnik]

…resulting in failure to produce a stack when a test times out

-

Commit messages:
 - 8284550: test failure_handler is not properly invoking jhsdb jstack, 
resulting in failure to produce a stack when a test times out

Changes: https://git.openjdk.java.net/jdk/pull/8588/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8588=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284550
  Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8588.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8588/head:pull/8588

PR: https://git.openjdk.java.net/jdk/pull/8588

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]

[Leonid Mesnik]

On Fri, 29 Apr 2022 06:33:42 GMT, Serguei Spitsyn  wrote:

>> Alan Bateman has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp
>  line 59:
> 
>> 57: static jvmtiEventCallbacks callbacks;
>> 58: static jint result = PASSED;
>> 59: static volatile size_t eventsCount = 0; // TODO these 2 vars mofified 
>> from different threads in getReady/check. What to DO???
> 
> I'd suggest to use RawMonitorLocker with event_lock or counter_lock to 
> protect updates of these counters.
> You can remove this comment then.

The variable eventsCount seems to be used in the sinlge thread only. I looked 
on the several tests with same variable and similar logic.

-

PR: https://git.openjdk.java.net/jdk/pull/8166

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]

[Leonid Mesnik]

On Fri, 29 Apr 2022 06:43:02 GMT, Serguei Spitsyn  wrote:

>> Alan Bateman has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp
>  line 287:
> 
>> 285:   }
>> 286: 
>> 287:   eventsCount = 0;
> 
> Counters are not protected with locks.
> I'm not sure it is a real problem here but would be better to double-check.

The variable eventsCount seems to be used in the sinlge thread only. I looked 
on the several tests with same variable and similar logic.

-

PR: https://git.openjdk.java.net/jdk/pull/8166

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]

[Leonid Mesnik]

On Fri, 29 Apr 2022 06:09:35 GMT, Serguei Spitsyn  wrote:

>> Alan Bateman has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp
>  line 139:
> 
>> 137:thr_info.name,(jni->IsVirtualThread(thread) == 
>> JNI_TRUE) ? "virtual" : "kernel",
>> 138: (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user");
>> 139:   }
> 
> I'd suggest to add locals (their names are up to you):
>const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? 
> "virtual" : "kernel";
>const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user";
> 
> It is better to place togeter lines: 129+130.
> Line 137 is not aligned, and there are many unneeded spaces.
> The '()' around conditions are not needed. At least, I do not see them 
> increasing readability.

fixed

-

PR: https://git.openjdk.java.net/jdk/pull/8166

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]

[Leonid Mesnik]

On Fri, 29 Apr 2022 05:48:19 GMT, Serguei Spitsyn  wrote:

>> Alan Bateman has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp
>  line 66:
> 
>> 64:   for (i = 0; i < METH_NUM; i++)
>> 65: bpEvents[i] = 0;
>> 66: }
> 
> Leonid, thank you for converting these tests from nsk.jvmti to provide test 
> coverage for virtual threads!
> As I understand all new tests are C++ based.
> So, I'd suggest to always use C++ style of loops:
>   for (int i = 0; i < METH_NUM; i++)
> 
> This suggestion applies to all new tests in the serviceability/jvmti folder.
> One reason to keep old style would be to keep these tests comparable with the 
> matching nsk.jvmti tests.
> However, I tried to compare and found out that the difference is already 
> pretty big.
> You can consider this clean up after integration though.

fixed in all ported tests were applicable

-

PR: https://git.openjdk.java.net/jdk/pull/8166

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]

[Leonid Mesnik]

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman  wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which 
>> JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the 
>> loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and 
>> require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems 
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for 
>> zero and some of the other ports. Additional ports can be contributed via 
>> PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels 
>> have been trimmed down for now to hotspot, serviceability and core-libs. 
>> We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from 
>> Doug Lea's CVS. These changes will probably be proposed and integrated in 
>> advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support 
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to 
>> make life a bit easier and avoid having to separate VM changes and juggle 
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Reviewed jvmti changes, hotspot tests (excluding tests modified by lmesnik), 
jdk svc tests changes.

-

Marked as reviewed by lmesnik (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

Re: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls

[Leonid Mesnik]

On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov  wrote:

> In a few places String.indexOf/lastIndexOf methods are called with default 
> parameter for index: `0` for `indexOf`, length() for `lastIndexOf`.
> I propose to cleanup such calls. It makes code a bit easier to read. In case 
> of `indexOf` it even could be faster, as there is separate intrinsic for 
> `indexOf` call without index argument.

Marked as reviewed by lmesnik (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7877

Re: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases [v2]

[Leonid Mesnik]

On Fri, 21 Jan 2022 11:04:26 GMT, Aleksey Shipilev  wrote:

>> While working on JDK-8280003, I noticed that 
>> java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays 
>> with more than 1-byte size elements, and no large arrays (past 4G limit) are 
>> tested either. It would be better to add those test cases. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected test still passes
>>  - [x] Linux x86_32 fastdebug, affected test still passes
>>  - [x] Linux AArch64 fastdebug, affected test still passes
>>  - [x] Linux PPC64 fastdebug, affected test still passes
>
> Aleksey Shipilev has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains two additional 
> commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8280166-getobjectsize
>  - Fix

Please update copyright years.

-

Marked as reviewed by lmesnik (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7132

Re: RFR: 8278028: [test-library] Warnings cleanup of the test library [v3]

[Leonid Mesnik]

On Tue, 14 Dec 2021 15:20:31 GMT, Roger Riggs  wrote:

>> Compilation warnings of the test library introduce noise in test output and 
>> should be addressed or suppressed. 
>> Changes include:
>>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>>  - Adding type parameters to Raw types
>>  - Adding a hashCode method where equals was already present
>
> Roger Riggs has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Remove a test/micro file added by mistake.

Marked as reviewed by lmesnik (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6638

Re: RFR: 8278028: [test-library] Warnings cleanup of the test library [v2]

[Leonid Mesnik]

On Mon, 13 Dec 2021 20:58:50 GMT, Roger Riggs  wrote:

>> Compilation warnings of the test library introduce noise in test output and 
>> should be addressed or suppressed. 
>> Changes include:
>>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>>  - Adding type parameters to Raw types
>>  - Adding a hashCode method where equals was already present
>
> Roger Riggs has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains three additional 
> commits since the last revision:
> 
>  - Merge branch 'master' into 8278028-test-warning-cleanup
>  - Update copyrights
>  - 8278028: [test-library] Warnings cleanup of the test library

Is test/micro/org/openjdk/bench/java/io/SerialFilterOverhead.java  added 
accidentally or by purpose?

-

PR: https://git.openjdk.java.net/jdk/pull/6638

Integrated: 8268626: Remove native pre-jdk9 support for jtreg failure handler

[Leonid Mesnik]

On Fri, 11 Jun 2021 18:44:38 GMT, Leonid Mesnik  wrote:

> jtreg failure handler uses native lib to implement getPid for preJDK9. 
> Currently. it is not needed and might be removed.

This pull request has now been integrated.

Changeset: 2e70bc35
Author:Leonid Mesnik 
URL:   
https://git.openjdk.java.net/jdk/commit/2e70bc35dffce47e85f5ca4eaa4c9bdba5afb95b
Stats: 100 lines in 4 files changed: 0 ins; 96 del; 4 mod

8268626: Remove native pre-jdk9 support for jtreg failure handler

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/4476

RFR: 8268626: Remove native pre-jdk9 support for jtreg failure handler

[Leonid Mesnik]

jtreg failure handler uses native lib to implement getPid for preJDK9. 
Currently. it is not needed and might be removed.

-

Commit messages:
 - native lib support removed.

Changes: https://git.openjdk.java.net/jdk/pull/4476/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4476=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268626
  Stats: 100 lines in 4 files changed: 0 ins; 96 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4476.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4476/head:pull/4476

PR: https://git.openjdk.java.net/jdk/pull/4476

Integrated: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes

[Leonid Mesnik]

On Thu, 27 May 2021 22:05:55 GMT, Leonid Mesnik  wrote:

> EFH is improved to process cores and get mixed stack traces with jhsdb and 
> native stack traces with gdb/lldb. It might be useful because hs_err doesn't 
> contain info about all threads, sometimes it is even not generated.

This pull request has now been integrated.

Changeset: 8c8422e0
Author:    Leonid Mesnik 
URL:   
https://git.openjdk.java.net/jdk/commit/8c8422e0f8886d9bbfca29fd228368f88bf46f2c
Stats: 159 lines in 12 files changed: 130 ins; 7 del; 22 mod

8267893: Improve jtreg test failure handler do get native/mixed stack traces 
for cores and live processes

Reviewed-by: iignatyev

-

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v6]

[Leonid Mesnik]

> EFH is improved to process cores and get mixed stack traces with jhsdb and 
> native stack traces with gdb/lldb. It might be useful because hs_err doesn't 
> contain info about all threads, sometimes it is even not generated.

Leonid Mesnik has updated the pull request incrementally with one additional 
commit since the last revision:

  fxies

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4234/files
  - new: https://git.openjdk.java.net/jdk/pull/4234/files/e70518bc..67b61d01

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4234=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4234=04-05

  Stats: 7 lines in 4 files changed: 2 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5]

[Leonid Mesnik]

On Wed, 2 Jun 2021 01:00:53 GMT, Leonid Mesnik  wrote:

>> EFH is improved to process cores and get mixed stack traces with jhsdb and 
>> native stack traces with gdb/lldb. It might be useful because hs_err doesn't 
>> contain info about all threads, sometimes it is even not generated.
>
> Leonid Mesnik has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   spaces updated.

updated diff

-

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5]

[Leonid Mesnik]

On Wed, 9 Jun 2021 08:42:13 GMT, Igor Ignatyev  wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   spaces updated.
>
> test/failure_handler/src/share/classes/jdk/test/failurehandler/GathererFactory.java
>  line 32:
> 
>> 30: import java.io.FileWriter;
>> 31: import java.io.PrintWriter;
>> 32: import java.nio.file.Files;
> 
> I don't see why we need these 3 new imports.

fixed

> test/failure_handler/src/share/classes/jdk/test/failurehandler/ToolKit.java 
> line 28:
> 
>> 26: import jdk.test.failurehandler.action.ActionSet;
>> 27: import jdk.test.failurehandler.action.ActionHelper;
>> 28: import jdk.test.failurehandler.action.PatternAction;
> 
> redundant import

fixed

> test/failure_handler/src/share/conf/mac.properties line 71:
> 
>> 69: native.lldb.app=lldb
>> 70: native.lldb.delimiter=\0
>> 71: native.lldb.args=--core\0%p\0%java\0-o\0thread backtrace all\0-o\0quit
> 
> could you please add a comment similar to the one in common.properties file?

fixed

> test/failure_handler/src/share/conf/mac.properties line 72:
> 
>> 70: native.lldb.delimiter=\0
>> 71: native.lldb.args=--core\0%p\0%java\0-o\0thread backtrace all\0-o\0quit
>> 72: native.lldb.params.timeout=360
> 
> why does `lldb` require an increases timeout, but `gdb` and `jhsdb` do not?

Not sure I remember if there is any reason. I remove it. Let increase it later 
if it actually needed.

-

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5]

[Leonid Mesnik]

On Fri, 28 May 2021 02:14:45 GMT, Igor Ignatyev  wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   spaces updated.
>
> test/failure_handler/src/share/classes/jdk/test/failurehandler/action/PatternAction.java
>  line 63:
> 
>> 61: }
>> 62: for (int i = 0, n = args.length; i < n; ++i) {
>> 63: args[i] = args[i].replace("%java", 
>> helper.findApp("java").getAbsolutePath());
> 
> are we sure that `java` from `PATH` (which is what `findApp` returns) is the 
> right `java`?

The paths contain testJdk and compileJdk before PATH. We use it to find any of 
our tools.

-

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes

[Leonid Mesnik]

On Fri, 28 May 2021 00:54:21 GMT, Leonid Mesnik  wrote:

>> Hi Leonid,
>> 
>> What is EFH? Please update the bug and PR to explain.
>> 
>> Thanks,
>> David
>
>> Hi Leonid,
>> 
>> What is EFH? Please update the bug and PR to explain.
>> 
>> Thanks,
>> David
> 
> Updated summary to "Improve jtreg test failure handler do get native/mixed 
> stack traces for cores and live processes".

> @lmesnik , how has this been tested?

I used it in the loom for several weeks.

-

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5]

[Leonid Mesnik]

On Fri, 28 May 2021 02:25:59 GMT, Igor Ignatyev  wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   spaces updated.
>
> @lmesnik , how has this been tested?

@iignatev, thank you for your comments. I updated all of them.

-

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5]

[Leonid Mesnik]

On Fri, 28 May 2021 02:20:04 GMT, Igor Ignatyev  wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   spaces updated.
>
> test/failure_handler/Makefile line 41:
> 
>> 39: CONF_DIR = src/share/conf
>> 40: 
>> 41: JAVA_RELEASE = 7
> 
> could you please update `DEPENDENCES` section in 
> `test/failure_handler/README`?

done

-

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5]

[Leonid Mesnik]

> EFH is improved to process cores and get mixed stack traces with jhsdb and 
> native stack traces with gdb/lldb. It might be useful because hs_err doesn't 
> contain info about all threads, sometimes it is even not generated.

Leonid Mesnik has updated the pull request incrementally with one additional 
commit since the last revision:

  spaces updated.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4234/files
  - new: https://git.openjdk.java.net/jdk/pull/4234/files/57d76163..e70518bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4234=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4234=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v4]

[Leonid Mesnik]

> EFH is improved to process cores and get mixed stack traces with jhsdb and 
> native stack traces with gdb/lldb. It might be useful because hs_err doesn't 
> contain info about all threads, sometimes it is even not generated.

Leonid Mesnik has updated the pull request incrementally with one additional 
commit since the last revision:

  remove unused code.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4234/files
  - new: https://git.openjdk.java.net/jdk/pull/4234/files/c48542b5..57d76163

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4234=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4234=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v3]

[Leonid Mesnik]

> EFH is improved to process cores and get mixed stack traces with jhsdb and 
> native stack traces with gdb/lldb. It might be useful because hs_err doesn't 
> contain info about all threads, sometimes it is even not generated.

Leonid Mesnik has updated the pull request incrementally with one additional 
commit since the last revision:

  README updated.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4234/files
  - new: https://git.openjdk.java.net/jdk/pull/4234/files/cb1eb944..c48542b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4234=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4234=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v2]

[Leonid Mesnik]

> EFH is improved to process cores and get mixed stack traces with jhsdb and 
> native stack traces with gdb/lldb. It might be useful because hs_err doesn't 
> contain info about all threads, sometimes it is even not generated.

Leonid Mesnik has updated the pull request incrementally with two additional 
commits since the last revision:

 - Merge branch 'efh' of https://github.com/lmesnik/jdk into efh
 - updated after comments from Igor

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4234/files
  - new: https://git.openjdk.java.net/jdk/pull/4234/files/68fd69d9..cb1eb944

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4234=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4234=00-01

  Stats: 47 lines in 7 files changed: 9 ins; 31 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes

[Leonid Mesnik]

On Thu, 27 May 2021 23:38:48 GMT, David Holmes  wrote:

> Hi Leonid,
> 
> What is EFH? Please update the bug and PR to explain.
> 
> Thanks,
> David

Updated summary to "Improve jtreg test failure handler do get native/mixed 
stack traces for cores and live processes".

-

PR: https://git.openjdk.java.net/jdk/pull/4234

RFR: 8267893: Improve EFH do get native/mixed stack traces for cores and live processes

[Leonid Mesnik]

EFH is improved to process cores and get mixed stack traces with jhsdb and 
native stack traces with gdb/lldb. It might be useful because hs_err doesn't 
contain info about all threads, sometimes it is even not generated.

-

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into efh
 - EFH improvements

Changes: https://git.openjdk.java.net/jdk/pull/4234/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4234=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267893
  Stats: 188 lines in 13 files changed: 158 ins; 6 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234

PR: https://git.openjdk.java.net/jdk/pull/4234

Re: RFR(S/T) : 8245874 : requires.extraPropDefns.vmOpts doesn't need -Xbootclasspath/a:bootClasses

[Leonid Mesnik]

Looks good.

Leonid

On 6/4/20 10:21 AM, Igor Ignatyev wrote:

piny?
-- Igor


On Jun 1, 2020, at 7:54 AM, Igor Ignatyev  wrote:

ping?
-- Igor


On May 27, 2020, at 10:25 AM, Igor Ignatyev  wrote:

http://cr.openjdk.java.net/~iignatyev//8245874/webrev.00

8 lines changed: 2 ins; 0 del; 6 mod;

Hi all,

could you please review this small and trivial cleanup in TEST.ROOT files of 
test/jdk/ and test/hotspot/jtreg test suites?
from JBS:

to make sure that classes listed in `requires.extraPropDefns.bootlibs` are in 
BCP, jtreg automatically adds corresponding `-Xbootclasspath/a:` to the options 
list, so `requires.extraPropDefns.vmOpts` doesn't have to have 
`-Xbootclasspath/a:bootClasses`

the patch
- removes -Xbootclasspath/a:bootClasses from requires.extraPropDefns.vmOpts
- moves jdk.test.lib.Platform and Container classes from 
requires.extraPropDefns.bootlibs to requires.extraPropDefns.libs as there is no 
need for them to be in BCP

JBS: https://bugs.openjdk.java.net/browse/JDK-8245874
testing: tier1
webrev: http://cr.openjdk.java.net/~iignatyev//8245874/webrev.00

Thanks,
-- Igor

Re: RFR: 8236939: [TESTBUG] Incorrect initialization in java/foreign/TestArrays.java

[Leonid Mesnik]

Thanks for letting me know. I'll just close bug.

Leonid

> On Jan 12, 2020, at 11:39 PM, Nick Gasson  wrote:
> 
> Hi Leonid,
> 
> On 11/01/2020 02:06, Leonid Mesnik wrote:
>> --- a/test/jdk/java/foreign/TestArrays.java Wed Jan 01 03:08:45 2020 
>> +0100
>> +++ b/test/jdk/java/foreign/TestArrays.java Fri Jan 10 09:51:51 2020 
>> -0800
>> @@ -76,8 +76,8 @@
>>   static VarHandle shortHandle = shorts.varHandle(short.class, 
>> PathElement.sequenceElement());
>>   static VarHandle intHandle = ints.varHandle(int.class, 
>> PathElement.sequenceElement());
>>   static VarHandle floatHandle = floats.varHandle(float.class, 
>> PathElement.sequenceElement());
>> -static VarHandle longHandle = doubles.varHandle(long.class, 
>> PathElement.sequenceElement());
>> -static VarHandle doubleHandle = longs.varHandle(double.class, 
>> PathElement.sequenceElement());
>> +static VarHandle longHandle = longs.varHandle(long.class, 
>> PathElement.sequenceElement());
>> +static VarHandle doubleHandle = doubles.varHandle(double.class, 
>> PathElement.sequenceElement());
>>  static void initBytes(MemoryAddress base, SequenceLayout seq, 
>> BiConsumer handleSetter) {
>>   for (long i = 0; i < seq.elementCount().getAsLong() ; i++) {
> 
> There's also an identical mix-up in TestByteBuffer.java. The patch for 
> 8236634 fixes this too along with some other things:
> 
> http://hg.openjdk.java.net/jdk/jdk14/rev/e70d8459c2ba
> 
> 
> Thanks,
> Nick

Re: RFR: 8236939: [TESTBUG] Incorrect initialization in java/foreign/TestArrays.java

[Leonid Mesnik]

On 1/10/20 10:16 AM, Aleksey Shipilev wrote:

On 1/10/20 7:06 PM, Leonid Mesnik wrote:

I am going to push it in jdk/jdk only and not in jdk14.

I suspect there would be some work around x86_32 before RDP2 hits, so maybe 
this can go into
jdk/jdk14 as well? This would minimize the jdk/jdk14 -> jdk/jdk merge chore 
next week.


Sure. The test bugs could be fixed during RDP2. So if you feel it is 
useful I will push it in jdk14.


Leonid




--- a/test/jdk/java/foreign/TestArrays.java Wed Jan 01 03:08:45 2020 +0100
+++ b/test/jdk/java/foreign/TestArrays.java Fri Jan 10 09:51:51 2020 -0800
@@ -76,8 +76,8 @@
   static VarHandle shortHandle = shorts.varHandle(short.class, 
PathElement.sequenceElement());
   static VarHandle intHandle = ints.varHandle(int.class, 
PathElement.sequenceElement());
   static VarHandle floatHandle = floats.varHandle(float.class, 
PathElement.sequenceElement());
-static VarHandle longHandle = doubles.varHandle(long.class, 
PathElement.sequenceElement());
-static VarHandle doubleHandle = longs.varHandle(double.class, 
PathElement.sequenceElement());
+static VarHandle longHandle = longs.varHandle(long.class, 
PathElement.sequenceElement());
+static VarHandle doubleHandle = doubles.varHandle(double.class, 
PathElement.sequenceElement());
   
   static void initBytes(MemoryAddress base, SequenceLayout seq, BiConsumer handleSetter) {

   for (long i = 0; i < seq.elementCount().getAsLong() ; i++) {

This looks good to me. It does look trivial.

RFR: 8236939: [TESTBUG] Incorrect initialization in java/foreign/TestArrays.java

[Leonid Mesnik]

Hi

Could you please review following trivial fix which corrects type of 
used SequenceLayout in the java/foreign/TestArrays.java test. Really 
both long and double layouts are actually "MemoryLayout.ofValueBits(64L, 
ByteOrder.nativeOrder());" so this issue didn't cause test failure.


I am going to push it in jdk/jdk only and not in jdk14.

bug: https://bugs.openjdk.java.net/browse/JDK-8236939

fix:


--- a/test/jdk/java/foreign/TestArrays.java Wed Jan 01 03:08:45 2020 +0100
+++ b/test/jdk/java/foreign/TestArrays.java Fri Jan 10 09:51:51 2020 -0800
@@ -76,8 +76,8 @@
 static VarHandle shortHandle = shorts.varHandle(short.class, 
PathElement.sequenceElement());
 static VarHandle intHandle = ints.varHandle(int.class, 
PathElement.sequenceElement());
 static VarHandle floatHandle = floats.varHandle(float.class, 
PathElement.sequenceElement());
-static VarHandle longHandle = doubles.varHandle(long.class, 
PathElement.sequenceElement());
-static VarHandle doubleHandle = longs.varHandle(double.class, 
PathElement.sequenceElement());
+static VarHandle longHandle = longs.varHandle(long.class, 
PathElement.sequenceElement());
+static VarHandle doubleHandle = doubles.varHandle(double.class, 
PathElement.sequenceElement());
 
 static void initBytes(MemoryAddress base, SequenceLayout seq, BiConsumer handleSetter) {

 for (long i = 0; i < seq.elementCount().getAsLong() ; i++) {


Leonid

Re: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses

[Leonid Mesnik]

Looks good.

Leonid

On 5/29/19 10:24 AM, Kim Barrett wrote:

[I’m not completely sure where this RFR should be sent, but core-libs-dev
and hotspot-dev seems likely to get reasonable coverage of those who
might care.]

Please review this change to the test library to add some "logging"
output to tests that spawn a child process to perform the test and
then analyze that child's output.  We are seeing occasional timeouts
in such tests whose cause is hard to pin down.  It's not clear whether
the excess time is in the child or instead some problem in the testing
framework.  The new logging output provides timestamps for (1) the
start of output collection from the child, (2) the start of waiting
for the child to terminate, and (3) the child's termination.  This
should be enough to determine whether the child is taking too long,
and hint at where (e.g. termination or not).

CR:
https://bugs.openjdk.java.net/browse/JDK-8219149

Webrev:
http://cr.openjdk.java.net/~kbarrett/8219149/open.00/

Testing:
Local hs-tier1 and verified the expected logging output is present.
mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
caused by the new logging.  (It seems unlikely, but...)

Re: RFR: 8197901: Crash during GC when logging level is debug

[Leonid Mesnik]

Thank you for review. I will add @bug info in the test.

Leonid

> On Feb 22, 2018, at 8:26 PM, David Holmes <david.hol...@oracle.com> wrote:
> 
> Hi Leonid,
> 
> Looks fine. Please also add this bug id to @bug in
> 
> test/jdk/java/lang/StackWalker/VerifyStackTrace.java
> 
> Thanks,
> David
> 
> On 23/02/2018 12:41 PM, Leonid Mesnik wrote:
>> Hi
>> Could you please review following fix which update implementation of 
>> Klass::external_name for anonymous classes.
>> Previously external_name tried to add hashcode of corresponding java_mirror 
>> for InstanceKlass if it exists. However the java_mirror could be incorrect 
>> during GC. Also external_name might tries to calculate hash_code if it was 
>> not “pre-calculated” during class verification. See JDK-8197442 
>> <https://bugs.openjdk.java.net/browse/JDK-8197442> [Graal] 
>> runtime/Metaspace/DefineClass.java crashes with "biases should not be seen 
>> by VM thread here"
>> The suggested fix is to  print address of corresponding InstanceKlass 
>> instead of hashcode. It allows to identify anonymous classes and allows to 
>> use external_name at any time. The hashcode for java_mirror is still 
>> pre-calculated in verifier.cpp since ik->java_mirror()->identity_hash()  
>> still might be used during safepoint. As a regression test I updated one of 
>> tests which redefine classes and easily reproduce problem when executed with 
>> full logging enabled.
>> Test java/lang/StackWalker/VerifyStackTrace.java is update to match new 
>> pattern.
>> webrev: http://cr.openjdk.java.net/~lmesnik/8197901/webrev.00/ 
>> <http://cr.openjdk.java.net/~lmesnik/8197901/webrev.00/>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8197901 
>> <https://bugs.openjdk.java.net/browse/JDK-8197901>
>> Leonid

RFR: 8197901: Crash during GC when logging level is debug

[Leonid Mesnik]

Hi

Could you please review following fix which update implementation of 
Klass::external_name for anonymous classes.
Previously external_name tried to add hashcode of corresponding java_mirror for 
InstanceKlass if it exists. However the java_mirror could be incorrect during 
GC. Also external_name might tries to calculate hash_code if it was not 
“pre-calculated” during class verification. See JDK-8197442 
 [Graal] 
runtime/Metaspace/DefineClass.java crashes with "biases should not be seen by 
VM thread here"

The suggested fix is to  print address of corresponding InstanceKlass instead 
of hashcode. It allows to identify anonymous classes and allows to use 
external_name at any time. The hashcode for java_mirror is still pre-calculated 
in verifier.cpp since ik->java_mirror()->identity_hash()  still might be used 
during safepoint. As a regression test I updated one of tests which redefine 
classes and easily reproduce problem when executed with full logging enabled. 
Test java/lang/StackWalker/VerifyStackTrace.java is update to match new pattern.

webrev: http://cr.openjdk.java.net/~lmesnik/8197901/webrev.00/ 

bug: https://bugs.openjdk.java.net/browse/JDK-8197901 


Leonid

RFR(XXS): Exclude tools/jlink/CheckExecutable.java until 8182878 is fixed.

[Leonid Mesnik]

Hi 

Could you please review very small fix which quarantines test 
tools/jlink/CheckExecutable.java until corresponding infra issue is fixed.

bug: https://bugs.openjdk.java.net/browse/JDK-8186581 

diff:
diff -r daed9a0332d3 test/ProblemList.txt
--- a/test/ProblemList.txt  Mon Aug 28 21:46:12 2017 +0200
+++ b/test/ProblemList.txt  Mon Aug 28 17:15:50 2017 -0700
@@ -265,6 +265,8 @@
 tools/jimage/JImageListTest.java8170120 
generic-all
 tools/jimage/JImageVerifyTest.java  8170120 
generic-all

+tools/jlink/CheckExecutable.java8182878 
linux-all,macosx-all
+
 

 # jdk_jdi


Leonid

Re: RFR(XS) 8184775: tools/launcher/modules/illegalaccess/IllegalAccessTest.java times out on some platforms…

[Leonid Mesnik]

Hi

Currently there were no timeouts wit fastdebug were observed. I don’t know 
exactly how  Xint affects this test but don’t expect significant performance 
degradation comparing with other tests.  Usually timeoutfactor is used to 
increase timeouts of all tests if VM or host are slow. However this test 
launches a lot of VMs with small applications and significantly depends on JVM 
startup performance. I don’t think that other ‘slow’ modes affect  startup 
performance so significantly as Xcomp.  

Leonid

> On Jul 28, 2017, at 2:17 PM, Martin Buchholz <marti...@google.com> wrote:
> 
> Won't this test fail with any "slow" VM, e.g. fastdebug, -Xint, etc ?
> 
> 
> On Fri, Jul 28, 2017 at 2:05 PM, Leonid Mesnik <leonid.mes...@oracle.com 
> <mailto:leonid.mes...@oracle.com>> wrote:
> Hi
> 
> Please review following small fix which excludes test 
> tools/launcher/modules/illegalaccess/IllegalAccessTest.java from execution in 
> Xcomp mode. Test launches about 100 VMs and fails when -Xcomp is used.
> 
> Tested locally with and without adding -Xcomp option.
> 
> Webrev: http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/ 
> <http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/> 
> <http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/ 
> <http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/>>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8184775 
> <https://bugs.openjdk.java.net/browse/JDK-8184775> 
> <https://bugs.openjdk.java.net/browse/JDK-8184775 
> <https://bugs.openjdk.java.net/browse/JDK-8184775>>
> Diff:
> --- old/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java  
>   2017-07-27 17:15:37.0 -0700
> +++ new/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java  
>   2017-07-27 17:15:37.0 -0700
> @@ -23,6 +23,7 @@
> 
>  /**
>   * @test
> + * @requires vm.compMode != "Xcomp"
>   * @modules java.base/jdk.internal.misc
>   *  java.base/sun.security.x509
>   *  java.activation
> 
> Leonid
> 

RFR(XS) 8184775: tools/launcher/modules/illegalaccess/IllegalAccessTest.java times out on some platforms…

[Leonid Mesnik]

Hi

Please review following small fix which excludes test 
tools/launcher/modules/illegalaccess/IllegalAccessTest.java from execution in 
Xcomp mode. Test launches about 100 VMs and fails when -Xcomp is used.

Tested locally with and without adding -Xcomp option.

Webrev: http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/ 

Bug: https://bugs.openjdk.java.net/browse/JDK-8184775 

Diff:
--- old/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java
2017-07-27 17:15:37.0 -0700
+++ new/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java
2017-07-27 17:15:37.0 -0700
@@ -23,6 +23,7 @@
 
 /**
  * @test
+ * @requires vm.compMode != "Xcomp"
  * @modules java.base/jdk.internal.misc
  *  java.base/sun.security.x509
  *  java.activation

Leonid

Re: RFR : 8132961 : JEP 279 Improve Test-Failure Troubleshooting

[Leonid Mesnik]

Hi

These changes were already reviewed internally.
Looks good for me. Please get official review from Reviewers.

Leonid

On 24.11.2015 22:13, Igor Ignatyev wrote:

http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/

3579 lines changed: 3579 ins; 0 del; 0 mod; 0 unchg

Hi,

Could you please review the webrev[0] for JEP 279[1]?

The scope of the JEP is an implementation of a library which uses jtreg timeout 
handler and observer extension points to collect information about environment 
in case of test failures (including timeouts) and about test processes in case 
of timeouts. This data is then presented together with the test failure to 
simplify analysis.

To make it easier to specify which tools should be run by the library on which 
platform when a test failure or timeout occurs, we use properties files to configure 
the library. Each platform family uses its own property file (named 
.properties) and common.properties, which contains platform independent 
tools, such as jps. Using property files allows to easily extend the tools that are 
used to collect information on test failure or timeout in the future. See the JEP for 
a more thorough overview of the collected data. Currently, we are using the following 
tools:
- on all platforms[3]: jps, jstack, jmap, jinfo, jcmd
- on linux[4]: ps, pmap, lsof, lslocks, gdb, gcore, id, who, last, df, env, 
dmesg, sysctl, top, free, vmstat, netstat
- on solaris[5]: pgrep, pmap, pfiles, pstack, gcore, id, who, last, df, env, 
dmesg, prtconf, sysdef, swap, ps, top, vmstat, pagesize, netstat
- on mac[6]: pgrep, vmmap, heap, leaks, spindump, lldb, gcore, id, who, last, 
df, env, dmesg, sysctl, ps, top, vm_stat, netstat
- on windows[7]: wmic, pmap, handle, cdb, id, who, last, df, env, powershell, 
tasklist, ps, top, free, vmstat, openfiles, netstat

More information can be found in the JEP[1] and README[2].

The library integration into makefiles will be done later as the fix for 
JDK-8132962[8].

[0] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/
[1] https://bugs.openjdk.java.net/browse/JDK-8075621
[2] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/README.html
[3] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/common.properties.html
[4] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/linux.properties.html
[5] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/solaris.properties.html
[6] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/mac.properties.html
[7] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/windows.properties.html
[8] https://bugs.openjdk.java.net/browse/JDK-8132962

Thanks,
— Igor