Pull to refresh

Comments 23

Так вот почему они скрывают их реализацию! Им СТЫДНО :)
Можно попробовать заюзать декомпилятор, чтобы проще было листинги анализировать.
jad геренегил вполне удобоваримые листинги.
Спасибо! С интересом глянул.
Кстати, в jre есть оптимизация для Integer'ов — для объектов, хранящих значения из интервала -127..127 используется объектный пул.
это есть ещё со времён 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>.
     */
Ага, спасибо. Я использовал когда-то jad, но лень было его устанавливать. Пару десятков строчек проще и надёжнее декомпилировать по ассемблеру в уме :-) Похоже, jad генерики совсем не любит и скобки ставит скупо, лишь по мере необходимости. Такое я воспринимаю хуже, чем ассемблер, мне всё время кажется, что у сдвига приоритет выше:
 return -1 << 32 - Integer.numberOfLeadingZeros(i - 1);
Есть ещё jd и fernflower — они лучше понимают байт-код новых версий java.
По поводу AggressiveOpts
if (AggressiveOpts)

таких вот условий по коду не мало. Поэтому для упрощения я не включал их в пост.
На мой взгляд, это неправильный подход. Честно говоря, я думал, что вы добросовестно заблуждаетесь. В вашем посте написано:
Не в том плане, что она резко увеличивает производительность Вашего приложения, а в том смысле, что она всего лишь изменяет значения других опций.
Выражение «всего лишь изменяет значения других опций» — это не упрощение, это либо заблуждение, либо ложь. Может, добавите какой-нибудь минимальный комментарий про альтернативную реализацию некоторых классов? Или хотя бы допишете, что не только в перечисленных опциях дело. А то ваш пост хорошо ищется в гугле, люди читают и верят вам :-)
Ну в целом, Вы правы. Добавил ремарку.
А есть где-нибудь сравнение быстродействия этих коллекций?
Вот, кстати, вы спросили бы начальство, зачем они это делают :-)
А зачем спрашивать. Мы знаем, но если молчать и надувать щеки — то можно тешить свое ЧСВ. :)))
UFO just landed and posted this here
Шутки-шутками, но всё же было бы интересно услышать предысторию к чему это делалось и зачем.

Я понимаю, что это некоторый эксперимент, ибо AggressiveOpts толсто намекают на это. Собственно какой аспект хотелось обкатать, или в каких случаях это должно работать лучше?
UFO just landed and posted this here
То что nvidia подкручивает драйвера для тестов все уже привыкли, а как Oracle крутит что-то, да еще при использовании специальных опций, так низя.
Про java.math.* скажу, что это было временное хранение. Новый убыстренный java.math.* уже давно в java8.
Скорей всего эта реализация была взята из JRockit-а, ибо Оракл давно собиралась перенести в JVM «лучшие черты JRockit».
А вот чисто теоретиццки, возникала ли когда-нибудь идея сделать native имплементацию части классов rt.jar? Всякие байткод компиляторы типа excelcior не в счет. Именно ручками на сях.
Sign up to leave a comment.

Articles