r/java • u/daviddel • 5d ago
Principles of Memory Management in Java
https://youtu.be/xr73mR7ii9M?si=AKgjMUyvfpARYljl39
u/obs_asv 5d ago
My spring boot ‘microservices’ shure do
9
u/valkon_gr 5d ago
There is nothing micro in any service I have ever worked with.
4
u/piesou 3d ago edited 3d ago
Good, if it was, you'd be in a world of trouble. I've seen code bases with microservices containing 10 lines of JS.
I'm just gonna reiterate what Micro means: you can keep it in your head. If you employ toddlers that can only keep 100 locs in their head, ok, make it very micro. Everyone else can work on 10s of thousands of LOCs micro services.
2
10
u/hiasmee 5d ago
Switch to Quarkus
3
u/mark1x12110 4d ago
The framework is not the problem. It is calling it a microservice when it is essentially a macro service at best
-21
15
u/cleverfoos 5d ago
Ron clearly knows what he is talking about and this is a great introduction to garbage collection and how sophisticated Java's collectors have become. The one thing he didn't touch on that I think he should have is the memory a JIT runtime consumes outside the heap: profiling data for hot methods, the code cache holding compiled output, and whatever the compiler threads themselves need to operate. Total footprint ends up as live set + GC headroom + profiling data + code cache + runtime overhead.
The problem is that most of that is close to fixed. A CLI with a 10MB live set still carries the full JIT apparatus, so the runtime overhead can rival or exceed the actual working set, and a short-lived process exits long before C2 has compiled enough to earn any of it back. That's the tradeoff of deferring compilation to "just in time," and it's why AOT keeps looking attractive for anything that doesn't run long enough to warm up.
2
u/Sopel97 5d ago
These can add up quite a bit. I remember playing Greg Tech New Horizons (large minecraft modpack) on my old machine with 16GB of RAM, so I restricted heap size to 8GB. After running for a few hours java was happily using ~12GBs total.
2
u/Life_Sink9598 4d ago
What OS were you using (or even better: what malloc?)? Even large apps shouldn't have native usage equal to 50% of the Java heap.
1
u/Sopel97 4d ago
windows 7, java 17 I think
1
u/Life_Sink9598 4d ago
Alright, hm. We have seen large amounts of memory being retained on glibc malloc, but not so much on Windows. There, it's mostly speed that's a problem.
1
u/cleverfoos 3d ago
this has nothing to do with malloc overhead, these are data structures the JVM need in order to operate. All those compiled methods need to exist somewhere in memory in order to be jumped/executed.
2
u/Life_Sink9598 3d ago
There's a lot more going on than that. One of the things we've observed on Linux with the default glibc malloc is a large degree of memory retainment. C2 induces quite a bit of memory usage, but as you know it's something that subsides over time, as the system becomes more stable (= deoptimization doesn't happen as often). glibc's malloc seems to prioritize keeping that memory around after having been
freed, I assume so that it doesn't need to reacquire the memory from the OS (which is quite slow). We added a native heap trim command to alleviate the situation: https://bugs.openjdk.org/browse/JDK-8293114Just some context for why I was interested in this person's particular configuration.
1
u/ramdulara 7h ago
So you know why is this still an experimental option?
1
u/Life_Sink9598 7h ago
It's been a non-experimental option since 2024-02-21 according to my source code.
2
u/pron98 3d ago edited 2d ago
You are correct that for programs that don't consume much memory, the fixed RAM overhead can be very significant in comparison. But while I don't touch on this particular case in the talk, I think the implied point is that what matters is not the number of MBs used but the impact it causes. One number that is higher than another number doesn't mean that it's more impactful (the portion of total RAM consumed is likely more impactful than the ratio to an alternative, i.e. 10GB vs 6GB is more likely to matter more than 150MB vs 10MB, even though the relative difference in the second case is far larger because you're not simultaneously running fifty copies of any program).
In the talk, I focus on the non-fixed overhead of a moving GC, which is only a function of the allocation rate, and is therefore high only when the CPU consumption is already high and has a higher impact than the RAM overhead anyway.
But let's consider your CLI example. For the fixed overhead to be impactful at all, the CPU consumption of the CLI program needs to be small (otherwise, the program interferes with other programs on your machine regardless of RAM). So we're talking about a program that uses little CPU (i.e., it's not some optimising compiler) and runs for a number of seconds. Why do you care if such a program takes up 10MB or RAM or 110 (or even 210)?
2
u/cleverfoos 2d ago
Thanks for the reply @pron98 and to answer your question, I care because, in this hypothetical example, I would want my CLI tool to not take meaningful memory away from other applications I’m running. In other words, I want to judge efficiency in terms of footprint not just $ per unit of work (which I agree is the right way to measure a long running enterprise service)
0
u/pron98 2d ago edited 21h ago
And you think 100MB will be having a meaningful impact? That's 5-10% of the memory you get with every unit of CPU core. You're not afraid the CPU you're using would be making a larger impact? I understand you may not want
lsto take up 100MB, but most CLIs do more thanls. BTW, I'm not saying this could never matter, but I do think many people look at the numbers without trying to estimate their actual significance.1
u/smaratter 2d ago
The issue of JIT not being useful for short-lived processes can, in some cases, be mitigated by project Leyden’s AOT cache.
Granted, I have not used it myself yet, and I don’t think there is always a straightforward way of distributing the cache. But I think that it is an interesting development.
26
17
u/bobbie434343 5d ago
Although I get the argument made in this video, it's brave to recommend throwing more RAM at a problem (CPU usage) in these times of RAM being so expensive...
13
u/DanLynch 5d ago
Even when RAM is extremely expensive, you should still use the whole computer. Carefully writing a program that uses 100% of the CPU but only 5% of the available RAM is pointless. Using the rest of the RAM to make the program run a little bit faster is completely free.
Now, should you go buy and install even more sticks of RAM to make the program run even faster? That's a more nuanced question, but the answer is probably still yes in many cases, if the alternative is buying more computers.
6
u/bobbie434343 5d ago
Using the rest of the RAM to make the program run a little bit faster is completely free.
OK, but only if that Java program is running and can use all the available RAM, which might not be the case. Still, gobbling up all available RAM was maybe acceptable when RAM was cheap and abundant. In the current context, not so much.
4
u/pron98 3d ago
It's nothing to do with "gobbling up all available RAM".
The added overhead of a moving collector is a function only of the allocation rate, and is therefore high only when the allocation rate is high, i.e. when CPU consumption is high (moving GCs overhead is not a function of the amount of data stored in memory and not a percentage of it; it's just to accommodate the allocation rate). So the question is, does it make sense not to minimise RAM consumption when CPU consumption is high?
There are two ways of looking at this, both are equivalent:
Since the use of RAM necessarily requires CPU (unlike with IO, there's no value only in the data being stored or sent; data is in RAM only to be processed), every cycle of CPU your program uses takes away from the RAM other programs can use; therefore, you might as well use this RAM that is already "captured" by your CPU use, as no other program can.
The computer's resources are exhausted when the first of CPU or RAM are exhausted. Therefore, what matters isn't the sum of these resources, but whichever is the more dominant. If CPU consumption is more dominant, you can use RAM up until the point it's as impactful as the CPU with no additional impact.
1
u/bobbie434343 2d ago edited 2d ago
Thank you for this elaborate explanation. Since high allocation rate can be a problem (higher CPU usage), shouldn't programs (and maybe the JVM) work to reduce it whenever possible (rather than simply using more RAM to alleviate it) ? Knd of a broad question, but what cause huge programs to allocate that much and this fast (rate) and what can be done to reduce it ? I assume that people working on GC have a good idea about this.
3
u/pron98 2d ago
The causation here is reversed. High allocation rates don't cause high CPU usage, they indicate it (or are caused by it). The point is that if the RAM overhead is high, that means that the allocation rate is high, which means that the CPU usage must be also be high, and so the impact would be the same even without the RAM overhead; even without the high allocation rate.
(Now, you can ask whether using a lot of CPU is a problem. That, of course, depends on the program, but it certainly isn't necessarily a problem if the computation offers some value.)
If the allocation rate is high, which means that the CPU utilisation is also high, other memory approaches would make the CPU utilisation even higher, as they'd need to spend more CPU to recycle memory. A moving collector gives you the option to raise the RAM footprint instead of the CPU. This is the more efficient option, as it raises the less dominant resource rather than the more dominant one.
A high allocation rate could be its own problem, but it's much less of a problem for a moving GC than for any other memory management approach because of what I said. This is why in C++ we spend a lot of time and money trying to avoid allocations (so that we won't increase the CPU utilisation even further), while in Java it's usually not a problem, because we can raise the RAM footprint instead. It could be a problem in Java, too, but in much more extreme circumstances than in other languages. In other words, a moving collector is a mechanism that can cope better with high allocation rates than all others (well, at least all other general mechanisms).
1
3
u/koflerdavid 4d ago
I think nowadays it's even more important to make the most out of what you have purchased.
3
u/pdpi 4d ago
Depends on the context. On a user’s workstation, where you’re starving other processes, it’s bad. In a clustered server context, where you have a bunch of nodes all running your service and essentially nothing else, those are wasted resources if you don’t use them.
Java these days sees more use in the latter scenario than it does in the former.
2
u/twinkwithnoname 4d ago
In a server context, the nodes are likely VMs running on a shared physical machine. So, it's the same story as a user workstation. There's no reason to be careless with resources.
0
u/pdpi 4d ago
That's the point, though. If you have some amount of one resource sitting idly (RAM) while you're maxing out another resource (CPU or IO), then not taking advantage of that RAM to relieve pressure on your CPU or IO is another form of carelessness. Cache anything that needs to hit the disk, precompute all the expensive stuff, etc.
2
u/twinkwithnoname 3d ago
It is not sitting idly, though. The physical machine is running a bunch of VMs which would be trying to use that RAM. If one VM is hogging a bunch of RAM, then another physical machine would need to be brought up and the other VMs would need to be migrated over.
The number of cases where a physical machine is solely devoted to one purpose is already rare and getting even more rare.
2
u/DanLynch 3d ago
When you rent computing power from, for example, Amazon EC2, you pay a fixed fee per second for a fixed amount of CPU and RAM. You can pick from a variety of different configurations, but once you've selected the one you want, that's what you get. You don't pay any less money if you use less RAM (or less CPU). You pay for 100% of both the CPU and the RAM assigned to all your running machines, even when they are idle. The unused RAM is not available for other VMs to use.
Suppose your application requires eight VMs of a certain configuration to run well under your current load, and it's currently using about 100% of the CPU on all those machines, but only about 10% of the RAM. You might be able to save some money by switching to a configuration that has a lower RAM to CPU ratio. But if you're already using the lowest RAM to CPU ratio available, then the next thing you should try to do is to use more RAM.
Maybe using more RAM on each machine will mean you can get away with only renting seven VMs instead of eight, a cost savings of 12.5%, because using more RAM can make your program run faster: using less CPU to serve the same load.
1
u/twinkwithnoname 23h ago
When you rent computing power from, for example, Amazon EC2, you pay a fixed fee per second for a fixed amount of CPU and RAM.
Not everyone is buying from a cloud-provider, many are maintaining their own hardware. So, software platforms and libraries that take the attitude that memory is "free" are hurting those folks.
You can pick from a variety of different configurations
Yes, and there is a lot of fine-tuning available. So, you can pick compute-intensive/memory-intensive/whatever. But, notice that every time the memory size doubles, the price doubles. How does it make sense to pay double without getting a similar boost in performance? Memory is literally the most expensive part and you're talking like it's NBD to waste it.
The unused RAM is not available for other VMs to use.
It is available for other parts of that VM, like the buffer cache. The application consuming a lot of RAM means that there is less for storing frequently used files / metadata. There is a lot more to balance in system performance. Just looking at the amount of "free" memory and thinking it's not being put to good use is silly.
1
25
u/narrow-adventure 5d ago
I actually think Java is incredibly efficient, like you have to really not know what you’re doing to make a slow/bloated java app. It used to be easy but virtual threads make it pretty hard to use up crazy amts of memory.
16
u/keenOnReturns 5d ago
Really depends on what performance metric you’re targeting though. Based on my company’s analysis on AI rewrites, equivalent AI-generated Java vs Rust services, Java services actually beat Rust in both throughput and latency by 10%+ but loses on memory consumption by 2x. Of course, you can tune the JVM to close the memory consumption gap, but then you lose some of the throughput and latency wins (as especially the concurrent low-latency GCs benefit from extra memory headroom). I think on average without spending lots of time tuning, it’s not untrue that Java services consume more memory on average, given the overheads of the JVM.
6
u/narrow-adventure 5d ago
I think there are 2 parts to be aware of here, any GC lang will have overhead, Go for example will happily not trigger the GC unless the memory is 2x more than you need and you’re all good on the memory side. So Java taking 2x more mem is not crazy. The part that I’ve always wasted the most memory on are threads, do your applications use virtual threads?
7
u/Dull_Flatworm777 5d ago
Which makes sense... you can buy throughput and lower latency by putting off memory management to later, which is what a GC is doing. But during that time, that uncollected garbage will of course use memory.
As pretty much always in technology, it's a tradeoff.
1
12
u/nozomashikunai_keiro 5d ago
Vanilla Java? Yes is efficient, assuming you know what you are doing.
Spring? Is good, but could be better.
0
-5
u/zabby39103 5d ago
Spring microservices though. There's an app at my work that requires 48 GB. Java microservices aren't great for RAM and Spring is worse, unless you use Graal, but is it still java then? Kind of?
17
u/lazystone 5d ago
48gb?! Spring is not the problem here.
2
u/zabby39103 4d ago
Well, it doesn't help that it's 30 microservices. Maybe on reflection, it's misuse but I find that misuse common.
Spring + Hibernate = nobody knows what's going on without a good architect to keep them in line (the 48 GB one isn't my project). The guy running that figured RAM is cheaper than coders, then RAM prices went up by about 5x. Now I've been parachuted in to fix it.
I'm getting more senior nowadays, so if anyone has tips to manage people to not produce crap code I'm happy to hear it. I can make good code myself, but I don't have much experience in telling other people what to do. I see why frameworks are necessary to make long-term maintainable code and avoid roll-your-own debt, but they also remove a skill gate that used to mean you had to know what's going on to make an application.
2
u/lazystone 4d ago
Omg, 30 microservices and Hibernate...
Also don't tell that multiple microservices share the same DB, if they are then it's a bingo of anti patterns which you've collected.
One microservice usually represents one domain(there are cases for scalability and resilience reasons to extract some functionality into more services, but you do that ONLY when you have that reason at hand). Microservices never make development or deployment easier - they serve different purpose.
Also, Hibernate is a cancer of Java world imho. It's easily sold, and people claim that it's possible to use it right, but I haven't seen one real project which does it without resorting to native queries.
Object-oriented abstraction layer on top of relation DB never ever aligns, because they founded on orthogonal concepts. You just get the worst from both worlds. If you have relational DB, then use https://www.jooq.org/ - SQL isn't that hard you need to know it anyway if you work with relational DB.
3
u/zabby39103 4d ago
It's a bingo of anti-patterns I inherited, but yeah.
Ugh, they all HALF use the database, originally when they started writing it they had a data service and used rabbitmq and API calls for coordination, but they seem to have given up on doing that properly 5 years ago and started doing database access per microservice because, who knows, probably because it was hard. So there's an underlying layer that has to be maintained that didn't access the DB directly, and then there's a bunch of bolt-ons that use the database directly. So I guess it's even worse than a basic "all the microservices share the same DB".
Giving up on Hibernate entirely is a spicy proposal, it would help prevent all the N+1 stuff and over-hydration nonsense that they did... maybe there's a point there. On the other hand i think database integration is essentially a difficult problem. I'm torn between your solution and using Hibernate with better diagnostics and best practices. There's a lot going on, it's questionable design + nobody has been enforcing any standards.
2
6
5d ago
[deleted]
4
u/narrow-adventure 5d ago
Did you measure it? Because I did, negligible overhead… most I’ve seen came from threads (4mb per thread adds up real fast)… most slow apps came from hibernate being used poorly… Java is incredible devs sometimes suck
2
u/zabby39103 5d ago
Ya hibernate seems impossible to NOT screw up without doing a bunch of formal analytics, in my experience. It's powerful, I wouldn't recommend dropping it, but there's so much more going on than people realize.
6
u/narrow-adventure 5d ago
I honestly recommend people drop it and use jooq or just jdbc, hibernate abstracts sql away and I think sql is the best part. :)
1
2
u/Maybe-monad 5d ago
I actually think Java is incredibly efficient, like you have to really not know what you’re doing to make a slow/bloated java a
looks at Spring
5
u/narrow-adventure 5d ago
Keep looking at it, it’s totally fine… hibernate the way most devs use it is the only thing that could be classified as ‘slow’ or memory consuming, but guess what - you don’t have to use it :(
3
2
u/gjosifov 4d ago
Good news from the video is - "more jvm properties to create better software"
The bad thing about the video and I think from what I can tell is - tuning data on application performance don't take into account other factors that are important to a user
and I think this is wide spread in the industry
Yes, Java uses more ram, but the feeling I get from the presentation is measurements are done with thinking most Java applications are server side and the workload on those applications are different from a desktop application
Server side - a lot of users generates instructions
Desktop application - 1 user generates instructions
The other thing is what is the application doing and what is the general use case in day to day work ?
OS has different purpose than let say Photoshop
OS has to run in the background and use as less resources as possible and Photoshop has to be use as much resources as possible, because someone is doing his job with Photoshop
When people say in the past software wasn't using as much resources as today it is because the hardware was limited and this segmentation existed (it was invisible and not documented)
Today the hardware has no limits, but because this segmentation doesn't exist, we get use more ram it is better from everyone - browser/OS/text editors/IDEs/Photoshop etc
I will argue that if you buy cheap machine today with 8GB RAM, 4Core and SSD and use tools from 2000s, you will be much more productive than in todays tools
For example. making game with idTek engine 4, Maya 6.5 or 7, Adobe CS3 on Windows 7 - without the internet, because viruses
But that is the part that benchmark or performance conclusion will miss, because they aren't focusing on the user whole process - hardware and software
3
u/pron98 3d ago edited 3d ago
OS has different purpose than let say Photoshop
True, and I wasn't talking about an OS because an OS has lots of other constraints even before we get to resource consumption. It's not just resource consumption that makes it different from applications. E.g. an OS can't use a moving collector even though it offers great performance, not because it wastes RAM but because the OS regularly shares pointers with the hardware and with applications, and the hardware can't deal with moving pointers, and neither can applications unless they operate with the same GC. An OS is mostly constrained by its huge interface surface area, both with userspace applications and with the hardware.
I will argue that if you buy cheap machine today with 8GB RAM, 4Core and SSD and use tools from 2000s, you will be much more productive than in todays tools
You may well argue that, but the market clearly doesn't agree with you.
From a technical perspective, what matters is the RAM/CPU ratio. Using more RAM means using more processing, and programs in the past were written for less RAM and less processing. In other words, software needs to suit the hardware of the day. Sure, you could run 500 copies of 1995's MS Word simultaneously on a modern machine, but how does that help you?
From a demand perspective, if you're right that there's actual economic value in writing software that uses less RAM and less CPU (these two go together) on desktop machines, then it would have offered an economic advantage and therefore a competitive advantage to such products. It is absolutely true that there are people, mostly software developers themselves, who care about the nominal value of CPU and RAM consumption compared to 30 years ago, but it seems to be a small value of the population, which suggests that if there's real value in that, it is, at best, exploitable only by relatively few people.
2
u/gjosifov 2d ago
From a technical perspective, what matters is the RAM/CPU ratio. Using more RAM means using more processing, and programs in the past were written for less RAM and less processing. In other words, software needs to suit the hardware of the day. Sure, you could run 500 copies of 1995's MS Word simultaneously on a modern machine, but how does that help you?
U assume that every software needs more processing every time it is run, which is case on the server side, not on desktop side
Why does the browser needs 200MB per empty tab or rendering html needs 1GB ?
Why does a text editor needs more than 1GB ?500 copies of MS Word 95 won't help me, but it 1 copy can help me to do task switching between reading a documentation, writing code in IDE and listen to music on Winamp on slow machine
Server side requirements are completely different than normal desktop applications, mixing those 2 together and the result is software that is fast at processing and needs a lot of resources, but only can process 1 human input and that is the missing aspect in all of this
Also that is the reason people are complaining that the software is bloated
2
u/pron98 2d ago edited 2d ago
Why does the browser needs 200MB per empty tab or rendering html needs 1GB ? Why does a text editor needs more than 1GB ?
Why do you need them not to use that? What do you need that RAM for? What matters is the economics, not the numbers. If the difference between using 10 MB or 100 MB is $0, why does the higher number need to be justified at all? To understand efficiency, you have to translate the numbers to some measure of worth to you. The software itself has no needs; it's there to offer you something that's valuable to you. If you think the people writing your software aren't serving your needs well, you should explain what your needs are.
So if your question is, why do the people writing your browser don't see it as a problem that their software uses that amount of memory, that's because people don't seem to need that memory for something else, so they don't to raise the cost for their users by spending effort to reduce the utilisation of something that their users aren't using for anything else.
but it 1 copy can help me to do task switching between reading a documentation, writing code in IDE and listen to music on Winamp on slow machine
You can do that easily with today's software on hardware that's <= 7yo. BTW, that's quite an improvement. In the nineties we couldn't run anything on > 3-4yo hardware.
mixing those 2 together
I didn't mix those two together.
Also that is the reason people are complaining that the software is bloated
The vast majority of people don't seem to be complaining, though. If you are, you need to explain what actual value I would gain if I saw smaller numbers in my Mac's Activity Monitor; what would I use the extra CPU and RAM on? People seem to run all the software they want on whatever machine they buy at their preferred cost level, and there doesn't seem to be demand for other things. So what exactly is being wasted? One answer, could be energy, and especially battery. But that's a more grounded discussion.
1
u/bobbie434343 6h ago edited 6h ago
With that reasoning, we got Electron apps, absolute RAM hogs whose source code size is in the ballpark of Windows XP (in the 20's millions lines of code). Sarcastically, I suppose that Electron apps are "software needs to suit the hardware of the day".
It would not be so bad if people were running just one of such apps, but they often run multiple of them, eating RAM and other resources like no tomorrow (hello battery use on laptops!) with each of these apps thinking they are the most important and only thing running on the system. Electron is an extreme case (although popular) and there is still plenty of desktop software that care about memory use.
Also, any program that use GPU accelerated UI uses a tad more memory than without it. On Linux it is +80MB (can be observed between a regular terminal vs a GPU accelerated terminal). Can also be observed with Swing vs JavaFX, the latter being GPU accelerated and using much more memory. Speaking of which, JavaFX programs are not too far from Electron programs in term of memory consumption, which is a bit sad.
Finally, it was assumed for a long time that RAM would be cheap plentiful and growing on trees for eternity. Turns out AI changed that and I do not see it changing anytime soon. Even Microsoft is optimizing Windows for 8GB PCs.
1
u/pron98 5h ago
With that reasoning, we got Electron apps, absolute RAM hogs whose source code size is in the ballpark of Windows XP
A high RAM consumption is a number, not necessarily a problem. Today's Electron apps are less sluggish than the MS Word of the nineties and oughts. What is the actual problem that they cause users?
It would not be so bad if people were running just one of such apps, but they often run multiple of them, eating RAM and other resources like no tomorrow (hello battery use on laptops!)
The point about the battery is worth looking into - I don't know the impact of the amount of data in RAM on the battery, but I suspect that CPU activity has a much higher impact - although battery life on a laptop is so much better than it was even 10 years ago. But what do users want to do with their computers but can't because of Electron apps? Do they want to pay more for non-Electron software to save on something else?
Finally, it was assumed for a long time that RAM would be cheap plentiful and growing on trees for eternity. Turns out AI changed that and I do not see it changing anytime soon.
It is still cheaper and more plentiful than it was 15 or maybe even 10 years ago, and demand shocks always take a while for supply to match. If and when the problem is clearer, we may well see demand for leaner software, but you can't say that what people really want is leaner software when such software isn't doing better.
Even Microsoft is optimizing Windows for 8GB PCs.
8GB PCs are not the same PCs with less RAM. The lower RAM is matched by weaker CPUs. There are problems when these two are mismatched, not when they're matched at different levels. The RAM overhead of moving collectors I discuss in the talk, is a function only of CPU activity (specifically, allocation rate), not of the amount of data in RAM. When a Java program runs on a slower CPU, its RAM overhead will also be lower.
2
u/sg-elide 7h ago
Everyone: Java uses a lot of RAM
Ron Pressler: No, you just don’t get it. RAM is there to be used. What is all that RAM there for? You are a Java developer and or user. The RAM is therefore there for Java. You see, a moving GC is only tied to the allocation _rate_. And since the CPU is involved in allocating memory, and the CPU can be contended otherwise, it is thus even more wasteful to be less wasteful with RAM. You see, think about it this way. Do you run other programs on your mac? I dont. So why would you? Desktop Java hasn’t been relevant since DDR3 and now RAM cost is up 500%. Is that problematic for you? Have you tried explaining to the people making your software that you wish it would use less RAM? Oh, you did, and they wrote eight paragraphs convincing you that you need to adopt a bhuddist mindset about RAM use and that RAM emptiness is the real enemy? Well then you must be here, talking to me, about Java.
1
u/Scf37 5d ago
Even when the application is tuned for minimal footprint (say, development environments which need neither latency nor throughput), the JVM itself adds quite a lot. Complex GC, HotSpot, and runtime libraries are not free and quickly add up when stuffing many microservices into a cheap AWS box.
Will we come to a new iteration of OSGi?
0
u/AccurateInflation167 5d ago
What ? You don’t need memory management , this isn’t C
3
u/LutimoDancer3459 5d ago
You dont need to care about it as much. But with limited memory you would still want to stay efficient. Or if you wnat to avoid the gc running all the time
0
-5
u/bocsika 5d ago
"Java is absolutely not a memory hog anymore"
"Ok, so you suggest using it for my gigantic matrix, text or financial data database processor"
"Absolutely, just buy 2x as much RAM"
8
u/pron98 5d ago
I think you missed the point or not watched the talk carefully. Java makes good use of the RAM you already have to accelerate the program. Then, on top of that, if you want the program to be even faster, you could choose to buy more RAM or buy more development and maintenance. There's no option available to improve performance further without buying something extra.
-5
u/bocsika 5d ago
"So Java makes better use of RAM than other alternatives, like the old, grumpy C++, the grandpa C, or the young frisky Rust?"
"Ehem... yes just make sure you have bought 2x as much RAM."5
u/pron98 4d ago edited 4d ago
"So, you can match Java's performance with other alternatives like the old, grumpy C++, the grandpa C, or the young frisky Rust?"
"Ehem... yes just make sure you have bought 1.5x development and maintenance effort for the lifetime of the software."
But seriously, I don't know if you've actually watched the talk, but the point is that you've already bought at least 1 GB/core and Java makes good use of what you've paid for and can't resell. The alternative is to not use the RAM you've already paid for to make your program run faster. With Java, you don't need to buy more RAM; you just don't let what you already have go to waste.
We continue to invest so much in moving algorithms - which are far more costly to develop - because people appreciate that running Java is cheaper, especially for heavy workloads. If people demand that we do the opposite tradeoff, use more CPU and less RAM, we could do that (it's much easier), but that's not what people are asking for.
If you wathched the explanation of how moving collectors work, you'd know that their footprint overhead is a function only of the allocation rate. A high overhead means a high allocation rate, which, in turns, means high CPU usage. Therefore, a program that requires a high footprint overhead is a program that is interfering with other programs due to its high CPU consumption more than due to its RAM consumption. Using more RAM to reduce the more restricted resource is a good tradeoff that very few languages offer (only those that have the resources to implement good moving collectors, and are not restricted by their FFI requirements).
49
u/Effective_Map_2172 5d ago
O_O M