Что такое "внутренний адрес" на Java?

Ответ 1

Это явно специфично для реализации.

Ниже я включаю реализацию Object.hashCode(), используемую в OpenJDK 7.

Функция поддерживает шесть разных методов расчета, только два из которых принимают любое уведомление об адресе объекта ( "адрес", являющийся С++ oop, отличным от intptr_t). Один из двух методов использует адрес as-is, тогда как другой выполняет некоторую битовую сглаживание, а затем выдает результат с редко обновляемым случайным числом.

Из оставшихся методов возвращается константа (предположительно для тестирования), одна возвращает порядковые номера, а остальные основываются на псевдослучайных последовательностях.

Похоже, что метод можно выбрать во время выполнения, а по умолчанию - метод 0, который равен os::random(). Последний является линейным конгруэнтным генератором, с предполагаемым состоянием гонки, брошенным.:-) Состояние гонки приемлемо, потому что в худшем случае это приведет к тому, что два объекта будут одинаковыми хэш-код; это не нарушает никаких инвариантов.

Вычисление выполняется в первый раз, когда требуется хэш-код. Чтобы сохранить согласованность, результат затем сохраняется в заголовке объекта и возвращается при последующих вызовах hashCode(). Кэширование выполняется вне этой функции.

Таким образом, понятие о том, что Object.hashCode() основано на адресе объекта, в значительной степени является историческим артефактом, устаревшим по свойствам современных сборщиков мусора.

// hotspot/src/share/vm/runtime/synchronizer.hpp

// hashCode() generation :
//
// Possibilities:
// * MD5Digest of {obj,stwRandom}
// * CRC32 of {obj,stwRandom} or any linear-feedback shift register function.
// * A DES- or AES-style SBox[] mechanism
// * One of the Phi-based schemes, such as:
//   2654435761 = 2^32 * Phi (golden ratio)
//   HashCodeValue = ((uintptr_t(obj) >> 3) * 2654435761) ^ GVars.stwRandom ;
// * A variation of Marsaglia shift-xor RNG scheme.
// * (obj ^ stwRandom) is appealing, but can result
//   in undesirable regularity in the hashCode values of adjacent objects
//   (objects allocated back-to-back, in particular).  This could potentially
//   result in hashtable collisions and reduced hashtable efficiency.
//   There are simple ways to "diffuse" the middle address bits over the
//   generated hashCode values:
//

static inline intptr_t get_next_hash(Thread * Self, oop obj) {
  intptr_t value = 0 ;
  if (hashCode == 0) {
     // This form uses an unguarded global Park-Miller RNG,
     // so it possible for two threads to race and generate the same RNG.
     // On MP system we'll have lots of RW access to a global, so the
     // mechanism induces lots of coherency traffic.
     value = os::random() ;
  } else
  if (hashCode == 1) {
     // This variation has the property of being stable (idempotent)
     // between STW operations.  This can be useful in some of the 1-0
     // synchronization schemes.
     intptr_t addrBits = intptr_t(obj) >> 3 ;
     value = addrBits ^ (addrBits >> 5) ^ GVars.stwRandom ;
  } else
  if (hashCode == 2) {
     value = 1 ;            // for sensitivity testing
  } else
  if (hashCode == 3) {
     value = ++GVars.hcSequence ;
  } else
  if (hashCode == 4) {
     value = intptr_t(obj) ;
  } else {
     // Marsaglia xor-shift scheme with thread-specific state
     // This is probably the best overall implementation -- we'll
     // likely make this the default in future releases.
     unsigned t = Self->_hashStateX ;
     t ^= (t << 11) ;
     Self->_hashStateX = Self->_hashStateY ;
     Self->_hashStateY = Self->_hashStateZ ;
     Self->_hashStateZ = Self->_hashStateW ;
     unsigned v = Self->_hashStateW ;
     v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)) ;
     Self->_hashStateW = v ;
     value = v ;
  }

  value &= markOopDesc::hash_mask;
  if (value == 0) value = 0xBAD ;
  assert (value != markOopDesc::no_hash, "invariant") ;
  TEVENT (hashCode: GENERATE) ;
  return value;
}

Ответ 2

Обычно - адрес памяти объекта. Однако в первый раз, когда метод hashcode вызывается для объекта, целое число хранится в заголовке этого объекта, так что следующий вызов будет возвращать одно и то же значение (как вы говорите, уплотнение коллекции мусора может изменить адрес). Насколько я знаю, так оно реализовано в JVM Oracle.

РЕДАКТИРОВАТЬ: выкапывая исходный код JVM, это то, что отображается (synchronizer.cpp):

// hashCode() generation :
//
// Possibilities:
// * MD5Digest of {obj,stwRandom}
// * CRC32 of {obj,stwRandom} or any linear-feedback shift register function.
// * A DES- or AES-style SBox[] mechanism
// * One of the Phi-based schemes, such as:
//   2654435761 = 2^32 * Phi (golden ratio)
//   HashCodeValue = ((uintptr_t(obj) >> 3) * 2654435761) ^ GVars.stwRandom ;
// * A variation of Marsaglia shift-xor RNG scheme.
// * (obj ^ stwRandom) is appealing, but can result
//   in undesirable regularity in the hashCode values of adjacent objects
//   (objects allocated back-to-back, in particular).  This could potentially
//   result in hashtable collisions and reduced hashtable efficiency.
//   There are simple ways to "diffuse" the middle address bits over the
//   generated hashCode values:
//

static inline intptr_t get_next_hash(Thread * Self, oop obj) {
  intptr_t value = 0 ;
  if (hashCode == 0) {
     // This form uses an unguarded global Park-Miller RNG,
     // so it possible for two threads to race and generate the same RNG.
     // On MP system we'll have lots of RW access to a global, so the
     // mechanism induces lots of coherency traffic.
     value = os::random() ;
  } else
  if (hashCode == 1) {
     // This variation has the property of being stable (idempotent)
     // between STW operations.  This can be useful in some of the 1-0
     // synchronization schemes.
     intptr_t addrBits = intptr_t(obj) >> 3 ;
     value = addrBits ^ (addrBits >> 5) ^ GVars.stwRandom ;
  } else
  if (hashCode == 2) {
     value = 1 ;            // for sensitivity testing
  } else
  if (hashCode == 3) {
     value = ++GVars.hcSequence ;
  } else
  if (hashCode == 4) {
     value = intptr_t(obj) ;
  } else {
     // Marsaglia xor-shift scheme with thread-specific state
     // This is probably the best overall implementation -- we'll
     // likely make this the default in future releases.
     unsigned t = Self->_hashStateX ;
     t ^= (t << 11) ;
     Self->_hashStateX = Self->_hashStateY ;
     Self->_hashStateY = Self->_hashStateZ ;
     Self->_hashStateZ = Self->_hashStateW ;
     unsigned v = Self->_hashStateW ;
     v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)) ;
     Self->_hashStateW = v ;
     value = v ;
  }

  value &= markOopDesc::hash_mask;
  if (value == 0) value = 0xBAD ;
  assert (value != markOopDesc::no_hash, "invariant") ;
  TEVENT (hashCode: GENERATE) ;
  return value;
}

Так что 6 разных способов сделать это в JVM Oracle, один из них эквивалентен тому, что я сказал... Значение хранится в заголовке объекта методом, вызывающим get_next_hash (тот, который вызывается FastHashCode и вызывается из собственной версии Object.hashCode().

Ответ 3

IMHO, хотя и зависит от реализации, ссылки на объекты в JVM никогда не являются фактическими адресами памяти, но внутренние ссылки JVM, которые указывают на фактические адреса. Эти внутренние ссылки ARE генерируются первоначально на основе адреса памяти, но они остаются связанными с объектом до тех пор, пока он не будет отброшен.

Я говорю это, потому что Java HotSpot GCs копируют сборщики какой-либо формы или другой, и они работают путем перемещения live objects и копирования их из одной кучи в другую, впоследствии уничтожая old heap. Поэтому, когда GC происходит, JVM не нуждается в обновлении ссылок во всех объектах, а просто измените фактический адрес памяти, сопоставленный с внутренней ссылкой.

Ответ 4

Предложение Javadoc для Object.hashCode(), которое реализовано путем вывода хэш-кода из адреса памяти, просто устарело.

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

Было очень важно реализовать hashcode таким образом, прежде чем появился копировальный сборщик мусора, поскольку он спасет кучу пространства. Не копирующий GC (CMS) все еще может реализовать хэш-код сегодня.