gcj's IO performance vs blackdown JDK

Fri Jan 9 22:09:00 GMT 2004

On Jan 10, 2004, at 4:34 AM, Dalibor Topic wrote:
> Bryce McKinlay wrote:
>>> Here's my BufferedReader and InputStreamReader improvements. Perhaps 
>> you would like to bake these versions off against your modifications. 
>> In the case of BufferedReader the new code is a lot simpler as well 
>> as potentially more efficient, since it gets rid of all the 
>> special-case checks for "\r" at the end of each line.
>> Sorry for coming late into this BufferedReader discussion. Since 
> according to the CVS you wrote the huge chunk of the \r\n handling 
> code, it would be interesting to hear why it's possible to get rid of 
> it now.

Thanks for looking at this Dalibor. I've attached the diff below.
Its possible to get rid of the \r\n special cases because readLine() 
was changed to consume the entire end-of-line sequence before 
returning, even if the last character in the buffer is a \r. So, a 
little more work in readLine() saves a lot of special cases elsewhere 
in the BufferedReader code.
>> /** Read more data into the buffer, updating pos and limit 
>> appropriately,
>> * and taking mark and markLimit into account. Assumes pos==limit 
>> initially.
>> * Return true if chars were added to the buffer, or false on EOF. 
>> */
>> private boolean refill() throws IOException
>> I think this function could yield a significant perfomance boost if we 
> used a circular buffer in the BufferedReader. Then the arraycopys to 
> shuffle bytes around to the beginning may not be necessary.

Perhaps, but given all the different combinations of buffer state, mark 
and markLimit settings, and the special cases needed to accommodate 
readLine(), I think a circular buffer would be difficult to implement 
correctly here. Also, the arraycopys you mention are only required in 
the event where the buffer is refilled with a (non-invalidated) mark 
set - no doubt this is a rare case. Still, if you want to give it a try 
... ;-)
>> public String readLine() throws IOException
>> {
> [snip]
>> // Consume the line termination character(s).
>> I think that's a bad idea, because it can cause deadlocks. See 
> http://developer.apple.com/technotes/tn/tn1157.html . Citing from it :
>> "Fixing the server
>> If you happen to be developing the server as well, and can make 
> changes to its code, then there's an even better fix you can make on 
> the server side instead of changing the client. In the previous 
> section, I described how the server blocks waiting for a character to 
> follow the CR so it can tell whether it's an LF or not. A more 
> intelligent way to handle nonstandard line breaks is for the server to 
> process the input line immediately once it receives the CR, but to set 
> a flag that indicates that if the next character received is an LF it 
> should be ignored.
>> This way the server will not block after it receives the CR, will 
> process the command and return a response, and the client code will 
> receive the response and continue running. No deadlock."

Interesting. I must admit I did not consider this case. Perhaps we do 
need the special \r\n handling after all.
Thanks for the feedback.
Regards,
Bryce.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Reader.patch.txt
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040109/abda0691/attachment.txt>
-------------- next part --------------