RFR: jsr166 openjdk9 integration

[Martin Buchholz]

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.sandoz at 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 <martinrb at 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
>
>