Bug 2037089 Comment 7 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Oh nice. That is useful --- there is a part in the rlbox support for 32-bit machines where we need to guess what the upper limit on memory usage is so we can reserve non fragmented space for the sandbox. 64-bit machines don't have to do this.

https://searchfox.org/firefox-main/source/extensions/spellcheck/hunspell/glue/RLBoxHunspell.cpp#53

We'd have to double check our heuristic here if the memory profile got significantly worse. However, it looks like that's not going to be needed.
Oh nice. That is useful --- there is a part in the rlbox support for 32-bit machines where we need to guess what the upper limit on memory usage is so we can reserve non fragmented space for the sandbox. 64-bit machines don't have to do this.

https://searchfox.org/firefox-main/source/extensions/spellcheck/hunspell/glue/RLBoxHunspell.cpp#53

We'd have to double check our heuristic here if the memory profile got significantly worse. However, it looks like that's not going to be needed.

I haven't looked at the code, but at least strict reordering changes sounds like something that can be upstreamed.
Oh nice. That is useful --- there is a part in the rlbox support for 32-bit machines where we need to guess what the upper limit on memory usage is so we can reserve non fragmented space for the sandbox. 64-bit machines don't have to do this.

https://searchfox.org/firefox-main/source/extensions/spellcheck/hunspell/glue/RLBoxHunspell.cpp#53

We'd have to double check our heuristic here if the memory profile got significantly worse. However, it looks like that's not going to be needed.

I haven't looked at the code, but at least struct reordering changes sounds like something that can be upstreamed.

Back to Bug 2037089 Comment 7