Now we have a issue id
issue: https://bugs.openjdk.java.net/browse/JDK-8151481
webrev: http://cr.openjdk.java.net/~sherman/8151481/webrev
thanks,
sherman
btw, the patter inside [...] no longer be "printable", they are
"function" now.
On 3/8/16 9:45 AM, Xueming Shen wrote:
Hi,
While waiting
On 10/03/2016 12:42 PM, Ivan Krylov wrote:
Hi David,
I looked around for more examples and adopted both of your suggestions.
New javadoc (should look like the one before except for the horizontal
line)
http://cr.openjdk.java.net/~ikrylov/8147844.doc.01/java/lang/Thread.html#onSpinWait--
I rep
Hi David,
I looked around for more examples and adopted both of your suggestions.
New javadoc (should look like the one before except for the horizontal line)
http://cr.openjdk.java.net/~ikrylov/8147844.doc.01/java/lang/Thread.html#onSpinWait--
I replaced the webrev in place again:
http://cr
I thought it was there to prevent loads after the call from moving before
it, such as when loop is unrolled. That type of motion would defeat (some
of) the purpose.
But ok, your call. The javadoc is a bit vacuous (purposely) so wasn't sure
if mentioning ordering is appropriate or not, even if to
To me this is an implementation detail that could change. The barrier is
there to prevent the intrinsic to be hoisted.
Thanks,
Ivan
On 09/03/2016 17:50, Vitaly Davidovich wrote:
Is it worthwhile to mention ordering effects? In particular, I believe
there's a compiler barrier preventing movin
Is it worthwhile to mention ordering effects? In particular, I believe
there's a compiler barrier preventing moving ops before the call. Not sure
if this needs any attention in the javadoc.
On Wednesday, March 9, 2016, Ivan Krylov wrote:
> I have added a little example that hopefully explains f
Hi Ivan,
On 10/03/2016 8:26 AM, Ivan Krylov wrote:
I have added a little example that hopefully explains for the new method
is for
JavaDoc:
http://cr.openjdk.java.net/~ikrylov/8147844.doc.00/java/lang/Thread.html#onSpinWait--
I replaced the webrev in place:
http://cr.openjdk.java.net/~ikrylov/
I have added a little example that hopefully explains for the new method
is for
JavaDoc:
http://cr.openjdk.java.net/~ikrylov/8147844.doc.00/java/lang/Thread.html#onSpinWait--
I replaced the webrev in place:
http://cr.openjdk.java.net/~ikrylov/8147844.jdk.03
Thanks,
Ivan
On 07/03/2016 17:4
Hi Mandy, Chris, Kim, Roger and others,
Hearing no objections for a day, two Reviewers saying it looks ok and
successfully re-running the tests, I pushed webrev.07.part1 to jdk9-dev.
Thanks for reviews and comments.
Now to the 2nd part...
On 03/07/2016 07:35 PM, Mandy Chung wrote:
...
And
The fix/workaround itself looks fine. My concern is that even the native
inflater does increase its usage a little, but it seems like the "real" root
cause is that someone's code (out of the core-libs) uses the inflater without
releasing it AND the finalizer is not faster enough to finalize/releas
On 03/09/2016 06:14 PM, Xueming Shen wrote:
On 3/9/16 7:58 AM, Peter Levart wrote:
P.S.
Do you happen to know why String.compareToIgnoreCase /
CASE_INSENSITIVE_ORDER is defined to compare characters transformed
through the following function:
Character.toLowerCase(Character.toUpperCase(c
Looks OK Eric
Best
Lance
On Mar 8, 2016, at 8:40 PM, Eric Guo wrote:
> Hi Lance,
>
> Could you please help me to review these change?
> Thanks in advance!
>
> Best Regards,
> Eric
>
> Original Message
> Received: from userv0021.oracle.com (/156.151.31.71) by default (Ora
Hi Langer,
Thanks for the update. I'll do an all-test run. I'm okay with the
TransformerTest, although it can be better. For the license header, I
meant to say the whole header that includes updating the Apache License
to its new format. You may update the webrev if you want. Otherwise, I
c
On 3/9/16 7:58 AM, Peter Levart wrote:
P.S.
Do you happen to know why String.compareToIgnoreCase /
CASE_INSENSITIVE_ORDER is defined to compare characters transformed
through the following function:
Character.toLowerCase(Character.toUpperCase(character))
...and not simply:
Character.toLow
On 03/09/2016 05:10 PM, Claes Redestad wrote:
On 2016-03-09 16:58, Peter Levart wrote:
Can this really happen? ASCIICaseInsensitiveComparator was asserting
that
string characters were ASCII, so this situation would have triggered
an assert
with the old code, no?
If assertions were..
St
On 9 Mar 2016, at 16:10, Claes Redestad wrote:
>
> On 2016-03-09 16:58, Peter Levart wrote:
>>> Can this really happen? ASCIICaseInsensitiveComparator was asserting that
>>> string characters were ASCII, so this situation would have triggered an
>>> assert
>>> with the old code, no?
>>
>> If a
On 2016-03-09 16:58, Peter Levart wrote:
Can this really happen? ASCIICaseInsensitiveComparator was asserting
that
string characters were ASCII, so this situation would have triggered
an assert
with the old code, no?
If assertions were..
Stahp! Attributes.Name constructor validates that a
On 03/09/2016 04:30 PM, Chris Hegarty wrote:
On 9 Mar 2016, at 14:43, Peter Levart wrote:
On 03/09/2016 02:44 PM, Chris Hegarty wrote:
On 9 Mar 2016, at 13:03, Claes Redestad wrote:
On 2016-03-09 13:17, Peter Levart wrote:
When digging through old history to try to find out why java.uti
Hi Chris,
So what do you think of providing a hashCode for
java.util.jar.Attributes.Name that is obviously consistent with its
equals method (and not dependent on the good will of Unicode tables)
*and* also provide it as a public API to serve others, like for example:
http://cr.openjdk.java.
On 9 Mar 2016, at 14:43, Peter Levart wrote:
>
> On 03/09/2016 02:44 PM, Chris Hegarty wrote:
>> On 9 Mar 2016, at 13:03, Claes Redestad wrote:
>>
>>> On 2016-03-09 13:17, Peter Levart wrote:
> When digging through old history to try to find out why
> java.util.jar.Attributes
> w
On 03/09/2016 02:44 PM, Chris Hegarty wrote:
On 9 Mar 2016, at 13:03, Claes Redestad wrote:
On 2016-03-09 13:17, Peter Levart wrote:
When digging through old history to try to find out why java.util.jar.Attributes
was ever using ASCIICaseInsensitiveComparator, it was not clear that
performa
Hi Claes,
Here's the pre-post-patch comparison:
import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;
import java.util.concurrent.TimeUnit;
import java.util.jar.Attributes;
@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations = 5)
@Measurement(iterations = 10)
@OutputTim
On 9 Mar 2016, at 13:03, Claes Redestad wrote:
> On 2016-03-09 13:17, Peter Levart wrote:
>>>
>>> When digging through old history to try to find out why
>>> java.util.jar.Attributes
>>> was ever using ASCIICaseInsensitiveComparator, it was not clear that
>>> performance was the motivation.
>>
On 2016-03-09 13:17, Peter Levart wrote:
When digging through old history to try to find out why
java.util.jar.Attributes
was ever using ASCIICaseInsensitiveComparator, it was not clear that
performance was the motivation.
I guess looking-up a manifest attribute is not a performance critic
Hi Stefan,
> On 9 Mar 2016, at 00:01, Stefan Zobel wrote:
>
> Hi all,
>
> just noticed that
>
> org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest
>
>
> has a small copy & paste error in line 116:
>
> 115: maps.put(HashMap.class.getName(), () -> new HashMap<>(content));
>
Hi Chris,
On 03/09/2016 12:07 PM, Chris Hegarty wrote:
Hi Peter,
On 9 Mar 2016, at 08:42, Peter Levart wrote:
Hi Chris,
While Attribute.Name.equals() should be comparably fast, what about
Attribute.Name.hashCode() ? Could you for example extend the
AvailableCharsetsCompare benchmark with
On 03/08/2016 08:45 PM, Xueming Shen wrote:
> [2] http://cr.openjdk.java.net/~sherman/regexClosure/MyBenchmark.java
Do return the matches() result:
@Benchmark
public boolean testMethod() {
return matcher.reset(input).matches();
}
Thanks,
-Aleksey
Thanks Aleksey,
I will take care of it.
- Michael
On 09/03/16 11:34, Aleksey Shipilev wrote:
Alan mentioned I should have sent this to net-dev@. Instead, I submitted
a new bug:
https://bugs.openjdk.java.net/browse/JDK-8151505
-Aleksey
On 03/09/2016 02:06 PM, Aleksey Shipilev wrote:
Hi,
I
Alan mentioned I should have sent this to net-dev@. Instead, I submitted
a new bug:
https://bugs.openjdk.java.net/browse/JDK-8151505
-Aleksey
On 03/09/2016 02:06 PM, Aleksey Shipilev wrote:
> Hi,
>
> In recently committed java.net.http.ExecutorWrapper, there is a
> synchronize() method [1], whi
Hi Peter,
On 9 Mar 2016, at 08:42, Peter Levart wrote:
> Hi Chris,
>
> While Attribute.Name.equals() should be comparably fast, what about
> Attribute.Name.hashCode() ? Could you for example extend the
> AvailableCharsetsCompare benchmark with a a @Setup method that constructs
> (via Attribu
Hi,
In recently committed java.net.http.ExecutorWrapper, there is a
synchronize() method [1], which is used as "memory fence" [2]:
public synchronized void synchronize() {}
public void execute(Runnable r, Supplier
ctxSupplier) {
synchronize();
Runnable r1 = () -> {
try {
r.ru
Hi Chris,
While Attribute.Name.equals() should be comparably fast, what about
Attribute.Name.hashCode() ? Could you for example extend the
AvailableCharsetsCompare benchmark with a a @Setup method that
constructs (via Attributes.putValue(String, String)) a
java.util.jar.Attributes instance wi
Hi,
Your fix look good to me.
We cannot change current behavior for backward compatibility.
Thanks,
--
Yuka
On 2016/03/04 15:51, vaibhav x.choudhary wrote:
Hello,
Please review this small fix for jdk9/dev repo :-
Bug: https://bugs.openjdk.java.net/browse/JDK-8150702
Webrev: http://cr.openjdk
33 matches
Mail list logo
