518744 - TM: mark and rewind dataAlloc

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Graydon Hoare :graydon]

Attachment: sketch of marker guard class

The attached patch begins implementing mark/commit/rewind on the dataAlloc as suggested in the tail end of bug 497009.

It doesn't *quite* work yet because some quantity of objects (I think fragments, which are recycled, and possibly their entry typemaps?) should actually not be discarded when compilation fails. So we'll need another allocator for their lifecycle.

Anyway, thought I'd post this to show what I have in mind. Valgrind will help me work out the remaining correct lifecycles :)

Comment 1

[Andreas Gal :gal]

Just rewind() instead of rewind_to() imo. Maybe you can allocate those things before the mark() to make sure they stick around?

Comment 2

[Graydon Hoare :graydon]

Attachment: Update the patch

This patch introduces *another* allocator, the markAlloc, which is the "mark-and-rewind portion" of what was formerly living in dataAlloc. Better names for the lot of them welcome.

After introducing this allocator, I began shifting different metadata -- allocation-by-allocation -- into it, checking that I wasn't making anything crashy along the way. Crude, I know, but effective.

The results on box2d are pleasingly dramatic. It can still hit pathological cases -- this is a very noisy test -- but in general the average execution tightens right up around the optimal case (4s) with only a single overfull-cache event, and nearly double the quantity of native code in the cache at flush events.

Notable fact: it seems like we're allocating about 3x as much metadata as real machine code. Even with the mark thing only holding onto the *live* metadata. markAlloc is generally 12mb on overflow, codeAlloc generally 4mb (dataAlloc is the much smaller remainder, like 400k, but all it's holding at this point are fragments and treeinfos).

We might consider more space-profiling of the metadata objects to figure out where all that space is going.

Comment 3

[Andreas Gal :gal]

Comment on attachment 402971 [details] [diff] [review]
Update the patch

markAlloc is really weird. How about recordAlloc?

Comment 4

[Graydon Hoare :graydon]

I dislike "recordAlloc", it's lifecycle is explicitly *longer* than a single recording session. After consultation on IRC, I took jorendorff's advice and went with "traceAlloc". Also added a comment explaining the lifecycles.

http://hg.mozilla.org/tracemonkey/rev/7f846ee36343

Comment 5

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/7f846ee36343