Please look at my JEP
volker.simonis at gmail.com
Wed Jul 2 17:26:08 UTC 2014
first of all I want to say that although I've already done a complete
(and successfull) round trough the JEP process with our PowerPC/AIX
port, the whole process still remained mysterious to me. Generally,
coming from outside Oracle, it is hard to inspire people to review a
JEP for a project which doesn't help them and which in the end will
cause a lot of work for them.
If nobody else want to comment on the Draft, I'd push the JEP to the
"Submitted" state right away. Nevertheless, providing some more
details about the approximate number and size of changes in the Wiki
together with links to the webrevs may be helpful for reviewers. One
thing we did for example was to create a patch queue (i.e. a Mercurial
Queue - see ) which could be imported into the latest development
branch (in your case that would probably be jdk9/hs/hotspot). Each of
the patches in the queue was:
- more or less self-contained
- usually a collection/merge of several changes from our porting repository
- easy to review (not too big, not too small)
- verbosely named to summarize their content
We tried hard to always keep the queue up-to date with respect to the
upstream repository such that reviewers could easily build and test
the changes (that means nightly builds and daily fixes:). Just see our
porting repository  to get an impression of our patch queue and
read Goetz's mail  which explains how this patch queue can be
applied to an upstream repository. You could then easily link these
patches (or lists thereof) into your JEP/Wiki/Integration Plan.
Once you have all this in place, I think there's no excuse, why your
JEP shouldn't be endorsed and funded. At first glance, David is right
that this review should be done in the context of the JDK 9 project.
On the other hand, I'm pretty sure that the vast majority of your
changes are in the HotSpot repository and it's the HotSpot changes
which causes most of the trouble because you always need an Oracle
sponsor for each of them even if you're a comitter. And anyway, your
JEP needs to be endorsed and sponsored by a Group Lead anyway (see
"Making decisions and building consensus" in ), so I think the
hotspot group would be the right sponsoring group and John Coomes as
the hotspot Group Lead the right person to endorse it.
If I remember right, just about at this stage of the preocess we
created our "PowerPC/AIX Port Integration Plan"  together with some
people from Oracle which already contained a quite detailed estimation
of the efforts, durations, dependencies and confidence levels in each
of the planned integration steps. One of the main points was the
creation of a so called "staging" forest inside our project repository
which was a clone of the latest development forest (in your case that
would probably be jdk9/hs/hotspot).
Notice that this step HAS TO BE DONE by Oracle, because the staging
forest also contains Oracles closed part of the OpenJDK (a nice
Oxymoron:) and it has to, because all your HotSpot changes will have
to pass Oracles internal testing which also exercises the closed
platforms. Sometimes it is also necessary that Oracle adapts its
closed sources such that they still work together with the open part
after your changes and this can obviously only be done by Oracle.
Because of its special nature, the "staging" repository can only be
synced with the upstream development repository by an Oracle employee
(and this person should be a good friend of yours, because you'll need
With this staging repository in place, we finally created bug IDs and
webrevs for each of the patches from our patch queue , submitted
them for review to the corresponding mailing lists and submitted them
into our staging repository once they were reviewed (or asked our
sponsors insode Oracle to submit them for HotSpot changes).
So what could be the next steps to push your JEP forward:
- publish a more detailed description of your proposed changes (patch
- publish build results (see for example  which contained nightly
builds of our staging repository and the upstream repository with our
patch queue applied before our port was merged into the main code
- publish more information about your port on your Wiki page (e.g.
your FOSDEM talks which I liked a lot:), ARM manuals, etc) which makes
it easier vor reviewers to understand your code.
- contact the corresponding Group Leads directly and ask them what
additional information they need to endorse/fund your JEP (do this
more often if you get no answer:)
- campaign for your project among among all your Oracle connections
(you probably know the names better than I do, if not contact me :)
You have to understand that a port integration is a considerable
effort from Oracles side and they won't do it until you don't push
them really hard.
PS: still not a reviewer but maybe an OpenJDK Porting “Area Lead” :)
On Wed, Jul 2, 2014 at 2:57 PM, Andrew Haley <aph at redhat.com> wrote:
> On 07/02/2014 11:39 AM, David Holmes wrote:
>> Hi Andrew,
>> On 2/07/2014 6:11 PM, Andrew Haley wrote:
>>> Hi everybody,
>>> Please can someone review my JEP?
>>> It's very simple, and until we can get things moving this is
>>> blocking a significant contribution to OpenJDK.
>> The JEP 2.0 process  is still being formulated so it is unclear to me
>> how to advance this JEP at this time.
> I'm doing this as part of JEP 2.0 because Mark Reinhold asked me to.
> He suggested I post the request here. Perhaps he can advise.
>> I'm not even sure how to officially "review" it as such. The basic
>> proposal is sound (similar to ppc64/aix). The engineering plan would
>> need a lot more detail I think - perhaps discuss with Volker & Goetz
>> to get details of what was needed for PPC64 with regard to the
>> staging etc. Perhaps prepare webrevs for teh shared code changes and
>> have them looked at by the different groups: hotspot, build,
>> core-libs. Also it needs to be done in the context of the JDK 9
>> project, so this email probably needs to go to the jdk9-dev alias,
>> and solicit support from the JDK 9 project lead.
> Right, but as I understand it all that is required at this stage is a
> basic sanity check of the proposal, which is very similar to that for
> I'm of course happy to produce webrevs for the shared code or anything
More information about the hotspot-dev