diff options
author | Goktug Gokdogan <goktug@google.com> | 2023-12-12 14:08:21 -0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-12-12 22:08:21 +0000 |
commit | da18e25f22afcd916171aae8511c7b6860d4d7cc (patch) | |
tree | e920a053051b09ec936392943787cc802f8e9fbd /src/passes/TupleOptimization.cpp | |
parent | a6c1165db639e505d68758b14256492ede57e362 (diff) | |
download | binaryen-da18e25f22afcd916171aae8511c7b6860d4d7cc.tar.gz binaryen-da18e25f22afcd916171aae8511c7b6860d4d7cc.tar.bz2 binaryen-da18e25f22afcd916171aae8511c7b6860d4d7cc.zip |
J2CL: Add extra guardrails (#6171)
The patch puts a new guardrail that will only hoist the field
if it is initialized with the owner class.
The constant hoisting optimization in J2CL pass relies on the
assumption that clinit that will initialize the field will be
executed before the read of the field. That means the field
that is optimized is within the same class:
class Foo {
public static final Object field = new Object();
}
Although it is possible to observe the initial value, that is
not intention of the developer (which the point of the
optimization).
However can also see a similar pattern in following:
class Foo {
public static Object field;
}
class Zoo {
static {
Foo.field = new Object();
}
}
Currently the pass also optimizes it as well since the field
is only initialized once and by a clinit. However Zoo clinit
is not guaranteed to be run before Foo.field access so it is
less safe to speculate on the intention of the developer here
hence it is not worth the risk.
FWIW, we haven't seen this issue. But this is something we
are also guarding in Closure Compiler so I decided it is
worthwhile to do here as well.
Diffstat (limited to 'src/passes/TupleOptimization.cpp')
0 files changed, 0 insertions, 0 deletions