RFR(13): JDK-8216263: Add historical data for JDK 12
Jan Lahoda
jan.lahoda at oracle.com
Thu Jan 17 18:53:23 UTC 2019
On 17.1.2019 17:58, Jonathan Gibbons wrote:
> Re:
>
> 36 # The checkout must not have any local changes that could interfere with the new data. In particular,
> 37 # there must be absolutely no changed, new or removed files under the ${JDK_CHECKOUT}/make/data/symbols
> 38 # directory.
>
> That seems like a simple check that could be incorporated into the
> script itself.
>
> But, it also seems reasonable to separate enhancements like that from
> the specific issue here, to add historical data for 12.
Ok. Sent as:
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html
And limited this patch to the historical data only:
http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/
Thanks,
Jan
>
> -- Jon
>
> On 1/17/19 8:51 AM, Jan Lahoda wrote:
>> Hi Joe,
>>
>> On 17.1.2019 02:13, Joseph D. Darcy wrote:
>>> Hi Jan,
>>>
>>> On 1/8/2019 2:13 AM, Jan Lahoda wrote:
>>>> Hi Joe,
>>>>
>>>> Thanks for the comments, some responses inline. Updated webrev:
>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/
>>>>
>>>> On 7.1.2019 23:51, Joseph D. Darcy wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote:
>>>>>> Hi,
>>>>>>
>>>>>> To make --release 12 work, we need to add historical data for JDK 12.
>>>>>> The current historical data is based on:
>>>>>> $ javac -fullversion
>>>>>> javac full version "12-ea+26"
>>>>>>
>>>>>> We may need to update the data once JDK 12 is out to cover any
>>>>>> changes
>>>>>> to the APIs that might happen.
>>>>>>
>>>>>> The patch also adds a simple (shell) script to generate the data, so
>>>>>> all that was needed to generate the data was:
>>>>>> $ cd make/data/symbols
>>>>>> $ sh generate-data <path-to-JDK-12>
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263
>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>>>>>>
>>>>>> How does this look?
>>>>>
>>>>> If the overhead is small enough and we don't mind a few updates to the
>>>>> JDK N+1 data, than perhaps the generation of this information could be
>>>>> included as part of the start of JDK N+1 activities.
>>>>
>>>> That would be perfect!
>>>>
>>>>>
>>>>> I suggest a more extensive description of how to
>>>>> make/data/symbols/generate-data. For example, this builds the data for
>>>>> the current release independent of whether or not the current release
>>>>> has already had its data generated, correct?
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>> Concretely, if JDK N+1 has already forked, what is the proper way
>>>>> to get
>>>>> data for JDK N? Likewise, how should a re-build of the data for JDK
>>>>> N be
>>>>> done?
>>>>
>>>> What exactly should be there? To the existing description:
>>>> # to generate (add) data for JDK N, do:
>>>> # cd make/data/symbols
>>>> # sh generate-data <path-to-JDK-N>
>>>>
>>>> I've added (in .01):
>>>> # to regenerate the data for JDK N, run the above commands again
>>>>
>>>> What more should be there?
>>>>
>>>
>>> I'd appreciate somewhere to have a textual discussion of how
>>> make/data/symbols/symbols should be updated, the A = 10, B = 11, etc.
>>> convention, what else need to be done to generate the contents of this
>>> changeset.
>>>
>>> The <patch-to-JDK-N> is the contents of the build directory?
>>>
>>> In general, a description of how the data of JDK N should be added to
>>> JDK (N+1).
>>
>> I've added more textual description to the script, an updated webrev
>> is here:
>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/
>>
>> Jan
>>
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>>
More information about the compiler-dev
mailing list