On 8/13/18 2:09 AM, Felix Yang wrote:
Hi Alan,
please review the update patch, and reduced checking as suggested:
http://cr.openjdk.java.net/~xiaofeya/8194230/webrev.01/
This looks okay.
Mandy
Hi Roger,
thanks for review.
-- Igor
> On Aug 10, 2018, at 1:49 PM, Roger Riggs wrote:
>
> Hi Igor,
>
> Looks fine
>
> Roger
>
> On 8/10/18 4:22 PM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html
>>> 2 lines changed: 0 ins; 0 del; 2 mod;
>> Hi
Approved!
There was a lot of benchmarking work, so I'd like to see the jmh benchmark
checked in.
Especially since the exact variant we eventually settled on is not in
Hacker's Delight.
On Mon, Aug 13, 2018 at 12:09 PM, Ivan Gerasimov
wrote:
> Okay, your last variant is the winner :)
>
> Here's
Hi Bernard,
I updated the patch per your suggestions and it checks out on our systems.
http://cr.openjdk.java.net/~bpb/8207744/webrev.04/
Thanks,
Brian
On Aug 10, 2018, at 6:20 AM, B. Blaser wrote:
> Among the files you suggest to fix, only the following ones are still
> using 'readdir64'
On 8/13/18 11:18 AM, Baesken, Matthias wrote:
As Chris and Alan mentioned, you should move the parsing of the property
to a more general location so it can be used by other code that uses
this property.
Hi Sean, Thanks for the input and comments .
Could we do the moving of the property
Okay, your last variant is the winner :)
Here's the updated webrev, benchmark and the graphs:
http://cr.openjdk.java.net/~igerasim/8209171/02/webrev/
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/MyBenchmark.java
On Mon, Aug 13, 2018 at 10:10 AM, Ivan Gerasimov
wrote:
> Hi Martin!
>
> Good point about the command line flags, thanks!
>
> These variants are close to numberOfTrailingZeros_07 that I've already
> tested, though you did better by saving one arithmetic operation at the
> return line!
>
>
Right.
Hi Martin!
Good point about the command line flags, thanks!
These variants are close to numberOfTrailingZeros_07 that I've already
tested, though you did better by saving one arithmetic operation at the
return line!
I'll rerun the benchmarks.
With kind regards,
Ivan
On 8/13/18 7:56 AM,
Hi Claes,
Looks good!
Thanks,
Jiangli
On 8/13/18 7:16 AM, Claes Redestad wrote:
Hi Jiangli,
On 2018-08-10 19:15, Jiangli Zhou wrote:
Hi Claes,
The updated Integer.java looks good. The test also looks good to me.
I'd suggest adding some checks in CheckIntegerCacheApp test for the
cached
Looks good.
Naoto
On 8/13/18 2:48 AM, Rachna Goel wrote:
Hi,
Kindly review the fix to JDK-8209047.
Bug: https://bugs.openjdk.java.net/browse/JDK-8209047
webrev: http://cr.openjdk.java.net/~rgoel/JDK-8209047/webrev.03/
It is a regression caused by JDK-8202537. Because of the 'B' character
>As Chris and Alan mentioned, you should move the parsing of the property
>to a more general location so it can be used by other code that uses
>this property.
Hi Sean, Thanks for the input and comments .
Could we do the moving of the property parsingdo in a followup CR, I
would
The number of plausible variants is astonishing!
---
Your use of -client and -server is outdated, which explains why you get the
same results for both (-client is ignored).
I'm not sure what's blessed by hotspot team, but for C1 I
use -XX:+TieredCompilation -XX:TieredStopAtLevel=1 and for C2 I
Hi Jiangli,
On 2018-08-10 19:15, Jiangli Zhou wrote:
Hi Claes,
The updated Integer.java looks good. The test also looks good to me.
I'd suggest adding some checks in CheckIntegerCacheApp test for the
cached Integers using WhiteBox API, WhiteBox.isShared(object) to make
sure that they are
Hi,
Kindly review the fix to JDK-8209047.
Bug: https://bugs.openjdk.java.net/browse/JDK-8209047
webrev: http://cr.openjdk.java.net/~rgoel/JDK-8209047/webrev.03/
It is a regression caused by JDK-8202537. Because of the 'B' character
introduced in the CLDR time patterns "B HH:mm:ss", "B H:mm"
Hi Alan,
please review the update patch, and reduced checking as suggested:
http://cr.openjdk.java.net/~xiaofeya/8194230/webrev.01/
Thanks,
Felix
On 2018/8/6 18:23, Alan Bateman wrote:
On 31/07/2018 07:16, Felix Yang wrote:
Hi all,
please review a patch to improve the checking on
On 8/12/18 10:57 AM, Martin Buchholz wrote:
If delegating to nlz is the winner so far, we should be able to do at
least as well by inlining nlz into ntz and then looking for more
optimizations. Following this strategy leads naturally to
static int ntz_inlineNlz2(int i) {
i &= -i;
16 matches
Mail list logo