I pushed this today based on Dan and Robbin's reviews, but realized just
after the act that I should have waited for any feedback from core-libs
- apologies about that. If there are concerns I will roll it back.
Thanks,
David
-
On 26/04/2019 2:57 pm, David Holmes wrote:
Thanks Dan!
Hi Robbin,
On 25/04/2019 5:53 pm, Robbin Ehn wrote:
Hi David,
Looks good.
Thanks for the review.
Just a question:
It seems like we could just hold the ThreadsList over p->unpark() and
not rely on TSM ?
Yes now it is done this way we could do the unpark while holding the TLH
and avoid
Thanks Dan! Extraneous ; culled.
David
On 25/04/2019 1:16 am, Daniel D. Daugherty wrote:
On 4/24/19 3:12 AM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8222518
webrev: http://cr.openjdk.java.net/~dholmes/8222518/webrev/
src/hotspot/share/classfile/javaClasses.cpp
For issue [1] please review the patch [2].
The source change merely changes mark() to use a read ahead limit one value
larger than the parameter if the most recently read character is a ‘\r’
(carriage return). In this case if the next character in the stream is a ‘\n’
(line feed), the next
+1
> On Apr 25, 2019, at 6:09 PM, naoto.s...@oracle.com wrote:
>
> Hello,
>
> Please review the changes to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8222980
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8222980/webrev.00/
>
> It is
Hi Naoto,
On the surface this looks fine to me although I am not familiar with this area.
Brian
> On Apr 25, 2019, at 3:09 PM, naoto.s...@oracle.com wrote:
>
> Hello,
>
> Please review the changes to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8222980
>
> The proposed
Hello,
Please review the changes to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8222980
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8222980/webrev.00/
It is simply replacing the subtag registry file with the most up-to-date
one, along with test
https://openjdk.java.net/jeps/353
- Mark
Sorry, meant to include core-libs on this !
-phil.
On 4/25/19, 1:12 PM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8130266
CSR: https://bugs.openjdk.java.net/browse/JDK-
Webrev: http://cr.openjdk.java.net/~prr/8130266/
Please review this fix + the CSR which eliminates the
And the complete CSR link is this :
https://bugs.openjdk.java.net/browse/JDK-8222990
On 4/25/19, 1:31 PM, Philip Race wrote:
Sorry, meant to include core-libs on this !
-phil.
On 4/25/19, 1:12 PM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8130266
CSR:
Hi Lance,
No problem. Thanks for reviewing the patch in between your busy schedules!
Best,
Joe
On 4/25/19, 11:51 AM, Lance Andersen wrote:
Hi Joe,
Sorry for the delay but took a while to go through :-)
I think your changes look good overall
On Apr 19, 2019, at 4:19 PM, Joe Wang
Hi Joe,
Sorry for the delay but took a while to go through :-)
I think your changes look good overall
> On Apr 19, 2019, at 4:19 PM, Joe Wang wrote:
>
> Please review an update to xerces/dom. Details are as described in the JBS.
> XML related tests and JCK passed.
>
> JBS:
Also, here is a new webrev including the updated implementations for
mappingAddress/Offset/Length as described below
JIRA: https://bugs.openjdk.java.net/browse/JDK-8221696
webrev: http://cr.openjdk.java.net/~adinn/8221696/webrev.02
regards,
Andrew Dinn
---
On 23/04/2019 17:15, Andrew
Hi Lance,
thanks for the review.
I checked again whether I would remove an important test path for testing the
ability to create mr jars with the jar tool. But I see this is tested for
instance in test/jdk/java/util/jar/JarFile/mrjar and probably in other places
as well.
So I’ll push my
Hi Frank,
These performance measurements would be good to add as JMH tests in
open/test/micro...
Thanks, Roger
On 04/24/2019 05:51 AM, Frank Yuan wrote:
Hi Aleksey
I happened to see the performance to access a field by VarHandle API is much
worse than the native access.
I tested the
Hi Stuart,
Whoops, typo. Thanks for catching that.
Ditto for Martin, who has modified the bug. :)
Best Regards
Adam Farley
IBM Runtimes
Stuart Marks wrote on 24/04/2019 17:59:17:
> From: Stuart Marks
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 24/04/2019 17:59
> Subject: Re: RFR:
Hi,
sorry for the delay, got distracted by other things. Switch back:
http://cr.openjdk.java.net/~redestad/8222852/open.01/
Passed a sanity tier1 run.
/Claes
On 2019-04-23 13:27, Aleksey Shipilev wrote:
I'd keep the switch in the second loop, like this:
for (RecipeElement el :
My assumption is based on conclusions drawn from this article:
https://shipilev.net/blog/2016/arrays-wisdom-ancients/
I don't think the situation has changed much since then.
However, I'll do separate benchmarking with the latest JDK just in case.
25.04.2019, 11:24, "Ivan Gerasimov" :
> Hi
Hi Ivan,
the changes and fast-path speed-ups look reasonable, but I'd like to see
that the overhead for cases not helped by the fast paths isn't
excessive, e.g., micro variants with UTF16 Strings and a mix of Latin1
and UTF16.
/Claes
On 2019-04-25 08:00, Ivan Gerasimov wrote:
Hello!
This
Hi Martin
There's a good chance COWAL access to the array can be optimized as you suggest
using VarHandles.
Write using release; read using acquire, or plain if holding the lock.
I am not very sure, setRelease only ensures the ordering or has the effect that
update the writing data to
Hi Sergei!
Thanks for sharing.
However, it's not immediately obvious to me why the later is better than
the former. Can you please elaborate on that?
I think, it worth a separate discussion.
With kind regards,
Ivan
On 4/25/19 12:40 AM, Сергей Цыпанов wrote:
Hi Ivan,
recently looking
Hi David,
Looks good.
Just a question:
It seems like we could just hold the ThreadsList over p->unpark() and not rely
on TSM ?
Not sure in how many places we do rely on it, but it would be nice to remove TSM
for parkers.
The exiting thread would set parker to NULL before removing itself from
Hi Ivan,
recently looking into java.lang.String I've found out that String::split still
uses old collection-to-array approach:
String[] result = new String[resultSize];
return list.subList(0, resultSize).toArray(result);
which should be replaced with
return list.subList(0,
There's a good chance COWAL access to the array can be optimized as you
suggest using VarHandles.
Write using release; read using acquire, or plain if holding the lock.
Doesn't buy much on x86 but performance improvement should be measurable on
ppc.
On Wed, Apr 24, 2019 at 10:33 PM Frank Yuan
Hello!
This enhancement was inspired by a recent discussion at
compiler-...@openjdk.java.net.
It seems to be a non-uncommon situation when String.replace(CS, CS) is
called with this and both arguments being Latin1 strings, so it seems
reasonable to optimize for such case.
Here are the
25 matches
Mail list logo
