626822 - nativegen could generate the C++ class declaration for native classes

Status: VERIFIED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Steven Johnson]

Currently nativegen makes assumptions about the C++ classes that implement native classes/methods/etc; life would be much simpler if it could generate the entire class, leaving only the method bodies to be implemented by the client.

Comment 1

[Steven Johnson]

Attachment: Sketch

Here's an initial proof-of-concept sketch, which converts avmshell's DomainClass/Object to be auto-generated. It extends the native metadata approach to allow specifying extra data members and invisible-to-as3 methods.

Obviously lots more work to do, but initial assumptions worth pondering:

-- will the metadata approach for the extra members/methods scale up to Flash/AIR, or it will it look/feel too weird?

-- I've done hand-wavy voodoo to ignore ExactGC for now (I rely on the existing script to be run); the good news is that we could abandon those scripts and have nativegen emit the gcTrace() methods itself; the bad news is that I'd have to extract and rewrite big chunks from AS3 to Python. (Or rewrite nativegen from Python to AS3, which is arguably worth doing...) Ugh. Suggestions here extremely welcome.

-- Note that I decree that an "auto" class/instance requires ExactGC. This seems reasonable and greatly simplifies things.

-- I'd also like to decree that an "auto" class/instance also uses GCRef for all native methods; I haven't tackled this yet but it shouldn't be too tricky.

-- It also seems likely that autogenerated classes should simply put all the AS3-declared data members inline, rather than using the existing "DECLARE_SLOTS_Foo" macro hackery; this should be doable but requires nontrivial code refactoring.

-- If take the native(method) etc approach, we really MUST have a way to strip the native metadata out... (we've needed this for a while but this really forces the issue)

-- Need a way to deal with overriding "standard" virtual methods (getAtomProperty and friends, etc); I have something in mind and need to experiment with it.

The issue of ExactGC and generating tracing methods is definitely the most important question in the short-term, though, so that's what I'd most welcome feedback on.

Comment 2

[Steven Johnson]

Comment on attachment 504955 [details] [diff] [review]
Sketch

(NOTE: this patch assumes that the "generated" patch from https://bugzilla.mozilla.org/show_bug.cgi?id=624842 is already applied)

Comment 3

[Lars T Hansen]

Comment on attachment 504955 [details] [diff] [review]
Sketch

I don't understand what this is buying us.

Comment 4

[Steven Johnson]

Another thing to note: it is a non-goal to be able to express every subclass of ScriptObject in this way; in particular, classes that live in the VM should not be forced to use this. (The goal is to eventually require all native subclasses of ScriptObject that live in Flash/AIR/etc to use this approach.) Thus, special casing for the needs of, say, Dictionary, is not important.

Comment 5

[Lars T Hansen]

Also see bug 578405 for a separate take on this.

Comment 6

[Steven Johnson]

Another obvious need is to be able to use #ifdefs of some sort for method/member declarations, which the initial sketch makes no provision for. Oy.

Comment 7

[Steven Johnson]

Withdrawing... experimentation has made clear this will become far too awkward with existing source base.

Comment 8

[Trevor Baker]

bulk verifying resolved !fixed issues