Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WAVM: standalone WebAssembly VM prototype

github.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: WAVM: standalone WebAssembly VM prototype

#21

Post by chrisseaton »

sspiff wrote: post #19
merb wrote: post #15

Earlier quoted context omitted.

> implement their own GC when that would be so easy, maybe. But especially on top of the browser restrictions that will be even harder.

Garbage collection is not magic. It's a fairly simple (but byzantine) matter of tracking references, and allocating and freeing memory. Why would this be so much harder for WebAssembly? Why can't existing garbage collectors be compiled to WA?

> Why can't existing garbage collectors be compiled to WA?

Yes I think that's the idea.

Re: WAVM: standalone WebAssembly VM prototype

#23

Post by ascheidecker »

fizzbatter wrote: post #22

Dumb question, but is the purpose of this to run WASM code (binaries/etc) in standalone? Ie, is Nodejs to Javascript as WAVM is to WASM?

Not exactly. Node.js will probably integrate a future release of V8 that supports WebAssembly, and WAVM isn't a suitable replacement for that.

WAVM is more like V8, but for WebAssembly only instead of both JavaScript and WebAssembly. The purpose is to serve as a simple VM for my programming language that compiles to WebAssembly.

Re: WAVM: standalone WebAssembly VM prototype

#24

Post by sievebrain »

slimsag wrote: post #2

Am I correct that WebAssembly is the first browser language VM (like JVM, Flash, etc) that is developed as a specification and not an implementation? If so, I wonder how security will fare in comparison to JVM/Flash/etc, I imagine it'll be much better. WebAssembly is gonna be huge, esp. with languages like Rust supporting it!

JVM's are a specification.

Re: WAVM: standalone WebAssembly VM prototype

#25

Post by sievebrain »

cm3 wrote: post #18

I haven't been following WebAssembly, but I've asked myself why, given the elevated level of security threats, there is not effort to design a safer, tinier, web page scripting system. I have the feeling that based on the experience we could streamline and simplify much of the web client stack to allow (1) safer implementations, (2) smaller implementations and (3) less interpretation of the standards.

Once upon a time Javascript was tiny.

Unfortunately, the web became the only app platform that was perceived as being politically neutral, and so there was huge pressure to add features to it. These features all hugely increased the complexity of HTML renderers, and with complexity came bugs.

Could you build a smaller, simpler, safer web? Sure. It's called HTML4.

Re: WAVM: standalone WebAssembly VM prototype

#26

Post by cm3 »

sievebrain wrote: post #25
cm3 wrote: post #18

I haven't been following WebAssembly, but I've asked myself why, given the elevated level of security threats, there is not effort to design a safer, tinier, web page scripting system. I have the feeling that based on the experience we could streamline and simplify much of the web client stack to allow (1) safer implementations, (2) smaller implementations and (3) less interpretation of the standards.

Once upon a time Javascript was tiny. Unfortunately, the web became the only app platform that was perceived as being politically neutral, and so there was huge pressure to add features to it. These features all hugely increased the complexity of HTML renderers, and with complexity came bugs. Could you build a smaller, simpler, safer web? Sure. It's called HTML4.

I get what you're saying, but what I meant is that it's surely possible to keep the current features while streamlining it into something coherent, much smaller, and easier to implement.

The modern web platform's bloat and what you can achieve with it always reminds me of 1990s demo scene mags on floppy disks and their mag engines. I think most of the problems stem from adding more stuff to HTML rather than taking what we build today building the smallest possible DSL and its engine around it. At some point we have to do a cut like that or we'll have browsers that'll have to support many, many HTML profiles and become monstrosities.

Re: WAVM: standalone WebAssembly VM prototype

#27

Post by vmorgulis »

cm3 wrote: post #26
sievebrain wrote: post #25

Earlier quoted context omitted.

Once upon a time Javascript was tiny. Unfortunately, the web became the only app platform that was perceived as being politically neutral, and so there was huge pressure to add features to it. These features all hugely increased the complexity of HTML renderers, and with complexity came bugs. Could you build a smaller, simpler, safer web? Sure. It's called HTML4.

I get what you're saying, but what I meant is that it's surely possible to keep the current features while streamlining it into something coherent, much smaller, and easier to implement. The modern web platform's bloat and what you can achieve with it always reminds me of 1990s demo scene mags on floppy disks and their mag engines. I think most of the problems stem from adding more stuff to HTML rather than taking wh…

I expect a reboot of the web with wasm.

As wasm defines a VM, the browser could become useless.

Re: WAVM: standalone WebAssembly VM prototype

#28

Post by sspiff »

chrisseaton wrote: post #21
sspiff wrote: post #19

Earlier quoted context omitted.

Garbage collection is not magic. It's a fairly simple (but byzantine) matter of tracking references, and allocating and freeing memory. Why would this be so much harder for WebAssembly? Why can't existing garbage collectors be compiled to WA?

> Why can't existing garbage collectors be compiled to WA? Yes I think that's the idea.

Exactly. From what I've seen of WebAsm, you can request pages of memory using grow_memory. Upon this, you could implement a memory pool system to handle malloc and free. Using this, it is trivial to port existing GC's.

I don't understand why people moan about GC in WebAsm. WebAsm is a compiler target for lower level languages, not the JVM.

Re: WAVM: standalone WebAssembly VM prototype

#29

Post by cm3 »

vmorgulis wrote: post #27
cm3 wrote: post #26

Earlier quoted context omitted.

I get what you're saying, but what I meant is that it's surely possible to keep the current features while streamlining it into something coherent, much smaller, and easier to implement. The modern web platform's bloat and what you can achieve with it always reminds me of 1990s demo scene mags on floppy disks and their mag engines. I think most of the problems stem from adding more stuff to HTML rather than taking wh…

I expect a reboot of the web with wasm. As wasm defines a VM, the browser could become useless.

Given how single page web sites are more or less like Flash in that they don't follow the document model anymore, maybe it's for the best, giving real web pages a chance to revive an effort like XHTML and get us document standards.

Re: WAVM: standalone WebAssembly VM prototype

#30

Post by wrmsr »

cm3 wrote: post #18

I haven't been following WebAssembly, but I've asked myself why, given the elevated level of security threats, there is not effort to design a safer, tinier, web page scripting system. I have the feeling that based on the experience we could streamline and simplify much of the web client stack to allow (1) safer implementations, (2) smaller implementations and (3) less interpretation of the standards.

  in my mind, as it is aimed at replacing the sprawling forests of javascript
  many pages are powered by, wasm pretty clearly addresses your three
  points. with wasm web applications delivered to browsers can be written in
  c++, rust, haskell, whatever, and compiled and linked and optimized and
  profiled and reoptimized on developer machines before deployment to end
  users. the result of this is that performant applications won't require as
  much (or any) runtime optimization like javascript engines necessarily do now:
  
  - arbitrarily dynamic code needn't be jitted and traced and rejitted to raw
    machine code at runtime
  - object structure needn't be inferred and shared and monitored and reshaped
  - primitive types don't have to be inferred and guarded
  - functions needn't be inlined and guarded because they are all dynamically
    bound
  - objects needn't be tracked and freed and moved around
  - javascript is weird and irregular. half a point here but just look at the
    equality table.
  
  you can say that 'well formed' javascript eases the pain on these poor beasts
  but they still have to strive to support as much of the common language as
  they can, no matter how awful, because it's their job. wasm has to do exactly
  none of this:
  
  - jitting can occur once, at load, statically like the CLR not dynamically
    like HotSpot or luajit as inlining happened on some jenkins box somewhere.
  - there are no objects, there are four types and they're all 4 or 8 byte
    primitives and if you need a gc you baked it into your binary. no vm-level
    object or allocation headers, no gc-related finalizer bugs.
  - desugared there's about 20 instructions (expressions). implement those and
    you've implemented webassembly. standard lib? that was compiled into the
    binary*.
  
  because there's so much less to its job it will be safer, smaller, and more
  widely consistent than javascript. it's still young and definitely not without
  its warts but these three points are home runs.
  
  * ..ish, but it's definitely more spartan:
      https://webassembly.github.io/demo/AngryBots/Release/AngryBots.js
    ... that'll buff out :p

  edit: wow i suck at HN formatting
Post reply on HN