[GLASSFISH-4949] print(char) does too much memory allocation Created: 29/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: performance
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: kohlerm Assignee: Scott Oaks
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 4,949
Status Whiteboard:


Tags: tp2-exclude


Hi all,
I just ran the following Servlet on the latest GlassFish V3 (April 21)

protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException

{ ServletOutputStream out = response.getOutputStream(); response.setContentType("text/html"); response.setHeader("pragma", "no-cache"); String sizeStr = request.getParameter("size"); int size=0; if (sizeStr!=null) size=Integer.parseInt(sizeStr); for (int i=0; i<size;i++) out.print((char)(255*Math.random())); }

With an reponse of 100000 (configurable by the size parameter of the servlet)
bytes 20Mbyte are allocated.

Profiling indicates that


which calls

java.nio.ByteBuffer.wrap(byte[], int, int) 100000 times as well as
java.nio.CharBuffer.wrap(char[], int, int) 100000 times.

The response time is 3 times slower than when using write on the Outputstream,
which allocates almost nothing except a Directbuffer.


Comment by kumara [ 30/Apr/08 ]

Exclude from the list being tracked for TP2 release.

Comment by kumara [ 19/Aug/08 ]

Add gfv3-prelude-include to status whiteboard

Comment by Scott Oaks [ 02/Sep/08 ]

First, it's not correct to compare calling print(c) vs write(c). The former
must encode the 16-bit character as a series of bytes; the latter can simply
write out the raw data. So the performance of printing characters vs writing
binary data will always be drastically different.

We have in the past explored various ways to get the fastest encoding out of
the JDK, and I think the current implementation is still optimal. We have filed
issues against the JDK for its memory use for encoding/decoding strings and are
tracking those. The JDK isn't well-designed for encoding single characters at a

I'm leaving this open for now so we can track the JDK issue, but at present,
this is the best we can do.

Comment by kumara [ 03/Sep/08 ]

v3 defect tracking

Comment by kohlerm [ 03/Sep/08 ]

Unfortunately, I don't have the profiling snapshot available anymore, but I seem
to remember that for each char at least one byte[] would be allocated.
I know that write is supposed to be faster than print because of the additional
encoding that print has to do, but still a factor of 3 seems to high for me.

And actually what really hurts it that 20 Mbytes are temporarily allocated just
to return 10000 bytes.


Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Generated at Wed Dec 02 04:35:18 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.