This is very similar to bug 1066759. With --no-ion, this script eventually runs to completion. With ion enabled, it takes longer to print the first output ("create table : took 603 ms" vs "create table : took 319 ms"), and then is terminated by the OOM killer halfway through execution.

Given that both scripts are very large, poorly optimized Emscripten'd versions of sqlite3, it seems pretty likely that they're the same issue. Indeed, in both cases we OOM while ion-building "sqlite3VdbeExec", which is 176K of bytecode, has 5000+ locals and args, and has at least 150 inlineable call sites. This function appears to be the interpreter for sqlite3's internal virtual machine: [https://github.com/smparkes/sqlite/blob/8caf9219240123fbe6cff67b1e0da778c62d7621/src/vdbe.c#L546](over 5000 lines of C).

In bug 886957, bhackett said:

Per the formula in bug 807464 comment 3 a script of length 100000 should take a bit less than a second to compile, which isn't bad and of course can be canceled by the main thread when necessary.

In this case, it is not possible for the main thread to cancel the compilation, because we OOM during IonBuilder itself, and haven't moved the compilation off-thread yet.

We used to have a size limit for off-thread compiles (that would be checked before we started IonBuilder) but we removed it in bug 1010417.

I don't know how often we hit this issue in the wild. I hope it is rarely. If we are interested in improving IonBuilder's performance, though, it might be worth digging into this a little deeper; we've obviously run into some part of IonBuilder that doesn't scale linearly.