I followed up on my own suggestion and wrote a race-simulating test without
the big hammer:
/**
* Checks that traversal operations collapse a random pattern of
* dead nodes as could normally only occur with a race.
*/
@Test(dataProvider = "traversalActions")
public void traversalOperationsCollapseNodes(
Consumer<LinkedTransferQueue> traversalAction) {
LinkedTransferQueue q = new LinkedTransferQueue();
int n = rnd.nextInt(6);
for (int i = 0; i < n; i++) q.add(i);
ArrayList nulledOut = new ArrayList();
for (Object p = head(q); p != null; p = next(p))
if (rnd.nextBoolean()) {
nulledOut.add(item(p));
ITEM.setVolatile(p, null);
}
traversalAction.accept(q);
if (n == 0)
assertEquals(nodeCount(q), 0);
else {
int c = nodeCount(q);
assertEquals(q.size(), c - (q.contains(n - 1) ? 0 : 1));
for (int i = 0; i < n; i++)
assertTrue(nulledOut.contains(i) ^ q.contains(i));
}
}
On Mon, Jan 9, 2017 at 2:07 PM, Paul Sandoz <paul.san...@oracle.com> wrote:
>
> On 9 Jan 2017, at 13:27, Martin Buchholz <marti...@google.com> wrote:
>
> My whitebox tests tend to use private access only for reading, but I can
> imagine cases where it is useful to give testing code stronger access than
> for regular VarHandles, maybe even to write final fields, for example for
> fuzz testing or reliably creating an internal state that can only happen
> with a race. There's may be a case for providing such a big hammer, if
> it's sufficiently hard to get at, but I can live without it.
>
>
>
> That big hammer could be jdk.internal.misc.Unsafe for certain tightly
> bound tests that really need it.
>
>
> My preference would be to encourage people to use
>> MethodHandles.privateLookupIn.
>>
>
> I'm a convert!
>
>
> Great!
>
>
> It will take a while for privateLookupIn to become "common knowledge".
>
>
> I shall endeavour to mention it at Devoxx US in March where John and I
> will present on java.lang.invoke.
>
> Paul.
>
