Stack overflows #652
Comments
|
Browser / node information is crucial here as SO behavior is very sensible to a particular JS optimizer. One trick you can try in Dev Chrome is to "warm" the optimizer up. That is to say, try to execute such function a few times, after 2/3 stack overflows the browser may re-optimize and the problem may be disappear. [A gross hack, I know] |
|
I'm on Chromium, Version 64.0.3282.167 (Official Build) Built on Ubuntu , running on LinuxMint 18.1 (64-bit). I think the main issue is the frame size: the call stacks are not deep: |
|
In that browser you may try enabling I don't follow V8 dev closely anymore so I dunno what |
|
Thanks. I just tried in Firefox, and the problem exists there too. |
|
In the end, the only way I've managed to get around these problems in a reliable way is to run the code in the main thread. Even if V8 developers told me otherwise, the main thread gets a way better stack treatment than workers. But at some point, using the above flags, I could run using workers pretty well. |
|
Hmm, I see. I'm not excited about running the code in the main thread :/ |
|
Your point about re-running is correct, though: I only get a stack overflow the first time... |
Neither I am.
Yup, I don't start Coq until all the required files have been downloaded.
Glad to hear it doesn't only happen to me. So I have been tracking browser performance since Chrome 40 and indeed it is very hard, a fast-moving target. It doesn't help that plans for tail-call optimization in JS are so messed up [with Google advocating to optimize only if annotated]. I dunno what more it can be done, it would be great to know how to improve the warm up routine, but I didn't get something that I like. Maybe you may have some luck asking in SO about SO, people such as Andreas Rossberg used to be there!! |
I see :/
Thing is, I really don't think it's a tail call issue: the calls aren't actually tail-recursive, but that shouldn't be too bad, since there's fairly few of them.. The problem seems to be large stack frames more than many calls. |
|
Maybe, last time I investigated a bit more problems like this tail-call had some effect, [Andrew also thought like that] but yeah, who knows, my understanding is that stack size in workers was static so difference in behavior has to be due to JIT. |
|
Yuck, yuck, yuck. |
|
This seems a dead-end, yuck yuck, however, how would https://github.com/sebmarkbage/ocamlrun-wasm fare ? |
|
Not sure. I don't think that there was much effort there in integrating with system libraries, so I don't know how that would work (files in particular) Js_of_OCaml is still pretty unique. |
|
Another relevant source: https://mozakai.blogspot.com/2013/08/outlining-workaround-for-jits-and-big.html |
@cpitclaudel, can you point to code you're compiling and its generated code ? |
|
Absolutely :) I'm working on compiling the F* proof assistant. The setup to compile it is here: https://github.com/cpitclaudel/fstar.js The actual OCaml code that gets compiled (and the problematic function) is here https://github.com/FStarLang/FStar/blob/d678ab35b751adeb843264cbc3da8b30851cb22b/src/ocaml-output/FStar_TypeChecker_Normalize.ml#L3709 and here https://github.com/FStarLang/FStar/blob/d678ab35b751adeb843264cbc3da8b30851cb22b/src/ocaml-output/FStar_TypeChecker_Normalize.ml#L7133 I've uploaded a copy of the generated code here https://gist.github.com/cpitclaudel/2da7d62be9242d3099b129ba23cbb84a. The interesting function are this: and that: The OCaml code is already the result of extracting F* code, so a more readable version is at https://github.com/FStarLang/FStar/blob/d678ab35b751adeb843264cbc3da8b30851cb22b/src/typechecker/FStar.TypeChecker.Normalize.fs#L1012 and https://github.com/FStarLang/FStar/blob/d678ab35b751adeb843264cbc3da8b30851cb22b/src/typechecker/FStar.TypeChecker.Normalize.fs#L2056 Let me know if I can help diagnose this (for example, I could share the bytecode files — this is all very much work in progress… sorry if things aren't the simplest to run / compile). One experience I've had with compiling CVC4 with emscripten is that Chrome and FF are both very sensitive to excessive function size, making Emscripten's outlining optimization extremely useful. |
|
just curious, have you tried disabling inlining ? (with |
|
I think so, once (IIRC, I disabled all optimizations); let me try it again :) |
|
By the way @cpitclaudel what method are you using to get call stacks in the |
|
what "usual trick" are you talking about ? |
|
Setting a breakpoint inside Before I tried #410 but may I did not understand well. |
|
I disable all error catching in my program, and then I inspect the error in chrome's debugger. In bad cases, I put console.trace in the function that I suspect is causing issues. |
|
I see, thanks. I have started to use a very similar method [adding Anyways, stack traces for Coq don't look very interesting, lots of very simple calls mixed with a couple of large closures. In 8.9 these large closures will go away so we will see if that has an effect. |
|
There is a way to attach js stacktraces to ocaml exceptions. It would not work for stackoverflow yet though. I'll try to come back with an example soon. |
It doesn't seem to make a difference — I get stack overflows in the same places. |
Both Chrome and Firefox tend to overflow the stack on the first run. ocsigen/js_of_ocaml#652.
|
The new cps compilation mode used for ocaml 5.0 effects might help. ( |
|
reopen if you still have issues |
Hi there,
I 'm compiling a fairly large set of mutually recursive functions (~1k lines). The resulting javascript is a large (~3k lines) function. I'm running into stack overflows, although the same bytecode requires very little stack (it starts overflowing when I reduce the stack size to 25kB, but it works fine at e.g. 50kB).
Is there anything I should look into, specifically? Any optimizations I should disable, or enable? The problem happens both with the default settings and with
--opt 3Thanks.
The text was updated successfully, but these errors were encountered: