rework cppgc for prototype chain

[littledivy]

Implement prototype inheritance into cppgc object wraps.

struct Foo {}

impl GarbageCollected for Foo {}

#[op2]
impl Foo {
    fn super_method(&self) {
        println!("super method called!");
    }
}

struct Bar {}

impl GarbageCollected for Bar {}

#[op2(inherit = Foo)]
impl Bar {
    #[constructor]
    #[cppgc]
    fn new() -> (Foo, Bar) {
        let foo = Foo {};
        let bar = Bar {};

        (foo, bar)
    }

    #[fast]
    fn use_proto(&self, #[proto] foo: &Foo) {
        // do something with foo
    }
}

const bar = new Bar();

assert(bar instanceof Foo);
bar.superMethod();
bar.useProto();

[bartlomieju]

Are you sure we're not gonna hit this limit immediately in Deno?

[littledivy]

Nope, this is only for native object proto chain. The actual JS proto chain isn't restricted.

[bartlomieju]

Maybe change a name to something more descriptive to suggest that it uses the second argument as a prototype

[littledivy]

It's named because its easier for the macro to do: format!("make_cppgc_object{}", chain.len()). These aren't supposed to be publicly used. I've added #[doc(hidden)]

[lucacasonato]

I think cppgc_template_constructor should throw a TypeError.

[lucacasonato]

Actually this abstraction is much nicer than what we had previously. With this it is impossible to accidentially use T without checking ptr.tag anymore. Great!

[lucacasonato]

Does this dispatch correctly? We don't want to call EreasedPtr's T here - I assume this all works out, but can you add some comments?

[littledivy]

Added

[lucacasonato]

@devsnek PTAL also

[devsnek]

do normal objects need this? its unfortunate to have double the allocations. could we instead have two tags, one for plain objects and one for prototype backed objects? plain objects can continue to use wrap/unwrap, and prototype backed objects can use wrap2/unwrap2.

[devsnek]

maybe crazy but could this be an interior linked list of ErasedPtr stored on each object? not sure if saving the memory is worth the slight overhead of traversing when unwrapping, perhaps worth testing?

[littledivy]

Tried it out:

#[repr(C)]
struct CppGcObject<T: GarbageCollected> {
  tag: TypeId,
  next: Option<ErasedPtr>,
  member: T,
}

./dcore_proto_linked_list test.mjs # linked list
🛑 deno_core binary is meant for development and testing purposes.
Run test.mjs

1e8x new DOMPoint(): 10290ms
1e8x point.x: 2985ms

./dcore_proto_array test.mjs # array
🛑 deno_core binary is meant for development and testing purposes.
Run test.mjs

1e8x new DOMPoint(): 10544ms
1e8x point.x: 2785ms

Maybe it makes sense to use linked list when we increase depth further than 3?