On 07/12/2014 10:46 PM, Ivan Gerasimov wrote:
Peter, seems you need to fix capacity():
int capacity = Integer.highestOneBit(expectedMaxSize + (expectedMaxSize << 1));
does not necessarily produces a negative number in the case of overflow.
Good catch. You're right.
Why don't you want to use
Hi,
please review this patch to expose formatUnsignedInt/-Long through
JavaLangAccess.
webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/
bug: https://bugs.openjdk.java.net/browse/JDK-8050114
The behavior of the methods have been adjusted to be zero-padding in
case the number
Peter, seems you need to fix capacity():
int capacity = Integer.highestOneBit(expectedMaxSize + (expectedMaxSize << 1));
does not necessarily produces a negative number in the case of overflow.
Why don't you want to use the variant that from the latest Martin's webrev?
It seems to work correctl
On 07/12/2014 08:12 PM, Peter Levart wrote:
(3 * size < 2 * highestOneBit(3*size)) is true for any size, so IHM
will never be resized if filled with size elements and table was
preallocated with length =
2 * highestOneBit(3*size) even if condition for resizing is changed
from (3*size > length)
On 07/12/2014 08:12 PM, Peter Levart wrote:
If we're willing to pay the price of special-casing the non-power-of-2
MAX_CAPACITY = (1 << 29) + (1 << 28), which amounts to approx. 4% of
performance,
The cause of performance drop is of course the conditional in:
297 private static int hash
On 07/12/2014 05:47 PM, Peter Levart wrote:
If we're willing to pay the price of special-casing the non-power-of-2
MAX_CAPACITY = (1 << 29) + (1 << 28), which amounts to approx. 4% of
performance,
Then here's a possible solution:
http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/w
I played with this some years ago. Doesn't it just become recursive,
because it won't inline through the dynamicInvoker?
- Charlie (mobile)
On Jul 12, 2014 9:36 AM, "Remi Forax" wrote:
> It seems that the JIT is lost with whe there is a loopy callsite and never
> stabilize (or the steady state i
On 07/11/2014 09:08 PM, Doug Lea wrote:
I've been content to just observe Martin and Peter's nice efforts
on this, but one note:
On 07/11/2014 03:00 PM, Martin Buchholz wrote:
On Wed, Jul 9, 2014 at 3:17 PM, Peter Levart
wrote:
IMH resizing is arranged so that the table is always 33% ...
I was not able to find the answer to my question in the archive,
why Stream.concat is not implemented like this ?
@SafeVarargs
public static Stream concat(Stream... streams) {
return Arrays.stream(streams).flatMap(Function.identity());
}
Rémi
http://cr.openjdk.java.net/~prr/8049892.1/
On Fri, Jul 11, 2014 at 6:41 AM, Pavel Rappo wrote:
> Hi Otavio,
>
> Other than things already spotted by Andrej, the change looks good to me.
> Thank you for doing this.
>
> -Pavel
>
> On 11 Jul 2014, at 02:36, Otávio Gonçalves de Santana <
> otaviopo
It seems that the JIT is lost with whe there is a loopy callsite and
never stabilize (or the steady state is after the program ends).
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
import java.lang.invoke.MutableCallSite;
public
11 matches
Mail list logo
