Make it possible to subclass wasm C++ API classes for the implementor. #161

nlewycky · 2020-11-05T02:02:22Z

Fixes #119.

Use some guarantees about standard layout of zero size classes to make a safe reinterpret_cast hierarchy so that the ExternType can find its kind.

Fix build of wasm-bin since ExternType::from was removed.

rossberg

Excellent, thanks a lot! The two main questions I have are:

Is there really no convenient way to allow implicit casting from own<Derived> to own<Base> anymore? What is common C++ practice to work around that?
Can we somehow maintain the former regularity and brevity of going from an interface type to its implementation?

include/wasm.hh

src/wasm-v8.cc

rossberg · 2020-11-10T09:22:25Z

src/wasm-v8.cc

 }


 // Extern Types

-struct ExternTypeImpl {
+struct ExternTypeKind {


I'm confused, why do we need this aux wrapper?

I wrote the answer in response to a different comment: #161 (comment)

So IIUC, you are saying that this (and the static_asserts) could be avoided if we used virtual inheritance on the Impl classes? As long as that does not leak to the .hh file and imposes no other overhead, I suppose I'd be fine with that.

No, FuncType etc. would need to virtually inherit from ExternType too. Both inheritance edges need to be marked virtual for the bases to be merged.

https://isocpp.org/wiki/faq/multiple-inheritance#virtual-inheritance-where

src/wasm-v8.cc

rossberg · 2020-11-10T09:30:44Z

src/wasm-v8.cc

@@ -240,30 +217,22 @@ DEFINE_VEC(Val, vec, VAL)

 // Configuration

-struct ConfigImpl {
+struct ConfigImpl : public Config {


Let's either convert all these definitions to class or drop the public.

Dropping public breaks a lot, I've opted for making them classes.

Dropping public breaks a lot, I've opted for making them classes.

I'm confused, what can it break? Isn't public simply the default for structs?

I'm not sure what I tested, maybe I tried class ConfigImpl : Config which defaults to private inheritance. struct ConfigImpl : Config works fine.

src/wasm-v8.cc

rossberg · 2020-11-10T09:35:44Z

src/wasm-v8.cc

@@ -642,16 +597,16 @@ struct FuncTypeImpl : ExternTypeImpl {
  }
 };

-template<> struct implement<FuncType> { using type = FuncTypeImpl; };
+static_assert(std::is_standard_layout<ExternTypeImpl<FuncTypeImpl, FuncType, ExternKind::FUNC>>::value);


Why are these assertions needed? Can they be avoided somehow?

Of course asserts are just that, their only purpose is to sometimes make the build fail, so they can be removed. But in this case they're indicating something very important.

Recall my original plan was Config::method() can safely cast Config* to ConfigImpl* because the only way to get a Config* is through Config::make() which always actually creates a ConfigImpl?

ExternType is the base of a type hierarchy. In C++ when you create an object, it starts by creating the base object first, so that's a second way to create ExternType. This means that when you see an ExternType* you don't know whether it's an ExternTypeImpl* or a casted FuncType*. Oops. How do you implement ExternType::methods()?

The obvious fix of saying "well, FuncTypImpl derives from ExternTypeImpl too" doesn't work either because now you have two distinct copies of ExternType, and a given ExternType* might be the one that's a base of FuncType of FuncTypeImpl or the one that's a base of ExternTypeImpl of FuncTypeImpl. Two copies of a base objects usually have to have distinct addresses (C++20 adds an attribute to permit merging them but it's merely a suggestion).

Quick aside, there's a common C++ fix for this: virtual inheritance. When inheriting virtually, you merge two copies of a base into one copy. Tada! But I'm continuing to assume we can't use virtual.

So here's what I'm going to do: we add a simple struct ExternTypeKind that allows us to tell what the most-derived type of the object is. Once we know that, we're home free because we know what to cast to. Now, we need to be able to go from ExternType* or FuncType* etc. to the ExternTypeKind* even though we don't know what casts have been performed previously. The standard term for this is pointer-interconvertible and it will allow us to use reinterpret_cast to correctly cast between them. ExternTypeImpl exists to follow those rules, one of which is being a standard-layout type. That's what the static assert is checking.

Then we can derive FuncTypeImpl on top, and that can do whatever it likes including things which cause static_cast<> between FuncTypeImpl and ExternType to have a pointer adjustment.

Reference: https://eel.is/c++draft/basic.compound#4.3 . Also since it doesn't link to "standard-layout class": https://eel.is/c++draft/class.prop#3

src/wasm-v8.cc

rossberg · 2020-11-10T09:41:24Z

include/wasm.hh

 template<class T> using ownvec = vec<own<T>>;

 template<class T>
 auto make_own(T* x) -> own<T> { return own<T>(x); }

+template<class To, class From>
+auto own_cast(own<From> x) -> own<To> { return make_own<To>(x.release()); }


Suggested change

auto own_cast(own<From> x) -> own<To> { return make_own<To>(x.release()); }

auto own_cast(own<From> x) -> own<To> { return own<To>(x.release()); }

Why does make_own exist? I noticed that wasm-v8.cc uses own<T> directly and mimicked that in my changes, but in wasm.hh I thought that making perhaps a pointer should go through the make function.

Is it supposed to be a parallel to std::make_unique? make_unique doesn't take a pointer, it takes the arguments that the T's c'tor would take and forwards them along. This wouldn't be useful to V8 because wasm-v8.cc uses new(std::nothrow) instead of regular new.

I've gone ahead and removed make_own.

make_own exists for the same reason that make_pair and friends exist in the std lib: to work around C++'s odd inability to infer template arguments for constructor invocations. So this would mostly be for convenience in user code, not necessarily the implementation.

Okay, but in this case it might be confusing because it's different from make_unique<T> while otherwise own<T> is an alias to unique_ptr<T>. I've put it back, but we still don't use it in wasm-v8.

include/wasm.hh

…hierarchy.

nlewycky · 2020-11-10T22:32:09Z

Excellent, thanks a lot! The two main questions I have are:

Is there really no convenient way to allow implicit casting from own<Derived> to own<Base> anymore? What is common C++ practice to work around that?

Ordinarily you simply make the Base destructor virtual and everything just works. Deletion of a pointer at any type in the hierarchy goes through virtual method dispatch to find the most derived type's destructor.

The trouble with a non-virtual d'tor is that you can, with no complaint from the compiler, create a unique_ptr<Derived> cast it to a unique_ptr<Base>. In practical terms this means that any additional members Derived adds which have user-defined d'tors won't see their d'tors called. In theory, the incorrect destruction is UB regardless.

I've been assuming we can't use virtual, without really questioning why. This would all be a lot easier if we could use virtual dispatch and virtual inheritance.

Now, unique_ptr<T1, D1> can cast to unique_ptr<T2, D2> when T2 is a T1 and D2 is a D1. We could have a class hierarchy of D's that mirrors the types and the unique_ptr would cast through them together. Better idea, we could use a single D type if it knew how to delete each of T1, T2, etc. So I suppose we can change destroyer<> to:

class destroyer {
public:
  template<typename T>
  void operator()(T *ptr) {
    ptr->destroy();
  }
};

Yep, I'll commit that.

Can we somehow maintain the former regularity and brevity of going from an interface type to its implementation?

Sorry for the confusion, I was always planning to put that back. That's part of the reason this was a draft PR.

ExternType is a little more complicated but I think I can make impl(ptr) work on those too, but the template code will be a little bit more than just defining a single type alias.

…nce.

rossberg · 2020-11-12T08:17:55Z

include/wasm.hh

-template<class T> using ownvec = vec<own<T>>;
-
-template<class T>
-auto make_own(T* x) -> own<T> { return own<T>(x); }


I think this is still useful, see other comment.

rossberg · 2020-11-12T08:29:09Z

src/wasm-v8.cc

 }


 // Extern Types

-struct ExternTypeImpl {
+struct ExternTypeKind {


So IIUC, you are saying that this (and the static_asserts) could be avoided if we used virtual inheritance on the Impl classes? As long as that does not leak to the .hh file and imposes no other overhead, I suppose I'd be fine with that.

rossberg · 2020-11-12T08:36:08Z

src/wasm-v8.cc

@@ -1453,23 +1463,32 @@ auto Module::deserialize(Store* store_abs, const vec<byte_t>& serialized) -> own


 // TODO(v8): do better when V8 can do better.
-template<> struct implement<Shared<Module>> { using type = vec<byte_t>; };
+auto impl(Shared<Module>* x) -> vec<byte_t>* {


IIUC, the implement template no longer works for this because it requires a reinterpret_cast? Could that be fixed by introducing a SharedImpl subclass as well?

You'd need to make vec<byte_t> derive from the subclass too.

No, that's not quite right. We could also have SharedImpl derive from both Shared<Module> and from vec<byte_t>.

Done. I made SharedImpl<T> derive from vec<byte_t> but when you add SharedImpl<T != Module> you'll probably want to make that optional.

…e parameter.

…h method declarations.

nlewycky · 2020-11-12T19:20:38Z

include/wasm.hh

+class Module;
+
+template<>
+class WASM_API_EXTERN Shared<Module> {


FYI it's possible to remove class Module; here by instead writing:

template<> class WASM_API_EXTERN Shared<class Module> {

I haven't done that because I expect most users of C++ to be surprised to discover that you're allowed to write a forward declaration using an elaborated type specifier inside the template argument of an explicit specialization. Regardless, it's an option that would be a little cleaner.

Why not simply move the definition after Module?

Shared<Module> is used in the declaration of Module. So either we forward declare Module for Shared<Module>, or we forward-declare Shared<> for Module. All things the same, I figured the forward declaration of a non-template is less likely to cause any confusion.

Ah, right. Stylistically, it probably makes more sense to define Shared<Module> next to Module, but it's a minor point.

Okay, I've done what I think you mean. If that isn't exactly what you meant, it's a quick PR to fix, I'd be happy to review it.

Oh, I can't merge anyways. :)

rossberg

Looks good!

rossberg · 2020-11-17T07:59:28Z

include/wasm.hh

+class Module;
+
+template<>
+class WASM_API_EXTERN Shared<Module> {


Why not simply move the definition after Module?

rossberg · 2020-11-23T10:06:01Z

Thanks a lot!

nlewycky added 6 commits November 4, 2020 17:58

Make it possible to implement the Wasm C++ API using subclasses.

2a82d7d

Update wasm-bin for C++ API changes.

1a41e0f

WIP. Start updating V8 to the new C++ API.

6165f26

WIP. Continue implementation through ExternType to ExportType.

c8a138a

Use some guarantees about standard layout of zero size classes to make a safe reinterpret_cast hierarchy so that the ExternType can find its kind.

Fix own_cast<> to cast to the To type, not to the From type.

51413ad

Fix build of wasm-bin since ExternType::from was removed.

WIP. First pass through the whole file, excluding Shared<>.

c61f484

nlewycky mentioned this pull request Nov 10, 2020

C++ opaque handle implementation is based on undefined behaviour #119

Closed

rossberg reviewed Nov 10, 2020

View reviewed changes

nlewycky added 3 commits November 10, 2020 13:41

Reintroduce template implement and use it, except for the ExternType …

d2e5b1c

…hierarchy.

Rename "Destroyer" to "destroyer", re-add Table::size_t.

4ebbe72

Update for renaming of Destroyer.

31f2b9a

nlewycky added 13 commits November 10, 2020 14:34

Make destroyer a non-template allowing us to remove own_cast.

3e18dbb

Remove make_own<T>(ptr), use own<T>(ptr) instead.

bf93f13

Make these classes instead of structs, since they use public inherita…

3bc9596

…nce.

Simplify ExternTypeImpl. Use impl() to cast instead of T::from().

3b0598f

Remove use of own_cast<> from wasm-bin too.

03ccee2

Cleanup changes versus master.

4f92dd0

WIP. Implement Shared<> using explicit template specialization.

e4fe1b7

Always free the v8::Persistent<object> handle in the Store.

a84c358

Don't delete v8::PersistenObject ourselves, let the V8 GC do it.

43e74c1

Fix static_assert to work in C++11.

99144ae

ValTypeImpl's never destroyed, only a small pool is created on startup.

6929ae1

Simplify this code now that we can implicitly cast own<T>.

65a9d63

Fix bug deleting ExternTypes. Make Shared<Module>::~Shared() non-inline.

9f28f9b

nlewycky marked this pull request as ready for review November 11, 2020 23:31

Use structs, remove 'public'.

225009c

rossberg reviewed Nov 12, 2020

View reviewed changes

nlewycky added 2 commits November 12, 2020 00:40

Add convenience method for creating own<T> without specifying templat…

eef1823

…e parameter.

Define the explicit specialization for Shared<Module> in wasm.hh, wit…

8a95d59

…h method declarations.

nlewycky commented Nov 12, 2020

View reviewed changes

Make a SharedImpl<> that derives from vec<byte_t>.

c937d7e

rossberg approved these changes Nov 17, 2020

View reviewed changes

nlewycky added 2 commits November 19, 2020 10:44

Forward-declare Shared, then define Shared<Module> after Module.

abf9aed

Merge branch 'master' into use-subclasses

3364581

rossberg merged commit fd09246 into WebAssembly:master Nov 23, 2020

nlewycky deleted the use-subclasses branch November 23, 2020 18:17

syrusakbary mentioned this pull request Dec 3, 2020

Investigate wasm-c-api to allow other WASM backends iree-org/iree#4024

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make it possible to subclass wasm C++ API classes for the implementor. #161

Make it possible to subclass wasm C++ API classes for the implementor. #161

nlewycky commented Nov 5, 2020

rossberg left a comment

rossberg Nov 10, 2020

nlewycky Nov 11, 2020

rossberg Nov 12, 2020

nlewycky Nov 12, 2020

rossberg Nov 10, 2020

nlewycky Nov 10, 2020

rossberg Nov 12, 2020

nlewycky Nov 12, 2020

rossberg Nov 10, 2020

nlewycky Nov 11, 2020 •

edited

Loading

rossberg Nov 10, 2020

nlewycky Nov 10, 2020

nlewycky Nov 11, 2020

rossberg Nov 12, 2020

nlewycky Nov 12, 2020 •

edited

Loading

nlewycky commented Nov 10, 2020 •

edited

Loading

rossberg Nov 12, 2020

rossberg Nov 12, 2020

rossberg Nov 12, 2020

nlewycky Nov 12, 2020

nlewycky Nov 12, 2020

nlewycky Nov 12, 2020

nlewycky Nov 12, 2020

rossberg Nov 17, 2020

nlewycky Nov 17, 2020 •

edited

Loading

rossberg Nov 18, 2020

nlewycky Nov 19, 2020

nlewycky Nov 19, 2020

rossberg left a comment

rossberg Nov 17, 2020

rossberg commented Nov 23, 2020

	auto own_cast(own<From> x) -> own<To> { return make_own<To>(x.release()); }
	auto own_cast(own<From> x) -> own<To> { return own<To>(x.release()); }

Make it possible to subclass wasm C++ API classes for the implementor. #161

Make it possible to subclass wasm C++ API classes for the implementor. #161

Conversation

nlewycky commented Nov 5, 2020

rossberg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nlewycky Nov 11, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nlewycky Nov 12, 2020 • edited Loading

Choose a reason for hiding this comment

nlewycky commented Nov 10, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nlewycky Nov 17, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rossberg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rossberg commented Nov 23, 2020

nlewycky Nov 11, 2020 •

edited

Loading

nlewycky Nov 12, 2020 •

edited

Loading

nlewycky commented Nov 10, 2020 •

edited

Loading

nlewycky Nov 17, 2020 •

edited

Loading