Printing bug RT-36178 reported a failure to print
plus messages about locked resources from the resource pool tracking code ..
====
Outstanding resource locks detected:
J2D Texture Pool: 9,846,784 used (15.2%), 9,846,784 managed (15.2%), 64,880,640 total
D3D Vram Pool: 21,325,748 used (7.9%), 21,325,748 managed (7.9%), 268,435,456 total
54 total resources being managed
average resource age is 1.9 frames
0 resources at maximum supported age (0.0%)
6 resources marked permanent (11.1%)
4 resources have had mismatched locks (7.4%)
4 resources locked (7.4%)
16 resources contain interesting data (29.6%)
0 resources disappeared (0.0%)
===

The failure to print is one bug but the lock messages are something else

The resource management code uses a single system-wide pool
and all resources from all factories are tracked there.
The J2D printing pipeline does properly lock & unlock the resources
however its operating on an off-screen thread, aysnchronous to
the checks run by the resource management code which runs
based on the on-screen pulse. Thus it randomly sees whatever
resources are currently in use in printing on the other thread.

There are several issues here
1) The printing of the warnings is on by default - perhaps it should not be.
2) The resource pool should perhaps be per-factory
3) The resource pool should perhaps somehow take into account the
thread on which a resource was allocated and count it only as leaked
if the render thread allocated it. That would ignore most of what
printing allocates and may need refinement
4) The ManagedResource class uses a HashMap. Perhaps it should be
a ConcurrentHashMap, or be local to a thread.