[View]  [Edit]  [Lock]  [References]  [Attachments]  [History]  [Home]  [Changes]  [Search]  [Help] 

[JSC] Avoiding the JSC bug (Jan 25, 2017)

Crash situations

  1. crash (or high execution times) are observed while compiling (parsing) smalltalk code to javascript.
  2. crash after reading contents of a file to memory using NSFileHandle

[Case 1] Issue during compilation of smalltalk code

The memory consumption was detected (using instruments implemented in coco8) while running naive s8 code during parsing simple expressions. The bug emerges when the parsing is repeated multiple times; it is easy to reproduce in devices with low memory free.

The bug has NOTHING to do with coco8 and happens using Safari in OSX, without any native interface; parsing normal smalltalk code using our default image. In safari/OSX the bug is observed as demanding +200 times for execution compared with Chrome in the same computer; and in cases of multiple executions the page is closed without any indication of the failure.

We suspect that the crashes we suffered are related with the following reports (we canīt guaranty that it is the same bug instance, the symptoms are the same; low level tools and iOS crash reports have failed to indicate any valuable information about the bug)
Bug 136772: Safari on iOS 8 crashes in JIT codeReported: 2014-09-11 22:53 PDT by Jason Parrott
Bug 139847: JavaScriptCore deeply nested "call" performance issueReported: 2014-12-19 16:51 PST by Mike Fikes
Bug 160027: Crash in JSC::speculationFromCellReported: 2016-07-21 09:52 PDT by Alejandro Reimondo

Using coco8 we have detected that the unsuspected grown of consumed memory occurred while executing simple RegExp objects to match simple characters from source stream!

Solution

The solution found to the issue was to avoid the emergence of bug removing uses of regular expressions.
We modified our compiler to use ONLY smalltalk code for parsing (removed uses of RegExp while parsing smalltalk code).

Results and tests

After removing RegExp we have NOT detected memory issues while parsing.
We tested recompiling multiple times the complete environment. All methods of all classes was recompiled without observing crashes.
The expression for testing wasObject recompileAll
NOte that execution of "Object recompileAll" is an operation that takes more than 3 hours to complete; and will need aprox 1Gb of free memory to run; so it should work OK on devices with 4Gb or more.

[Case 2] Reading contents of a file to memory using NSFileHandle

The test load a big string (an snapshot of the system) multiple times in a loop.
It has observed that a lot of memory was consumed and that goes to crash (memory issue) too fast. It was observed that there are NO references to old data but it is not garbage collected until memory is full, and when it goes to GC it crash in places where executing normal smalltalk code.

It has been observed that the issue occurs in low level implementation of conversion of NSData to NSString. The function is an user defined function (not a S8 nor coco8 core function) implemented in ObjectiveC. The NSSTring returned by the function remains in memory too long and it is not garbage collected when GC is triggered by JSC.

Solution

It has been solved forcing a JSC garbage collect just before converting from NSData to a new NSString; inside the user function.

Testing

The devices and configurations used for testing was