JDK-8063154 : Checked in jvmti.h not in sync with generated jvmti.h
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-11-06
  • Updated: 2016-12-14
  • Resolved: 2016-11-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b143Fixed
Related Reports
Duplicate :  
JDK-6784084 - jvmti.h created during the build differs from file in jdk repo and should not
Relates :  
JDK-8147943 - jvmti.h generated with GPL header
Description
The checked jvmti.h (jdk/src/java.base/share/native/include/jvmti.h) is not in sync with the jvmti.h generated in the hotspot build:

<     JVMTI_VERSION = 0x30000000 + (1 * 0x10000) + (2 * 0x100) + 1  /* version: 1.2.1 */
---
>     JVMTI_VERSION = 0x30000000 + (1 * 0x10000) + (2 * 0x100) + 3  /* version: 1.2.3 */

It's the checked in version that goes into the generated images.

In the old build then it used to warn if the checked-in jvmti.h doesn't match the header file generated in the hotspot build. It's possible that we lost this feature when moving to the new build.

An alternative to just doing a once-off sync up of jvmti.h would be to see if the build can can generated to use the generated jvmti.h and remove the checked-in copy.
Comments
We had a short comments exchange with Erik in the recently filed bug: https://bugs.openjdk.java.net/browse/JDK-8167078 and figured that Erik has already done needed make files refactoring (tracked by JDK-8150736). Erik also already has a working fix for using the generated jvmti.h instead of the checked-in header. So that we decided that Erik will take care about this bug (thanks, Erik!).
06-10-2016
I just meant that JDK-8147943 currently sits in hs and JDK-8150736 is in dev. It shouldn't take more than a week to get them together.
06-10-2016
There isn't any short term need to address this so address it in JDK 10 or whenever we have one repo is fine.
06-10-2016
I will fix this by changing the build to use the generated file only. Need to wait for JDK-8147943 and JDK-8150736 to meet in the same forest first though.
06-10-2016
Just to add, Serguei fixed the XSL as part of the updates to JVM TI for modules. This means that the generated jvmti.h no longer has tabs and other white space issues that caused it to differ to the checked in jvmti.h. At this time, the only difference between the checked in and generated jvmti.h is the copyright header (JDK-8147943). I assume we need to sort out the copyright header issue before we can dropping the checked in jvmti.h
13-05-2016
Yes, I assume it is still a problem as we have not made any attempt at fixing it. The new build system is still mimicking the old in these kinds of regards.
13-05-2016
Is this still a problem with the new hotspot build system?
13-05-2016
One other issue is that the generated jvmti.h has tabs and so needs to be run through the normalize script each time.
26-01-2016