4 ms·

You don't need to "believe", you just have to know it. CS is a discipline, not a church. As an exercise, get a full list of all your processes and do the math

You don't need to "believe", you just have to know it. CS is a discipline, not a church. As an exercise, get a full list of all your processes and do the math by replacing them by hypothetical JVM instances [one per process] and I suggest paying attention to "shared pool" size for each process too. I guarantee you'll be shocked by total RAM consumed by an "empty" OSX or Vista. Just imagine: every little tiny process, even simple background services, will have a full copy of your entire userspace layer in its address space. Moreover, with 12-core CPUs becoming a reality very soon, the issue becomes even more important. With proper code sharing on OS level 12 instances of a process should (theoretically) take not much more RAM than just one. But because of VM overhead you'll be essentially duplicating it 12 times. More code duplication also means more I/O hits on disk and system bus and CPU L1/L2 cache drain. This is why Java is for enterprise/web software only. It is simply retarded to build on it in a true multi-process environment. OS-level code sharing is hugely important. Your hard drive is full of code, gigabytes of it, and you can't just clone big chunks of it into every process who needs it. Without code sharing you'd have to wait a few more years for an iPhone. He-he, actually because of lack of it, you aren't reading this in a JVM-powered browser and probably never will.

nradov 18y ago
Have you actually tested this on a complex system of multiple applications running or JVMs to measure the effects, or are you just guessing that it would be a problem? I don't dispute that sharing libraries across multiple processes would be a nice optimization, but for typical use cases it's way down on the priority list. Most Java applications are written to use multiple threads (rather than multiple processes), which all execute on the same JVM and share all memory. Web apps typically run in some sort of J2EE container and those can be configured to share libraries across multiple applications; the OS doesn't come into play. Even if you're talking about running multiple separate desktop applications those will mostly only have the J2SE runtime library in common; for Java 1.6 the rt.jar file is 42MB, and only a fraction of it even needs to be loaded into memory.
- deleted 18y ago
  [deleted]
- old-gregg 18y ago
  Have you actually tested this on a complex system? What? Have you actually tested the multiplication table with rocks or buttons? That's simple math. Memory consumption is in front of you: I already pointed you to tools and told you what numbers to use. Your last paragraph only restates what I already said: Java is for few-processes-per-machine use case. And cloning 42MB of code into every process is insane, I can't believe you're actually proposing this. BTW, that's compressed 42MB, you seem to actually be using J2EE download size to estimate your RAM consumption. Nice. I am amazed by the damage done by Java lobotomy at US schools and have very little hope for progress moving forward: UNIX clones from the 70s are here to stay, not only we can't hope to advance in that area (OS design) but I'm afraid we're losing skill to even comprehend existing systems. One more time: right now, as you're reading this, nearly all processes of you machine have much, much larger code segments than data segments. Most of your RAM, young man, is consumed by code, not data. The code-vs-data ratio becomes even more ridiculous if you're running a few instances of VMWare. Most of the time you're waiting for your Macbook Pro to do something, it's pushing code around. And the reason Vista is so bloated and so much slower is because it loads a lot more code into RAM than XP did. So yes, code sharing is hugely important. A server machine, however, is very different: there a very few applications and lots of data, so using something inefficient as JVM makes sense if it speeds up development/deployment.
  - nradov 18y ago
    You missed the point. Code sharing in memory only helps if you have multiple processes all using the exact same library. That problem is already solved for server applications, and is mostly irrelevant for mobile platforms, so I guess you're mostly worried about the desktop environment. But typical desktops only run a few user-mode processes at a time, and wouldn't be able to share much code regardless of whether the JVM supported it or not. While it would certainly be possible to implement that feature, it seems most of us just don't care. RAM is cheap and I would rather see the Sun and IBM developers focus on more important issues. Dynamic method invocation and tail-call optimization are a lot higher on my list. The reason you're not seeing much progress on OS design is not because we don't comprehend the systems, but rather because what we have now is good enough for what most people want to do. The OS has largely ceased to be an obstacle and quietly faded into the background. Disruptive OS innovation will have to wait until someone comes up with a killer app that requires fundamental capabilities which current OS designs can't support. Most of the time I'm waiting for my Vista machine to do something it's not pushing code around. It's idling, waiting for a response from a server.

nradov 18y ago

Have you actually tested this on a complex system of multiple applications running or JVMs to measure the effects, or are you just guessing that it would be a problem? I don't dispute that sharing libraries across multiple processes would be a nice optimization, but for typical use cases it's way down on the priority list. Most Java applications are written to use multiple threads (rather than multiple processes), which all execute on the same JVM and share all memory. Web apps typically run in some sort of J2EE container and those can be configured to share libraries across multiple applications; the OS doesn't come into play. Even if you're talking about running multiple separate desktop applications those will mostly only have the J2SE runtime library in common; for Java 1.6 the rt.jar file is 42MB, and only a fraction of it even needs to be loaded into memory.

deleted 18y ago
[deleted]
old-gregg 18y ago
Have you actually tested this on a complex system? What? Have you actually tested the multiplication table with rocks or buttons? That's simple math. Memory consumption is in front of you: I already pointed you to tools and told you what numbers to use. Your last paragraph only restates what I already said: Java is for few-processes-per-machine use case. And cloning 42MB of code into every process is insane, I can't believe you're actually proposing this. BTW, that's compressed 42MB, you seem to actually be using J2EE download size to estimate your RAM consumption. Nice. I am amazed by the damage done by Java lobotomy at US schools and have very little hope for progress moving forward: UNIX clones from the 70s are here to stay, not only we can't hope to advance in that area (OS design) but I'm afraid we're losing skill to even comprehend existing systems. One more time: right now, as you're reading this, nearly all processes of you machine have much, much larger code segments than data segments. Most of your RAM, young man, is consumed by code, not data. The code-vs-data ratio becomes even more ridiculous if you're running a few instances of VMWare. Most of the time you're waiting for your Macbook Pro to do something, it's pushing code around. And the reason Vista is so bloated and so much slower is because it loads a lot more code into RAM than XP did. So yes, code sharing is hugely important. A server machine, however, is very different: there a very few applications and lots of data, so using something inefficient as JVM makes sense if it speeds up development/deployment.
- nradov 18y ago
  You missed the point. Code sharing in memory only helps if you have multiple processes all using the exact same library. That problem is already solved for server applications, and is mostly irrelevant for mobile platforms, so I guess you're mostly worried about the desktop environment. But typical desktops only run a few user-mode processes at a time, and wouldn't be able to share much code regardless of whether the JVM supported it or not. While it would certainly be possible to implement that feature, it seems most of us just don't care. RAM is cheap and I would rather see the Sun and IBM developers focus on more important issues. Dynamic method invocation and tail-call optimization are a lot higher on my list. The reason you're not seeing much progress on OS design is not because we don't comprehend the systems, but rather because what we have now is good enough for what most people want to do. The OS has largely ceased to be an obstacle and quietly faded into the background. Disruptive OS innovation will have to wait until someone comes up with a killer app that requires fundamental capabilities which current OS designs can't support. Most of the time I'm waiting for my Vista machine to do something it's not pushing code around. It's idling, waiting for a response from a server.