RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v6]

[Aleksey Shipilev]

On Wed, 24 Jan 2024 18:51:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Naive question: the right way to use this would be almost invariably be like this:
> 
> ```
> if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
>     // fast-path
> }
> // slow path
> ```
> 
> Right? 

Yes, I think so.

> Then the expectation is that during interpreter and C1, `isCompileConstant` always returns false, so we just never take the fast path (but we probably still pay for the branch, right?). 

Yes, I think so. For C1, we would still prune the "dead" path, because C1 is able to know that `if (false)` is never taken. We do pay with the branch and the method call in interpreter. (There are ways to special-case these intrinsics for interpreter too, if we choose to care.)

> And, when we get to C2 and this method is inlined, at this point we know that either `foo` is constant or not. If it is constant we can check other conditions on foo (which presumably is cheap because `foo` is constant) and maybe take the fast-path. In both cases, there's no branch in the generated code because we know "statically" when inlining if `foo` has the right shape or not. Correct?

Yes. I think the major use would be using `constexpr`-like code on "const" path, so that the entire "const" branch constant-folds completely. In [my experiments](https://github.com/openjdk/jdk/pull/17527#issuecomment-1906379544) with `Integer.toString` that certainly happens. But that is not a requirement, and we could probably still reap some benefits from partial constant folds; but at that point we would need to prove that a "partially const" path is better than generic "non-const" path under the same conditions.

I agree it would be convenient to put some examples in javadoc.

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

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1908736651