Looking ahead: proposed Hg forest consolidation for JDK 10
joe.darcy at oracle.com
Fri Oct 21 23:50:35 UTC 2016
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:
>> 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,
> 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