3 ms·
Both. JVM also allocates a lot of memory (relatively) for even its smallest objects (round sizes up, frequent boxing and copying of primitives, everybody gets
by angelbob 15y ago
Both. JVM also allocates a lot of memory (relatively) for even its smallest objects (round sizes up, frequent boxing and copying of primitives, everybody gets an automatic mutex), and fragments significantly because it has good garbage collectors that deal fine with that.
A lot of Java is optimized for this, and it would take a fair bit of work to make a JVM (and compiler!) implementation that changed the behavior pervasively.
Java assumes memory is cheap at many levels. And usually, it's right.
- jshen 15y ago"Java assumes memory is cheap at many levels. And usually, it's right." I would say it's usually wrong. Imagine how much ram you'd need if all of your GUI apps were on the JVM. Imagine how much ram you'd need if '$ cat blah.txt | grep "something" | uniq | sort' were all JVM processes. Etc, etc, etc. It seems to only be right for long lived server side processes that have enough load to make it a benefit.
- angelbob 15y agoYou wouldn't architect that in that way in JVM. Instead, you'd use threads rather than processes, use heavier-weight but more capable tools and so on. The JVM is not The Unix Way. You have to do things differently - and in Java-land, they do. It's not really my thing either, but it's not as bad as you'd think if you just pretend we're mapping all our existing Unix stuff, unchanged, into Java.
- jshen 15y agoRight, and my point is that the JVM way only fits a narrow range of use cases. Primarily long running server side processes.
- seanp2k 15y agoYou mean `$ grep 'something' blah.txt |sort -u`, right?! http://partmaps.org/era/unix/award.html http://partmaps.org/era/unix/award.html