RFR: 8261137: Optimization of Box nodes in uncommon_trap [v4]

[Igor Veresov]

On Wed, 10 Feb 2021 23:18:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > The improvement you are proposing is not specific to uncommon traps, but can be generalized to any debug usage at safepoints.
> > The downside is that, in general, rematerialization logic has to use the corresponding pure function in order to materialize the eliminated instance. In this particular case (primitive boxing), it has to take into account the caching effects of primitive box factories. Otherwise, user code can encounter identity paradoxes with rematerialized primitive box instances.
> > I don't see how the scalarization logic you propose preserves identity constraints imposed by `valueOf` factories.
> 
> Yes, it seems this optimization introduces the issue we had with Graal (8223320):
> "C2 doesn't model Integer.valueOf() as anything special. It just inlines it. So the check that determines whether to allocate a new Integer or take one from the cache always happens at runtime. Graal models it as a BoxNode. It is correctly lowered, however, if it needs to be present in a JVM state, it is described as an allocation. So the decision whether to allocate or take the cached value has to happen during the deopt."
> There is code in deoptimizer for JVMCI which looks for cached Boxed values. We may need to adopt it for C2 EA for this optimization to work.

In addition to using the logic that we already have there for Graal (see ```Deoptimization::get_cached_box()```), you need to track where the box came from. If it comes as a result of ```valueOf()``` then it has to come from the caches, if it's something that the user allocates with ```new Integer(x)```, then it should be just a normal scalarized object.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2401