RFR (XS) 8161280 - assert failed: reference count underflow for symbol

[David Holmes]

Hi Ioi,

On 23/08/2016 8:01 PM, Ioi Lam wrote:
> https://bugs.openjdk.java.net/browse/JDK-8161280
> http://cr.openjdk.java.net/~iklam/jdk9/8161280-symbol-refcount-underflow.v01/
>
>
> Summary:
>
> The test was loading a lot of JCK classes into the same VM. Many of the
> JCK classes refer to "javasoft/sqe/javatest/Status", so the refcount (a
> signed short integer) of this Symbol would run up and past 0x7fff.
>
> The assert was caused by a race condition: the refcount started with a
> large (16-bit) positive value such as 0x7fff, one thread is decrementing
> and several other threads are incrementing. The refcount will end up
> being 0x8000 or slightly higher (limited to the number of concurrent
> threads that are running within a small window of several instructions
> in the decrementing thread, so most likely it will be 0x800?).
>
> As a result, the decrementing thread found that the refecount is
> negative after the operation, and thought that an underflow had happened.
>
> The fix is to ignore any value that may appear in the [0x8000 - 0xbfff]
> range and do not flag these as underflows (since they are most likely
> overflows -- overflows are already handled by making the Symbol permanent).

This seems fine to me. Essentially we hit overflow but it appeared as 
underflow. So we extend the range of the signed value as-if it were 
unsigned but only to a point. Once we hit that point, even if 
overflowing, it will be flagged as an underflow. Another way to handle 
this would be to start from a negative initial value and allow the 
counter to cover the range from there, through zero up to the maximum 
positive value. But the end result is the same so I am fine with this.

Thanks,
David

> Thanks
> - Ioi
>
>