On systems that don't have <stdint.h> (i.e., Microsoft, which is
tragically underfunded and cannot spare the resources necessary to
provide and support this header: http://tinyurl.com/absoh8),
SpiderMonkey header files should not introduce definitions for these
types, as doing so may conflict with client code's attempts to provide
its own definitions for these types.
Instead, have jstypes.h define JS{Int,Uint}{8,16,32,64,Ptr} types
based on configure's results, and make jsstdint.h into an uninstalled
header for use within SpiderMonkey that does whatever is necessary to
get definitions for the <stdint.h> types.
The changes to make the appropriate SpiderMonkey .cpp files #include
"jsstdint.h" explicitly are in a separate patch, for ease of review.
At configure time, check for <stdint.h>. If we don't have it, find
integer types of various sizes. On Windows, where we can't run
compilation tests in configure, hard-code definitions suggesting the
use of the built-in __intN types for the exact-size types, and
<stddef.h> for the pointer-sized types.
Use namespace-clean names for the preprocessor macros we define.
Since these types are used in the public JavaScript API, the configure
script needs to place the definitions it finds in js-config.h, the
installed configure-generated header, so it can be used by jsapi.h and
that gang.
New header js/src/jsstdint.h does what it takes to get definitions for
the exact-size and pointer-size integral types. It includes
<stdint.h> when available, uses the types found by configure.in to
define the {,u}int{8,16,32,64,ptr}_t types itself, or uses the __intN
types and the <stddef.h> header.
Remove now-unnecessary and possibly conflicting definitions of intN_t
types from js/src/nanojit/avmplus.h.
LirBuffer has been modified to provide advance warning of
out of memory (OOM) conditions.
A new page is allocated LIR_BUF_THRESHOLD instructions
prior to reaching the end of page. If the page allocation fails,
call to outOmem() will return true. The buffer can still be
safely written to during during this period but it is assumed
the higher level code will catch this condition and handle
it appropriately as writing LIR_BUF_THRESHOLD instructions
past this point will cause a crash.
This opportunity was also taken to re-factor the code for
LirBufWriter making it more platform agnostic.
- All non-LInsp data in the instruction stream is now managed
through structures that overlay the memory region.
- prepFor() was added to replace the multiple
ensureReferenceable() calls for each instruction.
- insCall() was also modified somewhat in that the
arguments are now stored growing downwards from
the position of the pseudo instruction LirCallIns.
CodegenLIR now has LirBuffer checks at the granularity
of each emitXXX() call that is exposed publicly. This seemed
like a reasonable approach since a client could potentially
call at this level indefinitely. If we want to reduce the frequency
of these checks then we'd have to push the check up into the
verifier.
Assembler OOM handling has also changed. The variable
_startingIns was added and contains the location at which
the assembler began writing code for the current
begin/assem/end sequence. If an OOM condition occurs
the assembler will reset the current instruction pointer
to _startingIns, effectively overwriting the code that has
been generated. This allows the assembler to produce
code indefinitely (and without error) until the upper layers
have noticed the error and respond accordingly.
The constant LARGEST_UNDERRUN_PROT was added
and needs to be set to a platform specific value that is
equal to or greater than the number of NIns written for
the largest possible instruction. i.e. you cannot write
more than this number of NIns to the buffer for each
call to underrunProtect().
