Some interesting changes for developers to note with this fix:
- Previously (pre-8.0) we added 2 parameters to control our vram usage:
-Dprism.maxvram=NNN[kmg]
-Dprism.targetvram=NNN[kmg]
- Our implementation was fairly ham-handed, if you ever needed more than
the target we would thrash about trying to keep freeing anything that
wasn't tied down to stay under it and we'd do this on every allocation.
There was no "growing the target" as the tide of vram usage raised and
if you ever reached a point where you were using more than the target
amount on each frame then you probably would see a hit in fps as we
struggled to stay below it (even if you didn't use more than "max").
- The default limits were modest because they provided the only
backpressure against just allocating new vram on every operation with no
attempts to free unused blocks. The defaults were max=256m,
target=192m. Most apps wouldn't even notice those limits, but
media-intensive apps might have run into the limit.
- Due to the ham-handed algorithm we had to choose the defaults low
enough to provide enough back-pressure that even simple apps didn't
become frame-buffer wasted memory hogs and yet high enough to enable
media-rich apps.
- You could watch our attempts to stay under the target with:
-Dprism.pooldebug=true (prints out info on cleanup attempts)
-Dprism.poolstats=true (prints out vram usage on every frame)
------------------
The new system is a bit more flexible. In particular:
- target will grow (up to max) as we use more vram and don't find
anything (un)useful to free
- defaults are now max=512m, target=64m
- You will now see messages about growing the vram target with
-Dprism.verbose=true
- the lower initial target keeps some back-pressure so that we don't
keep a lot of stale vram around so hopefully our vram usage for regular
apps will be lower now (most apps would "free-wheel" up to the default
target of 192m, but now will likely stay well and happily under 64m).
- the higher max setting means some more media-heavy apps are now
possible without having to tweak the settings. We no longer need a low
"max" setting to keep simple apps small.
- the floating target that rises as you use more vram for media and
complicated effects means "target" doesn't end up being "really a
maximum in practice because you won't like the results if you exceed it"
like it is now. The target "bumps" will happen easily with just enough
back-pressure to make sure we aren't raising it when there are unused
textures wasting space - similar to the Java heap growth.
- Hopefully this is all transparent, but if you see something odd let us
know...
...jim
On 10/10/14 2:36 AM, Jim Graham wrote:
Kevin already reviewed this fix during a discussion on the Jira issue
(see the comments), but I realized after I pushed that I never sent out
a public request for reviews to the list...
Jira: https://javafx-jira.kenai.com/browse/RT-36566
webrev: http://cr.openjdk.java.net/~flar/RT-36566/webrev.02/
There was one minor change after that webrev which was to make 2 new
variables final as per the final +1 review comment...
...jim
