С учетом 16 значений - как-то хочется MMX, но тогда JNI

Вроде, в И-нете предлагают заменять abs на подсчет двух вариантов + OR. Насколько это работает и математически правильно - не знаю
http://www.asmcommunity.net/forums/topic/?id=18590

1) Смотрю на
http://developer.classpath.org/doc/java/lang/Math-source.html

Если это правда, то вполне возможно, что возведение в квадрат (как советовал mayton) будет быстрее, чем условные переходы.

2.1)
На C еще предлагают реализовывать

abs(x) = (x XOR y) - y
where y = x >>> 31 (assuming 32-bit input), and >>> is arithmetic right shift operator.

gcc 4.6.3 generated assembly snippet (AT&T syntax)

movl -8(%rbp), %eax # -8(%rbp) is memory for x on stack
sarl $31, %eax # shift arithmetic right: x >>> 31, eax now represents y
movl %eax, %edx #
xorl -8(%rbp), %edx # %edx = x XOR y
movl %edx, -4(%rbp) # -4(%rbp) is memory for output on stack
subl %eax, -4(%rbp) # (x XOR y) - y

2.2) If you have a fast multiply by +1 and -1, the following will give you abs(x):
((x >>> 30) | 1) * x

и много других способов

https://stackoverflow.com/questions/2639173/x86-assembly-abs-implementation

Но как изобразить на Java где unsigned арифметика через ж... - х.з.

Вполне возможно, что уход с int на float так же может быть оправдан. Т.к. будет аппаратная реализация данной инструкции

"In general, computing the absolute-value of a floating-point quantity is an extremely cheap and fast operation." ( C ) интернет

" it, most implementations follow the IEEE-754 standard. In that standard, each floating-point value's representation contains a bit known as the sign bit, and this marks whether the value is positive or negative....Therefore, taking the absolute value basically just amounts to flipping a byte in the value's representation in memory. In particular, you just need to mask off the sign bit (bitwise-AND), forcing it to 0—thus, unsigned."

Скорость не замерял. Нужно не мне.

Если abs сделано через условные переходы..... то 16 переходов, 8 промахов предсказателя переходов... тут хоть возведение в квадрат, хоть квадратный корень, хоть тригонометрические ф-ции - будет совершенно пофиг

Но это нужно иметь доступ к актуальным исходникам + быть уверенным, что ф-ции приведенные в исходниках ровно те же, которые реально используются JVM.

Последнее предложение поясняю: ряд ф-ций хоть и имеют исходники на Java, на самом деле заменяются C-инлайнами реализованными в ядре/JIT.

Я бы подумал, что базовые арифметические функции, по хорошему, авторы Java должны были бы на C в JIT перетащить. Относится ли к этим ф-циям Math.abs - х.з. Смотреть код Open JDK или замерять время, лично мне влом.

Персонально я, взял бы в руки C с inline ассемблером и переписал на MMX. две пары по 3 инструкции (в первых Pentium было два исполняемых блока, т.ч. фактически 3 последовательные инструкции, т.к. две пары будет выполняться на разных процессорных блоках). Все остальное - от лукавого. IMHO & AFAIK На невозможность выполнения на 386, 486 процессорах - думаю в наше время можно забить.

Мне кажется Вы излишне оптимистично относитесь к JIT

Его тоже разрабатывали наши коллеги-программисты. Коллегам нужно доверять.