date:20190219

I've pushed the patch. 

for the reference, 8219408 
 [1] was filed to handle 
jdk tests which have ${; the only affected hotspot tests are vmTestbase tests, 
so 8219140  [2] covers all 
hotspot tests.

[1] https://bugs.openjdk.java.net/browse/JDK-8219408 

[2] https://bugs.openjdk.java.net/browse/JDK-8219140 


Thanks,
-- Igor


> On Feb 19, 2019, at 5:06 PM, Igor Ignatyev  wrote:
> 
> Hi Erik,
> 
> thanks for your review. 
> 
> we can't just bump the required version as it can introduce changes in tests' 
> behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], 
> this will affect all the tests which have ${} in their @run directives, 
> for example it will affect many vmTestbase tests which use 
> PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after 
> we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. 
> I'll check if there are other tests which will be affected and will file 
> RFE(s) to cover them as well.
> 
> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 
> 
> [2] https://bugs.openjdk.java.net/browse/JDK-8219140 
> 
> 
> Thanks,
> -- Igor
> 
>> On Feb 19, 2019, at 5:01 PM, Erik Joelsson  wrote:
>> 
>> Looks good.
>> 
>> Do we need to also bump the required version in the TEST.ROOT files?
>> 
>> /Erik
>> 
>> On 2019-02-19 16:34, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
 1 line changed: 0 ins; 0 del; 1 mod;
>>> Hi all,
>>> 
>>> could you please review this one-liner which switch jtreg version to 
>>> jtreg4.2-b14?
>>> 
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
>>> JBS:  https://bugs.openjdk.java.net/browse/JDK-8219132
>>> testing: tier[1-5], client tests and jcstress test group testing showed no 
>>> new failures; spot checking of .jtr files also didn't find any anomalies
>>> 
>>> Thanks,
>>> -- Igor
>

Re: RFR(T) : 8219132 : switch to jtreg4.2-b14

2019-02-19 Thread Joseph D. Darcy


Hi Igor,

On 2/19/2019 5:54 PM, Igor Ignatyev wrote:

Joe,

allowSmartActionArgs is opt-in if requiredVersion < b14, and opt-out 
if requiredVersion >= b14, please see 
http://hg.openjdk.java.net/code-tools/jtreg/rev/36c592d2f544 . so you 
don't have to have allowSmartActionArgs=true in 8219254.


Thanks,
-- Igor



Thanks for the correction Igor; I'll update my patch accordingly.

Cheers,

-Joe

Re: RFR(T) : 8219132 : switch to jtreg4.2-b14

Joe,

allowSmartActionArgs is opt-in if requiredVersion < b14, and opt-out if 
requiredVersion >= b14, please see 
http://hg.openjdk.java.net/code-tools/jtreg/rev/36c592d2f544 
 . so you don't 
have to have allowSmartActionArgs=true in 8219254.

Thanks,
-- Igor

> On Feb 19, 2019, at 5:49 PM, Joseph D. Darcy  wrote:
> 
> Hello,
> 
> On 2/19/2019 5:06 PM, Igor Ignatyev wrote:
>> Hi Erik,
>> 
>> thanks for your review.
>> 
>> we can't just bump the required version as it can introduce changes in 
>> tests' behavior. requiredVersion >= 4.2 b14 will enable 
>> allowSmartActionArgs[1],
> 
> From what I understand from Jon, allowSmartActionArgs is opt-in and has to be 
> enabled in the TEST.ROOT file with
> 
>allowSmartActionArgs=true
> 
> Therefore, IIRC, the required version could be bumped without enabling smart 
> action args.
> 
> (I have a patch in progress to use smart action args for langtools tests: 
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012959.html)
> 
> HTH,
> 
> -Joe
> 
>>  this will affect all the tests which have ${} in their @run directives, 
>> for example it will affect many vmTestbase tests which use 
>> PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after 
>> we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase 
>> tests. I'll check if there are other tests which will be affected and will 
>> file RFE(s) to cover them as well.
>> 
>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 
>> 
>> [2] https://bugs.openjdk.java.net/browse/JDK-8219140 
>> 
>> 
>> Thanks,
>> -- Igor
>> 
>>> On Feb 19, 2019, at 5:01 PM, Erik Joelsson  wrote:
>>> 
>>> Looks good.
>>> 
>>> Do we need to also bump the required version in the TEST.ROOT files?
>>> 
>>> /Erik
>>> 
>>> On 2019-02-19 16:34, Igor Ignatyev wrote:
 http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
> 1 line changed: 0 ins; 0 del; 1 mod;
 Hi all,
 
 could you please review this one-liner which switch jtreg version to 
 jtreg4.2-b14?
 
 webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
 JBS:  https://bugs.openjdk.java.net/browse/JDK-8219132
 testing: tier[1-5], client tests and jcstress test group testing showed no 
 new failures; spot checking of .jtr files also didn't find any anomalies
 
 Thanks,
 -- Igor
>

Re: RFR(T) : 8219132 : switch to jtreg4.2-b14

2019-02-19 Thread Joseph D. Darcy


Hello,

On 2/19/2019 5:06 PM, Igor Ignatyev wrote:

Hi Erik,

thanks for your review.

we can't just bump the required version as it can introduce changes in tests' 
behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1],


From what I understand from Jon, allowSmartActionArgs is opt-in and has 
to be enabled in the TEST.ROOT file with


allowSmartActionArgs=true

Therefore, IIRC, the required version could be bumped without enabling 
smart action args.


(I have a patch in progress to use smart action args for langtools 
tests: 
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012959.html)


HTH,

-Joe


  this will affect all the tests which have ${} in their @run directives, 
for example it will affect many vmTestbase tests which use PropertyResolvingWrapper. 
therefore, I suggest we bump requiredVersion after we clean up such tests and have 
filed 8219140[2] to deal w/ vmTestbase tests. I'll check if there are other tests 
which will be affected and will file RFE(s) to cover them as well.

[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 

[2] https://bugs.openjdk.java.net/browse/JDK-8219140 


Thanks,
-- Igor


On Feb 19, 2019, at 5:01 PM, Erik Joelsson  wrote:

Looks good.

Do we need to also bump the required version in the TEST.ROOT files?

/Erik

On 2019-02-19 16:34, Igor Ignatyev wrote:

http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html

1 line changed: 0 ins; 0 del; 1 mod;

Hi all,

could you please review this one-liner which switch jtreg version to 
jtreg4.2-b14?

webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
JBS:  https://bugs.openjdk.java.net/browse/JDK-8219132
testing: tier[1-5], client tests and jcstress test group testing showed no new 
failures; spot checking of .jtr files also didn't find any anomalies

Thanks,
-- Igor

RFR(S) : 8219395 : integrate gcov w/ run-test

http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html
> 65 lines changed: 59 ins; 0 del; 6 mod;

Hi all,

could you please review the patch which makes it easy to run tests on the 
builds w/ native-code-coverage enabled? to do so the patch
 - sets GCOV_PREFIX env. variable, so .gcda files will be stored in 
build/*/test-results/gcov-output directory, and makes jtreg to propagate this 
env. variable to JDK under test
 - adds linux-x64-gcov and macosx-x64-gcov jib profiles
 - changes 'run-test-prebuilt' profile to set GCOV_ENABLED=true if it's the 
tested profile is -gcov profile

and also fixes comment for JDKOPT_SETUP_CODE_COVERAGE in jdk-options.m4.

webrev: http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8219395
testing: 
 - :tier1 on {linux,macos}-x64 and {linux,macos}-x64-gcov
 - checked that *-gcov builds have .gcno files generated and stored in symbols 
bundle; and regular builds don't 
 - checked that *-gcov runs have .gcda files generated in 
test-results/gcov-output; and runs on regular builds don't

Thanks,
-- Igor

Re: Faster rebuild with GNU gold linker

2019-02-19 Thread Martin Buchholz

https://openjdk.markmail.org/thread/q3layufiyjivu42c

On Tue, Feb 19, 2019 at 5:03 PM Ioi Lam  wrote:

> For the impatient engineers 
>
> I did some measurement between the default GNU linker "ld" vs "ld.gold".
> I am trying to get the fastest rebuild time after I modify one cpp file.
> With gold, it's down to about 1/3 of the original time.
>
>
> slowdebug (~220MB libjvm.so)
>
>   recompile 1 cpp file  |  relink libjvm.so only
> ld:   33 s   25 s
> gold 1 thread:16 s9 s
> gold 8 threads:   13 s6 s
>
>
> fastdebug (~360MB libjvm.so)
>
>
>   recompile 1 cpp file  |  relink libjvm.so only
> ld:   35 s25 s
> gold 1 thread:18 s10 s
> gold 8 threads:   15 s 6 s
>
>
> Question: do we want to add built-in support for gold into the JDK
> makefiles?
>
>
> Notes:
>
> To choose gold, run configure with something like:
>
>  --with-extra-ldflags='-fuse-ld=gold -Wl,--threads,--thread-count,8'
>
> I essentially do a "make hotspot" and then move the libjvm.so into a JDK
> image, instead of doing a full JDK image build.
>
> "make hotspot" makes a copy of libjvm.so (from
> support/modules_libs/java.base/server/ to jdk/lib/server/). I hacked the
> Makefile to make a hard link instead to avoid the unnecessary I/O.
>
> libjvm.so is built with --with-native-debug-symbols=internal to avoid
> the expensive invocations of objcopy and strip.
>
>
> My environment:
>
> I am using gcc7.3.0 on Ubuntu 16.04.5 on a 5 year old Dell Precision
> T7600 with dual socket Xeon E5-2665 @ 2.40GHz, 64GB RAM, Samsung 840 PRO
> SSD. I suspect gold can run even faster, but my slow SSD is holding it
> back.
>
> ld version   = GNU ld (GNU Binutils) 2.30
> gold version = GNU gold (GNU Binutils for Ubuntu 2.26.1) 1.11
>
> (These are just the versions available to me on my machine, not
> necessarily the best)
>
>

Re: RFR(T) : 8219132 : switch to jtreg4.2-b14

Hi Erik,

thanks for your review. 

we can't just bump the required version as it can introduce changes in tests' 
behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], this 
will affect all the tests which have ${} in their @run directives, for 
example it will affect many vmTestbase tests which use 
PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after we 
clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. I'll 
check if there are other tests which will be affected and will file RFE(s) to 
cover them as well.

[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 

[2] https://bugs.openjdk.java.net/browse/JDK-8219140 

Thanks,
-- Igor

> On Feb 19, 2019, at 5:01 PM, Erik Joelsson  wrote:
> 
> Looks good.
> 
> Do we need to also bump the required version in the TEST.ROOT files?
> 
> /Erik
> 
> On 2019-02-19 16:34, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
>>> 1 line changed: 0 ins; 0 del; 1 mod;
>> Hi all,
>> 
>> could you please review this one-liner which switch jtreg version to 
>> jtreg4.2-b14?
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
>> JBS:  https://bugs.openjdk.java.net/browse/JDK-8219132
>> testing: tier[1-5], client tests and jcstress test group testing showed no 
>> new failures; spot checking of .jtr files also didn't find any anomalies
>> 
>> Thanks,
>> -- Igor

Re: RFR(T) : 8219132 : switch to jtreg4.2-b14


Looks good.

Do we need to also bump the required version in the TEST.ROOT files?

/Erik

On 2019-02-19 16:34, Igor Ignatyev wrote:

http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html

1 line changed: 0 ins; 0 del; 1 mod;

Hi all,

could you please review this one-liner which switch jtreg version to 
jtreg4.2-b14?

webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
JBS:  https://bugs.openjdk.java.net/browse/JDK-8219132
testing: tier[1-5], client tests and jcstress test group testing showed no new 
failures; spot checking of .jtr files also didn't find any anomalies

Thanks,
-- Igor

Faster rebuild with GNU gold linker

2019-02-19 Thread Ioi Lam


For the impatient engineers 

I did some measurement between the default GNU linker "ld" vs "ld.gold". 
I am trying to get the fastest rebuild time after I modify one cpp file. 
With gold, it's down to about 1/3 of the original time.



slowdebug (~220MB libjvm.so)

 recompile 1 cpp file  |  relink libjvm.so only
ld:       33 s   25 s
gold 1 thread:    16 s            9 s
gold 8 threads:   13 s    6 s


fastdebug (~360MB libjvm.so)


 recompile 1 cpp file  |  relink libjvm.so only
ld:           35 s            25 s
gold 1 thread:    18 s    10 s
gold 8 threads:   15 s     6 s


Question: do we want to add built-in support for gold into the JDK 
makefiles?



Notes:

To choose gold, run configure with something like:

    --with-extra-ldflags='-fuse-ld=gold -Wl,--threads,--thread-count,8'

I essentially do a "make hotspot" and then move the libjvm.so into a JDK 
image, instead of doing a full JDK image build.


"make hotspot" makes a copy of libjvm.so (from 
support/modules_libs/java.base/server/ to jdk/lib/server/). I hacked the 
Makefile to make a hard link instead to avoid the unnecessary I/O.


libjvm.so is built with --with-native-debug-symbols=internal to avoid 
the expensive invocations of objcopy and strip.



My environment:

I am using gcc7.3.0 on Ubuntu 16.04.5 on a 5 year old Dell Precision 
T7600 with dual socket Xeon E5-2665 @ 2.40GHz, 64GB RAM, Samsung 840 PRO 
SSD. I suspect gold can run even faster, but my slow SSD is holding it back.


ld version   = GNU ld (GNU Binutils) 2.30
gold version = GNU gold (GNU Binutils for Ubuntu 2.26.1) 1.11

(These are just the versions available to me on my machine, not 
necessarily the best)

RFR(T) : 8219132 : switch to jtreg4.2-b14

http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
> 1 line changed: 0 ins; 0 del; 1 mod;

Hi all,

could you please review this one-liner which switch jtreg version to 
jtreg4.2-b14?

webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html
JBS:  https://bugs.openjdk.java.net/browse/JDK-8219132
testing: tier[1-5], client tests and jcstress test group testing showed no new 
failures; spot checking of .jtr files also didn't find any anomalies

Thanks,
-- Igor

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

2019-02-19 Thread Claes Redestad


Looks good.

I filed https://bugs.openjdk.java.net/browse/JDK-8219394 for this bug.

Thanks!

/Claes

On 2019-02-19 18:04, Erik Joelsson wrote:
The problem with the jarfile looks to be a missing $(FIXPATH) when 
running microbenchmarks. The java process is simply unable to understand 
cygwin paths. Does this patch solve the issue for you, Jorn?


diff -r 7c17199fa37d make/RunTests.gmk
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -690,7 +690,7 @@
  $$(call LogWarn, Running test '$$($1_TEST)')
  $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR))
  $$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/micro, \
-        $$($1_MICRO_TEST_JDK)/bin/java $$($1_MICRO_JAVA_OPTIONS) -jar 
$$($1_MICRO_BENCHMARKS_JAR) \
+        $$(FIXPATH) $$($1_MICRO_TEST_JDK)/bin/java 
$$($1_MICRO_JAVA_OPTIONS) -jar $$($1_MICRO_BENCHMARKS_JAR) \

      $$($1_MICRO_ITER) $$($1_MICRO_FORK) $$($1_MICRO_TIME) \
      $$($1_MICRO_WARMUP_ITER) $$($1_MICRO_WARMUP_TIME) \
      $$($1_MICRO_VM_OPTIONS) $$($1_MICRO_BASIC_OPTIONS) 
$$(MICRO_OPTIONS) \


/Erik

On 2019-02-18 14:20, Claes Redestad wrote:

http://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002624.html>

Hi,

On 2019-02-18 22:34, Jorn Vernee wrote:

Hi Claes,


1. Does running make test rather than make test-only work?


No. Same error there. Sorry, I tried that first and then re-ran with 
`test-only`. I also tried with a clean build FWIW.



2. Can you run the benchmarks.jar directly?


Yes, this is working, thanks. This way I can also pass extra flags to 
JMH, which is nice :)


---

FWIW, I also had some problems when running configure.

   1.) I did not get a warning when I was missing --with-jmh for 
configure, although it looks like there is supposed to be one 
(without --with-jmh I got the same access error, but the 
benchmarks.jar did not exist).


--with-jmh is an optional configure flag, not sure what we could do to
warn here. Perhaps there's some way to ensure certain make targets
depend on the configure having been run with the necessary prerequistes.
Sounds like a fine enhancement.

   2.) My path to the --with-jmh folder had spaces in it, which was 
causing an error in make/autoconf/lib-tests.m4 on line 76 [1].


Sounds like a bug.



But those both had obvious workarounds.

---

I was hoping to use the framework for Panama, so I'd likely have some 
native library as dependency of the benchmark. Is there currently any 
support for building (native) dependencies automatically?


There should be support in the build system _somewhere_, but adding a
native library to a microbenchmark might still be a non-trivial
enhancement to the current implementation. It'd be a great addition,
though. I might have time to help out sometime soon, but I've got my
hands full right now. Perhaps someone else on this list could advice?

Thanks!

/Claes



Thanks,
Jorn

[1] : 
http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

2019-02-19 Thread Claes Redestad


Pushed here: http://hg.openjdk.java.net/jdk/jdk/rev/1b40a0178b2a

/Claes

On 2019-02-19 22:41, Jorn Vernee wrote:

Great! Thanks for picking this up.

Jorn

Re: RFR(S) : 8219391 : extend gcov support to llvm/clang

thanks Erik, pushed.

y, this means exactly that.

-- Igor

> On Feb 19, 2019, at 12:35 PM, Erik Joelsson  wrote:
> 
> Looks good.
> 
> Does this mean it works on Macos?
> 
> /Erik
> 
> On 2019-02-19 11:46, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00
>>> 21 lines changed: 3 ins; 0 del; 18 mod;
>> Hi all,
>> 
>> could you please review this small and trivial patch which allows usage of 
>> --enable-native-coverage configure option w/ clang devkit?
>> 
>>> llvm/clang supports gcov in the same way gcc does, it has the same 
>>> compiler/linker options to enable code coverage information, produces the 
>>> same .gcda files; the produced binaries generate .gcdo files and treat env. 
>>> variables in the same way.
>> webrev: http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219391
>> testing: built on mac w/ --enable-native-coverage, run some tests and 
>> spot-checked coverage
>> 
>> Thanks,
>> -- Igor
>>

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

Thanks, looks good!

/Erik

On 2019-02-19 10:35, Jorn Vernee wrote:

Hi Erik,

I have included your suggestions:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.01

I'm a committer on project Panama, but I'm not sure if I have write
access to jdk/jdk as well. If the new webrev looks good I could give
it a try, but otherwise someone else would have to create a commit for
me.

Thanks,
Jorn

Erik Joelsson schreef op 2019-02-19 18:13:

Hello Jorn,

This looks pretty good and should probably be pushed to mainline. Some
minor nits.

In BuildMicrobenchmark.gmk:

Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in
RunTests.gmk.

Line 131, please add ", \" plus newline like on 123-124.

/Erik

On 2019-02-19 03:49, Jorn Vernee wrote:

Hi,

I've taken a first stab at adding support for native dependencies:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/

With a small test benchmark:
http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/

Please be aware that both are based on the Panama/foreign branch [1].

I was not able to find a workaround for my problem with the jar file
access unfortunately. So I have been testing by manually running the
jar file with the expected arguments (but, that's not really testing
the RunTests.gmk changes).

It would be great if someone can offer a suggestion for that. The
jar file is being created in make/test/BuildMicrobenchmark.gmk using
the SetupJarArchive function [2]. The execution of the jar is done
by code in RunTests.gmk [3]. I guess these 2 are racing to access
the jar, and that is what's causing the error from the subject line.

Otherwise, I can't really test this properly, so maybe someone else
can take it from here.

Cheers,
Jorn

[1] : http://hg.openjdk.java.net/panama/dev/shortlog/tip
[2] :
http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/test/BuildMicrobenchmark.gmk#l98
[3] :
http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/RunTests.gmk#l692

Jorn Vernee schreef op 2019-02-18 23:38:

Hi,

1.) I did not get a warning when I was missing --with-jmh for
configure, although it looks like there is supposed to be one
(without --with-jmh I got the same access error, but the
benchmarks.jar did not exist).

--with-jmh is an optional configure flag, not sure what we could
do to

warn here. Perhaps there's some way to ensure certain make targets
depend on the configure having been run with the necessary
prerequistes.

Sounds like a fine enhancement.

There seems to be a check for this in
make/test/BuildMicrobenchmark.gmk [2]:

```
ifeq ($(JMH_CORE_JAR), )
$(info Error: JMH is missing. Please use configure --with-jmh.)
$(error Cannot continue)
endif
```

But this does not seem to be triggered.

I was hoping to use the framework for Panama, so I'd likely have
some native library as dependency of the benchmark. Is there
currently any support for building (native) dependencies
automatically?

There should be support in the build system _somewhere_, but adding a
native library to a microbenchmark might still be a non-trivial
enhancement to the current implementation. It'd be a great addition,
though. I might have time to help out sometime soon, but I've got my
hands full right now. Perhaps someone else on this list could advice?

The Panama native test sources are being built by
'make/test/JtregNativeJdk.gmk' I'm not sure it's possible to hook
directly into that, but maybe it can serve as an example for adding a
similar feature to the benchmark suite.

I'll try looking into that.

Thanks!

Thanks for the help!

Jorn

[2] :
http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34

/Claes

Thanks,
Jorn

[1] :
http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

Great! Thanks for picking this up.

Jorn

Claes Redestad schreef op 2019-02-19 22:36:

Hi Jorn,

I'll sponsor this for jdk/jdk. I'll file a RFE, test it and push it
seeing it's already reviewed.

Thanks!

/Claes

On 2019-02-19 19:35, Jorn Vernee wrote:

Hi Erik,

I have included your suggestions:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.01

Thanks,
Jorn

Erik Joelsson schreef op 2019-02-19 18:13:

Hello Jorn,

This looks pretty good and should probably be pushed to mainline.
Some

minor nits.

In BuildMicrobenchmark.gmk:

Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in
RunTests.gmk.

Line 131, please add ", \" plus newline like on 123-124.

/Erik

On 2019-02-19 03:49, Jorn Vernee wrote:

Hi,

I've taken a first stab at adding support for native dependencies:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/

With a small test benchmark:
http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/

Please be aware that both are based on the Panama/foreign branch
[1].

Otherwise, I can't really test this properly, so maybe someone else
can take it from here.

Cheers,
Jorn

Hi,

--with-jmh is an optional configure flag, not sure what we could
do to

warn here. Perhaps there's some way to ensure certain make targets
depend on the configure having been run with the necessary
prerequistes.

Sounds like a fine enhancement.

There seems to be a check for this in
make/test/BuildMicrobenchmark.gmk [2]:

```
ifeq ($(JMH_CORE_JAR), )
$(info Error: JMH is missing. Please use configure --with-jmh.)
$(error Cannot continue)
endif
```

But this does not seem to be triggered.

I was hoping to use the framework for Panama, so I'd likely have
some native library as dependency of the benchmark. Is there
currently any support for building (native) dependencies
automatically?

There should be support in the build system _somewhere_, but
adding a

native library to a microbenchmark might still be a non-trivial
enhancement to the current implementation. It'd be a great
addition,
though. I might have time to help out sometime soon, but I've got
my
hands full right now. Perhaps someone else on this list could
advice?

The Panama native test sources are being built by
'make/test/JtregNativeJdk.gmk' I'm not sure it's possible to hook
directly into that, but maybe it can serve as an example for adding
a

similar feature to the benchmark suite.

I'll try looking into that.

Thanks!

Thanks for the help!

Jorn

[2] :
http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34

/Claes

Thanks,
Jorn

[1] :
http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

2019-02-19 Thread Claes Redestad

Hi Jorn,

I'll sponsor this for jdk/jdk. I'll file a RFE, test it and push it
seeing it's already reviewed.

Thanks!

/Claes

On 2019-02-19 19:35, Jorn Vernee wrote:

Hi Erik,

I have included your suggestions:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.01

I'm a committer on project Panama, but I'm not sure if I have write
access to jdk/jdk as well. If the new webrev looks good I could give it
a try, but otherwise someone else would have to create a commit for me.

Thanks,
Jorn

Erik Joelsson schreef op 2019-02-19 18:13:

Hello Jorn,

This looks pretty good and should probably be pushed to mainline. Some
minor nits.

In BuildMicrobenchmark.gmk:

Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in
RunTests.gmk.

Line 131, please add ", \" plus newline like on 123-124.

/Erik

On 2019-02-19 03:49, Jorn Vernee wrote:

Hi,

I've taken a first stab at adding support for native dependencies:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/

With a small test benchmark:
http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/

Please be aware that both are based on the Panama/foreign branch [1].

It would be great if someone can offer a suggestion for that. The jar
file is being created in make/test/BuildMicrobenchmark.gmk using the
SetupJarArchive function [2]. The execution of the jar is done by
code in RunTests.gmk [3]. I guess these 2 are racing to access the
jar, and that is what's causing the error from the subject line.

Otherwise, I can't really test this properly, so maybe someone else
can take it from here.

Cheers,
Jorn

[1] : http://hg.openjdk.java.net/panama/dev/shortlog/tip
[2] :
http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/test/BuildMicrobenchmark.gmk#l98

[3] :
http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/RunTests.gmk#l692

Jorn Vernee schreef op 2019-02-18 23:38:

Hi,

--with-jmh is an optional configure flag, not sure what we could do to
warn here. Perhaps there's some way to ensure certain make targets
depend on the configure having been run with the necessary
prerequistes.

Sounds like a fine enhancement.

There seems to be a check for this in
make/test/BuildMicrobenchmark.gmk [2]:

```
ifeq ($(JMH_CORE_JAR), )
$(info Error: JMH is missing. Please use configure --with-jmh.)
$(error Cannot continue)
endif
```

But this does not seem to be triggered.

I was hoping to use the framework for Panama, so I'd likely have
some native library as dependency of the benchmark. Is there
currently any support for building (native) dependencies
automatically?

I'll try looking into that.

Thanks!

Thanks for the help!

Jorn

[2] :
http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34

/Claes

Thanks,
Jorn

[1] :
http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76

Re: RFR(S) : 8219391 : extend gcov support to llvm/clang


Looks good.

Does this mean it works on Macos?

/Erik

On 2019-02-19 11:46, Igor Ignatyev wrote:

http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00

21 lines changed: 3 ins; 0 del; 18 mod;

Hi all,

could you please review this small and trivial patch which allows usage of 
--enable-native-coverage configure option w/ clang devkit?


llvm/clang supports gcov in the same way gcc does, it has the same 
compiler/linker options to enable code coverage information, produces the same 
.gcda files; the produced binaries generate .gcdo files and treat env. 
variables in the same way.

webrev: http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00
JBS: https://bugs.openjdk.java.net/browse/JDK-8219391
testing: built on mac w/ --enable-native-coverage, run some tests and 
spot-checked coverage

Thanks,
-- Igor

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

2019-02-19 Thread Martin Buchholz

On Tue, Feb 19, 2019 at 10:37 AM Jorn Vernee  wrote:

>
> I'm a committer on project Panama, but I'm not sure if I have write
> access to jdk/jdk as well.


You don't
https://openjdk.java.net/census#jvernee

RFR(S) : 8219391 : extend gcov support to llvm/clang

http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00
> 21 lines changed: 3 ins; 0 del; 18 mod;

Hi all,

could you please review this small and trivial patch which allows usage of 
--enable-native-coverage configure option w/ clang devkit?

> llvm/clang supports gcov in the same way gcc does, it has the same 
> compiler/linker options to enable code coverage information, produces the 
> same .gcda files; the produced binaries generate .gcdo files and treat env. 
> variables in the same way.

webrev: http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00
JBS: https://bugs.openjdk.java.net/browse/JDK-8219391
testing: built on mac w/ --enable-native-coverage, run some tests and 
spot-checked coverage

Thanks,
-- Igor

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

Hi Erik,

I have included your suggestions:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.01

I'm a committer on project Panama, but I'm not sure if I have write
access to jdk/jdk as well. If the new webrev looks good I could give it
a try, but otherwise someone else would have to create a commit for me.

Thanks,
Jorn

Erik Joelsson schreef op 2019-02-19 18:13:

Hello Jorn,

This looks pretty good and should probably be pushed to mainline. Some
minor nits.

In BuildMicrobenchmark.gmk:

Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in
RunTests.gmk.

Line 131, please add ", \" plus newline like on 123-124.

/Erik

On 2019-02-19 03:49, Jorn Vernee wrote:

Hi,

I've taken a first stab at adding support for native dependencies:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/

With a small test benchmark:
http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/

Please be aware that both are based on the Panama/foreign branch [1].

It would be great if someone can offer a suggestion for that. The jar
file is being created in make/test/BuildMicrobenchmark.gmk using the
SetupJarArchive function [2]. The execution of the jar is done by code
in RunTests.gmk [3]. I guess these 2 are racing to access the jar, and
that is what's causing the error from the subject line.

Otherwise, I can't really test this properly, so maybe someone else
can take it from here.

Cheers,
Jorn

Jorn Vernee schreef op 2019-02-18 23:38:

Hi,

--with-jmh is an optional configure flag, not sure what we could do
to

warn here. Perhaps there's some way to ensure certain make targets
depend on the configure having been run with the necessary
prerequistes.

Sounds like a fine enhancement.

There seems to be a check for this in
make/test/BuildMicrobenchmark.gmk [2]:

```
ifeq ($(JMH_CORE_JAR), )
$(info Error: JMH is missing. Please use configure --with-jmh.)
$(error Cannot continue)
endif
```

But this does not seem to be triggered.

I was hoping to use the framework for Panama, so I'd likely have
some native library as dependency of the benchmark. Is there
currently any support for building (native) dependencies
automatically?

There should be support in the build system _somewhere_, but adding
a

native library to a microbenchmark might still be a non-trivial
enhancement to the current implementation. It'd be a great addition,
though. I might have time to help out sometime soon, but I've got my
hands full right now. Perhaps someone else on this list could
advice?

I'll try looking into that.

Thanks!

Thanks for the help!

Jorn

[2] :
http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34

/Claes

Thanks,
Jorn

[1] :
http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76

Re: Running micro benchmark results in 'Error: Unable to access jarfile'


Yes, that fixes the problem. Thanks!

Jorn

Erik Joelsson schreef op 2019-02-19 18:04:

The problem with the jarfile looks to be a missing $(FIXPATH) when
running microbenchmarks. The java process is simply unable to
understand cygwin paths. Does this patch solve the issue for you,
Jorn?

diff -r 7c17199fa37d make/RunTests.gmk
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -690,7 +690,7 @@
 $$(call LogWarn, Running test '$$($1_TEST)')
 $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR))
 $$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/micro, \
-        $$($1_MICRO_TEST_JDK)/bin/java $$($1_MICRO_JAVA_OPTIONS) -jar
$$($1_MICRO_BENCHMARKS_JAR) \
+        $$(FIXPATH) $$($1_MICRO_TEST_JDK)/bin/java
$$($1_MICRO_JAVA_OPTIONS) -jar $$($1_MICRO_BENCHMARKS_JAR) \
     $$($1_MICRO_ITER) $$($1_MICRO_FORK) $$($1_MICRO_TIME) \
     $$($1_MICRO_WARMUP_ITER) $$($1_MICRO_WARMUP_TIME) \
     $$($1_MICRO_VM_OPTIONS) $$($1_MICRO_BASIC_OPTIONS)
$$(MICRO_OPTIONS) \

/Erik

On 2019-02-18 14:20, Claes Redestad wrote:

http://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002624.html>

Hi,

On 2019-02-18 22:34, Jorn Vernee wrote:

Hi Claes,


1. Does running make test rather than make test-only work?


No. Same error there. Sorry, I tried that first and then re-ran with 
`test-only`. I also tried with a clean build FWIW.



2. Can you run the benchmarks.jar directly?


Yes, this is working, thanks. This way I can also pass extra flags to 
JMH, which is nice :)


---

FWIW, I also had some problems when running configure.

   1.) I did not get a warning when I was missing --with-jmh for 
configure, although it looks like there is supposed to be one 
(without --with-jmh I got the same access error, but the 
benchmarks.jar did not exist).


--with-jmh is an optional configure flag, not sure what we could do to
warn here. Perhaps there's some way to ensure certain make targets
depend on the configure having been run with the necessary 
prerequistes.

Sounds like a fine enhancement.

   2.) My path to the --with-jmh folder had spaces in it, which was 
causing an error in make/autoconf/lib-tests.m4 on line 76 [1].


Sounds like a bug.



But those both had obvious workarounds.

---

I was hoping to use the framework for Panama, so I'd likely have some 
native library as dependency of the benchmark. Is there currently any 
support for building (native) dependencies automatically?


There should be support in the build system _somewhere_, but adding a
native library to a microbenchmark might still be a non-trivial
enhancement to the current implementation. It'd be a great addition,
though. I might have time to help out sometime soon, but I've got my
hands full right now. Perhaps someone else on this list could advice?

Thanks!

/Claes



Thanks,
Jorn

[1] : 
http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

Hello Jorn,

This looks pretty good and should probably be pushed to mainline. Some
minor nits.

In BuildMicrobenchmark.gmk:

Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in
RunTests.gmk.

Line 131, please add ", \" plus newline like on 123-124.

/Erik

On 2019-02-19 03:49, Jorn Vernee wrote:

Hi,

I've taken a first stab at adding support for native dependencies:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/

With a small test benchmark:
http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/

Please be aware that both are based on the Panama/foreign branch [1].

It would be great if someone can offer a suggestion for that. The jar
file is being created in make/test/BuildMicrobenchmark.gmk using the
SetupJarArchive function [2]. The execution of the jar is done by code
in RunTests.gmk [3]. I guess these 2 are racing to access the jar, and
that is what's causing the error from the subject line.

Otherwise, I can't really test this properly, so maybe someone else
can take it from here.

Cheers,
Jorn

Jorn Vernee schreef op 2019-02-18 23:38:

Hi,

Sounds like a fine enhancement.

There seems to be a check for this in
make/test/BuildMicrobenchmark.gmk [2]:

```
ifeq ($(JMH_CORE_JAR), )
$(info Error: JMH is missing. Please use configure --with-jmh.)
$(error Cannot continue)
endif
```

But this does not seem to be triggered.

I was hoping to use the framework for Panama, so I'd likely have
some native library as dependency of the benchmark. Is there
currently any support for building (native) dependencies
automatically?

I'll try looking into that.

Thanks!

Thanks for the help!

Jorn

[2] :
http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34

/Claes

Thanks,
Jorn

[1] :
http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

The problem with the jarfile looks to be a missing $(FIXPATH) when 
running microbenchmarks. The java process is simply unable to understand 
cygwin paths. Does this patch solve the issue for you, Jorn?


diff -r 7c17199fa37d make/RunTests.gmk
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -690,7 +690,7 @@
 $$(call LogWarn, Running test '$$($1_TEST)')
 $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR))
 $$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/micro, \
-        $$($1_MICRO_TEST_JDK)/bin/java $$($1_MICRO_JAVA_OPTIONS) -jar 
$$($1_MICRO_BENCHMARKS_JAR) \
+        $$(FIXPATH) $$($1_MICRO_TEST_JDK)/bin/java 
$$($1_MICRO_JAVA_OPTIONS) -jar $$($1_MICRO_BENCHMARKS_JAR) \

     $$($1_MICRO_ITER) $$($1_MICRO_FORK) $$($1_MICRO_TIME) \
     $$($1_MICRO_WARMUP_ITER) $$($1_MICRO_WARMUP_TIME) \
     $$($1_MICRO_VM_OPTIONS) $$($1_MICRO_BASIC_OPTIONS) 
$$(MICRO_OPTIONS) \


/Erik

On 2019-02-18 14:20, Claes Redestad wrote:

http://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002624.html>

Hi,

On 2019-02-18 22:34, Jorn Vernee wrote:

Hi Claes,


1. Does running make test rather than make test-only work?


No. Same error there. Sorry, I tried that first and then re-ran with 
`test-only`. I also tried with a clean build FWIW.



2. Can you run the benchmarks.jar directly?


Yes, this is working, thanks. This way I can also pass extra flags to 
JMH, which is nice :)


---

FWIW, I also had some problems when running configure.

   1.) I did not get a warning when I was missing --with-jmh for 
configure, although it looks like there is supposed to be one 
(without --with-jmh I got the same access error, but the 
benchmarks.jar did not exist).


--with-jmh is an optional configure flag, not sure what we could do to
warn here. Perhaps there's some way to ensure certain make targets
depend on the configure having been run with the necessary prerequistes.
Sounds like a fine enhancement.

   2.) My path to the --with-jmh folder had spaces in it, which was 
causing an error in make/autoconf/lib-tests.m4 on line 76 [1].


Sounds like a bug.



But those both had obvious workarounds.

---

I was hoping to use the framework for Panama, so I'd likely have some 
native library as dependency of the benchmark. Is there currently any 
support for building (native) dependencies automatically?


There should be support in the build system _somewhere_, but adding a
native library to a microbenchmark might still be a non-trivial
enhancement to the current implementation. It'd be a great addition,
though. I might have time to help out sometime soon, but I've got my
hands full right now. Perhaps someone else on this list could advice?

Thanks!

/Claes



Thanks,
Jorn

[1] : 
http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76

Re: RFR: JDK-8212091 : Move native code under platform specific folders and files

2019-02-19 Thread Roger Riggs


Hi Alexander,

Some files appear to be moved with hg, but others are copied and deleted.

Please use hg mv to retain the continuity of the history.

Thanks, Roger

On 02/15/2019 10:03 PM, Alexander Matveev wrote:

Hi Magnus,

http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/

Moved all files from "posix" to "unix" folder and reverted 
Lib-jdk.jpackage.gmk changes.

Webrev updated with files moved, instead of add/remove.

Thanks,
Alexander

On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote:



On 2019-02-15 04:31, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Moved native code under platform specific folder.
- Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX.
- MAC define is still used in JavaVirtualMachine.cpp and Package.cpp 
for Mac specific code to filter out some arguments. I decided to 
keep it as is for now, since Mac specific code is small.
- Defines are used in Platform.cpp to initialize platform specific 
classes.

- Removed all pragma warning and fixed all compilation warnings.
- Removed unused code.

[1] https://bugs.openjdk.java.net/browse/JDK-8212091

[2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/
The JDK standard is to use "unix", not "posix", for the shared 
functionality between linux/solaris/macosx. You can keep the name 
"PosixPlatform.*" if you want, though; the important thing is the 
directory name.


Also, if you do that, you do not need any changes to 
make/lib/Lib-jdk.jpackage.gmk, since that will be automatically 
understood by the build system.


It looks from the webrev that you have "moved" the files by doing "hg 
add" and "hg remove". Please use "hg move" instead -- this will keep 
history intact, and it allows reviewers to see if you have also made 
changes to the moved files.


(If you do have modified the moved file, reverting a "hg add+hg 
remove" process is a bit more tricky -- you need to do "hg forget" on 
the new file, rename it to something else (otherwise "hg move" will 
complain), "hg revert" the old file back in place, do a "hg move" 
from the old to the new, and then copy the modified, renamed file 
back over the target new file again.)


/Magnus


Thanks,
Alexander

Re: Running micro benchmark results in 'Error: Unable to access jarfile'