Lazy objects v0 for raw objects

[jeffreytan81]

Release Note: introduce lazy objects feature for raw objects in Prepack.
Introduce lazy objects feature for raw objects in Prepack with supported runtime.
Lazy object is a collaboration feature between the Prepack and new runtime that supports this feature. With this feature, object can be created with a special LazyObjectsRuntime.createLazyObject() API. The object created with this API can be a light-weight placeholder object. Once the lazy object is touched/used the first time, runtime is responsible to callback the registered initialization function to hydrate the object into a real object.
By doing this we will save both memory and object creation speed.

Currently, Prepack only supports lazy for raw objects.

The APIs that runtime needs to support:

1. LazyObjectsRuntime.createLazyObject(<lazy_object_id>);
2. LazyObjectsRuntime.setLazyObjectInitializer().

Under lazy objects mode, Prepack will serialize all lazy objects into two parts:

1. All lazy objects are created via lightweight LazyObjectsRuntime.createLazyObject() call.
2. Lazy objects' property assignments are delayed in a callback function which is registered with the runtime.

TODO:

1. Test-runner support for lazy mode.
2. Support more object types for this feature
3. Remove "reference count === 1" objects' root and directly serialize into callback function.
4. Figure out "reference count > 1" objects that are safe to remove root from global anonymous function and directly serialize into callback function.

Test Plan:

1. "bin/prepack.js <foo.js> --lazyObjectsRuntime LazyObjectRuntime"
2. test-runner introduced a lazy mode(later PR) can successfully run all tests.

[NTillmann]

I'd prefer !== undefined

[NTillmann]

Why did you remove this invariant?

[jeffreytan81]

This is a redundant invariant from previous checkin.
In "_serializeAbstractValue()" function, there is already same invariant.

[NTillmann]

void | ObjectValue. No need to allow two kinds of undefinedness.

[NTillmann]

The approach with the subclass is quite beautiful! And for a v0 it looks very solid :-)

Long term, I see an issue with the subclass approach when it comes to combining features, such as delayed initialization and lazy objects. Switching to the getTarget later might require re-architecting the modularity approach.

In any case, great work for the v0!

[facebook-github-bot]

@yinghuitan is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.