New vram usage algorithms, [was Re: 8u40 (already reviewed) post-push notification: RT-36566 - make vram target limit more dynamic]

[Jim Graham]

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