On 12/01/2015 10:00 PM, Daniel Fuchs wrote:
On 12/01/15 03:20, David Holmes wrote:
Hi Daniel,
Looking at the hotspot part ...
On 10/01/2015 2:56 AM, Daniel Fuchs wrote:
Hi David,
[...]
http://cr.openjdk.java.net/~dfuchs/webrev_8068730/webrev.00/
Some more details on the patch:
native (h
- Original message -
> On 10/01/15 07:00, Peter Firmstone wrote:
> > Again, thank you all for engaging in discussion of this very difficult
> > topic.
> >
> > While we can't presently check intra object dependencies during
> > deserialization with readObject(), the examples I provide
Overall, I'm very happy with the way that Doug's heroic treebinization
project worked out - we have expected O(1) and worst case O(log N) when
trees are possible.
I didn't consider the problem of not hurting iterator performance. I might
consider having the iterator read-ahead all the elements in
Am Mon, 12 Jan 2015 15:31:24 -0800
schrieb Xueming Shen :
> We do have map based cache in standard and extended charset provider
> implementation already. The standard version is prehashedmap based, it
> probably should be fast enough. The extended version is a treemap
> based, which probably is s
Hello,
I see typical use of "ASCII", "ISO88591", "UTF8" and then the 1-2
platform/filename encodings in case of Windows (ANSI+OEM). That makes at least 5
commonly used ones (not sure about UTF-16((BL)E) internally?).
And this hopes, that all charsets are not used by any of their aliases.
But of
We do have map based cache in standard and extended charset provider
implementation already. The standard version is prehashedmap based, it
probably should be fast enough. The extended version is a treemap based,
which probably is slow.
I'm a little surprised that the 2-elements cache in Charset
I don't disagree about 3 elements in the cache being better than 2.
When I implemented this crappy cache, it was all about "2 is better than 1".
Yeah, maybe we could get a "real" cache someday...
On Mon, Jan 12, 2015 at 1:26 PM, Ulf Zibis wrote:
>
> Am 12.01.2015 um 20:42 schrieb Martin Buchholz
These String literals may be replaced by equivalent character literals[1],
gaining some performance enhancement.
Webrev:
https://dl.dropboxusercontent.com/u/16109193/open_jdk/jdk/index_of_character/index.html
[1]
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.SECONDS)
public class IndexOfBenchmar
Hi,
I added results obtained with JDK 8 (FCS and u20) - same machine, same
VM options, just different JDKs:
Original JDK 7 HashMap (and JVM):
Benchmark (initialSize) Mode
SamplesScore Score errorUnits
j.t.HashMapCollision.badDistNoComp
Hi Daniel,
Looks fine, a great enhancement.
Thanks, Roger
On 1/12/2015 12:17 PM, Daniel Fuchs wrote:
...
Ah! That's a good one. 'windows_to_time_ticks' I like this better :-)
Here is the new webrev. Testing on windows went well :-)
http://cr.openjdk.java.net/~dfuchs/webrev_8068730/webrev.02
Am 12.01.2015 um 20:42 schrieb Martin Buchholz:
Historical notes:
I added the two-element cache many years ago, assuming that code that
repeatedly accessed more than 2 charsets would be rare.
I suspect this opinion, see:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6795535
-Ulf
Hi Pavel,
I would like to help on some open Issues that needed being solved. Should I
apply the transferTo method on the existing codebase, where possible? Or what
would be a issue that need some attention?
-Patrick
> Am 12.01.2015 um 17:15 schrieb Stephen Colebourne :
>
> On 12 January 2015 at 11:37, Chris Hegarty wrote:
>> For clarity, I would like to describe how things currently work.
>>
>> 1) Allocate a new instance of the deserialized type.
>> 2) Call the first non-Serializable types no-arg construct
If there's a clean improvement in the java code, it's worth putting in.
You can try benchmarking with -Xint.
Are we talking about this method?
static int indexOf(char[] source, int sourceOffset, int sourceCount,
char[] target, int targetOffset, int targetCount,
int from
Historical notes:
I added the two-element cache many years ago, assuming that code that
repeatedly accessed more than 2 charsets would be rare.
I have been hoping for a high-quality cache implementation to be added to
the JDK, perhaps via guava, and to use that in places like Charset.
I agree th
Thanks, Paul!
Best regards,
Vladimir Ivanov
On 1/12/15 9:42 PM, Paul Sandoz wrote:
On Jan 12, 2015, at 7:06 PM, Vladimir Ivanov
wrote:
Paul,
Thanks for the review!
Look good, +1,
Paul.
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8067344/webrev.02
70 TestMethod
Hello,
I see some strange scalability problem in an application which uses a
few exernal Charsets which are provided by ServiceLoader. When I check
the code for Charset.forName()/lookup() I can the 2-entry LRU cache for
charsets, and if those caches do not find the charset, it will check
standard,
On Jan 12, 2015, at 7:06 PM, Vladimir Ivanov
wrote:
> Paul,
>
> Thanks for the review!
>
Look good, +1,
Paul.
> Updated webrev:
> http://cr.openjdk.java.net/~vlivanov/8067344/webrev.02
>
>> 70 TestMethods testCase = getTestMethod();
>> 71 if (testCase == TestMetho
Paul,
Thanks for the review!
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8067344/webrev.02
70 TestMethods testCase = getTestMethod();
71 if (testCase == TestMethods.EXACT_INVOKER || testCase ==
TestMethods.INVOKER) {
72 // Invokers ar
On 12/01/15 15:41, Daniel Fuchs wrote:
On 12/01/15 13:49, Stephen Colebourne wrote:
On 12 January 2015 at 12:00, Daniel Fuchs
wrote:
I'm not a big fan of the current name either.
I would gladly rename it. I did think of
windows_to_java_time_micros, but it actually returns tenth of
micros - so
On 12 January 2015 at 11:37, Chris Hegarty wrote:
> For clarity, I would like to describe how things currently work.
>
> 1) Allocate a new instance of the deserialized type.
> 2) Call the first non-Serializable types no-arg constructor
> ( may be j.l.Object ).
> 3) For each type in the dese
On 10/01/15 07:00, Peter Firmstone wrote:
Again, thank you all for engaging in discussion of this very difficult
topic.
While we can't presently check intra object dependencies during
deserialization with readObject(), the examples I provide can do this.
I have replied to Davids mail with a sm
On 01/12/2015 05:51 AM, Chris Hegarty wrote:
On 08/01/15 22:03, David M. Lloyd wrote:
private static void validate(GetField fields) {
if (fields.getInt("lo") > fields.getInt("hi")) { ... }
}
...
In fact you cannot validate invariants across multiple objects at
On 12/01/15 13:49, Stephen Colebourne wrote:
On 12 January 2015 at 12:00, Daniel Fuchs wrote:
I'm not a big fan of the current name either.
I would gladly rename it. I did think of
windows_to_java_time_micros, but it actually returns tenth of
micros - so it would be lying...
Is there a good nam
Hello, Chris
You have asked "Have you seen NetworkInterface.getName() return names
with ‘_’, ’.’, or ‘:’ ,or is this theoretical?"
I can answer your question. I have named one of network interfaces on my
Linux desktop like "eth0.1_55".
ifconfig says:
eth0.1_55 Link encap:Ethernet HWaddr 08
On 12 January 2015 at 12:00, Daniel Fuchs wrote:
> I'm not a big fan of the current name either.
> I would gladly rename it. I did think of
> windows_to_java_time_micros, but it actually returns tenth of
> micros - so it would be lying...
> Is there a good name for 'tenth of micros'?
.NET refers
Hi everyone!
May I assume the last webrev is good to go?
- It uses static final in the if clause, so that the additional code is
eliminated on Unix;
- Quotation marks are used as new delimiter, so it's impossible for them
to collide with whatever is found in the property value;
- The last loop
On 01/12/2015 01:03 PM, Ivan Gerasimov wrote:
On 31.12.2014 16:26, Lev Priima wrote:
Thanks Ivan!
I've updated: http://cr.openjdk.java.net/~lpriima/8067471/webrev.05/.
I would say I'm Okay with the latest variant, if the performance team
doesn't have any objections.
No objection from me,
On 01/12/2015 03:26 AM, Peter Levart wrote:
Did bit smearing function used in JDK 7 have negative impact on any hashCodes or
was it replaced with simpler one just because it is not needed when tree bins
are used?
I don't have detailed records, but in pre-release jdk8 tests, smearing was
detecta
On 31.12.2014 16:26, Lev Priima wrote:
Thanks Ivan!
I've updated: http://cr.openjdk.java.net/~lpriima/8067471/webrev.05/.
I would say I'm Okay with the latest variant, if the performance team
doesn't have any objections.
Sincerely yours,
Ivan
Best Regards,
Lev
On 12/01/15 03:20, David Holmes wrote:
Hi Daniel,
Looking at the hotspot part ...
On 10/01/2015 2:56 AM, Daniel Fuchs wrote:
Hi David,
[...]
http://cr.openjdk.java.net/~dfuchs/webrev_8068730/webrev.00/
Some more details on the patch:
native (hotspot) side:
- adds a new method to the o
On 08/01/15 22:03, David M. Lloyd wrote:
private static void validate(GetField fields) {
if (fields.getInt("lo") > fields.getInt("hi")) { ... }
}
...
In fact you cannot validate invariants across multiple objects at all
using this method *or* readObject() (exis
On 12 January 2015 at 11:36, Daniel Fuchs wrote:
>> In java.time.Instant, a readObject() has been added. However, I don't
>> believe this will ever be called because Instant has a writeReplace()
>> method and so is not deserialized. (There may be some security related
>> "evil serialization stream
Erik:
Looks good to me. Thanks for picking this up - I struggled with the
problem for months.
Tim
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 int
On 09/01/15 19:26, Stephen Colebourne wrote:
Well that is a nice surprise ;-) And I think the implementation via an
adjustment is very sensible.
Thanks Stephen :-)
In java.time.Instant, a readObject() has been added. However, I don't
believe this will ever be called because Instant has a wri
On 08/01/15 20:10, 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 lines
On 01/09/2015 05:12 PM, Alan Bateman wrote:
webrev: http://cr.openjdk.java.net/~redestad/8068498/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-8068498
This looks good to me and the behavior change looks reasonable for a
major release.
Thanks! I was expecting some opposition, but I g
Hi Kumar,
I've updated patch with your comments.
http://cr.openjdk.java.net/~anazarov/8067437/webrev.02/
Also see comments inline.
Thank you for review.
On 23.12.2014 18:28, Kumar Srinivasan wrote:
Missed clarifying this, I will be sponsoring this patch.
Kumar
On 12/23/2014 7:26 AM, Kumar Sr
On 01/12/2015 12:26 AM, Peter Levart wrote:
With tree bins we don't need heavy bit-smearing to get decent
performance in speed, but the table gets quite sparse anyway (although
this is the smaller of the space overheads - tree nodes are bigger).
For example, for 1M integral Floats, we get the f
39 matches
Mail list logo
