[concurrency-interest] lazy finals - was: Here's why Atomic*FieldReference access checking is broken

Paul Sandoz paul.sandoz at oracle.com
Thu Oct 9 13:53:31 EDT 2014

On Oct 9, 2014, at 3:23 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> What HotSpot misses right now (to preserve correctness w.r.t. Reflection API) is a way to track dependencies between final fields and nmethods which embed their values. It would allow to invalidate all nmethods which rely on stale value and ensure the updated value is "visible" everywhere in the running application.

In such a case would it provide a form of eventual consistency or would there be checks in place before a final field is used? e.g. one thread could be stomping on a final field while another thread is executing an nmethod under the assumption the field is final (and what if the nmethod is executing a large or infinite loop?). 

Instead perhaps final fields should really be final and safe mechanisms are provided to support the DI and serialization use-cases, which i suspect cover almost all use-cases.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141009/7e629118/attachment-0001.bin>

More information about the Concurrency-interest mailing list