TiDB in Webassembly crashes in some mobile browsers

[5kbpers]

Bug Report

TiDB in Webassembly(#13069) always gets stuck and even crash in some mobile browsers(iOS Safari, Android Chrome, etc.).
In my iOS13.2:

[5kbpers]

Seems in Go1.12, the runtime will allocate 1GB initial memory (see golang/go#27462). So I tried with Go1.13 and set initialSize to 64MB(see golang/go#34395), the initial memory finally changed to about 100MB, but it still cannot work in iOS Safari(see the error above).

[siddontang]

@5kbpers you also adjust the mac proc number to 1, and it still can't work on mobile phone, right?

[siddontang]

do you have any idea? @syrusakbary

[siddontang]

Use https://github.com/rustwasm/twiggy, I find most of the size is occupied by the data section, but I have no idea which static var uses so large size.

twiggy top -n 10 main.css
 Shallow Bytes │ Shallow % │ Item
───────────────┼───────────┼────────────────────────────────────────
      14461356 ┊    18.59% ┊ data[99993]
      10291671 ┊    13.23% ┊ data[99997]
       4152701 ┊     5.34% ┊ data[99998]
       2861120 ┊     3.68% ┊ "function names" subsection
        999248 ┊     1.28% ┊ github.com_pingcap_parser.yyParse
        528491 ┊     0.68% ┊ data[43154]
        401922 ┊     0.52% ┊ data[99999]

[siddontang]

Through wasm-objdump -j data -x main.css, I find the data section 99997 is below, still hard to know the data.

- segment[99997] size=10291660 - init i32=22910259
  - 15d9533: 1000 0000 00f0 920b 0000 0000 0000 0001  ................
  - 15d9543: 1000 0000 0028 930b 0000 0000 0000 0002  .....(..........
  - 15d9553: 1000 0000 0050 940b 0000 0000 0000 0003  .....P..........
  - 15d9563: 1000 0000 00b8 940b 0000 0000 0000 0004  ................
  - 15d9573: 1000 0000 0010 950b 0000 0000 0000 0005  ................
  - 15d9583: 1000 0000 0060 950b 0000 0000 0000 0006  .....`..........
  - 15d9593: 1000 0000 00d0 950b 0000 0000 0000 0007  ................
  - 15d95a3: 1000 0000 0028 960b 0000 0000 0000 0008  .....(..........
  - 15d95b3: 1000 0000 00a0 960b 0000 0000 0000 0009  ................
  - 15d95c3: 1000 0000 0018 970b 0000 0000 0000 000a  ................
  - 15d95d3: 1000 0000 0070 970b 0000 0000 0000 000b  .....p..........
  - 15d95e3: 1000 0000 00c8 970b 0000 0000 0000 000c  ................

[lucklove]

The expression module take too much place

[siddontang]

BTW, for goweight: https://github.com/jondot/goweight

refer to https://medium.com/@jondot/a-story-of-a-fat-go-binary-20edc6549b97#.bzaq4nol0

[siddontang]

I am so surprised that Wasm needs some dependencies like etcdserverpb, debugpb, etc. IMO, if we only use a standalone TiDB, we should not depend on these.

I think we need to refactor the code now.

[siddontang]

We should remove the etcd and TiKV dependence when we only use a standalone TiDB.
PTAL @winkyao

[lucklove]

I have tested with a large binary generated the following code:

package main

import (
        "fmt"
        "syscall/js"
)

func main() {
        fmt.Println(len(xs))
        js.Global().Get("document").Call("write", "Hello, world")
}

var xs []int = []int{
        0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
        0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
        0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
        // many lines copy and paste from above
}

It can work in phone browser when the binary is 170MB. So I think it's not related to the bianry size.

And I execute download, compilation, and initialization operations independently. I found that when I try to compile tidb's binary, the phone browser crashes, and the adb message is:

It seems the chrome run out of memory when compile WebAssembly binary code.

[lucklove]

BTW, the firefox works well:

And the chrome will crash:

[lucklove]

Closing this issue since there is no good way to solve chrome crashing. If there is any opportunity we can reopen this again.

[frank-dspeed]

via the graalvm language research framework i found out that compiling stuff with a lot of so called Nodes where every function call is a node causes such problems.

there is at present a magic number of 40 000 nodes that can safe get compiled

[lucklove]

@frank-dspeed Thanks for letting us know this! And do you know is there any good way to work around this? We have been plagued by this problem all the time.

[frank-dspeed]

@lucklove splitting it up into independent wasm is the way to go and then reuse them

[frank-dspeed]

wasm needs an overall more modular coding style and mindset you will never want to compile an application to wasm you want to support all functions of the application as wasm so you can, for example, include them inside node.js + wasi to have a high-level language to use them and do efficient prototyping.

this will also lead to being so modular that we can improve even a single sorting algo via replacing a single wasm in the stack.

[frank-dspeed]

I have for example at present the idea to expose many data structures as wasm and a way to access them so you can create them like objects with a fixed size and operate efficiently on them.

others are going the same way already https://unpkg.com/browse/merkle-tree-wasm@0.1.1/merkle_tree_wasm.js

I would code more of the interface inside the wasm and expose a more friendly API but this shows where it goes.

I am also looking only for that into tikv and tidb i want to make the functionality useable as was modules so that I can do coprocessing on the data where the data is :) my response to universal grid computing my research showed that this is the best we can archive today.

i want feature parity with apache ignite inside the wasm universe :)

[Zireael07]

The parent issue to this was closed as frozen. This one is also closed, but without any info whether it's still an issue or not?

[frank-dspeed]

@Zireael07 it is a issue that can not get fixed lets call it upstream issues nothing can be done at present inside here!