6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization
brian.goetz at oracle.com
Mon Nov 22 15:29:18 UTC 2010
Is it possible to coalesce the fences so that we don't incur them on every
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:
>> 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
> 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.
More information about the core-libs-dev