557688 - nativegen should allow arbitrary GCObjects as native fields in Object

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, enhancement)

Description

[Steven Johnson]

A desirable longterm goal would be to have all descendants of ScriptObject declare all data members in AS3 and have the declarations managed by nativegen.py and the VM; this would make data layout simpler and pave the way for further simplification of the native-glue layer. Based on work done in TT, I think the only piece remaining is to allow an arbitrary GCObject to be stored as a private, accessible-only-by-C++-code field. If this was in place, it would be possible to rewrite all existing glue code to have all data members declared in AS3 and managed by the VM. (Said rewrite is fairly trivial for the VM, much less so for Flash/AIR, and would have to be done piecewise.)

Comment 1

[Steven Johnson]

Attachment: Patch to nativegen.py to error on native classes with C++ members

Quick hack to nativegen.py that causes a compiletime error if a native class adds a data member in C++. Running on current codebase shows 6 such cases in core and 2 in shell.

Comment 2

[Lars T Hansen]

(In reply to comment #0)
> I think the only piece remaining is to allow an arbitrary GCObject to be
> stored as a private, accessible-only-by-C++-code field.

You should elaborate on that with a sketch.  Having a GCObject as an in-line member of anything is probably out of the question, so I assume you mean something else.

Comment 3

[Steven Johnson]

(In reply to comment #2)
> You should elaborate on that with a sketch.  Having a GCObject as an in-line
> member of anything is probably out of the question, so I assume you mean
> something else.

Ah, yes, that definitely wasn't clear enough... the intent is to allow for a GCObject* (finalized or not) to be a field in a native class, not a GCObject itself. In theory, this is doable right now (since storing a double in Atom for is simply a tagged GCObject*) but bulletproofing and general cleanup is necessary.

In term of a sketch, the existing failure modes in core are:

ArrayClas, RegExpClass, XMLClass, QNameClass (declares various String constants, which could be trivially moved to AS3 right now)
MathClass (declares TRandomFast, which would easily be converted to GCObject form)
ErrorObject (declares a StackTrace in debugger builds, which is already a GCObject)

Comment 4

[Steven Johnson]

FWIW, trying this on Flash only turns up another 25 or so classes with C++ declared data members, so adapting the existing code might not be as involved as I would have thought. (Granted, some of those classes have a *lot* of C++ data members...)

Comment 5

[Rick Reitmaier]

Naive question, but does this preclude accessing the members directly in C++?

Comment 6

[Steven Johnson]

(In reply to comment #5)
> Naive question, but does this preclude accessing the members directly in C++?

Nope, we already generate C++ accessor wrappers for the members (see doc/slots.txt)

Comment 7

[Rick Reitmaier]

(In reply to comment #6)
>
> Nope, we already generate C++ accessor wrappers for the members (see
> doc/slots.txt)

Ok, so we use the wrappers and then rely on in-lining in order to achieve equivalent performance.  Sounds like a reasonable approach to me.

Comment 8

[Lars T Hansen]

I have comments to this issue that also pertain to bug #578405; I'm adding the comments there.