JVM off-heap assunto endereço de memória para mudar?

Jovan Perovic:

Temos uma plataforma que depende fortemente de memória off-heap na JVM. Percebemos que, de tempos em tempos, temos SIGSEGV durante o ciclo de GC:

V  [libjvm.so+0x5c56cf]  G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*)+0x4bf

Entendo perfeitamente que aqueles são muito difíceis de rastrear, mas nós começamos a estreitar o caso raiz.

A questão:

Se eu fizer:

base = unsafe.allocateMemory(capacity);

e, obviamente, manter o basepara deallocation mais tarde, pode (de forma alguma) GC envolver-se e optar por mudar a minha memória nativa?

Eu sei que GC não deve ter nenhum impacto sobre este tipo de memória, mas eu estou procurando tipo de resposta oficial para isso.

Eugene:

Que irá retornar algum ponteiro endereço virtual e AFAIK unsafe.allocateMemorysó vai chamar mallocinternamente. Sendo um off-heap memória, obviamente GC não vai tocá-lo e que seria tremendamente ruim e inesperado se você mais tarde faria Unsafe.freeMemorycom esse ponteiro, para encontrar apenas por que ele mudou.