-
Enhancement
-
Resolution: Unresolved
-
P4
-
repo-valhalla
We currently always allocate when performing acmp on inline types and delegate to ValueBootstrapMethods::isSubstitutable() if the klasses are equal. We should try to check for substitutability at compile time or even emit optimized code for the substitutability check (for example, directly compare memory if there are no oop fields).
With all the branching in Parse::do_acmp, we should also make sure that profile information is correctly used to set branch probabilities (Tobias: I checked while working onJDK-8325417 but we should double-check and maybe add an IR framework test to verify that the traps are at the correct branch. TestAcmpWithUnstableIf could be used/converted, TestLWorldProfiling already contains some tests for acmp profiling).
ValueBootstrapMethods::isSubstitutable() is currently special cased in the JIT to avoid recursion. Should it use unsafe for pointer comparison?
The runtime call to isSubstitutable might end up with both arguments referring to the same inline type. We should remove it in that case.
With all the branching in Parse::do_acmp, we should also make sure that profile information is correctly used to set branch probabilities (Tobias: I checked while working on
ValueBootstrapMethods::isSubstitutable() is currently special cased in the JIT to avoid recursion. Should it use unsafe for pointer comparison?
The runtime call to isSubstitutable might end up with both arguments referring to the same inline type. We should remove it in that case.
- relates to
-
JDK-8255024 [lworld] Split acmp forward through virtual calls to Object.equals
- Open
-
JDK-8255030 [lworld] Vectorize equality comparison of some inline types
- Open
-
JDK-8325417 [lworld] Incorrect re-execution state at uncommon traps emitted by acmp
- Resolved
-
JDK-8335128 [lworld] use virtual dispatch to manage fieldwise operations on values
- Open