RE: 8207830: [aix] disable jfr in build and tests

[Lindenmaier, Goetz]

Hi Vladimir, 

Thanks for looking at my change. 

> Thank you for fixing aot check in hotspot.m4
I guess this does no harm if aot is enabled, but I saw it on aix.

> Add new method vmHasJFR()
Fixed.

New partial webrev:
http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/02/
The other part is unchanged.

Best regards,
  Goetz.


> -Original Message-
> From: Vladimir Kozlov 
> Sent: Thursday, July 19, 2018 7:22 PM
> To: Lindenmaier, Goetz ; hotspot-dev
> developers 
> Cc: build-dev 
> Subject: Re: 8207830: [aix] disable jfr in build and tests
> 
> Tests changes are good.
> 
> Thank you for fixing aot check in hotspot.m4
> 
> In VMProps.java I would suggest to follow code pattern from other
> features. Add new method vmHasJFR() which returns "true" or "false"
> instead of:
> 
> map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());
> 
> We may need such method to add other conditions in future.
> 
> Thanks,
> Vladimir
> 
> On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > We didn't manage to port JFR to aix in the jdk11 time frame.
> > Thus I would like to disable it in the build.
> > As well, I would like to introduce @requires vm.hasJFR which
> > will disable the tests on aix, and also on linuxsparcv9 and zero.
> >
> > Two webrevs for better readability:
> > This contains the functional changes
> > http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
> > This contains adding @requires.
> > http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/
> 
> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/
> 
> > The only one not straight forward is
> runtime/appcds/sharedStrings/FlagCombo.java
> >
> > Best regards,
> >Goetz.
> >

Re: adding additional numbers to the Java version string

[Martin Buchholz]

OK.  Despite our deep interest in version strings, we rarely use
Runtime.Version.

On Thu, Jul 19, 2018 at 12:42 PM, Tony Printezis 
wrote:

> Hi Martin,
>
> Yes, we have also used the opt field too. However, if I understand the
> spec correctly, when doing version comparisons, the opt string is compared
> alphanumerically. So if you add any numbers to it, you have to plan ahead
> and pad with enough 0s to make sure the comparison works as expected. Given
> that the spec now allows extra numbers in the version string, it’d be good
> to be able to use that instead.
>
> Additionally, we want both compareTo() and compareToIgnoreOptional() to
> show our version as different to the upstream one it’s synced up to. And
> adding an extra number to the version string satisfies that too.
>
> Other folks might want this to behave differently, and that’s totally OK!
> But, the change I proposed will help anyone who has the above requirement.
>
>

Re: RFR: JDK-8207365: Make man pages optional

[Tim Bell]

Erik:

The patch adds a configure parameter
--enable-manpages/--disable-manpages, default is enabled, just like
before the change. The patch also changes the Oracle configuration in
jib-profiles.js to disable manpages.

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

Webrev: http://cr.openjdk.java.net/~erikj/8207365/webrev.01/index.html


Looks good.

Tim

RFR: JDK-8207365: Make man pages optional

[Erik Joelsson]

Hello,

The man pages are currently not being actively maintained by anyone, so 
we would like to make including them in the build optional. Oracle 
produced builds will disable inclusion of man pages. (This was already 
the case for OracleJDK builds but will now also be true for Oracle 
produced OpenJDK builds)


The patch adds a configure parameter 
--enable-manpages/--disable-manpages, default is enabled, just like 
before the change. The patch also changes the Oracle configuration in 
jib-profiles.js to disable manpages.


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

Webrev: http://cr.openjdk.java.net/~erikj/8207365/webrev.01/index.html

/Erik

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

[Erik Joelsson]

This looks ok to me.

/Erik


On 2018-07-19 13:11, Tony Printezis wrote:

Thanks for the explanation. So I think I’ll just leave it as is.

New webrev:

http://cr.openjdk.java.net/~tonyp/8207849/webrev.1/ 



The only new changes are in the spec.gmk.in  file.

Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com 




On July 19, 2018 at 4:01:14 PM, Erik Joelsson 
(erik.joels...@oracle.com ) wrote:





On 2018-07-19 12:52, Tony Printezis wrote:

Erik,

Many thanks for looking at this change!

I can totally add the VERSION_EXTRAX variables to the spec.gmk file.

Related: I was not sure what to do with 
VERSION_NUMBER_ALL_POSITIONS. Right now, 
VERSION_NUMBER_FOUR_POSITIONS is exposed to the spec.gmk file but 
I'm not sure exactly where it’s used. Is it worth also exposing 
VERSION_NUMBER_ALL_POSITIONS? I didn’t to make sure that anything 
that relies on VERSION_NUMBER_FOUR_POSITIONS having exactly four 
numbers didn’t break (and I’m happy to leave it as is).


The VERSION_NUMBER_FOUR_POSITIONS is used in windows launcher 
manifests (shows up if you right click a windows executable) and it's 
used internally at Oracle for Windows installers. I believe (but is 
not 100% sure) that the format with 4 numbers is specifically needed 
in the windows manifest case.


/Erik

Tony

—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com 




On July 19, 2018 at 3:02:26 PM, Erik Joelsson 
(erik.joels...@oracle.com ) wrote:



Hello Tony,

I think this looks ok. We like to keep AC_SUBST calls paired with
variables in spec.gmk.in  so please add 
corresponding VERSION_EXTRAX

variables there.

/Erik


On 2018-07-19 11:46, Tony Printezis wrote:
> Hi all,
>
> Here’s the webrev for this:
>
> http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/ 


>
> I’m no configure expert so I basically did a cut-and-paste of 
what was
> already there. If there’s a way to do this better (maybe, cut 
down on the

> awkward code replication), let let me know.
>
> The decision to allow up to 3 extra numbers was arbitrary. I can 
do more or

> fewer.
>
> Tony
>
> —
> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com 

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

[Tony Printezis]

Thanks for the explanation. So I think I’ll just leave it as is.

New webrev:

http://cr.openjdk.java.net/~tonyp/8207849/webrev.1/

The only new changes are in the spec.gmk.in file.

Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On July 19, 2018 at 4:01:14 PM, Erik Joelsson (erik.joels...@oracle.com)
wrote:



On 2018-07-19 12:52, Tony Printezis wrote:

Erik,

Many thanks for looking at this change!

I can totally add the VERSION_EXTRAX variables to the spec.gmk file.

Related: I was not sure what to do with VERSION_NUMBER_ALL_POSITIONS. Right
now, VERSION_NUMBER_FOUR_POSITIONS is exposed to the spec.gmk file but I'm
not sure exactly where it’s used. Is it worth also exposing
VERSION_NUMBER_ALL_POSITIONS? I didn’t to make sure that anything that
relies on VERSION_NUMBER_FOUR_POSITIONS having exactly four numbers didn’t
break (and I’m happy to leave it as is).

The VERSION_NUMBER_FOUR_POSITIONS is used in windows launcher manifests
(shows up if you right click a windows executable) and it's used internally
at Oracle for Windows installers. I believe (but is not 100% sure) that the
format with 4 numbers is specifically needed in the windows manifest case.

/Erik

Tony

—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On July 19, 2018 at 3:02:26 PM, Erik Joelsson (erik.joels...@oracle.com)
wrote:

Hello Tony,

I think this looks ok. We like to keep AC_SUBST calls paired with
variables in spec.gmk.in so please add corresponding VERSION_EXTRAX
variables there.

/Erik


On 2018-07-19 11:46, Tony Printezis wrote:
> Hi all,
>
> Here’s the webrev for this:
>
> http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/
>
> I’m no configure expert so I basically did a cut-and-paste of what was
> already there. If there’s a way to do this better (maybe, cut down on the
> awkward code replication), let let me know.
>
> The decision to allow up to 3 extra numbers was arbitrary. I can do more
or
> fewer.
>
> Tony
>
> —
> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

[Erik Joelsson]

On 2018-07-19 12:52, Tony Printezis wrote:

Erik,

Many thanks for looking at this change!

I can totally add the VERSION_EXTRAX variables to the spec.gmk file.

Related: I was not sure what to do with VERSION_NUMBER_ALL_POSITIONS. 
Right now, VERSION_NUMBER_FOUR_POSITIONS is exposed to the spec.gmk 
file but I'm not sure exactly where it’s used. Is it worth also 
exposing VERSION_NUMBER_ALL_POSITIONS? I didn’t to make sure that 
anything that relies on VERSION_NUMBER_FOUR_POSITIONS having exactly 
four numbers didn’t break (and I’m happy to leave it as is).


The VERSION_NUMBER_FOUR_POSITIONS is used in windows launcher manifests 
(shows up if you right click a windows executable) and it's used 
internally at Oracle for Windows installers. I believe (but is not 100% 
sure) that the format with 4 numbers is specifically needed in the 
windows manifest case.


/Erik

Tony

—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com 




On July 19, 2018 at 3:02:26 PM, Erik Joelsson 
(erik.joels...@oracle.com ) wrote:



Hello Tony,

I think this looks ok. We like to keep AC_SUBST calls paired with
variables in spec.gmk.in  so please add 
corresponding VERSION_EXTRAX

variables there.

/Erik


On 2018-07-19 11:46, Tony Printezis wrote:
> Hi all,
>
> Here’s the webrev for this:
>
> http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/ 


>
> I’m no configure expert so I basically did a cut-and-paste of what was
> already there. If there’s a way to do this better (maybe, cut down 
on the

> awkward code replication), let let me know.
>
> The decision to allow up to 3 extra numbers was arbitrary. I can do 
more or

> fewer.
>
> Tony
>
> —
> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com 

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

[Tony Printezis]

Erik,

Many thanks for looking at this change!

I can totally add the VERSION_EXTRAX variables to the spec.gmk file.

Related: I was not sure what to do with VERSION_NUMBER_ALL_POSITIONS. Right
now, VERSION_NUMBER_FOUR_POSITIONS is exposed to the spec.gmk file but I'm
not sure exactly where it’s used. Is it worth also exposing
VERSION_NUMBER_ALL_POSITIONS? I didn’t to make sure that anything that
relies on VERSION_NUMBER_FOUR_POSITIONS having exactly four numbers didn’t
break (and I’m happy to leave it as is).

Tony

—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On July 19, 2018 at 3:02:26 PM, Erik Joelsson (erik.joels...@oracle.com)
wrote:

Hello Tony,

I think this looks ok. We like to keep AC_SUBST calls paired with
variables in spec.gmk.in so please add corresponding VERSION_EXTRAX
variables there.

/Erik


On 2018-07-19 11:46, Tony Printezis wrote:
> Hi all,
>
> Here’s the webrev for this:
>
> http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/
>
> I’m no configure expert so I basically did a cut-and-paste of what was
> already there. If there’s a way to do this better (maybe, cut down on the
> awkward code replication), let let me know.
>
> The decision to allow up to 3 extra numbers was arbitrary. I can do more
or
> fewer.
>
> Tony
>
> —
> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com

Re: adding additional numbers to the Java version string

[Tony Printezis]

Hi Martin,

Yes, we have also used the opt field too. However, if I understand the spec
correctly, when doing version comparisons, the opt string is compared
alphanumerically. So if you add any numbers to it, you have to plan ahead
and pad with enough 0s to make sure the comparison works as expected. Given
that the spec now allows extra numbers in the version string, it’d be good
to be able to use that instead.

Additionally, we want both compareTo() and compareToIgnoreOptional() to
show our version as different to the upstream one it’s synced up to. And
adding an extra number to the version string satisfies that too.

Other folks might want this to behave differently, and that’s totally OK!
But, the change I proposed will help anyone who has the above requirement.

Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On July 19, 2018 at 1:30:40 PM, Martin Buchholz (marti...@google.com) wrote:

At Google we use --with-version-opt to put in local version data - that
works for us.

--with-version-patch is also available for third party build use.


On Thu, Jul 19, 2018 at 6:54 AM, Erik Joelsson 
wrote:

> Since JEP 223 specifies an arbitrary length (something I had missed
> before), I agree the build should support a few extra version numbers.
>
> /Erik
>
>
> On 2018-07-18 13:22, Tony Printezis wrote:
>
>> Hi all,
>>
>> According to the Java version string spec (JEPs 223 and 322) the first
>> part
>> of the version string is a sequence of numbers separated by periods. The
>> sequence can be of arbitrary length. However, in the OpenJDK configure
>> scripts, the sequence length is fixed to exactly four numbers.
>>
>> For our internal builds we’d like to add at least one additional number to
>> the version string. Is there any interest in a change to the scripts to
>> allow that?
>>
>> I’ve prototyped this in a generic way (can add up to 3 additional numbers,
>> called “extra1”, “extra2”, and “extra3”). These are set by passing
>> --with-version-extra(1|2|3)=… to configure. If they are not set, the
>> version string is of course exactly the same as it was before. I also
>> changed the way the value of --with-version-string=… is parsed to be able
>> to also extract the additional three numbers, if present.
>>
>> Would this be generally helpful?
>>
>> Tony
>>
>> —
>> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
>>
>
>

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 2:31 PM, Erik Joelsson  wrote:
> 
> I can do that. Do you have a bug?
> 
No.
> /Erik
> 
> On 2018-07-19 10:57, Christian Thalinger wrote:
>> 
>> 
>> On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson > > wrote:
>> This looks good to me, but will need coordination when pushed as I said 
>> earlier.
>> 
>> 
>> Do you want to push it so it’s easier?
>> 
>> /Erik
>> 
>> On 2018-07-19 10:04, Christian Thalinger wrote:
>>> 
>>> 
 On Jul 19, 2018, at 12:57 PM, Erik Joelsson >>> > wrote:
 
 
 
 On 2018-07-19 09:54, Christian Thalinger wrote:
> 
> 
>> On Jul 19, 2018, at 12:44 PM, Erik Joelsson > > wrote:
>> 
>> 
>> On 2018-07-19 09:16, Christian Thalinger wrote:
>>> 
>>> 
>>> Well, the issue is this:
>>> 
>>> exploded-image: exploded-image-base release-file
>>> 
>>>   release-file: create-source-revision-tracker
>>> 
>>> store-source-revision:
>>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
>>> SourceRevision.gmk store-source-revision)
>>> 
>>> create-source-revision-tracker:
>>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
>>> SourceRevision.gmk create-source-revision-tracker)
>>> 
>>> We need these targets because all isn’t really used.
>>> 
>> Ah, the all target is tricking me and should be removed if not called 
>> from anywhere. Then your suggested patch is good (except for missing the 
>> :=).
> 
> Do you want me to remove the all: target?
> 
 Yes, that would be a good cleanup to avoid confusion.
>>> 
>>> How about this:
>>> 
>>> diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
>>> index 10dd943..6d4a706 100644
>>> --- a/make/SourceRevision.gmk
>>> +++ b/make/SourceRevision.gmk
>>> @@ -1,5 +1,5 @@
>>>  #
>>> -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
>>> +# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights 
>>> reserved.
>>>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  #
>>>  # This code is free software; you can redistribute it and/or modify it
>>> @@ -23,12 +23,10 @@
>>>  # questions.
>>>  #
>>>  
>>> -default: all
>>> -
>>>  include $(SPEC)
>>>  include MakeBase.gmk
>>>  
>>> -$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
>>> +$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
>>>  
>>>  
>>> 
>>>  # Keep track of what source revision is used to create the build, by 
>>> creating
>>> @@ -94,11 +92,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
>>>  
>>>$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
>>>  
>>> -  store-source-revision: $(STORED_SOURCE_REVISION)
>>> +  hg-store-source-revision: $(STORED_SOURCE_REVISION)
>>>  
>>>$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
>>>  
>>> -  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>>> +  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>>> +
>>> +  STORE_SOURCE_REVISION_TARGET := hg-store-source-revision
>>> +  CREATE_SOURCE_REVISION_TRACKER_TARGET := 
>>> hg-create-source-revision-tracker
>>>  
>>>  else
>>># Not using HG
>>> @@ -106,28 +107,39 @@ else
>>>ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
>>>  # We have a stored source revision (.src-rev)
>>>  
>>> -store-source-revision:
>>> +src-store-source-revision:
>>> $(call LogInfo, No mercurial configuration present$(COMMA) not 
>>> updating .src-rev)
>>>  
>>>  $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
>>> $(install-file)
>>>  
>>> -create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>>> +src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>>>else
>>>  # We don't have a stored source revision. Can't do anything, really.
>>>  
>>> -store-source-revision:
>>> +src-store-source-revision:
>>> $(call LogWarn, Error: No mercurial configuration present$(COMMA) 
>>> cannot create .src-rev)
>>> exit 2
>>>  
>>> -create-source-revision-tracker:
>>> +src-create-source-revision-tracker:
>>> $(call LogWarn, Warning: No mercurial configuration present and no 
>>> .src-rev)
>>>endif
>>>  
>>> +  STORE_SOURCE_REVISION_TARGET := src-store-source-revision
>>> +  CREATE_SOURCE_REVISION_TRACKER_TARGET := 
>>> src-create-source-revision-tracker
>>> +
>>>  endif
>>>  
>>> -all: store-source-revision create-source-revision-tracker
>>> +
>>> +
>>> +$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
>>> +
>>> +
>>> +
>>> +store-source-revision: 

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

[Erik Joelsson]

Hello Tony,

I think this looks ok. We like to keep AC_SUBST calls paired with 
variables in spec.gmk.in so please add corresponding VERSION_EXTRAX 
variables there.


/Erik


On 2018-07-19 11:46, Tony Printezis wrote:

Hi all,

Here’s the webrev for this:

http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/

I’m no configure expert so I basically did a cut-and-paste of what was
already there. If there’s a way to do this better (maybe, cut down on the
awkward code replication), let let me know.

The decision to allow up to 3 extra numbers was arbitrary. I can do more or
fewer.

Tony

—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com

RFR: 8207849: Allow the addition of more number to the Java version string (S)

[Tony Printezis]

Hi all,

Here’s the webrev for this:

http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/

I’m no configure expert so I basically did a cut-and-paste of what was
already there. If there’s a way to do this better (maybe, cut down on the
awkward code replication), let let me know.

The decision to allow up to 3 extra numbers was arbitrary. I can do more or
fewer.

Tony

—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com

Re: custom extension for make/SourceRevision.gmk

[Erik Joelsson]

I can do that. Do you have a bug?

/Erik


On 2018-07-19 10:57, Christian Thalinger wrote:



On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson 
mailto:erik.joels...@oracle.com>> wrote:


This looks good to me, but will need coordination when pushed as I
said earlier.


Do you want to push it so it’s easier?

/Erik


On 2018-07-19 10:04, Christian Thalinger wrote:




On Jul 19, 2018, at 12:57 PM, Erik Joelsson
mailto:erik.joels...@oracle.com>> wrote:



On 2018-07-19 09:54, Christian Thalinger wrote:




On Jul 19, 2018, at 12:44 PM, Erik Joelsson
mailto:erik.joels...@oracle.com>>
wrote:


On 2018-07-19 09:16, Christian Thalinger wrote:



Well, the issue is this:

exploded-image: exploded-image-base release-file

  release-file: create-source-revision-tracker

store-source-revision:
        +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f
SourceRevision.gmk store-source-revision)

create-source-revision-tracker:
        +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f
SourceRevision.gmk create-source-revision-tracker)

We need these targets because all isn’t really used.


Ah, the all target is tricking me and should be removed if not
called from anywhere. Then your suggested patch is good
(except for missing the :=).


Do you want me to remove the all: target?


Yes, that would be a good cleanup to avoid confusion.


How about this:

diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
index 10dd943..6d4a706 100644
--- a/make/SourceRevision.gmk
+++ b/make/SourceRevision.gmk
@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2016, Oracle and/or its affiliates. All rights
reserved.
+# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All
rights reserved.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or
modify it
@@ -23,12 +23,10 @@
 # questions.
 #


-default: all
-
 include $(SPEC)
 include MakeBase.gmk


-$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
+$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))


 

 # Keep track of what source revision is used to create the
build, by creating
@@ -94,11 +92,14 @@ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )


$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))


- store-source-revision: $(STORED_SOURCE_REVISION)
+ hg-store-source-revision: $(STORED_SOURCE_REVISION)


$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))


- create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+ hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+
+ STORE_SOURCE_REVISION_TARGET := hg-store-source-revision
+ CREATE_SOURCE_REVISION_TRACKER_TARGET :=
hg-create-source-revision-tracker


 else
# Not using HG
@@ -106,28 +107,39 @@else
ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
  # We have a stored source revision (.src-rev)


-   store-source-revision:
+   src-store-source-revision:
      $(call LogInfo, No mercurial configuration present$(COMMA)
not updating .src-rev)


  $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
      $(install-file)


-   create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+   src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
else
  # We don't have a stored source revision. Can't do anything,
really.


-   store-source-revision:
+   src-store-source-revision:
      $(call LogWarn, Error: No mercurial configuration
present$(COMMA) cannot create .src-rev)
      exit 2


-   create-source-revision-tracker:
+   src-create-source-revision-tracker:
      $(call LogWarn, Warning: No mercurial configuration present
and no .src-rev)
endif


+ STORE_SOURCE_REVISION_TARGET := src-store-source-revision
+ CREATE_SOURCE_REVISION_TRACKER_TARGET :=
src-create-source-revision-tracker
+
 endif


-all: store-source-revision create-source-revision-tracker

+
+
+$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
+

+
+
+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker:
$(CREATE_SOURCE_REVISION_TRACKER_TARGET)


 FRC: # Force target


-.PHONY: all store-source-revision create-source-revision-tracker
+.PHONY: store-source-revision create-source-revision-tracker

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson 
wrote:

> This looks good to me, but will need coordination when pushed as I said
> earlier.
>

Do you want to push it so it’s easier?

/Erik
>
> On 2018-07-19 10:04, Christian Thalinger wrote:
>
>
>
> On Jul 19, 2018, at 12:57 PM, Erik Joelsson 
> wrote:
>
>
>
> On 2018-07-19 09:54, Christian Thalinger wrote:
>
>
>
> On Jul 19, 2018, at 12:44 PM, Erik Joelsson 
> wrote:
>
>
> On 2018-07-19 09:16, Christian Thalinger wrote:
>
>
>
> Well, the issue is this:
>
> exploded-image: exploded-image-base release-file
>
>   release-file: create-source-revision-tracker
>
> store-source-revision:
> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f
> SourceRevision.gmk store-source-revision)
>
> create-source-revision-tracker:
> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f
> SourceRevision.gmk create-source-revision-tracker)
>
> We need these targets because all isn’t really used.
>
> Ah, the all target is tricking me and should be removed if not called from
> anywhere. Then your suggested patch is good (except for missing the :=).
>
>
> Do you want me to remove the all: target?
>
> Yes, that would be a good cleanup to avoid confusion.
>
>
> How about this:
>
> diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
> index 10dd943..6d4a706 100644
> --- a/make/SourceRevision.gmk
> +++ b/make/SourceRevision.gmk
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> +# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights
> reserved.
>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  #
>  # This code is free software; you can redistribute it and/or modify it
> @@ -23,12 +23,10 @@
>  # questions.
>  #
>
>
> -default: all
> -
>  include $(SPEC)
>  include MakeBase.gmk
>
>
> -$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
> +$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
>
>
>
>  
> 
>  # Keep track of what source revision is used to create the build, by
> creating
> @@ -94,11 +92,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
>
>
>$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
>
>
> -  store-source-revision: $(STORED_SOURCE_REVISION)
> +  hg-store-source-revision: $(STORED_SOURCE_REVISION)
>
>
>$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
>
>
> -  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
> +  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
> +
> +  STORE_SOURCE_REVISION_TARGET := hg-store-source-revision
> +  CREATE_SOURCE_REVISION_TRACKER_TARGET :=
> hg-create-source-revision-tracker
>
>
>  else
># Not using HG
> @@ -106,28 +107,39 @@ else
>ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
>  # We have a stored source revision (.src-rev)
>
>
> -store-source-revision:
> +src-store-source-revision:
> $(call LogInfo, No mercurial configuration present$(COMMA) not
> updating .src-rev)
>
>
>  $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
> $(install-file)
>
>
> -create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
> +src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>else
>  # We don't have a stored source revision. Can't do anything, really.
>
>
> -store-source-revision:
> +src-store-source-revision:
> $(call LogWarn, Error: No mercurial configuration present$(COMMA)
> cannot create .src-rev)
> exit 2
>
>
> -create-source-revision-tracker:
> +src-create-source-revision-tracker:
> $(call LogWarn, Warning: No mercurial configuration present and no
> .src-rev)
>endif
>
>
> +  STORE_SOURCE_REVISION_TARGET := src-store-source-revision
> +  CREATE_SOURCE_REVISION_TRACKER_TARGET :=
> src-create-source-revision-tracker
> +
>  endif
>
>
> -all: store-source-revision create-source-revision-tracker
>
> +
> +
> +$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
> +
>
> +
> +
> +store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
> +
> +create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
>
>
>  FRC: # Force target
>
>
> -.PHONY: all store-source-revision create-source-revision-tracker
> +.PHONY: store-source-revision create-source-revision-tracker
>
>
>

Re: 8207830: [aix] disable jfr in build and tests

[Erik Joelsson]

Build changes look good.

/Erik


On 2018-07-19 10:22, Vladimir Kozlov wrote:

Tests changes are good.

Thank you for fixing aot check in hotspot.m4

In VMProps.java I would suggest to follow code pattern from other 
features. Add new method vmHasJFR() which returns "true" or "false" 
instead of:


map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());

We may need such method to add other conditions in future.

Thanks,
Vladimir

On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:

Hi,

We didn't manage to port JFR to aix in the jdk11 time frame.
Thus I would like to disable it in the build.
As well, I would like to introduce @requires vm.hasJFR which
will disable the tests on aix, and also on linuxsparcv9 and zero.

Two webrevs for better readability:
This contains the functional changes
http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
This contains adding @requires.
http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/


http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/

The only one not straight forward is 
runtime/appcds/sharedStrings/FlagCombo.java


Best regards,
   Goetz.

Re: adding additional numbers to the Java version string

[Martin Buchholz]

At Google we use --with-version-opt to put in local version data - that
works for us.

--with-version-patch is also available for third party build use.


On Thu, Jul 19, 2018 at 6:54 AM, Erik Joelsson 
wrote:

> Since JEP 223 specifies an arbitrary length (something I had missed
> before), I agree the build should support a few extra version numbers.
>
> /Erik
>
>
> On 2018-07-18 13:22, Tony Printezis wrote:
>
>> Hi all,
>>
>> According to the Java version string spec (JEPs 223 and 322) the first
>> part
>> of the version string is a sequence of numbers separated by periods. The
>> sequence can be of arbitrary length. However, in the OpenJDK configure
>> scripts, the sequence length is fixed to exactly four numbers.
>>
>> For our internal builds we’d like to add at least one additional number to
>> the version string. Is there any interest in a change to the scripts to
>> allow that?
>>
>> I’ve prototyped this in a generic way (can add up to 3 additional numbers,
>> called “extra1”, “extra2”, and “extra3”). These are set by passing
>> --with-version-extra(1|2|3)=… to configure. If they are not set, the
>> version string is of course exactly the same as it was before. I also
>> changed the way the value of --with-version-string=… is parsed to be able
>> to also extract the additional three numbers, if present.
>>
>> Would this be generally helpful?
>>
>> Tony
>>
>> —
>> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
>>
>
>

Re: 8207830: [aix] disable jfr in build and tests

[Vladimir Kozlov]

Tests changes are good.

Thank you for fixing aot check in hotspot.m4

In VMProps.java I would suggest to follow code pattern from other 
features. Add new method vmHasJFR() which returns "true" or "false" 
instead of:


map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());

We may need such method to add other conditions in future.

Thanks,
Vladimir

On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:

Hi,

We didn't manage to port JFR to aix in the jdk11 time frame.
Thus I would like to disable it in the build.
As well, I would like to introduce @requires vm.hasJFR which
will disable the tests on aix, and also on linuxsparcv9 and zero.

Two webrevs for better readability:
This contains the functional changes
http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
This contains adding @requires.
http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/


http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/


The only one not straight forward is runtime/appcds/sharedStrings/FlagCombo.java

Best regards,
   Goetz.

Re: custom extension for make/SourceRevision.gmk

[Erik Joelsson]

This looks good to me, but will need coordination when pushed as I said 
earlier.


/Erik


On 2018-07-19 10:04, Christian Thalinger wrote:



On Jul 19, 2018, at 12:57 PM, Erik Joelsson > wrote:




On 2018-07-19 09:54, Christian Thalinger wrote:



On Jul 19, 2018, at 12:44 PM, Erik Joelsson 
mailto:erik.joels...@oracle.com>> wrote:



On 2018-07-19 09:16, Christian Thalinger wrote:



Well, the issue is this:

exploded-image: exploded-image-base release-file

  release-file: create-source-revision-tracker

store-source-revision:
+($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
SourceRevision.gmk store-source-revision)


create-source-revision-tracker:
+($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
SourceRevision.gmk create-source-revision-tracker)


We need these targets because all isn’t really used.

Ah, the all target is tricking me and should be removed if not 
called from anywhere. Then your suggested patch is good (except for 
missing the :=).


Do you want me to remove the all: target?


Yes, that would be a good cleanup to avoid confusion.


How about this:

diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
index 10dd943..6d4a706 100644
--- a/make/SourceRevision.gmk
+++ b/make/SourceRevision.gmk
@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights 
reserved.

 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or modify it
@@ -23,12 +23,10 @@
 # questions.
 #


-default: all
-
 include $(SPEC)
 include MakeBase.gmk


-$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
+$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))


 

 # Keep track of what source revision is used to create the build, by 
creating

@@ -94,11 +92,14 @@ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )


$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))


- store-source-revision: $(STORED_SOURCE_REVISION)
+ hg-store-source-revision: $(STORED_SOURCE_REVISION)


$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))


- create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+ hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+
+ STORE_SOURCE_REVISION_TARGET := hg-store-source-revision
+ CREATE_SOURCE_REVISION_TRACKER_TARGET := 
hg-create-source-revision-tracker



 else
# Not using HG
@@ -106,28 +107,39 @@else
ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
  # We have a stored source revision (.src-rev)


-   store-source-revision:
+   src-store-source-revision:
      $(call LogInfo, No mercurial configuration present$(COMMA) not 
updating .src-rev)



  $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
      $(install-file)


-   create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+   src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
else
  # We don't have a stored source revision. Can't do anything, really.


-   store-source-revision:
+   src-store-source-revision:
      $(call LogWarn, Error: No mercurial configuration 
present$(COMMA) cannot create .src-rev)

      exit 2


-   create-source-revision-tracker:
+   src-create-source-revision-tracker:
      $(call LogWarn, Warning: No mercurial configuration present and 
no .src-rev)

endif


+ STORE_SOURCE_REVISION_TARGET := src-store-source-revision
+ CREATE_SOURCE_REVISION_TRACKER_TARGET := 
src-create-source-revision-tracker

+
 endif


-all: store-source-revision create-source-revision-tracker
+
+
+$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
+
+
+
+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)


 FRC: # Force target


-.PHONY: all store-source-revision create-source-revision-tracker
+.PHONY: store-source-revision create-source-revision-tracker

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 12:57 PM, Erik Joelsson  wrote:
> 
> 
> 
> On 2018-07-19 09:54, Christian Thalinger wrote:
>> 
>> 
>>> On Jul 19, 2018, at 12:44 PM, Erik Joelsson >> > wrote:
>>> 
>>> 
>>> On 2018-07-19 09:16, Christian Thalinger wrote:
 
 
 Well, the issue is this:
 
 exploded-image: exploded-image-base release-file
 
   release-file: create-source-revision-tracker
 
 store-source-revision:
 +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
 SourceRevision.gmk store-source-revision)
 
 create-source-revision-tracker:
 +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
 SourceRevision.gmk create-source-revision-tracker)
 
 We need these targets because all isn’t really used.
 
>>> Ah, the all target is tricking me and should be removed if not called from 
>>> anywhere. Then your suggested patch is good (except for missing the :=).
>> 
>> Do you want me to remove the all: target?
>> 
> Yes, that would be a good cleanup to avoid confusion.

How about this:

diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
index 10dd943..6d4a706 100644
--- a/make/SourceRevision.gmk
+++ b/make/SourceRevision.gmk
@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or modify it
@@ -23,12 +23,10 @@
 # questions.
 #
 
-default: all
-
 include $(SPEC)
 include MakeBase.gmk
 
-$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
+$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
 
 

 # Keep track of what source revision is used to create the build, by creating
@@ -94,11 +92,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
 
   $(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
 
-  store-source-revision: $(STORED_SOURCE_REVISION)
+  hg-store-source-revision: $(STORED_SOURCE_REVISION)
 
   $(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
 
-  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+
+  STORE_SOURCE_REVISION_TARGET := hg-store-source-revision
+  CREATE_SOURCE_REVISION_TRACKER_TARGET := hg-create-source-revision-tracker
 
 else
   # Not using HG
@@ -106,28 +107,39 @@ else
   ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
 # We have a stored source revision (.src-rev)
 
-store-source-revision:
+src-store-source-revision:
$(call LogInfo, No mercurial configuration present$(COMMA) not updating 
.src-rev)
 
 $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
$(install-file)
 
-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
   else
 # We don't have a stored source revision. Can't do anything, really.
 
-store-source-revision:
+src-store-source-revision:
$(call LogWarn, Error: No mercurial configuration present$(COMMA) 
cannot create .src-rev)
exit 2
 
-create-source-revision-tracker:
+src-create-source-revision-tracker:
$(call LogWarn, Warning: No mercurial configuration present and no 
.src-rev)
   endif
 
+  STORE_SOURCE_REVISION_TARGET := src-store-source-revision
+  CREATE_SOURCE_REVISION_TRACKER_TARGET := src-create-source-revision-tracker
+
 endif
 
-all: store-source-revision create-source-revision-tracker
+
+
+$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
+
+
+
+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
 
 FRC: # Force target
 
-.PHONY: all store-source-revision create-source-revision-tracker
+.PHONY: store-source-revision create-source-revision-tracker

Re: custom extension for make/SourceRevision.gmk

[Erik Joelsson]

On 2018-07-19 09:54, Christian Thalinger wrote:



On Jul 19, 2018, at 12:44 PM, Erik Joelsson > wrote:



On 2018-07-19 09:16, Christian Thalinger wrote:



Well, the issue is this:

exploded-image: exploded-image-base release-file

  release-file: create-source-revision-tracker

store-source-revision:
        +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
SourceRevision.gmk store-source-revision)


create-source-revision-tracker:
        +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
SourceRevision.gmk create-source-revision-tracker)


We need these targets because all isn’t really used.

Ah, the all target is tricking me and should be removed if not called 
from anywhere. Then your suggested patch is good (except for missing 
the :=).


Do you want me to remove the all: target?


Yes, that would be a good cleanup to avoid confusion.

/Erik


/Erik

+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker: 
$(CREATE_SOURCE_REVISION_TRACKER_TARGET)

+
 all: store-source-revision create-source-revision-tracker

 FRC: # Force target

Do you really need the separate variables? Since both of them are 
built by all anyway, I would just have one variable TARGETS to 
which you add everything you wish to build and finish with "all: 
$(TARGETS)".


/Erik

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 12:44 PM, Erik Joelsson  wrote:
> 
> 
> On 2018-07-19 09:16, Christian Thalinger wrote:
>> 
>> 
>> Well, the issue is this:
>> 
>> exploded-image: exploded-image-base release-file
>> 
>>   release-file: create-source-revision-tracker
>> 
>> store-source-revision:
>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
>> store-source-revision)
>> 
>> create-source-revision-tracker:
>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
>> create-source-revision-tracker)
>> 
>> We need these targets because all isn’t really used.
>> 
> Ah, the all target is tricking me and should be removed if not called from 
> anywhere. Then your suggested patch is good (except for missing the :=).

Do you want me to remove the all: target?

> 
> /Erik
 +store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
 +
 +create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
 +
  all: store-source-revision create-source-revision-tracker
  
  FRC: # Force target
 
>>> Do you really need the separate variables? Since both of them are built by 
>>> all anyway, I would just have one variable TARGETS to which you add 
>>> everything you wish to build and finish with "all: $(TARGETS)".
>>> 
>>> /Erik
>> 
> 

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 12:46 PM, Erik Joelsson  wrote:
> 
> One thing though. Since you are renaming the top file, we need to coordinate 
> pushing of this change since we are relying on the old name.

We can keep the old name, if you want, but that wouldn’t be very consistent 
with other files.

> 
> /Erik
> 
> 
> On 2018-07-19 09:44, Erik Joelsson wrote:
>> 
>> On 2018-07-19 09:16, Christian Thalinger wrote:
>>> 
>>> 
>>> Well, the issue is this:
>>> 
>>> exploded-image: exploded-image-base release-file
>>> 
>>>   release-file: create-source-revision-tracker
>>> 
>>> store-source-revision:
>>>   +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
>>> store-source-revision)
>>> 
>>> create-source-revision-tracker:
>>>   +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
>>> create-source-revision-tracker)
>>> 
>>> We need these targets because all isn’t really used.
>>> 
>> Ah, the all target is tricking me and should be removed if not called from 
>> anywhere. Then your suggested patch is good (except for missing the :=).
>> 
>> /Erik
> +store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
> +
> +create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
> +
>  all: store-source-revision create-source-revision-tracker
> 
>  FRC: # Force target
> 
 Do you really need the separate variables? Since both of them are built by 
 all anyway, I would just have one variable TARGETS to which you add 
 everything you wish to build and finish with "all: $(TARGETS)".
 
 /Erik
>>> 
>> 
> 

Re: custom extension for make/SourceRevision.gmk

[Erik Joelsson]

One thing though. Since you are renaming the top file, we need to 
coordinate pushing of this change since we are relying on the old name.


/Erik


On 2018-07-19 09:44, Erik Joelsson wrote:


On 2018-07-19 09:16, Christian Thalinger wrote:



Well, the issue is this:

exploded-image: exploded-image-base release-file

  release-file: create-source-revision-tracker

store-source-revision:
      +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
SourceRevision.gmk store-source-revision)


create-source-revision-tracker:
      +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
SourceRevision.gmk create-source-revision-tracker)


We need these targets because all isn’t really used.

Ah, the all target is tricking me and should be removed if not called 
from anywhere. Then your suggested patch is good (except for missing 
the :=).


/Erik

+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker: 
$(CREATE_SOURCE_REVISION_TRACKER_TARGET)

+
 all: store-source-revision create-source-revision-tracker

 FRC: # Force target

Do you really need the separate variables? Since both of them are 
built by all anyway, I would just have one variable TARGETS to which 
you add everything you wish to build and finish with "all: $(TARGETS)".


/Erik

Re: custom extension for make/SourceRevision.gmk

[Erik Joelsson]

On 2018-07-19 09:16, Christian Thalinger wrote:



Well, the issue is this:

exploded-image: exploded-image-base release-file

  release-file: create-source-revision-tracker

store-source-revision:
      +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
SourceRevision.gmk store-source-revision)


create-source-revision-tracker:
      +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
SourceRevision.gmk create-source-revision-tracker)


We need these targets because all isn’t really used.

Ah, the all target is tricking me and should be removed if not called 
from anywhere. Then your suggested patch is good (except for missing the 
:=).


/Erik

+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker: 
$(CREATE_SOURCE_REVISION_TRACKER_TARGET)

+
 all: store-source-revision create-source-revision-tracker

 FRC: # Force target

Do you really need the separate variables? Since both of them are 
built by all anyway, I would just have one variable TARGETS to which 
you add everything you wish to build and finish with "all: $(TARGETS)".


/Erik

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 12:08 PM, Erik Joelsson  wrote:
> 
> Hello,
> On 2018-07-19 07:43, Christian Thalinger wrote:
>> 
>> 
>>> On Jul 18, 2018, at 3:28 PM, Christian Thalinger >> > wrote:
>>> 
>>> 
>>> 
 On Jul 18, 2018, at 1:46 PM, Erik Joelsson >>> > wrote:
 
 Hello Christian,
 
 Sometimes we need hooks both close to the beginning and close to the end 
 of the file, and in that case we create a SourceBundle-post.gmk. The 
 recommended position of the post inclusion is right before the typical 
 "all: $(TARGETS)" declaration. This file has the all target depend 
 explicitly on a list of phony targets and no TARGETS variable, so I would 
 recommend changing that to building a TARGETS variable like we usually do. 
 That way you can create a SourceBundle-post.gmk and clear the TARGETS 
 variable from any targets you don't want to run from the open file. Does 
 that sound ok?
>>> 
>>> Yes, that would be great.  In JDK 11, please :-)
>> 
>> Ok, this is the only way I could make it work:
>> 
>> diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
>> index 10dd943..13ea407 100644
>> --- a/make/SourceRevision.gmk
>> +++ b/make/SourceRevision.gmk
>> @@ -28,7 +28,7 @@ default: all
>>  include $(SPEC)
>>  include MakeBase.gmk
>>  
>> -$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
>> +$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
>>  
>>  
>> 
>>  # Keep track of what source revision is used to create the build, by 
>> creating
>> @@ -94,11 +94,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
>>  
>>$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
>>  
>> -  store-source-revision: $(STORED_SOURCE_REVISION)
>> +  hg-store-source-revision: $(STORED_SOURCE_REVISION)
>>  
>>$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
>>  
>> -  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>> +  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>> +
> These assignments should be using :=. Applies further down as well.
>> +  STORE_SOURCE_REVISION_TARGET = hg-store-source-revision
>> +  CREATE_SOURCE_REVISION_TRACKER_TARGET = hg-create-source-revision-tracker
>>  
>>  else
>># Not using HG
>> @@ -106,26 +109,39 @@ else
>>ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
>>  # We have a stored source revision (.src-rev)
>>  
>> -store-source-revision:
>> +src-store-source-revision:
>> $(call LogInfo, No mercurial configuration present$(COMMA) not 
>> updating .src-rev)
>>  
>>  $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
>> $(install-file)
>>  
>> -create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>> +src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>>else
>>  # We don't have a stored source revision. Can't do anything, really.
>>  
>> -store-source-revision:
>> +src-store-source-revision:
>> $(call LogWarn, Error: No mercurial configuration present$(COMMA) 
>> cannot create .src-rev)
>> exit 2
>>  
>> -create-source-revision-tracker:
>> +src-create-source-revision-tracker:
>> $(call LogWarn, Warning: No mercurial configuration present and no 
>> .src-rev)
>>endif
>>  
>> +  STORE_SOURCE_REVISION_TARGET = src-store-source-revision
>> +  CREATE_SOURCE_REVISION_TRACKER_TARGET = src-create-source-revision-tracker
>> +
>>  endif
>>  
>> +
>> +
>> +$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
>> +
>> +
>> +
> I would suggest using the variables directly on the all: line instead of 
> declaring more phony targets. 

Well, the issue is this:

exploded-image: exploded-image-base release-file

  release-file: create-source-revision-tracker

store-source-revision:
+($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
store-source-revision)

create-source-revision-tracker:
+($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
create-source-revision-tracker)

We need these targets because all isn’t really used.

>> +store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
>> +
>> +create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
>> +
>>  all: store-source-revision create-source-revision-tracker
>>  
>>  FRC: # Force target
>> 
> Do you really need the separate variables? Since both of them are built by 
> all anyway, I would just have one variable TARGETS to which you add 
> everything you wish to build and finish with "all: $(TARGETS)".
> 
> /Erik

Re: custom extension for make/SourceRevision.gmk

[Erik Joelsson]

Hello,

On 2018-07-19 07:43, Christian Thalinger wrote:



On Jul 18, 2018, at 3:28 PM, Christian Thalinger 
mailto:cthalin...@twitter.com>> wrote:




On Jul 18, 2018, at 1:46 PM, Erik Joelsson > wrote:


Hello Christian,

Sometimes we need hooks both close to the beginning and close to the 
end of the file, and in that case we create a SourceBundle-post.gmk. 
The recommended position of the post inclusion is right before the 
typical "all: $(TARGETS)" declaration. This file has the all target 
depend explicitly on a list of phony targets and no TARGETS 
variable, so I would recommend changing that to building a TARGETS 
variable like we usually do. That way you can create a 
SourceBundle-post.gmk and clear the TARGETS variable from any 
targets you don't want to run from the open file. Does that sound ok?


Yes, that would be great.  In JDK 11, please :-)


Ok, this is the only way I could make it work:

diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
index 10dd943..13ea407 100644
--- a/make/SourceRevision.gmk
+++ b/make/SourceRevision.gmk
@@ -28,7 +28,7 @@default: all
 include $(SPEC)
 include MakeBase.gmk


-$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
+$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))


 

 # Keep track of what source revision is used to create the build, by 
creating

@@ -94,11 +94,14 @@ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )


$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))


- store-source-revision: $(STORED_SOURCE_REVISION)
+ hg-store-source-revision: $(STORED_SOURCE_REVISION)


$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))


- create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+ hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+

These assignments should be using :=. Applies further down as well.

+ STORE_SOURCE_REVISION_TARGET = hg-store-source-revision
+ CREATE_SOURCE_REVISION_TRACKER_TARGET = 
hg-create-source-revision-tracker



 else
# Not using HG
@@ -106,26 +109,39 @@else
ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
  # We have a stored source revision (.src-rev)


-   store-source-revision:
+   src-store-source-revision:
      $(call LogInfo, No mercurial configuration present$(COMMA) not 
updating .src-rev)



  $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
      $(install-file)


-   create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+   src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
else
  # We don't have a stored source revision. Can't do anything, really.


-   store-source-revision:
+   src-store-source-revision:
      $(call LogWarn, Error: No mercurial configuration 
present$(COMMA) cannot create .src-rev)

      exit 2


-   create-source-revision-tracker:
+   src-create-source-revision-tracker:
      $(call LogWarn, Warning: No mercurial configuration present and 
no .src-rev)

endif


+ STORE_SOURCE_REVISION_TARGET = src-store-source-revision
+ CREATE_SOURCE_REVISION_TRACKER_TARGET = 
src-create-source-revision-tracker

+
 endif


+
+
+$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
+
+
+
I would suggest using the variables directly on the all: line instead of 
declaring more phony targets.

+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
+
 all: store-source-revision create-source-revision-tracker


 FRC: # Force target

Do you really need the separate variables? Since both of them are built 
by all anyway, I would just have one variable TARGETS to which you add 
everything you wish to build and finish with "all: $(TARGETS)".


/Erik

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 18, 2018, at 3:28 PM, Christian Thalinger  
> wrote:
> 
> 
> 
>> On Jul 18, 2018, at 1:46 PM, Erik Joelsson  wrote:
>> 
>> Hello Christian,
>> 
>> Sometimes we need hooks both close to the beginning and close to the end of 
>> the file, and in that case we create a SourceBundle-post.gmk. The 
>> recommended position of the post inclusion is right before the typical "all: 
>> $(TARGETS)" declaration. This file has the all target depend explicitly on a 
>> list of phony targets and no TARGETS variable, so I would recommend changing 
>> that to building a TARGETS variable like we usually do. That way you can 
>> create a SourceBundle-post.gmk and clear the TARGETS variable from any 
>> targets you don't want to run from the open file. Does that sound ok?
> 
> Yes, that would be great.  In JDK 11, please :-)

Ok, this is the only way I could make it work:

diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
index 10dd943..13ea407 100644
--- a/make/SourceRevision.gmk
+++ b/make/SourceRevision.gmk
@@ -28,7 +28,7 @@ default: all
 include $(SPEC)
 include MakeBase.gmk
 
-$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
+$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
 
 

 # Keep track of what source revision is used to create the build, by creating
@@ -94,11 +94,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
 
   $(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
 
-  store-source-revision: $(STORED_SOURCE_REVISION)
+  hg-store-source-revision: $(STORED_SOURCE_REVISION)
 
   $(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
 
-  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+
+  STORE_SOURCE_REVISION_TARGET = hg-store-source-revision
+  CREATE_SOURCE_REVISION_TRACKER_TARGET = hg-create-source-revision-tracker
 
 else
   # Not using HG
@@ -106,26 +109,39 @@ else
   ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
 # We have a stored source revision (.src-rev)
 
-store-source-revision:
+src-store-source-revision:
$(call LogInfo, No mercurial configuration present$(COMMA) not updating 
.src-rev)
 
 $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
$(install-file)
 
-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
   else
 # We don't have a stored source revision. Can't do anything, really.
 
-store-source-revision:
+src-store-source-revision:
$(call LogWarn, Error: No mercurial configuration present$(COMMA) 
cannot create .src-rev)
exit 2
 
-create-source-revision-tracker:
+src-create-source-revision-tracker:
$(call LogWarn, Warning: No mercurial configuration present and no 
.src-rev)
   endif
 
+  STORE_SOURCE_REVISION_TARGET = src-store-source-revision
+  CREATE_SOURCE_REVISION_TRACKER_TARGET = src-create-source-revision-tracker
+
 endif
 
+
+
+$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
+
+
+
+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
+
 all: store-source-revision create-source-revision-tracker
 
 FRC: # Force target

Re: adding additional numbers to the Java version string

[Tony Printezis]

Hi Erik,

Thanks for the response. I created:

https://bugs.openjdk.java.net/browse/JDK-8207849

(infrastructure/build is the right component for this, right?)

and I’ll post a webrev soon.

Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On July 19, 2018 at 9:53:42 AM, Erik Joelsson (erik.joels...@oracle.com)
wrote:

Since JEP 223 specifies an arbitrary length (something I had missed
before), I agree the build should support a few extra version numbers.

/Erik


On 2018-07-18 13:22, Tony Printezis wrote:
> Hi all,
>
> According to the Java version string spec (JEPs 223 and 322) the first
part
> of the version string is a sequence of numbers separated by periods. The
> sequence can be of arbitrary length. However, in the OpenJDK configure
> scripts, the sequence length is fixed to exactly four numbers.
>
> For our internal builds we’d like to add at least one additional number
to
> the version string. Is there any interest in a change to the scripts to
> allow that?
>
> I’ve prototyped this in a generic way (can add up to 3 additional
numbers,
> called “extra1”, “extra2”, and “extra3”). These are set by passing
> --with-version-extra(1|2|3)=… to configure. If they are not set, the
> version string is of course exactly the same as it was before. I also
> changed the way the value of --with-version-string=… is parsed to be able
> to also extract the additional three numbers, if present.
>
> Would this be generally helpful?
>
> Tony
>
> —
> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com

Re: adding additional numbers to the Java version string

[Erik Joelsson]

Since JEP 223 specifies an arbitrary length (something I had missed 
before), I agree the build should support a few extra version numbers.


/Erik


On 2018-07-18 13:22, Tony Printezis wrote:

Hi all,

According to the Java version string spec (JEPs 223 and 322) the first part
of the version string is a sequence of numbers separated by periods. The
sequence can be of arbitrary length. However, in the OpenJDK configure
scripts, the sequence length is fixed to exactly four numbers.

For our internal builds we’d like to add at least one additional number to
the version string. Is there any interest in a change to the scripts to
allow that?

I’ve prototyped this in a generic way (can add up to 3 additional numbers,
called “extra1”, “extra2”, and “extra3”). These are set by passing
--with-version-extra(1|2|3)=… to configure. If they are not set, the
version string is of course exactly the same as it was before. I also
changed the way the value of --with-version-string=… is parsed to be able
to also extract the additional three numbers, if present.

Would this be generally helpful?

Tony

—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com

Re: [8u] RFR 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped]

[Severin Gehwolf]

Hi Erik,

On Wed, 2018-07-18 at 18:10 +0200, Severin Gehwolf wrote:
> webrev with info line removed:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/webrev.03/
> 
> HG-export:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/JDK-8036003.jdk8.export.patch
> 
> Could you please sponsor this change once [I] gets approved? I'd then
> close JDK-8207234 as a duplicate of the 8036003 8u-backport bug.

Rob approved the enhancement backport request[a] and the actual
backport request[b]. Could you please sponsor this patch as it needs to
include generated-configure as well which needs to be done by an Oracle
sponsor, AFAIK?

Thanks,
Severin

[a] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007697.html
[b] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007698.html

> Thanks,
> Severin
> 
> [I] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007670.html
> 
> > /Erik
> > 
> > 
> > On 2018-07-18 06:42, Severin Gehwolf wrote:
> > > Hi Erik,
> > > 
> > > Latest webrev with default param over changes in the jdk tree:
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/webrev.0
> > > 2/
> > > 
> > > Thanks,
> > > Severin
> > > 
> > > 
> > > On Tue, 2018-07-17 at 09:16 -0700, Erik Joelsson wrote:
> > > > That should work, but if it doesn't, please try double dollar
> > > > on
> > > > $(STRIP_POLICY). Then it gets evaluated when the macro is
> > > > called instead
> > > > of when it is defined.
> > > > 
> > > > /Erik
> > > > 
> > > > 
> > > > On 2018-07-17 09:01, Severin Gehwolf wrote:
> > > > > Hi Erik,
> > > > > 
> > > > > On Tue, 2018-07-17 at 07:24 -0700, Erik Joelsson wrote:
> > > > > > Good work backporting the proper fix!
> > > > > 
> > > > > Thanks for the review!
> > > > > 
> > > > > > I think it would be good if you could make $1_STRIP_POLICY
> > > > > > default to
> > > > > > $(STRIP_POLICY) in SetupNativeCompilation instead of
> > > > > > setting it as
> > > > > > parameter basically everywhere. That shouldn't change the
> > > > > > default
> > > > > > behavior anywhere I think?
> > > > > 
> > > > > How would I do that? No values from spec.gmk seem to be
> > > > > available in
> > > > > SetupNativeCompilation. For example, this doesn't work (with
> > > > > the params
> > > > > passed in in the jdk repo reverted):
> > > > > 
> > > > > diff --git a/make/common/NativeCompilation.gmk
> > > > > b/make/common/NativeCompilation.gmk
> > > > > --- a/make/common/NativeCompilation.gmk
> > > > > +++ b/make/common/NativeCompilation.gmk
> > > > > @@ -260,6 +260,10 @@
> > > > >$1_CC:=$(CC)
> > > > >  endif
> > > > >
> > > > > +  ifeq ($$($1_STRIP_POLICY),)
> > > > > +$1_STRIP_POLICY:=$(STRIP_POLICY)
> > > > > +  endif
> > > > > +
> > > > >  # Make sure the dirs exist.
> > > > >  $$(eval $$(call MakeDir,$$($1_OBJECT_DIR)
> > > > > $$($1_OUTPUT_DIR)))
> > > > >  $$(foreach d,$$($1_SRC), $$(if $$(wildcard
> > > > > $$d),,$$(error SRC specified to SetupNativeCompilation $1
> > > > > contains missing directory $$d)))
> > > > > 
> > > > > Thanks,
> > > > > Severin
> > > > > 
> > > > > > On 2018-07-17 05:54, Severin Gehwolf wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > This work started as a patch for JDK-8207234[1], but
> > > > > > > turned out to
> > > > > > > become a 8-backport of JDK-8036003[2] using the old build
> > > > > > > logic and
> > > > > > > with backwards-compatibilty. We are facing an issue where
> > > > > > > .gnu_debuglink sections get generated unconditionally on
> > > > > > > the various
> > > > > > > JDK libs (serviceability, security, nio, awt, etc.).
> > > > > > > That's an issue,
> > > > > > > since for our distro builds the stripping happens outside
> > > > > > > the OpenJDK
> > > > > > > build post-factum. The result of adding debug links
> > > > > > > unconditionally is
> > > > > > > that our binaries would have two links, one pointing to a
> > > > > > > file which
> > > > > > > doesn't exist.
> > > > > > > 
> > > > > > > What's more, there is no real support for the kind of
> > > > > > > debug-info build
> > > > > > > we need as downstream distribution consumers: Have all
> > > > > > > debug symbols
> > > > > > > present, but leave them in the binary/library itself
> > > > > > > without any
> > > > > > > stripping. That's basically what JDK 11's --with-native-
> > > > > > > debug-
> > > > > > > symbols=internal does. This patch ports that configure
> > > > > > > flag to JDK 8u
> > > > > > > and keeps backward-compatibility with --disable-debug-
> > > > > > > symbols and --
> > > > > > > disable-zip-debug-info flags. More info on this in [1].
> > > > > > > 
> > > > > > > Bug(s): https://bugs.openjdk.java.net/browse/JDK-8207234
> > > > > > >https://bugs.openjdk.java.net/browse/JDK-80360
> > > > > > > 03
> > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > > > > > > 8207234/01/
> > > > > > > 
> > > > > > > Testing:
> > > > > > > 
> > > > > > > Tested all build configs