Check for boolean array when running bastore bytecode

[tajila]

Check for boolean array when running bastore bytecode

The JVM spec states: "If the arrayref refers to an array whose
components are of type boolean, then the int value is narrowed by taking
the bitwise AND of value and 1; the result is stored as the component of
the array indexed by index"

Issue: #2049

Signed-off-by: tajila atobia@ca.ibm.com

[tajila]

@pshipton please review

[DanHeidinga]

FYI @andrewcraik @fjeremic The JIT will need to modify the jit equivalent of bastore to do the & 1 before storing the value for boolean[] as well

[DanHeidinga]

Jenkins test sanity plinux jdk8

[DanHeidinga]

Before merging this, I'd like to hear from the some of the JIT committers about how long it would take to update the JIT to match this behaviour. Having the interpreter and JIT have different results isn't optimal

[fjeremic]

Before merging this, I'd like to hear from the some of the JIT committers about how long it would take to update the JIT to match this behaviour.

So we had a discussion on this and came to the conclusion that it will take us some single digit integer number of weeks to complete this on the JIT side.

The reason for this is because of the overloaded bytecode for both byte and boolean values we could do one of the two following solutions in the JIT:

1. Check the arrayref at runtime for boolean[] and do the AND with 1
2. Prove at compile time whether the arrayref is of type boolean[] and do the AND with 1

Doing 1. would involve introducing control flow at IL generation where it does not exist in the bytecode, which is something we don't do today so we would have to teach the IL generator about that. The alternative is to do the check at codegen time in the evaluators which would be simpler but will still involve additional path length and changes on all 4 code generators.

We would like to avoid doing 1. as it is expensive at runtime and would potentially hinder other optimizations by introducing such control flow.

Doing 2. is the proper way of solving this issue from the JIT perspective as the problem is decidable at compile time. Given Java semantics it is always possible to determine the type of the arrayref starting from the entry of a method. However doing so would involve doing a dataflow analysis which is quite expensive in terms of compile time. We cannot do a full dataflow for this problem given that it has to be done at IL generation time. We will need to come up with some simplified version of a dataflow to determine the type of the arrayref statically at compile time.

This solution must not increase compile time (by much) on the set of benchmarks we track. IL generation runs for every method we compile and every method we attempt to inline or consider inlining so it is important compile time is taken into consideration when implementing this IL pass during IL generation.

Because of these restrictions and other commitments we will need some time to come up with the right solution to this problem. Hope this clears things up for the JIT perspective.

[tajila]

FYI, we will have to do something similar for putstatic and putfield as well.
See #2057

[andrewcraik]

From a performance perspective doing 1 is a non-starter - any runtime checks will greatly affect performance (especially in Java 9 and later due to strings using byte arrays as their backing storage). The proof is the way we need to go - especially since verified bytecode already passed the check of being able to statically decide the type. Would be nice if we could pickup the verification result rather than having to figure it out with a dataflow though the data flow Is likely required when the verifier is off.

Will need to consider putstatic and putfield as well.

Is this a change in the spec?

[DanHeidinga]

Is this a change in the spec?

Yes

[DanHeidinga]

Jenkins test sanity plinux,aix,xlinux jdk8

[DanHeidinga]

JIT side is merged - #2910