RFR: jsr166 openjdk9 integration

[Paul Sandoz]

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