On Fri, 23 Oct 2020 16:34:54 GMT, Roger Riggs wrote:
>> Do you want to refactor some of the classes where `HexFormat` would be a
>> well-suited replacement for the current code, and what do you think about my
>> other previous review comments (mostly formatting related)?
>> The bridgekeeper
> 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 parameters.
> - Consistent naming of methods for conversion of
On Fri, 23 Oct 2020 10:32:27 GMT, Peter Levart wrote:
>>> NewInvocationHandler/DefaultMethodInvoker feels a bit awkward. If I have it
>>> right, to use it as a lambda expression to Proxy.newProxyInterface would
>>> require casting to NewInvocationHandler. I also need to be careful when
>>>
On Mon, 26 Oct 2020 12:49:43 GMT, Claes Redestad wrote:
>> Current implementation of the statSampler does upcalls to System.getProperty
>> to collect values for a number of properties that are all provided by the VM
>> itself. And since the sampling starts before any user code run then no
>>
On Sat, 24 Oct 2020 00:49:12 GMT, Alexander Matveev
wrote:
> I did not reproduce issue with license is not shown as per SQE report. It
> work as expected. However, jpackage fails due to unflatten/flatten being
> removed from hdiutil on macOS 11. I am not sure why it was needed, probably
>
On Mon, 26 Oct 2020 20:24:35 GMT, Igor Ignatyev wrote:
>> Harold Seigel has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8238263: Create at-requires mechanism for containers
>
> LGTM, modulo my earlier comment/doubt about the name, but I
On Fri, 23 Oct 2020 18:44:54 GMT, Harold Seigel wrote:
> Please review this change to add an @requires mechanism called
> "jdk.containerized" to help mark tests that are incompatible with containers.
> Users would add "@requires jdk.containerized != true" to the incompatible
> tests and then
On Mon, 26 Oct 2020 18:13:29 GMT, Harold Seigel wrote:
>> Please review this change to add an @requires mechanism called
>> "jdk.containerized" to help mark tests that are incompatible with
>> containers. Users would add "@requires jdk.containerized != true" to the
>> incompatible tests and
On Mon, 26 Oct 2020 18:13:29 GMT, Harold Seigel wrote:
>> Please review this change to add an @requires mechanism called
>> "jdk.containerized" to help mark tests that are incompatible with
>> containers. Users would add "@requires jdk.containerized != true" to the
>> incompatible tests and
On Thu, 22 Oct 2020 22:06:11 GMT, CoreyAshford
wrote:
>> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3878:
>>
>>> 3876: // |Element| | |
>>> | | | |
>>>
> 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 lead to performance degradation.
>
> This is implemented
> 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 lead to performance degradation.
>
> This is implemented
On Fri, 23 Oct 2020 17:47:36 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 lead
On Mon, 26 Oct 2020 17:13:05 GMT, Rémi Forax
wrote:
>> We can clarify the new methods and tie them closer to method handle
>> semantics. I suggest the names `asExactInvoker` and `asInvoker`, referencing
>> `MethodHandles.exactInvoker` and `MethodHandles.invoker` respectively. (The
>> term
On Mon, 26 Oct 2020 16:34:10 GMT, Paul Sandoz wrote:
>> The direct use of the enum ordinal is because HotSpot accessing it from the
>> enum value is (or was) not optimal in C2.
>>
>> You can avoid the addition of the stable array by doing the following:
>>
>> public final MethodType
On Sat, 24 Oct 2020 00:49:12 GMT, Alexander Matveev
wrote:
> I did not reproduce issue with license is not shown as per SQE report. It
> work as expected. However, jpackage fails due to unflatten/flatten being
> removed from hdiutil on macOS 11. I am not sure why it was needed, probably
>
On Mon, 26 Oct 2020 18:01:04 GMT, John R Rose wrote:
>> @rose00 My bad. You're right, I realized we could also use `asType` later on
>> (I did call it out in the CSR), but It's still a bit more wordy than what
>> I'm proposing.
>>
>> `dropReturn` seemed like a good choice since we already
On Mon, 26 Oct 2020 14:25:14 GMT, Igor Ignatyev wrote:
>> Defining an environment variable works when running JTReg from the command
>> line. But, mach5 does not pass environment variable settings to its JTReg
>> test runs. Some mach5 special command args would still be needed.
>
>> Defining
> Please review this change to add an @requires mechanism called
> "jdk.containerized" to help mark tests that are incompatible with containers.
> Users would add "@requires jdk.containerized != true" to the incompatible
> tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or
On Mon, 26 Oct 2020 17:29:11 GMT, Jorn Vernee wrote:
> …`dropReturn` seemed like a good choice since we already have
> `dropArguments`. WRT changing to `MethodHandle::changeReturnType`...
That's a very reasonable point. People might look for `dropRT` after they find
`dropAs`. And `MHs` is
On Mon, 26 Oct 2020 17:16:17 GMT, John R Rose wrote:
>> LGTM, pending CSR.
>>
>> A minor simplification suggested inline.
>
> I don't mind shorthands, but the existing idiom is shorter than advertised,
> a one-liner assuming the MH is already bound to a var:
>
> target =
On Mon, 26 Oct 2020 15:45:00 GMT, Claes Redestad wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Collapse lform get and update into single line
>>
>> Co-authored-by: Claes Redestad
>
> LGTM, pending CSR.
>
>
On Sat, 24 Oct 2020 00:49:12 GMT, Alexander Matveev
wrote:
> I did not reproduce issue with license is not shown as per SQE report. It
> work as expected. However, jpackage fails due to unflatten/flatten being
> removed from hdiutil on macOS 11. I am not sure why it was needed, probably
>
On Mon, 26 Oct 2020 16:13:59 GMT, Paul Sandoz wrote:
>> I've updated the javadoc, and added two benchmarks that show the existing
>> discrepancy between an exact and a generic use of a VarHandle, as well as
>> showing that an exact VarHandle is as fast as a generic VarHandle for an
>> exact
On Mon, 26 Oct 2020 13:37:58 GMT, Jorn Vernee wrote:
>> @PaulSandoz I've implemented your suggestion, by moving the `exact` flag to
>> VarHandle itself. FWIW, the VH::accessModeType method took an AccessMode
>> value as an argument, and the AccessDescriptor only stored the ordinal, so I
>>
> Hi,
>
> This patch adds a `dropReturn` combinator to `MethodHandles` that can be used
> to create a new method handle that drops the return value, from a given
> method handle. Similar to the following code:
>
> MethodHandle target = ...;
> Class targetReturnType =
On Mon, 12 Oct 2020 21:17:47 GMT, Marcono1234
wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comment updates to class javadoc
>
> src/java.base/share/classes/java/util/HexFormat.java line 148:
>
>> 146:
On Mon, 26 Oct 2020 15:45:34 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This patch adds a `dropReturn` combinator to `MethodHandles` that can be
>> used to create a new method handle that drops the return value, from a given
>> method handle. Similar to the following code:
>>
>> MethodHandle
> Hi,
>
> This patch adds a `dropReturn` combinator to `MethodHandles` that can be used
> to create a new method handle that drops the return value, from a given
> method handle. Similar to the following code:
>
> MethodHandle target = ...;
> Class targetReturnType =
- Mail original -
> De: "Jorn Vernee"
> À: "core-libs-dev"
> Envoyé: Lundi 26 Octobre 2020 16:37:20
> Objet: RFR: 8255398: Add a dropReturn MethodHandle combinator
> Hi,
>
> This patch adds a `dropReturn` combinator to `MethodHandles` that can be used
> to
> create a new method handle
Hi,
This patch adds a `dropReturn` combinator to `MethodHandles` that can be used
to create a new method handle that drops the return value, from a given method
handle. Similar to the following code:
MethodHandle target = ...;
Class targetReturnType = target.type().returnType();
if
On Mon, 26 Oct 2020 13:49:26 GMT, Harold Seigel wrote:
> Defining an environment variable works when running JTReg from the command
> line. But, mach5 does not pass environment variable settings to its JTReg
> test runs. Some mach5 special command args would still be needed.
right, yet given
On Fri, 23 Oct 2020 20:08:01 GMT, Igor Ignatyev wrote:
>>> I think it depends on whether the tests will be permanently or temporarily
>>> excluded from running with containers. I thought this mechanism would be to
>>> permanently exclude the tests. That's why I used `@requires`.
>>
>> I see,
On Fri, 23 Oct 2020 23:58:29 GMT, Jorn Vernee wrote:
>> @PaulSandoz Thanks. I initially tested this with memory access VarHandles,
>> which don't erase the receiver type. e.g.
>>
>> MemoryLayout layout = MemoryLayout.ofSequence(10, JAVA_INT);
>> VarHandle vh = layout.varHandle(int.class,
>>
> 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 lead to performance degradation.
>
> This is implemented
> Current implementation of the statSampler does upcalls to System.getProperty
> to collect values for a number of properties that are all provided by the VM
> itself. And since the sampling starts before any user code run then no
> property can have changed.
>
> I suggest refactoring the code
> 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 lead to performance degradation.
>
> This is implemented
On Fri, 23 Oct 2020 16:21:53 GMT, Jan Lahoda wrote:
>> This is an update to javac and javadoc, to introduce support for Preview
>> APIs, and generally improve javac and javadoc behavior to more closely
>> adhere to JEP 12.
>>
>> The notable changes are:
>>
>> * adding support for Preview
On Fri, 23 Oct 2020 14:06:22 GMT, Maurizio Cimadamore
wrote:
>> Changes requested by ihse (Reviewer).
>
> @magicus the files you commented on are not part of this PR, but they are
> introduced as part of:
> https://git.openjdk.java.net/jdk/pull/548
> (you seemed to have approved the changes
On Thu, 22 Oct 2020 17:04:34 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the first incubation round
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
>> access support (see JEP 393
On Mon, 19 Oct 2020 10:34:32 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation (see JEP 393 [1]). This
>> iteration focus on improving the usability of the API in 3 main ways:
>>
>> *
On Fri, 23 Oct 2020 10:42:14 GMT, Aleksey Shipilev wrote:
> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
>
> Testing:
> - [x] Affected test on Linux x86_64 (still passes)
> - [x] Affected test on Linux x86_32 (now ignored)
@mcimadamore, please take a look? This
On Fri, 23 Oct 2020 12:37:10 GMT, Aleksey Shipilev wrote:
> It currently fails on x86_32 with `java.lang.IllegalStateException:
> Misaligned access at address: 12`. I checked that once JDK-8254162
> integrates, that issue is gone. Until then, having clean x86_32 testing is
> beneficial for
43 matches
Mail list logo
