21 ms·

In my opinion, anything on JVM isn't going to become a mainstream language because VMs refuse to share code between OS processes. .NET and Mono solve this with

In my opinion, anything on JVM isn't going to become a mainstream language because VMs refuse to share code between OS processes. .NET and Mono solve this with AOT-precompiled modules. Ruby and Python kind of solve this by heavily reusing C runtime/libraries, so at least there aren't 25 copies of printf() and qsort() wasting space in RAM. JVM doesn't solve this at all. JVM-based softwares act like pigs showing zero respect to the enrivonment they're in. They're good at "one program = one computer" tasks, i.e. only for server-side or perhaps developer's workstation scenarios. Flash/Air is even worse: not only it won't share anything, but it also brings in its own graphics, font rasterization, hot key bindings, scroll bar behavior, etc, making every software built on top of it look and feel like a poorly designed console game running on your PC under software emulator. This is why I never touch anything like JVM/AIR: I don't believe the cloud is "the answer" and I want my code to run on servers, desktops, netbooks, routers and cell phones.

icey 18y ago
Help me understand your point.. You're saying Java will never become mainstream because it runs on a VM? Edit: The more I read your response the less it makes sense to me. You say that you hate VMs because they don't respect the OS, but then you go on to say you want to write code that will run everywhere... That's the point of running in a VM, no?
- old-gregg 18y ago
  Thank you for proof-reading, I edited my post above: I guess I am complaining about implementation of JVM/AIR. Yes, I want my code to run everywhere, but I want to use more lightweight VMs for that, those that blend into native OS more easily, and code sharing between processes is a big part of it, i.e. if I want to be able to write my application as a module which can be shared between 20 processes without being copied around 20 times. Basically the only parts of VMs I like is the bytecode and garbage collection. JVM/AIR do a lot more than that.
  - deleted 18y ago
    [deleted]
  - andreyf 18y ago
    I want to use more lightweight VMs for that, those that blend into native OS more easily Well, it's a tradeoff, right? With the JVM, because of the separation from the OS, you have that write-once-run-anywhere interoperability?
- Xichekolas 18y ago
  Not that I totally understand it either, but I think he was railing against the JVM in particular, not VMs in general.
nradov 18y ago
I find it hard to believe that sharing libraries in memory makes a significant difference. Most libraries are small relative to RAM sizes. The only exception is on cell phones, which only run a few processes anyway.
- old-gregg 18y ago
  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.

icey 18y ago

Help me understand your point.. You're saying Java will never become mainstream because it runs on a VM? Edit: The more I read your response the less it makes sense to me. You say that you hate VMs because they don't respect the OS, but then you go on to say you want to write code that will run everywhere... That's the point of running in a VM, no?

old-gregg 18y ago
Thank you for proof-reading, I edited my post above: I guess I am complaining about implementation of JVM/AIR. Yes, I want my code to run everywhere, but I want to use more lightweight VMs for that, those that blend into native OS more easily, and code sharing between processes is a big part of it, i.e. if I want to be able to write my application as a module which can be shared between 20 processes without being copied around 20 times. Basically the only parts of VMs I like is the bytecode and garbage collection. JVM/AIR do a lot more than that.
- deleted 18y ago
  [deleted]
- andreyf 18y ago
  I want to use more lightweight VMs for that, those that blend into native OS more easily Well, it's a tradeoff, right? With the JVM, because of the separation from the OS, you have that write-once-run-anywhere interoperability?
Xichekolas 18y ago
Not that I totally understand it either, but I think he was railing against the JVM in particular, not VMs in general.

nradov 18y ago

I find it hard to believe that sharing libraries in memory makes a significant difference. Most libraries are small relative to RAM sizes. The only exception is on cell phones, which only run a few processes anyway.

old-gregg 18y ago
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.