Looking ahead: proposed Hg forest consolidation for JDK 10

joe darcy joe.darcy at oracle.com
Fri Oct 21 23:50:35 UTC 2016

Hi Thomas,

On 10/18/2016 7:39 AM, Thomas Stüfe wrote:
> Hi all,
> On Mon, Oct 17, 2016 at 2:22 PM, Lindenmaier, Goetz <
> goetz.lindenmaier at sap.com> wrote:
>> Hi,
>> I'm on a 1.6 TB share available to our team visible on all our
>> servers. The machine is a 48 processor 64GB linux x86_64 server.
>> The servers only have limited local disc space.  Especially with the
>> new setup I can not have clones on all the machines I need to compile
>> and test on.
>> Best regards,
>>    Goetz.
> I'm on Goetz team at SAP. Just wanted to give some additional information:
> I keep reading "use local repos". This is unfortunately not practical for
> us. Limited local disk space on build machines is only the smallest of the
> problems. A bigger problem is our platform breadth.
> We have a large zoo of machines running a number of cpu/os combinations.
> When we develop for the OpenJDK, we want to build and test on multiple -
> preferably all - machines and platforms the OpenJDK is supported on, to
> make sure we do not introduce regressions. But we have no automatic build
> system for these platforms, nor do we have access to your jprt.

Independent of what happens with this proposal, I suggest setting up 
some kind of in-house build and test system to help automate such 
procedures. Internally at Oracle, we have various Hudson/Jenkins systems 
in addition to jprt.

> So, as an example the fix for JDK-8166944 I did build on Linux (x64, ppc,
> s390), Solaris (sparc, x64), AIX, MacOS, and Windows x64. I usually leave
> out platforms I think are safe - in this case 32bit and zero - but at my
> own risk, because if I introduce a regression because I do not build, I
> risk the annoyance of other developers.
> Therefore local repos are not practical - syncing local repos across many
> machines is a pain and very error prone. So, every developer keeps his
> repos on a filer (NFS) and so if the NFS client on a certain machine is not
> good, we wait and suffer.
> So performance matters for us a lot.


Using a particular set of Hg source repositories is not a guaranteed 
interface of the JDK and as a historical note there was some discontent 
with consequences of using more than one repository when the Hg repos 
were first published:


We on the consolidation team are willing to continue exploring options 
to better accommodate differing workflows and system architectures. I 
think it is reasonable for some changes to those systems to be included 
in the space of candidate solutions.



More information about the jdk9-dev mailing list