Re: [8u60] RFR: 8038189: Add cross-platform compact profiles support

[David Holmes]

Updated webrev:

http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/

Only changes are to profile-includes.txt.

Thanks,
David

On 2/12/2014 2:24 PM, David Holmes wrote:

Erik,

Many thanks for the makefile macro wizardry! I will incorporate, test
and return with an updated webreb.

David

On 1/12/2014 7:19 PM, Erik Joelsson wrote:

Hello David,

Most of it looks good, but profile-includes.txt could certainly benefit
from some reduction in duplication. (Aside from the extension of the
file itself, which I find a bit weird, but it's already there.) The two
common structures that I can see are:
1. Expanding debuginfo files for macosx.
2. Assigning/expanding libraries to the correct variable.

For macosx debuginfo expanding, I would define a macro to something like
this:

# Expand the contents of the .dSYM directories on macosx.
# Param 1 - debug files list
# Param 2 - libraries list
define expand-debuginfo
   $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter
macosx, $(OPENJDK_TARGET_OS))), \
   $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \
   $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i,
$(filter $i.%, $1))), \
   $1)
endef

And use it like this:

PROFILE_1_DEBUG_FILES := $(call expand-debuginfo,
$(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES))

Filtering out jsig can be done on the parameters at the macro call.

For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would
do something like:

ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx))
   LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/
else
   LIB_SUBDIR :=
endif

And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix
$(LIB_SUBDIR), ...). The conditional on Windows for assigning to
...BIN_FILES or ...LIB_FILES I would leave in place since I don't think
a macro solution would make it easier to understand.

/Erik


On 2014-12-01 01:09, David Holmes wrote:

Main bug is 8038189 but that is a closed bug, the open backport issue
is:

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

Compact Profiles support was added in 8, but only for the Linux
platform. I've now generalized this support to all the other
platforms. This is an 8u only change, targetting 8u60, as soon as the
jdk8u/dev starts accepting things for 8u60.

The changes are not that extensive - mostly generalizing the lists and
accounting for different platforms putting files into different places
(jre/lib/ vs jre/lib vs jre/bin). It isn't necessary to produce
detailed per-platform lists as files that don't exist simply don't get
copied; but when files are obviously platform specific then I add them
under suitable guards.

The biggest complexity comes from the debuginfo files, and in
particular unzipped debuginfo files. This accounts for the bulk of the
changes in profiles-includes.txt, as we try to identify the set of
debug files that might exist for each library (and OSX is the main
complication due to the .dSYM directory because the existing rules
only copy files not directories). Suggestions for reducing the
duplicated patterns would be appreciated.

Platform specific contents were determined in conjunction with
examination of what Jigsaw is using in JDK 9 for the base module.

I tested all the main platforms (Windows, Linux, Solaris and OSX) and
with/without zipping of debuginfo files. Note that Windows builds will
not work with unzipped debuginfo files due to 8025936, but I checked
that multiple debug info files were expanded into the right set of
targets.

webrevs:

http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/

make/Main.gmk:
 - Remove the os-check that constrained profiles to linux

http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/

make/CreateJars.gmk:
 - Check for empty variables (Solaris doesn't like them)
 - Fix # # comments
 - Add explicit targets for the beanless classes with $ in them (the %
substitution doesn't work on all platforms when $ is also present)

make/Images.gmk
 - Don't filter out server VM from compact profiles

make/Import.gmk
 - Add Info.plist to the exported files (for unzipped debuginfo files
- this is a general fix not profiles specific so may warrant its own CR)

make/Profiles.gmk
 - Remove linux-only comment

make/Tools.gmk
 - Fix tool definitions to use $(PATH_SEP) and quote cp entries

make/profile-includes.txt
 - Bulk of changes as described above

make/profile-rtjar-includes.txt
 - Additional packages that exist on OSX only (but don't need to be
conditionally added)
 - NOTE: if AIX or other platform add platform specific packages not
already included by an enclosing package, then they will also need to
be added

Thanks,
David

RE: Confirming JDK 8 GA version

[Medi Montaseri]

Thanks David and Erik,

A bit more confused...I don't know what hotspot is.

I am aware of configure --with-build-number and --with-milestone and indeed use 
themand that is why I get

bin/java -version
openjdk version "1.8.0-20141202"// note how this version is stamped 
with a date
OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701) // note 
how this portion is also decorated with date, label and more numbers
OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode)
  /// what is 
this b70

The b70 makes me think that I am not working with the tip 

Let me ask the question another way...

If I pull the latest and "hg tags" says b132 as in 

>> unix> cd srcDir/jdk ; hg tags | head -2
>>tip 9107:687fd7c7986d
>>jdk8-b132   9106:43cb25339b55
>>

Can I then be sure that I am indeed working with the tip...?

David...you see how yours is showing the b132 

> java version "1.8.0"
> Java(TM) SE Runtime Environment (build 1.8.0-b132)   // look there is the 
> b132 thing  -b132
> Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode)
>

Again, I need to make sure I have the latest and be able to query some binary 
(java or javac) to show that it is the latest.

Thanks
Medi


From: Erik Joelsson [erik.joels...@oracle.com]
Sent: Wednesday, December 03, 2014 12:33 AM
To: David Holmes; Medi Montaseri; build-dev@openjdk.java.net
Subject: Re: Confirming JDK 8 GA version

The source/makefiles are not aware of the build number. It's assigned
from an external source at the time of building a promoted build. If you
want your version number to better match 8 GA, you will have to play
around with the configure arguments --with-build-number and possibly
--with-milestone.

Also, as David pointed out, in JDK 8, hotspot has it's own numbering.

/Erik

On 2014-12-03 06:13, David Holmes wrote:
> On 3/12/2014 12:25 PM, Medi Montaseri wrote:
>> Hi,
>>
>> Just wanted to confirm some issues:
>> I am interested in building the latest (tip) of jdk8 GA release.
>>
>> 1- jdk8 GA is different from jdk8u (u is for updates), I should get
>> the src from http://hg.openjdk.java.net/jdk8/jdk8
>> 2- The latest tagged version of the src is
>> "jdk8-b132   9106:43cb25339b55"
>> 3- I confirm that I have the latest src (for GA) by running "hg tags"
>> like
>> unix> cd srcDir/jdk ; hg tags | head -2
>>tip 9107:687fd7c7986d
>>jdk8-b132   9106:43cb25339b55
>>
>> I go ahead and build everything and then run "java -version" and I see
>>
>> openjdk version "1.8.0-20141202"
>> OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701)
>> OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode)
>>
>> Q- Why am I seeing "build 25.0-b70" ? Does this "b70" has anything to
>> do with above "jdk8-b132" ?
>
> That is the hotspot version number and build number as used in the GA
> build of JDK 8. It is correct.
>
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build 1.8.0-b132)
> Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode)
>
> David
> -
>
>> Thanks
>> Medi
>>

Re: build warnings

[Dave Pointon]

Amen to that Magnus - what possible motive can there be to fix invisible,
benign 'problems' ?

--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 3 December 2014 at 17:42, Kelly O'Hair  wrote:

>
> On Dec 3, 2014, at 3:09 AM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
> > On 2014-12-02 22:59, Jonathan Gibbons wrote:
> >> Build folk,
> >>
> >> The build has always generated warnings (sigh!) but right now, the
> warnings look scarier than usual.
> >>
> >> In particular, when the build terminates, I get a couple of screenfuls
> of messages like this:
> >>
> >>
> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:
> In function ‘SplashScreenThread’:
> >>
> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9:
> warning: ignoring return value of ‘pipe’, declared with attribute
> warn_unused_result [-Wunused-result]
> >> pipe(splash->controlpipe);
> >> ^
> >>
> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:
> In function ‘initFormat’:
> >>
> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34:
> warning: ‘numBits’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> >> format->shift[i] = shift + numBits - i * 8 - 8;
> >>  ^
> >>
> >> What would it take to have some sort of campaign to reduce build
> warnings like these?  We've made good progress on lint and doclint warnings
> for Java code and doc comments; what does it take to start on native code
> warnings?
> >
> > Actually, I've already started on such a campain. ;-)
> >
> > I believe the way to go is:
> > 1) disable all (or more or less all) of the current flood of warnings
> > 2) open bugs for all disabled warnings on the corresponding components,
> indicating that the owner of the component should:
> > a) fix the issue with the source code and re-enable the warning, or
> > b) come up with a good reason why the warning is bad/broken and should
> be left disabled for that component.
> >
> > I have started on 1). I have a local forest which disables most of the
> warnings for linux builds. I'm about to move on to the other platforms as
> well, but other work came between.
> >
> > /Magnus
>
> Speaking from a bit of experience, if you disable the warnings, odds are
> good that they will never get fixed because being disabled will be
> considered by some as "we have no warnings" and they will work on other
> things, like adding more code with more invisible disabled warnings.
> Granted some of the C/C++ compiler warnings are very dubious and of little
> value, but many are not. Disabling the less valuable warnings makes sense,
> but I would caution on disabling all warnings. Just my 2 cents...
>
> -kto
>
>
>

Re: RFR [JEP 220] Modular Run-Time Images - fix zero build

[Dave Pointon]

Yep ,

I like that even more, Erik :-)

--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 3 December 2014 at 17:46, Erik Joelsson  wrote:

>  Yes, it can be modified. My preferred variant for file existence checking
> in make is "ifneq ($(wildcard /path/to/file), )". Also, in
> Gensrc-jdk.jdi.gmk, I would probably like some other logical condition to
> check on than sa-jdi.jar. We will address this at some point soon.
>
> /Erik
>
> On 2014-12-03 15:47, Dave Pointon wrote:
>
>  Hmmm ,
>
>  Would it not be possible to modify Xerxes' suggested patch to do
> something along the lines of ...
>
> # sa-jdi.jar do not exist for Itanium and zero
> ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N;
> fi),N)
>   SA_TARGETS += \
> $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \
> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services
>  endif
>
>  Just a thought
>
>  --
> Dave Pointon FIAP MBCS -
> ​ contractor engaged by IBM​
>
>
> Now I saw, tho' too late, the folly of beginning a work before we count
> the cost and before we we judge rightly of our strength to go thro' with it
> - Robinson Crusoe
>
> On 3 December 2014 at 14:30, Erik Joelsson 
> wrote:
>
>> Hello Xerxes,
>>
>> Thanks for the suggestion. I have created
>> https://bugs.openjdk.java.net/browse/JDK-8066589 to track this issue.
>> Unfortunately we won't have time to fix it before pushing JEP 220 to jdk9.
>> I hope this won't inconvenience you too much.
>>
>> Your suggested patch does correctly highlight the problem areas, but will
>> not work since gnu make does not accept shell logic outside of recipes or
>> $(shell ...) constructs.
>>
>> /Erik
>>
>> ​ ​
>>
>
>
>

Re: RFR [JEP 220] Modular Run-Time Images - fix zero build

[Erik Joelsson]

Yes, it can be modified. My preferred variant for file existence 
checking in make is "ifneq ($(wildcard /path/to/file), )". Also, in 
Gensrc-jdk.jdi.gmk, I would probably like some other logical condition 
to check on than sa-jdi.jar. We will address this at some point soon.


/Erik

On 2014-12-03 15:47, Dave Pointon wrote:

Hmmm ,

Would it not be possible to modify Xerxes' suggested patch to do 
something along the lines of ...


# sa-jdi.jar do not exist for Itanium and zero
ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; 
fi),N)

  SA_TARGETS += \
$(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa 
.services

endif

Just a thought

--
Dave Pointon FIAP MBCS -
​ contractor engaged by IBM​


Now I saw, tho' too late, the folly of beginning a work before we 
count the cost and before we we judge rightly of our strength to go 
thro' with it - Robinson Crusoe


On 3 December 2014 at 14:30, Erik Joelsson > wrote:


Hello Xerxes,

Thanks for the suggestion. I have created
https://bugs.openjdk.java.net/browse/JDK-8066589 to track this
issue. Unfortunately we won't have time to fix it before pushing
JEP 220 to jdk9. I hope this won't inconvenience you too much.

Your suggested patch does correctly highlight the problem areas,
but will not work since gnu make does not accept shell logic
outside of recipes or $(shell ...) constructs.

/Erik

​ ​

Re: build warnings

[Kelly O'Hair]

On Dec 3, 2014, at 3:09 AM, Magnus Ihse Bursie  
wrote:

> On 2014-12-02 22:59, Jonathan Gibbons wrote:
>> Build folk,
>> 
>> The build has always generated warnings (sigh!) but right now, the warnings 
>> look scarier than usual.
>> 
>> In particular, when the build terminates, I get a couple of screenfuls of 
>> messages like this:
>> 
>> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:
>>  In function ‘SplashScreenThread’:
>> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9:
>>  warning: ignoring return value of ‘pipe’, declared with attribute 
>> warn_unused_result [-Wunused-result]
>> pipe(splash->controlpipe);
>> ^
>> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:
>>  In function ‘initFormat’:
>> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34:
>>  warning: ‘numBits’ may be used uninitialized in this function 
>> [-Wmaybe-uninitialized]
>> format->shift[i] = shift + numBits - i * 8 - 8;
>>  ^
>> 
>> What would it take to have some sort of campaign to reduce build warnings 
>> like these?  We've made good progress on lint and doclint warnings for Java 
>> code and doc comments; what does it take to start on native code warnings?
> 
> Actually, I've already started on such a campain. ;-)
> 
> I believe the way to go is:
> 1) disable all (or more or less all) of the current flood of warnings
> 2) open bugs for all disabled warnings on the corresponding components, 
> indicating that the owner of the component should:
> a) fix the issue with the source code and re-enable the warning, or
> b) come up with a good reason why the warning is bad/broken and should be 
> left disabled for that component.
> 
> I have started on 1). I have a local forest which disables most of the 
> warnings for linux builds. I'm about to move on to the other platforms as 
> well, but other work came between.
> 
> /Magnus

Speaking from a bit of experience, if you disable the warnings, odds are good 
that they will never get fixed because being disabled will be considered by 
some as "we have no warnings" and they will work on other things, like adding 
more code with more invisible disabled warnings. Granted some of the C/C++ 
compiler warnings are very dubious and of little value, but many are not. 
Disabling the less valuable warnings makes sense, but I would caution on 
disabling all warnings. Just my 2 cents...

-kto

Re: build warnings

[Jonathan Gibbons]

On 12/03/2014 03:09 AM, Magnus Ihse Bursie wrote:

On 2014-12-02 22:59, Jonathan Gibbons wrote:

Build folk,

The build has always generated warnings (sigh!) but right now, the 
warnings look scarier than usual.


In particular, when the build terminates, I get a couple of 
screenfuls of messages like this:


/w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: 
In function ‘SplashScreenThread’:
/w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: 
warning: ignoring return value of ‘pipe’, declared with attribute 
warn_unused_result [-Wunused-result]

 pipe(splash->controlpipe);
 ^
/w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: 
In function ‘initFormat’:
/w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: 
warning: ‘numBits’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]

 format->shift[i] = shift + numBits - i * 8 - 8;
  ^

What would it take to have some sort of campaign to reduce build 
warnings like these?  We've made good progress on lint and doclint 
warnings for Java code and doc comments; what does it take to start 
on native code warnings?


Actually, I've already started on such a campain. ;-)

I believe the way to go is:
1) disable all (or more or less all) of the current flood of warnings
2) open bugs for all disabled warnings on the corresponding 
components, indicating that the owner of the component should:

a) fix the issue with the source code and re-enable the warning, or
b) come up with a good reason why the warning is bad/broken and should 
be left disabled for that component.


I have started on 1). I have a local forest which disables most of the 
warnings for linux builds. I'm about to move on to the other platforms 
as well, but other work came between.


/Magnus


Magnus,

Thank you for the update; it's great to hear this is being looked at.

-- Jon

Re: build warnings

[Alan Bateman]

On 03/12/2014 07:58, Staffan Larsen wrote:

These are warnings in the java.desktop module. I don’t know what the 
appropriate email list is for java.desktop discussions, but perhaps bringing it 
up there would be the right thing to do?

Most of the warnings that I see are in the AWT and 2D code and so 
awt-dev and 2d-dev would be the mailing lists to bring patches for review.


-Alan

Re: RFR [JEP 220] Modular Run-Time Images - fix zero build

[Dave Pointon]

Hmmm ,

Would it not be possible to modify Xerxes' suggested patch to do something
along the lines of ...

# sa-jdi.jar do not exist for Itanium and zero
ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; fi),N)
  SA_TARGETS += \
$(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services
endif

Just a thought

--
Dave Pointon FIAP MBCS -
​ contractor engaged by IBM​


Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 3 December 2014 at 14:30, Erik Joelsson  wrote:

> Hello Xerxes,
>
> Thanks for the suggestion. I have created https://bugs.openjdk.java.net/
> browse/JDK-8066589 to track this issue. Unfortunately we won't have time
> to fix it before pushing JEP 220 to jdk9. I hope this won't inconvenience
> you too much.
>
> Your suggested patch does correctly highlight the problem areas, but will
> not work since gnu make does not accept shell logic outside of recipes or
> $(shell ...) constructs.
>
> /Erik
>
> ​​
>

Re: RFR [JEP 220] Modular Run-Time Images - fix zero build

[Erik Joelsson]

Hello Xerxes,

Thanks for the suggestion. I have created 
https://bugs.openjdk.java.net/browse/JDK-8066589 to track this issue. 
Unfortunately we won't have time to fix it before pushing JEP 220 to 
jdk9. I hope this won't inconvenience you too much.


Your suggested patch does correctly highlight the problem areas, but 
will not work since gnu make does not accept shell logic outside of 
recipes or $(shell ...) constructs.


/Erik

On 2014-12-03 14:37, Xerxes Rånby wrote:

Hi Chris!

The build changes introduced a new dependency that sa-jdi.jar is 
always built.


The sa-jdi.jar do not get built  for Zero and Itanium builds.
Zero is built using the --with-jvm-interpreter=cpp 
--with-jvm-variants=zero configure options.


The sa-jdi.jar also do not exist if you use the --with-import-hotspot= 
to import alternative OpenJDK JVM such as

a pre-compiled CACAO JVM or JamVM libjvm.so .

I would suggest to change the jdk/make/Import.gmk and 
jdk/make/gensrc/Gensrc-jdk.jdi.gmk to first check if sa-jdi.jar
exist before adding it to the SA_TARGETS and GENSRC_JDK_JDI something 
like this:


Index: openjdk-jdk9-b38/jdk/make/Import.gmk
===
--- openjdk-jdk9-b38.orig/jdk/make/Import.gmk   2014-11-17 
17:34:13.830175424 +0100
+++ openjdk-jdk9-b38/jdk/make/Import.gmk2014-11-18 
09:10:25.420715300 +0100

@@ -221,6 +221,8 @@
 # even if zip is already unpacked.
 $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services: 
$(HOTSPOT_DIST)/lib/sa-jdi.jar


+# sa-jdi.jar do not exist for Itanium and zero
+if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \
 SA_TARGETS += 
$(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \

$(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services

Index: openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk
===
--- openjdk-jdk9-b38.orig/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 
2014-11-18 08:57:26.504852865 +0100
+++ openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 2014-11-18 
09:10:43.348804201 +0100

@@ -78,12 +78,10 @@
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector
$(install-file)

+# sa-jdi.jar do not exist for Itanium and zero
+if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \
 GENSRC_JDK_JDI += 
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector 
\

$(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector


Cheers
Xerxes




From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev 
, build-dev , 
Alan Bateman , Alex Buckley 
, Chris Hegarty , 
Erik Joelsson , Jonathan Gibbons 
, Karen Kinnear 
, "Jim Laskey (Oracle)" 
, Magnus Ihse Bursie 
, Mandy Chung 
, Mark Reinhold , 
Paul Sandoz , "A. Sundararajan" 



This is a review request for the changes for JEP 220: Modular 
Run-Time Images [1].


There are a number of individuals responsible for these changes. 
Some, possibly not all, are explicitly listed in the 'To' section of 
this mail, and they will help address any comments arising from this 
review request.


The new run-time image structure is defined in JEP 220 [1], and can 
be seen as a result of building the staging forest [2], or in the 
early access builds [3].


Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion 
has been tentatively reserved for their integration. All comments 
are welcome, although given the nature of the changes then we might 
have to create separate issues in JIRA to address some of them later 
in jdk9/dev.


-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea

Re: build warnings

[Magnus Ihse Bursie]

On 2014-12-02 22:59, Jonathan Gibbons wrote:

Build folk,

The build has always generated warnings (sigh!) but right now, the 
warnings look scarier than usual.


In particular, when the build terminates, I get a couple of screenfuls 
of messages like this:


/w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: 
In function ‘SplashScreenThread’:
/w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: 
warning: ignoring return value of ‘pipe’, declared with attribute 
warn_unused_result [-Wunused-result]

 pipe(splash->controlpipe);
 ^
/w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: 
In function ‘initFormat’:
/w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: 
warning: ‘numBits’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]

 format->shift[i] = shift + numBits - i * 8 - 8;
  ^

What would it take to have some sort of campaign to reduce build 
warnings like these?  We've made good progress on lint and doclint 
warnings for Java code and doc comments; what does it take to start on 
native code warnings?


Actually, I've already started on such a campain. ;-)

I believe the way to go is:
1) disable all (or more or less all) of the current flood of warnings
2) open bugs for all disabled warnings on the corresponding components, 
indicating that the owner of the component should:

a) fix the issue with the source code and re-enable the warning, or
b) come up with a good reason why the warning is bad/broken and should 
be left disabled for that component.


I have started on 1). I have a local forest which disables most of the 
warnings for linux builds. I'm about to move on to the other platforms 
as well, but other work came between.


/Magnus

Re: Adding Microbenchmarks to the JDK forest/trees (JEP-230)

[Magnus Ihse Bursie]

On 2014-12-02 23:45, Christian Thalinger wrote:

On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons  
wrote:

Staffan,

That seems to put it on the low end for reasonably being its own repo, if you 
wanted that, at least, as indicated by the numbers.

Do we really want more repositories?
As long as the number of repositories are around a dozen, one more or 
less does not really matter. But our model will probably not scale well 
with hundreds of repos (e.g. if someone would suggest that every module 
should reside in a separate repo).


My suggestion is that the microbenchmarks are put in the top-level repo, 
if only for the reason that it seems fully possible to split them out to 
a separate repo some time in the future if it grows too much, but it 
seems much more unlikely that it will ever be moved back into the 
top-level repo if we realized it was a stupid idea to put it in a 
separate repo.


/Magnus

Re: Confirming JDK 8 GA version

[Erik Joelsson]

The source/makefiles are not aware of the build number. It's assigned 
from an external source at the time of building a promoted build. If you 
want your version number to better match 8 GA, you will have to play 
around with the configure arguments --with-build-number and possibly 
--with-milestone.


Also, as David pointed out, in JDK 8, hotspot has it's own numbering.

/Erik

On 2014-12-03 06:13, David Holmes wrote:

On 3/12/2014 12:25 PM, Medi Montaseri wrote:

Hi,

Just wanted to confirm some issues:
I am interested in building the latest (tip) of jdk8 GA release.

1- jdk8 GA is different from jdk8u (u is for updates), I should get 
the src from http://hg.openjdk.java.net/jdk8/jdk8
2- The latest tagged version of the src is 
"jdk8-b132   9106:43cb25339b55"
3- I confirm that I have the latest src (for GA) by running "hg tags" 
like

unix> cd srcDir/jdk ; hg tags | head -2
   tip 9107:687fd7c7986d
   jdk8-b132   9106:43cb25339b55

I go ahead and build everything and then run "java -version" and I see

openjdk version "1.8.0-20141202"
OpenJDK Runtime Environment (build 1.8.0-20141202-HDS-174701)
OpenJDK 64-Bit Server VM (build 25.0-b70, mixed mode)

Q- Why am I seeing "build 25.0-b70" ? Does this "b70" has anything to 
do with above "jdk8-b132" ?


That is the hotspot version number and build number as used in the GA 
build of JDK 8. It is correct.


java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode)

David
-


Thanks
Medi

Re: build warnings

[Staffan Larsen]

These are warnings in the java.desktop module. I don’t know what the 
appropriate email list is for java.desktop discussions, but perhaps bringing it 
up there would be the right thing to do?

/Staffan

> On 2 dec 2014, at 22:59, Jonathan Gibbons  wrote:
> 
> Build folk,
> 
> The build has always generated warnings (sigh!) but right now, the warnings 
> look scarier than usual.
> 
> In particular, when the build terminates, I get a couple of screenfuls of 
> messages like this:
> 
> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:
>  In function ‘SplashScreenThread’:
> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9:
>  warning: ignoring return value of ‘pipe’, declared with attribute 
> warn_unused_result [-Wunused-result]
> pipe(splash->controlpipe);
> ^
> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:
>  In function ‘initFormat’:
> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34:
>  warning: ‘numBits’ may be used uninitialized in this function 
> [-Wmaybe-uninitialized]
> format->shift[i] = shift + numBits - i * 8 - 8;
>  ^
> 
> What would it take to have some sort of campaign to reduce build warnings 
> like these?  We've made good progress on lint and doclint warnings for Java 
> code and doc comments; what does it take to start on native code warnings?
> 
> -- Jon