RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted

[Aleksey Shipilev]

Hi Volker,

On 10/26/2015 09:01 PM, Volker Simonis wrote:
> However, I already see the list of exceptions in
> trust_final_non_static_fields() growing longer and longer :)

Yes, it grows. This particular thing appears to have a very low
cost/benefit ratio. In fact, it is surprising how many people have
contacted me offline saying this what helps to get rid of Unsafe usages
for them. Yes, this is a band-aid, but this is a highly profitable
band-aid, considering the use case :)


> Maybe a new annotation "@TrustNonStaticFinalFields" would be the
> better solution? It should be public (but not necessarily in the
> standard java name space) to allow users to annotate their code and
> profit from such optimizations as well.

I am against adding yet another annotation, especially since it will
leak into publicly-accessible namespace. As we learned, people would
frown once we decide to pull it back, so it seems better to never tempt!

As noted in the JIRA issue, the "actual" way to fix this is to deal with
final fields wholesale, e.g. by speculatively optimizing them, and
detecting the stores. This will also solve A*FU thing we are discussing.
This is what Vladimir I. had shown at this list already:
 https://bugs.openjdk.java.net/browse/JDK-8058164

With a limited time budget, I think a sane tactics would be to add
another explicit exception to the stability rules, and invest the saved
time into solving the problem wholesale, and later ditch the exceptions.


> We could also avoid adding an annotation and instead just introduce a
> new option like
> -XX:TrustNonStaticFinalFieldsIn=<classname|packagename>. This would
> have the charm of not polluting the code with non-standard
> annotations. And it could be of type 'ccstrlist' (i.e. 'accumulating
> string argument') and pre-initialized with packages like
> "java/util/concurrent/atomic". 

While this is an interesting suggestion, I think parsing these lists
adds up to either classload, or compilation time, depending where you
implement the predicate tests, and how many hours you spend fine-tuning
it. Compiler Control JEP, I think, is providing the facilities to access
these properties in the uniform and more-or-less performant manner.


> Extending -XX:CompileCommand with
> something like a 'trustnonstaticfinalsin <class>' option would be just
> another flavour of this approach.

See above. Yes, compiler command would be nice. Compiler Control JEP had
not landed yet though. I would suggest to rebuild the exception list to
Compiler Control the next time a new exception is required.


> Both these proposals would give people the chance to experiment with
> this optimization without having to recompile HotSpot.

You can already experiment with the optimization (I assume in
benchmarks) by using global -XX:+TrustNonStaticFinalFields option.

Cheers,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151026/68ed6f73/signature.asc>