Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8264760: JVM crashes when two threads encounter the same resolution error #3392

Closed
wants to merge 7 commits into from

Conversation

@Wanghuang-Huawei
Copy link
Contributor

@Wanghuang-Huawei Wanghuang-Huawei commented Apr 8, 2021

As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger issue will be fixed in the other issue.


Progress

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

Issue

  • JDK-8264760: JVM crashes when two threads encounter the same resolution error

Reviewers

Contributors

  • Wang Huang <whuang@openjdk.org>
  • Wu Yan <wuyan34@huawei.com>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3392

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

Using diff file

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Apr 8, 2021

👋 Welcome back whuang! 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 openjdk bot added the rfr label Apr 8, 2021
@Wanghuang-Huawei
Copy link
Contributor Author

@Wanghuang-Huawei Wanghuang-Huawei commented Apr 8, 2021

/contributor add Wang Huang whuang@openjdk.org
/contributor add Wu Yan wuyan34@huawei.com

@openjdk
Copy link

@openjdk openjdk bot commented Apr 8, 2021

@Wanghuang-Huawei
Contributor Wang Huang <whuang@openjdk.org> successfully added.

@openjdk
Copy link

@openjdk openjdk bot commented Apr 8, 2021

@Wanghuang-Huawei
Contributor Wu Yan <wuyan34@huawei.com> successfully added.

@openjdk
Copy link

@openjdk openjdk bot commented Apr 8, 2021

@Wanghuang-Huawei The following label will be automatically applied to this pull request:

  • hotspot-runtime

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

@mlbridge mlbridge bot commented Apr 8, 2021

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Hi Wang,

Thanks for reporting this and offering to fix it. I have a comment on the actual fix and a few issues with the testcase - though thanks for adding one. With a race condition like this it is hard to write a test that will fail reliably without the fix.

Thanks,
David

src/hotspot/share/classfile/systemDictionary.cpp Outdated Show resolved Hide resolved
@@ -0,0 +1,114 @@
class HostNoNestMember {

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 8, 2021
Member

This new file needs a copyright notice and GPL header.

Also please add a comment stating what this jcod file describes - see other jcod files in the directory for example.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 23, 2021
Author Contributor

OK. I will fix that.


import java.util.concurrent.CountDownLatch;

class HostNoNestMember {

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 8, 2021
Member

Please add a comment describing how this class is replaced with the jcode version, and the difference in that version.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 23, 2021
Author Contributor

I split this class into a single file HostNoNestMember.java as @hseigel suggested and add a comment.

TestNestHostErrorWithMultiThread t = new TestNestHostErrorWithMultiThread();
t.test();
Comment on lines 52 to 53

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 8, 2021
Member

There is no need to create an instance - just use a static test method.

The test code could be placed directly in main in this case.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 23, 2021
Author Contributor

Thank you. It will be deleted in next commit.

private int value;
}

public int foo() {

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 8, 2021
Member

Please call this "test".

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 23, 2021
Author Contributor

Sure. Thank you.

new Thread(() -> {
try {
latch.await();
HostNoNestMember h = new HostNoNestMember();
h.foo();
} catch (IllegalAccessError expected) {
System.out.println("OK - got expected exception: " + expected);
} catch (InterruptedException e) {}
}).start();
Comment on lines 60 to 68

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 8, 2021
Member

Please extract the logic to a Runnable so that both threads can use that one runnable rather than duplicating the code.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 23, 2021
Author Contributor

Thank you for your review. It will be more clear after extracting the logic. I will refact that.


public void test() throws Throwable {

CountDownLatch latch = new CountDownLatch(1);

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 8, 2021
Member

The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 14, 2021
Author Contributor

I have tested CyclicBarrier here and found that CountDownLatch could trigger this bug fast while CyclicBarrier couldn't always trigger this bug.

This comment has been minimized.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 19, 2021
Author Contributor

The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives.

I have tested a small case the CyclicBarrier version and CountDownLatch version on JDK17 & JDK11. It seems that :

  • For JDK17, the wake-up time between two threads in the CyclicBarrier version is bigger than the CountDownLatch version. In other words, the CountDownLatch version can trigger this bug more easily .
  • the CyclicBarrier version and the CountDownLatch version running under JDK11 have the same performance.
// CountDownLatch version 
public class TestCountDownLatch {

  public static void main(String args[]) {
    CountDownLatch latch1 = new CountDownLatch(1);
    CountDownLatch latch2 = new CountDownLatch(2);

    MyThread t1 = new MyThread(latch1, latch2);
    MyThread t2 = new MyThread(latch1, latch2);

    t1.start();
    t2.start();

    try {
      // waiting thread creation
      latch2.await();
      latch1.countDown();

      t1.join();
      t2.join();
    } catch (InterruptedException e) {}   

    System.out.println(Math.abs(t1.getAwakeTime() - t2.getAwakeTime()));
  }

  static class MyThread extends Thread {
    private CountDownLatch latch1;
    private CountDownLatch latch2;
		private long awaketime;

    MyThread(CountDownLatch latch1, CountDownLatch latch2) {
      this.latch1 = latch1;
      this.latch2 = latch2;
    }

    @Override
    public void run() {
      try {
        latch2.countDown();
        // Try to have all threads trigger the nesthost check at the same time
        latch1.await();
        awaketime = System.nanoTime();
      } catch (InterruptedException e) {}
    }

    public long getAwakeTime() {
      return awaketime; 
    }
  }
}
// CyclicBarrier version 
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.CyclicBarrier;

public class TestCyclicBarrier {

  public static void main(String args[]) {
    CyclicBarrier barrier = new CyclicBarrier(2);

    MyThread t1 = new MyThread(barrier);
    MyThread t2 = new MyThread(barrier);

    t1.start();
    t2.start();

    try {
      t1.join();
      t2.join();
    } catch (InterruptedException e) {}   

    System.out.println(Math.abs(t1.getAwakeTime() - t2.getAwakeTime()));
  }

  static class MyThread extends Thread {
    private CyclicBarrier barrier; 
		private long awaketime;

    MyThread(CyclicBarrier barrier) {
      this.barrier = barrier;
    }

    @Override
    public void run() {
      try {
        // Try to have all threads trigger the nesthost check at the same time
        barrier.await();
        awaketime = System.nanoTime();
      } catch (Exception e) {}
    }

    public long getAwakeTime() {
      return awaketime; 
    }
  }
}
  • results:
  • CountDownLatch against CyclicBarrier
 CountDownLatch: 3960
 CyclicBarrier: 3361280
 CountDownLatch: 6120
 CyclicBarrier: 3337540
 CountDownLatch: 6160
 CyclicBarrier: 3462920
 CountDownLatch: 9150
 CyclicBarrier: 3328090
 CountDownLatch: 6580
 CyclicBarrier: 3345450
 CountDownLatch: 6340
 CyclicBarrier: 3342900
 CountDownLatch: 1330
 CyclicBarrier: 3379210
 CountDownLatch: 7780
 CyclicBarrier: 3219020
 CountDownLatch: 2460
 CyclicBarrier: 3297020
 CountDownLatch: 7320
 CyclicBarrier: 3332770
  • JDK17 against CyclicBarrier
CyclicBarrier jdk17: 3188590
CyclicBarrier jdk11: 49090
CyclicBarrier jdk17: 3123340
CyclicBarrier jdk11: 14680
CyclicBarrier jdk17: 3107910
CyclicBarrier jdk11: 780
CyclicBarrier jdk17: 3072600
CyclicBarrier jdk11: 1720
CyclicBarrier jdk17: 3164340
CyclicBarrier jdk11: 41020
CyclicBarrier jdk17: 3098490
CyclicBarrier jdk11: 7060
CyclicBarrier jdk17: 3058220
CyclicBarrier jdk11: 14750
CyclicBarrier jdk17: 3052460
CyclicBarrier jdk11: 660
CyclicBarrier jdk17: 3083650
CyclicBarrier jdk11: 14670
CyclicBarrier jdk17: 3116260
CyclicBarrier jdk11: 850

new Thread(() -> {
try {
latch.await();

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 8, 2021
Member

Please add a comment:

// Try to have all threads trigger the nesthost check at the same time

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 23, 2021
Author Contributor

Thank you. I will add that in next commit.

try {
latch.await();
HostNoNestMember h = new HostNoNestMember();
h.foo();

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 8, 2021
Member

Please follow this by:
throw new RuntimeException("Did not get expected IllegalAccessError");

@@ -48,12 +48,12 @@ public int foo() {

public class TestNestHostErrorWithMultiThread {

public static void main(String args[]) {
public static void main(String args[]) throws Throwable {

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 8, 2021
Member

"throws Throwable" is only necessary if you want unlisted checked exceptions to propagate.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 23, 2021
Author Contributor

Thank you for your review. throws Throwable will be removed in my next commit.

Copy link
Member

@hseigel hseigel left a comment

Class HostNoNestMember could be removed entirely from class TestNestHostErrorWithMultiThread by doing the following:

Generate a jcod representation for class HostNoNestMember$Member and add it to HostNoNestMember.jcod.

Delete class HostNoNestMember from TestNestHostErrorWithMultiThread.java.

Change the test to compile HostNoNestMember.jcod before compiling TestNestHostErrorWithMultiThread.java.

Doing this removes the confusion of class HostNoNestMember being compiled twice.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

I think the code you have is correct. I've suggested some additional commentary. There are a couple of races possible here, but I think the remaining ones are benign and we do not need to try and impose any stricter synchronization.

Thanks,
David

@@ -1935,8 +1935,7 @@ void SystemDictionary::add_nest_host_error(const constantPoolHandle& pool,
{
MutexLocker ml(Thread::current(), SystemDictionary_lock);
ResolutionErrorEntry* entry = resolution_errors()->find_entry(index, hash, pool, which);
if (entry != NULL) {
assert(entry->nest_host_error() == NULL, "Nest host error message already set!");
if (entry != NULL && entry->nest_host_error() == NULL) {
entry->set_nest_host_error(message);

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 12, 2021
Member

Please add a comment before line 1939:
// An existing entry means we had a true resolution failure (LinkageError) with our nest host, but we
// still want to add the error message for the higher-level access checks to report. We should
// only reach here under the same error condition, so we can ignore the potential race with setting
// the message. If we see it is already set then we can ignore it.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 23, 2021
Author Contributor

OK. Thank you for your advice. I will add that.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Apr 17, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

On 17/04/2021 5:42 pm, Wang Huang wrote:

On Thu, 8 Apr 2021 05:02:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

add throw exception

test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 58:

56: public void test() throws Throwable {
57:
58: CountDownLatch latch = new CountDownLatch(1);

The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives.

@dholmes-ora

Not sure what commentary you are looking for. CyclicBarrier should work
better for ensuring concurrent attempts in theory.

David

@mlbridge
Copy link

@mlbridge mlbridge bot commented Apr 19, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

On 19/04/2021 2:38 pm, Wang Huang wrote:

On Sat, 17 Apr 2021 07:40:05 GMT, Wang Huang <whuang at openjdk.org> wrote:

test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 58:

56: public void test() throws Throwable {
57:
58: CountDownLatch latch = new CountDownLatch(1);

The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives.

@dholmes-ora

The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives.

I have tested a small case the `CyclicBarrier ` version and `CountDownLatch ` version on `JDK17` & `JDK11`. It seems that :
* For `JDK17`, the wake-up time between two threads in the `CyclicBarrier ` version is bigger than the `CountDownLatch ` version. In other words, the `CountDownLatch ` version can trigger this bug more easily .

So ... thinking about what can happen here

Case 1: countdown latch

The thread that does the countdown() could do that before either thread
calls await(), between the two calls to await(), or after both calls to
await(). So how close in time the two threads are to getting the
nesthost will depend on scheduling and whether either thread actually
blocked in await(). So I can see how we can just be lucky here and both
threads sail through the latch at around the same time without needing
to block.

Case 2: cyclic barrier

The first thread to arrive has to block - no choice. The last thread to
arrive never blocks. So we are actually guaranteed to see worse
behaviour here as the last thread sails through the barrier and does the
nesthost lookup well ahead of the thread that had to block.

So while logically the cyclic barrier releases all threads "at the time
time", in terms of implementation we've added a lot of overhead to the
blocked threads.

Conversely the CDL is not guaranteed to show better bug reproducability
(extreme case - run on a uniprocessor) but in practice as long as we
have a few CPUs to play with it likely will behave "better".

Okay - the CDL version is what we should go with.

Sorry to have taken up so much time on this. I didn't expect you to
benchmark things. :)

Thanks,
David

1 similar comment
@mlbridge
Copy link

@mlbridge mlbridge bot commented Apr 19, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

On 19/04/2021 2:38 pm, Wang Huang wrote:

On Sat, 17 Apr 2021 07:40:05 GMT, Wang Huang <whuang at openjdk.org> wrote:

test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 58:

56: public void test() throws Throwable {
57:
58: CountDownLatch latch = new CountDownLatch(1);

The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives.

@dholmes-ora

The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives.

I have tested a small case the `CyclicBarrier ` version and `CountDownLatch ` version on `JDK17` & `JDK11`. It seems that :
* For `JDK17`, the wake-up time between two threads in the `CyclicBarrier ` version is bigger than the `CountDownLatch ` version. In other words, the `CountDownLatch ` version can trigger this bug more easily .

So ... thinking about what can happen here

Case 1: countdown latch

The thread that does the countdown() could do that before either thread
calls await(), between the two calls to await(), or after both calls to
await(). So how close in time the two threads are to getting the
nesthost will depend on scheduling and whether either thread actually
blocked in await(). So I can see how we can just be lucky here and both
threads sail through the latch at around the same time without needing
to block.

Case 2: cyclic barrier

The first thread to arrive has to block - no choice. The last thread to
arrive never blocks. So we are actually guaranteed to see worse
behaviour here as the last thread sails through the barrier and does the
nesthost lookup well ahead of the thread that had to block.

So while logically the cyclic barrier releases all threads "at the time
time", in terms of implementation we've added a lot of overhead to the
blocked threads.

Conversely the CDL is not guaranteed to show better bug reproducability
(extreme case - run on a uniprocessor) but in practice as long as we
have a few CPUs to play with it likely will behave "better".

Okay - the CDL version is what we should go with.

Sorry to have taken up so much time on this. I didn't expect you to
benchmark things. :)

Thanks,
David

@Wanghuang-Huawei
Copy link
Contributor Author

@Wanghuang-Huawei Wanghuang-Huawei commented Apr 23, 2021

Thank you for your review.

Class HostNoNestMember could be removed entirely from class TestNestHostErrorWithMultiThread by doing the following:

Generate a jcod representation for class HostNoNestMember$Member and add it to HostNoNestMember.jcod.

I think a java file is more clear?

Delete class HostNoNestMember from TestNestHostErrorWithMultiThread.java.

I split HostNoNestMember.java from TestNestHostErrorWithMultiThread.java.

Change the test to compile HostNoNestMember.jcod before compiling TestNestHostErrorWithMultiThread.java.

Doing this removes the confusion of class HostNoNestMember being compiled twice.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Hi,

Sorry for the delayed re-review. There are still a bunch of nits with the test logic that I'd like to see addressed. Sorry I should have flagged them earlier.

Thanks,
David

CountDownLatch latch1 = new CountDownLatch(1);
CountDownLatch latch2 = new CountDownLatch(2);
Comment on lines 41 to 42

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 28, 2021
Member

Please rename latch1 as run, and latch2 as started. The names should aid in understanding the logic of the synchronization.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 28, 2021
Author Contributor

Sure. It will make the code more clear. I will do that.Thank you.

new Thread(new Test(latch1, latch2)).start();
new Thread(new Test(latch1, latch2)).start();
Comment on lines 44 to 45

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 28, 2021
Member

Nit: you only need a single Runnable instance as it is stateless. The Runnable could even be defined inline rather than as a separate named class.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 28, 2021
Author Contributor

It's my fault. I will adjust that. Thank you.

// waiting thread creation
latch2.await();
latch1.countDown();
} catch (InterruptedException e) {}

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 28, 2021
Member

Catch block should have:

throw new Error("Unexpected interrupt");

msg + "\"", expected);
}
System.out.println("OK - got expected exception: " + expected);
} catch (InterruptedException e) {}

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 28, 2021
Member

Catch block should have:

throw new Error("Unexpected interrupt");

// Try to have all threads trigger the nesthost check at the same time
latch1.await();
HostNoNestMember h = new HostNoNestMember();
h.test();

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 28, 2021
Member

After the call to test you should have:

throw new Error("IllegalAccessError was not thrown as expected");

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 28, 2021
Author Contributor

Thank you. I will change that.

* @bug 8264760
* @summary JVM crashes when two threads encounter the same resolution error
*
* @library /test/lib

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 28, 2021
Member

You don't use the test library

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 28, 2021
Author Contributor

Yes. Thank you for your review.

* @compile HostNoNestMember.java
* @compile HostNoNestMember.jcod
*
* @run main/othervm TestNestHostErrorWithMultiThread

This comment has been minimized.

@dholmes-ora

dholmes-ora Apr 28, 2021
Member

No need for othervm in this test.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei Apr 28, 2021
Author Contributor

Sure. I will do that.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Looks good. Thanks for your patience here.

David

@openjdk
Copy link

@openjdk openjdk bot commented Apr 28, 2021

@Wanghuang-Huawei 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:

8264760: JVM crashes when two threads encounter the same resolution error

Co-authored-by: Wang Huang <whuang@openjdk.org>
Co-authored-by: Wu Yan <wuyan34@huawei.com>
Reviewed-by: dholmes, hseigel

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 497 new commits pushed to the master branch:

  • 36e5ad6: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels
  • 0ca86da: 8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001 should skip events for unexpected classes
  • 52f1db6: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file"
  • 04f7112: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long"
  • a90b33a: 8266573: Make sure blackholes are tagged for all JVMCI paths
  • 2dcbedf: 8266044: Nested class summary should show kind of class or interface
  • e840597: 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG
  • fcedfc8: 8266579: Update test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java
  • c665dba: 8266561: Remove Compile::_save_argument_registers
  • 47d4438: 8266426: ZHeapIteratorOopClosure does not handle native access properly
  • ... and 487 more: https://git.openjdk.java.net/jdk/compare/78d1164ce28a17b5a5fb369de143908f66095af9...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@dholmes-ora, @hseigel) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready label Apr 28, 2021
@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Apr 28, 2021

The new test is failing for a reason that is not clear to me yet.

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Apr 28, 2021

I was unable to reproduce the test failure locally.

@Wanghuang-Huawei
Copy link
Contributor Author

@Wanghuang-Huawei Wanghuang-Huawei commented Apr 29, 2021

The new test is failing for a reason that is not clear to me yet.

I will run regression and check this thing.

@Wanghuang-Huawei
Copy link
Contributor Author

@Wanghuang-Huawei Wanghuang-Huawei commented Apr 30, 2021

I was unable to reproduce the test failure locally.

Thank you for your feedback. I have reproduced this problem (~ 10% ) and fixed it. Could you give me a favor to review new commit ? Thank you very much.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

I don't see exactly why the lack of join() would lead to the test failure, but doing the join() is cleaner and consistent with what other tests do.

Thanks,
David

@Wanghuang-Huawei
Copy link
Contributor Author

@Wanghuang-Huawei Wanghuang-Huawei commented Apr 30, 2021

I don't see exactly why the lack of join() would lead to the test failure, but doing the join() is cleaner and consistent with what other tests do.

Thanks,
David

The reason is that the main thread needs to exit and wait for the other two threads to exit. However, the jtreg just waits for a fix time. If two threads are not scheduled in this time, an error will be triggered.

@Wanghuang-Huawei
Copy link
Contributor Author

@Wanghuang-Huawei Wanghuang-Huawei commented Apr 30, 2021

/integrate

@openjdk openjdk bot added the sponsor label Apr 30, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 30, 2021

@Wanghuang-Huawei
Your change (at version adaffaa) is now ready to be sponsored by a Committer.

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Apr 30, 2021

We actually need a second review here (hotspot group rules).

Thanks,
David

@Wanghuang-Huawei
Copy link
Contributor Author

@Wanghuang-Huawei Wanghuang-Huawei commented Apr 30, 2021

hotspot group rules

Sure. It's my fault. Is there any way to revoke /integrate here?

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Apr 30, 2021

No need to revoke it, the sponsor just needs to hold off until there is a second review.

*
* @run main TestNestHostErrorWithMultiThread
*/

This comment has been minimized.

@hseigel

hseigel Apr 30, 2021
Member

Please add a comment here that HostNoNestMember.jcod must be compiled after HostNoNestMember.java because the class file from the jcod file must replace the HostNoNestMember class file generated from HostNoNestMember.java.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei May 6, 2021
Author Contributor

Thank you for your review. I will add that.

* NestMembers attribute to make it empty. The class
* HostNoNestMember$Member has a class HostNoNestMember as its
* NestHost, which will trigger an error when resolving .
*/

This comment has been minimized.

@hseigel

hseigel Apr 30, 2021
Member

Can you modify the above comment to something such as:

 * This class was used to produce a jcod file in which the
 * NestMembers attribute was modified to make it empty. Class
 * HostNoNestMember$Member has class HostNoNestMember as its
 * NestHost, which will trigger an error when resolving.
 *
 * When compiled, this generates a HostNoNestMember class and
 * a HostNoNestMember$Menber class.  The former class, HostNoNestMember,
 * gets overwritten when HostNoNestMember.jcod gets compiled.

This comment has been minimized.

@Wanghuang-Huawei

Wanghuang-Huawei May 6, 2021
Author Contributor

OK. I will fix that. Thank you.

@openjdk openjdk bot removed the sponsor label May 6, 2021
@hseigel
hseigel approved these changes May 6, 2021
Copy link
Member

@hseigel hseigel left a comment

Changes look good. Thanks for fixing this.
Harold

@Wanghuang-Huawei
Copy link
Contributor Author

@Wanghuang-Huawei Wanghuang-Huawei commented May 7, 2021

Changes look good. Thanks for fixing this.
Harold

Thank you for your approval. @dholmes-ora @hseigel

@Wanghuang-Huawei
Copy link
Contributor Author

@Wanghuang-Huawei Wanghuang-Huawei commented May 7, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented May 7, 2021

@Wanghuang-Huawei
Your change (at version ae95790) is now ready to be sponsored by a Committer.

@openjdk openjdk bot added the sponsor label May 7, 2021
@hseigel
Copy link
Member

@hseigel hseigel commented May 7, 2021

/sponsor

@openjdk openjdk bot closed this May 7, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 7, 2021

@hseigel @Wanghuang-Huawei Since your change was applied there have been 509 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

Pushed as commit 9a19a0c.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants