A mechanism for virtual overloads

[dcodeIO]

Currently, the compiler does not support virtual overloads of class members, as one would expect from JS, but instead resolves the respective member statically from the contextual class type. This is noted in the docs so far but we should aim at resolving this.

What's necessary here is to decide on a mechanism to resolve the virtual function or field at runtime, using the unique class ids we already have in RTTI plus, possibly, unique ids for each virtual member.

Let's say we have A#foo() with foo possibly being overloaded by a class B extends A, the implementation must call B#foo() here if the actual instance we are dealing with is a B, not an A. Interfaces are similar.

One mechanism I thought about so far is to use the unique class ids (here: of A and B), and give the foo member another internal unique id, so we can generate a runtime lookup function that performs a (memberId, classId) -> functionIndex or fieldOffset mapping through a compiler-generated big switch. The implementation on the compiler side should skip making a runtime lookup if it is not necessary (that is: the class has no subclasses or respective interfaces) for perf reasons. If it is necessary, calling a virtually overloaded functions becomes a call_indirect.

This isn't exactly scientific but is solely based on what I think would work, so if this problem has already been solved in better ways in the past, feel free to comment :)

@MaxGraey, @willemneal, @bowenwang1996

[MaxGraey]

I'm also not pretty experienced in different approaches but agree with your notes and also add on my own:

1. All subclasses share one vtable which create (link) in basic class constructor.
2. vtable not create if:
   • basic class hasn't any subclasses or interfaces
   • all methods are private or just fields
3. only non-private methods with identical name and signatures (?) added to vtable. Methods declared in interfaces or abstract classes always add to vtable for class which realize its.
4. add @final decorator? 🤔

[bowenwang1996]

Sounds reasonably to me. Let's see whether @willemneal has something to add.

[dcodeIO]

All subclasses share one vtable which create (link) in basic class constructor.

In this case, the functions would look like

function MyClass~virtual(memberId: u32): u32 { // classId implicitly is idof<MyClass>
  switch (memberId) {
    case 0: return SOME_CONST;
    case 1: return SOME_CONST;
    case 2: return SOME_CONST;
    default: unreachable();
  }
}

Questions are:

• Can we guarantee that member ids are adjacent? Looks like mixing interfaces into different classes will lead to holes.
• How much redundant code would having one function per class yield (like, each subclass would need one case even if the member isn't overloaded deeper in the tree)? Will we be missing optimization opportunities compared to one large function where Binaryen can optimize a single big switch?

The alternative is to reverse classId/memberId by using a single function that first switches over memberId, and only then over classId:

function ~virtual(memberId: u32, classId: u32): u32 {
  switch (memberId) { // guaranteed to be adjacent because memberId is a global counter
    case 0: {
      switch (classId) {
        // might become a br_table or a series of ifs depending on classId distribution here
      }
    }
    case 1: {
      ...
    }
    default: unreachable();
  }
}

In this case, the most important question is whether such a function will optimize well. On a first glimpse this "looks" like Binaryen can rereloop a lot of stuff, but haven't seen it in action yet ofc. Hmm...

[willemneal]

My first question is are we going to now implicitly inherit from an Object class?

Also do we want interfaces to be structural and nominal like typescript? Personally I think we should.

I think the per class method would be a good first step; you could use the class id as the index into the function table or a memory address it's

What do you mean by "each subclass would need one case even if the member isn't overloaded deeper in the tree".

I also have another question. When are class id's computed currently? After parsing? Or during compilation?

[dcodeIO]

My first question is are we going to now implicitly inherit from an Object class?

I think we should do this in the long term, yeah. If we can do this now, sure, why not.

Also do we want interfaces to be structural and nominal like typescript? Personally I think we should.

Depends if a static compiler can do that. Consider those two classes for example:

class Foo { a: i32; b: f32; }
class Bar { b: f32; a: i32; }

These are statically incompatible even though structurally compatible, but interfaces might not suffer from this due to all members being virtual. So I guess that there might be ways to make something structurally compatible sometimes, not but every time, which leaves the question whether we should do it at all. Might even be that structural things like these don't work well with static typing.

What do you mean by "each subclass would need one case even if the member isn't overloaded deeper in the tree".

In a single global function there can be switch fall-throughs, while if there's one function per class every function must either implement all the cases up the tree or fall-through by means of calling the overloaded virtual table function, leading to more code overhead than just a big switch (which might also optimize better because it's one large blob of code that can possibly take advantage of re-relooping).

When are class id's computed currently? After parsing? Or during compilation?

The class ids of ArrayBuffer, String, ArrayBufferView are generated when the program is initialized, as these are static, while all the others are generated as soon as a concrete class is resolved (from type arguments), which happens during compilation when the compiler sees the use of a type or expression that requires resolving a class.

[willemneal]

So I guess that there might be ways to make something structurally compatible sometimes, not but every time

If we are going to make fields, e.i. getter functions, have a unique member ID, we will always be able to determine structurally compatibility.

Consider this interface:

interface AB {
  a: i32;
  b: f32;
}

Then both of the above classes would implement it structurally even if they aren't in the same order. If there is ever flow where either class could be used where an AB interface is expected, we would be able to test that each class contains the set of member ids of the interface. Go, typescript, and other languages have static structural typing so it's definitely possible. After being able to validate that the class implements the interface then its invocation the same as if it was nominal. E.g.

class Foo implements AB { a: i32; b: f32; } differs from class Bar implements AB { b:f32; a: i32;}

But the use of virtual functions means it doesn't matter.

I understand the want to keep everything in one function for compactness and potential optimizations, but one down side is a lack of modularity. For example, assuming we could merge wasm binaries (which will be a future runtime feature of the loader), we couldn't merge the two big virtual method lookup functions, whereas it would if each class is responsible for their table.

Perhaps we should add a step between parsing and compiling, where we resolve classes/interfaces. A special transform that starts at the entries and produces a condensed program object, which only contains statements that will be compiled and handle the type checking.

[dcodeIO]

Then both of the above classes would implement it structurally even if they aren't in the same order.

If field layout isn't statically compatible, accessing any of its members structurally must resort to doing a virtual lookup. So I assume what you are proposing here is to have something like hidden interfaces for class types that are used interchangeably in a structural way? This incurs some overhead (that might ofc be worth it).

I understand the want to keep everything in one function for compactness and potential optimizations, but one down side is a lack of modularity. For example, assuming we could merge wasm binaries (which will be a future runtime feature of the loader), we couldn't merge the two big virtual method lookup functions, whereas it would if each class is responsible for their table.

Not so sure about this point. There are already things that cannot be merged easily having just executables, like RC's __visit_members. My expectation there would be that merging requires at least enough meta information to first strip and then regenerate these features after the merge, so whether or not that'd be one or multiple functions isn't really important just for that. From a WebAssembly perspective, I think that static linking will assume two otherwise independent modules and make them work in one module (at least initially), while an AssemblyScript linker will reuse additional information to do it in a way that both modules join together to a single AS program.

More generally spoken, the way to go here seems to first get interfaces up and running, and only then think about structural compatibility of other types, like using hidden interfaces which we can always do. Does that sound reasonable?

[willemneal]

Yeah that's what we should do for sure. My point was once we have the nominal interfaces, the implementing structural becomes easy. Assuming we have a virtual lookup for each method of a class that implements the interface, then all it would take is to add all classes that match it structurally as implementing the interface.

Regardless I think the place to start is what you first suggested:

function MyClass~virtual(memberId: u32): u32 { // classId implicitly is idof<MyClass>
  switch (memberId) {
    case 0: return SOME_CONST;
    case 1: return SOME_CONST;
    case 2: return SOME_CONST;
    default: unreachable();
  }
}

Each classid could correspond to an table entry that points to the class's virtual method like above.

Then each class has its methods in the table and function above would map the method ids to their table entries.

let func = call_indirect(load<u32>(ref - 8), memberid); // Calls MyClass~virtual.
call_indirect(func,...) // make actual function call.

Then after we get this to work interfaces are just classes with static methods that do the above look up on a constant memberid. After get some data about the performance we can revisit and use a different method.

Does this make sense?

[dcodeIO]

Another pro for a single function might be that multiple levels of indirect calls can be avoided, since we don't have to look up the respective virtual function first. I also wonder if storing something (for methods) in class instance's memory can be avoided, e.g.

let func = ~virtual(memberId, classId); // direct call returning the function index, memberId is static
call_indirect(func, this, ...args) // make the actual function call

where ~virtual contains the statically known function indexes directly and avoids a second indirect call due to being a single big function. This seems like it can be more efficient, if I'm not missing something about storing in instance memory (please let me know if I do). Also, if it just so happens (memberId and classId are constant, even though classId usually isn't) that Binaryen can precompute the outcome of the ~virtual call, it can optimize the indirect to a direct call, but this might not necessary be possible in the single function case only.

[MaxGraey]

How about Static Polymorphism? And CRTP which desugared (generated) by compiler?

[MaxGraey]

So this code:

class B {
   i: i32 = 1;
   add(i: i32): void { // abstract method
   }
}

class D extends B {
    add(i: i32): void { // override subtyped method foo
       this.i += i;
    }
}

let boo: B = new D();
boo.foo(1);
log(boo.i); // should be 2

generate as:

class B {
   i: i32 = 1;
   add(i: i32): void { // abstract method
   }
}

class _B<T extends D> {
  i: i32 = 1;
  add(i: i32): void {
    changetype<T>(this).add(i); // generated in compile time
  }
}

class D extends _B<D> {
  add(i: i32): void { 
    this.i += i;
  }
}

let boo: _B<D> = new D(); // _B<D> generated in compile time
boo.add(1);
log(boo.i); // -> 2

Of course it as always speed / size trade-off so main disadvantage of this approach is quickly growing codesize and slower compilation but I guess this could be partially solved.

[dcodeIO]

When we have a D down-cast to B, and pass that around to

function callMe(actuallyD: B): void {
  actuallyD.add(1);
}

how would the compiler not have to do a lookup there? I might be missing something, but CRTP seems like an alternative pattern that can be used in some situations in C++, but doesn't necessarily solve our inheritance model.

[MaxGraey]

We don't cast to B actually. Instead we cast to statically generic class _B<D> which link to its supertype.

See this approach in C++ fiddle. I don't use virtual keyword.