Таинственный FrontCache

[datacompboy]

Так вот почему они скрывают их реализацию! Им СТЫДНО :)

[RainM]

Можно попробовать заюзать декомпилятор, чтобы проще было листинги анализировать.
jad геренегил вполне удобоваримые листинги.

[AlexanderYastrebov]

gist.github.com/AlexanderYastrebov/5135780

[RainM]

Спасибо! С интересом глянул.
Кстати, в jre есть оптимизация для Integer'ов — для объектов, хранящих значения из интервала -127..127 используется объектный пул.

[vladimir_dolzhenko]

это есть ещё со времён java 5 — и более того, в sun/oracle jre можно расширять верхнюю границу при помощи ключа
-Djava.lang.Integer.IntegerCache.high=max

и ещё говориться о

/**
     * Cache to support the object identity semantics of autoboxing for values between 
     * -128 and 127 (inclusive) as required by JLS.
     *
     * The cache is initialized on first usage. During VM initialization the
     * getAndRemoveCacheProperties method may be used to get and remove any system
     * properites that configure the cache size. At this time, the size of the
     * cache may be controlled by the vm option -XX:AutoBoxCacheMax=<size>.
     */

[tagir_valeev]

Ага, спасибо. Я использовал когда-то jad, но лень было его устанавливать. Пару десятков строчек проще и надёжнее декомпилировать по ассемблеру в уме :-) Похоже, jad генерики совсем не любит и скобки ставит скупо, лишь по мере необходимости. Такое я воспринимаю хуже, чем ассемблер, мне всё время кажется, что у сдвига приоритет выше:

 return -1 << 32 - Integer.numberOfLeadingZeros(i - 1);

[madkite]

Есть ещё jd и fernflower — они лучше понимают байт-код новых версий java.

[doom369]

По поводу AggressiveOpts
if (AggressiveOpts)

таких вот условий по коду не мало. Поэтому для упрощения я не включал их в пост.

[tagir_valeev]

На мой взгляд, это неправильный подход. Честно говоря, я думал, что вы добросовестно заблуждаетесь. В вашем посте написано:

Не в том плане, что она резко увеличивает производительность Вашего приложения, а в том смысле, что она всего лишь изменяет значения других опций.

Выражение «всего лишь изменяет значения других опций» — это не упрощение, это либо заблуждение, либо ложь. Может, добавите какой-нибудь минимальный комментарий про альтернативную реализацию некоторых классов? Или хотя бы допишете, что не только в перечисленных опциях дело. А то ваш пост хорошо ищется в гугле, люди читают и верят вам :-)

[doom369]

Ну в целом, Вы правы. Добавил ремарку.

[boolivar]

А есть где-нибудь сравнение быстродействия этих коллекций?

[Walrus]

Власти Оракл скрывает!!!

[tagir_valeev]

Вот, кстати, вы спросили бы начальство, зачем они это делают :-)

[Walrus]

А зачем спрашивать. Мы знаем, но если молчать и надувать щеки — то можно тешить свое ЧСВ. :)))

[DiNoZawR]

Этот фильм до сих пор популярный…

[vladimir_dolzhenko]

Шутки-шутками, но всё же было бы интересно услышать предысторию к чему это делалось и зачем.

Я понимаю, что это некоторый эксперимент, ибо AggressiveOpts толсто намекают на это. Собственно какой аспект хотелось обкатать, или в каких случаях это должно работать лучше?

[aib]

То что nvidia подкручивает драйвера для тестов все уже привыкли, а как Oracle крутит что-то, да еще при использовании специальных опций, так низя.

[Walrus]

Про java.math.* скажу, что это было временное хранение. Новый убыстренный java.math.* уже давно в java8.

[Walrus]

а вот еще кусочек мозаики.

[Throwable]

Скорей всего эта реализация была взята из JRockit-а, ибо Оракл давно собиралась перенести в JVM «лучшие черты JRockit».
А вот чисто теоретиццки, возникала ли когда-нибудь идея сделать native имплементацию части классов rt.jar? Всякие байткод компиляторы типа excelcior не в счет. Именно ручками на сях.

[vladimir_dolzhenko]

Месье просто обязан для себя открыть intrinsic в java, не говоря уже о jit.