8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently #14
Conversation
|
👋 Welcome back dholmes! A progress list of the required criteria for merging this PR into |
|
@dholmes-ora The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
openjdk
bot
added
serviceability
|
/label remove core-libs |
|
@dholmes-ora This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
openjdk
bot
added
ready
|
@AlanBateman |
|
Thanks for all the reviews! /integrate |
|
Going to push as commit c93b24d. |
openjdk
bot
added
integrated
|
@dholmes-ora Pushed as commit c93b24d. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
…test fail
This bug appears intermittently and it's caused by vmaskAll_immI[1]
when the vector mask size is smaller than max predicate size of running
machine. It generates an all-true predicate without considering those
inactive bits. That may result in the wrong result of VectorMask.toLong.
The problematic code is as below:
```
ShortVector.SPECIES_64.MaskAll(true).toLong()
assembly:
ptrue p0.h <= MaskAll(true)
mov z16.h, p0/z, openjdk#1
mov z17.h, #0
uzp1 z16.b, z16.b, z17.b
fmov x10, d16
orr x10, x10, x10, lsr openjdk#7
orr x10, x10, x10, lsr openjdk#14
orr x10, x10, x10, lsr openjdk#28
and x10, x10, #0xff
(gdb) p/x $p0 # on an SVE machine with vector length as 64 in bytes
$1 = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55}
Expected:
(gdb) p/x $p0
$1 = {0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
```
Considering MaskAll is used in VectorMask.fromLong() only for a special
case and relies on the mechanism of inline and intrinsification, even it
could be optimized out, this patch also adds test cases for MaskAll to
reproduce this issue stably.
Also fix a small issue on register utilization for
sve_reduce_[max|min][D|F].
[1] https://github.com/openjdk/jdk18/blob/master/src/hotspot/cpu/aarch64/aarch64_sve.ad#L416
hotspot/compiler/vectorapi, jdk/incubator/vector passed on SVE enabled
system.
[INTERNAL ONLY]
hotspot/compiler/vectorapi, jdk/incubator/vector passed on a64fx.
TEST_LABEL: ent-arch-aarch64 && ent-conformance-enabled && ent-os-ubuntu
JDK_SCOPE: test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi
Jira: ENTLLT-4502
CustomizedGitHooks: yes
Change-Id: I401650c1cc32d730603a185d5ebf7bb263a4b539
…test fail
This bug appears intermittently and it's caused by vmaskAll_immI[1]
when the vector mask size is smaller than max predicate size of running
machine. It generates an all-true predicate without considering those
inactive bits. That may result in the wrong result of VectorMask.toLong.
The problematic code is as below:
```
ShortVector.SPECIES_64.MaskAll(true).toLong()
assembly:
ptrue p0.h <= MaskAll(true)
mov z16.h, p0/z, openjdk#1
mov z17.h, #0
uzp1 z16.b, z16.b, z17.b
fmov x10, d16
orr x10, x10, x10, lsr openjdk#7
orr x10, x10, x10, lsr openjdk#14
orr x10, x10, x10, lsr openjdk#28
and x10, x10, #0xff
(gdb) p/x $p0 # on an SVE machine with vector length as 64 in bytes
$1 = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55}
Expected:
(gdb) p/x $p0
$1 = {0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
```
Considering MaskAll is used in VectorMask.fromLong() only for a special
case and relies on the mechanism of inline and intrinsification, even it
could be optimized out, this patch also adds test cases for MaskAll to
reproduce this issue stably.
Also fix a small issue on register utilization for
sve_reduce_[max|min][D|F].
[1] https://github.com/openjdk/jdk18/blob/master/src/hotspot/cpu/aarch64/aarch64_sve.ad#L416
hotspot/compiler/vectorapi, jdk/incubator/vector passed on SVE enabled
system.
Change-Id: I9631f26f9232ffe7a28b74f14062d945c32fa1fb
Investigation showed this test was experiencing interference from threads created by other tests in agentvm mode. The simple solution is to run this test isolated using othervm mode. Also added some diagnostics to the test incase we see future failures.
Testing: local and tier3.
Thanks,
David
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk18 pull/14/head:pull/14$ git checkout pull/14Update a local copy of the PR:
$ git checkout pull/14$ git pull https://git.openjdk.java.net/jdk18 pull/14/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 14View PR using the GUI difftool:
$ git pr show -t 14Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk18/pull/14.diff