Create pre-frozen change records for Object.observe

Create pre-frozen change records for Object.observe

Added a JSChangeRecord bag-of-constants to objects.h and use it to create two custom maps for each context in bootstrapper.cc.

This greatly increases performance (~5x) of the ChangeSummary fuzzer (which tests creating lots of change records).

Before (ms): 4102, 4263, 4219
After (ms): 860, 871, 870

[adamk, 2013-02-04 23:03:20]

Hi Andreas,

I'm not sure whether this is worth submitting, but I wanted to pass it along
since I spent a bit of time Friday hacking it up. It'd be mostly superseded by
speeding up Object.freeze() in general, but it may be worth it in the long term
since we know exactly the layout of these objects ahead of time.

[rafaelw, 2013-02-19 22:20:09]

Can we land this as a near-term fix, and back it out when generalized
Object.freeze is faster?

There are folks that are actually preparing production JS code with support for
O.o that consumes changeRecords. Having it be catastrophically slow makes that
hard for a number of reasons -- but in particular, it makes it hard to do
profiling work.

[rossberg, 2013-02-25 11:06:03]

On 2013/02/19 22:20:09, rafaelw wrote:
> Can we land this as a near-term fix, and back it out when generalized
> Object.freeze is faster?
> 
> There are folks that are actually preparing production JS code with support
for
> O.o that consumes changeRecords. Having it be catastrophically slow makes that
> hard for a number of reasons -- but in particular, it makes it hard to do
> profiling work.

I'm sorry, but I don't think we want to land this. If it was a simple, local
change, and/or addressing a problem with a production feature, then we could
bite, but I'm afraid it is neither.

Plan is that Adam will soon be working on the proper fix for Object.freeze, and
it doesn't even look all that complicated. If the performance is really
unbearable until then, I'd rather disable freezing of change records as a
temporary fix.