Walter Bright wrote:
> I just don't get the reason for a VM. It seems like a solution looking for a problem.

Some of the benefits of using a VM platform:

1) Dynamic classloading. Linking is greatly simplified, and my code doesn't need to be written differently depending on whether I'm linking dynamically or statically.

2) Better tools for profiling, debugging, reflection, and runtime instrumentation than are typically available for natively-compiled languages.

3) Better memory management: with the memory manager located in the VM, rather than in the application code, the collection of garbage is much more well-defined. Since all classes are loaded into the same VM instance, there's only a single heap. Consequently, there's never an issue of what happens when an object passes from one module to another (as can be the case when a native library passes an object into the main application, or vice versa).

4) Better security/sandboxing. If you write a pluggable application in C++, how will you restrict plugin authors from monkeying with your application data structures? In the JVM or the CLR, the VM provides security mechanisms to restrict the functionality of sandboxed code. A particular CLR assembly might, for example, be restricted from accessing the file system or the network connection. You can't do that with native code.

Sure, it's possible for natively-compiled languages to offer most of the same bells and whistles as dynamic languages or VM-based platforms. But, in the real world, those abstractions are usually difficult to implement in native code, so they become available much more readily in virtual machine.

--benji

Sean Kelly wrote:
...
> That said, JIT optimization is still a relatively new practice, and with more cores being added to computers these days it's entirely possible that a JIT optimizer could run on one or more background CPUs and do much better than today.

And then you're sacrificing two or three cores to run one thread, rather than sacrificing most of the developer's computational power at compile time and running as efficiently (or more so) with at most one core per thread.

Now, if the compiler cached its optimizations on disk, you could potentially get similar optimizations after some large number of runs. However, in the interim the program would run slower than the optimized precompiled code, and would start slower than the JIT code that didn't cache its optimizations (because that caching takes disk time, and that's one of the most expensive resources).

Of course, your runtime compiler can optimize for your user's current CPU, even if that changes. I suppose you could create binaries optimized for each CPU and have a script determine which is appropriate for the current CPU, but that's spending disk space (also quite scarce) in exchange for CPU time (relatively abundant).

I don't know how to solve this problem, but it's an interesting one.

Benji Smith wrote:
> Walter Bright wrote:
>> I just don't get the reason for a VM. It seems like a solution looking for a problem.
> 
> Some of the benefits of using a VM platform:
> 
> 1) Dynamic classloading. Linking is greatly simplified, and my code doesn't need to be written differently depending on whether I'm linking dynamically or statically.
> 
> 2) Better tools for profiling, debugging, reflection, and runtime instrumentation than are typically available for natively-compiled languages.
> 
> 3) Better memory management: with the memory manager located in the VM, rather than in the application code, the collection of garbage is much more well-defined. Since all classes are loaded into the same VM instance, there's only a single heap. Consequently, there's never an issue of what happens when an object passes from one module to another (as can be the case when a native library passes an object into the main application, or vice versa).
> 
> 4) Better security/sandboxing. If you write a pluggable application in C++, how will you restrict plugin authors from monkeying with your application data structures? In the JVM or the CLR, the VM provides security mechanisms to restrict the functionality of sandboxed code. A particular CLR assembly might, for example, be restricted from accessing the file system or the network connection. You can't do that with native code.
> 
> Sure, it's possible for natively-compiled languages to offer most of the same bells and whistles as dynamic languages or VM-based platforms. But, in the real world, those abstractions are usually difficult to implement in native code, so they become available much more readily in virtual machine.
> 
> --benji

Interesting.  Paraphrasing your reply:  These are benefits of VM's, but no they're not.

They're above list of 'benefits' are some things that current VM implementations and the languages that sit on top of them and the provided libraries that sit on top of them all add up to provide. They're very much not attributes of the VM underneath nor of VM's in general.

Please be careful when attributing causal effects.  A favorite phrase: correlation is not causation.

Later,
Brad

You people can list a million of (mostly) theoretical benefits in having a VM. Java/.NET apps will continue to be damn slow despite of these statements (Java the most). That is the simple and self-evident truth. Aside from, the idea of having a CPU core for the exclusive use of a VM is a *total* waste. I don't trust in hardware solutions for software problems.

Just my opinion. :)

Tom;

Benji Smith escribió:
> Walter Bright wrote:
>> I just don't get the reason for a VM. It seems like a solution looking for a problem.
> 
> Some of the benefits of using a VM platform:
> 
> 1) Dynamic classloading. Linking is greatly simplified, and my code doesn't need to be written differently depending on whether I'm linking dynamically or statically.
> 
> 2) Better tools for profiling, debugging, reflection, and runtime instrumentation than are typically available for natively-compiled languages.
> 
> 3) Better memory management: with the memory manager located in the VM, rather than in the application code, the collection of garbage is much more well-defined. Since all classes are loaded into the same VM instance, there's only a single heap. Consequently, there's never an issue of what happens when an object passes from one module to another (as can be the case when a native library passes an object into the main application, or vice versa).
> 
> 4) Better security/sandboxing. If you write a pluggable application in C++, how will you restrict plugin authors from monkeying with your application data structures? In the JVM or the CLR, the VM provides security mechanisms to restrict the functionality of sandboxed code. A particular CLR assembly might, for example, be restricted from accessing the file system or the network connection. You can't do that with native code.
> 
> Sure, it's possible for natively-compiled languages to offer most of the same bells and whistles as dynamic languages or VM-based platforms. But, in the real world, those abstractions are usually difficult to implement in native code, so they become available much more readily in virtual machine.
> 
> --benji

Brad Roberts wrote:
> Benji Smith wrote:
>> Walter Bright wrote:
>>> I just don't get the reason for a VM. It seems like a solution looking for a problem.
>>
>> Some of the benefits of using a VM platform:
>>
>> 1) Dynamic classloading. Linking is greatly simplified, and my code doesn't need to be written differently depending on whether I'm linking dynamically or statically.

That's an attribute of the language, not the VM. COM does the same thing with natively compiled languages.

>> 2) Better tools for profiling, debugging, reflection, and runtime instrumentation than are typically available for natively-compiled languages.

I attribute this to two things, none of which are a characteristic of a VM:

1) Java is a very easy language to parse, with well defined semantics. This makes it easy to develop such tools for it. C++, on the other hand, is disastrously difficult to parse.

2) The two VMs out there have billions and billions of dollars sunk into them to create tools, no matter how easy/hard that might be.

>> 3) Better memory management: with the memory manager located in the VM, rather than in the application code, the collection of garbage is much more well-defined. Since all classes are loaded into the same VM instance, there's only a single heap. Consequently, there's never an issue of what happens when an object passes from one module to another (as can be the case when a native library passes an object into the main application, or vice versa).

1) I wrote a GC for Java, back in the day. Doing a good GC is dependent on the right language semantics, having a VM has nothing to do with it. D works with add on DLLs by sharing a single instance of the GC.


>> 4) Better security/sandboxing. If you write a pluggable application in C++, how will you restrict plugin authors from monkeying with your application data structures? In the JVM or the CLR, the VM provides security mechanisms to restrict the functionality of sandboxed code. A particular CLR assembly might, for example, be restricted from accessing the file system or the network connection. You can't do that with native code.

Every single VM based system, from javascript to Word macros, has turned into a vector for compromising a system. That's why I run email with javascript, etc., all turned off. It's why I don't use Word. I know about the promises of security, but I don't believe it holds up in practice.


>> Sure, it's possible for natively-compiled languages to offer most of the same bells and whistles as dynamic languages or VM-based platforms. But, in the real world, those abstractions are usually difficult to implement in native code, so they become available much more readily in virtual machine.

I believe you are seeing the effects of billions of dollars being invested in those VMs, not any fundamental advantage.

gareis wrote:
> Sean Kelly wrote:
> ...
>> That said, JIT optimization is still a relatively new practice, and 

But the optimizations are the same (basically), and the best and brightest have been at it for years. I'd venture a guess that more has been / still is being spent on VM research rather than static compiler research. Over roughly the past 10 years, I've seen several articles promising Java would exceed C and Fortran in 'a year or two'. A couple of years later I also recall finding some pretty large performance regressions between major releases of their Java VM. I still think 1.3 does some things better than 1.6 and it's been, what, 5 years? Interestingly, Sun is still improving their static compiler tools though.

>> with more cores being added to computers these days it's entirely possible that a JIT optimizer could run on one or more background CPUs and do much better than today.
> 
> And then you're sacrificing two or three cores to run one thread, rather than sacrificing most of the developer's computational power at compile time and running as efficiently (or more so) with at most one core per thread.
> 
> Now, if the compiler cached its optimizations on disk, you could potentially get similar optimizations after some large number of runs. 

Sun's Hotspot does this (but it's not explicitly cached on disk).

> However, in the interim the program would run slower than the optimized precompiled code, and would start slower than the JIT code that didn't 

That's why Sun has both a 'client' and a 'server' VM.

> cache its optimizations (because that caching takes disk time, and that's one of the most expensive resources).
> 
> Of course, your runtime compiler can optimize for your user's current CPU, even if that changes. I suppose you could create binaries optimized for each CPU and have a script determine which is appropriate for the 

I know Intel and (IIRC) to a lesser extent MS VS2005 C/C++ as well as Sun and HP compilers will compile this right into the binary for you (and then the best code is picked at runtime). Seems to work pretty well from what I've seen.

> current CPU, but that's spending disk space (also quite scarce) in exchange for CPU time (relatively abundant).
> 
> I don't know how to solve this problem, but it's an interesting one.

Tom wrote:
> You people can list a million of (mostly) theoretical benefits in having a VM. Java/.NET apps will continue to be damn slow despite of these statements (Java the most). That is the simple and self-evident truth. Aside from, the idea of having a CPU core for the exclusive use of a VM is a *total* waste. I don't trust in hardware solutions for software problems.

I strongly disagree that Java and C# are 'damn slow'. Have you seen some of the games out there being developed in both languages? This is an argument that will last into infinity, I'm sure. There are people who use languages like Java and C# because they really do see benefits in doing so. The fact that you don't doesn't make it less true that they do. I've used Java for a variety of applications. I have a good feel for what I think it is and isn't suitable for. What is and isn't beneficial is highly subjective.

And really, someone who has never taken the time to roll their sleeves up and dive into a language can really only speculate about it. How many times have we seen C++ programmers dis D after glancing at the feature comparison list without ever writing a line of D code? When you have actually used a language in anger, you have a much better perspective as to what its strengths and weaknesses are. The benefits they see are not theoretical. To most Java programmers I know, speed is rarely a concern (though it does pop up occasionally, particularly with trig functions). If they weren't satisfied with the performance characteristics they wouldn't be using it. They are more often concerned with distribution, or the market penetration of a particular JRE version.

Java and .NET both have a place. The benefits users see from them may or may not be related to the existence of a VM, but those who do use the languages usually do see benefits of some kind. Otherwise they'd all be using C or C++.

Walter Bright wrote:
> Brad Roberts wrote:
>> Benji Smith wrote:
>>> 1) Dynamic classloading. Linking is greatly simplified, and my code doesn't need to be written differently depending on whether I'm linking dynamically or statically.
> 
> That's an attribute of the language, not the VM. COM does the same thing with natively compiled languages.

Actually, COM illustrates my point quite nicely. If you're going to write a COM-compatible library, you have to plan for it from the start, inheriting from IUnknown, creating GUIDs, and setting up reference counting functionality.

Likewise, a consumer of a COM library has to know it uses COM semantics, since the application code will have to query the interface using COM-specific functions.

Even in D, if I want to write code in a DLL (or call code from a DLL), my ***CODE*** has to be aware of the existence of the DLL.

In Java, the code I write is identical, whether I'm calling methods on my own classes, calling methods on classes packaged up in a 3rd party library, or packaging up my own library for distribution to other API consumers.

Since the VM provides all of the classloading functionality, the application code and the library code is completely agnostic of calling & linking conventions.

Of course, the disadvantage of this is that there's no such thing as static linking. *Everything* is linked dynamically. But at least I don't have to rewrite my code just to create (or consume) a library.


>>> 2) Better tools for profiling, debugging, reflection, and runtime instrumentation than are typically available for natively-compiled languages.
> 
> I attribute this to two things, none of which are a characteristic of a VM:
> 
> 1) Java is a very easy language to parse, with well defined semantics. This makes it easy to develop such tools for it. C++, on the other hand, is disastrously difficult to parse.
> 
> 2) The two VMs out there have billions and billions of dollars sunk into them to create tools, no matter how easy/hard that might be.

You can use the "billions of dollars" excuse if you like, but the "easy to parse" excuse doesn't hold water. Notice, I'm not talking about refactoring tools or code-coverage tools, or anything like that. I'm talking about profiling, debugging, reflection, and runtime instrumentation.

Take debugging, for example...

It's possible to hook a debugger to an already-running instance of the JVM on a remote machine. And you can do that without a special debug build of the application. The application binaries always contain the necessary symbols for debugging, so it's always possible to debug applications.

The JVM has a debugging API which provides methods for suspending and resuming execution, walking the objects on the heap, querying objects on the stack, evaluating expressions, setting normal and conditional breakpoints, replacing or redefining entire class definitions in-place (without restarting the application).

Essentially, the JVM already includes the complete functionality of a full-featured debugger. The debugging API is just a mechanism for controlling the debugger from a 3rd-party application, like a debugging GUI.

Without a VM, I don't know how you could get a debugger implemented just by connecting some GUI code to a debugging API. The x86 doesn't have a debugger built-in.

The same thing is true of profiling, reflection, and instrumentation. It has *nothing* to do with the semantics of the language, or with the syntax being "easy to parse". It has everything to do with the fact that a VM can provide hooks for looking inside itself. A non-virtual machine doesn't do that.

>>> 3) Better memory management: with the memory manager located in the VM, rather than in the application code, the collection of garbage is much more well-defined. Since all classes are loaded into the same VM instance, there's only a single heap. Consequently, there's never an issue of what happens when an object passes from one module to another (as can be the case when a native library passes an object into the main application, or vice versa).
> 
> 1) I wrote a GC for Java, back in the day. Doing a good GC is dependent on the right language semantics, having a VM has nothing to do with it. D works with add on DLLs by sharing a single instance of the GC.

I won't argue this one, since I don't know much about D's shared GC implementation.

>>> 4) Better security/sandboxing. If you write a pluggable application in C++, how will you restrict plugin authors from monkeying with your application data structures? In the JVM or the CLR, the VM provides security mechanisms to restrict the functionality of sandboxed code. A particular CLR assembly might, for example, be restricted from accessing the file system or the network connection. You can't do that with native code.
> 
> Every single VM based system, from javascript to Word macros, has turned into a vector for compromising a system. That's why I run email with javascript, etc., all turned off. It's why I don't use Word. I know about the promises of security, but I don't believe it holds up in practice.

You may argue that certain VMs (I suppose JavaScript and VBA) have implemented their security functionality poorly. But the core concept, if implemented correctly (as in the JVM and the CLR) allows a hosting application to load a plugin and restrict the functionality of the executable code within that plugin, preventing it from accessing certain platform features or resources.

Natively-compiled code can't even *hope* to enforce that kind of isolation.

--benji

Op Tue, 01 May 2007 11:25:06 +1000
schreef Daniel Keep <daniel.keep.lists@gmail.com>:

> Jan Claeys wrote:
> > Well, in practice most Python code just runs on the Python bytecode
> > interpreter (and in most other cases on the Java or .NET VMs), and
> > with a good reason.
> > ...
> 
> The really interesting stuff on Python is happening over at the PyPy[1] project.

It's a very interesting project, but RPython is not the same language as Python, and they left out some of the things that make compiling Python to native code so difficult...

> It's all very cool, and really hard to understand. :P

Right, I didn't try to understand the details yet.  ;)


-- 
JanC

Dave wrote:
> gareis wrote:
>> Sean Kelly wrote:
>> ...
>>> That said, JIT optimization is still a relatively new practice, and 
> 
> But the optimizations are the same (basically), and the best and brightest have been at it for years. I'd venture a guess that more has been / still is being spent on VM research rather than static compiler research. Over roughly the past 10 years, I've seen several articles promising Java would exceed C and Fortran in 'a year or two'. A couple of years later I also recall finding some pretty large performance regressions between major releases of their Java VM. I still think 1.3 does some things better than 1.6 and it's been, what, 5 years? Interestingly, Sun is still improving their static compiler tools though.

That's because (I suspect) most of Sun's big customers use their static compilers.  On Java speed... I still debug in emacs instead of using Sun Studio because the latter is irritatingly slow.  Java may have the potential to produce fast code, but I wish that were more evident in the performance of Java UI apps I've used.  This may be entirely a problem with Swing or whatever, but appearances count.


Sean