Tamarin:WeeklyUpdates/2007-12-01

From MozillaWiki
Jump to: navigation, search

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

Marsha

  • 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)