[E8] Concecuences of the JSC parse issue while runnning coco8 applications
The S8 Compiler emit code patters using functions for
most expressions using block closures
So.. the use of deep nested expressions with this shapes increases severely the risk of bug emergence.
The S8 Compiler trigger the bug condition because there are multiple methods written with nested blocks (see e.g. SmalltalkParser>>#methodParserParts and others), so the sole inclusion of Compiler in the image put the system in risk.
The dynamic loading of methods with nested blocks increases the risk of bug emergence (long time -minutes- after loading).
The bug appears in all platforms using JSC (we checked using jscocoa/coco8, native script, react native, with and w/o s8 environment)
Symptoms of the bug emergence
The parsing of nested functions in JSC consumes a lot of memory (and time) and leaving the object memory corrupted. The evaluation of nested functions runs OK.
If the device has enough memory to compile the script (containing nested functions) execution continues without any indication that the bug has been instantiated.
There are times where there are crashes later in the execution of the system when the garbage collector run when memory are near to fill memory of the device. This evidence is shown by xcode, but it is not reproducible, because the crash happens in different points of execution later in time, and depending on the memory use pattern of the application.
If a garbage collection is forced to happen by JSC API, the garbage collection finishes without crash (the corruption is removed by GC?). As we canīt predict the emergence of the bug, we canīt force a garbage collection to prevent the crash during GC.
When the bug has been instantiated, the crash can happen minutes later, depending on the policy in the VM activating the (incremental) GC.
When the object space is full (there are memory to reclaim by the GC) the parsing of nested functions cause a crash. NO crash report has been found in the device in this cases and XCode debugger use to report a text saying "Memory issue has happened" without any other information about the crash.
We infer, from our observations, that the parser use object memory and do not enter the GC procedure in this cases; causing the system to crash.
each level of nesting consumes much more memory
if memory becomes full during parsing, a crash will happen ("memory issue has happened")
if memory is not full, the execution continues, but with corrupted object space
a crash happen when collecting garbage of a corrupted object space (at any point in time during the execution of the system, e.g. during assignment to a local variable, just entering a method, etc)
evaluating nested functions works OK
Preventive calls to force GC prevent crashes but it is not possible to know when we need to GC