Re: RFR: JDK-8191856 "make clean-test" does not work properly

[Magnus Ihse Bursie]

On 2017-11-25 00:19, Martin Buchholz wrote:

Should all phony targets be listed in a .PHONY line?
Yes, that's our policy. We do that using the ALL_TARGETS variable, which 
has a

.PHONY: $(ALL_TARGETS)
rule at the end.

Things can break subtly if you don't have phony targets declared as such.

/Magnus



On Fri, Nov 24, 2017 at 2:45 AM, Magnus Ihse Bursie 
mailto:magnus.ihse.bur...@oracle.com>> 
wrote:


With the new layout of make run-test, the test-results and
test-support directories are not removed by "make clean-test", and
not even "make clean".

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

Patch inline:
diff --git a/make/Main.gmk b/make/Main.gmk
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -1049,7 +1049,7 @@
 # file.

 CLEAN_DIRS += hotspot jdk bootcycle-build test buildtools support \
-    images make-support test-make bundles buildjdk
+    images make-support test-make bundles buildjdk test-results
test-support
 CLEAN_DIR_TARGETS := $(addprefix clean-, $(CLEAN_DIRS))
 CLEAN_SUPPORT_DIRS += demos
 CLEAN_SUPPORT_DIR_TARGETS := $(addprefix clean-,
$(CLEAN_SUPPORT_DIRS))
@@ -1094,6 +1094,8 @@
 # while classes and touch files end up in jdk.
 clean-support: clean-jdk

+clean-test: clean-test-results clean-test-support
+
 # Remove everything, including configure configuration. If the output
 # directory was created by configure and now becomes empty,
remove it as well.
 dist-clean: clean

/Magnus

RE: Building OpenJDK9 on MSYS2

[Peter Budai]

MSYS2 or Cygwin should be similar from the technical point of view IMHO. I’m 
familiar with MSYS2, but not with Cygwin.

The big change as you called out is to make sure that gcc toolchain can build 
successfully also for a Windows platform and produce a properly working 
binaries.

BTW I don’t belie there are big performance differences whether you are 
building with GCC or MSC

Once again, please advise on what is the best way to move forward, or stop this 
effort.

Peter


From: Thomas Stüfe 
Sent: Thursday, November 23, 2017 10:36:07 PM
To: Lussier, Denis
Cc: Jonathan Gibbons; build-dev@openjdk.java.net; Peter Budai
Subject: Re: Building OpenJDK9 on MSYS2



On Thu, Nov 23, 2017 at 12:40 AM, Lussier, Denis 
mailto:den...@bigsql.com>> wrote:
This is good stuff.  Back in 2010 I got OpenJDK compiled and running on the
Microsoft Toolchain.   I never ran the jtreg tests, but, the binaries
worked for running basic Tomcat but definitely not for trying to run
Eclipse.

These days I am a pretty big fan of MSYS2.  In my personal experiences with
building a PostgreSQL Windoze distribution, the MSYS2 binaries run a little
faster than using the old MS Toolchain.

https://www.openscg.com/2016/02/building-postgresql-on-windows-for-performance/


Well, the linked article does claim the msys2 toolchain to be faster than the 
Visual Studio, but there are no information I can see which compiler and linker 
options were used. Without this information, the article is difficult to take 
seriously.

While I really respect these efforts, I regret seeing the fragmentation in 
windows build environments. I rather have one well kept build environment than 
of multiple buggy ones - and we have not that many folks interested in the 
windows port in the first place (it always feels like second place to the Posix 
platforms to me). The official build environment of the openjdk windows port is 
Cygwin + Visual Studio. Even if we think the gcc toolchain would be an 
attractive alternative to VS - why not just use the cygwin gcc instead? That 
way we would at least share the same posix layer.

Just my 5c.

Kind Regards, Thomas


--Luss


On Wed, Nov 22, 2017 at 4:28 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:

> Peter,
>
> With over 120 :tier1 test failures, it would be worth understanding the
> test failures as part of moving forward. There should normally be no :tier1
> test failures.
>
> -- Jon
>
>
>
>
> On 11/22/2017 01:10 PM, Peter Budai wrote:
>
>> Let me give an update on the current status:
>>
>>*   I have managed to build both the 64 and the 32-bit version.
>>*   The 64-bit version seems reasonable:
>>
>>
>>
>> ==
>>
>> Test summary - w64-bit
>>
>> ==
>>
>> TEST  TOTAL  PASS  FAIL
>> ERROR
>>
>> jtreg:jdk/test:tier1   1645  161034 1
 <<
 jtreg:langtools/test:tier1 3907  381979
  9 <<

>>> jtreg:nashorn/test:tier1  0 0 0
>>0
>>
>> jtreg:jaxp/test:tier1 0 0 0
>>0
>>
>> ==
>>
>>*   However the 32-bit version of hotspot contains a bunch of inline
>> assembly pieces which uses an MSC specific syntax, and my ASM knowledge is
>> really limited. I have managed to get a many inline assembly codes from the
>> Linux version, but there are few pieces where I was not able to find a good
>> solution yet, so although the 32-bit version compiles, unfortunately it is
>> not working
>>*   I have installed VS Express 2013 and made sure that the
>> “traditional” Microsoft toolchain is still working with the changes
>>*   My OCA has been processed
>>
>> I have a changeset which cleanly applies to JDK9 v181, but I recall you
>> have mentioned earlier that you would like to consider this to JDK10
>>
>> So what is the best way to open a PR for review? This page:
>> http://openjdk.java.net/contribute/ says I should send the changeset as
>> attachment, but earlier somebody mentioned here that attachments are
>> removed from the developer mailing lists.
>>
>> Best regards,
>>
>> Peter
>>
>> From: Erik 
>> Joelsson>
>> Sent: Thursday, November 2, 2017 1:07 AM
>> To: Peter 
>> Budai>; Magnus 
>> Ihse
>> Bursie>
>> Cc: 
>> build-dev@openjdk.java.net>
>> Subject: Re: Building OpenJDK9 on MSYS2
>>
>> I would say a few hours is way too long for tier1, but it of course
>> depends on the hardware used. We typically run it on windows in less
>> than 30 minutes wit

Re: Building OpenJDK9 on MSYS2

[Thomas Stüfe]

Hi Peter,

sorry if I came over too harsh. I gave this some thoughts and now I think
getting the openjdk to build with gcc on Windows may be beneficial. Please
find more comments inline.

On Mon, Nov 27, 2017 at 12:12 PM, Peter Budai 
wrote:

> MSYS2 or Cygwin should be similar from the technical point of view IMHO.
> I’m familiar with MSYS2, but not with Cygwin.
>
>
>

I would prefer cygwin, as this is the officially adopted tool chain, and
the work is already done and we need to maintain it anyway. I can see the
value in having a different compiler, but not in having a different tool
chain. Again, my personal opinions, others may think differently.

A quick grep through our sources yields a number of hits on cygwin specific
code. Some are really cygwin specific (e.g. calls to cygpath.exe to
calculate the cygwin specific path) whereas others seem to just mean "any
posix like windows environment as opposed to native windows cmd.exe". If we
add msys2 to the list, would we not have to revise all these places?

The big change as you called out is to make sure that gcc toolchain can
> build successfully also for a Windows platform and produce a properly
> working binaries.
>
>
>
> BTW I don’t belie there are big performance differences whether you are
> building with GCC or MSC
>
>
>

Maybe you are right on the performance front, but I personally would still
be careful using gcc as a compiler for production builds. On one hand I
have an established tool chain with a company behind it I can pay for
support if something goes wrong. On the other hand a quiet exotic solution
for this platform.


> Once again, please advise on what is the best way to move forward, or stop
> this effort.
>
>
It is not my place to advice you or to decide anything. People from the
build group would have to decide whether we want to add support for
msys2+gcc and whether we want to support it.

..Thomas


>
> Peter
>
>
> --
> *From:* Thomas Stüfe 
> *Sent:* Thursday, November 23, 2017 10:36:07 PM
> *To:* Lussier, Denis
> *Cc:* Jonathan Gibbons; build-dev@openjdk.java.net; Peter Budai
>
> *Subject:* Re: Building OpenJDK9 on MSYS2
>
>
>
> On Thu, Nov 23, 2017 at 12:40 AM, Lussier, Denis 
> wrote:
>
>> This is good stuff.  Back in 2010 I got OpenJDK compiled and running on
>> the
>> Microsoft Toolchain.   I never ran the jtreg tests, but, the binaries
>> worked for running basic Tomcat but definitely not for trying to run
>> Eclipse.
>>
>> These days I am a pretty big fan of MSYS2.  In my personal experiences
>> with
>> building a PostgreSQL Windoze distribution, the MSYS2 binaries run a
>> little
>> faster than using the old MS Toolchain.
>>
>> https://www.openscg.com/2016/02/building-postgresql-on-windo
>> ws-for-performance/
>>
>>
> Well, the linked article does claim the msys2 toolchain to be faster than
> the Visual Studio, but there are no information I can see which compiler
> and linker options were used. Without this information, the article is
> difficult to take seriously.
>
> While I really respect these efforts, I regret seeing the fragmentation in
> windows build environments. I rather have one well kept build environment
> than of multiple buggy ones - and we have not that many folks interested in
> the windows port in the first place (it always feels like second place to
> the Posix platforms to me). The official build environment of the openjdk
> windows port is Cygwin + Visual Studio. Even if we think the gcc toolchain
> would be an attractive alternative to VS - why not just use the cygwin gcc
> instead? That way we would at least share the same posix layer.
>
> Just my 5c.
>
> Kind Regards, Thomas
>
>
>
>> --Luss
>>
>>
>> On Wed, Nov 22, 2017 at 4:28 PM, Jonathan Gibbons <
>> jonathan.gibb...@oracle.com> wrote:
>>
>> > Peter,
>> >
>> > With over 120 :tier1 test failures, it would be worth understanding the
>> > test failures as part of moving forward. There should normally be no
>> :tier1
>> > test failures.
>> >
>> > -- Jon
>> >
>> >
>> >
>> >
>> > On 11/22/2017 01:10 PM, Peter Budai wrote:
>> >
>> >> Let me give an update on the current status:
>> >>
>> >>*   I have managed to build both the 64 and the 32-bit version.
>> >>*   The 64-bit version seems reasonable:
>> >>
>> >>
>> >>
>> >> ==
>> >>
>> >> Test summary - w64-bit
>> >>
>> >> ==
>> >>
>> >> TEST  TOTAL  PASS  FAIL
>> >> ERROR
>> >>
>> >> jtreg:jdk/test:tier1   1645  161034
>>  1
>>  <<
>>  jtreg:langtools/test:tier1 3907  381979
>>   9 <<
>> 
>> >>> jtreg:nashorn/test:tier1  0 0
>>  0
>> >>0
>> >>
>> >> jtreg:jaxp/test:tier1 0 0 0
>> >>0
>> >>
>> >> ==
>> >>
>> >>*   However the 32-bit version of hotspot contains a bunch of inli

Re: Building OpenJDK9 on MSYS2

[Magnus Ihse Bursie]

Just a quick reply (I haven't read the details yet, will do so and 
re-reply if I find anything more to add).


It's important to differentiate two different aspects here.

1) Using msys2 instead of cygwin
2) Compiling using gcc on windows.

1 should be fairly trivial. We once supported msys, and it just recently 
bitrotted due to lack of testing. I don't see any good reasons not to 
revive this support.


2 has never been done before, and can probably be quite tricky. I'm not 
sure what to gain from it, but if someone is prepared to go through the 
effort of fixing this, I think it can be a quality boost to the code 
base -- right now we don't properly differentiate between "windows" and 
"microsoft toolchain", and this effort would help us clean up that mess.


But this is likely a huge undertaking, the prelimininary results showed 
multiple tier1 failures, which indicates (I believe) subtle issues in 
the compiled hotspot code.


/Magnus

On 2017-11-27 14:36, Thomas Stüfe wrote:

Hi Peter,

sorry if I came over too harsh. I gave this some thoughts and now I think
getting the openjdk to build with gcc on Windows may be beneficial. Please
find more comments inline.

On Mon, Nov 27, 2017 at 12:12 PM, Peter Budai 
wrote:


MSYS2 or Cygwin should be similar from the technical point of view IMHO.
I’m familiar with MSYS2, but not with Cygwin.




I would prefer cygwin, as this is the officially adopted tool chain, and
the work is already done and we need to maintain it anyway. I can see the
value in having a different compiler, but not in having a different tool
chain. Again, my personal opinions, others may think differently.

A quick grep through our sources yields a number of hits on cygwin specific
code. Some are really cygwin specific (e.g. calls to cygpath.exe to
calculate the cygwin specific path) whereas others seem to just mean "any
posix like windows environment as opposed to native windows cmd.exe". If we
add msys2 to the list, would we not have to revise all these places?

The big change as you called out is to make sure that gcc toolchain can

build successfully also for a Windows platform and produce a properly
working binaries.



BTW I don’t belie there are big performance differences whether you are
building with GCC or MSC




Maybe you are right on the performance front, but I personally would still
be careful using gcc as a compiler for production builds. On one hand I
have an established tool chain with a company behind it I can pay for
support if something goes wrong. On the other hand a quiet exotic solution
for this platform.



Once again, please advise on what is the best way to move forward, or stop
this effort.



It is not my place to advice you or to decide anything. People from the
build group would have to decide whether we want to add support for
msys2+gcc and whether we want to support it.

..Thomas



Peter


--
*From:* Thomas Stüfe 
*Sent:* Thursday, November 23, 2017 10:36:07 PM
*To:* Lussier, Denis
*Cc:* Jonathan Gibbons; build-dev@openjdk.java.net; Peter Budai

*Subject:* Re: Building OpenJDK9 on MSYS2



On Thu, Nov 23, 2017 at 12:40 AM, Lussier, Denis 
wrote:


This is good stuff.  Back in 2010 I got OpenJDK compiled and running on
the
Microsoft Toolchain.   I never ran the jtreg tests, but, the binaries
worked for running basic Tomcat but definitely not for trying to run
Eclipse.

These days I am a pretty big fan of MSYS2.  In my personal experiences
with
building a PostgreSQL Windoze distribution, the MSYS2 binaries run a
little
faster than using the old MS Toolchain.

https://www.openscg.com/2016/02/building-postgresql-on-windo
ws-for-performance/



Well, the linked article does claim the msys2 toolchain to be faster than
the Visual Studio, but there are no information I can see which compiler
and linker options were used. Without this information, the article is
difficult to take seriously.

While I really respect these efforts, I regret seeing the fragmentation in
windows build environments. I rather have one well kept build environment
than of multiple buggy ones - and we have not that many folks interested in
the windows port in the first place (it always feels like second place to
the Posix platforms to me). The official build environment of the openjdk
windows port is Cygwin + Visual Studio. Even if we think the gcc toolchain
would be an attractive alternative to VS - why not just use the cygwin gcc
instead? That way we would at least share the same posix layer.

Just my 5c.

Kind Regards, Thomas




--Luss


On Wed, Nov 22, 2017 at 4:28 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:


Peter,

With over 120 :tier1 test failures, it would be worth understanding the
test failures as part of moving forward. There should normally be no

:tier1

test failures.

-- Jon




On 11/22/2017 01:10 PM, Peter Budai wrote:


Let me give an update on the current status:

*   I have managed to build both the 64 and the 32-bit versio

Re: Building OpenJDK9 on MSYS2

[Thomas Stüfe]

On Mon, Nov 27, 2017 at 3:01 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> Just a quick reply (I haven't read the details yet, will do so and
> re-reply if I find anything more to add).
>
> It's important to differentiate two different aspects here.
>
> 1) Using msys2 instead of cygwin
> 2) Compiling using gcc on windows.
>
> 1 should be fairly trivial. We once supported msys, and it just recently
> bitrotted due to lack of testing. I don't see any good reasons not to
> revive this support.
>
> 2 has never been done before, and can probably be quite tricky. I'm not
> sure what to gain from it, but if someone is prepared to go through the
> effort of fixing this, I think it can be a quality boost to the code base
> -- right now we don't properly differentiate between "windows" and
> "microsoft toolchain", and this effort would help us clean up that mess.
>
>
Also the question of who is supposed to maintain it in the long run should
be answered. We are usually quite strict in adding new platforms - I
remember the recent BSD port discussions, which I believe ended in 1) needs
a long term maintainer, preferably a company or foundation 2) must pass TCK
*before* being added to the mainline. The BSD people did not meet the
restrictions, so they are still in their port branch. Which, btw, would be
a solution for msys2+gcc port too: work in their own branch until the
conditions are met to migrate to the base line?



> But this is likely a huge undertaking, the prelimininary results showed
> multiple tier1 failures, which indicates (I believe) subtle issues in the
> compiled hotspot code.
>
>
I agree this looks huge.


> /Magnus
>

..Thomas


>
> On 2017-11-27 14:36, Thomas Stüfe wrote:
>
>> Hi Peter,
>>
>> sorry if I came over too harsh. I gave this some thoughts and now I think
>> getting the openjdk to build with gcc on Windows may be beneficial. Please
>> find more comments inline.
>>
>> On Mon, Nov 27, 2017 at 12:12 PM, Peter Budai 
>> wrote:
>>
>> MSYS2 or Cygwin should be similar from the technical point of view IMHO.
>>> I’m familiar with MSYS2, but not with Cygwin.
>>>
>>>
>>>
>>> I would prefer cygwin, as this is the officially adopted tool chain, and
>> the work is already done and we need to maintain it anyway. I can see the
>> value in having a different compiler, but not in having a different tool
>> chain. Again, my personal opinions, others may think differently.
>>
>> A quick grep through our sources yields a number of hits on cygwin
>> specific
>> code. Some are really cygwin specific (e.g. calls to cygpath.exe to
>> calculate the cygwin specific path) whereas others seem to just mean "any
>> posix like windows environment as opposed to native windows cmd.exe". If
>> we
>> add msys2 to the list, would we not have to revise all these places?
>>
>> The big change as you called out is to make sure that gcc toolchain can
>>
>>> build successfully also for a Windows platform and produce a properly
>>> working binaries.
>>>
>>>
>>>
>>> BTW I don’t belie there are big performance differences whether you are
>>> building with GCC or MSC
>>>
>>>
>>>
>>> Maybe you are right on the performance front, but I personally would
>> still
>> be careful using gcc as a compiler for production builds. On one hand I
>> have an established tool chain with a company behind it I can pay for
>> support if something goes wrong. On the other hand a quiet exotic solution
>> for this platform.
>>
>>
>> Once again, please advise on what is the best way to move forward, or stop
>>> this effort.
>>>
>>>
>>> It is not my place to advice you or to decide anything. People from the
>> build group would have to decide whether we want to add support for
>> msys2+gcc and whether we want to support it.
>>
>> ..Thomas
>>
>>
>> Peter
>>>
>>>
>>> --
>>> *From:* Thomas Stüfe 
>>> *Sent:* Thursday, November 23, 2017 10:36:07 PM
>>> *To:* Lussier, Denis
>>> *Cc:* Jonathan Gibbons; build-dev@openjdk.java.net; Peter Budai
>>>
>>> *Subject:* Re: Building OpenJDK9 on MSYS2
>>>
>>>
>>>
>>> On Thu, Nov 23, 2017 at 12:40 AM, Lussier, Denis 
>>> wrote:
>>>
>>> This is good stuff.  Back in 2010 I got OpenJDK compiled and running on
 the
 Microsoft Toolchain.   I never ran the jtreg tests, but, the binaries
 worked for running basic Tomcat but definitely not for trying to run
 Eclipse.

 These days I am a pretty big fan of MSYS2.  In my personal experiences
 with
 building a PostgreSQL Windoze distribution, the MSYS2 binaries run a
 little
 faster than using the old MS Toolchain.

 https://www.openscg.com/2016/02/building-postgresql-on-windo
 ws-for-performance/


 Well, the linked article does claim the msys2 toolchain to be faster
>>> than
>>> the Visual Studio, but there are no information I can see which compiler
>>> and linker options were used. Without this information, the article is
>>> difficult to take seriously.
>>>
>>> While I real

Re: Building OpenJDK9 on MSYS2

[dalibor topic]

On 27.11.2017 15:17, Thomas Stüfe wrote:

Also the question of who is supposed to maintain it in the long run should
be answered. We are usually quite strict in adding new platforms - I
remember the recent BSD port discussions, which I believe ended in 1) needs
a long term maintainer, preferably a company or foundation 


To be more specific, adding a new platform (such as cygwin-newlib-gcc) 
would need to be accompanied by a JEP, and someone (an individual, or a 
few, or a lot of them) signing up to do the work on the JEP, i.e. the 
JEP would need to be 'funded'.  Whether those individuals are also 
members of a single legal entity or not does not matter much in theory. 
In practice, of course, legal entities might able to muster more 
resources in the pursuit of their goals than a single individual.



2) must pass TCK
*before* being added to the mainline. The BSD people did not meet the
restrictions, so they are still in their port branch. Which, btw, would be
a solution for msys2+gcc port too: work in their own branch until the
conditions are met to migrate to the base line?


I'd suggest that work on something adding a new platform such as 
cygwin-newlib-gcc would usually be better off in its own Project, as 
that allows the Project's contributors to bootstrap a port and the 
assiciated roles (Committer, Reviewer, etc) without having to 'earn 
merit' as mainline committers first.


cheers,
dalibor topic

--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: RFR: JDK-8177957 run-test summary lines look bad/misleading with long test names

[Erik Joelsson]

Looks good.

/Erik


On 2017-11-24 01:28, Magnus Ihse Bursie wrote:
When running individual tests using run-test, the summary section gets 
hard to read. For instance: (imagine having a fixed-with font :))

   TEST TOTAL PASS FAIL ERROR
   jtreg:hotspot/test/gc/stress/gcbasher/TestGCBasherWithG1.java 1 1 0 0

What makes this exact example even worse is that it aligns so bad so 
that the "1" belonging to the TOTAL column, ends up aligned with the 
FAIL label, so it looks as if the test failed.


If the test name is too long to fit before the number columns, we 
should add a line break, so the numbers still align on the right 
columns, but on the line after.


This bug also fixes some remaining issues from JDK-8191820:
* jtreg test descriptors are now normalized to TOPDIR (or CUSTOM_ROOT, 
if present). (Without this fix, almost all test names were too long.)

* Do not disallow running named test groups for jtreg tests out-of-tree.
* And a simplification in the matching for paths (we didn't need to 
treat absolute paths differently).


Bug: https://bugs.openjdk.java.net/browse/JDK-8177957
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8177957-linebreak-long-test-names/webrev.01


/Magnus

Re: RFR: JDK-8179554 make run-test does not respect ProblemList.txt

[Erik Joelsson]

Looks good.

/Erik


On 2017-11-24 02:14, Magnus Ihse Bursie wrote:
When running tests with `make run-test`, tests from 
jdk/test/ProblemList.txt and/or hotspot/test/ProblemList.txt aren't 
excluded.


Bug: https://bugs.openjdk.java.net/browse/JDK-8179554
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8179554-run-test-should-respect-problem-list/webrev.01


/Magnus

Re: RFR: JDK-8179555 make run-test should always use a fresh, clean JTwork directory

[Erik Joelsson]

Looks good.

/Erik


On 2017-11-24 02:23, Magnus Ihse Bursie wrote:
When running jtreg tests, make run-test should always run with a 
fresh, clean JTwork directory in order to avoid issues with code not 
being recompiled.


Bug: https://bugs.openjdk.java.net/browse/JDK-8179555
Patch inline:
diff --git a/make/RunTests.gmk b/make/RunTests.gmk
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -407,7 +407,10 @@
 $1_JTREG_BASIC_OPTIONS += -cpa:$$(JIB_JAR)
   endif

-  run-test-$1:
+  clean-workdir-$1:
+   $$(RM) -r $$($1_TEST_SUPPORT_DIR)
+
+  run-test-$1: clean-workdir-$1
    $$(call LogWarn)
    $$(call LogWarn, Running test '$$($1_TEST)')
    $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR))

/Magnus

Re: RFR: JDK-8189099 JTReg now supports 256 jobs

[Erik Joelsson]

Looks good.

/Erik


On 2017-11-24 02:22, Magnus Ihse Bursie wrote:

From the bug report:
"According to research by Jonathan Gibbons , JTReg now supports 256 
jobs, in contrast to the older limit of 50 jobs. This limit is 
enforced in the make files, and it should be updated to reflect the 
new limit (or the check removed entirely)."


I choose to remove the check. If you send in more than JOBS=256, then 
JTReg will complain. If that limit is ever increased, it should only 
be done so in JTReg, not also in the makefiles.


Bug: https://bugs.openjdk.java.net/browse/JDK-8189099
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8189099-remove-jtreg-job-limit-of-50/webrev.01


/Magnus

Re: RFR: JDK-8191856 "make clean-test" does not work properly

[Erik Joelsson]

Looks good.

/Erik


On 2017-11-24 02:45, Magnus Ihse Bursie wrote:
With the new layout of make run-test, the test-results and 
test-support directories are not removed by "make clean-test", and not 
even "make clean".


Bug: https://bugs.openjdk.java.net/browse/JDK-8191856
Patch inline:
diff --git a/make/Main.gmk b/make/Main.gmk
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -1049,7 +1049,7 @@
 # file.

 CLEAN_DIRS += hotspot jdk bootcycle-build test buildtools support \
-    images make-support test-make bundles buildjdk
+    images make-support test-make bundles buildjdk test-results 
test-support

 CLEAN_DIR_TARGETS := $(addprefix clean-, $(CLEAN_DIRS))
 CLEAN_SUPPORT_DIRS += demos
 CLEAN_SUPPORT_DIR_TARGETS := $(addprefix clean-, $(CLEAN_SUPPORT_DIRS))
@@ -1094,6 +1094,8 @@
 # while classes and touch files end up in jdk.
 clean-support: clean-jdk

+clean-test: clean-test-results clean-test-support
+
 # Remove everything, including configure configuration. If the output
 # directory was created by configure and now becomes empty, remove it 
as well.

 dist-clean: clean

/Magnus

Re: RFR: JDK-8179554 make run-test does not respect ProblemList.txt

[Tim Bell]

Magnus:

Looks good to me as well.

Tim

On 11/27/17 08:41, Erik Joelsson wrote:

Looks good.

/Erik


On 2017-11-24 02:14, Magnus Ihse Bursie wrote:

When running tests with `make run-test`, tests from
jdk/test/ProblemList.txt and/or hotspot/test/ProblemList.txt aren't
excluded.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179554
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8179554-run-test-should-respect-problem-list/webrev.01


/Magnus

Re: RFR: JDK-8179555 make run-test should always use a fresh, clean JTwork directory

[Tim Bell]

Magnus:


   "...always run with a fresh, clean JTwork directory..."


I couldn't agree more.  Looks good to me as well.

Tim

On 11/27/17 08:42, Erik Joelsson wrote:

Looks good.

/Erik


On 2017-11-24 02:23, Magnus Ihse Bursie wrote:

When running jtreg tests, make run-test should always run with a
fresh, clean JTwork directory in order to avoid issues with code not
being recompiled.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179555
Patch inline:
diff --git a/make/RunTests.gmk b/make/RunTests.gmk
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -407,7 +407,10 @@
 $1_JTREG_BASIC_OPTIONS += -cpa:$$(JIB_JAR)
   endif

-  run-test-$1:
+  clean-workdir-$1:
+   $$(RM) -r $$($1_TEST_SUPPORT_DIR)
+
+  run-test-$1: clean-workdir-$1
$$(call LogWarn)
$$(call LogWarn, Running test '$$($1_TEST)')
$$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR))

/Magnus

RFR: JDK-8191923 Save run-test summary to file

[Magnus Ihse Bursie]

We should save the run-test summary to a file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01


/Magnus

Re: RFR: JDK-8191923 Save run-test summary to file

[Tim Bell]

Magnus:


We should save the run-test summary to a file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01


Looks good.

/Tim

Re: RFR: JDK-8191923 Save run-test summary to file

[Erik Joelsson]

Looks good.

/Erik


On 2017-11-27 10:41, Magnus Ihse Bursie wrote:

We should save the run-test summary to a file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01


/Magnus

on jdk.internal.vm.ci

[Maurizio Cimadamore]

Hi,
the IntelliJ support for JDK relies on make to give the set of source 
roots used for any given modules. I have noticed that the set of source 
roots associated with 'jdk.internal.vm.ci' is incorrect, as it points to


src/jdk.internal.vm.ci/share/classes

while in reality it should point to a subset of directories contained in 
such a folder (depending on the architecture).


This breaks the IntelliJ project configuration if jdk.internal.vm.ci is 
selected - which is causing issues for some, see [1].


[1] - 
http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-November/000590.html


Maurizio

Re: RFR: JDK-8191923 Save run-test summary to file

[Magnus Ihse Bursie]

On 2017-11-27 20:02, Erik Joelsson wrote:

Looks good.

Only it didn't. :-)

I managed to drop one (very important) line when juggling this patch 
between my sandbox and the repo.


Updated WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02


/Magnus



/Erik


On 2017-11-27 10:41, Magnus Ihse Bursie wrote:

We should save the run-test summary to a file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01


/Magnus

Re: RFR: JDK-8191923 Save run-test summary to file

[Tim Bell]

Magnus:


On 2017-11-27 20:02, Erik Joelsson wrote:

Looks good.

Only it didn't. :-)

I managed to drop one (very important) line when juggling this patch
between my sandbox and the repo.

Updated WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02


Yes, indeed.  That would do it.

Looks good.

Tim


/Magnus



/Erik


On 2017-11-27 10:41, Magnus Ihse Bursie wrote:

We should save the run-test summary to a file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01


/Magnus

RFR: JDK-8191933 Use failure handler in run-test

[Magnus Ihse Bursie]

The jtreg failure handler needs to be used when running tests using the 
run-test framework.


Bug: https://bugs.openjdk.java.net/browse/JDK-8191933
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191933-use-failure-handler-in-run-test/webrev.01


/Magnus

Re: RFR: JDK-8191923 Save run-test summary to file

[Erik Joelsson]

You need a definition of the variable? Couldn't the user just be 
required to define it when running tests?


Looks good.

/Erik


On 2017-11-27 11:59, Magnus Ihse Bursie wrote:

On 2017-11-27 20:02, Erik Joelsson wrote:

Looks good.

Only it didn't. :-)

I managed to drop one (very important) line when juggling this patch 
between my sandbox and the repo.


Updated WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02


/Magnus



/Erik


On 2017-11-27 10:41, Magnus Ihse Bursie wrote:

We should save the run-test summary to a file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01


/Magnus

Re: RFR: JDK-8191923 Save run-test summary to file

[Magnus Ihse Bursie]

On 2017-11-27 22:52, Erik Joelsson wrote:
You need a definition of the variable? Couldn't the user just be 
required to define it when running tests?
I'm not sure what you mean. The intention is to not only print the 
output, but to also store it in the test-results directory. I don't 
think the test result directory should be specifically user overridable. 
If it should be (why?), there's more places to update.


/Magnus


Looks good.

/Erik


On 2017-11-27 11:59, Magnus Ihse Bursie wrote:

On 2017-11-27 20:02, Erik Joelsson wrote:

Looks good.

Only it didn't. :-)

I managed to drop one (very important) line when juggling this patch 
between my sandbox and the repo.


Updated WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02


/Magnus



/Erik


On 2017-11-27 10:41, Magnus Ihse Bursie wrote:

We should save the run-test summary to a file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01


/Magnus

Re: RFR: JDK-8191923 Save run-test summary to file

[Erik Joelsson]

On 2017-11-27 14:19, Magnus Ihse Bursie wrote:

On 2017-11-27 22:52, Erik Joelsson wrote:
You need a definition of the variable? Couldn't the user just be 
required to define it when running tests?

Sorry, I meant this as a joke but forgot to add the smiley. :)

/Erik
I'm not sure what you mean. The intention is to not only print the 
output, but to also store it in the test-results directory. I don't 
think the test result directory should be specifically user 
overridable. If it should be (why?), there's more places to update.


/Magnus


Looks good.

/Erik


On 2017-11-27 11:59, Magnus Ihse Bursie wrote:

On 2017-11-27 20:02, Erik Joelsson wrote:

Looks good.

Only it didn't. :-)

I managed to drop one (very important) line when juggling this patch 
between my sandbox and the repo.


Updated WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02


/Magnus



/Erik


On 2017-11-27 10:41, Magnus Ihse Bursie wrote:

We should save the run-test summary to a file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01


/Magnus

RFR: JDK-8177956 Add TEST_VM_OPTS as convenience for run-test arguments

[Magnus Ihse Bursie]

From the bug report:

A common scenario is adding vm arguments when running tests. While this 
can be accomplished by JTREG="VM_OPTIONS=-Xfoo", this is a lot to type 
for a common case. In the future, when gtest accepts vm arguments as 
well, a separate, similar but yet different GTEST="VM_OPTIONS=-Xfoo" 
would be needed.


A new "global" TEST_VM_OPTS=X should behave as if VM_OPTIONS=X were 
present on all applicable test framework option control variables.


My solution also adds a new "global" TEST_OPTS, where TEST_VM_OPTS=-Xfoo 
behaves identical to TEST_OPTS="VM_OPTIONS=-Xfoo", but which also allows 
other global settings. It also adds support for VM_OPTIONS to gtest, and 
it improves error resilience in gtest result parsing.


Bug: https://bugs.openjdk.java.net/browse/JDK-8177956
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8177956-add-TEST_OPTS/webrev.01

/Magnus

Re: RFR: JDK-8177956 Add TEST_VM_OPTS as convenience for run-test arguments

[Erik Joelsson]

Looks good.

/Erik


On 2017-11-27 15:11, Magnus Ihse Bursie wrote:

From the bug report:

A common scenario is adding vm arguments when running tests. While 
this can be accomplished by JTREG="VM_OPTIONS=-Xfoo", this is a lot to 
type for a common case. In the future, when gtest accepts vm arguments 
as well, a separate, similar but yet different 
GTEST="VM_OPTIONS=-Xfoo" would be needed.


A new "global" TEST_VM_OPTS=X should behave as if VM_OPTIONS=X were 
present on all applicable test framework option control variables.


My solution also adds a new "global" TEST_OPTS, where 
TEST_VM_OPTS=-Xfoo behaves identical to TEST_OPTS="VM_OPTIONS=-Xfoo", 
but which also allows other global settings. It also adds support for 
VM_OPTIONS to gtest, and it improves error resilience in gtest result 
parsing.


Bug: https://bugs.openjdk.java.net/browse/JDK-8177956
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8177956-add-TEST_OPTS/webrev.01


/Magnus

Review Request: JDK-8191942: Replace jdeps use of jdk.internal.util.jar.VersionedStream with new public API

[mandy chung]

This is a follow-up on JDK-8189611 that defines a new public API to 
return a stream of versioned entries and to return the real name of a 
JAR entry.  JDK-8189611 leaves jdeps untouched because jdeps is compiled 
with the boot JDK.


This patch includes:
(1) changes the build not to build jdk.jdeps interim module but include 
com.sun.tools.classfile classes in the CreateSymbol buildtool
(2) replace the use of internal API with the public APIs defined by 
JDK-8191942

(3) remove jdk.internal.util.jar.VersonedStream class

Webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8191942/webrev.00/

Thanks
Mandy

[10] Review Request: 8189656 The Windows L&F should be moved out from the shared folder

[Sergey Bylokhov]

Hello.
Please review the fix for jdk10. This is the second attempt to move 
windows L&F from non-windows platforms. The first attempt JDK-6461834[1] 
was reverted because of JDK-8184813[2].
The root cause of those issue was fixed in JDK-8075255[3], and now we 
can move it again.


Bug: https://bugs.openjdk.java.net/browse/JDK-8189656
Webrev can be found at: http://cr.openjdk.java.net/~serb/8189656/webrev.02

The fix contains a few parts:
 - The code related to win l&f was moved from the "share" to the 
"windows" folder
 - The platform-specific export was moved from module-info.java to 
module-info.java.extra

 - A number of tests which use windows L&F were marked as windows-specific
 - The stub "ThemeReader.java" which was used to build win w&f on unix 
was removed.


[1] https://bugs.openjdk.java.net/browse/JDK-6461834
[2] https://bugs.openjdk.java.net/browse/JDK-8184813
[3] https://bugs.openjdk.java.net/browse/JDK-8075255

--
Best regards, Sergey.

Re: problem building client variant in 9.0.1+11

[David Holmes]

Hi Mete,

A 64-bit client build, stand-alone, is not supported. There could be 
more issues than just getting the build to not fail.


David

On 23/11/2017 11:32 PM, Mete Balci wrote:

Hi,

I am trying to build the client variant, but it fails with the output
below. Is this a known issue or is there any specific configure option I
should use ?

Thanks,

Mete

Compiling 4 files for BUILD_JIGSAW_TOOLS
Error: missing `server' JVM at
`/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/lib/server/libjvm.so'.
Please install or use the JRE or JDK that contains these missing components.
ExplodedImageOptimize.gmk:40: recipe for target
'/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done'
failed
make[3]: ***
[/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done]
Error 4
make/Main.gmk:356: recipe for target 'exploded-image-optimize' failed
make[2]: *** [exploded-image-optimize] Error 1