6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

This is a patch to default deserialization so that it uses volatile-write when setting final fields: http://cr.openjdk.java.net/~alanb/6647361/webrev/ Thanks, Alan.

Re: Code review request 6858865: Fix for 6728376 causes regression if the size of data is 0 and malloc returns Null for 0-length

Xueming Shen wrote: Alan, After staring those simple, 11 lines of change for minutes, I believe we should simply go back with the original approach at http://cr.openjdk.java.net/~sherman/6858865/webrev.00 The change in http://cr.openjdk.java.net/~sherman/6858865/webrev.00 obviously is

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

Le 22/11/2010 14:52, Alan Bateman a écrit : This is a patch to default deserialization so that it uses volatile-write when setting final fields: http://cr.openjdk.java.net/~alanb/6647361/webrev/ Thanks, Alan. I wonder if we can't use putOrdered instead of putVolatile. In that case

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

The performance impact of this might be severe when deserializing object graphs with lots of final fields (and we recommend using final fields wherever possible.) And, I'm a little unclear on the approach here. If the goal is to provide a happens-before edge between deserializing an object

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

On 11/22/2010 07:52 AM, Alan Bateman wrote: This is a patch to default deserialization so that it uses volatile-write when setting final fields: http://cr.openjdk.java.net/~alanb/6647361/webrev/ Please don't go farther down the path of only JDK/proprietary classes can properly deserialize.

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

On 11/22/10 09:35, Rémi Forax wrote: This is a patch to default deserialization so that it uses volatile-write when setting final fields: http://cr.openjdk.java.net/~alanb/6647361/webrev/ I wonder if we can't use putOrdered instead of putVolatile. In that case Field.set() should be changed

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

Is it possible to coalesce the fences so that we don't incur them on every field write? On 11/22/2010 10:10 AM, Doug Lea wrote: On 11/22/10 09:35, Rémi Forax wrote: This is a patch to default deserialization so that it uses volatile-write when setting final fields:

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

Brian Goetz wrote: Is it possible to coalesce the fences so that we don't incur them on every field write? I've also been concerned about performance. As I understand it, but maybe I have it wrong, is that the JLS [1] doesn't allow this when changing final fields after an object is

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

On 11/22/10 10:41, Alan Bateman wrote: Brian Goetz wrote: Is it possible to coalesce the fences so that we don't incur them on every field write? I've also been concerned about performance. As I understand it, but maybe I have it wrong, is that the JLS [1] doesn't allow this when changing

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 4bb2a0229796 Author:michaelm Date: 2010-11-22 16:09 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4bb2a0229796 6984182: Setting SO_RCVBUF/SO_SNDBUF to larger than tcp_max_buf fails on Solaris 11 if kernel params changed Reviewed-by: alanb, chegar !

hg: jdk7/tl/jdk: 3 new changesets

Changeset: 951db417fc3c Author:mullan Date: 2010-11-22 10:16 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/951db417fc3c 6995424: Eliminate dependency to a deprecated API com.sun.security.auth.PolicyFile Reviewed-by: mchung !

Re: Code review request 6858865: Fix for 6728376 causes regression if the size of data is 0 and malloc returns Null for 0-length

On 11/22/2010 05:52, Alan Bateman wrote: Xueming Shen wrote: Alan, After staring those simple, 11 lines of change for minutes, I believe we should simply go back with the original approach at http://cr.openjdk.java.net/~sherman/6858865/webrev.00 The change in

Re: Code review request 6858865: Fix for 6728376 causes regression if the size of data is 0 and malloc returns Null for 0-length

Xueming Shen wrote: : We can not simply return 0 if the out buffer length is NOT 0 even when in buffer length is 0. The de/inflater might have something to push/flush out even there is no more input. Consider the buffer in last invocation of de/inflating is not big enough, de/infalte() gets

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

Doug Lea said the following on 11/23/10 01:49: On 11/22/10 10:41, Alan Bateman wrote: Brian Goetz wrote: Is it possible to coalesce the fences so that we don't incur them on every field write? I've also been concerned about performance. As I understand it, but maybe I have it wrong, is that

hg: jdk7/tl/jdk: 6858865: Fix for 6728376 causes regression if the size of data is 0 and malloc returns Null for 0-length

Changeset: 0049b9a85e74 Author:sherman Date: 2010-11-22 16:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0049b9a85e74 6858865: Fix for 6728376 causes regression if the size of data is 0 and malloc returns Null for 0-length Summary: don't throw OOME when in or out buffer

hg: jdk7/tl/jdk: 7001434: charset name for Cp833 should be x-IBM833.

Changeset: 7fac77daa9be Author:sherman Date: 2010-11-22 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fac77daa9be 7001434: charset name for Cp833 should be x-IBM833. Summary: changed the name to x-IBM833 in extsbcs Reviewed-by: alanb !