Re: RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2

+1 Paul. > On May 14, 2020, at 1:12 PM, Mandy Chung wrote: > > MethodHandles::privateLookupIn should prepare for being called during early > startup when the module of java.base classes are not yet assigned. This bug > is uncovered by panama prototype converting NIO to use memory access

Re: RFR: 8245094: Reduce overhead of initializing the default StringConcatFactory strategy

+1 Paul. > On May 15, 2020, at 3:54 AM, Claes Redestad wrote: > > Hi, > > by adding a bridge method in JavaLangAcces to call into the > StringConcatHelper.initialCoder - which is done only once during > initialization - we can reduce bootstrap overhead of SCF by a few > million instructions -

Re: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

Looks good. — Separately, not for this issue, the code changes you made impact what is mostly unused code. I don’t recall us ever changing the default strategy, nor I am aware of others changing it via a system property (except for our tests), are you? At the time when we introduced this

Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

the wider point you raised about where factory methods reside, and I agree about waiting for specialized generics, as that might allow us to make better moves. Paul. > On May 5, 2020, at 8:01 PM, John Rose wrote: > > On May 1, 2020, at 1:36 PM, Paul Sandoz <mailto:paul.san...@oracle

Re: 8244293 : Remove outdated @apiNote in java.util.Objects

Hi, Removing all of the api note looks good, since it was really written in the context of the removed methods. I’ll sponsor. (I removed the methods but forgot to remove the note.) Paul. > On May 3, 2020, at 9:03 AM, Anirvan Sarkar wrote: > > Hi, > > The class level @apiNote in

Re: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable

I’ll push it for you, Paul. > On May 1, 2020, at 2:13 PM, Jorn Vernee wrote: > > The CSR for this patch is now Approved, so it looks like this patch is ready > to be sponsored. > > Here are the relevant links again. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 > CSR:

Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

Hi Remi, Thanks for the feedback. I am gonna need to go over this with John. Some comments inline. > On Apr 20, 2020, at 6:31 AM, Remi Forax wrote: > > Hi Paul, > about the API part (not the implementation), > there are location where the same concept is described with a different names >

Re: [XXS] JDK-8243598: Typos in java.lang.invoke package-info

+1 > On Apr 28, 2020, at 5:50 PM, Mandy Chung wrote: > > diff --git a/src/java.base/share/classes/java/lang/invoke/package-info.java > b/src/java.base/share/classes/java/lang/invoke/package-info.java > --- a/src/java.base/share/classes/java/lang/invoke/package-info.java > +++

Re: LinkedHashMap/LinkedHashSet enhancement: OrderedMap/OrderedSet

Hi Tagir, I am hesitant to add new interfaces specific to Set/Map for a non-indexed encounter order. The interface OrderedSet is tantalizingly queue-like, in fact rather close to the read-only part of Deque. Did you consider the possibility of LinkedHashSet implementing Deque? I have not

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

> On Apr 23, 2020, at 5:45 PM, Maurizio Cimadamore > wrote: > > > On 24/04/2020 01:35, Paul Sandoz wrote: >> Hi, >> >> Looks good. I have seen almost all of this in reviews on panama-dev hence >> the lack of substantial comments here. >>

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

Hi, Looks good. I have seen almost all of this in reviews on panama-dev hence the lack of substantial comments here. I suspect we are not gonna need the drop argument VH combinator, dropping coordinates feels a little suspicious to me, but I can see why it's there for completeness. Paul. >

Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

tract V bar(); > } > > public abstract class IntVector extends AbstractVector { > > } > > Rémi > > - Mail original - >> De: "Paul Sandoz" >> À: "core-libs-dev" , "hotspot-dev" >> >> Envoyé: Jeu

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

Looks good to me (not familiar with all the code areas. Minor suggestion: MethodHandles.java 1811 * ASCII periods. For the instance of {@link java.lang.Class} representing {@code C}: 1812 * 1813 * {@link Class#getName()} returns the string {@code GN + "/" + },

Re: RFR: JDK-8241627: Updating ASM to 8.0 for JDK 15

> On Apr 14, 2020, at 11:22 AM, Vicente Romero > wrote: > > Hi Paul, > > On 4/14/20 2:05 PM, Paul Sandoz wrote: >> Hi Vicente, >> >> Looks ok from the changes required to integrate into the JDK. >> >> Maybe the @SuppressWarnings warning a

Re: RFR: JDK-8241627: Updating ASM to 8.0 for JDK 15

Hi Vicente, Looks ok from the changes required to integrate into the JDK. Maybe the @SuppressWarnings warning annotations could be upstreamed? Paul. > On Apr 13, 2020, at 8:05 AM, Vicente Romero wrote: > > Hi all, > > Please review this patch that updates the ASM version to appear in JDK15

Re: RFR: 8188055: (ref) Add Reference.refersTo predicate

Reference.java — 335 * 336 * @return The object to which this reference refers, or 337 * {@code null} if this reference object has been cleared Add @see refersTo 338 */ 339 @HotSpotIntrinsicCandidate 340 public T get() { Paul. > On Apr 7, 2020, at

Re: RFR: JDK-8241742 - Remove the preview status for methods introduced for Text Blocks

+1 Paul. > On Apr 6, 2020, at 8:54 AM, Jim Laskey wrote: > > Updated webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 > > >> On Apr 6, 2020, at 11:40 AM, Jim Laskey wrote: >> >> Please take the time to review the code

RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

Hi, A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

+1 Paul. > On Mar 27, 2020, at 3:22 PM, Mandy Chung wrote: > > Hi Paul, > > This is the delta incorporating your comment: > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-psandoz/ > >

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

Hi Mandy, Very thorough, bravo! Minor suggestions below. Paul. MethodHandleNatives.java — 142 143 /** 144 * Flags for Lookup.ClassOptions 145 */ 146 static final int 147 NESTMATE_CLASS= 0x0001, 148 HIDDEN_CLASS

Re: RFR (XS/T) 8241445: Fix copyrights after JDK-8240629 change

> On Mar 24, 2020, at 10:40 AM, Aleksey Shipilev wrote: > > On 3/24/20 6:38 PM, Paul Sandoz wrote: >> I’ll bite :-) +1 > > Thanks. Would you also, per chance, consider it trivial? Very much so. It’s maybe something that could be gated by jcheck (or whatever the equ

Re: RFR (XS/T) 8241445: Fix copyrights after JDK-8240629 change

I’ll bite :-) +1 Paul. > On Mar 24, 2020, at 10:10 AM, Aleksey Shipilev wrote: > > On 3/23/20 3:02 PM, Aleksey Shipilev wrote: >> This change in JDK-8240629 was not correct and slipped the review? >> https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2#l2.5 >> >> Also, other file has not

Re: RFR [15] 8241014: Miscellaneous typos in documentation comments

+1 Paul. > On Mar 13, 2020, at 8:42 AM, Pavel Rappo wrote: > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and

Re: RFR [15] 8241014: Miscellaneous typos in documentation comments

--- a/src/java.base/share/classes/java/lang/invoke/MethodType.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java @@ -1379,12 +1379,12 @@ /** * This implementation returns {@code true} if {@code obj} is another - * {@code WeakEntry}

RFR JEP 338: Vector API (Incubator), JDK-8223347 Integration of Vector API (Incubator): Vector API

Hi, This email is intended to kick start the review of JEP 338: Vector API (Incubator). For ease of review we intend to split this up into separate parts for review of the Java API, Java implementation, Java unit tests, Java jmh tests, shared hotspot code, and platform specific hotspot

Re: JEP 370 - text example leads to exception

Thanks for pointing out the inconsistencies. I modified the JEP with updated code snippets that compile against the latest API in JDK 14 [*]. The handle created “withStride” requires an additional coordinate the is an offset from the base address. You may find Maurizio’s recent talk at Fosdem

Re: RFR: 8238684: Override getOrDefault in immutable Map implementations

+1 Paul. > On Feb 7, 2020, at 4:17 AM, Claes Redestad wrote: > > Hi, > > in our immutable map implementations, it's unnecessary for getOrDefault > to check containsKey(key) in case get(key) returns null. This follows > since null values are disallowed. > > Overriding the method with an

Re: RFR: JDK-8238239: java.lang.Record spec clarifications

+1 Paul. > On Feb 5, 2020, at 2:36 PM, Vicente Romero wrote: > > forwarding to compiler dev, I need a reviewer for this change, > > Thanks, > Vicente > > > Forwarded Message > Subject: RFR: JDK-8238239: java.lang.Record spec clarifications > Date: Tue, 4 Feb 2020

Re: RFR [15] 8236825: Reading output from ... using ProcessBuilder/Process might hang

My sense is it is fixing a marginal case for the less dominant platform where this is less likely arise, whereas for the dominant platform there is still an issue. Waiting for a non-blocking native read is a reasonable approach (IIUC that is required for the desired proper fix). It would be

Re: RFR (14) 8235837: Memory access API refinements

+1 Paul. > On Jan 14, 2020, at 10:30 AM, Maurizio Cimadamore > wrote: > > Another revision which addresses some additional CSR feedback: > > * SequenceLayout::withElementCount should throw if new element count < 0 > * MemoryLayout::hasSize should clarify that certain layout (e.g. ValueLayout)

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

> On Jan 13, 2020, at 1:12 PM, Claes Redestad wrote: > > On 2020-01-13 20:49, Paul Sandoz wrote: >> Looks good. > > Thanks! > >> 78 private static final Object[] EMPTY; >> Is there a specific reason related to archiving that this is Object[] and

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

Looks good. 78 private static final Object[] EMPTY; Is there a specific reason related to archiving that this is Object[] and not Object and instead assigned a value of new Object() ? -- For information purposes: an alternative salt might be to use mix32 from Splittable random: /** *

Re: JDK 14 RFR of JDK-8236695: java.lang.Record should be declared with an explicit constructor

+1 Paul. > On Jan 6, 2020, at 3:22 PM, Joe Darcy wrote: > > Hello, > > The initial implementation of java.lang.Record uses a default constructor; an > explicit constructor should be added instead. Please review the code change > and CSR for this: > > JDK-8236695: java.lang.Record

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

stays the same, and only the offset part > changes, which means C2 will have no troubles hoisting out the alignment > check out of the loop. > > > As things appear stable, I do not plan to make any other changes to the > implementation/API ahead of integration, unless th

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

> On Dec 10, 2019, at 4:51 AM, Maurizio Cimadamore > wrote: > > And, another, small iteration > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v5 > > Delta compared to previous version (v4): > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v5_delta > > Javadoc updated

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

+1 Paul. > On Dec 9, 2019, at 11:23 AM, Maurizio Cimadamore > wrote: > > Another iteration: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4/ > > Delta of the changes since last version (v3) here: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4_delta/ > > The

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

6/12/2019 21:04, Paul Sandoz wrote: >> GroupLayout.java >> — >> >> 80 OptionalLong sizeof(List elems) { >> 81 long size = 0; >> 82 for (MemoryLayout elem : elems) { >> 83 if (AbstractLayout.optS

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

I mostly looked at the API and implementation and not the tests. s/offset/add or plus ? add ‘l’ to the offset of this memory address the result of which is the offset of the returned memory address. If we ever have controlled operator overloading that’s how I would like to express it :-)

Re: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen state

+1 > On Nov 19, 2019, at 10:12 AM, Vladimir Ivanov > wrote: > > Thanks, Paul. > >> CallSite: >> public class CallSite { >> - // The actual payload of this call site: >> + // The actual payload of this call site. >> + // Can be modified using {@link >>

Re: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen state

Much better :-) I accumulated some more questions while I was looking further. CallSite: public class CallSite { -// The actual payload of this call site: +// The actual payload of this call site. +// Can be modified using {@link MethodHandleNatives#setCallSiteTargetNormal} or

Re: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen state

Ah the perils of partial construction :-) Subtle, so I could be misunderstanding something, did you intend to remove the assignment of isFrozen in the ConstantCallSite constructor? ConstantCallSite: protected ConstantCallSite(MethodType targetType, MethodHandle createTargetHook) throws

Re: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes generated lambdas

> the stack trace created in a static initialiser of a lambda super-type. The > stack trace should not contain LMF when > -Djdk.internal.lambda.disableEagerInitialization=true. Let me know if this > kind of a test reasonable; I can easily add it. — Vojin > >> On 29 Oct 2

Re: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes generated lambdas

> On Oct 28, 2019, at 3:29 PM, mark.reinh...@oracle.com wrote: > > 2019/10/28 11:10:25 -0700, vojin.jovano...@oracle.com: >> This email proposes a change to the LambdaMetaFactory that allows to >> disable eager initialization (with Unsafe) of generated lambdas. ... >> >> ... >> >> After the

Re: Long chains created by direct Buffer::slice

Thanks, i uploaded a new webrev in place that uses a similar technique to some stuff in j.u.concurrent tests. Paul. > On Aug 5, 2018, at 11:59 AM, Alan Bateman wrote: > > On 03/08/2018 23:15, Paul Sandoz wrote: >> Got caught up with JVMLS this week… >> >> I searche

Re: Long chains created by direct Buffer::slice

12:35 PM, Paul Sandoz wrote: > > > >> On Jul 27, 2018, at 1:09 AM, Florian Weimer wrote: >> >> * Paul Sandoz: >> >>> I created this issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8208362 >> >> Thanks. >>

Re: Long chains created by direct Buffer::slice

> On Jul 27, 2018, at 1:09 AM, Florian Weimer wrote: > > * Paul Sandoz: > >> I created this issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8208362 > > Thanks. > >> The suggested fix requires a tweak though since an inst

Re: Long chains created by direct Buffer::slice

+1 I created this issue: https://bugs.openjdk.java.net/browse/JDK-8208362 The suggested fix requires a tweak though since an instance of a DirectBuffer interface is passed. This is required because views over direct ByteBuffers can be created. Florian, i will push tomorrow and assign you

[11] RFR 8207027 Lookup.accessClass fails for an array type in the same package when assertions are enabled

Hi, Please review this fix for 11: http://cr.openjdk.java.net/~psandoz/jdk/JDK-8207027-lookup-access-class-array-type/webrev/ The fix removes an old and now incorrect assert statement. This statement causes MethodHandles.Lookup.accessClass to fail when system assertions are enabled and an

Re: RFR 8206955 MethodHandleProxies.asInterfaceInstance does not support default methods

unctionality which was introduced prior to the latter e.g. it's possible to explicitly declare overloaded abstract methods whose return/parameter types are compatible with the target type. Paul. > Regards, Peter > > > On 07/11/2018 12:43 AM, Paul Sando

RFR 8206955 MethodHandleProxies.asInterfaceInstance does not support default methods

Hi, Please review this fix to MethodHandleProxies.asInterfaceInstance to support default methods: http://cr.openjdk.java.net/~psandoz/jdk/JDK-8206955-mh-func-iface-proxy-default-methods/webrev/

Re: RFR 8206123 : ArrayDeque created with default constructor can only hold 15 elements

> On Jul 3, 2018, at 10:42 AM, Martin Buchholz wrote: > > > On Tue, Jul 3, 2018 at 9:53 AM, Paul Sandoz <mailto:paul.san...@oracle.com>> wrote: > Looks good. Where do you propose to place the test in the OpenJDK repo? > > > http://cr.openjdk.java.net/~mart

Re: RFR 8206123 : ArrayDeque created with default constructor can only hold 15 elements

Looks good. Where do you propose to place the test in the OpenJDK repo? Paul. > On Jun 30, 2018, at 10:29 AM, Martin Buchholz wrote: > > Hi Ivan, > > Thanks for finding this bug - I'll take the blame. > > Forgive my pushiness - I'd like to do a friendly takeover of this. As > penance I

Re: [PATCH] AbstractStringBuilder.append()

quot;bar" + "foo"; >> x += "baz" + "biz"; >> >> I had trouble reading stringopts.cpp. I was thinking this append might >> be common due to implicit StringBuilder creation. >> >> Isaac >> >> >> On Fri, Jun 29, 2

Re: [PATCH] AbstractStringBuilder.append()

Hard to reconstruct the culture memory around this. I suspect such a new method was not considered necessary when StringBuilder was added to Java 1.5 given the CharSequence accepting method, and performance was not considered a concern, and I doubt it's a concern now. (I don’t think there is

Re: RFR: 8177275: IllegalArgumentException when MH would have too many parameters is not specified for several methods

+1 Paul. > On Jun 28, 2018, at 1:27 AM, Vivek Theeyarath > wrote: > > Hi All, > > Please review fix for > https://bugs.openjdk.java.net/browse/JDK-8177275 . The jtreg test runs fine > with the changes. > > > > http://cr.openjdk.java.net/~vtheeyarath/8177275/webrev.02/ >

Re: RFR(xs): JDK-8201610: fix broken link in UnicastRemoteObject

+1 Paul. > On Jun 25, 2018, at 4:44 PM, Stuart Marks wrote: > > Hi all, > > Please review this small fix for a broken link. > > Patch appended below. > > Bug: > >https://bugs.openjdk.java.net/browse/JDK-8201610 > > Thanks, > > s'marks > > > > diff -r 8b98dcf37891 -r 3da3bcc7b28b >

Re: RFR 8205547 : FileChannel/CleanerTest.java fails due to expected FD count

> On Jun 25, 2018, at 11:08 AM, Roger Riggs wrote: > > Hi Paul, > > Updated the webrev in place: > http://cr.openjdk.java.net/~rriggs/webrev-fd-count-wrong-8205547/ > <http://cr.openjdk.java.net/~rriggs/webrev-fd-count-wrong-8205547/> > > On 6/25/2018

Re: RFR: 8205184: Delegating Iterator implementations that don't delegate forEachRemaining()

Looks good. Sometimes in these cases i reach for proxy rather than explicit code. It tends to be more robust to certain changes at the expense of reflective complexity. You could probably reduce the test method names by removing the “forEachRemainingIsDelegated_” given that can be inferred

Re: RFR 8205547 : FileChannel/CleanerTest.java fails due to expected FD count

Hi Roger, Are you missing the throwing of an exception when the fdCount != fdCount0? (and relatedly i could not tell if the print statements were for temporary debugging and you intended to remove them) Since you check before hand for support of UnixOperatingSystemMXBean there appears no need

Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions

> On Jun 22, 2018, at 5:17 PM, Vladimir Kozlov > wrote: > > On 6/22/18 3:58 PM, Paul Sandoz wrote: >> Hi Smita, >> I am ok with it if Vladimir is :-) One slight concern is this may be biasing >> towards the x86 implementation of the intrinsic. > >

Re: RFR 8195650 Method references to VarHandle accessors

Gentle reminder. I would like to get this reviews and pushed before the ramp down phase one kicks in this week. Paul. > On Jun 19, 2018, at 5:08 PM, Paul Sandoz wrote: > > Hi, > > Please review the following fix to ensure method references to VarHandle > signature p

Re: RFR: jsr166 integration 2018-06

> On Jun 24, 2018, at 1:29 PM, Doug Lea wrote: > > On 06/22/2018 01:28 PM, Paul Sandoz wrote: > >>> 8203864: Execution error in Java's Timsort >>> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/TimSort/index.html >>> https://b

Re: RFC: Experiment in accessing/managing persistent memory from Java

Hi, > On Jun 21, 2018, at 9:32 AM, Andrew Dinn wrote: > > Hi Paul, > > Sorry for the delay in responding to this -- holiday and then an urgent > bug fix intervened . . . > > On 08/06/18 01:42, Paul Sandoz wrote: >> Sandhya gave an overview to a few of us Orac

Re: RFR: jsr166 integration 2018-06

> On Jun 21, 2018, at 6:28 PM, Martin Buchholz wrote: > > JDK 11 draws nigh. > Indeed, comments below, Paul. > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html > > 8202422: value of 'sizeCtl' in ConcurrentHashMap varies with the constructor > called >

Re: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.

ivek R > wrote: > > Hi Paul > > The folding of if/else is the right way in this patch which I missed in > earlier webrev. > http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.03/ > I think I would keep the same earlier path if both the values are NaN. >

Re: RFR 8202922 Method reference identity is broken by serialization

Gentle reminder, Paul. > On Jun 14, 2018, at 10:41 AM, Paul Sandoz wrote: > > Hi, > > Please review an update to the specifications of LambdaMetafactory and > SerializedLambda to clarify that the identity of function objects is > unpredictable. A similar (informa

Re: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.

gested. > Please find the updated webrev at this location: > http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.02/ > <http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.02/> > > Regards, > Vivek > From: Paul Sandoz [mailto:paul.san

Re: RFR(s): JDK-8203184 List.copyOf() fails to copy sublists

+1 Paul. > On Jun 20, 2018, at 2:18 PM, Stuart Marks wrote: > > Hi all, > > Please review this small changeset that restores copy semantics to > List.copyOf() when applied to a sublist of an unmodifiable list. > > Webrev: > >http://cr.openjdk.java.net/~smarks/reviews/8203184/webrev.0/

Re: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.

v is here: > http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.01/ > <http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.01/> > I have also modified the bug with updated webrev. > Regards, > Vivek > > From: Deshpande, Vivek R > Se

Re: [core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

> On Jun 19, 2018, at 10:25 PM, mandy chung wrote: > > The javadoc update looks good to me. > Same here, +1 Paul.

RFR 8195650 Method references to VarHandle accessors

Hi, Please review the following fix to ensure method references to VarHandle signature polymorphic methods are supported at runtime (specifically the method handle to a signature polymorphic method can be loaded from the constant pool):

Re: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.

d > > On 19/06/2018 9:52 AM, Deshpande, Vivek R wrote: >> Hi All >> >> Forgot to add the links: >> https://bugs.openjdk.java.net/browse/JDK-8205194 >> webrev: >> http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.0 >> 0/ >&g

Re: BiCollector

Gosh, this is a tricky one to name. collectingTo seems the best so far, although collect(collectingTo(…)) ... One last suggestion from me, “expanding”, as in the collector expands the number of collectors the input elements are applied to. Paul. > On Jun 19, 2018, at 7:47 AM, Brian Goetz

Re: BiCollector

Hi Peter, Existing composing collectors tend to unpack all the functions of the input collector ahead of time, i don’t recall being too concerned about this at the time. It does allow for more robust null checking, something we were less diligent about doing. Paul. > On Jun 17, 2018, at 3:04

Re: BiCollector

Hi Tagir, This is looking good. My current favorite name for the factory method is “bisecting” since we are dividing the collector into two collectors, the results of which are then merged. Suggested first paragraph of the factory method: "Returns a collector that passes the input

Re: RFR 8198669: Refactor annotation array value parsing to reduce duplication

> On Jun 15, 2018, at 2:31 PM, Liam Miller-Cushon wrote: > > On Fri, Jun 15, 2018 at 1:44 PM Paul Sandoz <mailto:paul.san...@oracle.com>> wrote: > A nice cleanup. Did you run any tiered tests just to double check that the > use of lambdas causes no bootstra

Re: RFR 8170159 Improve the performance of BitSet traversal

> On Jun 15, 2018, at 2:24 PM, Martin Buchholz wrote: > > Still looks correct, but I might keep looking for something more elegant. > What bothers me a little now is > > 1290 long word = words[u] & (WORD_MASK << i); > > which is part of the initial setup and is not

Re: RFR 8198669: Refactor annotation array value parsing to reduce duplication

+1 A nice cleanup. Did you run any tiered tests just to double check that the use of lambdas causes no bootstrapping issues? (i suspect it probably does not). Paul. > On Jun 15, 2018, at 10:58 AM, Liam Miller-Cushon wrote: > > Hello, > > This change is a follow-up to JDK-7183985 which

Re: RFR 8170159 Improve the performance of BitSet traversal

Thanks! Doh, obvious in hindsight. > On Jun 15, 2018, at 11:05 AM, Martin Buchholz wrote: > > It took me a while to realize why you were checking tz < 63. It's because > the shift by 64 that might occur below would be a no-op! Right! > 1301 action.accept(i++); >

Re: RFR 8199435 : Unsafe publication of java.util.Properties.map

Yes, like that, thanks, Paul. > On Jun 15, 2018, at 11:01 AM, Brent Christian > wrote: > > On 6/15/18 10:35 AM, Paul Sandoz wrote: >> I would also publish the map in readHashtable after you have placed in the >> keys/values. > > Like this? > > /

Re: RFR 8199435 : Unsafe publication of java.util.Properties.map

> On Jun 15, 2018, at 8:44 AM, Brent Christian > wrote: > > Hi, > > In JDK 9, 8029891[1] refactored java.util.Properties to store its values in > an internal ConcurrentHashMap, and removed synchronization from "reader" > methods in order to avoid potential hangs/deadlocks during

Re: RFR 8170159 Improve the performance of BitSet traversal

; > System.out.println(s.cardinality()); > s.flip(Integer.MAX_VALUE); > System.out.println(s.cardinality()); > } > } > > > ==> java -Xmx20g -esa -ea BitSetCardinality > 2147483647 > -2147483648 > Oh dear! Thanks, Paul. > > On

RFR 8170159 Improve the performance of BitSet traversal

Hi, Please review this enhancement to improve the performance of BitSet traversal when using a stream. http://cr.openjdk.java.net/~psandoz/jdk/JDK-8170159-bitset-traverse/webrev/ The associated issue started out

RFR 8202922 Method reference identity is broken by serialization

Hi, Please review an update to the specifications of LambdaMetafactory and SerializedLambda to clarify that the identity of function objects is unpredictable. A similar (informational) clarification was made to the language specification and similar wording is used. Amusingly a quirk of (or

Re: BiCollector

in this respect since we have similar operations for collection as we do on Stream. Paul. > On Jun 14, 2018, at 12:29 AM, Peter Levart wrote: > > Hi Paul, > > On 06/11/18 19:10, Paul Sandoz wrote: >> Hi Peter, >> >> I like it and can see it being useful,

Re: [JDK 11] RFR 8204944: Remove java/util/Map/InPlaceOpsCollisions.java from ProblemList.txt

+1 Paul. > On Jun 13, 2018, at 2:31 AM, Amy Lu wrote: > > Please review this patch to remove java/util/Map/InPlaceOpsCollisions.java > from ProblemList.txt, > related bug JDK-8203387 (JDK-8203425) has been fixed. > > Thanks, > Amy > > --- old/test/jdk/ProblemList.txt2018-06-13

Re: RFR(xs): 8204663: clean up remaining native parts after JDK-8187631

+1 Paul. > On Jun 13, 2018, at 2:56 AM, Thomas Stüfe wrote: > > May I have a second review please. > > Thanks, Thomas > > On Mon, Jun 11, 2018, 15:13 Thomas Stüfe wrote: > >> Hi, >> >> may I please have reviews for this small cleanup. >> >> Bug:

Re: RFC: Experiment in accessing/managing persistent memory from Java

Hi Jonathan, > On Jun 8, 2018, at 3:59 AM, Jonathan Halliday > wrote: > > > Hi Paul > > Looks like we're all on the same page regarding the basic approach of using a > small API and making the critical bits intrinsic. We perhaps have some way to > go on exactly what that API looks like in

Re: RFR: 8196988 (Resolve disabled warnings for libjimage)

Looks ok. Including Jim in case he is not listening in… I am guessing the comment selectively disables the warning in this code (rather than using a diagnostic pragma). Thanks, Paul. > On Jun 7, 2018, at 11:17 PM, Srinivas Dama wrote: > > Hi, > > Please review

Re: RFR: 8202216: (bf) Add Buffer mismatch()

+1 Paul. > On Jun 12, 2018, at 2:34 AM, Vivek Theeyarath > wrote: > > Hi All, > > Please review fix for > https://bugs.openjdk.java.net/browse/JDK-8202216 > > > > Webrev: http://cr.openjdk.java.net/~vtheeyarath/8202216/webrev.00/ > > CSR :

Re: RFR: 8202216: (bf) Add Buffer mismatch()

Hi Peter, Buffer is not currently a generic class and making it so likely would cause some source compatibility issues (e.g. lots of raw type warnings/errors). Paul. > On Jun 12, 2018, at 3:20 AM, Peter Levart wrote: > > Hi, > > On 06/12/2018 11:34 AM, Vivek Theeyarath wrote: >> Hi All, >>

Re: BiCollector

r > > On 06/11/18 19:10, Paul Sandoz wrote: >> Hi Peter, >> >> I like it and can see it being useful, thanks for sharing. >> >> I am hesitating a little about it being in the JDK because there is the >> larger abstraction of a BiStream, where a similar

Re: BiCollector

Hi Peter, I like it and can see it being useful, thanks for sharing. I am hesitating a little about it being in the JDK because there is the larger abstraction of a BiStream, where a similar form of collection would naturally fit (but perhaps without the intersection constraints for the

Re: RFC: Experiment in accessing/managing persistent memory from Java

Hi Andrew, Jonathan, Sandhya gave an overview to a few of us Oracle folks. I agree with what Sandhya says regarding the API, a small surface, and on pursuing an unsafe intrinsic. I like it and would encourage the writing of a draft JEP, especially to give this visibility. I expect this will

Re: Implementations of PrimitiveIterator.OfInt#forEachRemaining(IntConsumer) doesn't check IntConsumer for null

Performance should not be a concern, null checking is highly optimized by the JIT and is anyway required when the consumer is accessed in the loop. It’s probably an oversight but FWIW these internal iterators are never exposed directly and are wrapped in spliterators and those wrappers will

Re: RFR: 8201608 fix broken links in javax/sql/rowset/package.html and javax/sql/rowset/spi/package.html

> On Jun 4, 2018, at 12:00 PM, Lance Andersen wrote: > > >> On Jun 4, 2018, at 2:51 PM, Paul Sandoz > <mailto:paul.san...@oracle.com>> wrote: >> >> >> >>> On Jun 4, 2018, at 4:22 AM, Lance Andersen >> <mailto:lance.ander...@o

Re: RFR: 8201608 fix broken links in javax/sql/rowset/package.html and javax/sql/rowset/spi/package.html

> On Jun 4, 2018, at 4:22 AM, Lance Andersen wrote: > > Hi, > > Bug 8201608 highlights a few broken links in javax/sql/rowset/package.html > and javax/sql/rowset/spi/package.html > > As part of this fix, I took the liberty to move from package.html to > package-info.java > > The webrev

Re: RFR: 8204194: Lazily create MethodHandleImpl$AsVarargsCollector.asCollectorCache

+1 Paul. > On May 31, 2018, at 2:24 PM, Claes Redestad wrote: > > Hi, > > please review this tiny fix that removes the eager creation of > asCollectorCache, which saves us a few milliseconds on certain startup tests > with no observed peak performance penalties. > > Bug:

Re: RFR: JDK-8050818 Predicate::not - provide an easier way to negate a predicate

+1 — Actually… even small API tweaks are not easy :-), this got me thinking whether this method should explicitly state negate is called, since it has implications for subtypes. Something to consider as a follow on tweak perhaps. Paul. > On May 29, 2018, at 5:52 AM, Jim Laskey wrote: > >

Re: RFR: JDK-8203839: API clarification: versioned jar entry verification in multi-release jar file

+1 Paul. > On May 29, 2018, at 12:22 PM, Xueming Shen wrote: > > Hi, > > Please help review the proposed api spec update for JDK-8203839 (and its CSR) > > issue: JDK-8203839: API clarification: versioned jar entry verification in > multi-release jar file > csr:

<    1   2   3   4   5   6   7   8   9   10   >