RFR (M): 8143925: Enhancing CounterMode.crypt() for AES
vladimir.kozlov at oracle.com
Tue Jan 5 17:17:04 UTC 2016
> On 31 Dec 2015, at 22:33, John Rose <john.r.rose at oracle.com> wrote:
> When performing explicit range checks in pre-intrinsic code,
> let's try to use the new intrinsic functions in java.util.Objects,
> called checkIndex, checkFromToIndex, and checkFromIndexSize.
Please, don't forget that checks in pre-intrinsic code should match checks generated by javac (bytecode) for
intrinsified methods. Otherwise those checks will not be removed (by dominated checks in pre-intrinsic code) when
intrinsics are not support on a platform. That is why we currently have such duplicated pre-intrinsic code.
On other hand when intrinsics are supported they don't have checks so if they present we can intrinsify pre-intrinsic
code as you suggested.
On 1/5/16 1:48 AM, Andrew Haley wrote:
> On 04/01/16 20:12, John Rose wrote:
>> Corrected, thanks. They don't need to be intrinsics if they optimize well.
>> The point is that the library functions have code shapes which work well
>> with the JIT. For example, the multi-index checks might (as in Kishor's code)
>> be implemented on top of the single-index check, without themselves being
> We seem to be missing the opportunity to convert
> i >= 0 && i < size
> (unsigned)i < (unsigned)size
> and this is, as far as I can see, the only real code-quality advantage of
> the checkIndex intrinsic. Could we not do this optimization and then
> drop the C2 checkIndex intrinsic?
More information about the hotspot-compiler-dev