Feature Inquiry: WeakRef proposal intent?

[rwaldron]

@phoddie I'm wondering what your plans are for WeakRefs? I recognize that it may be too soon to make that decision, which I will gladly accept as an answer to my question :)

[phoddie]

@rwaldron - We have been tracking WeakRef since we first joined TC39. Mark Miller and Dean Tribble introduced us to the work on WeakRef at that time We have yet to identify a place to apply it to our work that has a significant benefit. Consequently, we haven't been in a rush to implement it. Now that it has achieved Stage 3, it makes sense to take another look. Any particular reason for asking?

[rwaldron]

Any particular reason for asking?

Yes! I'm trying to determine if we need to extend the $262 host API to include a $262.gc() function for the purpose of testing the semantics of WeakRef (tc39/eshost#83)

[erights]

Obviously, a conforming engine is under no obligation to give us a gc() operation. That said, for platforms that do, it can be useful for the tests to call it. However is has no guarantees, and so isn't really any different than not calling it wrt required behavior.

[phoddie]

The XS engine provides a C API to control the garbage collector. That is not usually exposed to scripts. The debug module implements a gc API to turn the GC on/off and to collect. That is documented here. So, there's no problem to add a gc trigger to our test262 harness. If it would help, we can do that sooner than later.

Regarding WeakMap itself, to reinforce what I said above, we do intend to implement it. The finalization behavior is not a trivial change and will likely take time to implement and debug. We'll have to prioritize it against other Stage 3 proposals. Consequently, we don't have a firm target date to share yet.

[rwaldron]

@erights

Obviously, a conforming engine is under no obligation to give us a gc() operation.

That is well understood. Test262 defines a special namespace for host implementations to hang necessary functionality that aids in the testing of certain ECMAScript capabilities, and publishes a versioned document that describes the name and semantics of each of those host extensions. My goal here is to define a $262.gc() that can be used by Test262 tests to test the semantics of WeakRef. Each major engine implementation maintains their own local implementation of $262, so I don't add new things without building consensus (and sometimes we do the work of implementing those pieces of functionality to ensure smooth paths for Test262 consumers).

@phoddie

So, there's no problem to add a gc trigger to our test262 harness. If it would help, we can do that sooner than later.

If I could get this in xst and get a new release, that would be excellent!

[phoddie]

@rwaldron - Sure. We'll look at adding $262.gc() to xst. Will let you know when that's in place.

[rwaldron]

@phoddie it's difficult to manage when runtimes try to implement their own $262. Similar to createRealm(), it would be ideal if it were exposed as gc() (that also matches all the other runtimes)

[phoddie]

@rwaldron We're happy to provide gc() within xst however test262 wants. I'm not sure where that is, however, as two of your comments in this thread seem to provide different guidance. It may have to do with the use of "engine" versus "runtime." Maybe you can help. Here's the first:

My goal here is to define a $262.gc() that can be used by Test262 tests to test the semantics of WeakRef. Each major engine implementation maintains their own local implementation of $262...

And the second:

it's difficult to manage when runtimes try to implement their own $262. Similar to createRealm(), it would be ideal if it were exposed as gc() (that also matches all the other runtimes)

Our $262 is here, FWIW, and includes createRealm.

[phoddie]

With today's update to XS, the gc call is in place.