A Intern's Journey Through SpiderMonkey and JavaScript Engine Enhancements
The first time I saw the Iterator.range proposal and the algorithms inside I wasn't sure that I'd be able to hack it. As an Outreachy contributor, I and other contributors would contribute for a month, and then one intern would get chosen to work on the proposal/specification.
Preamble
A couple of days into the contribution period, I was assigned tasks designated to Outreachy contributors, but most importantly, I was assigned the ErrorIsError TC39 proposal.
The first step to implementing a TC39 proposal in SpiderMonkey (Mozilla JavaScript Engine) is to add a preference for it.
This allows for the feature to be enabled or disabled at runtime, which is important, because we don't want to enable a feature by default until we've tested it enough to be confident that it won't cause problems for our users. In this case, we create a preference and set the value to false.
As you can see, when implemented with JavaScript, the proposal is quite straightforward and was the initial implementation. However, code review came back and it was better to implement the proposal as a native C++ function which was a learning process for me, both in terms of the reason and working with C++.
During the process, we encountered some interesting challenges involving cross-compartment wrappers (CCWs) and intrinsic type checks in JavaScript engines.
The Issue with Cross-Compartment Wrappers and ErrorObject Checks
When handling Error objects , the IsErrorObject function determines if a given value is an instance of the ErrorObject type. However, a critical edge case arises when the argument is a cross-compartment wrapper (CCW) for an ErrorObject from another compartment. The IsErrorObject check does not account for CCWs directly, as they obscure the underlying object.
Implementation Context: In the code handling intrinsic type checks, the intrinsic_IsInstanceOfBuiltin function is used to check if an object is of a specific type. While it works when applied to the this value; assuming it's already unwrapped; it doesn't handle arguments that might still be wrapped by CCWs.
The Proposed Solution: A Dedicated Native Function
To address this issue, the solution involves:
1. Adding a new native function: A dedicated native function is created to handle CCWs transparently by:
- Unwrapping CCWs.
- Testing if the unwrapped object is of type
ErrorObject. - Verifying the object type in one cohesive operation.
2. Removing Self-Hosted Complexity:
By implementing this new function as JSNative, we can streamline the process, performing all operations within a single native function without relying on self-hosted helpers.
Why This Approach?
Handles Non-Object Cases: The new function integrates checks for whether the value is even an object before proceeding to unwrap it.
Simplifies Specification Alignment: Since CCWs are an implementation detail and not part of the TC39 JavaScript specification, these changes ensure behavior aligns with the spec while avoiding discrepancies.
The above consisted of 45 lines of code, excluding two test files: one for JIT (Just-In-Time) compiled tests and another for Test262 tests/files. However, through those 45 lines of code, I was able to:
- Learn where predefined error messages are within the Mozilla codebase and how to use them. This proved handy when I needed to define error messages for Iterator.range.
- Understand nightly and nightly builds.
- Code consistency: Tailor my code to meet TC39 specifications and avoid shorthand for newly added code as per Mozilla standards.
What I'm Currently Working On: Iterator.range
After diving into the complexities of cross-compartment wrappers and enhancing ErrorObject handling during my Outreachy contribution period, I turned my attention to something equally exciting: the Iterator.range proposal for my Mozilla Outreachy Internship.
For those unfamiliar, Iterator.range is an addition to the TC39 proposals for JavaScript, aimed at making iterators more versatile. This method introduces an efficient way to generate ranges of values, which can be particularly useful in everyday programming, such as iterating over a sequence of numbers or creating step-based loops.
The concept itself might seem simple; generate a series of values from a start point to an end point, but implementing it in SpiderMonkey is proving to be an excellent challenge.
Unlike the previous ErrorObject work, which involved handling abstract operations and native C++ functions, Iterator.range requires a deep dive into how JavaScript iterators work internally and how SpiderMonkey integrates these features at the engine level.
When I started working on Iterator.range, the initial implementation - similar to what I had done for ErrorIsError proposal had been done, ie; adding a preference for the proposal and making the builtin accessible in the JavaScript shell.
The Iterator.range simply returned false, a stub indicating that the actual implementation of Iterator.range was under development or not fully implemented, which is where I came in.
As a start, I created a CreateNumericRangeIterator function that delegates to the Iterator.range function. Following that, I implemented the first three steps within the Iterator.range function.
Next, I initialised variables and parameters for the NUMBER-RANGE data type in the CreateNumericRangeIteratorfunction.
I focused on implementing sequences that increase by one, such as Iterator.range(0, 10). I also updated the CreateNumericRangeIterator function to invoke IteratorRangeGenerator (which handles step 18 of the Range Proposal specification) with the appropriate arguments, aligning with Step 19 of the specification, and added tests to verify its functionality.
This week, I am exploring how to properly set the prototype for generators returned by Iterator.range.
My work for the next couple of weeks/months includes, but is not limited to:
- Set proper prototype for generator returned by Iterator.range.
- Support BigInt in Iterator.range.
- Support other sequences, as I have only covered sequences that increase by one for now.
- Add adequate tests for the above.
You may also like:
Decoding Open Source: Vocabulary I've Learned on My Outreachy Journey
Top comments (0)