4 ms·

One thing that bothers me about Spring is how it manages to use so much off-heap. I used it initially for a small project (hobby-tier) and was shocked to find

One thing that bothers me about Spring is how it manages to use so much off-heap. I used it initially for a small project (hobby-tier) and was shocked to find it was using 200-300MB of offheap (or something in that range). To where my poor 1GB RAM digital ocean VPS was 20-30% just random Spring offheap crap. I ported my handlers from Spring to just using netty and their provided HTTP codecs (and I wrote my own http router implementation which was fun but also wish there was an easy one to just use, I didn't see anything I liked when I looked) and suddenly offheap was ~0 and I could've easily crammed 100 of these into this tiny VPS. (Not that I planned to, but I did want to use this VPS for other things too). I know "300MB offheap" is not something Spring will care about when they're probably normally running on giant ec2 instances, but for my case, while I would've liked to use the "django/rails but for java"-type tool, it did actually end up being too heavy in the most-constrained vector of cloud hosting (RAM).

imtringued 3y ago
I am sorry but RAM is the least constrained vector of cloud hosting. I have apps that need to do video encoding in real time with 100ms latency and those are always bottlenecked on CPUs. I have a micronaut app that uses around 350MB which is almost entirely JVM overhead.
nunobrito 3y ago
Of course that all depends on the context, for my cases I'll certainly keep my distance from either Spring or JBoss. Prefer to build faster apps with Java.
frant-hartm 3y ago
Not sure what you did wrong. You can easily fit whole spring web app including support for jpa and what not into 300 MB heap/native together.
throwaway45391 3y ago
I'm not an expert, but I think the memory used is not necessarily the memory it requires. I think Java tends to grow memory usage up to a point, rather than to try and release it at the cost of performance. That doesn't mean it would not be able to run on a machine with lower memory. It could run more expensive GC if it was needed
- mrkeen 3y ago
  I have been told this before too. Currently I can't run my integration tests on my work laptop because they spin up a bunch of "micro" services, so I run out of ram and need to reboot. The memory that Java "doesn't require" really adds up.
  - imtringued 3y ago
    It's especially bad when you have to run both IntelliJ with multiple projects and grails.
  - Pet_Ant 3y ago
    I believe that is why the original Java answer to microservices was EARs all within a single app server so they could share a JVM and caching. Then in production for load you could spread them all out and they can find eachother... but I've never worked in actively developed JEE (as opposed to a legacy one).
- seadan83 3y ago
  Java by default allocates a healthy percentage of available RAM. It releases memory if a large percentage is unused, and it only runs full GC when a large percentage is used. The trick is therefore to decrease the initial max memory. Otherwise you can wind up with 70% usage, a lot of objects that could be GC'd but are not because there is not enough memory pressure to run full GC, and there is not enough unused memory to be able to release RAM back to the OS
  - ye-olde-sysrq 3y ago
    See my reply to the other comment - I specifically refer to off-heap memory, not on-heap/GC-managed memory.
- ye-olde-sysrq 3y ago
  I'm here specifically referring to off-heap memory. I verified this by looking into the jvm with VisualVM. These are objects that aren't part of the normal java heap area and aren't part of garbage collection. The offheap can contain many things - classloaded code, memory-mapped files, direct bytebuffers, and so on. And since it's offheap, it's hard to analyze from Java tooling. So I literally don't know what it was doing. So in my above scenario, I could indeed run the app with a -Xmx32M and yet the application was still using 200-300MB of resident memory (RSS) due to offheap usage.

imtringued 3y ago

I am sorry but RAM is the least constrained vector of cloud hosting. I have apps that need to do video encoding in real time with 100ms latency and those are always bottlenecked on CPUs. I have a micronaut app that uses around 350MB which is almost entirely JVM overhead.

nunobrito 3y ago

Of course that all depends on the context, for my cases I'll certainly keep my distance from either Spring or JBoss. Prefer to build faster apps with Java.

frant-hartm 3y ago

Not sure what you did wrong. You can easily fit whole spring web app including support for jpa and what not into 300 MB heap/native together.

throwaway45391 3y ago

I'm not an expert, but I think the memory used is not necessarily the memory it requires. I think Java tends to grow memory usage up to a point, rather than to try and release it at the cost of performance. That doesn't mean it would not be able to run on a machine with lower memory. It could run more expensive GC if it was needed

mrkeen 3y ago
I have been told this before too. Currently I can't run my integration tests on my work laptop because they spin up a bunch of "micro" services, so I run out of ram and need to reboot. The memory that Java "doesn't require" really adds up.
- imtringued 3y ago
  It's especially bad when you have to run both IntelliJ with multiple projects and grails.
- Pet_Ant 3y ago
  I believe that is why the original Java answer to microservices was EARs all within a single app server so they could share a JVM and caching. Then in production for load you could spread them all out and they can find eachother... but I've never worked in actively developed JEE (as opposed to a legacy one).
seadan83 3y ago
Java by default allocates a healthy percentage of available RAM. It releases memory if a large percentage is unused, and it only runs full GC when a large percentage is used. The trick is therefore to decrease the initial max memory. Otherwise you can wind up with 70% usage, a lot of objects that could be GC'd but are not because there is not enough memory pressure to run full GC, and there is not enough unused memory to be able to release RAM back to the OS
- ye-olde-sysrq 3y ago
  See my reply to the other comment - I specifically refer to off-heap memory, not on-heap/GC-managed memory.
ye-olde-sysrq 3y ago
I'm here specifically referring to off-heap memory. I verified this by looking into the jvm with VisualVM. These are objects that aren't part of the normal java heap area and aren't part of garbage collection. The offheap can contain many things - classloaded code, memory-mapped files, direct bytebuffers, and so on. And since it's offheap, it's hard to analyze from Java tooling. So I literally don't know what it was doing. So in my above scenario, I could indeed run the app with a -Xmx32M and yet the application was still using 200-300MB of resident memory (RSS) due to offheap usage.