On Mon, 19 Apr 2021 19:15:18 GMT, Daniel D. Daugherty <dcu...@openjdk.org>
wrote:
> I'm updating the runtime/Thread/SuspendAtExit.java test:
>
> - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread()
> - switch from java.lang.Thread.resume() to JVM/TI ResumeThread()
> - switch from counter-based to time-based testing
> - improve error checking since we're now using an API with error codes!
>
> I've used this test to stress @robehn's fix for JDK-8257831 using both
> invocation styles for 9 hours each in {fastdebug, release, slowdebug}
> configs without any issues.
>
> I've run the updated test thru Mach5 Tier[134567] testing; one timeout
> was observed in a single Tier6 run on Win-X64. I believe this is a case of
> a lost Thread.interrupt() call.
Hi Dan,
A few nits (mostly pre-existing) but otherwise the conversion to JVMTI looks
good.
Thanks,
David
test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 90:
> 88: while (System.currentTimeMillis() < start_time + (timeMax *
> 1000)) {
> 89: count++;
> 90: SuspendAtExit threads[] = new SuspendAtExit[N_THREADS];
Style nit pre-existing: The [] go on the type not the variable.
test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 103:
> 101: // the exitSyncObj.await() call and the
> SuspendThread()
> 102: // calls will come in during thread exit.
> 103: threads[i].interrupt();
Pre-existing: why use interrupt() instead of simply calling countDown() on the
latch ??
test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 159:
> 157: "after thread #" + i +
> 158: " has been join()'ed");
> 159: }
This is unnecessary, you aren't testing the correctness of Thread.join() here.
join() can't return normally if the thread is alive.
test/hotspot/jtreg/runtime/Thread/libSuspendAtExit.cpp line 2:
> 1: /*
> 2: * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights
> reserved.
Copyright year should just be 2021.
-------------
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3576
