Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

2018-05-25 Thread Chris Hegarty
Alan, On 25/05/18 12:27, Alan Bateman wrote: On 24/05/2018 21:57, Ivan Gerasimov wrote: .. WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ The changes in 01/webrev look okay to me but I'm curious if there are any ports in OpenJDK where the values are different. HPUX 11.31 (

Re: RFR: CSR - JDK-8203428 Predicate::not

2018-05-18 Thread Chris Hegarty
On 18/05/18 17:35, Jim Laskey wrote: Introduce a new static method Predicate::not which will allow developers to negate predicate lambdas trivially. csr: https://bugs.openjdk.java.net/browse/JDK-8203428 I have looked for this a number of times. +1 -Chris.

Re: BiCollector

2018-06-18 Thread Chris Hegarty
> On 18 Jun 2018, at 22:29, Brian Goetz wrote: > > "bisecting" sounds like it sends half the elements to one collector and half > to the other ... > > "tee" might be a candidate, though it doesn't follow the `ing convention. > "teeing" sounds dumb. Doesn’t follow the convention either,

Re: RFR: JDK-8203891: Upgrade JOpt Simple to 5.0.4

2018-06-05 Thread Chris Hegarty
On 31/05/18 10:11, Jan Lahoda wrote: Hi, I'd like to upgrade the JOpt Simple library we are using to version 5.0.4. Bug: https://bugs.openjdk.java.net/browse/JDK-8203891 Complete webrev: http://cr.openjdk.java.net/~jlahoda/8203891/webrev.00/complete/ Delta webrev only showing (all) JDK

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

2020-04-06 Thread Chris Hegarty
> On 6 Apr 2020, at 17:03, Paul Sandoz wrote: > > ... >> On Apr 6, 2020, at 8:54 AM, Jim Laskey wrote: >> >> Updated webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 >> Woohoo. LGTM. -Chris.

Re: RFR 15 8243099: Adding ADQ support to JDK

2020-04-21 Thread Chris Hegarty
Vladimir, > On 18 Apr 2020, at 00:13, Ivanov, Vladimir A > wrote: > > Hello everyone, > I would like to add support for the Application Device Queue (ADQ) technology > to the JDK. > > The JBS entry and webrev were created for this improvement: > JBS:

Re: RFR: JDK-8243168 Remove addition preview adornment from String::stripIndent and String::translateEscapes

2020-04-20 Thread Chris Hegarty
> On 20 Apr 2020, at 16:07, Jim Laskey wrote: > > Cleaning up the JavaDoc. > > webrev: http://cr.openjdk.java.net/~jlaskey/8243168/webrev-00 > > jbs: https://bugs.openjdk.java.net/browse/JDK-8243168 >

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

2020-04-20 Thread Chris Hegarty
I skimmed over the webrev, the changes seem fine. Thanks for updating the record serialization tests that use ASM. -Chris. > On 17 Apr 2020, at 21:28, Vicente Romero wrote: > > ping, any other comment? are we ready to push this change? > > Vicente > > On 4/13/20 11:05 AM, Vicente Romero

RFR [15] 8241921: Remove leftover diagnostic from test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java

2020-03-31 Thread Chris Hegarty
Remove leftover diagnostic that dumps generated class from test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java At one point it was useful to be able to inspect the generated bytecode using javap, but it was noticed recently for a different reason that the output file is

Re: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact

2020-03-30 Thread Chris Hegarty
> On 30 Mar 2020, at 18:53, Joe Darcy wrote: > > Hello, > > Updated webrev at: > > http://cr.openjdk.java.net/~darcy/8241374.1/ > LGTM. -Chris.

Re: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact

2020-03-30 Thread Chris Hegarty
Joe, > On 29 Mar 2020, at 20:03, Joe Darcy wrote: > > Hi Stuart, > > Full webrev for review include including tests: > > http://cr.openjdk.java.net/~darcy/8241374.0/ > > and the companion CSR: > > https://bugs.openjdk.java.net/browse/JDK-8241805 Looks good to me. I do like the

Re: Review Request 8238195: Lookup::defineClass should link the class to match the specification

2020-04-02 Thread Chris Hegarty
> On 1 Apr 2020, at 19:43, Mandy Chung wrote: > .. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8238195/webrev.00/ LGTM. Trivially, you could update the copyright year range on the test. -Chris.

Re: Use Method.getParameterCount() where possible

2020-04-06 Thread Chris Hegarty
The changes look good to me. -Chris. > On 6 Apr 2020, at 11:44, Claes Redestad wrote: > > Hi, > > looks good and trivial to me. I'll sponsor. > > /Claes > > (I hope we can wrap up https://bugs.openjdk.java.net/browse/JDK-8029019 > some day, soon) > > On 2020-04-03 12:19, Christoph Dreis

Re: RFR: 8242186: Reduce allocations in URLStreamHandler.parseURL for some cases (Was: Re: [NEW BUG] Small optimization in URLStreamHandler.parseURL)

2020-04-06 Thread Chris Hegarty
> On 6 Apr 2020, at 11:29, Claes Redestad wrote: > > Hi, > > (including net-dev@.. since this is in java.net) > > I intend to sponsor this trivial patch provided by Christoph: > > diff -r 65b345254ca3 > src/java.base/share/classes/java/net/URLStreamHandler.java > ---

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

2020-04-30 Thread Chris Hegarty
Maurizio, > On 30 Apr 2020, at 15:35, Maurizio Cimadamore > wrote: > > Looks good - thanks. Perhaps I'd tweak "will hold" and replace it with "will > feature", and also add a link between "access modes" to the access mode > section of the javadoc, to make it more navigable. Done.

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

2020-04-30 Thread Chris Hegarty
Maurizio, > On 23 Apr 2020, at 21:33, Maurizio Cimadamore > wrote: > > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v2/javadoc > I’m still working my way through this update ( BTW it’s looking very good ), but an initial comment on the API. The access modes of

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

2020-05-14 Thread Chris Hegarty
Hi Mandy, > On 14 May 2020, at 21:12, 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 API. >

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

2020-05-13 Thread Chris Hegarty
> On 13 May 2020, at 13:12, Maurizio Cimadamore > wrote: > > Another iteration which addresses the latest CSR comments (the CSR has now > been approved): > > * make MemorySegment::withAccessModes/hasAccessMode throw > IllegalArgumentException in cases where the provided mask is invalid

Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

2020-03-23 Thread Chris Hegarty
> On 23 Mar 2020, at 19:18, Alan Bateman wrote: > >> ... >> > Socket(SocketImpl) is only specified to do a permission check when the impl > is non-null. The socket adaptor in JDK 12 and older releases doesn't have a > dummy impl so the change should not be needed. If there is a security >

Re: JDK14 spec query : MethodHandles:dropLookupMode(int)

2020-03-09 Thread Chris Hegarty
Mandy, > On 9 Mar 2020, at 16:37, Mandy Chung wrote: > > I have bcc'ed jdk-dev and add core-libs-dev mailing list where this thread > should be discussed. > > The spec says: > > "When dropping PACKAGE then the resulting lookup will not have PACKAGE or > PRIVATE access. When dropping

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

2020-05-20 Thread Chris Hegarty
> On 20 May 2020, at 15:01, Maurizio Cimadamore > wrote: > > Another very small iteration which fixes a gap in the javadoc specification > for MemorySegment::toArray (thanks Chris!) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev > > Delta webrev: > >

Re: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs

2020-09-16 Thread Chris Hegarty
On Tue, 15 Sep 2020 19:40:28 GMT, Phil Race wrote: >> This issue relates to JDK-8250639 '☂ Address reliance on default >> constructors in the java.desktop module'. The >> following classes have had an explicit no-arg constructor added, with a >> protected access modifier and accompanying API

Re: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v3]

2020-09-09 Thread Chris Hegarty
On Tue, 8 Sep 2020 19:44:21 GMT, Roger Riggs wrote: >> 8252830: Correct missing javadoc comments in java.rmi module > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Added java.io.Serial to java.rmi.activation.ActivationID

Re: RFR: 8251989: Hex formatting and parsing utility [v4]

2020-10-16 Thread Chris Hegarty
On Thu, 15 Oct 2020 18:22:12 GMT, Roger Riggs wrote: >> Marked as reviewed by dfuchs (Reviewer). > > Please review the corresponding CSR: > https://bugs.openjdk.java.net/browse/JDK-8251991 Hi Roger, This looks very good. I have a few minor comments: 1. Add an explicit type parameter to

Integrated: 8254161: Prevent instantiation of EnumSet subclasses through deserialization

2020-10-16 Thread Chris Hegarty
On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty wrote: > TL;DR add EnumSet::readObjectNoData() > > EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it > should strictly implement that pattern and demonstrate how best to > defend against inappropriate instan

Re: RFR: 8251989: Hex formatting and parsing utility [v4]

2020-10-16 Thread Chris Hegarty
On Fri, 16 Oct 2020 15:22:37 GMT, Roger Riggs wrote: >> The HexFormat API currently uses an indexing model for arrays and strings >> based on an index and a length. >> Many other APIs in the JDK use an index model of `fromIndex` and `toIndex` >> (exclusive). >> >> They are equivalent and

Re: RFR: 8251989: Hex formatting and parsing utility [v4]

2020-10-16 Thread Chris Hegarty
On Fri, 16 Oct 2020 14:00:38 GMT, Roger Riggs wrote: > Since the instances are immutable, it seemed useful to emphasize that only > the instance returned has the requested > change. Discarding the return value was incorrect programming. The original > instance is not modified. Understood, and

Re: RFR: 8251989: Hex formatting and parsing utility [v4]

2020-10-16 Thread Chris Hegarty
On Fri, 16 Oct 2020 11:46:47 GMT, Chris Hegarty wrote: >> Please review the corresponding CSR: >> https://bugs.openjdk.java.net/browse/JDK-8251991 > > Hi Roger, > > This looks very good. > > I have a few minor comments: > > 1. Add an explicit type param

Re: RFR: 8251989: Hex formatting and parsing utility [v6]

2020-10-20 Thread Chris Hegarty
On Mon, 19 Oct 2020 22:52:31 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, >> prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with >> modified

Re: RFR: 8251989: Hex formatting and parsing utility [v6]

2020-10-20 Thread Chris Hegarty
On Mon, 12 Oct 2020 22:17:58 GMT, Marcono1234 wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Correct length of StringBuilder in formatHex; >> Correct bug in formatHex(char[], 2, 3) and add test for subranges of

Re: RFR 8251989: Hex encoder and decoder utility

2020-08-20 Thread Chris Hegarty
> On 19 Aug 2020, at 22:14, Roger Riggs wrote: > > .. > JavaDoc: > http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html I like it Roger, very nice. A few minor comments/quibbles: Hex: - "Utilities to encode bytes to hex strings and decode hex strings to bytes.” -

Re: RFR 8251989: Hex formatter and parser utility

2020-08-27 Thread Chris Hegarty
Roger, > On 27 Aug 2020, at 02:34, Roger Riggs wrote: > > Please review updates to the formatting and parsing API based on the last > round of comments. > There are many changes, so it may be useful to read it as a fresh draft. > > - Rename classes: Encoder -> Formatter; Decoder -> Parser >

Re: RFR: 8246774: Record Classes (final) implementation

2020-09-22 Thread Chris Hegarty
On Mon, 21 Sep 2020 23:21:18 GMT, Vicente Romero wrote: >> Hi Vicente, >> Please file a separate subtask for the javax.lang.model changes. This helps >> with the JSR 269 MR paperwork. >> Thanks, >> -Joe > > note: I have removed from the original patch the code related to > javax.lang.model, I

Re: RFR 8246040: java/foreign/TestAddressHandle fails on big endian platforms

2020-05-29 Thread Chris Hegarty
> On 29 May 2020, at 12:21, Maurizio Cimadamore > wrote: > ... > > http://cr.openjdk.java.net/~mcimadamore/8246040_v1/webrev/ > LGTM. -Chris.

Re: RFR 8246095: Tweaks to memory access API

2020-05-29 Thread Chris Hegarty
> On 28 May 2020, at 22:25, Maurizio Cimadamore > wrote: > > Hi, > this followup change includes a number of tweaks that have been added to the > memory access API while we were in the process of integrating it. Most of > them have been contributed by Chris (thanks!), and are all listed in

RFR [15] 8238763: ObjectInputStream readUnshared method handling of Records

2020-06-02 Thread Chris Hegarty
This is a small change to ObjectInputStream, for 8238763 [1], to correctly handle readUnshared for records. Webrev: https://cr.openjdk.java.net/~chegar/8238763/webrev.00/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8238763

Re: RFR: 8255449: Improve the exception message of MethodHandles::permuteArguments

2020-10-28 Thread Chris Hegarty
On Wed, 28 Oct 2020 09:20:54 GMT, Aleksey Shipilev wrote: >> Hi, >> >> Currently, if MethodHandles::permuteArguments is used with a reorder array >> that is the wrong size, or one of the indexes in it is out of bounds of the >> new type, we simply get the exception message: >> >> bad

Re: RFR: 8255449: Improve the exception message of MethodHandles::permuteArguments [v3]

2020-10-28 Thread Chris Hegarty
On Wed, 28 Oct 2020 14:30:30 GMT, Chris Hegarty wrote: >> I've added some negative tests that test for the different failure >> conditions. > > Thanks for adding additional test coverage @JornVernee. > > Writing a tight implementation of assertThrows is no

Re: RFR: 8255449: Improve the exception message of MethodHandles::permuteArguments [v2]

2020-10-28 Thread Chris Hegarty
On Wed, 28 Oct 2020 13:32:19 GMT, Jorn Vernee wrote: >>> >>> >>> Seems like a reasonable change. Is there an already existing test for "bad" >>> permute args that could be expanded to discern the new exception message? >> >> There are several tests for permuteArguments, but none that

Re: RFR: 8255449: Improve the exception message of MethodHandles::permuteArguments [v3]

2020-10-28 Thread Chris Hegarty
On Wed, 28 Oct 2020 14:57:44 GMT, Jorn Vernee wrote: >> Hi, >> >> Currently, if MethodHandles::permuteArguments is used with a reorder array >> that is the wrong size, or one of the indexes in it is out of bounds of the >> new type, we simply get the exception message: >> >> bad reorder

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

2020-07-13 Thread Chris Hegarty
> On 1 Apr 2020, at 23:46, Paul Sandoz wrote: > > 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: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang private fields should be removed

2020-07-10 Thread Chris Hegarty
> On 9 Jul 2020, at 23:23, huizhe.w...@oracle.com wrote: > > ... > > webrev: http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/ > Looks good. Reviewed. -Chris.

Re: RFR: 8247532: Records deserialization is slow

2020-06-17 Thread Chris Hegarty
> On 17 Jun 2020, at 07:08, Peter Levart wrote: > > > On 6/16/20 5:15 PM, Chris Hegarty wrote: >> The caching is on a per-stream-field shape basis, which should be consistent >> in the common case, but of course is not always guaranteed to be the case, >> h

Re: RFR: 8247532: Records deserialization is slow

2020-06-17 Thread Chris Hegarty
> On 17 Jun 2020, at 06:44, Peter Levart wrote: >>> .. >> If there is a way for a test to compile several versions of the same >> (record) class and then produce byte streams with it, then we could simulate >> various class-evolution cases (field missing, surplus field, change of field >>

Re: (15) RFR: JDK-8247444: Trust final fields in records

2020-06-18 Thread Chris Hegarty
> On 18 Jun 2020, at 13:43, Aleksey Shipilev wrote: > >> ... > > Again, JDK-8247532 is the writing on the wall: we don't need 3rd party > developers to tell if Record > serialization works fast in 15 -- we already know it does not. I disagree. JDK-8247532 is under review and well on its

Re: RFR: 8247532: Records deserialization is slow

2020-06-17 Thread Chris Hegarty
Peter, > On 17 Jun 2020, at 09:23, Chris Hegarty wrote: > >> On 17 Jun 2020, at 06:44, Peter Levart wrote: >>>> .. >>> If there is a way for a test to compile several versions of the same >>> (record) class and then produce byte streams with it,

RFR [15] 8247696: Incorrect tail computation for large segments in AbstractMemorySegmentImpl::mismatch

2020-06-17 Thread Chris Hegarty
The MemorySegment::mismatch implementation added vectorized mismatch of long sizes. The implementation is trivial, but the starting point for a more optimized implementation, if needed. ArraysSupport::vectorizedMismatchLarge incorrectly returns the bitwise complement of the offset of the first

Re: RFR [15] 8247789: Remove use of reflection from test/jdk/java/io/Serializable/records/StreamRefTest.java

2020-06-18 Thread Chris Hegarty
> On 18 Jun 2020, at 14:56, Roger Riggs wrote: > > Hi Chris, > > It may be prudent to check that the current value in the byte array is the > one you expect > before changing it. > That would help catch tests if something else changes the contents of the > stream. Good idea Roger. Done.

RFR [15] 8247789: Remove use of reflection from test/jdk/java/io/Serializable/records/StreamRefTest.java

2020-06-18 Thread Chris Hegarty
This is a small change to remove the use of reflection to fabricate "bad" serial data - in order to verify constructor invariants for record serialization tests. Instead, it is straight forward to just modify a single value in the byte stream, that results in the same.

Re: RFR [15] 8247696: Incorrect tail computation for large segments in AbstractMemorySegmentImpl::mismatch

2020-06-19 Thread Chris Hegarty
d rely on other tests to ensure the intrinsic method is operating >>> efficiently. >>> >>> >>> 2) This method only works when operating on byte arrays. It will not work >>> correctly if operating on short or long arrays, since we are not adjusting

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

2020-06-23 Thread Chris Hegarty
> On 23 Jun 2020, at 10:46, Chris Hegarty wrote: > > > >> On 23 Jun 2020, at 10:17, Peter Levart wrote: >> >> ... >> http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.08/ > > Good stuff. Reviewed. > > I am going t

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

2020-06-23 Thread Chris Hegarty
> On 23 Jun 2020, at 10:17, Peter Levart wrote: > > ... > http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.08/ Good stuff. Reviewed. I am going to take this latest change and run it through our internal build and test system. Will post the results here soon.

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

2020-06-23 Thread Chris Hegarty
> On 23 Jun 2020, at 14:49, Peter Levart wrote: > > ... > > Ok, I'm going to push this to jdk15. Thank you Peter. This is a really nice change. As a follow on, and not for JDK 15, I observe that Class::isRecord0 / JVM_IsRecord shows up as consuming a significant amount of time, more than

Re: RFR [15] 8247696: Incorrect tail computation for large segments in AbstractMemorySegmentImpl::mismatch

2020-06-22 Thread Chris Hegarty
Paul pointed out an issue, off list, where subsequent subranges could still result in a call to the intrinsic. That is now fixed in-place and the test amended to cover the scenario. https://cr.openjdk.java.net/~chegar/8247696/webrev.01/ -Chris. > On 19 Jun 2020, at 11:56, Chris Hegarty wr

RFR [1]6 8248326 Add a minimal serialization test for local records

2020-06-25 Thread Chris Hegarty
While working on some record serialization changes recently, I noticed that we don’t have any coverage for local records. Here is a simple extension to an existing records test. diff -r 4e186efa6cbf test/jdk/java/io/Serializable/records/BasicRecordSer.java ---

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

2020-06-24 Thread Chris Hegarty
poking the bear!). If we encode these single state bits into a modifiers-like value, then we can treat them as such (without needing them to be “real” modifiers). And this should address any potential bloating concerns. -Chris. > Regards, Peter > > > > On 6/24/20 10:20 AM,

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

2020-06-24 Thread Chris Hegarty
> On 24 Jun 2020, at 07:03, David Holmes wrote: > > Hi Chris, > > On 24/06/2020 2:30 am, Chris Hegarty wrote: >>> On 23 Jun 2020, at 14:49, Peter Levart wrote: >>> >>> ... >>> >>> Ok, I'm going to push this to jdk15. >

Re: RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

2020-06-24 Thread Chris Hegarty
> On 24 Jun 2020, at 17:15, Claes Redestad wrote: > > ... > It seems ObjectInputStream#isRecord(Class) is now unused. No need for > a new webrev if you choose to remove it. Good catch, now removed. > On 24 Jun 2020, at 17:25, Peter Levart wrote: > > Hi Chris, > > The patch looks good. >

RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

2020-06-24 Thread Chris Hegarty
A micro-optimisation noticed when working on JDK-8247532. For further details see: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067446.html Webrev: https://cr.openjdk.java.net/~chegar/8248233/webrev.00/ before: RecordSerializationBench.deserializeClasses10

Re: RFR [1]6 8248326 Add a minimal serialization test for local records

2020-06-26 Thread Chris Hegarty
code, and this issue is narrowly focused on testing local records, then I’ll respectively decline the suggestion. If checking of the hash code is beneficial, we can consider it separately and in a larger context. -Chris. > best regards, > > -- daniel > > On 25/06/2020 16:01, Chris Heg

Re: RFR: 8247532: Records deserialization is slow

2020-06-16 Thread Chris Hegarty
Hi Peter, > On 14 Jun 2020, at 17:28, Peter Levart wrote: > > ... > > [2] > http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.01/ > I think that this is very good. It’s clever to build a chain of method handles that can be invoked with the stream field values. This

Re: RFR: 8247532: Records deserialization is slow

2020-06-15 Thread Chris Hegarty
Hi Peter, Thank you for doing this, it is really appreciated. I’m going to take this patch and run it in my local environment, after which I’ll post a reply here. > So WDYT? Since this is still a preview feature in JDK15, is it possible to > squeeze it into JDK15? I think that such a change

Re: RFR: 8247532: Records deserialization is slow

2020-06-15 Thread Chris Hegarty
mance "bug", right? That would be the categorisation that I would use. -Chris. > > Peter > > On 6/15/20 10:37 AM, Chris Hegarty wrote: >> Hi Peter, >> >> Thank you for doing this, it is really appreciated. I’m going to take this >> patch and run it in my l

Re: RFR: 8247532: Records deserialization is slow

2020-06-22 Thread Chris Hegarty
Peter, Thank you for taking the suggestion for additional test scenarios, improving coverage, and finding-and-fixing the issues in my hurried test builder (was only meant as a rough guide/idea). I agree with Claes, it would be good to include the microbenchmark in test/micro/.. I think this

Re: RFR [15] 8247696: Incorrect tail computation for large segments in AbstractMemorySegmentImpl::mismatch

2020-06-18 Thread Chris Hegarty
Bytes and drop the > log2ArrayIndexScale argument. Then expand later if need be. I still think the > method rightly belongs in ArraysSupport. Sounds reasonable. -Chris. > Paul. > >> On Jun 17, 2020, at 8:33 AM, Chris Hegarty wrote: >> >> The MemorySegment::mismatc

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

2020-06-04 Thread Chris Hegarty
Mandy, I think this looks good. Just a few minor comments... The spec wording is hard, since the method is offering a conditional initialization. I guess I expected to see something like “initializes targetClass, if it has not been initialized already”, or some such. The input and output is

Re: RFR 8246095: Tweaks to memory access API

2020-06-03 Thread Chris Hegarty
LGTM. The illustrative example in asUnsigned is nice ( I should have thought of similar, D’oh! ) -Chris. > On 3 Jun 2020, at 15:25, Maurizio Cimadamore > wrote: > > Please review this delta patch; I realized that the previously submitted > patch had few issues: > > * copyright header on

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

2020-06-05 Thread Chris Hegarty
> On 4 Jun 2020, at 21:16, Mandy Chung wrote: > > ... > I finalized an updated CSR per all feedbacks which includes the deprecation > `sun.misc.Unsafe::shouldBeInitialized`. >https://bugs.openjdk.java.net/browse/JDK-8245871 > > updated webrev: >

Re: RFR: JDK-8246098: API for Class::permittedSubclasses should clarify if returned elements are ordered or not

2020-06-11 Thread Chris Hegarty
> On 10 Jun 2020, at 23:23, Vicente Romero wrote: > > Please review this small change to the API for > java.lang.Class::permittedSubclasses which clarifies that no particular order > of the returned elements should be assumed by clients. The related bug is at > [1], the webrev at [2] and

Re: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle

2020-11-27 Thread Chris Hegarty
On Thu, 26 Nov 2020 19:24:16 GMT, Jorn Vernee wrote: > This upstreams the patch from: > https://github.com/openjdk/panama-foreign/pull/396 > > There were only some minor merge conflicts due to imports and some tests > being replaced by java/foreign/TestNulls. All tests still pass, no other >

Re: RFR: 8251989: Hex formatting and parsing utility [v10]

2020-11-27 Thread Chris Hegarty
On Wed, 25 Nov 2020 22:51:44 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, >> prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with >> modified

Re: RFR: 8251989: Hex formatting and parsing utility [v10]

2020-11-27 Thread Chris Hegarty
On Wed, 25 Nov 2020 22:51:44 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, >> prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with >> modified

Re: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle [v2]

2020-11-27 Thread Chris Hegarty
On Fri, 27 Nov 2020 12:28:01 GMT, Jorn Vernee wrote: >> This upstreams the patch from: >> https://github.com/openjdk/panama-foreign/pull/396 >> >> There were only some minor merge conflicts due to imports and some tests >> being replaced by java/foreign/TestNulls. All tests still pass, no

Re: RFR: 8257186: Size of heap segments is not computed correctlyFix overflow in size computation for heap segments

2020-11-27 Thread Chris Hegarty
On Thu, 26 Nov 2020 18:29:42 GMT, Maurizio Cimadamore wrote: > There is a subtle bug in the heap segment factories: the byte size is > computed using an int multiplication instead of a long multiplication. > Because of that, it is possible to observe overflow when creating segments > out of

Re: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle

2020-11-27 Thread Chris Hegarty
On Thu, 26 Nov 2020 19:24:16 GMT, Jorn Vernee wrote: > This upstreams the patch from: > https://github.com/openjdk/panama-foreign/pull/396 > > There were only some minor merge conflicts due to imports and some tests > being replaced by java/foreign/TestNulls. All tests still pass, no other >

Re: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols

2020-11-30 Thread Chris Hegarty
On Fri, 27 Nov 2020 13:21:15 GMT, Jan Lahoda wrote: > Adding support for record classes in the historical data for ct.sym. This > includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run > them. > -fixing Record

Re: RFR: 8251989: Hex formatting and parsing utility [v10]

2020-11-27 Thread Chris Hegarty
On Fri, 27 Nov 2020 16:51:02 GMT, Roger Riggs wrote: > It is the byte array that is formatted, the result is a hexadecimal string. I don't understand. How is the byte array formatter? Do we have "formatted byte arrays" and "unformatted byte arrays"? Are they formatted somehow with prefix,

Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v3]

2020-11-27 Thread Chris Hegarty
Maurizio, > On 27 Nov 2020, at 18:04, Maurizio Cimadamore > wrote: > > ... > Looks a great improvements. Two comments: > > * the names always mention the "Single" word, when in fact all benchmark > involve some kind of a loop. I'd suggest making that more explicit, both in > the benchmark

Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]

2020-11-30 Thread Chris Hegarty
; parameter was not always considered - this is now fixed. Chris Hegarty has updated the pull request incrementally with two additional commits since the last revision: - Add explicitly allocated heap carrier buffer tests - Replace Single with Loop - Changes: - all: https://git.

RFR: 8257074 Update the ByteBuffers micro benchmark

2020-11-25 Thread Chris Hegarty
The ByteBuffers micro benchmark seems to be a little dated. It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory

Re: RFR: 8257074 Update the ByteBuffers micro benchmark

2020-11-25 Thread Chris Hegarty
On Wed, 25 Nov 2020 13:12:34 GMT, Claes Redestad wrote: > I do wonder if there's some value to at least some of these noisy, allocating > variants, though. Could be interesting to zoom in on code where we allocate > transient, small buffers, e.g. when encoding/decoding strings. But perhaps >

Re: RFR: 8257074 Update the ByteBuffers micro benchmark

2020-11-25 Thread Chris Hegarty
On Wed, 25 Nov 2020 13:37:48 GMT, Maurizio Cimadamore wrote: > Looks like a good cleanup. I agree that mixing access and instantiation is > not good from a benchmark perspective - although, given that direct buffers > have a rather convoluted allocation process, I guess it would be useful, in

RFR: 8255904: Remove superfluous use of reflection in Class::isRecord

2020-11-24 Thread Chris Hegarty
Minor cleanup - Reflective access to j.l.Record is no longer required since it became standard. - Commit messages: - 8255904: Remove superfluous use of reflection in Class::isRecord Changes: https://git.openjdk.java.net/jdk/pull/1406/files Webrev:

Re: RFR: 8230501: Class data support for hidden classes [v4]

2020-11-24 Thread Chris Hegarty
On Mon, 23 Nov 2020 17:48:31 GMT, Mandy Chung wrote: > > It is my understanding that `Lookup` object returned from > > defineHiddenClass[WithClassData] features the ORIGINAL access lookup mode, > > right? I cannot find a normative statement to confirm this. If it is the > > case, then it

Re: RFR: 8256865: Foreign Memory Access and Linker API are missing NPE checks [v2]

2020-11-24 Thread Chris Hegarty
On Mon, 23 Nov 2020 18:22:14 GMT, Maurizio Cimadamore wrote: >> Both the Foreign Memory Access and the Foreign Linker APIs leave something >> to be desired when it comes to handling NPEs - first, most of the API >> javadoc is oblivious to NPEs being thrown. Secondly, not all API method >>

Re: RFR: 8230501: Class data support for hidden classes [v5]

2020-11-24 Thread Chris Hegarty
On Sat, 21 Nov 2020 00:39:23 GMT, Mandy Chung wrote: >> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live >> objects >> be shared between a hidden class and other classes. A hidden class can load >> these live objects as dynamically-computed constants via this API. >>

Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v2]

2020-11-26 Thread Chris Hegarty
; parameter was not always considered - this is now fixed. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Add additional carrier views and endianness variants. A large number of variants are now covered. The individual benchma

Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v3]

2020-11-26 Thread Chris Hegarty
; parameter was not always considered - this is now fixed. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: whitespace - Changes: - all: https://git.openjdk.java.net/jdk/pull/1430/files - new: https://git.openjdk.java.

Re: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored [v2]

2020-12-03 Thread Chris Hegarty
On Thu, 3 Dec 2020 09:58:16 GMT, Alan Bateman wrote: >> The attribute_length of known Module attributes in the module-info.class >> is currently ignored. It should be checked and the class rejected if the >> attribute length doesn't exactly match the length of the info in the >>

Re: RFR: 8257591: Remove suppression of record preview related warnings in java.lang

2020-12-03 Thread Chris Hegarty
On Thu, 3 Dec 2020 10:39:05 GMT, Julia Boes wrote: > Records exit preview in JDK 16. This change removes preview related > suppression warnings in some source files and removes the '--enable-preview' > option for compilation and execution of some tests that use record classes. Marked as

Re: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v5]

2020-12-07 Thread Chris Hegarty
since the JVM now allows > such classes that contain a Record Attribute to be loaded. Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Remove unused test helper method - Merge branch 'master' into isR

Integrated: 8255560: Class::isRecord should check that the current class is final and not abstract

2020-12-07 Thread Chris Hegarty
On Tue, 1 Dec 2020 19:34:11 GMT, Chris Hegarty wrote: > Update Class::isRecord to only return true for classes that are final. > > The removal of non-specified JVM checks on classes with a Record Attribute > (see JDK-8255342), has resulted in more types of loadable classes that ma

Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v6]

2020-12-04 Thread Chris Hegarty
On Fri, 4 Dec 2020 16:22:28 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this >>> iteration we are: >>> >>> * Enhancing narrowing

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended

2020-12-08 Thread Chris Hegarty
On Mon, 7 Dec 2020 23:47:40 GMT, Mandy Chung wrote: >> Please review this fix for JDK-8256867. This change no longer throws a >> ClassFormatError exception when loading a class whose PermittedSubclasses >> attribute is empty (contains no classes). Instead, the class is treated as >> a

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2]

2020-12-08 Thread Chris Hegarty
On Tue, 8 Dec 2020 14:10:26 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8256867. This change no longer throws a >> ClassFormatError exception when loading a class whose PermittedSubclasses >> attribute is empty (contains no classes). Instead, the class is treated as >> a

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3]

2020-12-08 Thread Chris Hegarty
On Tue, 8 Dec 2020 14:57:26 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8256867. This change no longer throws a >> ClassFormatError exception when loading a class whose PermittedSubclasses >> attribute is empty (contains no classes). Instead, the class is treated as >> a

Re: RFR: 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record [v2]

2020-12-08 Thread Chris Hegarty
On Tue, 8 Dec 2020 16:21:09 GMT, Julia Boes wrote: >> This change applies a stricter semantic distinction of 'type' versus 'class >> and interface'. This is based on the JLS changes described in the >> "Consistent Class and Interface Terminology" document: >>

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3]

2020-12-08 Thread Chris Hegarty
On Tue, 8 Dec 2020 17:18:20 GMT, Mandy Chung wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8256867: Classes with empty PermittedSubclasses attribute cannot be >> extended > >

Integrated: 8255904: Remove superfluous use of reflection in Class::isRecord

2020-11-25 Thread Chris Hegarty
On Tue, 24 Nov 2020 10:12:23 GMT, Chris Hegarty wrote: > Minor cleanup - Reflective access to j.l.Record is no longer required since > it became standard. This pull request has now been integrated. Changeset: cdb41ba1 Author: Chris Hegarty URL: https://git.openjdk.java.n

Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]

2020-12-10 Thread Chris Hegarty
On Mon, 30 Nov 2020 20:54:09 GMT, Brian Burkhalter wrote: >> Chris Hegarty has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Add explicitly allocated heap carrier buffer tests >> - Replace Single with Loop

  1   2   3   4   5   6   7   8   9   10   >