Boa Monthly Sync - April 2024

Boa Monthly Sync - April 2024 === ###### tags: `Meeting` :::info - **Date:** 2024-04-14 13:00 (UTC) - **Participants:** - Jedel (JDL) - Kevin (KN) - JaseW (JWS) - HalidOdat (HLD) - Iban (RAZ) ::: Welcome to the montly meeting. We have a lot of important points to discuss. ### Test262 data representation - https://github.com/boa-dev/boa/issues/3728 JDL: I did some investigation, thought that compressing JSON was enough by reducing data size by 90%, maybe this is fine. There's 4MB of size for each tag, so not much, but it will get pretty big once we have around 50 or 100 versions. RAZ: I did a check, and the latest JSON was 3.5MB, but the download size is 295kB (compressed in Gzip) JDL: Since the browser already compresses the file, we can focus on the Rust data representation then. JWS: About having a database, is this not something we were interested in doing? HLD: We would have to maintain it and it would be another moving part. RAZ: that was my thought as well. It could be nice in the future, if we need it, or if we are already using VMs for our benchmarks JDL: I left a ping on the issue https://github.com/boa-dev/boa/issues/3728#issuecomment-2054059241 JDL: We are in agreement that we don't need to have a new data format, we just need to improve the current data and deduplicate some things. HLD: We could have a scheduled GitHub workflow that runs once every 6 months that squashes the commits, if the repository becomes too large. RAZ: for the full list of commits for a given branch, we have a script that cleans up commits older than 1 year. We can also squash all data commits once in a while if the repo becomes too large. This can be done manually when needed. Conclusion: - Hear from CanadaHonk on his opinions of storage - Stick with JSON format for now and rely on the compression - Alter representation to be more efficient ### Conformance page improvements - https://github.com/boa-dev/boa-dev.github.io/issues/148 Potentially related PR: https://github.com/boa-dev/boa-dev.github.io/pull/150 JDL: For some users they want to see if the engines implements some features or particular use cases passes on the engine. It should be nice to improve the conformance page. KN: I have a PR that has history functionality, it implements sort but its not customizable yet. Its hard getting the edge cases. JWS: I can take a look at this and review JWS: Do we want to open up contributions to others (for low hanging fruit etc) JDL: Maybe we wait until we've merged Kevin's PR so that other contributors don't need to rebase over a big refactor. Conclusion: - Review Kevin's PR and help out if needed on other issues from the checklist. ### Migration from Discord JDL: Maybe we could use discord as a general channel where we can offer assitance, questions. But Matrix more for development. KN: Migrate boa-dev members over to matrix but keep the Boa general channel in Discord as it is? JDL: Yep RAZ: We could try the matrix channel and see how many people move there, as it may be tricky maintaining 2 platforms at the same time. JWS: You could do a poll to see how many people would migrate. KN: I'm not sure how visible matrix is for someone just casually looking through Boa, maybe its more for those who want to be more involved. Conclusion: - Find out how to set up a Matrix server and move boa-dev-members discussion over to there but keep General as it is for now in Discord. Mention the matrix channel and see how many move across. - https://matrix.org/docs/communities/getting-started/#creating-sharing-a-space ### `temporal-rs` - Possible removal of `relativeTo` from the spec. - General API thoughts - IANA TimeZone sourcing / handling - https://github.com/boa-dev/temporal/issues/4 JDL: It is on the plans to remove `relativeTo`, custom calendars and timezones. We need to figure out if we want to remove those APIs from `temporal-rs`, or if we want to still offer them. KN: Removing those APIs would be a very big refactor in our codebase. JWS: If it's removed, it would probably never come back, or it will come back far ahead in the future. It could take years. Conclusion: - If `relativeTo` is removed from the spec, agreed that we should remove that API from `temporal-rs`. - If custom calendars and custom timezones are removed from the spec, we will still offer those APIs. ### Performance JDL: I think we're in a very good place in conformance, but seeing our benchmarks we're behind on performance. It would be good to put some more effort on that. JWS: I think we discussed this before, but is it possible to lazy load builtins? JDL: I think that should be possible, but I also think snapshotting would remove the need of lazy loading. Most users will want snapshots anyways. HDL: there's too much linkage between the context and the byte compiler. JDL: We'll have to decouple the bytecode generation from the engine I suppose. HDL: I was thinking of implementing special bytecode but it would depend on globalThis and depending on that it would generate different bytecode. RAZ: We might want to offer the option to save the compilation, as an intermediate step before saving the whole machine state to enable execution pausing and resuming JDL: The GC would need some changes also? KN: We will need to change the GC eventually. HLD: We could generate just the scopes and analyse that on the AST instead of the bytecode. I was trying to do it during complation but a lot of things are not known at compilation. JDL: We could add types to the AST to add more optimization to certain methods. JDL: Do some more research on code analysis (using the rust compiler as an example) HDL: Another idea is to do a post analysis on the AST. JDL: We're missing big performance opportunities like dead code elimination, not needing to compile functions that aren't used. Conclusion: - Open up a custom GC repo to experiment with other APIs. See if something sticks. - Try to move our current optimizations to the AST instead of the bytecode. - Investigate code analysis, using the rust compiler as an example. - Investigate snapshotting only for builtins for now. We can check how to extend that to general snapshotting after rewriting the GC. ### Issue Triage - Parsing an expression containing a huge list of token triggers a stack overflow (https://github.com/boa-dev/boa/issues/162) Conclusion: JDL will work on this. - Create execution context and execution stack (https://github.com/boa-dev/boa/issues/186) Conclusion: Closed. - Span nodes (https://github.com/boa-dev/boa/issues/300) Conclusion: Add at least a starting position to all the AST nodes. Check how rustc does it since they have a really nice and compact span storing model. - Implement console methods (https://github.com/boa-dev/boa/issues/307) Conclusion: Open some issues for new contributors. - Expose API to Deno (https://github.com/boa-dev/boa/issues/575) Conclusion: Closed. - We cannot run some Test262 include files (https://github.com/boa-dev/boa/issues/823) Conclusion: Fixed. - 1000n << 10000000n takes forever (https://github.com/boa-dev/boa/issues/1053) Conclusion: Works as intended. - Optimize integer operations (https://github.com/boa-dev/boa/issues/1147) Conclusion: Fixed. - Duplicate code in Boa (https://github.com/boa-dev/boa/issues/1184) Conclusion: Not applicable to the current codebase anymore. - Should some object-specific operations be moved out of GcObject? (https://github.com/boa-dev/boa/issues/1323) Conclusion: Fixed. - NaN boxed JavaScript Value (https://github.com/boa-dev/boa/issues/1373) Conclusion: JDL will work on reducing the size of `JsObject`.