mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
Gecko engine for Wine
a70c5b7d48
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(). |
||
---|---|---|
accessible | ||
browser | ||
build | ||
caps | ||
chrome | ||
config | ||
content | ||
db | ||
dbm | ||
docshell | ||
dom | ||
editor | ||
embedding | ||
extensions | ||
gfx | ||
intl | ||
jpeg | ||
js | ||
layout | ||
media | ||
memory/jemalloc | ||
modules | ||
netwerk | ||
nsprpub | ||
other-licenses | ||
parser | ||
plugin/oji | ||
probes | ||
profile | ||
rdf | ||
security | ||
storage | ||
sun-java | ||
testing | ||
toolkit | ||
tools | ||
uriloader | ||
view | ||
webshell | ||
widget | ||
xpcom | ||
xpfe | ||
xpinstall | ||
xulrunner | ||
.hgignore | ||
.hgtags | ||
aclocal.m4 | ||
allmakefiles.sh | ||
client.mk | ||
client.py | ||
configure.in | ||
LEGAL | ||
LICENSE | ||
Makefile.in | ||
README.txt |
For information on how to build Mozilla from the source code, see: http://developer.mozilla.org/en/docs/Build_Documentation To have your bug fix / feature added to Mozilla, you should create a patch and submit it to Bugzilla (http://bugzilla.mozilla.org). Instructions are at: http://developer.mozilla.org/en/docs/Creating_a_patch http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree If you have a question about developing Mozilla, and can't find the solution on http://developer.mozilla.org, you can try asking your question in a mozilla.* Usenet group, or on IRC at irc.mozilla.org. [The Mozilla news groups are accessible on Google Groups, or news.mozilla.org with a NNTP reader.] You can download nightly development builds from the the Mozilla FTP server. Keep in mind that nightly builds, which are used by Mozilla developers for testing, may be buggy. Firefox nightlies, for example, can be found at: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/