These casts in JfrWriterHost<>::write for Ticks and Tickspans are wrong.
./share/jfr/writers/jfrWriterHost.inline.hpp:
write((uintptr_t)JfrTime::is_ft_enabled() ? time.ft_value() : time.value());
write((uintptr_t)JfrTime::is_ft_enabled() ? time.ft_value() : time.value());
First, the cast is on the wrong expression. The precedence for a cast operator is higher than the precedence for a terniary conditional operator. Hence, the cast is applied to is_ft_enabled() rather than the terniary operator's value.
Second, the intended type is a representationally common type for the two possible values (either time.ft_value() or time.value()), which can in theory differ, hence the presumed need for a cast. However, both values are 64bit types, even on a 32bit platform, whereas uintptr_t is a 32bit type on a 32bit platform. So on a 32bit platform this is narrowing off the high half of the value.
Third, there is a lot of code that assumes the types for ft_value() and value() are sufficiently compatible for the terniary operator to find an appropriate common type. That makes semantic sense, and would fail to compile otherwise. So the casts aren't needed for that purpose.
Similar issues for the casts when writing JfrTicks and JfrTickspan.
./share/jfr/writers/jfrWriterHost.inline.hpp:
write((uintptr_t)time.value());
write((uintptr_t)time.value());
These casts should be removed.
./share/jfr/writers/jfrWriterHost.inline.hpp:
write((uintptr_t)JfrTime::is_ft_enabled() ? time.ft_value() : time.value());
write((uintptr_t)JfrTime::is_ft_enabled() ? time.ft_value() : time.value());
First, the cast is on the wrong expression. The precedence for a cast operator is higher than the precedence for a terniary conditional operator. Hence, the cast is applied to is_ft_enabled() rather than the terniary operator's value.
Second, the intended type is a representationally common type for the two possible values (either time.ft_value() or time.value()), which can in theory differ, hence the presumed need for a cast. However, both values are 64bit types, even on a 32bit platform, whereas uintptr_t is a 32bit type on a 32bit platform. So on a 32bit platform this is narrowing off the high half of the value.
Third, there is a lot of code that assumes the types for ft_value() and value() are sufficiently compatible for the terniary operator to find an appropriate common type. That makes semantic sense, and would fail to compile otherwise. So the casts aren't needed for that purpose.
Similar issues for the casts when writing JfrTicks and JfrTickspan.
./share/jfr/writers/jfrWriterHost.inline.hpp:
write((uintptr_t)time.value());
write((uintptr_t)time.value());
These casts should be removed.