Re: [12] Review Request: 8212213 All tests for splashscreen stopped worked in jdk12b13
On 17/10/2018 13:59, Phil Race wrote: Everything in here - except the subject line - points to a completely unrelated bug + fix. I believe you meant : https://bugs.openjdk.java.net/browse/JDK-8212213 http://cr.openjdk.java.net/~serb/8212213/webrev.00/ O_o Right, Thank you for correction! -- Best regards, Sergey.
Re: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks
Hi, added documentation of the new build targets, and synced up with recent changes (thanks Erik for help dealing with some tricky merge conflicts): http://cr.openjdk.java.net/~redestad/8061281/jdk.01/ Thanks! /Claes On 2018-10-09 15:15, Claes Redestad wrote: Hi, please review the initial build support for JEP 230: Microbenchmark Suite[1]. Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 There are some added steps to be able to build the microbenchmark suite: export JMH_HOME=/path/to/jmh (mkdir -p $JMH_HOME; cd $JMH_HOME; bash make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) bash configure --with-jmh=$JMH_HOME make build-microbenchmark This produces the JMH benchmarks under build/$CONF_NAME/images/test/micro/microbenchmarks.jar There is also support woven into the make run-test target (thanks to Magnus), allowing for integrated build and test: make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi 2;RESULT_FORMAT=json" Remaining tasks before the JEP can be targetted is to write proper documentation and deciding which microbenchmarks to migrate from jmh-jdk-microbenchmarks[2]. Thanks! /Claes [1] http://openjdk.java.net/jeps/230 [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/
Re: [12] Review Request: 8212213 All tests for splashscreen stopped worked in jdk12b13
Everything in here - except the subject line - points to a completely unrelated bug + fix. I believe you meant : https://bugs.openjdk.java.net/browse/JDK-8212213 http://cr.openjdk.java.net/~serb/8212213/webrev.00/ -phil. On 10/17/2018 01:52 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8211992 Webrev: http://cr.openjdk.java.net/~serb/8211992/webrev.00 This change updates the fix for JDK-8210705[1] and adds one more JNIEXPORT which is requires for splashscreen logic. [1] http://hg.openjdk.java.net/jdk/jdk/rev/8bbb5cbac92c
[12] Review Request: 8212213 All tests for splashscreen stopped worked in jdk12b13
Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8211992 Webrev: http://cr.openjdk.java.net/~serb/8211992/webrev.00 This change updates the fix for JDK-8210705[1] and adds one more JNIEXPORT which is requires for splashscreen logic. [1] http://hg.openjdk.java.net/jdk/jdk/rev/8bbb5cbac92c -- Best regards, Sergey.
Re: RFC: JEP JDK-8208089: Implement C++14 Language Features
On 16/10/2018 02:25, Kim Barrett wrote: On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov wrote: Kim, If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming. What is "sufficient lead time"? I'm not proposing an answer, just suggesting that 3 months (approx time between JEP publication and JDK 12 fork) might be sufficient, and a worthy goal. That's a decision that ought to be made as part of the Targeting discussion for this JEP. Right now, it's not even a Candidate, since there's still work to be done. I'm fine with that, and you probably can assume to document this goal in the JEP if noone speaks up. Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker. That's good news, though pretty much what I expected. I'm more worried about Solaris. Having a goal of JDK 12 may help move things along.
Re: RFR: 8212201: Classlist build tool should be built with new javac
Looks good. /Erik On 2018-10-17 04:55, Claes Redestad wrote: Hi again, stumbled on some failures in pre-integration testing (but not locally, initially) due to having the wrong include: http://cr.openjdk.java.net/~redestad/8212201/jdk.01 Thanks Magnus for pointing out the very peculiar ways make is silent about missing definitions, leading to weird errors down the line instead of failing fast.. /Claes On 2018-10-15 21:10, Claes Redestad wrote: Hi, please review this patch to build HelloClasslist / classlist.jar targetting the latest bytecode version, to ensure the classlist generation uses all recent features, e.g., indified string concat (as intended) Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212201 Thanks! /Claes
Re: RFR: JDK-8212587 equals in MakeBase does not handle empty strings correctly
Looks good! /Erik On 2018-10-17 03:29, Magnus Ihse Bursie wrote: The macro equals in MakeBase.gmk does not handle empty strings correctly. Comparing two empty strings returns as non-equal, even though they should be equal. This had the result that DependOnVariable caused eternal redoing of a target if the variable in question happened to be empty, since when the new empty value was compared to the old empty value, it was deemed different, and thus a remake of the target was initiated. The solution was tricky, even by Make syntax standards. I guarantee you, every single space in this construct must be the way it is. :-& Bug: https://bugs.openjdk.java.net/browse/JDK-8212587 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8212587-equals-handle-empty-strings/webrev.01 /Magnus
Re: RFR: 8212201: Classlist build tool should be built with new javac
Looks good to me. /Magnus On 2018-10-17 13:55, Claes Redestad wrote: Hi again, stumbled on some failures in pre-integration testing (but not locally, initially) due to having the wrong include: http://cr.openjdk.java.net/~redestad/8212201/jdk.01 Thanks Magnus for pointing out the very peculiar ways make is silent about missing definitions, leading to weird errors down the line instead of failing fast.. /Claes On 2018-10-15 21:10, Claes Redestad wrote: Hi, please review this patch to build HelloClasslist / classlist.jar targetting the latest bytecode version, to ensure the classlist generation uses all recent features, e.g., indified string concat (as intended) Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212201 Thanks! /Claes
Re: RFR: 8212201: Classlist build tool should be built with new javac
Hi again, stumbled on some failures in pre-integration testing (but not locally, initially) due to having the wrong include: http://cr.openjdk.java.net/~redestad/8212201/jdk.01 Thanks Magnus for pointing out the very peculiar ways make is silent about missing definitions, leading to weird errors down the line instead of failing fast.. /Claes On 2018-10-15 21:10, Claes Redestad wrote: Hi, please review this patch to build HelloClasslist / classlist.jar targetting the latest bytecode version, to ensure the classlist generation uses all recent features, e.g., indified string concat (as intended) Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212201 Thanks! /Claes
RFR: JDK-8212587 equals in MakeBase does not handle empty strings correctly
The macro equals in MakeBase.gmk does not handle empty strings correctly. Comparing two empty strings returns as non-equal, even though they should be equal. This had the result that DependOnVariable caused eternal redoing of a target if the variable in question happened to be empty, since when the new empty value was compared to the old empty value, it was deemed different, and thus a remake of the target was initiated. The solution was tricky, even by Make syntax standards. I guarantee you, every single space in this construct must be the way it is. :-& Bug: https://bugs.openjdk.java.net/browse/JDK-8212587 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8212587-equals-handle-empty-strings/webrev.01 /Magnus
