[concurrency-interest] lazy finals - was: Here's why Atomic*FieldReference access checking is broken
aaron.grunthal at infinite-source.de
Thu Oct 9 12:29:17 EDT 2014
On 09.10.2014 17:21, Peter Levart wrote:
> This would be a cool optimization for mostly read-only and rarely
> updated fields, but do we want to transform final instance fields into
> such thing just to support deserialization via reflection? If this is
> not a big deal to support than perhaps it is a better approach since it
> does not neglect null/zero values.
I think the issue here may be that final is used to signal two slightly
1. It's to tell the compiler: "This data (almost) never changes, please
optimize aggressively, I'm willing to take a significant performance hit
if I ever have to change it via reflection"
This might also be relevant for other language implementers, e.g. for
jruby class variables and constants which should remain constant but can
be easily changed via metaprogramming or initialized multiple times by
2. It's to tell users of the class that it's immutable data, it's safe
to pass around, that they're doing something wrong if they want to
change the value, etc.
Since immutable data objects are often ephemeral and not assigned to
static fields the programmer doesn't really expect the compiler to
perform constant folding.
It's also where the deserialization problem commonly occurs.
More information about the Concurrency-interest