Originally it would complain about the resources being locked on every
frame since they remained locked. More recently we installed a "report
and forgive" mechanism that reports that the locks were outstanding
(because that is a bug), but then it conditionally can either mark the
resource as untrackable or it simply unlocks all of the locks. Either
way, you should now only see the messages once since we either "fix" the
problem or we mark it so that we don't complain on the next frame.
We use the "unlock all the locks" part of the mechanism if the render
loop fielded an Exception from the rendering code. When an exception
happens then it is very probably that some resources were left locked.
Arguably though the code really should be doing try/finally around the
locks to prevent locks even in the case of an exception, but it is very
hard to do that in some cases given the chain of events that happens
between the lock and unlock.
We use the "just mark it and stop complaining but leave it locked" part
of the mechanism if there was no exception. It represents an unbalanced
lock/unlock in the code or it may represent some code that wants to have
a resource locked across multiple frames on purpose without registering
it as such. If that code had a plan to eventually unlock the texture
then there really is no leak, but it should have registered the resource
as being locked long term and it didn't. If this a case of an
unbalanced lock/unlock in our code, then the resource could very well
leak, but eventually garbage collection may step in and reclaim the
resource non-aggressively as well...
...jim
On 9/2/14 9:45 AM, Kevin Rushforth wrote:
Jim can provide a more detailed answer, but in general, yes it would
indicate a (likely small) resource leak. The interesting part being:
2 resources locked (1,7%)
and later
5 resources locked (3,7%)
-- Kevin
Mike Hearn wrote:
OK. What is the impact of the bugs? I haven't noticed any obvious
problems when it occurs. Sounds like a GPU resource leak of some kind?
On Tue, Sep 2, 2014 at 6:24 PM, Kevin Rushforth
<kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> wrote:
Ideally we need a reproducible test case with a set of
instructions to demonstrate the bug. I know this can be a
challenge for an intermittent bug.
-- Kevin
Mike Hearn wrote:
I see this message quite frequently. What sort of things do you
need in these bug reports?
On Tue, Sep 2, 2014 at 5:38 PM, Kevin Rushforth
<kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>>
wrote:
Any time you see this message, it isn't your fault. Rather
this is a bug in the JavaFX runtime. Please file a JIRA.
-- Kevin
Mario Ivankovits wrote:
Hi!
Is there anything further I can do to see which resources
are locked so I can see if this is my fault and to
release them properly?
How to interpret this output?
Thanks for any info.
Outstanding resource locks detected:
ES2 Vram Pool: 76.571.592 used (28,5%), 76.571.592
managed (28,5%), 268.435.456 total
118 total resources being managed
average resource age is 540,5 frames
57 resources at maximum supported age (48,3%)
6 resources marked permanent (5,1%)
2 resources have had mismatched locks (1,7%)
2 resources locked (1,7%)
79 resources contain interesting data (66,9%)
0 resources disappeared (0,0%)
Outstanding resource locks detected:
ES2 Vram Pool: 141.193.956 used (52,6%), 141.193.956
managed (52,6%), 268.435.456 total
136 total resources being managed
average resource age is 467,8 frames
57 resources at maximum supported age (41,9%)
6 resources marked permanent (4,4%)
5 resources have had mismatched locks (3,7%)
5 resources locked (3,7%)
82 resources contain interesting data (60,3%)
0 resources disappeared (0,0%)
Best regards,
Mario
