NJ merge: x86 bits and pieces

VERIFIED FIXED

Status

Tamarin
Baseline JIT (CodegenLIR)
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: graydon, Assigned: Rick Reitmaier)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Created attachment 406363 [details] [diff] [review]
mostly harmless

A little more divergence-reduction from TM. About the only "surprising" bit is the large underrun protect value; this is due to our use of LIR_xtbl, which needs large-ish contiguous blocks.
I for one would dearly love a comment explaining the 3200 value.  I've looked at it several times and still have no idea where it comes from.
(Reporter)

Comment 2

9 years ago
It comes from bug 475115. I imagine it was chosen as "something big but not the size of a single page", on the (no longer true) assumption that page-size is some kind of natural limit in the allocation system.

What we now have is weirder. The CodeAlloc acquires slabs in some multiple of pages (on x86, 16-at-a-time) but it then carves them *up* into minimum-sized allocations, and it takes the minimum *from* the LARGEST_UNDERRUN_PROT value. This means that we are *potentially* wasting ~3000 bytes (nearly 1/16 of our code memory) at the end of each slab of native code, by having the minimum allocation size set so large. 

We should talk to dmandelin about this when he gets back. Meanwhile I don't think it does intolerable harm. We're aiming to dispose of xtbl anyway.
(Assignee)

Comment 3

9 years ago
pushed http://hg.mozilla.org/tamarin-redux/rev/e94a172bdafa
without the underrun prot change.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.