harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Ellison (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-597) Synchronization on non-final field in DataInputStream/DataOutputStream
Date Tue, 13 Jun 2006 13:29:30 GMT
     [ http://issues.apache.org/jira/browse/HARMONY-597?page=all ]

Tim Ellison updated HARMONY-597:

    Attachment: harmony-597.diff

Suggested fix - awaiting a testcase.

> Synchronization on non-final field in DataInputStream/DataOutputStream
> ----------------------------------------------------------------------
>          Key: HARMONY-597
>          URL: http://issues.apache.org/jira/browse/HARMONY-597
>      Project: Harmony
>         Type: Bug

>   Components: Classlib
>     Reporter: Dain Sundstrom
>     Assignee: Tim Ellison
>     Priority: Critical
>  Attachments: harmony-597.diff
> It appears that the DataInputStream and DataOutputStream classes use a shared buffer
to reduce the creation of temporary buffer space.  This buffer is contained in the static
DataInputStream.byteBuf field and access to this field is controled by the boolean flag DataInputStream.useShared.
 Access to this field is gated by a synchronized lock on the byteBuf field.  The problem is
that sometimes code set the useShared field to false and then resizes the buffer by creating
a new one.  Since the lock object itself is changing the lock is virtually useless.  This
problem can be eliminated by synchronizing on a static final object instead of the buffer
> I think this code should be reexamined in it's entirety to determine if performance improvement
of a shared buffer is worth the added complexity.  If such a determination is made, I suggest
the code is rewritten using Java5 concurrency primitives.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message