[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java
From: Mandy Chung <mandy.chung () oracle ! com>
Date: 2013-10-31 20:41:59
Message-ID: 5272C097.2060106 () oracle ! com
[Download RAW message or body]
On 10/31/2013 12:34 PM, Alan Bateman wrote:
> On 31/10/2013 19:11, Mandy Chung wrote:
>> Updated webrev that has a new
>> test/lib/testlibrary/ThreadStateController.java and also change to
>> use AtomicInteger:
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/
>>
>> Mandy
> Is ThreadStateController general enough for the unname package in
> /lib/testlibrary? Just wondering if it should be moved down into a
> package (I like using testlibrary, just wonder how it will scale if we
> make over-use of it).
>
I was also wondering how testlibrary is currently structured. While
ThreadStateController can be for general use, I would think that this
class would be more specific for these tests and other ThreadMXBean
tests to use. Having a second thought, it may be better to move it under
jdk/test/java/lang/Thread/testlibrary? Any opinion?
> Also does the refactoring mean that methods can be removed from
> ThreadMXBean/Utils.java? I realize this is expanding your scope a bit
> and maybe changing SynchronizationStatistics (which appears to be the
> user other of Utils).
>
I looked at them and I decide to leave it as a separate task.
ThreadMXBean/Utils and ThreadExecutionSynchronizer are currently used by
a few other ThreadMXBean tests that are intermittent test failures (I am
responsible for them :). Jarsolav has fixed several of them and he has
also filed a bug to remove ThreadExecutionSynchronizer and use
java.util.concurrent where appropriate.
https://bugs.openjdk.java.net/browse/JDK-8024326
I may spare some time to help clean them up but no promise :)
Mandy
Mandy
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 10/31/2013 12:34 PM, Alan Bateman
wrote:<br>
</div>
<blockquote cite="mid:5272B0C0.4070608@oracle.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 31/10/2013 19:11, Mandy Chung wrote:
<blockquote cite="mid:5272AB6C.5030300@oracle.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Updated webrev that has a new
test/lib/testlibrary/ThreadStateController.java and also change
to use AtomicInteger:<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Emchung/jdk8/webrevs/8022208/webrev.01/">http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/</a><br>
<br>
Mandy<br>
</blockquote>
Is ThreadStateController general enough for the unname package in
/lib/testlibrary? Just wondering if it should be moved down into a
package (I like using testlibrary, just wonder how it will scale
if we make over-use of it).<br>
<br>
</blockquote>
<br>
I was also wondering how testlibrary is currently structured. While
ThreadStateController can be for general use, I would think that
this class would be more specific for these tests and other
ThreadMXBean tests to use. Having a second thought, it may be better
to move it under jdk/test/java/lang/Thread/testlibrary? Any
opinion?<br>
<br>
<blockquote cite="mid:5272B0C0.4070608@oracle.com" type="cite"> Also
does the refactoring mean that methods can be removed from
ThreadMXBean/Utils.java? I realize this is expanding your scope a
bit and maybe changing SynchronizationStatistics (which appears to
be the user other of Utils).<br>
<br>
</blockquote>
<br>
I looked at them and I decide to leave it as a separate task.<br>
<br>
ThreadMXBean/Utils and ThreadExecutionSynchronizer are currently
used by a few other ThreadMXBean tests that are intermittent test
failures (I am responsible for them :). Jarsolav has fixed several
of them and he has also filed a bug to remove
ThreadExecutionSynchronizer and use java.util.concurrent where
appropriate.<br>
<a class="moz-txt-link-freetext" \
href="https://bugs.openjdk.java.net/browse/JDK-8024326">https://bugs.openjdk.java.net/browse/JDK-8024326</a><br>
<br>
I may spare some time to help clean them up but no promise :)<br>
<br>
Mandy<br>
Mandy<br>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic