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 constructed.
But don't we have the same overhead at object construction time?
I remember having read somewhere the
Clemens Eisserer said the following on 12/15/10 06:37:
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 constructed.
But don't we have the same overhead at object
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.
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
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
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.
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
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:
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
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
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
11 matches
Mail list logo