FlakyThreadFactory fixed:
(It would be nice if hotspot was consistent about the way it failed,
regardless of platform)
"Write once, fail anywhere"
Index:
src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java,v
retrieving revision 1.1
diff -u -r1.1 FlakyThreadFactory.java
---
src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java 24
Dec 2011 02:13:42 -0000 1.1
+++
src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java 24
Sep 2015 17:52:27 -0000
@@ -22,8 +22,10 @@
test(OutOfMemoryError.class,
new ThreadFactory() {
public Thread newThread(Runnable r) {
- // "guarantee" OutOfMemoryError
- return new Thread(null, r, "bloated", 1L << 60);
+ new Thread(null, r, "a natural OOME", 1L << 60);
+ // """On some platforms, the value of the stackSize
+ // parameter may have no effect whatsoever."""
+ throw new OutOfMemoryError("artificial OOME");
}});
test(null,
new ThreadFactory() {
On Thu, Sep 24, 2015 at 5:43 AM, Paul Sandoz <paul.san...@oracle.com> wrote:
> I ran the patches through JPRT.
>
> I am noticing one test failure that i cannot reproduce locally but
> reproduces on some test machines.
>
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1335)
> at FlakyThreadFactory.fail(FlakyThreadFactory.java:93)
> at FlakyThreadFactory.check(FlakyThreadFactory.java:96)
> at FlakyThreadFactory.test(FlakyThreadFactory.java:81)
> at FlakyThreadFactory.test(FlakyThreadFactory.java:49)
> at FlakyThreadFactory.instanceMain(FlakyThreadFactory.java:103)
> at FlakyThreadFactory.main(FlakyThreadFactory.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:519)
> at
> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:218)
> at java.lang.Thread.run(Thread.java:746)
> java.lang.AssertionError: Some tests failed
> at FlakyThreadFactory.instanceMain(FlakyThreadFactory.java:105)
> at FlakyThreadFactory.main(FlakyThreadFactory.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:519)
> at
> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:218)
> at java.lang.Thread.run(Thread.java:746)
>
> That is related to this test:
>
> test(OutOfMemoryError.class,
> new ThreadFactory() {
> public Thread newThread(Runnable r) {
> // "guarantee" OutOfMemoryError
> return new Thread(null, r, "bloated", 1L << 60);
> }});
>
> Where the submission of tasks succeeds and it such cases it expects that
> the expected exception is null, rather than OutOfMemoryError.
>
> The stackSize parameter on the Thread constructor seems more of a hint and
> can be processed in a platform specific way, so i am not sure it can be
> relied upon to produce an OutOfMemoryError, e.g. on Thread:
>
> * <p>The virtual machine is free to treat the {@code stackSize}
> * parameter as a suggestion. If the specified value is unreasonably low
> * for the platform, the virtual machine may instead use some
> * platform-specific minimum value; if the specified value is unreasonably
> * high, the virtual machine may instead use some platform-specific
> * maximum. Likewise, the virtual machine is free to round the specified
> * value up or down as it sees fit (or to ignore it completely).
>
> Paul.
>
> On 21 Sep 2015, at 20:34, Martin Buchholz <marti...@google.com> wrote:
>
> > This is the long-delayed and long-awaited bulk integration for jdk9 from
> jsr166 CVS.
> >
> > Find webrevs here:
> >
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> >
> > Sorry about the extreme size and tardiness of this integration.
> >
> > As a review convenience, I provided a diff-wbB file that contains all
> the jsr166 integration changes using "hg diff -wbB" that ignores whitespace
> changes.
> >
> > We will need JPRT+specdiff+CCC from Oracle folks
> >
> > All changes are subtasks of:
> > https://bugs.openjdk.java.net/browse/JDK-8132960
>
>
