Re: RFR8194230, jdk/internal/jrtfs/remote/RemoteRuntimeImageTest.java fails with NPE
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
Re: RFR(XXS) : 8209382 : [error-prone] HashtableContains in sun/rmi/server/ActivationGroupImpl.java
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 all, >> >> could you please review this one-line patch for the error reported by >> error-prone? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209382 >> webrev: http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html >> >> Thanks, >> -- Igor >
Re: RFR 8209171 : Simplify Java implementation of Integer/Long.numberOfTrailingZeros()
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 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
> http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/be
> nch-int-04-client.png
> http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/be
> nch-int-04-server.png
>
> With kind regards,
> Ivan
>
>
> On 8/13/18 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!
>>
>> I'll rerun the benchmarks.
>>
>> With kind regards,
>>
>> Ivan
>>
>>
>> On 8/13/18 7:56 AM, Martin Buchholz wrote:
>>
>>> 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 use
>>> -XX:-TieredCompilation -server
>>>
>>> ---
>>>
>>> Now I understand the advantage of using ~i & (i - 1): the subsequent
>>> zero check is a short-circuit for all odd numbers, better than i & -i,
>>> which explains your results - they depend on being able to short-circuit.
>>>
>>> So just use a more faithful inlining of nlz without trying to improve on
>>> it.
>>>
>>> static int ntz_inlineNlz5(int i) {
>>> i = ~i & (i - 1);
>>> if (i <= 0)
>>> return (i == 0) ? 0 : 32;
>>> int n = 1;
>>> if (i >= 1 << 16) { n += 16; i >>>= 16; }
>>> if (i >= 1 << 8) { n += 8; i >>>= 8; }
>>> if (i >= 1 << 4) { n += 4; i >>>= 4; }
>>> if (i >= 1 << 2) { n += 2; i >>>= 2; }
>>> return n + (i >>> 1);
>>> }
>>>
>>> But it's hard to resist the urge to optimize out a branch:
>>>
>>> static int ntz_inlineNlz6(int i) {
>>> i = ~i & (i - 1);
>>> if (i <= 0) return i & 32;
>>> int n = 1;
>>> if (i >= 1 << 16) { n += 16; i >>>= 16; }
>>> if (i >= 1 << 8) { n += 8; i >>>= 8; }
>>> if (i >= 1 << 4) { n += 4; i >>>= 4; }
>>> if (i >= 1 << 2) { n += 2; i >>>= 2; }
>>> return n + (i >>> 1);
>>> }
>>>
>>>
>>
> --
> With kind regards,
> Ivan Gerasimov
>
>
Re: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir versus opendir64/closedir64
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' for other systems than AIX:
Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
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 parsingdo in a followup CR, I would prefer this . I think it should be done as part of this issue. It is too late to get this into JDK 11, so I think it is better to take the time now to do the code restructuring. Thanks, Sean
Re: RFR 8209171 : Simplify Java implementation of Integer/Long.numberOfTrailingZeros()
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
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-04-client.png
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-04-server.png
With kind regards,
Ivan
On 8/13/18 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!
I'll rerun the benchmarks.
With kind regards,
Ivan
On 8/13/18 7:56 AM, Martin Buchholz wrote:
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 use
-XX:-TieredCompilation -server
---
Now I understand the advantage of using ~i & (i - 1): the subsequent
zero check is a short-circuit for all odd numbers, better than i &
-i, which explains your results - they depend on being able to
short-circuit.
So just use a more faithful inlining of nlz without trying to improve
on it.
static int ntz_inlineNlz5(int i) {
i = ~i & (i - 1);
if (i <= 0)
return (i == 0) ? 0 : 32;
int n = 1;
if (i >= 1 << 16) { n += 16; i >>>= 16; }
if (i >= 1 << 8) { n += 8; i >>>= 8; }
if (i >= 1 << 4) { n += 4; i >>>= 4; }
if (i >= 1 << 2) { n += 2; i >>>= 2; }
return n + (i >>> 1);
}
But it's hard to resist the urge to optimize out a branch:
static int ntz_inlineNlz6(int i) {
i = ~i & (i - 1);
if (i <= 0) return i & 32;
int n = 1;
if (i >= 1 << 16) { n += 16; i >>>= 16; }
if (i >= 1 << 8) { n += 8; i >>>= 8; }
if (i >= 1 << 4) { n += 4; i >>>= 4; }
if (i >= 1 << 2) { n += 2; i >>>= 2; }
return n + (i >>> 1);
}
--
With kind regards,
Ivan Gerasimov
Re: RFR 8209171 : Simplify Java implementation of Integer/Long.numberOfTrailingZeros()
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. At this point return n + i - (i >> 1); i is either 1 or 3, and i - (i >> 1) is equivalent to 1 + (i >>> 1) so just initialize n to 1 instead. Very much like Integer.numberOfLeadingZeros does.
Re: RFR 8209171 : Simplify Java implementation of Integer/Long.numberOfTrailingZeros()
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, Martin Buchholz wrote:
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
use -XX:-TieredCompilation -server
---
Now I understand the advantage of using ~i & (i - 1): the subsequent
zero check is a short-circuit for all odd numbers, better than i & -i,
which explains your results - they depend on being able to short-circuit.
So just use a more faithful inlining of nlz without trying to improve
on it.
static int ntz_inlineNlz5(int i) {
i = ~i & (i - 1);
if (i <= 0)
return (i == 0) ? 0 : 32;
int n = 1;
if (i >= 1 << 16) { n += 16; i >>>= 16; }
if (i >= 1 << 8) { n += 8; i >>>= 8; }
if (i >= 1 << 4) { n += 4; i >>>= 4; }
if (i >= 1 << 2) { n += 2; i >>>= 2; }
return n + (i >>> 1);
}
But it's hard to resist the urge to optimize out a branch:
static int ntz_inlineNlz6(int i) {
i = ~i & (i - 1);
if (i <= 0) return i & 32;
int n = 1;
if (i >= 1 << 16) { n += 16; i >>>= 16; }
if (i >= 1 << 8) { n += 8; i >>>= 8; }
if (i >= 1 << 4) { n += 4; i >>>= 4; }
if (i >= 1 << 2) { n += 2; i >>>= 2; }
return n + (i >>> 1);
}
--
With kind regards,
Ivan Gerasimov
Re: RFR: 8209120: Archive the Integer.IntegerCache
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 Integers using WhiteBox API, WhiteBox.isShared(object) to make
sure that they are archived. Checking all cached Integers is probably
too excessive and unnecessary. Select a few values within [-128, 127]
range would be good enough, I think.
As archived java heap data mapping may fail in some cases at runtime,
and there is no need to continue the test execution when that happens
as it would not exercise any of the archived java objects. The
following can be done at the beginning of CheckIntegerCacheApp:
WhiteBox wb = WhiteBox.getWhiteBox();
if (!wb.areOpenArchiveHeapObjectsMapped()) {
return;
}
thanks for reviewing!
I've added WhiteBox testing as suggested:
http://cr.openjdk.java.net/~redestad/8209120/open.03/
/Claes
Re: [11] RFR: 8209047:"Illegal pattern character 'B'" IllegalArgumentException with Burmese locales
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 introduced in the CLDR time patterns "B HH:mm:ss", "B H:mm" (where B represents the 'day period') for "my" (Burmese) locale. Since, this character is not supported in java.text.SimpleDateFormat and in java.time.DateTimeFormatter, it is throwing IllegalArgumentException. Fix is to change time pattern to previous CLDR's version i.e 29, until 'B' character is supported via JDK-8209175.
RE: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
>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 prefer this .
Best regards, Matthias
> -Original Message-
> From: Sean Mullan
> Sent: Freitag, 10. August 2018 17:39
> To: Baesken, Matthias ; Chris Hegarty
> ; Alan Bateman
> Cc: core-libs-dev@openjdk.java.net; security Dev OpenJDK d...@openjdk.java.net>
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
>
> I need more time to finish my review but here are some initial comments:
>
> - java.security
>
> 1079 # jarpath - enables more detailed information in the IOExceptions
> thrown
>
> Use "jarPath" to be consistent with "hostInfo".
>
> 1080 #by java.util.jar.Attributes and java.util.jar.Manifest
>
> and java.util.jar.JarFile
>
> - Manifest.java
>
> 57 private String jarFilename = null;
>
> Not necessary to set it to null, as that is the default.
>
>82 Manifest(InputStream is, String jarFilename) throws IOException {
>83 this.jarFilename = jarFilename;
>84 read(is);
>85 }
>
> Read from the InputStream and check for error conditions *before*
> setting jarFilename (switch lines 83 & 84). This is a general best
> practice but can also protect against finalizer attacks. See JSCG 7-3
> for more info:
> https://www.oracle.com/technetwork/java/seccodeguide-139067.html#7
>
> - Attributes.java
>
> 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.
>
> --Sean
>
> On 8/8/18 11:00 AM, Sean Mullan wrote:
> > Cross-posting to security-dev since this fix is security related and
> > should also be reviewed there.
> >
> > --Sean
> >
> > On 8/7/18 11:00 AM, Baesken, Matthias wrote:
> >> Ping , any reviews / comments ?
> >>
> >> Thanks , Matthias
> >>
> >>> -Original Message-
> >>> From: Baesken, Matthias
> >>> Sent: Dienstag, 31. Juli 2018 12:28
> >>> To: 'Chris Hegarty' ; Alan Bateman
> >>>
> >>> Cc: core-libs-dev@openjdk.java.net; Lindenmaier, Goetz
> >>> ; Langer, Christoph
> >>>
> >>> Subject: RE: [RFR] 8205525 : Improve exception messages during
> manifest
> >>> parsing of jar archives
> >>>
> >>> Hello ,
> >>> looks like the generalization of the `includeInExceptions`
> >>> security property
> >>> is now in jdk/jdk after
> >>>
> >>> "8207846: Generalize the jdk.net.includeInExceptions security property"
> >>>
> >>> was added, great news and thanks to Chris for driving this !
> >>>
> >>> I use this security property now as well , and updated the change :
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.3/
> >>>
> >>> I updated the CSR as well :
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8207768
> >>>
> >>>
> >>> Best regards, Matthias
> >>>
> >>>
> >>>
> -Original Message-
> From: Chris Hegarty
> Sent: Donnerstag, 19. Juli 2018 14:54
> To: Alan Bateman ; Baesken, Matthias
>
> Cc: core-libs-dev@openjdk.java.net; Lindenmaier, Goetz
>
> Subject: Re: [RFR] 8205525 : Improve exception messages during
> manifest
> parsing of jar archives
>
>
> > On 19 Jul 2018, at 11:46, Alan Bateman
> wrote:
> >
> > On 19/07/2018 09:07, Baesken, Matthias wrote:
> >> Hello, in the meantime I prepared a CSR :
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8207768
> >>
> >>
> >>> jdk.includeInExceptions expands the scope. That might be okay but
> we
> >>> will need to re-visit jdk.net.includeInExceptions and also move the
> >>> support to somewhere in jdk.internal so that it can be used by
> other
> >>> code in java.base.
> >> Is there some support code for " jdk.net.includeInExceptions "
> >> or do
> you just mean the name of the property ?
> >>
> > Chris is right that it's a bit premature to submit a CSR while the
> > question
> >>> on
> whether to rename the existing security property is on the table. I
> have no
> objection to doing that.
>
> I filed the following issue to generalize the `includeInExceptions`
> security
> property:
> https://bugs.openjdk.java.net/browse/JDK-8207846
>
> I would like to resolve 8207846 first, then 8205525 can propose to
> add the
> new argument value, `jarPath`.
>
> -Chris.
Re: RFR 8209171 : Simplify Java implementation of Integer/Long.numberOfTrailingZeros()
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
use -XX:-TieredCompilation -server
---
Now I understand the advantage of using ~i & (i - 1): the subsequent zero
check is a short-circuit for all odd numbers, better than i & -i, which
explains your results - they depend on being able to short-circuit.
So just use a more faithful inlining of nlz without trying to improve on it.
static int ntz_inlineNlz5(int i) {
i = ~i & (i - 1);
if (i <= 0)
return (i == 0) ? 0 : 32;
int n = 1;
if (i >= 1 << 16) { n += 16; i >>>= 16; }
if (i >= 1 << 8) { n += 8; i >>>= 8; }
if (i >= 1 << 4) { n += 4; i >>>= 4; }
if (i >= 1 << 2) { n += 2; i >>>= 2; }
return n + (i >>> 1);
}
But it's hard to resist the urge to optimize out a branch:
static int ntz_inlineNlz6(int i) {
i = ~i & (i - 1);
if (i <= 0) return i & 32;
int n = 1;
if (i >= 1 << 16) { n += 16; i >>>= 16; }
if (i >= 1 << 8) { n += 8; i >>>= 8; }
if (i >= 1 << 4) { n += 4; i >>>= 4; }
if (i >= 1 << 2) { n += 2; i >>>= 2; }
return n + (i >>> 1);
}
Re: RFR: 8209120: Archive the Integer.IntegerCache
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 archived. Checking all cached Integers is probably
too excessive and unnecessary. Select a few values within [-128, 127]
range would be good enough, I think.
As archived java heap data mapping may fail in some cases at runtime,
and there is no need to continue the test execution when that happens
as it would not exercise any of the archived java objects. The
following can be done at the beginning of CheckIntegerCacheApp:
WhiteBox wb = WhiteBox.getWhiteBox();
if (!wb.areOpenArchiveHeapObjectsMapped()) {
return;
}
thanks for reviewing!
I've added WhiteBox testing as suggested:
http://cr.openjdk.java.net/~redestad/8209120/open.03/
/Claes
[11] RFR: 8209047:"Illegal pattern character 'B'" IllegalArgumentException with Burmese locales
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" (where B represents the 'day period') for "my" (Burmese) locale. Since, this character is not supported in java.text.SimpleDateFormat and in java.time.DateTimeFormatter, it is throwing IllegalArgumentException. Fix is to change time pattern to previous CLDR's version i.e 29, until 'B' character is supported via JDK-8209175. -- Thanks, Rachna
Re: RFR8194230, jdk/internal/jrtfs/remote/RemoteRuntimeImageTest.java fails with NPE
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 the settings. Originally it will throw NPE, if specified path is invalid. Bug: https://bugs.openjdk.java.net/browse/JDK-8194230 Webrev: http://cr.openjdk.java.net/~xiaofeya/8194230/webrev.00/ Have you considered merging getJdk8Path and isJdk8 so that it simple checks for the release file and rejects the value of JDK8_HOME when it doesn't exist? I think that should reduce the number of checks and keep it very simple. -Alan
Re: RFR 8209171 : Simplify Java implementation of Integer/Long.numberOfTrailingZeros()
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;
if (i <= 0) return 32 - (i >>> 31);
int n = 0;
if (i >= 1 << 16) { n += 16; i >>>= 16; }
if (i >= 1 << 8) { n += 8; i >>>= 8; }
if (i >= 1 << 4) { n += 4; i >>>= 4; }
if (i >= 1 << 2) { n += 2; i >>>= 2; }
return n + (i >>> 1);
}
Right. The variant numberOfLeadingZeros_01() from the benchmark is very
close to this, though you've got better handling of (i <= 0) case, so I
added it as numberOfLeadingZeros_01a() with a minor modification.
which should save a branch and so should be a benchmark winner.
A reason why delegating to nlz may have beat my previous attempt is
because direct comparison with a constant is an operation the hardware
tries hard to optimize, e.g. branch predict.
Most of the comparisons should be false in practice because "most ints
are small".
I also see that our nlz implementation favors small integers, which
helps with ntz.
It's possible that benchmarking may cause branches to be very highly
predictable. It should be more real-world for each benchmark method
to see a variety of inputs, perhaps in an array.
Okay. Now I tried to combine calculating of several results in one
iteration of benchmark to make it harder to predict branches :)
Surprisingly, this made the variant 05 (reducing to nlz) the leader, for
which I don't have a good explanation, as it does strictly more
calculations than 01 or 01a even after inlining.
Anyways, please find the updated benchmark here:
http://cr.openjdk.java.net/~igerasim/8209171/03/bench/int/MyBenchmark.java
The graphs for -client and -server are here:
http://cr.openjdk.java.net/~igerasim/8209171/03/bench/int/bench-int-03-client.png
http://cr.openjdk.java.net/~igerasim/8209171/03/bench/int/bench-int-03-server.png
It took almost an hour to generate the results, so they seem to be quite
accurate.
So, I'm still inclined to prefer the variant 05 (which is to reduce ntz
to nlz) :)
With kind regards,
Ivan
On Sun, Aug 12, 2018 at 7:22 AM, Ivan Gerasimov
mailto:ivan.gerasi...@oracle.com>> wrote:
Hi Martin!
On 8/11/18 5:54 PM, Martin Buchholz wrote:
Hi Ivan,
Oh the allure of bit-twiddling!
Yes :)
I'm skeptical that ntz should ever delegate to nlz, and not only
because of the overhead of a wrapper, but because small numbers
are more common, and we can take that into account when
implementing ntz.
I was under impression that the more frequently a function is
called the faster it gets compiled, so all the callers of this
function will benefit.
For example, if numberOfTrailingZeros is reduced to
numberOfLeadingZeros then when the later is compiled while the
former is still not, it will still be running faster than the
variant with independent implementations.
At least add "1" to the set of numbers to benchmark.
In the last proposed patch, all odd numbers will be processed via
a fast path (because for any odd i, ~i & (i - 1) == 0).
So, I added 1, 16 and 42 -- small numbers with different number of
trailing zeros.
Here's the updated benchmark:
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/MyBenchmark.java
(I only executed four implementations to keep the picture clear.)
Here's my own entry in this race:
static int ntz(int i) {
if (i == 0) return 32;
int n = 0;
if ((i << 16) == 0) { n += 16; i >>>= 16; }
if ((i & 0xFF) == 0) { n += 8; i >>>= 8; }
if ((i & 0xF) == 0) { n += 4; i >>>= 4; }
if ((i & 0x3) == 0) { n += 2; i >>>= 2; }
return n + (~i & 1);
}
Interesting!
You might also avoid inversion at the end, if n is initialized
with 1, and then the last line may be written as return n - (i & 1).
Still this variant appears to be slower in most tried cases.
Here's the graph of the latest benchmark:
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-02-client.png
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-02-server.png
The variant from the test01 is the fastest in most cases, but I
would prefer to proceed with the variant from test05:
It's only slightly slower than 01, but contains less bytecode and
helps to warm up numberOfLeadingZeros().
Whatever happens, we ought to check in
