If the most recently used global cache item refers to the same
page, it would be overwritten. This will happen when closing a
paged (PDF/DjVu) document on the same page you opened it, as well
as when opening and closing EPUBs with crengine because it uses
its own cache.
Fixes#3846.
to make koreader on Android more stable
and with these opt params:
```
require("jit.opt").start("sizemcode=64","maxmcode=64", "hotloop=10000")
```
The strategy here is that we only use precious mcode memory (jitting)
on deep loops like the several blitting methods in blitbuffer.lua and
the pixel-copying methods in mupdf.lua. So that a small amount of mcode
memory (64KB) allocated when koreader is launched in the android.lua
is enough for the program and it won't need to jit other parts of lua
code and thus won't allocate mcode memory any more which by our
observation will be harder and harder as we run koreader.
Currently only tested on Ubuntu-touch emulator with framework
ubuntu-sdk-14.10 for armhf.
The ubuntu-touch port is binary compatible with the Kobo port
major changes in this PR are:
1. rename the emulator device to sdl device since both the emulator
and the ubuntu-touch target use libsdl to handle input/output.
2. ubuntu-touch app has no write access to the installation dir so
all write-outs should be in a seperate dir definded in `datastorage`.
the cache would behave badly when the same item was insert()ed twice:
it would add the size twice to memory consumption, but would never substract
it twice when purging the (actually single) object from cache. So the cache
would seem to fill up while in fact it wasn't.
In reflowing scroll mode with 2 pages hinting, 4 full page blitbuffers
and koptcontexts should stay well in cache in the most demanding cases,
with two pages shown on screen and two pages rendered in background.
Since blitbuffer size is halved the size of page, we need cache size
to be 6 times an average reflowed page size.
For Kobo Aura HD which has a resolution of 1440×1080, a reflowed page
could become 1080×4800. So 30MB of cache is demanded for this case.
This PR implements dynamic cache size allocating according to size of
system free memory. By default it will use 20 percent of free RAM with
a clip specified by DGLOBAL_CACHE_SIZE_MINIMUM and
DGLOBAL_CACHE_SIZE_MAXIMUM which are 10MB and 30MB respectively by default.
