4 ms·

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 co

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.
- old-gregg 18y ago
  But typical desktops only run a few user-mode processes at a time No. Run ps -A goddamit. A "typical" desktop, especially a UNIX-derived variant, runs a lot of processes. And servers in the near future will do too. and wouldn't be able to share much code No, there are a ton of userspace code which is being shared between processes. The code that allocates memory, the code that draws lines and buttons on your screen, the code that sorts strings, the code that implements threading, the code that renders bitmaps out of TTF glyphs, reads files and opens sockets, each process needs megabytes of code you seem to have no idea about: it's not even about libraries, it's about everything not drivers, do you understand now? There are good reasons why JVM programs are memory pigs: they are, essentially, running their own OS in complete isolation. 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. The problem is that programmers are cheap. There is no market pressure to evolve and leave technology from the 70s in the past. Armies of incubated Java code monkeys cost less in the short run as opposed to going against the stream of mediocrity. This is why new platforms (iPhone) are so exciting and refreshing: they let us leave obsoleted/inherited junk behind: iPhone doesn't have JVM nor Flash/AIR for very good reasons: OS is your VM. Has always been. It's just the right thing to do. The OS has largely ceased to be an obstacle and quietly faded into the background. You have demonstrated enough ignorance regarding what OS actually is to allow me to safely ignore this comment. There are a few folks at Apple and Microsoft who are still capable of understanding these issues, this is why Java, despite of 10+ years of availability, with all its beautiful promises, still lives in the obscurity of server rooms.
  - nradov 18y ago
    This is silly. The "typical" desktop runs MS Windows, with only a few user processes running at a time. Some of those processes may have a bunch of threads going, but the process count is small. Of course all of those processes share the low-level OS libraries. And guess what: each JVM process shares those OS libraries, too. The Java standard library does duplicate some of the higher-level OS features, which is the only practical way to achieve cross-platform compatibility. Any cross-platform solution is going to impose some overhead. Of course you can write native iPhone apps with no extra overhead, but then they can't be used by the 95% of mobile device users who have other platforms. I'm not sure what you mean about code running in server rooms being obscure. That's what drives web applications and network services which are more visible and critical to many of us than our desktop applications. By the way, anyone who wants to use the JVM for writing desktop applications should take a look at the Eclipse RCP. I haven't had a need to develop for that platform myself, but the results I've seen from other companies look pretty good.

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.

old-gregg 18y ago
But typical desktops only run a few user-mode processes at a time No. Run ps -A goddamit. A "typical" desktop, especially a UNIX-derived variant, runs a lot of processes. And servers in the near future will do too. and wouldn't be able to share much code No, there are a ton of userspace code which is being shared between processes. The code that allocates memory, the code that draws lines and buttons on your screen, the code that sorts strings, the code that implements threading, the code that renders bitmaps out of TTF glyphs, reads files and opens sockets, each process needs megabytes of code you seem to have no idea about: it's not even about libraries, it's about everything not drivers, do you understand now? There are good reasons why JVM programs are memory pigs: they are, essentially, running their own OS in complete isolation. 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. The problem is that programmers are cheap. There is no market pressure to evolve and leave technology from the 70s in the past. Armies of incubated Java code monkeys cost less in the short run as opposed to going against the stream of mediocrity. This is why new platforms (iPhone) are so exciting and refreshing: they let us leave obsoleted/inherited junk behind: iPhone doesn't have JVM nor Flash/AIR for very good reasons: OS is your VM. Has always been. It's just the right thing to do. The OS has largely ceased to be an obstacle and quietly faded into the background. You have demonstrated enough ignorance regarding what OS actually is to allow me to safely ignore this comment. There are a few folks at Apple and Microsoft who are still capable of understanding these issues, this is why Java, despite of 10+ years of availability, with all its beautiful promises, still lives in the obscurity of server rooms.
- nradov 18y ago
  This is silly. The "typical" desktop runs MS Windows, with only a few user processes running at a time. Some of those processes may have a bunch of threads going, but the process count is small. Of course all of those processes share the low-level OS libraries. And guess what: each JVM process shares those OS libraries, too. The Java standard library does duplicate some of the higher-level OS features, which is the only practical way to achieve cross-platform compatibility. Any cross-platform solution is going to impose some overhead. Of course you can write native iPhone apps with no extra overhead, but then they can't be used by the 95% of mobile device users who have other platforms. I'm not sure what you mean about code running in server rooms being obscure. That's what drives web applications and network services which are more visible and critical to many of us than our desktop applications. By the way, anyone who wants to use the JVM for writing desktop applications should take a look at the Eclipse RCP. I haven't had a need to develop for that platform myself, but the results I've seen from other companies look pretty good.