feat(bridge): Provide automatic garbage collection triggering #1060
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mbektchiev
force-pushed
the
bektchiev/auto-gc
branch
2 times, most recently
from
368d7f7
to
b5e6a71
Compare
Introduce settings similar to the ones in {N} Android Runtime for
configuring automatic GC triggering by the runtime. They are
specified in `app/package.json` as values in the `ios` section:
* `gcThrottleTime` - number of milliseconds which must have passed
since the last automatic GC in order to trigger one during a call from
JS to native
* `memoryCheckInterval` - number of milliseconds which must have
passed since the last automatic GC in order to check the memory
usage on the device and trigger GC if free memory is below the specified
threshold
* `freeMemoryRatio` - a floating-point value from 0 to 1 which sets the
threshold below which a GC will be triggered when the above check is made.
implements #1035
Runtime's stability is compromised when automatic GC triggering is set to a very small interval (e.g. 1 ms). It turns out that if a GC passes between the moment when an object is created and it's assigned to a variable, it can get destroyed prematurely. In order to avoid it we have to keep such objects as `Strong` references.
…xception In such cases the memory holding the result is uninitialized and reading it could crash the application.
In `TNSArrayAdapter`'s `countByEnumeratingWithState` we need to obtain a JS engine lock before accessing properties of the JS array(-like) object.
…n change Make additional stamp files for LLIntAssembly.h per configuration It seems like changing the build configuration also needs to regenerate the low level interpreter. If it's not regenerated we receive a linker error.
Set the automatic triggering period to 5 ms to keep the runtime and it's tests working correctly with frequent GCs. If sporadic crashes related to GCs start happening we may set this value to something significantly lower (e.g. 1 ns = `1e-6` ms) to instruct the runtime to trigger a new GC on each native call. This isn't the default value because it significantly degrades performance.
Temporary ObjectiveC objects which are created during marshalling are autorelease-d. This means that they are destroyed when the nearest autorelease pool is drained. Due to the refactoring in this PR, the racing condition between the JS calling thread for destroying them and the worker thread using them when performing the method call is won by the JS thread. To fix this we now marshal the arguments in the worker thread and reject the promise if something goes wrong instead of doing it synchronously and throwing an exception.
mbektchiev
force-pushed
the
bektchiev/auto-gc
branch
from
d44e2a5
to
30bcaca
Compare
tdermendjiev
approved these changes
Jan 17, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce settings similar to the ones in {N} Android Runtime for
configuring automatic GC triggering by the runtime. They are
specified in
app/package.jsonas values in theiossection:gcThrottleTime- number of milliseconds which must have passedsince the last automatic GC in order to trigger one during a call from
JS to native
memoryCheckInterval- number of milliseconds which must havepassed since the last automatic GC in order to check the memory
usage on the device and trigger GC if free memory is below the specified
threshold
freeMemoryRatio- a floating-point value from 0 to 1 which sets thethreshold below which a GC will be triggered when the above check is made.
After implementing the feature we faced a number of different bugs leading to random
crashes after a GC has run. The fixes are included in this PR as separate commits:
PR Checklist
Implements #1035