CODEWITHSUNDEEP
javagarbage-collectionjvm
Jovan Perovic
Jovan Perovic

Reputation: 20193

JVM off-heap memory address subject to change?

We have a platform which heavily relies on off-heap memory in JVM. We noticed that, from time to time, we get SIGSEGV during the GC cycle:

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

I completely understand that those are quite hard to track down, but we have started narrowing down the root case.

The question:

If I do:

base = unsafe.allocateMemory(capacity);

and, obviously, retain the base for later deallocation, can (in any way) GC get involved and choose to move my native memory?

I know that GC should have no impact on this kind of memory, but I am looking for kind of authoritative answer to this.

Upvotes: 4

Views: 167

Answers (1)

Eugene
Eugene

Reputation: 120848

That will return some virtual address pointer and AFAIK unsafe.allocateMemory will just call malloc internally. Being an off-heap memory, obviously GC will not touch it and that would be tremendously bad and unexpected if you later would do Unsafe.freeMemory with that pointer, to only find out that it moved.

Upvotes: 3

Related Questions