Hi Claes,
the patch is fine for me with the minor nitpick that the static final
containing Unsafe should be called UNSAFE and not just U.
do you know why BufferedInputStream is loaded in first place during the startup
of the VM ?
regards,
Rémi
- Mail original -
> De: "Claes Redestad"
Hi Remi,
On 2016-04-03 13:57, Remi Forax wrote:
Hi Claes,
the patch is fine for me with the minor nitpick that the static final
containing Unsafe should be called UNSAFE and not just U.
sure, I copied the setup/naming convention from ConcurrentHashMap, but
UNSAFE does make it stand out bette
- Mail original -
> De: "Claes Redestad"
> À: "Remi Forax"
> Cc: "core-libs-dev Libs"
> Envoyé: Dimanche 3 Avril 2016 14:19:52
> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of
> AtomicReferenceFieldUpdater with Unsafe
>
> Hi Remi,
>
> On 2016-04-03 13:57, Remi Forax wrot
On 03/04/2016 13:19, Claes Redestad wrote:
Hi Remi,
On 2016-04-03 13:57, Remi Forax wrote:
Hi Claes,
the patch is fine for me with the minor nitpick that the static final
containing Unsafe should be called UNSAFE and not just U.
sure, I copied the setup/naming convention from ConcurrentHas
Updated webrev, as per comments:
http://cr.openjdk.java.net/~chegar/8153181/01/
getVMTemporaryDirectory could be moved into jdk.internal.perf.Perf, which
would move its native implementation into the VM, perf.cpp, but it doesn’t
seem worth it, unless future refactoring wanted to get rid of
JVM_G
Easy changes to review, up to April Fools day, in part to make room
for later unfinished more exciting changes.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
On 03/04/2016 16:47, Chris Hegarty wrote:
Updated webrev, as per comments:
http://cr.openjdk.java.net/~chegar/8153181/01/
getVMTemporaryDirectory could be moved into jdk.internal.perf.Perf, which
would move its native implementation into the VM, perf.cpp, but it doesn’t
seem worth it, unles
Hi Martin,
for
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/
aka introducing a new constructor seems to be a regression to me,
the less overloads we have the better i understand the code.
Rémi
- Mail original -
> De: "Martin Buchholz"
> À: "
Hi Martin,
Dequeue doc change is fine,
ParkLoops test is fine too, i suppose it's related to the recent change in the
code of TimeUnit to test with different units.
For the CompletableFuture change, i don't understand the consequence of the
patch so i declare myself incompetent on that subject :
On 04/03/2016 04:55 PM, Alan Bateman wrote:
On 03/04/2016 13:19, Claes Redestad wrote:
Hi Remi,
On 2016-04-03 13:57, Remi Forax wrote:
Hi Claes,
the patch is fine for me with the minor nitpick that the static
final containing Unsafe should be called UNSAFE and not just U.
sure, I copied t
Thanks for the review!
On Sun, Apr 3, 2016 at 12:34 PM, Remi Forax wrote:
> Hi Martin,
> for
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/
>
> aka introducing a new constructor seems to be a regression to me,
> the less overloads we have the better
- Mail original -
> De: "Martin Buchholz"
> À: "Remi Forax"
> Cc: "core-libs-dev" , "Doug Lea"
> , "Paul Sandoz"
> , "Chris Hegarty" , "David
> Holmes"
> Envoyé: Dimanche 3 Avril 2016 23:08:50
> Objet: Re: RFR: jsr166 jdk9 integration wave 6
>
> Thanks for the review!
>
> On Sun, A
> On Apr 3, 2016, at 8:47 AM, Chris Hegarty wrote:
>
> Updated webrev, as per comments:
> http://cr.openjdk.java.net/~chegar/8153181/01/
>
> getVMTemporaryDirectory could be moved into jdk.internal.perf.Perf, which
> would move its native implementation into the VM, perf.cpp, but it doesn’t
>
+1
On 4/2/2016 1:55 AM, Claes Redestad wrote:
> Hi,
>
> seems my recent push for JDK-8152641 broke a jimage test or two.
>
> While I think these test seem a bit odd, it's apparent that checking
> that we're not adding the same resource twice is enough to make the
> tests happy for now:
>
> Webrev:
14 matches
Mail list logo
