D vs VM-based platforms

Benji Smith dlanguage at benjismith.net
Tue May 1 05:33:38 PDT 2007


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



More information about the Digitalmars-d mailing list