The classic vm C interpreter does not handle the MIN_LONG % -1L correctly. According to spec, the result should the 0. But the c interpreter gives MIN_LONG. The bug is caused by coding error in lrem bytecode. The code looks like (look for ^^):
        case opc_l##name: if (test && ll_eqz(S_LONG(-2))) { JAVA_ERROR("ArithmeticException", "/ by zero"); } if (test && (ll_eq(S_LONG(-4), LLONG_MIN) && ll_eq(S_LONG(-2), -1))) { if (isrem) { SET_S_LONG(-2, ll_zero_const); ^^ (should be -4)
                } else { /* do nothing. */ } } else { SET_S_LONG(-4, ll_##name(S_LONG(-4), S_LONG2(-2))); } TRACE(("\t%s => %s\n", opnames[opcode], S_LONGSTRING(-4))); SIZE_AND_STACK(1, -2);

The bug has affect on all platform, especially with java_g.

public class Test {
  public static void main(String[] args) {
    long l = Long.MIN_VALUE;
    System.out.println(l % -1L);
  }
}

NOTE: The assembly interpreter used by java is not affected by this bug.