412662 - Can we add optimization for faster object construction for 9.2?

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Erik Tierney]

Email thread below about the issue.  We need to "expand the createInstance+call constructor logic" so we can early bind to the constructor and avoid FP->atom->FP round trips.

From Ed Smith:

There is no theoretical problem with early binding constructor calls.  The problem is that we internally
need to call ScriptObject::construct() with a bunch of atoms.  This method then calls createInstance
and invokes the Actionscript constructor method.  
 
in tamarin, in the mean time
  - could have MIR expand the createInstance+call constructor logic so no boxing would be necessary.
   essentially we'd need a flag so that when the native class's construct() method is the trivial one
   inherited from ClassClosure, then the MIR expasion is valid to use.  But for the builtin classes with
  nonstandard construct() method (eg Array, Date, etc), we'd keep what's there now.
 
it goes without saying that the sooner we can move the quantum changes into tamarin, the better.
 
Ed



--------------------------------------------------------------------------------
From: Thomas Reilly 
Sent: Thursday, March 01, 2007 4:39 PM
To: Werner Sharp; Dan Schaffer; DL-Actionscript Core
Cc: Edwin Wong
Subject: RE: VM performance tests


+1 on object creation needing work.  I've seen real world apps take a beating on this with the Rectangle class for instance (requires a doubleToAtom and atomToDouble 4 times).   I think it boils down to being able to early bind a construct call.  If we can early bind the reference to the constructor the JIT can generate code to call the constructor directly.   Under what circumstances can we do this or not do this?
 

--------------------------------------------------------------------------------

From: Werner Sharp 
Sent: Thursday, March 01, 2007 1:31 PM
To: Dan Schaffer; DL-Actionscript Core
Cc: Edwin Wong
Subject: RE: VM performance tests

The raytracer test shows lots of object creation and double->atom operations and unboxing.   One flaw our JIT has is always converting types to Atoms for object construction then unboxing them back to native types for the constructor call.    Having someone look into a faster way to do this might speed things up significantly.   Maybe somehow separating out the createInstance operation from the construct/call itself for generic classes.



        
Transferred Comments:

JIRA Migration Admin - Mon Jun 04 12:32:29 CDT 2007
Move from BugDB issue number 200417

JIRA Migration Admin - Mon Jun 04 12:32:29 CDT 2007
Milestone ID = 1378
Milestone = FP 10 - Code Complete
Build ID = 23568
Build = AVMPLUS_1_0_0_d694
Fix Build ID = null
Fix Build = null


BugDB Migration - Mon Jun 04 12:32:29 CDT 2007
[wsharp 3/6/07] Entered Bug.  This could significantly boost performance in some cases - maybe 2x with lots of tiny objects.  

This operation?.

            r2 = new Rectangle (1.1, 2.2, 3.3, 4.4);

?is twice as slow as this?

            r3 = new Rectangle ();
            r3.bottom = 1.1;
            r3.top = 2.1;
            r3.left = 3.2;
            r3.right = 4.3;

...in a tight loop.   The 2nd case does not need to do FP->atom->FP round tripping.   
[dansmith 4/5/07] Assigned for Flash Player 10.

Dan Schaffer - Mon Nov 05 09:36:02 CST 2007
moving issue to Erik for FP10 as Dan Smith/Paul recommended.  These issues arose from the Silverlight Chess App demo.

Comment 1

[Erik Tierney]

Attachment: Implement early binding to ctor when possible.

This patch implements early binding to the ctor.  Takes some code from ClassClosure::construct, and places it in ClassClosure::newInstance.  This can be called from the generated code, and then the constructor method can be invoked directly on the new instance.  This way we can avoid converting the arguments to/from Atom's whenever we call the constructor.

This makes the chess app about 10% faster, and the raytracer app about 20% faster (lots of constructor calls with doubles).

Comment 2

[Erik Tierney]

Attachment: More up to date patch

Updating the patch so it works against the latest code in hg.

Comment 3

[Edwin Smith]

Comment on attachment 317710 [details] [diff] [review]
More up to date patch

ping me again after de-bitrotting

Comment 4

[Erik Tierney]

Attachment: Patch against latest code base

Here's a patch against the latest code in TC - changeset 6582fd7afc59 (http://hg.mozilla.org/tamarin-central/index.cgi/rev/6582fd7afc59)

Comment 5

[Edwin Smith]

If this is done lets close it out

Comment 6

[Chris Peyer]

Resolved fixed engineering / work item that has been pushed.  Setting status to
verified.