D vs VM-based platforms

Walter Bright newshound1 at digitalmars.com
Tue May 1 13:33:41 PDT 2007


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.



More information about the Digitalmars-d mailing list