Hmmm, 15 entries doesn't seem like a large enough number to drop linear
search. I'd have expected something like 60-80 entries (in some binary vs
linear search benchmarks I've come across, that seems to be crossover
point). It's hard to beat linear search for small sets when the comparison
Hello,
I don't have a comment on the changes to the test per se, but as someone
who keeps an eye on test failures that occur in regression tests in the
jdk repo of the JDK 9 dev forest, I'd like to see this test stop
failing, either by the test being fixed for, barring that, the testing
Hello Peter,
hm not sure what you mean, i was not suggesting the regression is
caused by simpler hashCode bits. (do you mean my comment about the
removed randomizer? that is not a problem for the benchmark, but it
might be an opportunity for DOS (again)).
I think the regression itself is caused
I'm fairly certain that nobody would object if you send a patch with
reproducible benchmark code demonstrating the gain. I think this mostly
comes down to cost/benefit of doing this work, and the benefit is
marginalized out of the gate by virtue of the intrinsic. You'd probably
also have to
Thanks Joe and Lance. do you mind sponsor this for me.
Tristan
On Jan 8, 2015, at 2:54 PM, huizhe wang huizhe.w...@oracle.com wrote:
Thanks for the update. I think the webrev is ready for putback.
Best,
Joe
On 1/7/2015 9:41 PM, Tristan Yan wrote:
Hi Joe/Lance and others.
Please
Hello Vitaly,
the TREEIFY_THRESHOLD in HashMap is 8 (6 for UNTREEIFY). Not sure if
there have been benchmarks for this, I dont see an justification in the
source comments. There is a comment, that it is expected to waste a
factor of two time and space when not compareable.
I would also expect
On 01/08/2015 02:10 PM, Brian Goetz wrote:
1) Validate invariants
A clear and easy to understand mechanism that can validate the
deserialized
fields. Does not prevent the use of final fields, as the
serialization framework
will be responsible for setting them. Something along the
Bernd,
I tried to change the comparableClassFor myself and it didn't work
(HashMap is used very early in boot-up sequence and initializing
ClassValue at that time triggers a NPE).
Anyway, caching of comparableClassFor result would only potentially
improve the badDistWithComp result. But
Thanks for the update. I think the webrev is ready for putback.
Best,
Joe
On 1/7/2015 9:41 PM, Tristan Yan wrote:
Hi Joe/Lance and others.
Please review updated version for this one.
http://cr.openjdk.java.net/~tyan/8051563/webrev.01/
http://cr.openjdk.java.net/%7Etyan/8051563/webrev.01/
Thanks for the info.
So that basically means we have 2 implementations of indexOf currently, one
is in HotSpot, the other is in the JDK itself, which rarely gets executed.
Aside from this later fact, isn't it still worth improving the JDK
implementation if it is possible? I know that the
On 01/08/2015 03:24 AM, David Holmes wrote:
On 7/01/2015 7:45 PM, Remi Forax wrote:
A simple Java question, what this code does ?
ArrayListString list = new ArrayList();
list.add(foo);
list.add(bar);
for(String s: list) {
list.remove(s);
}
:(
Rémi
tip: the bug lies in
On 01/08/2015 03:24 AM, David Holmes wrote:
So don't do that.
Yes, don't. However, it can happen unintentionally and such an exception helps
catch bugs. This can more easily occur when there is some distance between
iterating and operating on the list. So it's about strengthening the
I would not like to add to the overhead of ArrayList's iterator.
Those writing performance-critical code are avoiding the iterator and doing
for (int i = 0, limit = list.size(); i limit; i++) {
E elt = list.get(i);
...
}
On Thu, Jan 8, 2015 at 12:11 AM, Remi Forax fo...@univ-mlv.fr wrote:
Thank you all for participating in this discussion.
Initially a constructor signature for deserialization was proposed to
enforce invariants and encapsulation, however there appears to be
interest in using alternative methods, although they appear to be
improvements over the status quo, I'm
On the matter of writing a ComparatorNumber, the basic problem is
the Number interface is not strong enough to allow you to write such
functionality.
First, the Number type basically only means convertible to a
primitive. There are no strict requirements on consistency between
the
Hello,
Please review this patch, which adds support for building with different
versions of Visual Studio and in particular adds support for VS2013. In
order to control which version to use, I've introduced a new configure
parameter --with-toolchain-version. On windows, this parameter will
Hi Seán,
Thanks for taking care of that :-)
It looks good to me. You might want to set the copyright year to 2015.
Best regards,
-- daniel
On 08/01/15 15:41, Seán Coffey wrote:
I've taken suggested test code from Daniel and am looking to backport
8066612 to jdk7u-dev. The test differs
On Jan 8, 2015, at 3:24 PM, Chris Hegarty chris.hega...@oracle.com wrote:
This is a review request for a small spec clarification to
java.util.stream.Collectors, that appears to be a minor oversight in the
original spec.
Many of the Collectors that accumulate, group, etc, elements into a
On 01/08/2015 02:32 AM, Peter Firmstone wrote:
Thank you all for participating in this discussion.
Initially a constructor signature for deserialization was proposed to
enforce invariants and encapsulation, however there appears to be
interest in using alternative methods, although they appear
On Jan 8, 2015, at 5:06 PM, Chris Hegarty chris.hega...@oracle.com wrote:
On 8 Jan 2015, at 15:46, Paul Sandoz paul.san...@oracle.com wrote:
On Jan 8, 2015, at 3:24 PM, Chris Hegarty chris.hega...@oracle.com wrote:
This is a review request for a small spec clarification to
Peter, David
I would like to see how far we can push the existing Serialization mechanism,
before embarking on a road that may lead us to substantially different one.
Whether that be constructor based, to otherwise ( we know we will need a
replacement for Unsafe.allocateInstance, for
This is a review request for a small spec clarification to
java.util.stream.Collectors, that appears to be a minor oversight in the
original spec.
Many of the Collectors that accumulate, group, etc, elements into a Collection,
and do not accept a Collection supplier, come with a caveat on the
I've taken suggested test code from Daniel and am looking to backport
8066612 to jdk7u-dev. The test differs slightly in that it used the
non-lambda approach (ClassNameListBuilder)
I've reduced the number of run counts also (one ovm run for secure and
one for non-secure mode) - As a result
Hello,
I think it was topic before, but I just wanted to point out, that it is
still an topic on the internetz. :)
Motivated by a StackOverflow question regarding HashMap performance
regression in Java 8
http://stackoverflow.com/questions/27759527/using-java-7-hashmap-in-java-8/27760442
I made
On 8 Jan 2015, at 15:46, Paul Sandoz paul.san...@oracle.com wrote:
On Jan 8, 2015, at 3:24 PM, Chris Hegarty chris.hega...@oracle.com wrote:
This is a review request for a small spec clarification to
java.util.stream.Collectors, that appears to be a minor oversight in the
original spec.
Interesting observations.
The class description of HashMap in Java SE 8 alludes to the behaviour you are
seeing with respect to Comparable keys.
Note that using many keys with the same hashCode() is a sure way to slow
down performance of any hash table. To ameliorate impact, when keys are
Hi Bernd,
It seems that only bad hash codes (without comparable keys) in JDK8 HM
are worse than JDK7 HM.
Since you have already taken time to measure JDK7 vs JDK8 HM, could you
try to take the JDK8 source and just replace the internal
comparableClassFor method with the following
1) Validate invariants
A clear and easy to understand mechanism that can validate the deserialized
fields. Does not prevent the use of final fields, as the serialization
framework
will be responsible for setting them. Something along the lines of what
David
suggested:
Hello Peter,
yes it is only keys without an Compareable interface, but they are
quite common. I think the main problem with the internal comparator
(based on instance identity) is, that it would work for looking up the
same instance again, but not for the case where the actual instance is
On Thursday 08 January 2015 20:41:20 Bernd Eckenfels wrote:
Hello Peter,
yes it is only keys without an Compareable interface, but they are
quite common. I think the main problem with the internal comparator
(based on instance identity) is, that it would work for looking up the
same
Hi,
Thanks everyone for all the info.
So, just to go step by step in understanding this.
Andrew said HotSpot would ignore my implementation. So why is there an
implementation of indexOf at all in the JDK, if that's not the code that's
executed? Is it just a default fallback? When is the indexOf
The java impl you saw would be called by (a) interpreter, (b) if you
explicitly disable intrinsification of this function, or (c) some other JVM
that doesn't intrinsify this method (or any method).
People don't usually disable intrinsics; if they do, it's because they hit
some JIT bug and may
32 matches
Mail list logo
