Op Tue, 01 May 2007 02:55:44 -0300
schreef Tom <tom@nospam.com>:

> You people can list a million of (mostly) theoretical benefits in
> having a VM.

"Virtual machines" (implemented in software) & "real machines"
(implemented in hardware, aka "CPUs") are both "machines".

VMs have the advantage that they are easier & faster to change and also cheaper to (re)produce, that's also why every modern CPU starts life as a VM during its design & development.


-- 
JanC

Mike Parker escribió:
> 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've seen no big games written in Java/C# (so I can't really hold a position on this ground). Though I've seen *A LOT* of server/client apps done in Java. The speed *IS* a concern, believe me. They ARE definitely slow in comparison to C/C++ apps.

On the other hand, I remember a great game that was written in a mix of C++/Python, and was REALLY GOOD and fast: Blade of darkness was its name IIRC. Though, the speed code was C++, so...

> 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. 

Ehm, I work with Java/Perl the better part of the time. So, I think I've roll my sleeves a lot with it. :)

> 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.

I can't deny the benefits, and they're not ALL theoretical. Though, Java has a lot of drawbacks in the performance market. It's really good (yet slow but good) for server side apps.

> 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++.

Of course, and coming from the C++ world, that's why I like D so much.

Tom wrote:
> Mike Parker escribió:
>> 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've seen no big games written in Java/C# (so I can't really hold a position on this ground). Though I've seen *A LOT* of server/client apps done in Java. The speed *IS* a concern, believe me. They ARE definitely slow in comparison to C/C++ apps.
> 

Ok, I know Perl is specialized for this type of thing (with many of the libs. written in C), but for small programs handling large chunks of data, Java has rarely been a consideration in the shops I've recently worked at. And believe me, it's not for lack of trying because it's easier to find decent Java hackers than good C or Perl hackers, IME.

I remember actually scripting something like:

if(file_size > X)
  java -server -XmsY -XmxZ App
else
  java -client App

and having to experiment to set X, Y and Z, and Perl still worked better. What a PITA.

More of the same w/ .NET (speed critical stuff in native C++), although the .NET GC is very good and generally hard to beat with hand-crafted mem. mgmt. (again IME).

> On the other hand, I remember a great game that was written in a mix of C++/Python, and was REALLY GOOD and fast: Blade of darkness was its name IIRC. Though, the speed code was C++, so...
> 
>> 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. 
> 
> Ehm, I work with Java/Perl the better part of the time. So, I think I've roll my sleeves a lot with it. :)
> 
>> 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.
> 
> I can't deny the benefits, and they're not ALL theoretical. Though, Java has a lot of drawbacks in the performance market. It's really good (yet slow but good) for server side apps.
> 
>> 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++.
> 
> Of course, and coming from the C++ world, that's why I like D so much.

Reply to Benji,

[...]

Most of your rebuttal basically says that programs in VM can do X without the coder having to do something different than they would if they didn't do X. There is (lots of big problems aside) a simple solution to this problem in native code: Don't allow the coder to NOT do X, requiter that all classes be COM objects, always compile in debugging and profiling symbols, heck maybe even a full net-centric debugger. It seams to me (and I could be wrong) that the way that the VM languages get all of these advantages of these options is by not making them options, they are requirements.

The only case that all of that doesn't cover is sand boxing. Well, something is going to have to run in native code, so why not make native code safe? Allow a process to span off a thread that is native code but sand boxed: some OS API's don't work, it has a Read Only or no access to some part of ram that the rest of the process can access. In short If security is such a big deal, why is the VM doing it instead of the OS?

BCS wrote:
> Reply to Benji,
> 
> [...]
> 
> Most of your rebuttal basically says that programs in VM can do X without the coder having to do something different than they would if they didn't do X. There is (lots of big problems aside) a simple solution to this problem in native code: Don't allow the coder to NOT do X, requiter that all classes be COM objects, always compile in debugging and profiling symbols, heck maybe even a full net-centric debugger. It seams to me (and I could be wrong) that the way that the VM languages get all of these advantages of these options is by not making them options, they are requirements.
> 
> The only case that all of that doesn't cover is sand boxing. Well, something is going to have to run in native code, so why not make native code safe? Allow a process to span off a thread that is native code but sand boxed: some OS API's don't work, it has a Read Only or no access to some part of ram that the rest of the process can access. In short If security is such a big deal, why is the VM doing it instead of the OS?


Sure. Fair enough. You *could* maybe do all of that stuff with native code, if only someone had ever implemented it.

...Shrug...

Rather than speculating on what's theoretically possible in a natively compiled platform, I'm pointing out some of the advantages that exist *today* in VM-based platforms.

I never claimed those advantages outweighed the considerable advantages of native compilation. I'm just saying...there are some features that are *currently* being routinely provided in VM platforms that don't yet exist when you're compiling code to a native platform.

Jeez. Talk about throwing stones in glass houses...

--benji

Benji Smith wrote:
> 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.

Not if the language is designed to be COM-compatible from the start. You don't need a VM to inherit from IUnknown, create GUIDs, or do reference counting.

> 
> 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.

If you designed a language around COM, you'd get all that stuff for free, too. I agree that using COM in C++ is a bit clunky, but after all, C++ was designed before there was COM.

> 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.

If you want, you can always compile your native app with debug symbols on.

> 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.

Most debuggers are able to attach themselves to running processes. The CPU itself does contain specific hardware to support debugging.

> 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.

Many profilers are able to hook into executables that have symbolic debug info present (Intel's comes to mind). Reflection can be done natively - D will get there. Instrumentation - depends on what instrumentation is done. You can't do line-by-line code coverage analysis without recompiling with such turned on, even with Java, because the bytecode simply doesn't contain that information.

>> 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.

The x86 processors have 4 rings of hardware protection built in. The idea is to do the isolation in hardware, not software, and it does work (one process crashing can't bring down another process). Where it fails is where Windows runs all processes at ring 0. This is a terrible design mistake. The CPU *is* designed to provide the sandboxing that a VM can provide. Also, as VMware has demonstrated, the virtualization of hardware can provide complete sandbox capability.

Another example of this sort of hardware sandboxing is if you run 16 bit DOS code under Windows. The virtualization software sets up a "DOS box" which is completely controlled by hardware, so any interrupts, I/O port instructions, etc., are intercepted by the hardware and transferred to software that decides what to do, whether to allow/deny, etc.

These capabilities are all there in the hardware. The fact that systems software often fails to use it is no more of a fundamental flaw than the fact that all the VM systems are so routinely compromised that people run their mail and browsers with scripting disabled.

Dave escribió:
> Tom wrote:
>> Mike Parker escribió:
>>> Tom wrote:
[...]
>>
>> I've seen no big games written in Java/C# (so I can't really hold a position on this ground). Though I've seen *A LOT* of server/client apps done in Java. The speed *IS* a concern, believe me. They ARE definitely slow in comparison to C/C++ apps.
>>
> 
> Ok, I know Perl is specialized for this type of thing (with many of the libs. written in C), but for small programs handling large chunks of data, Java has rarely been a consideration in the shops I've recently worked at. And believe me, it's not for lack of trying because it's easier to find decent Java hackers than good C or Perl hackers, IME.
> 
> I remember actually scripting something like:
> 
> if(file_size > X)
>   java -server -XmsY -XmxZ App
> else
>   java -client App
> 
> and having to experiment to set X, Y and Z, and Perl still worked better. What a PITA.
> 
> More of the same w/ .NET (speed critical stuff in native C++), although the .NET GC is very good and generally hard to beat with hand-crafted mem. mgmt. (again IME).

I love Perl, but once the project surpasses X lines of code (i.e. gets bigger enough), dynamic typing is just prohibitive.

C# seems "a little" faster than Java, though I didn't give it much of a chance yet. Then, if I had all the same advantages in D that I have with Java/C# (IDE, frameworks, libs, etc.), I would choose D without hesitation. ;)

Tom;
(Tomás Rossi)

Walter Bright wrote:
> Benji Smith wrote:
>> Actually, COM illustrates my point quite nicely...
> 
> Not if the language is designed to be COM-compatible from the start. You don't need a VM to inherit from IUnknown, create GUIDs, or do reference counting.
> 
> If you designed a language around COM, you'd get all that stuff for free, too. I agree that using COM in C++ is a bit clunky, but after all, C++ was designed before there was COM.

Aha. Very interesting point. I hadn't thought of that.

Is there such a language? Or is this just hypothetical?

>> 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.
> 
> Most debuggers are able to attach themselves to running processes. The CPU itself does contain specific hardware to support debugging.

Cool. I didn't know that.

> Many profilers are able to hook into executables that have symbolic debug info present (Intel's comes to mind). Reflection can be done natively - D will get there. Instrumentation - depends on what instrumentation is done. You can't do line-by-line code coverage analysis without recompiling with such turned on, even with Java, because the bytecode simply doesn't contain that information.
>
>> Natively-compiled code can't even *hope* to enforce that kind of isolation.
> 
> The x86 processors have 4 rings of hardware protection built in. The idea is to do the isolation in hardware, not software, and it does work (one process crashing can't bring down another process). Where it fails is where Windows runs all processes at ring 0. This is a terrible design mistake. The CPU *is* designed to provide the sandboxing that a VM can provide. Also, as VMware has demonstrated, the virtualization of hardware can provide complete sandbox capability.

Lots of great info. Thanks. I didn't know that the x86 had support for profiling, debugging, sandboxing, etc.

I'd actually argue, though, that these kinds of features are actually VM features, even if they have actually been implemented on silicon. Since these kinds of functions provide an outside observer with a view into the machine's internals, I think they're more naturally implemented in a virtual machine (and VMs will, no doubt, be the environments where the most interesting research is conducted into new techniques for profiling, debugging, instrumentation, etc).

If you want these kinds of meta-platform features baked into silicon, or solidified in your platform, you either need to wait twenty years for the market to prove their viability, or you can get them in next year's VM technologies.

--benji

PS: Keep in mind, I'm playing devil's advocate here, not because I have anything against compilation for a native platform, but because I think there are lots of interesting innovation in the VM universe that could be useful to D.

Benji Smith wrote:
> 
> Lots of great info. Thanks. I didn't know that the x86 had support for profiling, debugging, sandboxing, etc.
> 
> I'd actually argue, though, that these kinds of features are actually VM features, even if they have actually been implemented on silicon.

Since the name "virtual machine" implies the virtualization of a machine, it seems reasonable that a good VM would provide all the features normally found in a non-virtual (ie. real) machine.  Why should these features be offered only in software?  Particularly at a time where hardware support for VMs is being explicitly added to hardware to improve performance?


Sean

Sean Kelly wrote:
> Benji Smith wrote:
>>
>> Lots of great info. Thanks. I didn't know that the x86 had support for profiling, debugging, sandboxing, etc.
>>
>> I'd actually argue, though, that these kinds of features are actually VM features, even if they have actually been implemented on silicon.
> 
> Since the name "virtual machine" implies the virtualization of a machine, it seems reasonable that a good VM would provide all the features normally found in a non-virtual (ie. real) machine.  Why should these features be offered only in software?  Particularly at a time where hardware support for VMs is being explicitly added to hardware to improve performance?
> 
> 
> Sean

I agree. A good virtual machine will provide all of the features of a real machine. The opposite, though, is not necessarily true. A real machine doesn't necessarily provide all of the features of a typical virtual machine.

--benji