gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] VM reentrancy


From: Benjamin Wolsey
Subject: [Gnash-dev] VM reentrancy
Date: Fri, 31 Jul 2009 11:41:49 +0200

I've been working on the problem of prototype creation, which is the
largest obstacle (though not necessarily the trickiest) in the way of a
reentrant VM. I'd be grateful for any feedback on the following ideas,
and for any new ideas.

It may be possible to mix elements of the suggestions, particularly as
not all so-called classes are equal. Some are native to AS, some part of
the player API, some are constructor functions, and some simple objects.

This work is also needed for AVM2 implementation, as currently we can't
implement AVM2 objects properly without changing AVM1 object prototypes.
It's important to bear in mind that the two AS versions treat classes
differently, so it should be easy to change code for one without
affecting the other.

Suggestion 1:

Instead of millions of get.*Interface functions, one for each genuine
class, use a central method.

typedef void(*PrototypeProperties)(as_object&);

Global_as::getPrototype(PrototypeProperties pp);

The Global object stores prototypes in a map with the function pointer
as a key, and creates them if they don't exist, attaching properties
with the function pointer.

Advantages:
- Removes the need for most of the separate get.*Interface functions.
- Is relatively painless to implement, as it only uses the Global_as
object, and this will have to be passed round anyway.

Disadvantages:
- Seems a bit ugly to use the function pointer as a key.
- Not all object prototypes (e.g. AsBroadcaster) have own properties.
This isn't necessarily a problem, but the workaround would be to define
no-op functions for such objects, and that's suspiciously like a dirty
hack (though it does declare positively that the prototype has no
properties, so it's not entirely senseless).
- Not very conformant to the way AS prototypes work.

Suggestion 2:

Same as above, but use ObjectURI as the key.

Advantages:
- Centralizes prototype creation.
- Each known class has a unique ObjectURI already.

Disadvantages:
- It would be necessary to pass ObjectURI to all functions that need a
prototype, which currently includes all as_object subclass ctors. As
these will also need a Global_as reference in any case, that means a
minumum of two arguments, and up to 6, for for the constructors. I think
that rules this option out.

Suggestion 3:

Keep all the get.*Interface functions, but pass a Global_as& reference
and let them retrieve their prototypes individually.

Advantages:
- Can't really see many over the first suggestion.

Disadvantages:
- Just as horrible to maintain as the current code.

Suggestion 4:

Make sure all prototypes are created exactly once before they are needed
and attached to the relevant class (constructor function). Subsequent
access to the prototype does not call the creation function, but instead
retrieves the existing prototype.

Advantages:
- Probably mirrors the behaviour of the player.
- There really shouldn't be any need to store most prototypes separately
then, because they would be members of a class, and marked as reachable
for that reason (I still haven't thought this through properly).

Disadvantages:
- May need major rewrite. The difficulty is ensuring that a prototype is
created before it's needed. Because we load most classes and objects  on
first use (basic classes like Object, String etc are created on
startup), the prototype is not created until then. However, some objects
can be created from the SWF parsing (TextField, MovieClip). These
currently access the prototype creation function (get.*Interface()),
even though it may not yet exist.

The most commonly used prototype is Object.prototype. We can make sure
this is initialized first, then it would be possible to use a different
function everywhere else to retrieve it.

bwy

--
Use Gnash, the GNU Flash Player!
http://www.gnu.org/software/gnash/

Benjamin Wolsey, Software Developer - http://benjaminwolsey.de

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


reply via email to

[Prev in Thread] Current Thread [Next in Thread]