Under what conditions is Off-Heap memory worth it?
What I've read about the off-heap memory interfaces like ByteBuffer and the FFMI make it sound like it's much harder to access than heap memory and incurs a significant performance penalty. But they also neglect to mention the cases where the penalty is mitigated or the trade-off is worth it.
So I wanted to ask: under what circumstances is moving something off the heap beneficial?
- Does it specifically have to be something that's rarely accessed, or can it be relatively often? - Does the type of data matter, or can you store most objects there without issue? Which types are better? - What is the performance penalty from storing objects off the heap? Is it just "if it will never be GC'd, you can put it off heap", or is it only useful in certain situations? Basically, what types of memory are good candidates for being moved off the heap?
- Does it specifically have to be something that's rarely accessed, or can it be relatively often? - Does the type of data matter, or can you store most objects there without issue? Which types are better? - What is the performance penalty from storing objects off the heap? Is it just "if it will never be GC'd, you can put it off heap", or is it only useful in certain situations? Basically, what types of memory are good candidates for being moved off the heap?
27 Replies
⌛ This post has been reserved for your question.
Hey @Haiku! Please useTIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here./closeor theClose Postbutton above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically closed after 300 minutes of inactivity.
Do correct me if I'm wrong but I don't think there is a way to allocate something that isn't on the heap (excluding primitives) in java
There are probably ways to do that through the JNI, but in pure java I don't think it's possible.
and generally speaking accessing objects from the heap and accessing objects from other memory (which would usually be the stack) isn't really all that different from a performance standpoint
The NIO package has a number of ways to move something off the heap, such as ByteBuffers and memory mapped files.
well I would assume that the ByteBuffer is also allocated on the heap
perhaps it just makes it more convenient for interfacing with aforementioned JNI
here is from the official documentation of ByteBuffer:
The object that handles memory interfacing is on the heap yes, but it maps to off heap memory.
If you don't know that's fine but I really want the input of someone who's used it before
Use ZGC or shenandoah
Slightly lower perf, but pauses dissapear
💤 Post marked as dormant
This post has been inactive for over 300 minutes, thus, it has been archived.
If your question was not answered yet, feel free to re-open this post or create a new one.
In case your post is not getting any attention, you can try to use /help ping.
Warning: abusing this will result in moderative actions taken against you.off-heap memory is often worth it when dealing with native memory or mapping files
I am wondering if there are any actual advantages to this performance wise since any memory access excluding the actual system calls that are required to allocate stuff is just about the same speed. Memory mapping to files would be plenty slower considering how much slower disks are. Of course the operating system does do virtual memory mapping, but it knows when to.
I meant memory-mapping files
there can be performance improvements with large chunks of memory
ah. Well yeah, perhaps, but I doubt it's worth the hassle.
in most cases, no
but there are some things where it makes a difference
can you give an example? I am actually pretty curious
Netty
Netty uses off-heap memory for some stuff
cool, maybe I'll look into it when I have some free time
or it can be useful for networking stuff in general
or things where the stuff is accessed by native code
where would the memory be allocated in that case though? I am using the JNI at the moment and in most cases things are still just on the heap
it just asks the OS for new chunks of memory so it's in the process heap but not the java heap
well yeah but it's still in the heap
off-heap means outside the Java heap
ah
I though we were talking about off-heap like off-off heap
well yeah if you allocate an object natively and interface with jni that object isn't actually managed by gc and it's not on the java heap
well where could you store that? On disk?
In the heap of another application?
that's exactly what I was asking
In Java, heap means the Java heap whose size can be configured with
-Xmxyeah. I misunderstood , that's my bad
so with off-heap memory, you are not limited to the size configured with
-Xmx💤 Post marked as dormant
This post has been inactive for over 300 minutes, thus, it has been archived.
If your question was not answered yet, feel free to re-open this post or create a new one.
In case your post is not getting any attention, you can try to use /help ping.
Warning: abusing this will result in moderative actions taken against you.