FULL PRODUCT VERSION :
Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

Bug also apparent (and slightly worse) under 1.8.0.31:
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows 2012 r2, but reproducible on Mac OS

"Microsoft Windows [Version 6.3.9600]"

"Darwin Kernel Version 14.1.0: Mon Dec 22 23:10:38 PST 2014; root:xnu-2782.10.72~2/RELEASE_X86_64 x86_64"


EXTRA RELEVANT SYSTEM CONFIGURATION :
Problem is most significant when run on a network-attached SSD RAID system, but is observable both on local SSD and even on laptop drives to a lesser extent.

A DESCRIPTION OF THE PROBLEM :

We noticed significant additional time writing log files to disk in our application after updating from 1.7.0.51 to 1.8.0.31 and then 1.8.0.40. We constructed a minimal test with 10 threads writing out, collectively, 500 MB of data to a single file, as would be seen in a logging subsystem. In running this test on 1.7.0.51 and on 1.8.0.31/40 we found that 1.8.0.40 takes about twice as long to complete on the target hardware (the difference was less dramatic on other hardware; around 50% degradation on a local SSD drive about 13% degradation on a laptop-grade HD).

Note that we ran similar tests (1) with a single thread writing to disk (no contention), and (2) with all threads contending over a resource but just issuing a Thread.sleep(1) instead of writing to the file system. These tests did NOT show a degradation in moving from 1.7 to 1.8. It appears that the bug is only reproducible when multiple threads are sharing a single file handle.


REGRESSION. Last worked in version 7u65

ADDITIONAL REGRESSION INFORMATION:
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

Compile the test case application using JDK 1.7 or 1.8 with -target 1.7. We saw no appreciable difference between these two options. We also saw no difference in compiling with -target 1.8 (ie, that would perform the same as with 1.7 bytecode under the JRE 1.8).

With the target file system as the "current directory", run the following command to run the test case application:

  java TestSynchLockContention_J7 10 1000000 1

[first param: 10 threads; second: 1million iterations each; third: one 50-byte line per iteration]

Note that elapsed times from this test will vary from run to run, and this is expected due to natural disk and OS processes. The first time this is run will often be the slowest, and subsequent runs will be faster. We ran the application ten times under each configuration to determine an average performance for the configuration.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -

Performance on 1.8.0.40 should, on average, be very similar (within the standard deviation) to performance on 1.7.0.51.
ACTUAL -

Performance on 1.8.0.40 is reliably half that of 1.7.0.51 - the application takes twice as long for ten threads to write 500MB in 50-byte chunks.

Note that this holds true whether the app is compiled using JDK 1.7 or JDK 1.8 (ie, it does not appear to be dependant upon the bytecode version or compiler optimizations).

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.ArrayList;
import java.util.List;

/**
 * Test writing to disk by multiple threads all contending over the synchronized lock ...
 */
public class TestSynchLockContention_J7 {
public static void main(String[] args) throws IOException, InterruptedException {

try ( ContendedResource resource = new ContendedResource("outfile.txt") ) {
int contenderCount = Integer.parseInt(args[0]);
int usageCount = Integer.parseInt(args[1]);
int linesPerUse = Integer.parseInt(args[2]);

List<Contender> contenders = new ArrayList<>(contenderCount);
long start = System.currentTimeMillis();
for (int i = 0; i < contenderCount; i++) {
Contender worker = new Contender(resource, linesPerUse, usageCount);
contenders.add(worker);
worker.start();
}
for (Contender contender : contenders) {
contender.join();
}
long end = System.currentTimeMillis();
System.out.println("" + contenders.size() + " threads wrote total of " + resource.getBytecount() + " bytes in " + (end - start) + "ms.");
}
}

private static class ContendedResource implements AutoCloseable {
private long bytecount = 0;
private PrintWriter out;
public ContendedResource(String filename) throws IOException {
File outfile = new File("outfile.txt");
out = new PrintWriter(new FileWriter(outfile));
}
public synchronized long useResource(long lineslong) {
for ( int i=0; i<lineslong; i++ ) {
out.print("This is a bit of text written to the file 123456.\n");
}
bytecount += 50*lineslong;
return lineslong;
}

public synchronized long getBytecount() {
return bytecount;
}

@Override
public synchronized void close() {
out.close();
}
}

private static class Contender extends Thread {
private final ContendedResource resource;
private final int linesPerUse;
private final int usageCount;

private Contender(ContendedResource resource, int linesPerUse, int usageCount) {
this.resource = resource;
this.linesPerUse = linesPerUse;
this.usageCount = usageCount;
}

@Override
public void run() {
for ( int i=0; i<usageCount; i++ ) {
resource.useResource(linesPerUse);
}
}
}
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The only workaround at the current time appears to be reducing load on the logging subsystem.