64
edits
Tamarin:WeeklyUpdates: Difference between revisions
→Updates
No edit summary |
|||
| Line 38: | Line 38: | ||
** Provides type annotations for arbitrary machine code. Interesting thing, he found that he caught lots and lots of compiler bugs. | ** 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. | * 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: [ | * 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)=== | === 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)=== | === 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 = | ||