Tamarin:WeeklyUpdates

From MozillaWiki
Jump to navigation Jump to search
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)
  • Location: Tel: 866 705 2554 (us), 913 227 1201 (int’l)
    • Passcode: 914008
  • Duration: 60 minutes
  • join irc.mozilla.org #tamarin for attendence taking and questions

Next meeting's Agenda Items:

  • TBD

November 11, 2008

Attendees

  • Intel: Moh, Shengnan
  • Mozilla: Andreas, Jim Blandy, Jeff, Rick
  • Adobe: Edwin, Steven, Vladimir, Tom H, Leslie

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

Meeting Logistics (Leslie)

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

  • Jim came up with this idea while watching Andreas hunt down bugs in TraceMonkey
  • The verifier would pass over the code and verify that all operations being performed are being done on appropriate types
  • 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.
  • 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: 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)

  • Edwin asked for feedback on Graydon's proposal to create a shared nanojit repository.
  • All felt that the concept was a good one and agreed to go for it.

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 guarded 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).

Older meetings

Retrieved from "https://wiki.allizom.org/index.php?title=Tamarin:WeeklyUpdates&oldid=116308"