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

> On 11 Dec 2019, at 16:43, Paul Sandoz wrote: > > Looks very good, +1 This looks very good to me too. Nice work. -Chris. > Paul. > >> On Dec 11, 2019, at 7:39 AM, Maurizio Cimadamore >> wrote: >> >> I went ahead and created a new revision: >> >> http://cr.openjdk.java.net/~mcimadamore

Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

The changes to the SCTP code seem ok. -Chris. > On 17 Dec 2019, at 03:00, Patrick Zhang OS > wrote: > > Thanks Martin. > > Hi net-dev, and/or security-dev Reviewers, > > Please help review and sponsor this patch if acceptable. > It does not tend to bring any functionality changes, instead to

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

> On 6 Jan 2020, at 23:22, 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 should be declare

Re: RFR (14) 8236769: Clarify javadoc of memory access API

Maurizio, > On 8 Jan 2020, at 12:36, Maurizio Cimadamore > wrote: > > A link to the webrev might be useful I guess :-) > > http://cr.openjdk.java.net/~mcimadamore/8236769/ Mostly looks good. Trivially, regarding the use of implSpec in MemoryLayout; I think that the tag is just not needed, r

Re: RFR (14) 8236769: Clarify javadoc of memory access API

> On 8 Jan 2020, at 15:07, Chris Hegarty wrote: > > Maurizio, > >> On 8 Jan 2020, at 12:36, Maurizio Cimadamore >> wrote: >> >> A link to the webrev might be useful I guess :-) >> >> http://cr.openjdk.java.net/~mcimadamore/8236769/ Forgot

Re: RFR (14) 8236769: Clarify javadoc of memory access API

> On 8 Jan 2020, at 15:33, Maurizio Cimadamore > wrote: > > I've looked at the java.lang.constant.ClassDesc interface which is similar in > spirit to what MemoryLayout does: an interface that is not meant to be > implemented by the user. There are many default methods there, and no > implS

Re: RFR (14) 8236769: Clarify javadoc of memory access API

> On 8 Jan 2020, at 15:52, Maurizio Cimadamore > wrote: > > New revision: > > http://cr.openjdk.java.net/~mcimadamore/8236769_v2 > > delta from previous: > > http://cr.openjdk.java.net/~mcimadamore/8236769_v2_delta/ LGTM. -Chris.

Re: RFR (14) 8236779: static field in implementation class erroneously leaking in memory access javadoc

Maurizio, > On 8 Jan 2020, at 16:06, Maurizio Cimadamore > wrote: > > Please review this one liner, which is to fix a static implementation field > leaking through the memory access API javadoc: > > cr.openjdk.java.net/~mcimadamore/8236779 Looks good. > And corresponding CSR here: > > http

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

Maurizio, > On 9 Jan 2020, at 14:36, Maurizio Cimadamore > wrote: > > Hi, > following the JEP 370 code review and CSR, certain comments that have not > been addressed have been added to the tracker issue: > > https://bugs.openjdk.java.net/browse/JDK-8235837 > > For further evaluation. After

Re: JDK 14 RFR of JDK-8236877: Add "record" to descriptions in java.lang.{annotation, reflect}

On 09/01/2020 19:22, Joe Darcy wrote: Hello, As noted by Werner [1], one of the discussions of the kinds of types in java.lang.annotation was not updated for records. I checked java.lang.annotation, java.lang.reflect, and java.lang.Class and found another location to update:     JDK-8236

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

> On 9 Jan 2020, at 18:36, Maurizio Cimadamore > wrote: > > New revision: > > http://cr.openjdk.java.net/~mcimadamore/8235837_v2 > > delta from previous iteration: > > http://cr.openjdk.java.net/~mcimadamore/8235837_v2_delta > > javadoc > > http://cr.openjdk.java.net/~mcimadamore/8235837

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

> On 13 Jan 2020, at 13:14, Daniel Fuchs wrote: > > On 13/01/2020 10:28, Seán Coffey wrote: >> some off line comments suggested that I could move the jar initialization >> checks to the EventHelper class. With that in place, the EventHelper utility >> class should never initialize the loggin

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

> On 13 Jan 2020, at 17:19, Seán Coffey wrote: > > Thanks for the reviews. All callers of EventHelper log methods are ensuring > that isLoggingSecurity() is true before proceeding. I've added an assert null > check in the 4 logger methods to ensure expectations are in place. > > http://cr.o

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

> On 14 Jan 2020, at 18:30, 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) > always ha

RFR [14] 8234782: Discuss evolution of records in serialization spec

As raised in the CSR feedback for records [1], evolution of serializable records should be discussed in the updates to the serialization spec. The most significant aspects of serialization evolution concerning records are 1) adding and removing record components, and 2) the compatible scenarios wh

Re: RFR (14) 8237348: Javadoc of MemorySegment::allocateNative should state that memory is zero-initialized

> On 16 Jan 2020, at 11:49, Maurizio Cimadamore > wrote: > > Hi, > there is a mistake in the javadoc of MemorySegment::allocateNative -as the > javadoc says that the initialization state is unspecified, where in reality > we do call setMemory on the allocated block (so that memory contents

Re: RFR (14) 8237370: Javadoc of memory access API still refers to old MemoryAddress::offset method

> On 16 Jan 2020, at 15:40, Maurizio Cimadamore > wrote: > > Small patch which fixes some @code snippets still showing > MemoryAddress::offset(long) instead of MemoryAddress::addOffset(long) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8237370/ LGTM. -Chris.

Re: RFR [14] 8234782: Discuss evolution of records in serialization spec

> On 15 Jan 2020, at 15:01, Chris Hegarty wrote: > > As raised in the CSR feedback for records [1], evolution of serializable > records should be discussed in the updates to the serialization spec. > > The most significant aspects of serialization evolution concerning >

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

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 MODULE

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

Mandy, > On 9 Mar 2020, at 18:55, Mandy Chung wrote: > > ... > > Here is the spec clarification I am thinking of that may explain why the > focus is not whether MODULE bit is set or not. > > @@ -1524,14 +1524,20 @@ > * Creates a lookup on the same lookup class which this lookup obje

Re: Review Request: JDK-8240242: improve the javadoc for Lookup::dropLookupModes w.r.t. dropping UNCONDITIONAL

This looks good to me Mandy. Thanks, -Chris. > On 10 Mar 2020, at 18:27, Mandy Chung wrote: > > Hi Chris, > > Below is the revised patch per your suggestion. I made some minor fixes in > the method name shown in the "Access modes" section as well. > > Mandy > > diff --git a/src/java.base/s

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

> 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 > e

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

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 expl

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

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

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

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 alway

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

> 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: RFR: 8242186: Reduce allocations in URLStreamHandler.parseURL for some cases (Was: Re: [NEW BUG] Small optimization in URLStreamHandler.parseURL)

> 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 > --- a/src/java.base/share/

Re: Use Method.getParameterCount() where possible

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 wro

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

> 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: 8037384: Fix wording in Javadoc of java.io.Serializable

On Thu, 19 Nov 2020 03:44:10 GMT, Stuart Marks wrote: > 8231547: Serializable class doc should link to serialization specification > > Rewrite a couple confusing sentences in the Serializable class doc. This does > affect normative text, but the edits are primarily to focus and clarify the > t

Re: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable [v2]

On Thu, 19 Nov 2020 23:36:20 GMT, Stuart Marks wrote: >> 8231547: Serializable class doc should link to serialization specification >> >> Rewrite a couple confusing sentences in the Serializable class doc. This >> does affect normative text, but the edits are primarily to focus and clarify >>

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

On Thu, 19 Nov 2020 11:08:26 GMT, Jorn Vernee wrote: >> Mandy Chung has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix the name passed to condy calling classData > > Left 2 minor comments on the new additions in line. It is my understa

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

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 >> imp

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

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 would

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

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. >> >

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

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: https://webrevs.openjdk.java.net/

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

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: 8256865: Foreign Memory Access and Linker API are missing NPE checks [v7]

On Tue, 24 Nov 2020 16:01:15 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 >> imp

RFR: 8257074 Update the ByteBuffers micro benchmark

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 acce

Re: RFR: 8257074 Update the ByteBuffers micro benchmark

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 > t

Re: RFR: 8257074 Update the ByteBuffers micro benchmark

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

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

; 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]

; 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: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle

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: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle

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: 8257186: Size of heap segments is not computed correctlyFix overflow in size computation for heap segments

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 a

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

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 parame

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

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 parame

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

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 othe

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

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, d

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

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 m

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

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 att

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

; 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.

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

On Tue, 1 Dec 2020 11:18:11 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

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

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 may contain a Record Attribute. Since these checks are not performed by the JVM

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

since the JVM now allows > such classes that contain a Record Attribute to be loaded. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Mandy's review comments - Changes: - all: https://git.openjdk.java.net/jdk/pu

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

On Tue, 1 Dec 2020 19:56:25 GMT, Mandy Chung wrote: >> Chris Hegarty has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Mandy's review comments > > src/java.base/share/classes/java/lang/Class.java

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

since the JVM now allows > such classes that contain a Record Attribute to be loaded. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: review comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/1543/files

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

since the JVM now allows > such classes that contain a Record Attribute to be loaded. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: fix issue in ByteCodeLoader - Changes: - all: https://git.openjdk.java.net/jdk/p

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

On Tue, 1 Dec 2020 21:04:34 GMT, Mandy Chung wrote: > `{@link ... final}` should be `@linkplain`. Otherwise, looks good. Oops! Yes, changed. - PR: https://git.openjdk.java.net/jdk/pull/1543

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

On Wed, 2 Dec 2020 12:11:16 GMT, Jan Lahoda wrote: >> Yes, would be a surprise if getPermittedSubclasses returned Class objects >> for classes that are not subclasses. I think it should be okay to separate >> that out to a separate issue so that it can be further re-examined after JEP >> 397 g

Re: RFR: 8256679: Update serialization javadoc once JOSS changes for records are complete

On Wed, 2 Dec 2020 14:51:23 GMT, Julia Boes wrote: > Now that the changes for record serialization are integrated into the Java > Object Serialization Specification, this change updates the serialization > javadocs in ObjectInputStream, ObjectOutputStream, Serializable and > java.lang.Record.

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

On Wed, 2 Dec 2020 17:39:59 GMT, Jan Lahoda wrote: > ... > Uh, I just realized it may be necessary to implement `Class.isSealed()` > differently. Consider: > > ``` > sealed class Sealed permits Unknown {} > ``` > > Where `Unknown` does not exist at runtime. So getPermittedSubclasses0() > retu

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

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 review

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

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 >> attribute.

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

On Wed, 2 Dec 2020 16:33:15 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 paramet

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

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 refe

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

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'

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

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: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended

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 sealed

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

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 seal

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

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 seal

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

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: >> https://download.java.net/java/ear

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

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 > > src/java.base/share/classes/java/la

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

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

Re: RFR: 8257596: Clarify trusted final fields for record classes

On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on > classes with `RecordComponents` attributes. That introduces a regression in > `InstanceKlass::is_record` that returns true on a non-record class which has > `Rec

Re: RFR: 8257837: Performance regression in heap byte buffer views

On Thu, 10 Dec 2020 13:15:41 GMT, Maurizio Cimadamore wrote: > As a result of the recent integration of the foreign memory access API, some > of the buffer implementations now use `ScopedMemoryAccess` instead of > `Unsafe`. While this works generally well, there are situations where profile >

Re: [jdk16] RFR: 8257598: Clarify what component values are used in Record::equals

On Fri, 11 Dec 2020 05:02:25 GMT, Vicente Romero wrote: > Please review this patch which modifies the spec for method > java.lang.Record::equals. It states that the implementation of this method > should use the record fields for the comparison instead of the accessors. > > TIA, > Vicente The

Re: [jdk16] RFR: 8257598: Clarify what component values are used in Record::equals [v2]

On Fri, 11 Dec 2020 15:52:13 GMT, Vicente Romero wrote: >> Please review this patch which modifies the spec for method >> java.lang.Record::equals. It states that the implementation of this method >> should use the record fields for the comparison instead of the accessors. >> >> TIA, >> Vicent

Re: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes

On Fri, 11 Dec 2020 17:58:33 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on > classes with RecordComponents attributes. > > See the discussion at > https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html > > T

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

On Sat, 31 Oct 2020 19:37:10 GMT, Stuart Marks wrote: >> I believe this changes is useful and still actual: >> 1. improve code to make it easier to read. >> 2. performance should be improved a bit too > > I’ll see if I can get somebody to take a look at this. This seems like a reasonable change,

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v3]

On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in >> java.base > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8258422: Cleanup unnecess

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4]

On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in >> java.base > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8258422: Cleanup unnecess

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

; parameter was not always considered - this is now fixed. Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits

Re: RFR: 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping.

On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs wrote: > Hi, > > Please find an almost trivial fix for: > 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default > executor when stopping. > > The HttpClient should shutdown his executor when stopping, when the executor > was

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4]

On Thu, 17 Dec 2020 13:16:31 GMT, Aleksei Efimov wrote: >> Andrey Turbanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8258422: Cleanup unnecessary null comparison before instanceof check in >> java.base >> take advantage of "flow

Re: [jdk16] RFR: 8259027: NullPointerException in makeMappedSegment due to NULL Unmapper when length of segment is 0

On Tue, 5 Jan 2021 12:56:49 GMT, Maurizio Cimadamore wrote: > When the size of the memory map is zero, FileChannelImpl returns a `null` > Unmapper - this creates issues to the mapped memory segment implementation. > > To fix, I've created an empty mapped segment class which is initialized to

Re: [jdk16] RFR: 8259027: NullPointerException in makeMappedSegment due to NULL Unmapper when length of segment is 0 [v2]

On Tue, 5 Jan 2021 15:42:11 GMT, Maurizio Cimadamore wrote: >> When the size of the memory map is zero, FileChannelImpl returns a `null` >> Unmapper - this creates issues to the mapped memory segment implementation. >> >> To fix, I've created an empty mapped segment class which is initialized

Re: [jdk16] RFR: 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl [v2]

On Wed, 6 Jan 2021 16:32:17 GMT, Maurizio Cimadamore wrote: >> This patch tweaks `MemorySegment::mapFile` so that it will throw >> `IllegalArgumentException` whenever the path to be mapped is associated with >> a custom file system provider. >> >> The check in the implementation is heavily bo

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4]

On Fri, 8 Jan 2021 13:20:38 GMT, Aleksei Efimov wrote: >> This issue is blocked by [8258657][1]. It should not be integrated until >> after 8258657 has been resolved. The JIRA issues have been linked up to >> reflect this. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8258657 > > [JDK-82

Re: [jdk16] RFR: 8259634: MemorySegment::asByteBuffer does not respect spatial bounds

On Tue, 12 Jan 2021 15:28:20 GMT, Maurizio Cimadamore wrote: > The byte buffers created from heap segments do not honor the javadoc - which > says that the resulting buffer size should be equal to > MemorySegment::byteSize, and that the buffer position should be zero. > > The issue is that th

Re: [jdk16] RFR: 8259636: Check for buffer backed by shared segment kicks in in unexpected places

On Tue, 12 Jan 2021 15:48:18 GMT, Maurizio Cimadamore wrote: > When support for shared segment was added, we decided to disable support for > buffers derived from shared segment in certain async operations, as there's > currently no way to make sure that the memory won't be reclaimed while the

Re: RFR: 8259947: Optimize UnixPath.encode

On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad wrote: > This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which > has fast-paths for common encoding) and avoiding a `toCharArray` call on the > input by refactoring the `normalizeNativePath` code to operate on `String`. >

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

On Thu, 10 Dec 2020 14:01:56 GMT, Jorn Vernee wrote: >> While the updated set of scenarios covered by this benchmark is >> reasonably (and vastly improves coverage), I find myself reluctant to >> add the last remaining buffer property - read-only views. It's time to >> template the generation of

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

; parameter was not always considered - this is now fixed. Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the

Integrated: 8257074 Update the ByteBuffers micro benchmark

On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty wrote: > 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. > Mo

Re: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names [v2]

On Thu, 4 Feb 2021 16:14:57 GMT, Claes Redestad wrote: >> This patch resolves a potential memory leak in >> Java_java_lang_ClassLoader_defineClass0 >> >> I've not figured a good way to write a regression test. A crude way to >> manually verify the leak and the fix is provided by the added micr

RFR: 8261160: Add a deserialization JFR event

This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event

Re: RFR: 8261160: Add a deserialization JFR event

On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java > deserialization. The event captures the details of deserialization activity > from ObjectInputStream. The event details are similar to that of the serial

Re: RFR: 8261160: Add a deserialization JFR event [v2]

alled or not. The event > also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Review comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files

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