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

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].

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

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

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 @@

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

Hi Roger, Some deleted files are actually deleted files, since I did code cleanup as well. Added files contain code from splitting original source files. This was needed to re-arrange code. Not sure how to log with hg file split. Also, we already moved files without keeping history, since we

Re: Faster rebuild with GNU gold linker

Hi Martin, Thanks for the info. I didn't know that this has been discussed so recently. Should have checked befor I posted. Anyway, I built the latest lld from GIT, but it's slower than gold on my machine. Just linking libjvm.so is 5.8s vs 3.8s. On 2/19/19 5:23 PM, Martin Buchholz wrote:

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

On 20/02/2019 00: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:

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

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

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:

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

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

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

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

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.

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

Faster rebuild with GNU gold linker

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

Re: Faster rebuild with GNU gold linker

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

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

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

Re: Faster rebuild with GNU gold linker

Ahh, I was using a debug build of lld. After making a release build, the link time drops to 1.1 seconds! It's definitely better than gold. On 2/19/19 10:35 PM, Ioi Lam wrote: Hi Martin, Thanks for the info. I didn't know that this has been discussed so recently. Should have checked befor I

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

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

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:

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

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

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

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: Running micro benchmark results in 'Error: Unable to access jarfile'

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

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

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

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,

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

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

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,

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