This scales worse and worse the more threads (number of cores) it is run with. On sthsparc15, with 32 cores, the entire test takes 45 minutes to complete.

It appears that the last 35 minutes or so execute the four most long running tests from chapter 7.8.5 still (this is normal behavior - they do O(n^4) evals of unicode strings). The other threads are idle though. Perhaps, with enough cores, something goes bad in HotSpot - classloader lock, classloader parallelism, verifier lock, system dictionary lock, class installation lock or something. Right now it's a mystery how the JVM spends its time during these last 35 minutes.

It appears not to be GC related. 2 GB of heap is actually enough.

How I reproed it:

I logged into sthinfra15.se.oracle.com

I installed the latest nashorn from jdk9 in /tmp/
I installed a recent ant version in /tmp - because whatever is default on OEL was modern when I was at the university in the ninties.
I untarred build 34 of the JDK for Linux 64 bits in /tmp/

I did

export PATH=/tmp/jdk1.9.0/bin/:$PATH
export JAVA_HOME=/tmp/jdk1.9.0/
export ANT_HOME=/tmp/apache-ant-1.9.2
cd nashorn/make

And first:

ant clean test

This runs the unit tests in pessimistic mode and as well as optimistic mode. The total time for the two runs is 5 minutes, which is faster than on my machine.

Then I did

ant clean test262parallel

This took a total of [java] Tests run: 11552/11552 tests, passed: 11552 (100.00%), failed: 0. Time elapsed: 46min 51s.

All 32 cores are fully utilized until the very end, where two long running tests spend the last minute finishing their execution on two cores (this is also normal and expected behavior, they try every unicode string literal in the world through the parser or something). This seems to take a LOT of time here, brining the total up from 9 minutes to 45. The strange thing here is that everything still takes a total of 18 minutes on my puny laptop.

The problematic tests are in chapter 7.8.5. that basically do evals on every possible unicode string that they can generate in an O(n^4) loop. I cannot account for the time discrepancy between the machines though.