There are multiple regressions in the web container atomics benchmarks. In this bug, we will focus on the issue that affects simple servlet writing.
For servlets, there is a regression in the way in which strings are written to the servlet output stream. Previously, a call to servletOutputStream.println() ended up in com.sun.grizzly.util.buf.C2BConverter, which got the character array from the string and passed it to the encoder. Because the buffer has a backing array, encoding it is simply a matter of iteration through the array.
Now in the org.glassfish.grizzly.http.server.io.OutputBuffer.flushCharsToBuf() method, we wrap the string in a CharBuffer and pass that to the character encoder. Because that CharBuffer does not have a backing array, the encoder uses its encodeBufferLoop() method, which results in lots of calls to buffer.get() rather than simply iterating through the array. This causes a significant performance penalty.
However, this code path is not used by JSP tests (JSP writers use char by the time the data gets to the OutputBuffer class). The JSP paths make up the bulk of the web container atomics benchmarks – hence changing the subject of this bug (and will file a separate bug on whatever is regressing in the JSP path).