I'd love to see the topics of soft-realtime and lightweight threads addressed.
The Inevitable Death of VMs: A Progress Report [pdf]
21–27 of 27 posts
Re: The Inevitable Death of VMs: A Progress Report [pdf]
#22Interesting that the author makes no mention of CLR, Microsoft’s attempt at the same thing which has been around for 20 years.
True that the CLR is not mentioned by name, but it is covered. I invite you to read the text again, and especially the following bit. "Specifically, we should aspire to package language implementations in a way that renounces ‘one true VM’, instead allowing first-class interoperability with the host environment (perhaps at modest drop in performance), the same interoperability with other VMs past and present, and too…
Surely it was an _attempt_ at all these things, it just didn’t work out.
For instance, I remember controversy that new Windows APIs would only be accessible via .Net.
Re: The Inevitable Death of VMs: A Progress Report [pdf]
#23tl;dr this is a two page description of Stephen Kell's liballocs library [0]. Basically, it's wasteful to install jvm, python interpreter, and electron. He's advocating that new languages use (u)nix infrastructure (processes, files, etc) as much as possible. His library is supposed to assist with this by providing process level gc. It provides a hierarchal view such that a caller allocates objects, rather than flat m…
I personally disagree. The differences between the language specific is high enough that a fully general VM is impossible without also incurring all the downsides of a language specific VM. Python and Java each have a distinct standard library. The end result will be that you have to install 'supervm-java-std' and 'supervm-python-std' instead of openjdk and cpython. JVMs tend to be very memory heavy in exchange for higher performance for java code, whereas the python interpreter is slow but more memory efficient because it relies on C code to accelerate CPU and memory intensive applications.
Re: The Inevitable Death of VMs: A Progress Report [pdf]
#24Earlier quoted context omitted.
I'd also add that I believe the usage in the title here is a little obscure -- I think almost any generalist programmer (i.e., not someone who exclusively works in program language VMs or in system VMs) would assume "VM" refers to a system-level virtual machine. At one point I interacted with the JVM and its quirks on a daily basis, and I never started referring to it as "the VM", it was always "the JVM". I suspect i…
The usage has changed over time. Go back 15 years, and I'd expect people would more commonly associated "VM" with the language VM. Of course, that historical development fits well with the high-level claims made in the paper.
Agreed. There was a time where the system-level virtualizer was "the hypervisor", but I was still in school then. ;)
Re: The Inevitable Death of VMs: A Progress Report [pdf]
#25tl;dr this is a two page description of Stephen Kell's liballocs library [0]. Basically, it's wasteful to install jvm, python interpreter, and electron. He's advocating that new languages use (u)nix infrastructure (processes, files, etc) as much as possible. His library is supposed to assist with this by providing process level gc. It provides a hierarchal view such that a caller allocates objects, rather than flat m…
I personally disagree. The differences between the language specific is high enough that a fully general VM is impossible without also incurring all the downsides of a language specific VM. Python and Java each have a distinct standard library. The end result will be that you have to install 'supervm-java-std' and 'supervm-python-std' instead of openjdk and cpython. JVMs tend to be very memory heavy in exchange for h…
Not sure whether you're disagreeing with the paper or the commenter's summary of it. As you could probably guess from the title of the paper, the goal is not a new "fully general" VM.
An analogy I sometimes use is pre-IP internetworking. If you wanted a new cross-network application, then of course you could in principle build application-layer gateways, but the economics simply didn't work. It took a carefully engineered "hourglass waist" to fix the economics. The goal is to create the equivalent for language implementations. And the whole point is that "one super-VM" is not the recipe.
Re: The Inevitable Death of VMs: A Progress Report [pdf]
#26Earlier quoted context omitted.
In all fairness to the author, casually maintaining any major changes to V8 or Chrome for more than a month is borderline impossible. The whole codebase undergoes massive churn on a release-to-release basis. There are projects like LibCEF that have the rug pulled out from under them every release or two because some major subsystem got completely overhauled. So, the difficulty of maintaining the v8 changes is kind of…
Thanks! Indeed I should have said "no more difficult to maintain than V8 in general... i.e. well beyond a researcher's means".
Ah, that makes sense.
"V8 changes such that alterations in general are difficult to maintain."
Re: The Inevitable Death of VMs: A Progress Report [pdf]
#27Earlier quoted context omitted.
> As an alternative view Is that really an alternative view? In a liballocs world some large part of the problems Cliff Click describes would be solved; everything is 'native' and playing by the same rules. The 'foreign' part of FFI would have no meaning. The cynic in me wonders what value liballocs delivers that is so compelling as to motivate many disparate systems to adopt it. People are entirely content to muddle…
Good question. I agree that endless muddling has shown remarkable mileage. liballocs is not quite there yet, but is progressing (er, when I get time, which is not often enough). Beyond that, adoption is cultural. We need to build a killer "added value" in one environment which makes enough waves that everyone else wants it. We're creeping closer... with Guillaume Bertholon we have made an initial "FFI-less" for CPyth…
Thanks for pointing out this paper.