Looks fine to me. Thanks!
Xuelei
On 9/22/2016 4:05 PM, Jamil Nimeh wrote:
That's a very good suggestion. I've made that change and updated the
webrev:
http://cr.openjdk.java.net/~jnimeh/reviews/8049516/webrev.02/
Thanks again,
--Jamil
On 09/21/2016 05:34 PM, Xuelei Fan wrote:
> latch = (l
That's a very good suggestion. I've made that change and updated the
webrev:
http://cr.openjdk.java.net/~jnimeh/reviews/8049516/webrev.02/
Thanks again,
--Jamil
On 09/21/2016 05:34 PM, Xuelei Fan wrote:
> latch = (latch + 1) & 0x7FFF; // Mask the sign bit
I'm fine with it.
BTW, if you
> On Sep 22, 2016, at 8:34 AM, Xuelei Fan wrote:
>
> > latch = (latch + 1) & 0x7FFF; // Mask the sign bit
> I'm fine with it.
>
> BTW, if you like, I may suggest to use a little bit small number for the
> mask, for example 0x1FFF, so that the counter variable does not overflow
> eith
> latch = (latch + 1) & 0x7FFF; // Mask the sign bit
I'm fine with it.
BTW, if you like, I may suggest to use a little bit small number for the
mask, for example 0x1FFF, so that the counter variable does not
overflow either. It works if counter overflow, but better not if we
want the
So here are a couple ideas related to your suggestion.
We can leave a simple increment on latch and let it overflow, then in
the array access do this:
v ^= rndTab[(latch & 0x7FFF) % 255];
That clears the high order bit and the mod will keep it in the range of
0-254. the lvalue for the m
Unfortunately not just with a straight "latch & 0xff" because the rndTab
array is 255 bytes, so every time latch is a multiple of 255 you end up
out of bounds. It would work if we could add a 256th byte to the
array. The comments suggest that there is an even statistical
distribution of the v
I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a little
difficult to understand. Does rndTab[latch & 0xff] also work?
Thanks
Max
> On Sep 21, 2016, at 11:57 PM, Jamil Nimeh wrote:
>
> Hi Max and Xuelei,
>
> Yesterday I also reached out to the SQE engineer who submitted
Hi Max and Xuelei,
Yesterday I also reached out to the SQE engineer who submitted the bug,
asking if this is an issue he's seen going forward from the original
instance in 8u20. He said that he hasn't seen this issue come up since
the original bug submission. Since the simple overflow condit
Hi Max and Xuelei, thanks for the feedback.
On 09/20/2016 07:52 PM, Wang Weijun wrote:
On Sep 21, 2016, at 9:58 AM, Xuelei Fan wrote:
359 while (System.nanoTime() - startTime < 25000) {
360 synchronized(this){};
- 361 latch++;
+ 361 latch = (latch + 1) % Integer.MA
> On Sep 21, 2016, at 9:58 AM, Xuelei Fan wrote:
>
> 359 while (System.nanoTime() - startTime < 25000) {
> 360 synchronized(this){};
> - 361 latch++;
> + 361 latch = (latch + 1) % Integer.MAX_VALUE;
> 362 }
>
> This block may be not CPU friendly as it may loop a lar
359 while (System.nanoTime() - startTime < 25000) {
360 synchronized(this){};
- 361 latch++;
+ 361 latch = (latch + 1) % Integer.MAX_VALUE;
362 }
This block may be not CPU friendly as it may loop a large amount of
times in a very short period (250milli).
What's
11 matches
Mail list logo
