8264632: compiler/codecache/jmx/PoolsIndependenceTest.java fails to Notification not being received

[lepestock]

Hi all,

May I ask for reviews for this change?

The case
https://bugs.openjdk.java.net/browse/JDK-8264632

The problem
The test calls for MemoryPoolMXBean.setUsageThreshold() and expects a Notification get fired when the threshold is breached. The Notification is never received.

The failure most probably is caused by the combination of following events:

1. Some threshold has already breached (caused by some other tests);
2. In this case MemoryPoolMXBean never fires subsequent Notifications until the usage is less than a set threshold;
3. The usage manages to grow up between these two lines[1]:

final long usageThresholdLimit = bean.getUsage().getUsed() + 1;
bean.setUsageThreshold(usageThresholdLimit);

4. The usage has never fallen below any set threshold and therefore Notification is never sent. Setting usageThresholdLimit to 0 doesn't clear up the situation "Notification has already been sent" either.

[1] Very common, happens almost every time during my testing - the code cache usage grows up quickly at VM start.

Proposed solution:

1. Before the actual test, I set the usageThresholdLimit to max. possible value;
2. This causes the current usage to appear below the threshold and therefore the "Notification has already been sent" state is cleared;
3. The monitoring is then switched off (by setting usageThresholdLimit to 0), as at the VM start.

Testing

1. Preemptive breaching of some threshold causes the problem for non-modified test.
2. The modified test has been tested with debug versions of macosx, windows, linux x64 builds and a linux-aarch64-debug build.

Thanks,
Evgeny.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8264632: compiler/codecache/jmx/PoolsIndependenceTest.java fails to Notification not being received

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3592/head:pull/3592
$ git checkout pull/3592

Update a local copy of the PR:
$ git checkout pull/3592
$ git pull https://git.openjdk.java.net/jdk pull/3592/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3592

View PR using the GUI difftool:
$ git pr show -t 3592

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3592.diff

[bridgekeeper]

👋 Welcome back enikitin! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@lepestock The following label will be automatically applied to this pull request:

• hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (f25b2187)

[iignatev]

Hi Evgeny,

I'm sorry but I don't understand your root-cause analysis (and hence can't review the patch), could you please elaborate on what you mean by some other tests? as far as I can see all test actions in PoolsIndependenceTest are run as @run main/othervm, so they are executed in a fresh JVM, in other words, there were no tests which got exected before compiler.codecache.jmx.PoolsIndependenceTest and no other tests are run concurrently to it.

Cheers,
-- Igor

[lepestock]

Hi Evgeny,

I'm sorry but I don't understand your root-cause analysis (and hence can't review the patch), could you please elaborate on what you mean by some other tests? as far as I can see all test actions in PoolsIndependenceTest are run as @run main/othervm, so they are executed in a fresh JVM, in other words, there were no tests which got exected before compiler.codecache.jmx.PoolsIndependenceTest and no other tests are run concurrently to it.

Cheers,
-- Igor

Hi Igor,

Yep, you're right. I came to that idea during simulated repetitive runs in attempt to trigger the problem, but the idea of mutual interference is completely wrong. I'm closing the PR.

// Evgeny.