Snapshot data memory managment

[jasssonpet]

This stops the debugger from crashing.

https://github.com/NativeScript/android-runtime/blob/3e6f6ea24b443805aa743b80bb434ab5df98f214/src/jni/include/v8.h#L5989-L5990

Related to: NativeScript/NativeScript#1563

Ping @atanasovg, @KristinaKoeva.

[atanasovg]

Looks good but this also means that we are keeping the whole blob in memory. I was thinking whether we should enable the snapshot in release builds only. What do you think?

[jasssonpet]

I think that enabling the snapshot in release mode only would be confusing for our users. My concerns are that they could would to edit the source code of the already snapshotted modules and that would make for an unlikely surprise when it comes time for releasing.

Also, enabling the snapshot in debug builds, would make apps start faster in debug mode and would make application development a bit faster and more pleasant. Users will be more likely to accept NativeScript if apps start faster in debug mode.

Another concern is that we could skip packaging the snapshotted modules in the npm plugin and that would make it's size smaller.

Having the same code path for both debug and release builds would also make testing easier and would catch more cases where something works in debug, but not in release mode.

My biggest concern, though, is that the runtime should be able to use snapshotted modules and debug just fine. The decision, whether to use the snapshot only in release should be decided in the CLI or the plugin, that provides the snapshot.

@atanasovg If memory is of an issue, I would suggest in researching memory-mapped files. Or maybe we could keep the snapshot data during the whole application lifecycle in debug config, but delete it once the V8 heap is initialized in release config. What do you think about that?

P.S. I've tested the embedded snapshot script with Node Inspector and it seems to work just fine, but the VS Code extension is not working properly and should be updated.

[ns-bot]

💚

[jasssonpet]

Closing this in favor of #425.