Our goal in TraceMonkey is to compile type-specialized code. To do that, TraceMonkey needs to know the types of variables. But JavaScript doesn’t have type declarations, and we also said that it’s practically impossible for a JS engine to figure out the types ahead of time. So if we want to just compile everything ahead of time, we’re stuck.

So let’s turn the problem around. If we let the program run for a bit in an interpreter, the engine can directly observe the types of values. Then, the engine can use those types to compile fast type-specialized code. Finally, the engine can start running the type-specialized code, and it will run much faster.

There are a few key details about this idea. First, when the program runs, even if there are many if statements and other branches, the program always goes only one way. So the engine doesn’t get to observe types for a whole method — the engine observes types through the paths, which we call traces, that the program actually takes. Thus, while standard compilers compile methods, TraceMonkey compiles traces. One side benefit of trace-at-a-time compilation is that function calls that happen on a trace are inlined, making traced function calls very fast.

Second, compiling type-specialized code takes time. If a piece of code is going to run only one or a few times, which is common with web code, it can easily take more time to compile and run the code than it would take to simply run the code in an interpreter. So it only pays to compile hot code (code that is executed many times). In TraceMonkey, we arrange this by tracing only loops. TraceMonkey initially runs everything in the interpreter, and starts recording traces through a loop once it gets hot (runs more than a few times).

Tracing only hot loops has an important consequence: code that runs only a few times won’t speed up in TraceMonkey. Note that this usually doesn’t matter in practice, because code that runs only a few times usually runs too fast to be noticeable. Another consequence is that paths through a loop that are not taken at all never need to be compiled, saving compile time.

Finally, above we said that TraceMonkey figures out the types of values by observing execution, but as we all know, past performance does not guarantee future results: the types might be different the next time the code is run, or the 500th next time. And if we try to run code that was compiled for numbers when the values are actually strings, very bad things will happen. So TraceMonkey must insert type checks into the compiled code. If a check doesn’t pass, TraceMonkey must leave the current trace and compile a new trace for the new types. This means that code with many branches or type changes tends to run a little slower in TraceMonkey, because it takes time to compile the extra traces and jump from one to another.

so so sexy.

How TraceMonkey traces

Bruce Springsteen is underrated.

Bruce Springsteen - Brilliant Disguise

Firefox: I like that you made hyperlink in "View source" clickable links in 3.5. But you stopped short! Now why can't I have the standard hyperlink context menu?

Where's my copy location, open in new window, etc? That would rock.

Also:

-Show me a copyable representation of the URL of the source code I'm currently looking at.

-Have a new "Close all open view source windows" feature. I commonly have a dozen or more "View Source" windows open and its a pain managing them.

-For that matter, show me "when" the source snap shot that the view source window shows was taken. When I'm doing a manual XSS demo Its annoying trying to find the most recent view source window for the audience.

If you use a bookmarklet on Facebook and it calls window.alert(), it doesn't quite do what you expect. They've re-defined the entire alert() method - it will pop up a box, but it will also behind the scenes send what you tried to pop up to the server!?! Look at Facebook's alert code (shown in an appropriate setting, of course):

More non-malicious use of function clobbering, though not sure why this is in production code.

This example amuses me. In our book Ajax Security we clobber the alert() function as an example and show it in Opera to prove it works on the strictest of browsers.

good stuff.

Facebook monitors your alert() usage

Ways to know you are working for an offensive security company:

1- You website consists of an "about us" page, a PGP key, and a contact page.
2- The company has "highly skilled information security veterans serving the unique requirements of the United States Government."
3- Your Robots.txt disallows all crawling and indexing.
4- Your work product has the fun and nebulous title of "vulnerability information."

Interesting overview of the low-tech-but-highly-successful hack that spilled 310 confidential Twitter documents into the hands of the press.

The Anatomy Of The Twitter Attack

... maybe

In ur quantum box

There are few things in life funnier than 2 southerners trying to explain "Talladega Nights" to an Israeli.

... ... what is shake and bake? ... what is NASCAR?

Only entrepreneurs ready to pitch can attend.
No observers. No press. No lurkers.

How does it work?
(1) Show up with a 3-minute elevator pitch.
(2) We'll draw names randomly. If you're called, you're on. Give your pitch.
(3) Powerpoint optional! The best pitches have no props, no notes, no teleprompter. It's all you.
(4) When done, the dungeonmasters will ask you questions about your company or idea. They'll pick it apart and leave you whimpering.
(5) Listen, improve your pitch and come back for more next time.

Remember, investors and prospects will never tell you why your pitch sucks. But we will !

this is an interesting idea. An environment to fail spectacularly and get feed back in the process.

Atlanta Startup Gauntlet - Toastmasters for Entrepreneurs

... be able take a Rorschach test :-)

And now you'll never....