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
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
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
On 12 January 2015 at 11:36, Daniel Fuchs daniel.fu...@oracle.com 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
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
On 12/01/15 13:49, Stephen Colebourne wrote:
On 12 January 2015 at 12:00, Daniel Fuchs daniel.fu...@oracle.com 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
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
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
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 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
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() (existing
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
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
On 12 January 2015 at 12:00, Daniel Fuchs daniel.fu...@oracle.com 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
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
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 vladimir.x.iva...@oracle.com
wrote:
Paul,
Thanks for the review!
Look good, +1,
Paul.
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8067344/webrev.02
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
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
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 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
Am 12.01.2015 um 17:15 schrieb Stephen Colebourne scolebou...@joda.org:
On 12 January 2015 at 11:37, Chris Hegarty chris.hega...@oracle.com 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
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 :-)
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
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 ulf.zi...@gmx.de wrote:
Am 12.01.2015 um 20:42 schrieb
Am Mon, 12 Jan 2015 15:31:24 -0800
schrieb Xueming Shen xueming.s...@oracle.com:
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,
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
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
- 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 can do
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
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
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
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 all
On 12 January 2015 at 11:37, Chris Hegarty chris.hega...@oracle.com 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
On Jan 12, 2015, at 7:06 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
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
34 matches
Mail list logo
