BlazkowiczСкомпилируйте класс с final аргументами в методах и убедитесь что байткод не отличается.Ну так у вас и с volatile байт-код не будет отличаться. Это ни о чем не говорит. Важен не байткод, а то, как это на самом деле работает в рантайме.
И final запросто может быть быстрее из-за того, что JIT может более агрессивно оптимизировать доступ к нему. А в каких-то крайних сценариях наоборот может быть медленнее, из-за продолбанных реордерингов, которые могли бы ускорить работу конкретной процедуры.

DEVcoachBlazkowiczСкомпилируйте класс с final аргументами в методах и убедитесь что байткод не отличается.Ну так у вас и с volatile байт-код не будет отличаться. Это ни о чем не говорит. Важен не байткод, а то, как это на самом деле работает в рантайме.
И final запросто может быть быстрее из-за того, что JIT может более агрессивно оптимизировать доступ к нему. А в каких-то крайних сценариях наоборот может быть медленнее, из-за продолбанных реордерингов, которые могли бы ускорить работу конкретной процедуры.Тьфу блин, в аргументах ! Тогда мой пост не валиден.

chabapokСамое разумное - использовать для экономии тот факт, что оракловская jvm выравнивает каждый обьект по границе кешлайна, который составляет 64 байта на х86(_64) архитектуре.
Делается это для отпимизации многопоточной работы: на жаве один поток с одним обьектом и другой с другим будут работать быстро, тогда как на с++ подобное будет зависеть от того как эти обьекты аллоцировались - можно налететь на false sharing.


поэтому возможны порой странный вещи. Миллион обьектов
class Foo{
int t;
}

и миллион обьектов
class Foo{
int t;
int g;
long p;
}

Должны по идее занимать одинаково, потому что оба обьекта влазят в 64байта.

По этой причине, много мелких долгоживущих обьектов - это не очень хорошо, и если можно без них обойтись, то такой путь следует предпочесть...Вы что-то оооочень сильно путаете.
1) Выравнивание по кэшлайну невозможно в принципе . Потому что не существует инструкции процессора, которая позволила бы ему записать конркетное значение конкретно в начало кэш-линии.
2) Выравнивание по кэшлайну не нужно . Потому что мы никогда не читаем объект целиком. Мы можем прочитать его адрес, его поле, и т.д.. Но мы никогда не вычитываем весь объект полностью сразу же.

Вы все это спутали с выравниванием по 64-битной сетке в памяти. Это да, такое есть. Смысл заключается в том, что бы можно было прочитать конкретное поле объекта за минимальное количество чтений из памяти. Адреса в памяти у нас идут так: 0, 8, 16 ... И если вы запишете Long по адресу 8, то сможете его считать за один раз. А если вы его запишете по адресу 12, то вам сначала придется прочитать адрес 8, взять 4 младших байта, потом прочитать адрес 16, взять 4 старших байта, и потом их объединить. Добавьте к этому проблему с конкурентным доступом (один заканчивает запись по адресу 16, а другой начинает вычитывать два адреса => будет прочитана какая-то хрень).

По этой же причине ваш пример с размерами классов неверен. Первый класс займет 16 байт (12 хеадер + 4 int). А второй займет 12 + 4 + 4 + 8 = 28 + 4 (выравнивание) = 32 байта. Ни о какой привязке к кэшлайнам речи не идет. Это легко можно проверить следующим кодом:

chabapokПо этой причине, много мелких долгоживущих обьектов - это не очень хорошо, и если можно без них обойтись, то такой путь следует предпочесть...Иметь много мелких долгоживущих объектов плохо, но по совершенно другой причине - высокая фрагментация хипа в tenured generation, которая может приводить к тормозам GC на мажорных сборках.