4 ms·

tl;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 ad

by Nzen 7y ago

tl;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 memory. I don't know enough to have an opinion on this. As an alterntative view, consider listening to Cliff Click describe the challenge the jvm faced when it had a more permissive ffi [1]. [0] https://github.com/stephenrkell/liballocs https://github.com/stephenrkell/liballocs [1] https://www.youtube.com/watch?v=LoyBTqkSkZk https://www.youtube.com/watch?v=LoyBTqkSkZk

topspin 7y ago
> 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 endlessly; inefficiencies and unnecessary complexity are usually deemed not worth fixing until they register as high costs.
- stephenrkell 7y ago
  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 CPython which I think could be the beginnings of that kind of killer addition. You might like to read our workshop paper about that, which I've just made available: https://www.cs.kent.ac.uk/people/staff/srk21/#vmil19 https://www.cs.kent.ac.uk/people/staff/srk21/#vmil19
  - topspin 7y ago
    Thanks for pointing out this paper.
imtringued 7y ago
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.
- stephenrkell 7y ago
  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.

by Nzen 7y ago

topspin 7y ago

> 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 endlessly; inefficiencies and unnecessary complexity are usually deemed not worth fixing until they register as high costs.

stephenrkell 7y ago
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 CPython which I think could be the beginnings of that kind of killer addition. You might like to read our workshop paper about that, which I've just made available: https://www.cs.kent.ac.uk/people/staff/srk21/#vmil19 https://www.cs.kent.ac.uk/people/staff/srk21/#vmil19
- topspin 7y ago
  Thanks for pointing out this paper.

imtringued 7y ago

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.

stephenrkell 7y ago
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.