jdk9/hs is CLOSED

[David Holmes]

I think a few things need clarifying here!

On 13/05/2016 7:34 AM, Vladimir Kozlov wrote:
>>> The more interesting question is if Oracle’s rules should also apply to
>>> non-shared code changes to ports that Oracle does not maintain.
>
> No, it does not apply to not-shared code. Jesper's statement is correct.
> It is internal Oracle's process related only to produces we support.

The OpenJDK JDK 9 project defines its schedule and milestones:

http://openjdk.java.net/projects/jdk9/

Schedule

     2016/05/26 		Feature Complete
     2016/08/11 		All Tests Run
     2016/09/01 		Rampdown Start
     2016/10/20 		Zero Bug Bounce
     2016/12/01 		Rampdown Phase 2
     2017/01/26 		Final Release Candidate
     2017/03/23 		General Availability

and the definition of FC is:

Feature Complete — All features have been implemented and integrated 
into the master forest, together with unit tests.

So these are OpenJDK rules _not_ Oracle internal rules.

However, it is unclear what set of platforms/ports the "Java SE 9 
Platform" consists of. The JEP process, as far as I can see, makes no 
mention of whether completion/integration of a JEP requires it to be 
done for all platforms:

http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

If it is not a requirement (which to me it seems not to be) then it is 
very unclear where the "porting" of a JEP to other platforms fits in the 
overall scheme of things. Even less clear if considering only a 
performance related aspect of the JEP, such as support for intrinsic 
operations.

Where things are also less well-defined is how the schedule is managed 
in relation to the non-master forests. The fact that jdk9/hs exists and 
pushes up to jdk9/dev, which in turn pushes up to jd9/jdk9 Master is not 
visible in the schedule (nor anywhere on the OpenJDK site AFAICS) - so 
the forest "operators" have to work backwards to determine how the 
ad-hoc rules of each forest have to be adjusted to meet the overall 
project deadlines. On that front I was sure I had seen some earlier 
announcement about the need for all FC changes to be into jdk9/hs by May 
10 (which actually became May 11).

The closure of jdk9/hs temporarily is not directly related to FC or the 
FC processes other than we have a deadline we need to meet. AFAICS this 
is the third time, in recent history, we have closed the hotspot forests 
(was hs-rt previously) while we stabilize things ready for pushing up.

> We discussed this issue at the end of last year (for original FC date):
>
> "One question is whether changes to platforms we do not build and test
> (specifically, aix/ppc and the open aarch64 port) must abide strictly by
> the FC rules, or if we can be more lenient in accepting and integrating
> such changes. General consensus is that given that we're not
> building/testing them, clean changes which do not impact us can be
> integrated."

To me that's more of a "we can rubber stamp post FC integration requests 
for that kind of work", not a "the rules don't apply to that kind of 
work". But that said, the post FC approval process, as with all the 
milestone related approval processes, does seem to be an Oracle internal 
process, as it is not mentioned anywhere in relation to the OpenJDK JDK 
9 project that I can see. So some clear information on that process and 
its scope/applicability would be beneficial for everyone.

Thanks,
David
-----

> Regards,
> Vladimir
>
> On 5/12/16 2:08 PM, Jesper Wilhelmsson wrote:
>> Den 12/5/16 kl. 21:39, skrev Christian Thalinger:
>>>
>>>> On May 12, 2016, at 5:17 AM, Jesper Wilhelmsson
>>>> <jesper.wilhelmsson at oracle.com
>>>> <mailto:jesper.wilhelmsson at oracle.com>> wrote:
>>>>
>>>> Den 12/5/16 kl. 16:52, skrev Andrew Haley:
>>>>> On 05/12/2016 03:12 PM, Jesper Wilhelmsson wrote:
>>>>>> Den 12/5/16 kl. 16:10, skrev Andrew Haley:
>>>>>>> On 05/12/2016 03:06 PM, Christian Tornqvist wrote:
>>>>>>>> FC means that no RFE/Features can be pushed without approval
>>>>>>>> from the JDK 9
>>>>>>>> Release Team. The updated schedule was published to the OpenJDK
>>>>>>>> community in
>>>>>>>> December last year by Mark Reinhold.
>>>>>>>
>>>>>>> You're not helping very much.  Or rather, you're restating what I've
>>>>>>> heard already but I don't know what that means.  Is finishing off
>>>>>>> the
>>>>>>> compact string intrinsics for AArch64 a RFE/Feature or not?  I don't
>>>>>>> know.  As far as I'm concerned it's a work in progress, which
>>>>>>> started
>>>>>>> some time ago.
>>>>>>
>>>>>> Do you have a JBS ID for this work?
>>>>>
>>>>> I thought so, but I can't see it.  I've been tending to create ad-hoc
>>>>> bugs for each part of the work.  But the need for it is implied by JEP
>>>>> 254: Compact Strings.  So you're perhaps telling me that if I had
>>>>> known that it was necessary to get this done, I should have created
>>>>> one?
>>>>
>>>> I was mainly looking for something to read to try to figure out if
>>>> this is an
>>>> enhancement or a bug. From your description it could be either.
>>>
>>> It’s an enhancement.  As far as I know Compact Strings works fine
>>> without
>>> compiler intrinsics; it’s just slow.
>>
>> Thanks for clarifying that!
>>
>>> The more interesting question is if Oracle’s rules should also apply to
>>> non-shared code changes to ports that Oracle does not maintain.
>>
>> That's a very interesting question indeed! Part of the answer needs to
>> be a definition of what is Oracle's rules and what is OpenJDK rules.
>> As far as I know there are very little (if anything) defined
>> on the OpenJDK web regarding rules around pushes and how to work with
>> bugs in JBS. I don't think the fact that we have a triage process is
>> even mentioned anywhere.
>>
>> Is the lack of documentation the same as no rules?
>>
>> FC, RDP, ZBB etc? Are these defined outside Oracle? Do we expect
>> OpenJDK contributors to respect these?
>>
>> Anyhow, the fact remains that changes pushed to jdk9/hs after we have
>> taken the snapshot will not get into jdk9/jdk9 before FC simply
>> because we will not be able to integrate them in time. If this
>> matters or not, I don't know.
>>
>> As I wrote in my first response:
>>
>> "If you are changing code that is not supported by Oracle - i.e. code
>> that we don't test in our internal testing, there should be no issues
>> getting this code into jdk9/hs. However, if you want the
>> code to get into jdk9/jdk9 before FC you'd have to push asap. Once we
>> take the snapshot to start PIT no more changes from jdk9/hs will make
>> it to jdk9/jdk9 before FC."
>>
>> /Jesper
>>
>>>
>>>>
>>>> JEP 254 is clearly a new feature and as such should be integrated
>>>> before FC.
>>>> It was integrated in November 2015. Is it a bug that the parts you
>>>> are fixing
>>>> now doesn't work..? I don't know.
>>>>
>>>> You will need a JBS ID to push your changes anyway so I suggest you
>>>> create a
>>>> bug for this (and make it a "Bug"). If no-one complains and it
>>>> passes triage
>>>> as a bug I guess it is a bug and then you can push it when the repo
>>>> opens again.
>>>>
>>>> /Jesper
>>>