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: [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: 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: 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: 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: 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: 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: 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

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: [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: [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: 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: 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: 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: 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: 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: 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 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: 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

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

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: 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'

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: 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: 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: 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: 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: 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) [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: 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: 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 [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 [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 [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

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

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

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 [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: 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: 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 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: 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: 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: 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: 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

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

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

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

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

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/

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

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: 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 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: 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: 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: 8256189: Exact VarHandle tests should test withInvokeBehavior() works as expected

On Tue, 17 Nov 2020 18:32:30 GMT, Jorn Vernee wrote: > This PR sharpens the testing done by > test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after > @mcimadamore reported that the test was not catching an issue with memory > access var handles; namely that the implementation of w

Re: RFR: 8256477: Specialize heap memory segment implementations

On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore wrote: > The current memory segment implementation defines a hierarchy with 3 concrete > classes: one for heap segments, one for native segments and one for mapped > segments. > > Since there can be many kinds of heap segments (e.g. create

Re: RFR: 8256063: Module::getPackages on an unnamed module may return packages that are in a named module

On Wed, 11 Nov 2020 23:02:49 GMT, Mandy Chung wrote: > If `Module::getPackages` is invoked on the unnamed module of a class loader > then the set of packages returned will include the packages of any named > modules > that are defined to that class loader. This is a spec and implementation bug.

Re: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle combinator [v14]

On Tue, 10 Nov 2020 15:02:08 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch adds an asExact() combinator to VarHandle, that will return a new >> VarHandle that performs exact type checks, similar to >> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, >> which can

Re: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v6]

> On 5 Nov 2020, at 18:11, Alex Buckley wrote: > > On 11/5/2020 4:45 AM, Jan Lahoda wrote: >> FWIW, a javadoc generated with the current version of the patch: >> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html > > Allow me to draw people's attention to the PREVIEW lin

Re: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle combinator [v12]

On Mon, 2 Nov 2020 11:22:07 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch adds an asExact() combinator to VarHandle, that will return a new >> VarHandle that performs exact type checks, similar to >> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, >> which can l

Re: RFR: 8255862: Remove @SuppressWarnings from sun.misc.Unsafe

On Tue, 3 Nov 2020 23:56:34 GMT, Mandy Chung wrote: > Record classes are now a standard feature in 16. @SuppressWarnings can be > removed from sun.misc.Unsafe. Marked as reviewed by chegar (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1049

Re: RFR: 8255863: Clean up test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java

On Tue, 3 Nov 2020 23:55:24 GMT, Mandy Chung wrote: > test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java tests a record > class. > This test no longer needs to be run with --enable-preview. Marked as reviewed by chegar (Reviewer). - PR: https://git.openjdk.java.net/jdk/pul

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

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 non-trivi

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

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 a

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

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 explicit

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

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 reor

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

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 formatting and parsing utility [v6]

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 parame

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

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 conve

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

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]

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 [v4]

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 t

Integrated: 8254161: Prevent instantiation of EnumSet subclasses through deserialization

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: 8246774: Record Classes (final) implementation

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 w

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

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]

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 Ma

Re: RFR 8251989: Hex formatter and parser utility

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 8251989: Hex encoder and decoder utility

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

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

> 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

> 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 [1]6 8248326 Add a minimal serialization test for local records

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

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

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 --- a/test/jdk/java/io/Serializable/rec

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

> 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

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 avgt

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

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

> 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: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

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

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

> 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

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

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

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

Re: RFR: 8247532: Records deserialization is slow

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 v

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

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

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

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

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

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. https://cr.openjdk.java.ne

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