Tamarin:WeeklyUpdates: Difference between revisions
Jump to navigation
Jump to search
m (→Older meetings) |
|||
| Line 12: | Line 12: | ||
= | = 18th December 2007 = | ||
== Attendees == | == Attendees == | ||
* | * Marsha | ||
* | * Brett | ||
* | * Ed | ||
* | * Steven | ||
* | * Brendan | ||
* | * Moh | ||
* | * Benjamin | ||
* | * Andreas Gal | ||
* | * Dan Schaffer | ||
* | * Jeff | ||
* | |||
* | == tamarin-tracing == | ||
* Adobe will push later today a branch of the code in tamarin-central (T-C), which introduces a trace-based just-in-time compiler. | |||
* Research (www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-07-10.pdf) and experience with Tamarin indicate that tracing provides significant size and performance advantages over traditional static JIT compilers, especially when executing untyped JavaScript. | |||
* The new code will reside in a repository at: | |||
http://hg.mozilla.org/tamarin-tracing | |||
* Tamarin-tracing (T-T) shares a common root with T-C and so the complete history of changes is recorded. Fixes from both branches will be merged to the other over time. | |||
* T-T is currently optimized to run effectively on mobile devices. As such, its performance characteristics favor memory efficiency over speed. | |||
* Not API compatible with T-C | |||
* Calls to builtins can be optimized by rewriting builtins in interpreted (trace-able) byte code. This also leads to smaller object files | |||
* The interpreter is and indirect threading Forth engine. | |||
== Status == | == Status == | ||
''' | '''Mark H''' | ||
* call | * Q. How different are the APIs? A. Pretty different. They are not compatible, but the builts have already been ported, and you'll only need to port you own host objects. | ||
* | |||
* Shouldn't be too bad then. | |||
* ChessApp working a bit better. JScript can call Tamarin and vice-versa. This allows workaround of missing event handling across engines since JScript event handlers can call Tamarin functions. Close to having Tamarin move chess pieces around the board. | |||
'''Benjamin''' | |||
* From earlier email: | |||
Just a note: I'm working on a project to add valgrind memory annotations to | |||
MMgc. This will allow valgrind to note improper use of GC memory. | |||
The first step is quite simple: it will use the valgrind client requests | |||
described at | |||
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs to | |||
declare freed memory as unaccessable. | |||
The second step will be to check memory overruns (writes of multiple GC | |||
allocations from a single call). | |||
The third step will be a warning system for correct incremental marking. If | |||
you write a pointer-like value to GC memory without using a write barrier, | |||
it will warn. This has to be a conservative warning, of course. | |||
I hope to have step I done by the first week of January. | |||
- --BDS | |||
'''Jason''' | '''Jason''' | ||
''' | * Stage 1 (ActionMonkey) just about complete. Waiting for reviews. "maybegc" api done. 4 or 5 patches ready to land. | ||
* | * Stage 2, incremental GC, is next | ||
'''Moh''' | |||
* Profiled JSBench (http://gforge.ssllab.org/gf/project/jsbench/scmsvn/) from the UCI team. Shows one helper method (doubleToAtom) is responsible for ~46% of the time in one of the tests (Moldyn). | |||
* Will study further to look for optimization opporunities | |||
= Older meetings = | = Older meetings = | ||
Revision as of 00:13, 19 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
18th December 2007
Attendees
- Marsha
- Brett
- Ed
- Steven
- Brendan
- Moh
- Benjamin
- Andreas Gal
- Dan Schaffer
- Jeff
tamarin-tracing
- Adobe will push later today a branch of the code in tamarin-central (T-C), which introduces a trace-based just-in-time compiler.
- Research (www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-07-10.pdf) and experience with Tamarin indicate that tracing provides significant size and performance advantages over traditional static JIT compilers, especially when executing untyped JavaScript.
- The new code will reside in a repository at:
http://hg.mozilla.org/tamarin-tracing
- Tamarin-tracing (T-T) shares a common root with T-C and so the complete history of changes is recorded. Fixes from both branches will be merged to the other over time.
- T-T is currently optimized to run effectively on mobile devices. As such, its performance characteristics favor memory efficiency over speed.
- Not API compatible with T-C
- Calls to builtins can be optimized by rewriting builtins in interpreted (trace-able) byte code. This also leads to smaller object files
- The interpreter is and indirect threading Forth engine.
Status
Mark H
- Q. How different are the APIs? A. Pretty different. They are not compatible, but the builts have already been ported, and you'll only need to port you own host objects.
- Shouldn't be too bad then.
- ChessApp working a bit better. JScript can call Tamarin and vice-versa. This allows workaround of missing event handling across engines since JScript event handlers can call Tamarin functions. Close to having Tamarin move chess pieces around the board.
Benjamin
- From earlier email:
Just a note: I'm working on a project to add valgrind memory annotations to MMgc. This will allow valgrind to note improper use of GC memory.
The first step is quite simple: it will use the valgrind client requests described at http://valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs to declare freed memory as unaccessable.
The second step will be to check memory overruns (writes of multiple GC allocations from a single call).
The third step will be a warning system for correct incremental marking. If you write a pointer-like value to GC memory without using a write barrier, it will warn. This has to be a conservative warning, of course.
I hope to have step I done by the first week of January.
- --BDS
Jason
- Stage 1 (ActionMonkey) just about complete. Waiting for reviews. "maybegc" api done. 4 or 5 patches ready to land.
- Stage 2, incremental GC, is next
Moh
- Profiled JSBench (http://gforge.ssllab.org/gf/project/jsbench/scmsvn/) from the UCI team. Shows one helper method (doubleToAtom) is responsible for ~46% of the time in one of the tests (Moldyn).
- Will study further to look for optimization opporunities