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

[Brian Goetz]

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:
>>> 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 too because it uses putVolatile.
>>
>
> Yes this will suffice. For some discussion about emulating
> final, see the draft (NOT JDK7 (maybe 8)) Fences API
> (http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html)
>
> In fact if this API existed you could just use it (modulo
> some JVM/platform-dependent tearing issues for long/double).
> In the mean time, putOrdered suffices. But note that
> putOrdered exists only for int, long, and volatile.
> For the others you could just resort to the volatile form.
>
> The cost savings of using these lighter fences are
> platform dependent. On some Intel i7s, it might be
> less than 10 cycles. On most processors, it is on the
> order of 30. On older P4s (and PowerPC) it can be over 100.
>
> -Doug
>