mirror of https://github.com/boa-dev/boa.git
Tree:
f4ebb2bd2d
add-vhs-ci
benchmarks
bump-test262
control-flow-graph
dependabot/cargo/rust-dependencies-50dc4690b8
expect-lints
feature/node_span
feature/snapshot
features
gh-readonly-queue/main/pr-2877-b0ddf5eed00a53281d67fc7d846233fc0d99ce9c
gh-readonly-queue/main/pr-3144-8e48cec73fae708420b9af88813d4870243c491a
local-parameters-if-mapped-arguments-object-not-accessed
main
nan-boxing
optimization/static-shapes
real_conformance
refactor/interner
refactor/register-vm
releases/0.17
releases/0.19
semver_checks
tco
utility-crate
wasm-debugger
nightly
v0.10
v0.11
v0.12
v0.13
v0.14
v0.15
v0.16
v0.17
v0.17.1
v0.17.2
v0.17.3
v0.18
v0.19
v0.19.1
v0.2.0
v0.2.1
v0.20
v0.3.0
v0.4.0
v0.5.0
v0.5.1
v0.6.0
v0.7.0
v0.8.0
v0.9.0
${ noResults }
4 Commits (f4ebb2bd2d7da487ca8c09876d8ad90ce99504f3)
Author | SHA1 | Message | Date |
---|---|---|---|
Haled Odat | ed37448175 |
Implement `Hidden classes` (#2723)
This PR implements `Hidden Classes`, I named them as `Shapes` (like Spidermonkey does), calling them maps like v8 seems confusing because there already is a JS builtin, likewise with `Hidden classes` since there are already classes in JS. There are two types of shapes: `shared` shapes that create the transition tree, and are shared between objects, this is mainly intended for user defined objects this makes more sense because shapes can create transitions trees, doing that for the builtins seems wasteful (unless users wanted to creating an object with the same property names and the same property attributes in the same order... which seems unlikely). That's why I added `unique` shapes, only one object has it. This is similar to previous solution, but this architecture enables us to use inline caching. There will probably be a performance hit until we implement inline caching. There still a lot of work that needs to be done, on this: - [x] Move Property Attributes to shape - [x] Move Prototype to shape - [x] ~~Move extensible flag to shape~~, On further evaluation this doesn't give any benefit (at least right now), since it isn't used by inline caching also adding one more transition. - [x] Implement delete for unique shapes. - [x] If the chain is too long we should probably convert it into a `unique` shape - [x] Figure out threshold ~~(maybe more that 256 properties ?)~~ curently set to an arbitrary number (`1024`) - [x] Implement shared property table between shared shapes - [x] Add code Document - [x] Varying size storage for properties (get+set = 2, data = 1) - [x] Add shapes to more object: - [x] ordinary object - [x] Arrays - [x] Functions - [x] Other builtins - [x] Add `shapes.md` doc explaining shapes in depth with mermaid diagrams :) - [x] Add `$boa.shape` module - [x] `$boa.shape.id(o)` - [x] `$boa.shape.type(o)` - [x] `$boa.shape.same(o1, o2)` - [x] add doc to `boa_object.md` |
2 years ago |
José Julián Espina | 6d3550d0cb |
Implement async functions using generators (#2821)
This should hopefully fix more async/futures issues related to resuming execution in the future, since we can leverage generator logic to handle this for us. It changes the following: - Refactors `GeneratorContext` to handle context preparation. - Reuses the functionality of `GeneratorContext` in `Await`. - Removes `EarlyReturnType` in favour of a single `r#await` bool flag in `CallFrame`. |
2 years ago |
José Julián Espina | 34d6b93f36 |
Fix cross-realm construction bugs (#2786)
This Pull Request fixes test [`assert-throws-same-realm.js`](
|
2 years ago |
Haled Odat | 570bc85ebe |
Implement debug object for CLI (#2772)
Currently some debugging stuff in JavaScript land is difficult to impossible, like triggering a GC collect, this is not impossible to do in JavaScript the way I triggered it was by creating a huge amount of object `for (let i = 0; i < 100000; ++i) { ({}) }` but this is cumbersome and not guaranteed to trigger a gc. This PR implements `--debug-object` flag that injects the `$boa` debug object in the context, the object is separated into modules currently `gc`, `function`, `object`. We can now do `$boa.gc.collect()`, which force triggers a GC collect. Or sometimes I wanted a trace (the current solution is great, you can trace stuff like `>>> 1 + 1` but that is also it's limitation), it traces everything, I sometimes have a scenario and just want to trace a single function in that scenario, that's why I added the `$boa.function.trace(func, this, ...args)` It only traces the function. ```js >> $boa.function.trace((a, b) => a + b, undefined, 1, 2) -------------------------Compiled Output: ''-------------------------- Location Count Opcode Operands 000000 0000 DefInitArg 0000: 'a' 000005 0001 DefInitArg 0001: 'b' 000010 0002 RestParameterPop 000011 0003 GetName 0000: 'a' 000016 0004 GetName 0001: 'b' 000021 0005 Add 000022 0006 Return 000023 0007 PushUndefined 000024 0008 Return ... (cut for brevity) ... ``` It also implements `$boa.function.flowgraph(func, options)`: ```js $boa.function.flowgraph(func, 'graphviz') $boa.function.flowgraph(func, { format: 'mermaid', direction: 'TopBottom' }) ``` Printing the object pointer: ```js $boa.object.id({}) // '0x566464F33' ``` It currently implements some functionality which we can grow it with our debugging needs since we are not restricted by a spec we can add whatever we want :) I was originally going to implement this in #2723 (but the PR is too big), for shapes having functions like: ```js $boa.shape.type({}) // Shared shape $boa.shape.id({}) // 0x8578FG355 (objects, shape pointer) $boa.shape.flowgraph({}) // printing the shape transition chain, like $boa.function.flowgraph ``` Shapes chains are very hard to debug once they are big... so having this type of debugging capability would make it much easier. |
2 years ago |