RFR 8217647: JFR: wrong recording on 32-bit systems

[Erik Gahlin]

Looks good.

Erik

> On 20 Feb 2019, at 15:15, Boris Ulasevich <boris.ulasevich at bell-sw.com> wrote:
> 
> Hi all,
> 
> Here is a new review for 32-bit systems JFR recording issue. Types was updated to specify variables size explicitly to avoid jfr recording format mismatch. Many thanks to Markus Gronlund who worked on this fix.
> 
> http://cr.openjdk.java.net/~bulasevich/8217647/webrev.02
> https://bugs.openjdk.java.net/browse/JDK-8217647
> 
> Tested on x64, x86, arm32.
> 
> regards,
> Boris
> 
> On 30.01.2019 8:41, David Holmes wrote:
>> Hi Boris,
>> Redirecting to hotspot-jfr-dev.
>> I can't tell from all the changes exactly where the conflict arises, but the JFR folk are in the best position to identify what should always be 64-bit what should follow the pointer size.
>> Cheers,
>> David
>> -----
>> On 30/01/2019 2:43 am, Boris Ulasevich wrote:
>>> Hi,
>>> 
>>> Can I please have a review for the following FlightRecorder fix:
>>> 
>>> http://cr.openjdk.java.net/~bulasevich/8217647/webrev.01
>>> https://bugs.openjdk.java.net/browse/JDK-8217647
>>> 
>>> The issue is about intptr_t/jlong size mismatch on 32-bit systems. The essence of the fix is is to specify jlong type implicitly when storing data to jfr recording, plus minor types rearrangement was done to avoid unnecessary type conversions.
>>> 
>>> Testing: JFR tests on Linux x64/x32/arm64/arm32, Mach5, Mission Control.
>>> 
>>> thanks,
>>> Boris