The Bytecode Alliance: Building a secure, composable future for WebAssembly

Re:The Bytecode Alliance: Building a secure, composable futu... by kllrnohj on Tuesday November 12, 2019 @02:29PM (#21517247)

Which means it can't free. But that's also not accurate, anyway, there's a brk() method to grow the heap. Which is such a bad starting point for a new runtime.

[ Parent | on HN ]

Re:The Bytecode Alliance: Building a secure, composable futu... by saagarjha on Tuesday November 12, 2019 @06:27PM (#21519394)

Would it be impossible to implement mmap and sbrk in the runtime?

[ Parent | on HN ]

Re:The Bytecode Alliance: Building a secure, composable futu... by kllrnohj on Tuesday November 12, 2019 @06:48PM (#21519525)

mmap is arguably the only thing it should have had in the first place. brk/sbrk is fairly dead.

[ Parent | on HN ]

Re:The Bytecode Alliance: Building a secure, composable futu... by saagarjha on Wednesday November 13, 2019 @04:47AM (#21522471)

  $ strace /bin/ls 2>&1 | grep brk
  brk(NULL)                               = 0x55fb032b3000
  brk(NULL)                               = 0x55fb032b3000
  brk(0x55fb032d4000)                     = 0x55fb032d4000

[ Parent | on HN ]

Re:The Bytecode Alliance: Building a secure, composable futu... by wahern on Wednesday November 13, 2019 @11:50PM (#21532881)

  $ ktrace /bin/ls >/dev/null
  $ kdump | grep brk | wc -l     
         0
  $ kdump | grep mmap | wc -l
       130

glibc, musl, and jemalloc got the memo, they just couldn't be bothered to stop using brk by default. They're all capable of using mmap exclusively, however, because whether or not brk is actually dead, there's long been consensus that mmap is the better abstraction on balance, particularly given the benefit of ASLR. So there's little reason to support brk instead of mmap for compatibility. Presumably it was chosen for the convenience of WebAssembly implementations--contiguous, flat memory is a great simplifier of VM, JIT, and even traditional AoT architectures.

[ Parent | on HN ]