Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock
pcj at roundroom.net
Fri Jan 14 05:52:57 UTC 2011
I believe that the past performance concern was about the change from using ObjectOutputStream.defaultWriteObject to using OOS.putFields/writeFields, which adds some overhead-- although if you need to use them, you need to use them. (This wouldn't apply to the Hashtable fix, which looks fine to me.)
On Jan 13, 2011, at 5:31 PM, Mike Duigou wrote:
> I know that on the Oracle side we did internally discuss the potential performance impact. The main performance concern seems to be the extra GC work from creating the array of values (or the entry stack in the case of Hashtable). We decided though that for most collections the small size and short lifetime of the extra objects would mean that they would never escape the eden generation and would be quickly and efficiently GCed. We don't expect that this change will result in only insignificant (it's not "free") performance degradation whether considered from a microbenchmark perspective or from an overall system performance perspective.
> Alternative opinions, analysis and insights are, of course, welcome.
> On Jan 12 2011, at 22:31 , Peter Jones wrote:
>> Sorry for chiming in late here, but I was wondering-- has the performance impact of this change been measured? Many years ago, the performance impact vs. the apparent severity of the bug at the time held back this fix (using PutField). Of course, both sides of that consideration may have changed since then.
>> FWIW, the code change looks correct to me. A style nit: I would drop the "= null" initializer on line 1060-- it is a value that should never be read, so let the compiler enforce that (and then you could declare "data" final as well).
>> -- Peter
>> P.S. There is a serialization micro-benchmark framework under test/java/rmi/reliability/benchmark
>> On Jan 12, 2011, at 5:42 AM, Neil Richards wrote:
>>> On 10 January 2011 21:11, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>> The update to the javadoc looks fine to me. On the headers then we use the
>>>> GPL header on tests (no Classpath Exception).
>>> Sorry once again - please find attached with the corrected header for
>>> GPL (without Classpath exception).
>>> I hope I'm pretty much there now - let me know if you spot anything else.
>>> Unless stated above:
>>> IBM email: neil_richards at uk.ibm.com
>>> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the core-libs-dev