Hi Vitaly,
> De: "Vitaly Davidovich" <vita...@gmail.com>
> À: mechanical-sympathy@googlegroups.com
> Envoyé: Dimanche 18 Décembre 2016 19:00:04
> Objet: Re: private final static optimization
> It doesn't care about reflection - modifying final fields via reflection is
> undefined by the JLS. Unfortunately, the same optimization isn't done for
> instance finals because some well known frameworks use that facility.
THose frameworks are not wrong, the JLS allows to change final fields when
doing deserialization (see JLS 17.5.3) and it's hard for the JIT to know if the
reflection is used during a deserialization or not.
> Oracle is working on ways to mitigate that in a backcompat manner (deopt when
> it
> detects such modifications).
I think, it's easier in the modular world of 9, you know statically if a module
uses sun.misc.Unsafe (it has to requires jdk.unsupported transitively) and if a
package is open to modification by reflection (the package is declared as open
or the module itself is declared as open). A JIT can use this heuristic instead
of trying to trap and deopt if a final field change which requires a lot of
metadata.
> But static finals work out of the box already without deopt (the modification
> isn't visible if done after code is JIT compiled).
cheers,
Rémi
> On Sun, Dec 18, 2016 at 5:12 AM Peter Veentjer < pe...@hazelcast.com > wrote:
>> Hi Martin,
>> so the JIT is able to remove the if(ENABLED) branch if ENABLED = false?
>> How does it deal with reflection? The JIT is triggered to deoptimize the code
>> when the ENABLED changes?
>> On Sunday, December 18, 2016 at 10:50:48 AM UTC+2, Peter Veentjer wrote:
>>> The following question is one out of curiosity of compiler optimization of
>>> private final static fields.
>>> I created a very contrived example. The idea is to have some kind of switch
>>> that
>>> can be enabled/disabled when the JVM starts up.
>>> public class Foo{
>>> private final static boolean ENABLED = Boolean.getBoolean("bla.enabled");
>>> private int x;
>>> public void foo(int x){
>>> if(ENABLED){
>>> if(x <0) throw new RuntimeException();
>>> }
>>> this.x = x;
>>> }
>>> }
>>> The question is if the JIT is allowed to remove the ENABLED check if
>>> ENABLED is
>>> false. My worry is that due to reflection, one could set the ENABLED to true
>>> and therefor the JIT isn't allowed to remove the ENABLED check.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email
>> to mechanical-sympathy+unsubscr...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout .
> --
> Sent from my phone
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email
> to mechanical-sympathy+unsubscr...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout .
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
