| cff661d65e3e6e2ac731ebbf938251656deb4be4 |
|
19-Feb-2017 |
Tobias Thierer <tobiast@google.com> |
Port JSR166 LinkedTransferQueueTest flakiness fix
This CL cherry-picks the following upstream (*) test changes ("upstream"
here is JSR166's CVS repository
cvs -d ':pserver:anonymous@gee.cs.oswego.edu/home/jsr166/jsr166'
This is in contrast to the code under test, whose upstream is OpenJDK).
=====
src/test/tck/LinkedTransferQueueTest.java
revision 1.70
date: 2017/02/18 16:37:49; author: jsr166; state: Exp; lines: +11 -5
waitForThreadToEnterWaitState should fail on timeout; tests should tolerate transient blocking Thread.State at any time (e.g. due to classloading)
src/test/tck/JSR166TestCase.java
revision 1.219
date: 2017/02/18 16:37:49; author: jsr166; state: Exp; lines: +43 -3
waitForThreadToEnterWaitState should fail on timeout; tests should tolerate transient blocking Thread.State at any time (e.g. due to classloading)
src/test/tck/PhaserTest.java
revision 1.45
date: 2017/02/18 15:05:55; author: jsr166; state: Exp; lines: +10 -10
use default timeout of LONG_DELAY_MS with
waitForThreadToEnterWaitState
======
The effect of this CL is to fix flakiness in LinkedTransferQueueTest's
testTransfer2() and testWaitingConsumer().
These test methods need to wait until a background thread was blocked
waiting on a LinkedTransferQueue; before this CL, they did so by
calling a helper method that waited for the background thread's state
to become WAITING, TIMED_WAITING, or BLOCKED. After this CL, they also
check that the LinkedTransferQueue is in the expected state before
they stop waiting.
The additional check is necessary because LinkedTransferQueue uses
LockSupport.park(), which on Android involves a synchronized lock
and therefore BLOCKED state. This caused the test methods to
prematurely stop waiting, which caused the test to fail.
The concrete failure could also have been prevented by waiting for
the thread to enter WAITING or TIMED_WAITING state rather than BLOCKED.
This was considered but not chosen by upstream since it would still
have made assumptions about those states not being entered elsewhere.
This CL also changes the waiting logic to fail() the test upon
timeout. PhaserTest was changed to use longer timeouts (10sec
rather than 250msec) to avoid flaky timeout failures.
Bug: 34814528
Test: LinkedTransferQueueTest
Test: PhaserTest
Test: Checked that testTransfer2() and testWaitingConsumer() are
non-flaky by running their body 10,000 times each in a loop.
Change-Id: I112ee1fba8aea6ca97ca0f99bba0fc9f00e5c0c2
|
| e8b323c7cb7d55be9a4df579231e44f04f53d766 |
|
11-Mar-2016 |
Przemyslaw Szczepaniak <pszczepaniak@google.com> |
JSR-166 update without java 1.9 method/classes
Second attempt, in frist one I've submitted some code from openJdk 1.9
that shouldn't be here, orignial change can be found at
5328e07d282bef36ac8b757bbee16a761415b2c4
Adapted from sources taken from CVS using:
cvs -d ':pserver:anonymous@gee.cs.oswego.edu/home/jsr166/jsr166' checkout -D "03/03/2016 10:00:00 GMT" jsr166
This time with hidden/removed "@since 9" methods and classes
Bug: 27426599
Change-Id: Ibd8d26e13cba091bfd983c73d005e4f8d8f5946d
(cherry picked from commit b8b75116273ecfdb8ffdd1869b1c0dd04570a95e)
|
| b8b75116273ecfdb8ffdd1869b1c0dd04570a95e |
|
11-Mar-2016 |
Przemyslaw Szczepaniak <pszczepaniak@google.com> |
JSR-166 update without java 1.9 method/classes
Second attempt, in frist one I've submitted some code from openJdk 1.9
that shouldn't be here, orignial change can be found at
5328e07d282bef36ac8b757bbee16a761415b2c4
Adapted from sources taken from CVS using:
cvs -d ':pserver:anonymous@gee.cs.oswego.edu/home/jsr166/jsr166' checkout -D "03/03/2016 10:00:00 GMT" jsr166
This time with hidden/removed "@since 9" methods and classes
Bug: 27426599
Change-Id: Ibd8d26e13cba091bfd983c73d005e4f8d8f5946d
|
| ed4f365789d43b1961657195df223a19bf4ef20f |
|
15-Mar-2016 |
Przemyslaw Szczepaniak <pszczepaniak@google.com> |
Revert "JSR-166 update"
I missed comments on framework/base change regarding "@since 9" parts
This reverts commit 5328e07d282bef36ac8b757bbee16a761415b2c4.
Change-Id: Iff71b8a17e79a0a5c1ecadc05bccadceabb83393
|
| 5328e07d282bef36ac8b757bbee16a761415b2c4 |
|
11-Mar-2016 |
Przemyslaw Szczepaniak <pszczepaniak@google.com> |
JSR-166 update
Adapted from sources taken from CVS using:
cvs -d ':pserver:anonymous@gee.cs.oswego.edu/home/jsr166/jsr166' checkout -D "03/03/2016 10:00:00 GMT" jsr166
Bug: 27426599
Change-Id: Ic9ba278929f8747d58b69e7d67ec325064588bff
|
| 8e9a0e92906742b17eb08d7fb83cca91965f9b8e |
|
28-Apr-2015 |
Narayan Kamath <narayan@google.com> |
Update JSR166 tck tests.
The following tests have been omitted because they are
unsupported :
- Atomic8Test.java
- CompletableFutureTest.java
- ConcurrentHashMap8Test.java
- DoubleAccumulatorTest.java
- DoubleAdderTest.java
- ForkJoinPool8Test.java
- ForkJoinTask8Test.java
- LongAccumulatorTest.java
- LongAdderTest.java
- SplittableRandomTest.java
- StampedLockTest.java
- ThreadLocalRandom8Test.java
- ThreadPoolExecutor9Test.java
A package declaration has been added to all files (package jsr166;)
and the base-class JSR166Test has been changed not to rely on features
that aren't available on android / junit in the android environment.
We also avoid using junit4 style TestSuite declarations. While the CTS
test runner handles them properly usually, it trips over itself when it
encounters a failure and tries to run each test in an invidual process
and fails each test for no good reason (needs investigation on the CTS
side of things)
bug: 20628776
(cherry picked from commit 5da8b2b3cac51f0f592a5e1941bd84eade9648cd)
Change-Id: If35be0881ad8da4c604ce6683149b15c1a85f289
|
| 5da8b2b3cac51f0f592a5e1941bd84eade9648cd |
|
28-Apr-2015 |
Narayan Kamath <narayan@google.com> |
Update JSR166 tck tests.
The following tests have been omitted because they are
unsupported :
- Atomic8Test.java
- CompletableFutureTest.java
- ConcurrentHashMap8Test.java
- DoubleAccumulatorTest.java
- DoubleAdderTest.java
- ForkJoinPool8Test.java
- ForkJoinTask8Test.java
- LongAccumulatorTest.java
- LongAdderTest.java
- SplittableRandomTest.java
- StampedLockTest.java
- ThreadLocalRandom8Test.java
- ThreadPoolExecutor9Test.java
A package declaration has been added to all files (package jsr166;)
and the base-class JSR166Test has been changed not to rely on features
that aren't available on android / junit in the android environment.
We also avoid using junit4 style TestSuite declarations. While the CTS
test runner handles them properly usually, it trips over itself when it
encounters a failure and tries to run each test in an invidual process
and fails each test for no good reason (needs investigation on the CTS
side of things)
bug: 20628776
Change-Id: Iddccfe89d5faac3249ebd8976145ef95f63a1186
|
| 8f0d92bba199d906c70a5e40d7f3516c1a424117 |
|
01-Aug-2013 |
Calin Juravle <calin@google.com> |
Added jsr166 tck tests as part of the libcore testsuite.
Change-Id: I6094d734f818fa043f2b277cf2b4ec7fec68e26e
|