JVM off-heap memory address subject to change?

user_662615 0
Viewed 112

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.

jvm garbage-collection java
1 Answers

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.

user_10593720
Related