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

Peter Levart peter.levart at gmail.com
Thu Oct 9 16:53:59 EDT 2014

On 10/09/2014 07:53 PM, Paul Sandoz wrote:
> 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?).

Or, if nmethod that depends on the value of the field which is 
constant-folded in it's code, modifies this same field in 1st part and 
after that executes 2nd part that uses constant-folded value? How does 
Hotspot deal in general with situations where the optimized code, while 
executing, invalidates it's assumptions? Does this ever happen currently?

Regards, Peter

> 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.
> Paul.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141009/954a0fc8/attachment-0001.html>

More information about the Concurrency-interest mailing list