Tamarin:WeeklyUpdates: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 12: Line 12:




== 4th December 2007 ==
== 11th December 2007 ==


== Attendees ==
* brendan
* bsmedberg
* ed
* erik t
* jorendorff
* lars
* marcia
* markh
* moh
* rick r
* seo
* steven j
== Status ==


'''Moh'''
'''Moh'''
 
* call graph in VTune working.
* Basic call graph working.  
* waiting for mgmt decision on VTune availability, possibly via [http://whatif.intel.com/ whatif.intel.com]
** Business dev preso, open up vtune. Went well.
* will look into adding JavaGrande to the VTune-profiled tests
** Licensing support. Team would have to commit to support.
** Also want to know how does newer perf tools relate to vtune?


'''Marcia'''
'''Marcia'''
* filed https://bugzilla.mozilla.org/show_bug.cgi?id=407046
* also looking for comments on PowerPoint draft showing VTune profiling results, preliminary, mailing around for review
* looking at slide 3, vtune barchart of alioth debian shootout benchmarks
* question about debugger support costs reading too high
* Ed: should be possible to build in release mode but enable the right opcodes to build address maps for vtune
* Goal is to have a "Release VTune" configuration
* Markh asked about debug penalty, but needs that to get exception detail otherwise missing
* Brendan says a Tamarin in Firefox must have good exception details, source images in ReferenceError diagnostics, etc.
* Ed suggests starting from Release Debugger and optimizing hard
* Brendan points to ESC involvement, JS debugger APIs used by Firebug -- lots to do (will file bugs)


* Wants more JS speed tests
'''Markh'''
* Object array. Unshift bug needs to be filed
* implementing IDispatch in ScreamingMonkey Tamarin glue
* A lot of time spend in GC. Not sure how that compares to other engines
* questions:
 
** use of MI and templates, specifically some GCRoot inheritors
** Hashtables for managed memory: GCHashtable, avmplus::Hashtable
** Also avmplus::List
* ScreamingMonkey status: plugging away, nothing much to expect till after Christmas


'''Seo'''
'''Seo'''
 
* working on CIL decompiler, [http://groups.google.com/group/mono-cecil/browse_thread/thread/b43296d0cb0e93f0 sent] patches upstream
* Currently working on translating MSIL exception handling to ABC
* exception issue from last week? no open issue
** necessary to support Iron* runtime (?)
* [http://www.iunknown.com/2007/11/dlr-hosting-spe.html DLR hosting spec], looks ok
* Goal: C# "hello world" to MSIL to ABC
 
 
'''Steven'''
 
* Has patch for review by Edwin. A grab-bag of FP changes, maybe 12 bug fixes
 


'''Jason'''
'''Jason'''
* chasing down GC bugs, progressively better, still crashing -- more to do on js/src side
* js/src/xpconnect/tests/js/old/threads.js broke some time over the years, due most recently to thread manager API change
* after fixing that, still having problems with thread-unsafe xpcom objects finalized on wrong thread
* See the [https://bugzilla.mozilla.org/show_bug.cgi?id=407803 bug]


* Running Tamarin tests on Mac results in six failures. Not clear what the
'''Rick'''
cause is
* JIT intermediate buffers are not shared across threads
* Wants to land mmgc thread safe this week. Will post an updated patch.
* each Tamarin instance has its own buffer => big footprint
 
* synch using GC spinlock
 
* Brendan: might want lock-free (SpiderMonkey portable [http://lxr.mozilla.org/mozilla/source/js/src/jslock.c CAS])
'''Mark H'''
 
* State management working properly.
* Summary of global object issue
** AS3 has one global object per ABC.
** This is not how the browser work.
** [Ed] Use façade as a clearing house for various binding
** ESC should be able define a façade with modification of Tamarin
** This is TBD
 
 
'''Discussion'''
 
* Moh/Marcia: is there any performance documentation or benchmarks?
* Tommy: UCI team has ported JavaGrande to Tamarin
* UPDATE from Brendan: UCI JavaGrande port is in a [http://gforge.ssllab.org/gf/project/jsbench/scmsvn/ public svn] now
* Ed: short running test are our focus
* Jeff: it would be interesting to profile ESC
 
* Benjamin: MMGC question about back references. <sorry had to leave the room>


== 27th November 2007 ==
== 27th November 2007 ==

Revision as of 22:52, 11 December 2007

These updates concern Tamarin and related projects only.

Meeting Details

  • 2:00pm Pacific Time (21:00 UTC) on Tuesdays
    • (5PM Eastern US, 11PM Oslo, 6AM (Wed) Seoul, 7AM (Wed) Melbourne)
  • Meeting ID: 8262746 (TAMARIN)
    • California: 408-536-9900
    • Toll-Free(US & Canada): 877-220-5439
    • International: +1-408-536-9900
  • Duration: 60 minutes
  • join irc.mozilla.org #tamarin for attendence taking and questions


11th December 2007

Attendees

  • brendan
  • bsmedberg
  • ed
  • erik t
  • jorendorff
  • lars
  • marcia
  • markh
  • moh
  • rick r
  • seo
  • steven j

Status

Moh

  • call graph in VTune working.
  • waiting for mgmt decision on VTune availability, possibly via whatif.intel.com
  • will look into adding JavaGrande to the VTune-profiled tests

Marcia

  • filed https://bugzilla.mozilla.org/show_bug.cgi?id=407046
  • also looking for comments on PowerPoint draft showing VTune profiling results, preliminary, mailing around for review
  • looking at slide 3, vtune barchart of alioth debian shootout benchmarks
  • question about debugger support costs reading too high
  • Ed: should be possible to build in release mode but enable the right opcodes to build address maps for vtune
  • Goal is to have a "Release VTune" configuration
  • Markh asked about debug penalty, but needs that to get exception detail otherwise missing
  • Brendan says a Tamarin in Firefox must have good exception details, source images in ReferenceError diagnostics, etc.
  • Ed suggests starting from Release Debugger and optimizing hard
  • Brendan points to ESC involvement, JS debugger APIs used by Firebug -- lots to do (will file bugs)

Markh

  • implementing IDispatch in ScreamingMonkey Tamarin glue
  • questions:
    • use of MI and templates, specifically some GCRoot inheritors
    • Hashtables for managed memory: GCHashtable, avmplus::Hashtable
    • Also avmplus::List
  • ScreamingMonkey status: plugging away, nothing much to expect till after Christmas

Seo

  • working on CIL decompiler, sent patches upstream
  • exception issue from last week? no open issue
  • DLR hosting spec, looks ok

Jason

  • chasing down GC bugs, progressively better, still crashing -- more to do on js/src side
  • js/src/xpconnect/tests/js/old/threads.js broke some time over the years, due most recently to thread manager API change
  • after fixing that, still having problems with thread-unsafe xpcom objects finalized on wrong thread
  • See the bug

Rick

  • JIT intermediate buffers are not shared across threads
  • each Tamarin instance has its own buffer => big footprint
  • synch using GC spinlock
  • Brendan: might want lock-free (SpiderMonkey portable CAS)

27th November 2007

Jason -

  • mmgc thread safe posted as patch ready for review
    • tom to review by end of week
  • large corresponding patch in Spidermonkey pending

Moh (Vtune) -

  • Good progress with the call graph
  • Vtune issue with call graph in the rt library; fixed by Vtune team
  • Vtune biz dev working on making interface of Vtune to public
    • Need to make header file public for integration with Tamarin
    • May need support from us to convince Intel biz dev that it is helpful and should be made public
    • The license is TBD
    • Brendan notes that the licensing must be compatible with Mozilla's.

Mark H (ScreamingMonkey)

  • Demo didn't quite make it for Brendan's last talk
  • Working with Brent to get the headless chessapp
    • The JIT version is 15x the Jscript.NET versiom, 20x slower than C#
  • Sent mail to tamarin-devel regarding global objects; response from Ed
  • ESC is quite slow
  • Would like to see ESC integrated into the build environment;

Seo (ironmonkey)

  • Using Cli disassembler library (Cecil)
  • Will use OP_callmethod to map early bound cli instructions to Tamarin

Various

  • John Resig / Brent are investigating a performance problem (probably an infinite loop)
  • Quick, somebody file a bug! and copy brendan@mozilla.org


Older meetings