Thread dump report "waiting to re-lock in wait()" shows incorrectly

JDK-8130448 made a number of improvements to the thread dump information, including separating the case of a thread actually waiting to be notified in wait() versus a thread waiting to re-acquire the monitor so it can return from wait(). However it appears the conditions for reporting this are not strong enough. If we take a thread dump of pretty much any running Java app we will normally find the Finalizer thread and the ReferenceHandler thread waiting for work. But the thread dump shows:

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007ffa2c518800 nid=0x37c8 in Object.wait() [0x00007ffa182ef000]
   java.lang.Thread.State: WAITING (on object monitor)
   JavaThread state: _thread_blocked
Thread: 0x00007ffa2c518800 [0x37c8] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
   JavaThread state: _thread_blocked
at java.lang.Object.wait(Native Method)
- waiting on <0x00000001bb41b350> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
- waiting to re-lock in wait() <0x00000001bb41b350> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:172)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007ffa2c514000 nid=0x37c7 in Object.wait() [0x00007ffa183f0000]
   java.lang.Thread.State: WAITING (on object monitor)
   JavaThread state: _thread_blocked
Thread: 0x00007ffa2c514000 [0x37c7] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
   JavaThread state: _thread_blocked
at java.lang.Object.wait(Native Method)
- waiting on <0x00000001bb41b508> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:516)
at java.lang.ref.Reference.tryHandlePending(Reference.java:193)
- waiting to re-lock in wait() <0x00000001bb41b508> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:155)

In both cases the "waiting to re-lock in wait()" is incorrect - that should only ever been seen in connection with the "at java.lang.Object.wait(Native Method)" frame.