- Mail original -
> De: "Claes Redestad"
> À: "Roger Riggs" , "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Vendredi 14 Juillet 2017 20:40:25
> Objet: Re: [10] RFR: 8184665: Skip name and alias checks for standard Charsets
> Hi,
>
> in this case the code isn't really fragile, since two
Hi,
in this case the code isn't really fragile, since two equal but not
identical Strings will end up with the same Charset, so there's no
*real* surprises to be had (only a tiny performance loss that isn't
really consequential except for startup).
So: I did use == mostly to be consistent with S
Hi Remi,
Point taken about consistency.
I'm concerned about code that is unnecessarily fragile due to
unnecessary and unexpected optimizations.
$.02, Roger
On 7/14/2017 2:01 PM, Remi Forax wrote:
I do not like the equals in the constructor of Charset given that in
StandardCharsets, == is u
I do not like the equals in the constructor of Charset given that in
StandardCharsets, == is used.
I think the constructor of Charset should use == and a comment should be added
explaining why it's valid to use == like in StandardCharsets.
cheers,
Rémi
- Mail original -
> De: "Roger Ri
Hi Claes,
The change looks fine.
The only concern is that, in theory, it appears we no longer have any "check"
to guarantee that all "alias" names defined for these 3 charsets indeed follow
the spec? The consequence of this is that someone can obtain the alias name
from the specific "charset", a
Looks fine,
Thanks, Roger
On 7/14/2017 1:30 PM, Naoto Sato wrote:
Hello,
Please review this trivial doc fix to java.time classes. The issue is:
https://bugs.openjdk.java.net/browse/JDK-8184314
And the proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8184314/webrev.00/
Na
Hello,
Please review this trivial doc fix to java.time classes. The issue is:
https://bugs.openjdk.java.net/browse/JDK-8184314
And the proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8184314/webrev.00/
Naoto
+1,
Thanks, Roger
On 7/14/2017 1:03 PM, Claes Redestad wrote:
Hi Roger,
On 2017-07-14 18:25, Roger Riggs wrote:
Hi Claes,
Using == with references always looks a bit suspicious in the source
code, especially strings.
Since the first thing in equals() is the identity check, I'd suggest
usin
Hi Roger,
On 2017-07-14 18:25, Roger Riggs wrote:
Hi Claes,
Using == with references always looks a bit suspicious in the source
code, especially strings.
Since the first thing in equals() is the identity check, I'd suggest
using .equals for the comparisons.
Sure, there's no significant per
> On Jul 14, 2017, at 12:15 PM, Volker Simonis wrote:
>
> Hi Bob,
>
> thanks for starting this JEP. I think it is long overdue and will be
> very helpful for many people.
>
Thanks for taking a look at the JEP.
> That said, I don't see any mentioning of the targeted Java release. As
> JEPs usu
Hi Claes,
Using == with references always looks a bit suspicious in the source
code, especially strings.
Since the first thing in equals() is the identity check, I'd suggest
using .equals for the comparisons.
Roger
On 7/14/2017 8:52 AM, Claes Redestad wrote:
Hi,
by special-casing the three
Hi Bob,
thanks for starting this JEP. I think it is long overdue and will be
very helpful for many people.
That said, I don't see any mentioning of the targeted Java release. As
JEPs usually go into the development version first, I suppose the work
for this JEP will be done in JDK10. However, tak
On 2017-07-14 17:57, Roger Riggs wrote:
Hi,
Looks fine to me also.
Thanks, Roger!
/Claes
Hi,
Looks fine to me also.
Thanks, Roger
On 7/14/2017 11:34 AM, Claes Redestad wrote:
On 2017-07-14 17:26, Chris Hegarty wrote:
http://cr.openjdk.java.net/~redestad/8184603/jdk.02/
This version looks good to me.
Thanks, Chris!
Can you please add a link to this review thread to the bug
On 2017-07-14 17:26, Chris Hegarty wrote:
http://cr.openjdk.java.net/~redestad/8184603/jdk.02/
This version looks good to me.
Thanks, Chris!
Can you please add a link to this review thread to the bug ( for future
archaeologists ).
Done.
/Claes
On 07/14/2017 05:30 PM, Aleksey Shipilev wrote:
> Maybe we should drop "null" stores in constructors, and instead rely on
> default
> values for them, since we are talking startup performance here where
> optimizing
> compilers have not yet got their chance.
Sorry, those are the stores to final
On 07/14/2017 05:24 PM, Claes Redestad wrote:
>>> http://cr.openjdk.java.net/~redestad/8184603/jdk.02/
>> I think this is fine from concurrency standpoint. Not sure how safe it is to
>> increase OSF footprint, that's your call! I also think the largest
>> improvement
>> would be from avoiding the
> On 14 Jul 2017, at 15:12, Claes Redestad wrote:
>
> On 2017-07-14 15:46, Aleksey Shipilev wrote:
>> On 07/14/2017 03:40 PM, Claes Redestad wrote:
>>> signature is already made volatile in this patch, deliberately to ensure
>>> that
>>> for the private constructors we keep correctness:
>>>
>>
On 2017-07-14 16:22, Aleksey Shipilev wrote:
On 07/14/2017 04:12 PM, Claes Redestad wrote:
Thing is, "volatile" is not as strong as "final" for racy initializations:
https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals
If that is not a concern -- e.g. if
I’d like to propose the following JEP that will enhance the Java runtime to be
more container aware.
This will allow the Java runtime to performance better ergonomics and provide
better
execution time statistics when running in a container.
JEP Issue:
https://bugs.openjdk.java.net/browse/JD
On 07/14/2017 04:12 PM, Claes Redestad wrote:
>> Thing is, "volatile" is not as strong as "final" for racy initializations:
>>
>> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals
>>
>>
>> If that is not a concern -- e.g. if private constructor is never used
On 2017-07-14 15:46, Aleksey Shipilev wrote:
On 07/14/2017 03:40 PM, Claes Redestad wrote:
signature is already made volatile in this patch, deliberately to ensure that
for the private constructors we keep correctness:
in these private constructors, the signature field is initialized in the
c
On 07/14/2017 03:40 PM, Claes Redestad wrote:
> signature is already made volatile in this patch, deliberately to ensure that
> for the private constructors we keep correctness:
>
> in these private constructors, the signature field is initialized in the
> constructor (we can assert that it's non-
On 2017-07-14 15:04, Alan Bateman wrote:
On 14/07/2017 13:47, Claes Redestad wrote:
http://cr.openjdk.java.net/~redestad/8184603/jdk.01/
The updated version looks okay. I would probably do "signature = sig =
getClassSignature(...)" but it shouldn't make a difference.
Thanks Alan, I believ
Hi Aleksey,
On 2017-07-14 15:33, Aleksey Shipilev wrote:
On 07/14/2017 03:25 PM, Aleksey Shipilev wrote:
On 07/14/2017 02:47 PM, Claes Redestad wrote:
For extra points remove the superfluous null assignment of
`signature` and `field` ( as well as `offset` ).
'field' is final so that'd make ja
On 07/14/2017 03:25 PM, Aleksey Shipilev wrote:
> On 07/14/2017 02:47 PM, Claes Redestad wrote:
>>> For extra points remove the superfluous null assignment of
>>> `signature` and `field` ( as well as `offset` ).
>>
>> 'field' is final so that'd make javac cry bloody murder, but I fixed the
>> rest
On 07/14/2017 02:47 PM, Claes Redestad wrote:
>> For extra points remove the superfluous null assignment of
>> `signature` and `field` ( as well as `offset` ).
>
> 'field' is final so that'd make javac cry bloody murder, but I fixed the
> rest and cleaned up a bit for consistency:
>
> http://cr.o
On 14/07/2017 13:47, Claes Redestad wrote:
:
For extra points remove the superfluous null assignment of
`signature` and `field` ( as well as `offset` ).
'field' is final so that'd make javac cry bloody murder, but I fixed the
rest and cleaned up a bit for consistency:
http://cr.openjdk.ja
Hi,
by special-casing the three Charsets we always load on startup in the
Charset
constructor we can avoid some superfluous checks and get a tiny startup
improvement (~7k less bytecode executed, which is fast approaching 1% of
total
on minimal startup tests).
Webrev: http://cr.openjdk.java.n
On 2017-07-14 14:32, Chris Hegarty wrote:
On 14 Jul 2017, at 13:19, Claes Redestad wrote:
Hi,
as a small startup optimization, we could make some setup in ObjectStreamField
lazier by calculating the signature field at first use.
Bug: https://bugs.openjdk.java.net/browse/JDK-8184603
Webrev: h
> On 14 Jul 2017, at 13:19, Claes Redestad wrote:
>
> Hi,
>
> as a small startup optimization, we could make some setup in ObjectStreamField
> lazier by calculating the signature field at first use.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8184603
> Webrev: http://cr.openjdk.java.net/
Hi,
as a small startup optimization, we could make some setup in
ObjectStreamField
lazier by calculating the signature field at first use.
Bug: https://bugs.openjdk.java.net/browse/JDK-8184603
Webrev: http://cr.openjdk.java.net/~redestad/8184603/jdk.00/
Thanks!
/Claes
> On Jul 14, 2017, at 4:26 PM, Weijun Wang wrote:
>
>
>> On Jul 14, 2017, at 4:23 PM, Mandy Chung wrote:
>>
>>
>>> On Jul 13, 2017, at 5:14 PM, Amy Lu wrote:
>>>
>>> java/lang/ClassLoader/deadlock/TestCrossDelegate.sh
>>> java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh
>>>
>>> Please
> On Jul 14, 2017, at 4:23 PM, Mandy Chung wrote:
>
>
>> On Jul 13, 2017, at 5:14 PM, Amy Lu wrote:
>>
>> java/lang/ClassLoader/deadlock/TestCrossDelegate.sh
>> java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh
>>
>> Please review this patch to refactor the shell tests to java.
>>
>> bug
> On Jul 13, 2017, at 5:14 PM, Amy Lu wrote:
>
> java/lang/ClassLoader/deadlock/TestCrossDelegate.sh
> java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh
>
> Please review this patch to refactor the shell tests to java.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8183377
> http://cr.op
35 matches
Mail list logo
