Re: RFR(XS): 8186218 - Make JIB exclude webrev from all sub-repo levels when creating source bundles

[David Holmes]

On 31/08/2017 11:56 PM, Christian Tornqvist wrote:

Please review this change that updates the exclude filter used by JIB when 
creating source bundles, it’ll now ignore webrev folders and webrev.zip in all 
repository levels.


Won't that added capability be obsolete once we have the consolidated 
repo, as you'll no longer be creating webrevs at those levels??


David


Tested locally using JIB.

Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8186218/webrev.00/ 

Bug: https://bugs.openjdk.java.net/browse/JDK-8186218 


Thanks,
Christian

Re: RFR(M): 8186978: Introduce configure argument enable-cds

[David Holmes]

Hi Goetz,

I will sponsor this.

Thanks,
David

On 1/09/2017 12:49 AM, Lindenmaier, Goetz wrote:

Hi,

thanks for reviewing everybody!
Yes, works fine without that assignment. New webrev:
http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.02/

Could someone please sponsor? I think autogen.sh needs to be run
before submitting.

Best regards,
   Goetz.


-Original Message-
From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
Sent: Thursday, August 31, 2017 3:35 PM
To: David Holmes ; Lindenmaier, Goetz
; hotspot-runtime-...@openjdk.java.net;
build-dev (build-dev@openjdk.java.net) 
Subject: Re: RFR(M): 8186978: Introduce configure argument enable-cds



On 2017-08-31 14:47, David Holmes wrote:

Hi Goetz,

On 31/08/2017 10:29 PM, Lindenmaier, Goetz wrote:

Hi,

Tests for class data sharing (cds) are enabled if @requires vm.cds is
true.
The property vm.cds depends on the preprocessor macro ENABLE_CDS.

... but you mean INCLUDE_CDS. :-)


This can not yet be switched by configure. It's only disabled
automatically
for the minimal build.

This change introduces enable-cds with default true, which only takes
effect
in the non-minimal build. If disabled, generate-classlist is
disabled, too.

Please review this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr17/8186978-

disableCDS/webrev.01/index.html




I'll let the build guys comment in detail, but the structure for this
doesn't quite look right to me. I don't understand why you have in
spec.gmk.in:

+ ENABLE_CDS:=@ENABLE_CDS@

when in the hotspot build CDS is controlled via the feature setting:

ifneq ($(call check-jvm-feature, cds), true)

which you are already handling. ??


Agree, the ENABLE_CDS variable is only used internally in the configure
script and need not/should not be exported in spec.gmk.in. As David
says, the test ($(call check-jvm-feature, cds), true) is enough to
determine if to send the -DINCLUDE_CDS to the compiler.

Just remove the changes to spec.gmk.in, and I'm ok with the patch.

/Magnus




Thanks,
David



Best regards,
Goetz.

RE: RFR(M): 8186978: Introduce configure argument enable-cds

[Lindenmaier, Goetz]

Hi,

thanks for reviewing everybody!
Yes, works fine without that assignment. New webrev:
http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.02/

Could someone please sponsor? I think autogen.sh needs to be run
before submitting.

Best regards,
  Goetz.

> -Original Message-
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
> Sent: Thursday, August 31, 2017 3:35 PM
> To: David Holmes ; Lindenmaier, Goetz
> ; hotspot-runtime-...@openjdk.java.net;
> build-dev (build-dev@openjdk.java.net) 
> Subject: Re: RFR(M): 8186978: Introduce configure argument enable-cds
> 
> 
> 
> On 2017-08-31 14:47, David Holmes wrote:
> > Hi Goetz,
> >
> > On 31/08/2017 10:29 PM, Lindenmaier, Goetz wrote:
> >> Hi,
> >>
> >> Tests for class data sharing (cds) are enabled if @requires vm.cds is
> >> true.
> >> The property vm.cds depends on the preprocessor macro ENABLE_CDS.
> ... but you mean INCLUDE_CDS. :-)
> 
> >> This can not yet be switched by configure. It's only disabled
> >> automatically
> >> for the minimal build.
> >>
> >> This change introduces enable-cds with default true, which only takes
> >> effect
> >> in the non-minimal build. If disabled, generate-classlist is
> >> disabled, too.
> >>
> >> Please review this change. I please need a sponsor.
> >> http://cr.openjdk.java.net/~goetz/wr17/8186978-
> disableCDS/webrev.01/index.html
> >>
> >
> > I'll let the build guys comment in detail, but the structure for this
> > doesn't quite look right to me. I don't understand why you have in
> > spec.gmk.in:
> >
> > + ENABLE_CDS:=@ENABLE_CDS@
> >
> > when in the hotspot build CDS is controlled via the feature setting:
> >
> > ifneq ($(call check-jvm-feature, cds), true)
> >
> > which you are already handling. ??
> 
> Agree, the ENABLE_CDS variable is only used internally in the configure
> script and need not/should not be exported in spec.gmk.in. As David
> says, the test ($(call check-jvm-feature, cds), true) is enough to
> determine if to send the -DINCLUDE_CDS to the compiler.
> 
> Just remove the changes to spec.gmk.in, and I'm ok with the patch.
> 
> /Magnus
> 
> 
> >
> > Thanks,
> > David
> >
> >
> >> Best regards,
> >>Goetz.
> >>

Re: RFR(XS): 8186218 - Make JIB exclude webrev from all sub-repo levels when creating source bundles

[Erik Joelsson]

Looks good to me.

/Erik


On 2017-08-31 15:56, Christian Tornqvist wrote:

Please review this change that updates the exclude filter used by JIB when 
creating source bundles, it’ll now ignore webrev folders and webrev.zip in all 
repository levels.

Tested locally using JIB.

Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8186218/webrev.00/ 

Bug: https://bugs.openjdk.java.net/browse/JDK-8186218 


Thanks,
Christian

Re: RFR(XS): 8186218 - Make JIB exclude webrev from all sub-repo levels when creating source bundles

[Magnus Ihse Bursie]

On 2017-08-31 15:56, Christian Tornqvist wrote:

Please review this change that updates the exclude filter used by JIB when 
creating source bundles, it’ll now ignore webrev folders and webrev.zip in all 
repository levels.

Tested locally using JIB.

Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8186218/webrev.00/ 



Looks good to me.

/Magnus


Bug: https://bugs.openjdk.java.net/browse/JDK-8186218 


Thanks,
Christian

RFR(XS): 8186218 - Make JIB exclude webrev from all sub-repo levels when creating source bundles

[Christian Tornqvist]

Please review this change that updates the exclude filter used by JIB when 
creating source bundles, it’ll now ignore webrev folders and webrev.zip in all 
repository levels.

Tested locally using JIB.

Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8186218/webrev.00/ 

Bug: https://bugs.openjdk.java.net/browse/JDK-8186218 


Thanks,
Christian

Re: [RFR]: 8186786: Name collisions with autoconf definitions on alpha and sh

[Magnus Ihse Bursie]

On 2017-08-25 23:52, John Paul Adrian Glaubitz wrote:

On 08/25/2017 11:28 PM, John Paul Adrian Glaubitz wrote:

Webrev can be found in [1].


Updated webrev in [1]. Removed the quotes around alpha and sh in
the comments to make it more consistent with the rest of the comments.


Looks good to me.

I'll sponsor the patch for you, and regenerate the generated-configure.sh.

/Magnus



Adrian


[1] http://cr.openjdk.java.net/~glaubitz/8186786/webrev.02/

Re: [RFR]: 8186786: Name collisions with autoconf definitions on alpha and sh

[John Paul Adrian Glaubitz]

On 08/31/2017 03:44 PM, Magnus Ihse Bursie wrote:

Looks good to me.

I'll sponsor the patch for you, and regenerate the generated-configure.sh.


Great. Thank you!

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR(M): 8186978: Introduce configure argument enable-cds

[Magnus Ihse Bursie]

On 2017-08-31 14:47, David Holmes wrote:

Hi Goetz,

On 31/08/2017 10:29 PM, Lindenmaier, Goetz wrote:

Hi,

Tests for class data sharing (cds) are enabled if @requires vm.cds is 
true.

The property vm.cds depends on the preprocessor macro ENABLE_CDS.

... but you mean INCLUDE_CDS. :-)

This can not yet be switched by configure. It's only disabled 
automatically

for the minimal build.

This change introduces enable-cds with default true, which only takes 
effect
in the non-minimal build. If disabled, generate-classlist is 
disabled, too.


Please review this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.01/index.html 



I'll let the build guys comment in detail, but the structure for this 
doesn't quite look right to me. I don't understand why you have in 
spec.gmk.in:


+ ENABLE_CDS:=@ENABLE_CDS@

when in the hotspot build CDS is controlled via the feature setting:

ifneq ($(call check-jvm-feature, cds), true)

which you are already handling. ??


Agree, the ENABLE_CDS variable is only used internally in the configure 
script and need not/should not be exported in spec.gmk.in. As David 
says, the test ($(call check-jvm-feature, cds), true) is enough to 
determine if to send the -DINCLUDE_CDS to the compiler.


Just remove the changes to spec.gmk.in, and I'm ok with the patch.

/Magnus




Thanks,
David



Best regards,
   Goetz.

Re: RFR(M): 8186978: Introduce configure argument enable-cds

[Erik Joelsson]

This looks ok to me, but I would value Magnus' input as well.

/Erik


On 2017-08-31 14:29, Lindenmaier, Goetz wrote:

Hi,

Tests for class data sharing (cds) are enabled if @requires vm.cds is true.
The property vm.cds depends on the preprocessor macro ENABLE_CDS.
This can not yet be switched by configure. It's only disabled automatically
for the minimal build.

This change introduces enable-cds with default true, which only takes effect
in the non-minimal build. If disabled, generate-classlist is disabled, too.

Please review this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.01/index.html

Best regards,
   Goetz.

Re: RFR(M): 8186978: Introduce configure argument enable-cds

[David Holmes]

Hi Goetz,

On 31/08/2017 10:29 PM, Lindenmaier, Goetz wrote:

Hi,

Tests for class data sharing (cds) are enabled if @requires vm.cds is true.
The property vm.cds depends on the preprocessor macro ENABLE_CDS.
This can not yet be switched by configure. It's only disabled automatically
for the minimal build.

This change introduces enable-cds with default true, which only takes effect
in the non-minimal build. If disabled, generate-classlist is disabled, too.

Please review this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.01/index.html


I'll let the build guys comment in detail, but the structure for this 
doesn't quite look right to me. I don't understand why you have in 
spec.gmk.in:


+ ENABLE_CDS:=@ENABLE_CDS@

when in the hotspot build CDS is controlled via the feature setting:

ifneq ($(call check-jvm-feature, cds), true)

which you are already handling. ??

Thanks,
David



Best regards,
   Goetz.

RFR(M): 8186978: Introduce configure argument enable-cds

[Lindenmaier, Goetz]

Hi,

Tests for class data sharing (cds) are enabled if @requires vm.cds is true. 
The property vm.cds depends on the preprocessor macro ENABLE_CDS. 
This can not yet be switched by configure. It's only disabled automatically 
for the minimal build. 

This change introduces enable-cds with default true, which only takes effect 
in the non-minimal build. If disabled, generate-classlist is disabled, too.

Please review this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.01/index.html

Best regards,
  Goetz.

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[dalibor topic]

(CC:ing bsd-port-dev, where this conversation should have moved to a 
while ago ...)


On 31.08.2017 10:53, John Paul Adrian Glaubitz wrote:

There is an active community maintaining OpenJDK on BSD. The problem is
just that they are doing it downstream instead of working together with
upstream due to lack of communication. I think that is a problem that can
be fixed though.

I will try to get these people join the upstream mailing list.


As far as I know, most of the people who actively maintain the BSD ports 
in various BSD distributions are already Committers on the BSD port Project:


Per http://openjdk.java.net/census#bsd-port

Greg Lewis (Project Lead, FreeBSD) & Jung-uk Kim (FreeBSD)
Christos Zoulas (NetBSD)
Kurt Miller (OpenBSD)

The FreeBSD Foundation is an OCTLA signatory: 
http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html


Unfortunately, no one has produced a build of the OpenJDK BSD port that 
passes the JCK yet, as far as I know.


The challenge in the past has been that the time the individual BSD Port 
developers have generously been able to spend on keeping the BSD port up 
and running (Greg just updated the JDK 8 forest with latest changes, 
while Kurt fixed a set of compilation issues this month - thanks!) [0] 
was not sufficient to simultaneously let them make enough progress on 
integrating their port into mainline JDK. Maybe the BSD porters are 
interested in having more individuals help with the various tasks around 
that - but it's also worth keeping in mind that the set of individuals 
who speak up wanting to help out with the port on bsd-port-dev is less 
than a handful per year.


One of the conditions for getting a port into JDK mainline has been that 
it should actually pass the JCK for the current version. I think that's 
a low enough bar that should remain in place for JDK 9 and beyond.


Here's a slightly updated version of what I wrote about getting BSD 
ports into mainline back in 2014 as part of a conversation with Greg 
about it:


In general, ports should come in through the 'next release' project, 
i.e. JDK9/10 currently, as that is where most of the development 
happens, and so that's the best place to review and integrate the 
changes going forward. Well, JDK 10, really, at this stage of JDK 9 
development.


* At this point in time, I'd be very pessimistic about adding new ports 
further back to the JDK 8 Updates Project or earlier, as they are more 
focused on bug fixes and stability, rather than adding features.


* For a port to get into mainline, it needs to have a JEP, and the JEP 
needs to be funded. Basically, someone needs to sign up to do all the 
necessary work.


See http://openjdk.java.net/jeps/175 for the JEP for the PowerPC64 
AIX/Linux port JEP, for an example, of what a JEP for a port should look 
like. See http://openjdk.java.net/jeps/1 for details,
and http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html for the revision 
of the JEP process.


* All source code changes need to be reviewed by the respective 
reviewers for mainline, as usual. This typically implies for a port's 
integration that it's a non-trivial effort on the side of Reviewers from 
Oracle and other port maintainers to ensure that changes proposed for 
review actually get timely reviews. Depending on how much there is to 
review, you'd want to get a plan in place that lets everyone plan their 
involvement in the review process accordingly, rather than just posting 
a bunch of patches for review on several mailing lists and hoping for 
the best.


* Each port is slightly different - some touch only a few files, others 
bring in new subsystems for graphics, native code, programming 
languages, CPUs, core libraries, etc.


So while in some cases integrating a port can be rather straightforward, 
because it touches only a limited set of files, in other cases it can be 
a complicated undertaking that requires several synchronization points, 
planning, and efficient execution from many parties to pull it off in 
time for a JDK release feature freeze. I.e. if you want to get a new 
port into mainline you'd need to get started early in a JDK release cycle.


* Testing is very important - a port should not introduce regressions, 
for example. It should also pass the JCK for the current release. The 
JDK mainline has rather strict rules about reviews, and processes to 
follow, which makes it an inconvenient place to finish off an unfinished 
port - that's what the porting projects are for.


* Once a port get into the mainline JDK project, it's expected to be 
kept up to date by its maintainers - which  means keeping up with the 
regular stream of changes - for example, the integration of Jigsaw into 
JDK 9 resulted in some build system changes (because of modules), and it 
would be up to each port's maintainers to make sure that they keep their 
port in sync in tree.


cheers,
dalibor topic

[0] 
http://mail.openjdk.java.net/pipermail/bsd-port-dev/2017-August/thread.html

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[John Paul Adrian Glaubitz]

On 08/31/2017 09:21 AM, David Holmes wrote:

Those were very minor patches of two quite distinct kinds:

1. Make zero work on platform Z

This is something we can easily accommodate, and it generally
doesn't take much effort or disturb other platforms.


Well, Zero is currently not maintained, is it?


2. Make the linux-sparc port work again

This is somewhat more significant and does require community support
as otherwise this is an "orphaned" port. The fact it already exists
and was starting to bit rot means the acceptance bar is somewhat lower.


I agree.


But there is still a question mark over longer term commitment from the
community for supporting this port.


You mean, there is no chance that Oracle is going to have their engineers
work on Oracle's OpenJDK so it will work on Oracle Linux running on Oracle
SPARC?

I know I am very cynical, but I have very hard problems to believe that
the Linux SPARC port of OpenJDK is going to be irrelevant in the near
future for Oracle when I see how much they are ramping up Linux support
on SPARC. I am following the sparclinux kernel mailing list and roughly
80% of the patches of the past months for Linux SPARC came from Oracle
folk.


Patric told me on hotspot-dev that Oracle has no problems accepting these
patches if they are maintained and tested by the community.


A full BSD port, not just Zero on BSD, requires a non-trivial level of
commitment from the community in terms of maintaining it etc, before it
can come into mainline. That is why we have the bsd-port project - to
establish that community and commitment. But AFAICS, and from what was
said when Magnus proposed this, that community is not active.


There is an active community maintaining OpenJDK on BSD. The problem is
just that they are doing it downstream instead of working together with
upstream due to lack of communication. I think that is a problem that can
be fixed though.

I will try to get these people join the upstream mailing list.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[David Holmes]

On 31/08/2017 5:40 PM, Thomas Stüfe wrote:
On Thu, Aug 31, 2017 at 9:21 AM, David Holmes > wrote:


On 31/08/2017 5:08 PM, John Paul Adrian Glaubitz wrote:

On 08/31/2017 08:58 AM, Magnus Ihse Bursie wrote:

BSD is buildable for jdk9 in the separate, hardly-maintained
bsd-port only. :-(


That's what I guess as well after seeing that the "bsd"
directories within
the "jdk" structure are missing in the mainline tree. Then I
checked what
NetBSD is using as upstream and saw the reference bsd-port.

I posted a set of patches for jdk9 mainline for building
jdk9 on BSD, that was
rejected. :( They ended up in the bsd-port, but this has not
been pushed upstream
to the mainline, and the bsd port is only sporadically
updated from mainline.


I think it won't hurt anyone if those patches are pushed
mainline. It seems that
most of the stuff lives inside its own directories, doesn't it?
If so, I don't
see any risk of breakage.

Since those changes are either a) general cleanups that all
platforms should
benefit from, or b) no-risk bsd-only changes, I'd really
like to see them go into
the mainline build system.


I agree. I'm all for merging them. If someone has invested so
much work into
the port, it shouldn't just go to bitrot in bsd-port. It should
be merged
into the mainline tree.

But for that to happen, we apparently need to change some
policy about
accepting code for platforms not tested by Oracle. :-(


I don't see why that should be necessary. I have sent in patches
for linux-sparc
and linux-zero in the past weeks and they were merged without a
hitch.


Those were very minor patches of two quite distinct kinds:

1. Make zero work on platform Z

This is something we can easily accommodate, and it generally
doesn't take much effort or disturb other platforms.

2. Make the linux-sparc port work again

This is somewhat more significant and does require community support
as otherwise this is an "orphaned" port. The fact it already exists
and was starting to bit rot means the acceptance bar is somewhat
lower. But there is still a question mark over longer term
commitment from the community for supporting this port.

Patric told me on hotspot-dev that Oracle has no problems
accepting these
patches if they are maintained and tested by the community.


A full BSD port, not just Zero on BSD, requires a non-trivial level
of commitment from the community in terms of maintaining it etc,
before it can come into mainline. That is why we have the bsd-port
project - to establish that community and commitment. But AFAICS,
and from what was said when Magnus proposed this, that community is
not active.

So unless something significant has changed with regards to the
bsd-port project and its supporting community, a full BSD port in
mainline seems unlikely.


FWIW, I would love a first class BSD port. I think BSD is a valuable 
platform to have.


The fact that different people at different times independently from 
each other try to make this work, and that there seems to be an active 
community of OpenJDK porters for BSD, seems to indicate there is enough 
interest to keep this going. And then, maybe I am naive, but we are not 
talking about new CPUs or a new GC, just another Posix compliant OS very 
similar to the existing OSX. Would this really be so much effort?


It isn't a question of initial effort.



But this should be discussed on porters-...@openjdk.java.net
 so that the porters group can
have its say.


Unfortunately, porters-dev is a ghost town. What about bsd-dev?


AFAIK the porters group should be the ones discussing this in general.

David


Cheers, Thomas

Cheers,
David
-


The changes, btw, look good.


Thanks.

Btw, I was chatting about OpenJDK on BSD yesterday on #netbsd in IRC
and I have learned that there are also several porters actively
working on OpenJDK on BSD. I will contact those guys and get them
to join build-dev@ and hotspot-dev@.

There are definitely enough qualified and motivated developers who
want to work on OpenJDK for the platforms Oracle doesn't officially
support.

Adrian

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Erik Joelsson]

On 2017-08-30 23:43, David Holmes wrote:

On 31/08/2017 12:36 AM, Erik Joelsson wrote:

Hello Jason,

I took the liberty of creating an issue for this: 
https://bugs.openjdk.java.net/browse/JDK-8186983


The mailing list server removes attachments. This makes it difficult 
for new people to send in their patches until they have an openjdk 
user so they can upload to cr.openjdk.java.net. Since you addressed 
the mail directly to me as well, I received the attachment and have 
created a webrev from it here:


http://cr.openjdk.java.net/~erikj/8186983/webrev.01/

I think the patch looks good now, but will leave it here until 
tomorrow to give other reviewers a chance to look at.


This seems okay, though I do want to point out that even with this 
change there is still limited ability to combine custom values with 
standard ones - the standard ones are always added last and so 
potentially could conflict with or override the intent of the custom 
settings.


That is a very good point. This type of extension mechanism is brittle, 
at least for flags type of variables. For include/exclude/copy/clean it 
is perfectly fine however.
It is good to know that someone else is actually using the 
customization mechanism though! :)



Yes, nice to see that effort wasn't completely in vain. :)

/Erik

Cheers,
David


/Erik


On 2017-08-30 16:20, Jason Yong wrote:

Hi Eric,

I've removed the SETUP changes as requested...



On a side note, I noticed that the attachment got stripped out in 
the post
to the mailing list. Should I actually be copying and pasting the 
entire
diff in the message? Its a couple of hundred lines... or is 
somewhere to

put the attachment?


Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 14:43
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



Hello,

Changing the assignment on COPY, CLEAN and FLAGS variables makes sense,
but please revert the SETUP variables as those are not lists but single
value types.

Otherwise this looks good to me.

/Erik


On 2017-08-30 15:37, Jason Yong wrote:

Hi Eric,

With regards to the OCA I believe IBM has signed a contributors

agreement

which should cover me for that.


So here's the mercurial export of the CompileJavaModule.java with my
changes in




Regards,


Jason Yong

CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 13:47
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



If you have signed the OCA, you can post your proposed change here 
and I

or someone else will sponsor it once we agree that it looks good.
/Erik

On 2017-08-30 14:27, Jason Yong wrote:
Thanks Eric,

Is the next step is to get a sponsor for the change or should I 
post my

proposed change first?

Jason

Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom






From:Erik Joelsson 
To:Jason Yong ,

build-dev@openjdk.java.net

Date:29/08/2017 12:55
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



Hello Jason,

Your suggestion makes sense. The only reason these variables have :=
today is that we (at Oracle) haven't had a need for appending to those
particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:

Hello,

I've had an issue where I've had a custom extension to

CompileJavaModules.gmk with the variable java.base_COPY set to files

that

I wanted to be copied across but its value was overwritten by
CompileJavaModules.gmk.
I would like to propose changes that would allow a custom 
extensions to
update variables listed in CompileJavaModules.gmk. This issue is 
similar

to bug JDK-8064372 (

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e= 




) but affects all the other variables such as:

java.activation_SETUP
java.base_ADD_JAVAC_FLAGS
java.base_COPY
java.base_CLEAN
etc

The fix is also similar, changing := to += allowing the custom

extension

to append to the variable if already set and create it if its not.

I would appreciate any feedback and help on what the next steps would

be.

Thanks

Jason


Jas

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Erik Joelsson]

Updated webrev with the below corrected:

http://cr.openjdk.java.net/~erikj/8186983/webrev.02/

/Erik


On 2017-08-30 16:57, Erik Joelsson wrote:

Hello,


On 2017-08-30 16:48, Gary Adams wrote:
Is the expectation that all of the := will be changed to += for these 
variables?


 468 jdk.internal.vm.ci_ADD_JAVAC_FLAGS := -parameters 
-Xlint:-exports -XDstringConcat=inline



Good catch! I missed that when just reviewing the patch file.

Do the closed makefiles also need to be updated?

No, they should be fine as they are.

/Erik


On 8/30/17, 10:36 AM, Erik Joelsson wrote:

Hello Jason,

I took the liberty of creating an issue for this: 
https://bugs.openjdk.java.net/browse/JDK-8186983


The mailing list server removes attachments. This makes it difficult 
for new people to send in their patches until they have an openjdk 
user so they can upload to cr.openjdk.java.net. Since you addressed 
the mail directly to me as well, I received the attachment and have 
created a webrev from it here:


http://cr.openjdk.java.net/~erikj/8186983/webrev.01/

I think the patch looks good now, but will leave it here until 
tomorrow to give other reviewers a chance to look at.


/Erik


On 2017-08-30 16:20, Jason Yong wrote:

Hi Eric,

I've removed the SETUP changes as requested...



On a side note, I noticed that the attachment got stripped out in 
the post
to the mailing list. Should I actually be copying and pasting the 
entire
diff in the message? Its a couple of hundred lines... or is 
somewhere to

put the attachment?


Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 14:43
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



Hello,

Changing the assignment on COPY, CLEAN and FLAGS variables makes 
sense,
but please revert the SETUP variables as those are not lists but 
single

value types.

Otherwise this looks good to me.

/Erik


On 2017-08-30 15:37, Jason Yong wrote:

Hi Eric,

With regards to the OCA I believe IBM has signed a contributors

agreement

which should cover me for that.


So here's the mercurial export of the CompileJavaModule.java with my
changes in




Regards,


Jason Yong

CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 13:47
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



If you have signed the OCA, you can post your proposed change here 
and I

or someone else will sponsor it once we agree that it looks good.
/Erik

On 2017-08-30 14:27, Jason Yong wrote:
Thanks Eric,

Is the next step is to get a sponsor for the change or should I 
post my

proposed change first?

Jason

Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom






From:Erik Joelsson 
To:Jason Yong ,

build-dev@openjdk.java.net

Date:29/08/2017 12:55
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



Hello Jason,

Your suggestion makes sense. The only reason these variables have :=
today is that we (at Oracle) haven't had a need for appending to 
those

particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:

Hello,

I've had an issue where I've had a custom extension to

CompileJavaModules.gmk with the variable java.base_COPY set to files

that

I wanted to be copied across but its value was overwritten by
CompileJavaModules.gmk.
I would like to propose changes that would allow a custom 
extensions to
update variables listed in CompileJavaModules.gmk. This issue is 
similar

to bug JDK-8064372 (

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e= 




) but affects all the other variables such as:

java.activation_SETUP
java.base_ADD_JAVAC_FLAGS
java.base_COPY
java.base_CLEAN
etc

The fix is also similar, changing := to += allowing the custom

extension

to append to the variable if already set and create it if its not.
I would appreciate any feedback and help on what the next steps 
would

be.

Thanks

Jason


Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtime Technologies
IBM Hybrid Cloud
Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[Thomas Stüfe]

On Thu, Aug 31, 2017 at 9:21 AM, David Holmes 
wrote:

> On 31/08/2017 5:08 PM, John Paul Adrian Glaubitz wrote:
>
>> On 08/31/2017 08:58 AM, Magnus Ihse Bursie wrote:
>>
>>> BSD is buildable for jdk9 in the separate, hardly-maintained bsd-port
>>> only. :-(
>>>
>>
>> That's what I guess as well after seeing that the "bsd" directories within
>> the "jdk" structure are missing in the mainline tree. Then I checked what
>> NetBSD is using as upstream and saw the reference bsd-port.
>>
>> I posted a set of patches for jdk9 mainline for building jdk9 on BSD,
>>> that was
>>> rejected. :( They ended up in the bsd-port, but this has not been pushed
>>> upstream
>>> to the mainline, and the bsd port is only sporadically updated from
>>> mainline.
>>>
>>
>> I think it won't hurt anyone if those patches are pushed mainline. It
>> seems that
>> most of the stuff lives inside its own directories, doesn't it? If so, I
>> don't
>> see any risk of breakage.
>>
>> Since those changes are either a) general cleanups that all platforms
>>> should
>>> benefit from, or b) no-risk bsd-only changes, I'd really like to see
>>> them go into
>>> the mainline build system.
>>>
>>
>> I agree. I'm all for merging them. If someone has invested so much work
>> into
>> the port, it shouldn't just go to bitrot in bsd-port. It should be merged
>> into the mainline tree.
>>
>> But for that to happen, we apparently need to change some policy about
>>> accepting code for platforms not tested by Oracle. :-(
>>>
>>
>> I don't see why that should be necessary. I have sent in patches for
>> linux-sparc
>> and linux-zero in the past weeks and they were merged without a hitch.
>>
>
> Those were very minor patches of two quite distinct kinds:
>
> 1. Make zero work on platform Z
>
> This is something we can easily accommodate, and it generally doesn't take
> much effort or disturb other platforms.
>
> 2. Make the linux-sparc port work again
>
> This is somewhat more significant and does require community support as
> otherwise this is an "orphaned" port. The fact it already exists and was
> starting to bit rot means the acceptance bar is somewhat lower. But there
> is still a question mark over longer term commitment from the community for
> supporting this port.
>
> Patric told me on hotspot-dev that Oracle has no problems accepting these
>> patches if they are maintained and tested by the community.
>>
>
> A full BSD port, not just Zero on BSD, requires a non-trivial level of
> commitment from the community in terms of maintaining it etc, before it can
> come into mainline. That is why we have the bsd-port project - to establish
> that community and commitment. But AFAICS, and from what was said when
> Magnus proposed this, that community is not active.
>
> So unless something significant has changed with regards to the bsd-port
> project and its supporting community, a full BSD port in mainline seems
> unlikely.
>
>
FWIW, I would love a first class BSD port. I think BSD is a valuable
platform to have.

The fact that different people at different times independently from each
other try to make this work, and that there seems to be an active community
of OpenJDK porters for BSD, seems to indicate there is enough interest to
keep this going. And then, maybe I am naive, but we are not talking about
new CPUs or a new GC, just another Posix compliant OS very similar to the
existing OSX. Would this really be so much effort?



> But this should be discussed on porters-...@openjdk.java.net so that the
> porters group can have its say.
>
>
Unfortunately, porters-dev is a ghost town. What about bsd-dev?

Cheers, Thomas



> Cheers,
> David
> -
>
>
> The changes, btw, look good.
>>>
>>
>> Thanks.
>>
>> Btw, I was chatting about OpenJDK on BSD yesterday on #netbsd in IRC
>> and I have learned that there are also several porters actively
>> working on OpenJDK on BSD. I will contact those guys and get them
>> to join build-dev@ and hotspot-dev@.
>>
>> There are definitely enough qualified and motivated developers who
>> want to work on OpenJDK for the platforms Oracle doesn't officially
>> support.
>>
>> Adrian
>>
>>

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[David Holmes]

On 31/08/2017 5:08 PM, John Paul Adrian Glaubitz wrote:

On 08/31/2017 08:58 AM, Magnus Ihse Bursie wrote:

BSD is buildable for jdk9 in the separate, hardly-maintained bsd-port only. :-(


That's what I guess as well after seeing that the "bsd" directories within
the "jdk" structure are missing in the mainline tree. Then I checked what
NetBSD is using as upstream and saw the reference bsd-port.


I posted a set of patches for jdk9 mainline for building jdk9 on BSD, that was
rejected. :( They ended up in the bsd-port, but this has not been pushed 
upstream
to the mainline, and the bsd port is only sporadically updated from mainline.


I think it won't hurt anyone if those patches are pushed mainline. It seems that
most of the stuff lives inside its own directories, doesn't it? If so, I don't
see any risk of breakage.


Since those changes are either a) general cleanups that all platforms should
benefit from, or b) no-risk bsd-only changes, I'd really like to see them go 
into
the mainline build system.


I agree. I'm all for merging them. If someone has invested so much work into
the port, it shouldn't just go to bitrot in bsd-port. It should be merged
into the mainline tree.


But for that to happen, we apparently need to change some policy about
accepting code for platforms not tested by Oracle. :-(


I don't see why that should be necessary. I have sent in patches for linux-sparc
and linux-zero in the past weeks and they were merged without a hitch.


Those were very minor patches of two quite distinct kinds:

1. Make zero work on platform Z

This is something we can easily accommodate, and it generally doesn't 
take much effort or disturb other platforms.


2. Make the linux-sparc port work again

This is somewhat more significant and does require community support as 
otherwise this is an "orphaned" port. The fact it already exists and was 
starting to bit rot means the acceptance bar is somewhat lower. But 
there is still a question mark over longer term commitment from the 
community for supporting this port.



Patric told me on hotspot-dev that Oracle has no problems accepting these
patches if they are maintained and tested by the community.


A full BSD port, not just Zero on BSD, requires a non-trivial level of 
commitment from the community in terms of maintaining it etc, before it 
can come into mainline. That is why we have the bsd-port project - to 
establish that community and commitment. But AFAICS, and from what was 
said when Magnus proposed this, that community is not active.


So unless something significant has changed with regards to the bsd-port 
project and its supporting community, a full BSD port in mainline seems 
unlikely.


But this should be discussed on porters-...@openjdk.java.net so that the 
porters group can have its say.


Cheers,
David
-


The changes, btw, look good.


Thanks.

Btw, I was chatting about OpenJDK on BSD yesterday on #netbsd in IRC
and I have learned that there are also several porters actively
working on OpenJDK on BSD. I will contact those guys and get them
to join build-dev@ and hotspot-dev@.

There are definitely enough qualified and motivated developers who
want to work on OpenJDK for the platforms Oracle doesn't officially
support.

Adrian

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[John Paul Adrian Glaubitz]

On 08/31/2017 08:58 AM, Magnus Ihse Bursie wrote:
> BSD is buildable for jdk9 in the separate, hardly-maintained bsd-port only. 
> :-(

That's what I guess as well after seeing that the "bsd" directories within
the "jdk" structure are missing in the mainline tree. Then I checked what
NetBSD is using as upstream and saw the reference bsd-port.

> I posted a set of patches for jdk9 mainline for building jdk9 on BSD, that was
> rejected. :( They ended up in the bsd-port, but this has not been pushed 
> upstream
> to the mainline, and the bsd port is only sporadically updated from mainline.

I think it won't hurt anyone if those patches are pushed mainline. It seems that
most of the stuff lives inside its own directories, doesn't it? If so, I don't
see any risk of breakage.

> Since those changes are either a) general cleanups that all platforms should
> benefit from, or b) no-risk bsd-only changes, I'd really like to see them go 
> into
> the mainline build system.

I agree. I'm all for merging them. If someone has invested so much work into
the port, it shouldn't just go to bitrot in bsd-port. It should be merged
into the mainline tree.

> But for that to happen, we apparently need to change some policy about
> accepting code for platforms not tested by Oracle. :-(

I don't see why that should be necessary. I have sent in patches for linux-sparc
and linux-zero in the past weeks and they were merged without a hitch.

Patric told me on hotspot-dev that Oracle has no problems accepting these
patches if they are maintained and tested by the community.

> The changes, btw, look good.

Thanks.

Btw, I was chatting about OpenJDK on BSD yesterday on #netbsd in IRC
and I have learned that there are also several porters actively
working on OpenJDK on BSD. I will contact those guys and get them
to join build-dev@ and hotspot-dev@.

There are definitely enough qualified and motivated developers who
want to work on OpenJDK for the platforms Oracle doesn't officially
support.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [RFR]: 8187004: No valid toolchains defined for BSD

[David Holmes]

On 31/08/2017 4:41 PM, Thomas Stüfe wrote:
Looking through my Mails quick, all mails at bsd-port-dev seem to refer 
to jdk8.


Yes the port went dormant after 8.

toolchain.m4 changed a bit since jdk8. Maybe noone attempted to build 
jdk10 yet on BSD and Adrian ran into new errors.


Did some digging. Magnus was trying to drum up support to resurrect the 
BSD port in 9:


http://mail.openjdk.java.net/pipermail/build-dev/2016-January/016421.html
http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01/

but that didn't happen. As you can see from Magnus's patches there is a 
lot more to it than just fixing the valid toolchains.


David
-



..Thomas

On Thu, Aug 31, 2017 at 8:25 AM, David Holmes > wrote:


On 31/08/2017 4:14 PM, Thomas Stüfe wrote:

Hi Adrian,

this looks fine. Thanks for taking on BSD (I'm a bit confused
though, I
thought BSD is already buildable).


Thomas you beat me to it - on both counts! I too recall others
building for BSD.

David


Best Regards, Thomas

On Wed, Aug 30, 2017 at 10:30 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de
> wrote:

Hello!

I started working on fixing OpenJDK on BSD today and already
ran into
the first issue which is the configure script being unable
to find a
usable toolchain.

This happens because there are no valid toolchains defined
for BSD in
common/autoconf/toolchain.m4. Since both clang and gcc are
supported
on most BSD systems, this can be trivially resolved with:

diff -r 1147dee33745 common/autoconf/toolchain.m4
--- a/common/autoconf/toolchain.m4      Tue Aug 29 17:17:57
2017 +0200
+++ b/common/autoconf/toolchain.m4      Wed Aug 30 22:22:49
2017 +0200
@@ -42,6 +42,7 @@
   VALID_TOOLCHAINS_macosx="gcc clang"
   VALID_TOOLCHAINS_aix="xlc"
   VALID_TOOLCHAINS_windows="microsoft"
+VALID_TOOLCHAINS_bsd="gcc clang"
    # Toolchain descriptions
   TOOLCHAIN_DESCRIPTION_clang="clang/LLVM"

Webrev can be found in [1].

Adrian

[1] http://cr.openjdk.java.net/~glaubitz/8187004/webrev.00/




--
   .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org

`. `'   Freie Universitaet Berlin -
glaub...@physik.fu-berlin.de

    `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5
F913