Usage of u4 as a type for thread_id cause a compilation error on platform, where thread_id is a pointer (e.g. FreeBSD) and could lead to unpredictable data loss on all 64bit platforms.


/usr/home/dms/ESC/hotspot-rt/hotspot/src/share/vm/gc_implementation/shared/gcTraceSend.cpp:112:
error: invalid conversion from 'pthread*' to 'u4'

/usr/home/dms/ESC/hotspot-rt/hotspot/src/closed/share/vm/jfr/jfrEvent.hpp:60:
error: cast from 'pthread*' to 'u4' loses precision


On 2013-08-07 03:30, David Holmes wrote:
> On 7/08/2013 6:11 AM, Dmitry Samersoff wrote:
>> Hi Everyone,
>>
>> I'd checked FreeBSD build for JDK-8021771 and got an error:
>>
>> (all noise are filtered out)
>>
>> /usr/home/dms/ESC/hotspot-rt/hotspot/src/closed/share/vm/jfr/jfrEvent.hpp:60:
>>
>> error: cast from 'pthread*' to 'u4' loses precision
>>
>> *I'm surprised why this error not appears on other platforms.*
>
> I think you will find that on most platforms thread_id_t maps to a
> platform thread type that is an integer type not a pointer type. Even so
> the code you refer to is wrong. There is other code that assumes the
> type is "long" so 32-bit on ILP32 and 64-bit on LP64. These thread types
> are supposed to be opaque so we should never be printing them the way we
> do but ...
>
>> Changing u4 to u8 solves the problem for my case, but I'm not sure is it
>> a correct fix.
>
> It seems a safe change to make. It just means on 32-bit that the id will
> potentially be printed in a 64-bit format (depending on write() actually
> does).