Value type sorting

[Tobias Hartmann]

Hi Doug,

On 27.08.2018 15:03, Doug Lea wrote:
> Thanks. While this can be worked around for particular cases, it will
> become a more common issue with generics+values, for which using
> Comparables and/or Comparators will be inescapable. It might help to
> intrinsify {Integer,Long, etc}.compareTo methods to somehow return coded
> condition status registers or somesuch (since only one comparison
> instruction is actually needed)? If users know that these primitive
> methods are optimized, they can use them to construct more efficient
> compareTo methods.

Yes, I agree that this pattern might become more common with value types and generics.

After looking at this in more detail, I've figured that the problem is not traps inserted due to
profiling (all paths should have been marked as taken anyway) but just C2 being not able to optimize
the following pattern:

  public static int compare(long a, long b) {
      return (a < b) ? -1 : (a == b) ? 0 : 1;
  }

  public static boolean test1(long a, long b) {
      return compare(a, b) > 0;
  }

  public static boolean test2(long a, long b) {
      return a > b;
  }

Test1 is compiled to two cmp instructions:

  0x00007f2e04cf714c: cmp    %rdx,%rsi
  0x00007f2e04cf714f: jl     0x00007f2e04cf7156
  0x00007f2e04cf7151: cmp    %rdx,%rsi
  0x00007f2e04cf7154: jne    0x00007f2e04cf7168
  [...]

Whereas test2 is compiled to just one:

  0x00007f2e04d19fd4: cmp    %rdx,%rsi
  0x00007f2e04d19fd7: cmovle %r10d,%eax
  [...]

So the performance difference comes from a limitation of C2 unrelated to value types. I'll have a
look if we can optimize that or file an RFE.

Best regards,
Tobias