Comments 23
Так вот почему они скрывают их реализацию! Им СТЫДНО :)
+29
Можно попробовать заюзать декомпилятор, чтобы проще было листинги анализировать.
jad геренегил вполне удобоваримые листинги.
jad геренегил вполне удобоваримые листинги.
0
Спасибо! С интересом глянул.
Кстати, в jre есть оптимизация для Integer'ов — для объектов, хранящих значения из интервала -127..127 используется объектный пул.
Кстати, в jre есть оптимизация для Integer'ов — для объектов, хранящих значения из интервала -127..127 используется объектный пул.
0
это есть ещё со времён java 5 — и более того, в sun/oracle jre можно расширять верхнюю границу при помощи ключа
-Djava.lang.Integer.IntegerCache.high=max
и ещё говориться о
-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>.
*/
+1
Ага, спасибо. Я использовал когда-то jad, но лень было его устанавливать. Пару десятков строчек проще и надёжнее декомпилировать по ассемблеру в уме :-) Похоже, jad генерики совсем не любит и скобки ставит скупо, лишь по мере необходимости. Такое я воспринимаю хуже, чем ассемблер, мне всё время кажется, что у сдвига приоритет выше:
return -1 << 32 - Integer.numberOfLeadingZeros(i - 1);
0
По поводу AggressiveOpts
таких вот условий по коду не мало. Поэтому для упрощения я не включал их в пост.
if (AggressiveOpts)
таких вот условий по коду не мало. Поэтому для упрощения я не включал их в пост.
0
На мой взгляд, это неправильный подход. Честно говоря, я думал, что вы добросовестно заблуждаетесь. В вашем посте написано:
Не в том плане, что она резко увеличивает производительность Вашего приложения, а в том смысле, что она всего лишь изменяет значения других опций.Выражение «всего лишь изменяет значения других опций» — это не упрощение, это либо заблуждение, либо ложь. Может, добавите какой-нибудь минимальный комментарий про альтернативную реализацию некоторых классов? Или хотя бы допишете, что не только в перечисленных опциях дело. А то ваш пост хорошо ищется в гугле, люди читают и верят вам :-)
+1
А есть где-нибудь сравнение быстродействия этих коллекций?
0
+3
UFO just landed and posted this here
Этот фильм до сих пор популярный…
0
Шутки-шутками, но всё же было бы интересно услышать предысторию к чему это делалось и зачем.
Я понимаю, что это некоторый эксперимент, ибо AggressiveOpts толсто намекают на это. Собственно какой аспект хотелось обкатать, или в каких случаях это должно работать лучше?
Я понимаю, что это некоторый эксперимент, ибо AggressiveOpts толсто намекают на это. Собственно какой аспект хотелось обкатать, или в каких случаях это должно работать лучше?
0
Про java.math.* скажу, что это было временное хранение. Новый убыстренный java.math.* уже давно в java8.
+2
Скорей всего эта реализация была взята из JRockit-а, ибо Оракл давно собиралась перенести в JVM «лучшие черты JRockit».
А вот чисто теоретиццки, возникала ли когда-нибудь идея сделать native имплементацию части классов rt.jar? Всякие байткод компиляторы типа excelcior не в счет. Именно ручками на сях.
А вот чисто теоретиццки, возникала ли когда-нибудь идея сделать native имплементацию части классов rt.jar? Всякие байткод компиляторы типа excelcior не в счет. Именно ручками на сях.
-1
Sign up to leave a comment.
Таинственный FrontCache