Такие вот у нас печеньки...
20 февраля 2012 г.
java.io.File is not immutable
Удивительно, но факт: несмотря на то, что контракт java.io.File явно указывает, что Instances of the File class are immutable; that is, once created, the abstract pathname represented by a File object will never change., однако поле File.path -- не final. Почему оно не-final тоже, в общем-то, понятно -- чертова сериализация, мать ее. Однако от нарушения контракта это не спасает. Я, поначалу, думал, что возможно safe publishing обеспечивается неявным мембаром при вызове какого-нибудь нативного метода в ходе инициализации -- но нет, авторитетные источники подтверждают -- баг как баг. И место его возле параши теперь здесь. Правда, приоритет Low, и поправлен будет не раньше 1.8 -- а до тех пор считать объект File immutable в том смысле, в котором это понимают в concurrency -- строго говоря, нельзя.
Такие вот у нас печеньки...
Такие вот у нас печеньки...
19 февраля 2012 г.
15 февраля 2012 г.
Arrays.sort() через Unsafe
Наблюдая за тем, как Даг Ли в последних версиях FJ активно использует Unsafe для доступа к массивам, мне пришел в голову вопрос: а что будет, если взять реализацию Arrays.sort(), и переписать ее через Unsafe[.arrayBaseOffset(), .arrayIndexScale(), .putXXX(), .getXXX()]? Казалось бы, таким образом можно избавиться от range checks. Да, JIT умеет их и сам убирать -- но лишь тогда, когда может доказать, что конкретный сценарий доступа к массиву эти самые границы гарантированно не нарушает. В сортировке доступ к массиву идет довольно причудливым паттерном, и кажется, что JIT-у вряд ли по силам доказать отсутствие необходимости проверки границ.
Я не поленился -- переписал Arrays.sort(long[]) на прямой доступ. UnsafeArraysSorter.java (у меня все еще 1.6, так что тимсорта не ждите). Прогнал тесты -- и вот фиг вам. Классическая реализация стабильно немного быстрее (+2-3% -- разброс результатов здесь маленький, так что даже такая мелочь вполне заметна).
Сижу теперь, и думаю -- да как же это? Либо JIT в целом умнее, чем я думал, либо он что-то особенное знает об Arrays.sort() :) Второй вариант мне кажется вероятнее.А власти-то -- скрывают!
Я не поленился -- переписал Arrays.sort(long[]) на прямой доступ. UnsafeArraysSorter.java (у меня все еще 1.6, так что тимсорта не ждите). Прогнал тесты -- и вот фиг вам. Классическая реализация стабильно немного быстрее (+2-3% -- разброс результатов здесь маленький, так что даже такая мелочь вполне заметна).
Сижу теперь, и думаю -- да как же это? Либо JIT в целом умнее, чем я думал, либо он что-то особенное знает об Arrays.sort() :) Второй вариант мне кажется вероятнее.
Подписаться на:
Сообщения (Atom)