Clean up and optimize sbrk() (#12222)

After we no longer include malloc/free by default (#12213) we can remove the
hack in sbrk which avoided using static memory. This gives some nice code
size improvements.

However this can't be as simple as we'd hope because of dynamic linking
plus SAFE_HEAP. In that mode we may try to use sbrk_val before the
dynamic linker has set it up. This is because SAFE_HEAP is not aware of
dynamic linking - it just instruments all loads and stores, period, including
ones that happen during dynamic linking startup. To avoid ordering issues
there, initialize sbrk_val manually.

Author: kripken

system/lib/sbrk.c

@@ -29,25 +29,17 @@
 #define SET_ERRNO()
 #endif
 
-// FIXME just use  = &sbrk_val  here. That is simpler, but currently it has a
-// code size cost for tiny programs that don't use malloc. We link in malloc by
-// default, and depend on metadce to remove it when not used, which we can do,
-// but a static assignment here would mean a nonzero value in a memory segment,
-// which metadce cannot remove (it can remove code, but not data in segments).
-// The current code allows tiny programs without malloc to have no data segments
-// at all, while programs that use malloc may suffer a few more bytes of code
-// size, but that's negligible compared to malloc itself.
-// TODO: when we stop including malloc by default we can use the simpler way.
-static intptr_t sbrk_val = 0;
+extern size_t __heap_base;
+
+static intptr_t sbrk_val = (intptr_t)&__heap_base;
 
 intptr_t* emscripten_get_sbrk_ptr() {
-  extern size_t __heap_base;
-  intptr_t* sbrk_ptr = &sbrk_val;
-#if __EMSCRIPTEN_PTHREADS__
-  if (__c11_atomic_load((_Atomic(intptr_t)*)sbrk_ptr, __ATOMIC_SEQ_CST) == 0) {
-    __c11_atomic_store((_Atomic(intptr_t)*)sbrk_ptr, (intptr_t)&__heap_base, __ATOMIC_SEQ_CST);
-  }
-#else
+#ifdef __PIC__
+  // In relocatable code we may call emscripten_get_sbrk_ptr() during startup,
+  // potentially *before* the setup of the dynamically-linked __heap_base, when
+  // using SAFE_HEAP. (SAFE_HEAP instruments *all* memory accesses, so even the
+  // code doing dynamic linking itself ends up instrumented, which is why we can
+  // get such an instrumented call before sbrk_val has its proper value.)
   if (sbrk_val == 0) {
     sbrk_val = (intptr_t)&__heap_base;
   }

tests/code_size/hello_webgl2_wasm.json

@@ -3,8 +3,8 @@
   "a.html.gz": 377,
   "a.js": 5035,
   "a.js.gz": 2395,
-  "a.wasm": 10910,
-  "a.wasm.gz": 6928,
-  "total": 16508,
-  "total_gz": 9700
+  "a.wasm": 10891,
+  "a.wasm.gz": 6915,
+  "total": 16489,
+  "total_gz": 9687
 }

tests/code_size/hello_webgl2_wasm2js.json

@@ -1,10 +1,10 @@
 {
   "a.html": 588,
   "a.html.gz": 386,
-  "a.js": 22128,
-  "a.js.gz": 8459,
-  "a.mem": 3168,
-  "a.mem.gz": 2711,
-  "total": 25884,
-  "total_gz": 11556
+  "a.js": 22091,
+  "a.js.gz": 8449,
+  "a.mem": 3171,
+  "a.mem.gz": 2715,
+  "total": 25850,
+  "total_gz": 11550
 }

tests/code_size/hello_webgl_wasm.json

@@ -3,8 +3,8 @@
   "a.html.gz": 377,
   "a.js": 4519,
   "a.js.gz": 2219,
-  "a.wasm": 10910,
-  "a.wasm.gz": 6928,
-  "total": 15992,
-  "total_gz": 9524
+  "a.wasm": 10891,
+  "a.wasm.gz": 6915,
+  "total": 15973,
+  "total_gz": 9511
 }

tests/code_size/hello_webgl_wasm2js.json

@@ -1,10 +1,10 @@
 {
   "a.html": 588,
   "a.html.gz": 386,
-  "a.js": 21617,
-  "a.js.gz": 8297,
-  "a.mem": 3168,
-  "a.mem.gz": 2711,
-  "total": 25373,
-  "total_gz": 11394
+  "a.js": 21580,
+  "a.js.gz": 8289,
+  "a.mem": 3171,
+  "a.mem.gz": 2715,
+  "total": 25339,
+  "total_gz": 11390
 }