D vs VM-based platforms

[Benji Smith]

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.