Proposal: Allowing selective pushes to hotspot without jprt

Mikael Vidstedt mikael.vidstedt at oracle.com
Wed Sep 10 22:16:09 UTC 2014


Andrew/Volker,

Thanks for the positive feedback. The goal of the proposal is to 
simplify pushing changes which are effectively not tested by the jprt 
system anyway. The proposed relaxation would not affect work on other 
infrastructure projects in any relevant way, but would hopefully improve 
all our lives significantly immediately.

Cheers,
Mikael

On 2014-09-10 01:45, Volker Simonis wrote:
> Hi Mikael,
>
> thanks a lot for this proposal. I think this will dramatically
> simplify our work to keep our ports up to date! So I fully support it.
>
> Nevertheless, I think this can only be a first step towards fully open
> the JPRT system to developers outside Oracle. With "opening" I mean to
> allow OpenJDK commiters from outside Oracle to submit and run JPRT
> jobs as well as allowing porting projects to add hardware which builds
> and tests the HotSpot on alternative platforms.
>
> So while I'm all in favor of your proposal I hope you can allay my
> doubts that this simplification will hopefully not push the
> realization of a truly OPEN JPRT system even further away.
>
> Regards,
> Volker
>
>
> On Tue, Sep 9, 2014 at 11:24 PM, Mikael Vidstedt
> <mikael.vidstedt at oracle.com> wrote:
>> All,
>>
>> Made up primarily of low level C++ code, the Hotspot codebase is highly
>> platform dependent and also tightly coupled with the tool chains on the
>> various platforms. Each platform/tool chain combination has its set of
>> special quirks, and code must be implemented in a way such that it only
>> relies on the common subset of syntax and functionality across all these
>> combinations. History has taught us that even simple changes can have
>> surprising results when compiled with different compilers.
>>
>> For more than a decade the Hotspot team has ensured a minimum quality level
>> by requiring all pushes to be done through a build and test system (jprt)
>> which guarantees that the code resulting from applying a set of changes
>> builds on a set of core platforms and that a set of core tests pass. Only if
>> all the builds and tests pass will the changes actually be pushed to the
>> target repository.
>>
>> We believe that testing like the above, in combination with later stages of
>> testing, is vital to ensuring that the quality level of the Hotspot code
>> remains high and that developers do not run into situations where the latest
>> version has build errors on some platforms.
>>
>> Recently the AIX/PPC port was added to the set of OpenJDK platforms. From a
>> Hotspot perspective this new platform added a set of AIX/PPC specific files
>> including some platform specific changes to shared code. The AIX/PPC
>> platform is not tested by Oracle as part of Hotspot push jobs. The same
>> thing applies for the shark and zero versions of Hotspot.
>>
>> While Hotspot developers remain committed to making sure changes are
>> developed in a way such that the quality level remains high across all
>> platforms and variants, because of the above mentioned complexities it is
>> inevitable that from time to time changes will be made which introduce
>> issues on specific platforms or tool chains not part of the core testing.
>>
>> To allow these issues to be resolved more quickly I would like to propose a
>> relaxation in the requirements on how changes to Hotspot are pushed.
>> Specifically I would like to allow for direct pushes to the hotspot/
>> repository of files specific to the following ports/variants/tools:
>>
>> * AIX
>> * PPC
>> * Shark
>> * Zero
>>
>> Today this translates into the following files:
>>
>> - src/cpu/ppc/**
>> - src/cpu/zero/**
>> - src/os/aix/**
>> - src/os_cpu/aix_ppc/**
>> - src/os_cpu/bsd_zero/**
>> - src/os_cpu/linux_ppc/**
>> - src/os_cpu/linux_zero/**
>>
>> Note that all changes are still required to go through the normal
>> development and review cycle; the proposed relaxation only applies to how
>> the changes are pushed.
>>
>> If at code review time a change is for some reason deemed to be risky and/or
>> otherwise have impact on shared files the reviewer may request that the
>> change to go through the regular push testing. For changes only touching the
>> above set of files this expected to be rare.
>>
>> Please let me know what you think.
>>
>> Cheers,
>> Mikael
>>



More information about the hotspot-dev mailing list