Tamarin:WeeklyUpdates: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(36 intermediate revisions by 2 users not shown)
Line 1: Line 1:
:''These updates concern Tamarin and related projects only.''
:''These updates concern Tamarin and related projects only.''


'''Meeting Details'''
'''Meeting Details (Changed as of 11/18/08)'''
* 2:00pm Pacific Time (21:00 UTC) on Tuesdays
* 10:00 AM Pacific Time (18:00 UTC) on Tuesdays
** (5PM Eastern US, 11PM Oslo, 6AM (Wed) Seoul, 7AM (Wed) Melbourne)
** 1PM Eastern US, 7PM Oslo, 3AM (Wed) Seoul, 5AM (Wed) Melbourne  
* Location: Tel: 866 705 2554 (us), 913 227 1201 (int’l)
* Location: Tel: 877-220-5439 (US & Canada), +1-408-536-9900(International)
** Passcode: 914008
** Meeting Place ID: 2000
* Duration: 60 minutes
* join irc.mozilla.org #tamarin for attendance taking and questions
* join irc.mozilla.org #tamarin for attendence taking and questions


'''Next meeting's Agenda Items:'''
* TBD


= November 11, 2008 =
'''Next meeting's Agenda Items (3/17/09):'''
* Canceled


= January 27, 2009 Meeting Notes =
== Attendees ==
== Attendees ==
Jeff,  Steven, Brent, Tom, Dan Schaffer, Rick Reitmaier, Rob Winchell, Moh
== Agenda Topics ==
* Status Updates
== Meeting Discussion Notes ==
=== Status Updates ===


* Intel: Moh, Shengnan
Jeff:  
* Mozilla: Andreas, Jim Blandy, Jeff, Rick
* Checked in a verifier refactoring. Some cleanup needed, but wanted to get it in.
* Adobe: Edwin, Steven, Vladimir, Tom H, Leslie
* Put in a pipeline architecture where all code generators are driven off of api (similar to backend nanojit api)


== Agenda Items Discussed ==
* Meeting Logistics (Leslie)
* Verifying the Code Generator (Jim Blandy)
* Proposal on Creating a Shared NJ Repository (Edwin)
* Regular Expression Compilation (Andreas)


== Updates ==
Steven
=== Meeting Logistics (Leslie)===
* Spot bug fixing
* Weekly meetings to move to Tuesdays at 1:00 ET starting next week, 11/18
* Details to be sent to list and updated on the wiki by the end of this week.


=== Verifying the Code Generator (Jim Blandy)===
Dan Schaffer
* Jim came up with this idea while watching Andreas hunt down bugs in TraceMonkey
* Ecma 3 data acceptance tests
* The verifier would pass over the code and verify that all operations being performed are being done on appropriate types
* If anyone sees any failures, send Dan Schaffer an email
* We have a type map that shows what kinds of values are in what places. The verifier would propagate those types forward and it would know the layout of the object. If we found ourselves arriving at some type info, we could verify the type map.
* There may still be some lurking problems
* Reference: George Necula's Proof Carrying Code project
** Provides type annotations for arbitrary machine code. Interesting thing, he found that he caught lots and lots of compiler bugs.
* If the verifier had a type system that was sound, we could ensure that the compiler was not generating code that was unsound.
* Here is the bug associated with this idea: [https://bugzilla.mozilla.org/show_bug.cgi?id=463137 Bug 463137] (TM: TraceMonkey should verify the compiler's output)
* Things that Belongs in nanojit
** Machine code disassemble back to LIR
** Walk LIR things and keep track of how types are moving around.
* However, Nanojit is being used by several different projects (TC, TM, Regular expression compilation).  So the sort of types for this verification would be different in each case. It seems to Jim Blandy that the type system that the client of nanojit provides and nj would make callbacks into type system to do the right thing.
* NJ would have all knowledge of what LIR needs and client would have knowledge of types that the code is operating on.
* Feedback:
** As long as nj can propagate types along copies the only place they get removed from models is function types
** 1 thing to explore is introducing a type for an object where
** Long haul having nj having concept of objects with layouts
* Come up with minimal types to cover what nanojit needs to know (probably put in an interface as opposed to nail down a data structure.)
* Ed ran across a paper to verify the reconstructed IR he will post to channel
* We might want to look at more automated generation of the emitter code.
* Everyone was in agreement that Jim should move forward with this.
* Jim may have it done by 11/12/08.


=== Proposal on Creating a Shared NJ Repository (Edwin)===
Tom Harwood
* Edwin asked for feedback on Graydon's proposal to create a shared nanojit repository.  
* Global optimizer stopped working on this for now
* All felt that the concept was a good one and agreed to go for it.
* Starting to work on verifier and code generators instead
* Jeff’s change broke GO code
* Tom filed a bug on that. Copy Jeff on that but.  


=== Regular Expression Compilation (Andreas)===
* Requires small changes to nj
* Andreas found it to be 4-5x speed up over regular interpreter
* Andreas asked if we were willing to take patch to nanojit? ANSWER: Yes.
* Does it make sense to share the regex compiler itself or just the infrastructure? No harm with code being in nj. Okay with either way, as long as nj is free of spider monkey dependencies. PROPOSAL: Put it in a shared place and use it as a test.
* We want a repository of shared components and nanojit is just a piece of this.
* Andreas to work with Graydon to push changes into nanojit
* Should guard records be in LIR buffer? Maybe move back into native code.
** Decision: Move it back into native code. It is important to generate code and throw the LIR away. Guard record will no longer be patchable.
* Next Steps:
** Andreas to work with Graydon to sumbit guard record shrinking
** Then put guardad records back in native code
* Edwin suggested refine placement of guard records
** Andreas played around with this and it did not make an impact on performance.) Now you can get rid of two code streams, it would simplify the assembler.
* Both patches are up there (they are mutually exclusive). Merge two pages into one page and take it from there.


= Older meetings =
= Older meetings =
* [[Tamarin:WeeklyUpdates/2009-01-27|January 27, 2009]]
* [[Tamarin:WeeklyUpdates/2009-01-013|January 13, 2009]]
* [[Tamarin:WeeklyUpdates/2009-01-06|January 6, 2009]]
* [[Tamarin:WeeklyUpdates/2008-12-16|December 16, 2008]]
* [[Tamarin:WeeklyUpdates/2008-12-09|December 9, 2008]]
* [[Tamarin:WeeklyUpdates/2008-12-03|December 3, 2008]]
* [[Tamarin:WeeklyUpdates/2008-11-18|November 18, 2008]]
* [[Tamarin:WeeklyUpdates/2008-11-11|November 11, 2008]]
* [[Tamarin:WeeklyUpdates/2008-09-30|September 30, 2008]]
* [[Tamarin:WeeklyUpdates/2008-09-30|September 30, 2008]]
* [[Tamarin:WeeklyUpdates/2008-08-26|August 26, 2008]]
* [[Tamarin:WeeklyUpdates/2008-08-26|August 26, 2008]]

Latest revision as of 00:52, 17 March 2009

These updates concern Tamarin and related projects only.

Meeting Details (Changed as of 11/18/08)

  • 10:00 AM Pacific Time (18:00 UTC) on Tuesdays
    • 1PM Eastern US, 7PM Oslo, 3AM (Wed) Seoul, 5AM (Wed) Melbourne
  • Location: Tel: 877-220-5439 (US & Canada), +1-408-536-9900(International)
    • Meeting Place ID: 2000
  • join irc.mozilla.org #tamarin for attendance taking and questions


Next meeting's Agenda Items (3/17/09):

  • Canceled



January 27, 2009 Meeting Notes

Attendees

Jeff, Steven, Brent, Tom, Dan Schaffer, Rick Reitmaier, Rob Winchell, Moh

Agenda Topics

  • Status Updates

Meeting Discussion Notes

Status Updates

Jeff:

  • Checked in a verifier refactoring. Some cleanup needed, but wanted to get it in.
  • Put in a pipeline architecture where all code generators are driven off of api (similar to backend nanojit api)


Steven

  • Spot bug fixing

Dan Schaffer

  • Ecma 3 data acceptance tests
  • If anyone sees any failures, send Dan Schaffer an email
  • There may still be some lurking problems

Tom Harwood

  • Global optimizer stopped working on this for now
  • Starting to work on verifier and code generators instead
  • Jeff’s change broke GO code
  • Tom filed a bug on that. Copy Jeff on that but.


Older meetings