On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> Patch adds the planned support for new vector operations and APIs targeted
>> for [JEP 426: Vector API (Fourth
>> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>>
>> Following is the brief summary of
On Fri, 13 May 2022 08:24:24 GMT, Jatin Bhateja wrote:
>> src/hotspot/share/opto/c2compiler.cpp line 521:
>>
>>> 519: if (!Matcher::match_rule_supported(Op_SignumF)) return false;
>>> 520: break;
>>> 521: case vmIntrinsics::_VectorComExp:
>>
>> Why `_VectorComExp` intrinsic is
On Fri, 13 May 2022 08:24:21 GMT, Jatin Bhateja wrote:
> LUT should be generated only if UsePopCountInsturction is false
Should there be `!UsePopCountInsturction` check then?
> restrict the scope of flag to only scalar popcount operation
Interesting. But AArch64 code does cover vector cases
On Fri, 13 May 2022 19:59:40 GMT, Jorn Vernee wrote:
>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933:
>>
>>> 931: } else {
>>> 932: assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s,
>>> %s)",
>>> 933: src.first()->name(), src.second()->name(),
>>>
On Fri, 13 May 2022 20:46:19 GMT, Vladimir Ivanov wrote:
>> Shouldn't there be a 2-space indentation wrt the assert here? I could also
>> indent all the arguments to be aligned with the format string, if that seems
>> better.
>
> It's preferred to indent multi-line argu
On Thu, 12 May 2022 16:58:36 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This PR updates the VM implementation of the foreign linker, by bringing
>> over commits from the panama-foreign repo.
>>
>> This is split off from the main JEP integration for 19, since we have
>> limited resources to handle
On Thu, 12 May 2022 17:26:44 GMT, Jorn Vernee wrote:
>>> Do nothing special for async exceptions. i.e. if they happen anywhere
>>> between 1. and 6. they will end up in one of the fallback handlers and the
>>> VM will be terminated.
>>
>> My understanding is that if they materialize while
On Tue, 10 May 2022 12:48:25 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> Patch adds the planned support for new vector operations and APIs targeted
>> for [JEP 426: Vector API (Fourth
>> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>>
>> Following is the brief summary of
On Mon, 28 Mar 2022 12:15:10 GMT, Jorn Vernee wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded ComputeMoveOrder
On Mon, 9 May 2022 10:28:27 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This PR updates the VM implementation of the foreign linker, by bringing
>> over commits from the panama-foreign repo.
>>
>> This is split off from the main JEP integration for 19, since we have
>> limited resources to handle
On Tue, 8 Feb 2022 17:11:45 GMT, Aleksey Shipilev wrote:
>> I was looking for easy things to do to improve `java.lang.invoke` cold
>> performance. One of the things is inlining `VarForm.getMemberName` a bit, so
>> that interpreter does not have to call through `getMemberNameOrNull`.
>>
>>
On Thu, 3 Feb 2022 07:20:28 GMT, Aleksey Shipilev wrote:
> I was looking for easy things to do to improve `java.lang.invoke` cold
> performance. One of the things is inlining `VarForm.getMemberName` a bit, so
> that interpreter does not have to call through `getMemberNameOrNull`.
>
> There is
On Wed, 19 Jan 2022 17:38:25 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов
wrote:
> Currently the method is implemented like
>
> public List> parameterList() {
> return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
> }
>
> This seems to be excessive, as three objects are allocated here. Instead we
>
On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote:
> Get rid of WeakReference-based logic in
> DirectMethodHandle::checkInitialized() and reimplement it with
> `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`.
>
> The key observation is that `Unsafe::ensureC
On Thu, 2 Sep 2021 11:45:01 GMT, Vladimir Ivanov wrote:
>> Get rid of WeakReference-based logic in
>> DirectMethodHandle::checkInitialized() and reimplement it with
>> `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`.
>>
>> The k
On Fri, 3 Sep 2021 14:41:45 GMT, Vladimir Ivanov wrote:
>> `MethodHandle.asTypeCache` keeps a strong reference to adapted
>> `MethodHandle` and it can introduce a class loader leak through its
>> `MethodType`.
>>
>> Proposed fix introduces a 2-level cache (1 ele
On Wed, 25 Aug 2021 09:31:51 GMT, Vladimir Ivanov wrote:
> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle`
> and it can introduce a class loader leak through its `MethodType`.
>
> Proposed fix introduces a 2-level cache (1 element each) where 1st level
On Fri, 3 Sep 2021 14:41:45 GMT, Vladimir Ivanov wrote:
>> `MethodHandle.asTypeCache` keeps a strong reference to adapted
>> `MethodHandle` and it can introduce a class loader leak through its
>> `MethodType`.
>>
>> Proposed fix introduces a 2-level cache (1 ele
On Fri, 3 Sep 2021 12:51:13 GMT, Peter Levart wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/java/lang/invoke/MethodH
ix is based on [the
> work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/)
> made by Peter Levart @plevart back in 2015.
>
> Testing: tier1 - tier6
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since
On Fri, 3 Sep 2021 00:09:17 GMT, Mandy Chung wrote:
> For the change of MethodHandle::asType to a final method, this needs a CSR.
It is not allowed to extend/subclass `MethodHandle` outside `java.lang.invoke`
package.
So, the aforementioned change doesn't have any compatibility risks. Do I
On Thu, 2 Sep 2021 05:08:38 GMT, David Holmes wrote:
>> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1152:
>>
>>> 1150: * The call returns when either class {@code c} is fully
>>> initialized or
>>> 1151: * class {@code c} is being initialized and the call is
thread.
>
> Also, removed `Unsafe::shouldBeInitialized()` in
> `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM.
> `Unsafe::ensureClassInitialized()` already has a fast-path check which checks
> whether the class is fully initialized or not.
>
> Testing: tie
On Wed, 1 Sep 2021 17:28:37 GMT, Mandy Chung wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/java/lang/invoke/MethodH
ix is based on [the
> work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/)
> made by Peter Levart @plevart back in 2015.
>
> Testing: tier1 - tier6
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since
On Wed, 25 Aug 2021 09:31:51 GMT, Vladimir Ivanov wrote:
> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle`
> and it can introduce a class loader leak through its `MethodType`.
>
> Proposed fix introduces a 2-level cache (1 element each) where 1st level
ix is based on [the
> work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/)
> made by Peter Levart @plevart back in 2015.
>
> Testing: tier1 - tier6
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since
On Thu, 26 Aug 2021 23:49:07 GMT, David Holmes wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve comments
>
> src/java.base/share/classes/java/lang/invoke/DirectMethodH
On Tue, 31 Aug 2021 16:36:58 GMT, Mandy Chung wrote:
> May i suggest that we add some JavaDoc to ensureClassInitialized
Thanks, Paul. How does the latest version look?
-
PR: https://git.openjdk.java.net/jdk/pull/5258
thread.
>
> Also, removed `Unsafe::shouldBeInitialized()` in
> `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM.
> `Unsafe::ensureClassInitialized()` already has a fast-path check which checks
> whether the class is fully initialized or not.
>
> Testing: tie
On Thu, 26 Aug 2021 02:48:38 GMT, David Holmes wrote:
> I'm unclear exactly what that statement is meant to indicate.
`DirectMethodHandle::checkInitialized()` is dual-purpose: it implements class
initialization barrier and reports whether the class is fully initialized, so
the barrier can be
Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized()
and reimplement it with
`Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`.
The key observation is that `Unsafe::ensureClassInitialized()` does not block
the initializing thread.
Also, removed
`MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle`
and it can introduce a class loader leak through its `MethodType`.
Proposed fix introduces a 2-level cache (1 element each) where 1st level can
only contain `MethodHandle`s which are guaranteed to not introduce any
On Mon, 9 Aug 2021 20:15:59 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/ref/Reference.java line 374:
>>
>>> 372: * to call the native implementation over the intrinsic.
>>> 373: */
>>> 374: boolean refersToImpl(T obj) {
>>
>> I'm curious why can't you get rid
On Mon, 9 Aug 2021 13:13:33 GMT, Per Liden wrote:
> While fixing JDK-8270626 it was discovered that the C2 intrinsic for
> `Reference.refersTo()` is not used as often as one would think. Instead C2
> often prefers using the native implementation, which is much slower which
> defeats the
On Tue, 13 Jul 2021 17:05:25 GMT, Vladimir Ivanov wrote:
>> Thanks for the suggestion. I'd like to keep it the way it is though, so that
>> the assert message contains the `has_last_frame` & `java_call_counter`
>> values. (this was one of the reason I did this r
On Tue, 13 Jul 2021 14:59:07 GMT, Jorn Vernee wrote:
>> src/hotspot/share/runtime/thread.hpp line 1128:
>>
>>> 1126:
>>> 1127: private:
>>> 1128: DEBUG_ONLY(void verify_frame_info();)
>>
>> If you declare `verify_frame_info` as returning a `bool` (and just put a
>> `return true;` at the
On Fri, 25 Jun 2021 17:38:32 GMT, Jorn Vernee wrote:
> This patch rewrites the prologue and epilogue of panama upcalls, in order to
> fix the test failure from the title.
>
> Previously, we did a call to potentially attach the current thread to the VM,
> and then afterwards did the same
On Thu, 3 Jun 2021 21:43:19 GMT, Sandhya Viswanathan
wrote:
>> The Vector API toShuffle method can be optimized using existing vector
>> conversion intrinsic.
>>
>> The following changes are made:
>> 1) vector.toShuffle java implementation is changed to call
>> VectorSupport.convert.
>> 2)
On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan
wrote:
>> This PR contains Short Vector Math Library support related changes for
>> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
>> in preparation for when targeted.
>>
>> Intel Short Vector Math Library
On Thu, 13 May 2021 10:52:35 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-412 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Wed, 12 May 2021 15:07:37 GMT, Maurizio Cimadamore
wrote:
>> src/hotspot/share/runtime/sharedRuntime.hpp line 465:
>>
>>> 463: static void restore_native_result(MacroAssembler *_masm, BasicType
>>> ret_type, int frame_slots);
>>> 464:
>>> 465: static void move32_64(MacroAssembler*
On Wed, 12 May 2021 14:53:39 GMT, Jorn Vernee wrote:
>> src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:
>>
>>> 470: __ block_comment("} preserve_callee_saved_regs ");
>>> 471:
>>> 472: // TODO mxcsr
>>
>> Anything left to do with mxcsr?
>
> I guess this slipped through
On Mon, 10 May 2021 20:43:20 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-412 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Mon, 10 May 2021 20:43:20 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-412 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Mon, 10 May 2021 21:37:25 GMT, Paul Sandoz wrote:
>> This PR contains API and implementation changes for [JEP-414 Vector API
>> (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for
>> when targeted.
>>
>> Enhancements are made to the API for the support of operations
On Thu, 29 Apr 2021 21:13:38 GMT, Paul Sandoz wrote:
> This PR contains API and implementation changes for [JEP-414 Vector API
> (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for
> when targeted.
>
> Enhancements are made to the API for the support of operations on
On Mon, 10 May 2021 18:31:30 GMT, Sandhya Viswanathan
wrote:
>> All the slice and unslice variants that take more than one argument can
>> benefit from already intrinsic methods on similar lines as slice(origin) and
>> unslice(origin).
>>
>> Changes include:
>> * Rewrite Vector API
On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee wrote:
> This patch implements 2 leftover TODOs for implementing var handle invoker MH
> caching (lambda forms for those were already shared/cached).
>
> This piggybacks on the existing mechanism for method handle invoker caching.
>
> Testing:
On Mon, 5 Apr 2021 14:16:37 GMT, Jorn Vernee wrote:
>> This patch speeds up MethodHandle.asCollector handles where the array type
>> is not Object[], as well as speeding up all collectors where the arity is
>> greater than 10.
>>
>> The old code is creating a collector handle by combining a
On Mon, 5 Apr 2021 11:57:08 GMT, Jorn Vernee wrote:
>> This patch speeds up MethodHandle.asCollector handles where the array type
>> is not Object[], as well as speeding up all collectors where the arity is
>> greater than 10.
>>
>> The old code is creating a collector handle by combining a
On Mon, 5 Apr 2021 11:57:08 GMT, Jorn Vernee wrote:
>> This patch speeds up MethodHandle.asCollector handles where the array type
>> is not Object[], as well as speeding up all collectors where the arity is
>> greater than 10.
>>
>> The old code is creating a collector handle by combining a
On Mon, 5 Apr 2021 12:37:06 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> - Revert back to injected constructor handle
>> - Add lambda form sharing
>&
On Fri, 2 Apr 2021 14:41:06 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>> line 874:
>>
>>> 872: case NEW_ARRAY:
>>> 873: Class rtype =
>>> name.function.methodType().returnType();
>>> 874:
On Fri, 2 Apr 2021 13:17:55 GMT, Jorn Vernee wrote:
>> This patch speeds up MethodHandle.asCollector handles where the array type
>> is not Object[], as well as speeding up all collectors where the arity is
>> greater than 10.
>>
>> The old code is creating a collector handle by combining a
On Sat, 27 Feb 2021 03:23:12 GMT, Jie Fu wrote:
>> Hi all,
>>
>> Vector API fails to work when:
>> - case 1: MaxVectorSize is set to <=8, or
>> - case 2: C2 is disabled
>>
>> The reason is that {max/preferred} VectorShape initialization fails in both
>> cases.
>> And the root cause is that
On Fri, 26 Feb 2021 15:37:08 GMT, Jie Fu wrote:
> I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <=
> VectorSupport.getMaxLaneCount(double.class) for Java programmers since the
> VectorSupport_GetMaxLaneCount is used to implement a Java API.
It doesn't make much sense to me.
On Fri, 26 Feb 2021 02:38:00 GMT, Jie Fu wrote:
>> Hi all,
>>
>> Vector API fails to work when:
>> - case 1: MaxVectorSize is set to <=8, or
>> - case 2: C2 is disabled
>>
>> The reason is that {max/preferred} VectorShape initialization fails in both
>> cases.
>> And the root cause is that
On Mon, 14 Dec 2020 14:46:41 GMT, Maurizio Cimadamore
wrote:
> This patch fixes a problem with type profile pollution when segments of
> different kinds are used on the same memory access var handle, or on the same
> `MemoryAccess` static method.
>
> In principle, argument profiling should
On Thu, 26 Nov 2020 13:13:43 GMT, Vladimir Ivanov wrote:
> Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers.
> It reduces the number of LambdaForms needed at runtime.
>
> Testing: tier1-4
This pull request has now been integrated.
Changeset: 7104400a
Author:
On Mon, 30 Nov 2020 19:38:56 GMT, Paul Sandoz wrote:
>> Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers.
>> It reduces the number of LambdaForms needed at runtime.
>>
>> Testing: tier1-4
>
> Marked as reviewed by psandoz (Reviewer).
Thanks for the reviews, Claes,
On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov wrote:
> Concurrent updates may lead to redundant LambdaForms created and unnecessary
> class loading when those are compiled.
>
> Most notably, it severely affects MethodHandle customization: when a
> MethodHandle is calle
On Mon, 30 Nov 2020 19:32:54 GMT, Paul Sandoz wrote:
>> Vladimir Ivanov 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 contain
On Wed, 2 Dec 2020 17:28:15 GMT, Vladimir Ivanov wrote:
>> Marked as reviewed by psandoz (Reviewer).
>
> Thanks for the reviews, Claes, Paul, and Peter.
\integrate
-
PR: https://git.openjdk.java.net/jdk/pull/1472
On Wed, 2 Dec 2020 15:30:07 GMT, Peter Levart wrote:
>>> Would it make a difference if MH.form was not final and each read access to
>>> it was done via appropriate Unsafe.getReferenceXXX()?
>>
>> It would break inlining through MH calls. JITs trust `MH.form` and
>> aggressively inline
On Wed, 2 Dec 2020 14:36:16 GMT, Peter Levart wrote:
> Would it make a difference if MH.form was not final and each read access to
> it was done via appropriate Unsafe.getReferenceXXX()?
It would break inlining through MH calls. JITs trust `MH.form` and aggressively
inline through it.
>I
the update in-flight is over: all other threads (except the one
> performing the update) can just proceed with the invocation using the
> existing MH.form.
>
> Testing:
> - manually monitored the behavior on a stress test from
> [JDK-8252049](https://bugs.openjdk.java.net/b
On Tue, 1 Dec 2020 15:55:36 GMT, Peter Levart wrote:
>> It seems that I was right. See `ciField.cpp`:
>>
>> static bool trust_final_non_static_fields(ciInstanceKlass* holder) {
>> if (holder == NULL)
>> return false;
>> if (holder->name() == ciSymbol::java_lang_System())
>> // Never
On Tue, 1 Dec 2020 20:36:48 GMT, Paul Sandoz wrote:
> Float/DoubleVector implementations contain redundant cases for bitwise
> operations. Such bitwise operations will fail on such FP vectors before the
> case is reached.
Looks good.
-
Marked as reviewed by vlivanov (Reviewer).
Concurrent updates may lead to redundant LambdaForms created and unnecessary
class loading when those are compiled.
Most notably, it severely affects MethodHandle customization: when a
MethodHandle is called from multiple threads, every thread starts customization
which takes enough time for
Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers.
It reduces the number of LambdaForms needed at runtime.
Testing: tier1-4
-
Commit messages:
- Share LambdaForms for VH linkers/invokers.
Changes: https://git.openjdk.java.net/jdk/pull/1455/files
Webrev:
On Wed, 25 Nov 2020 23:35:14 GMT, Vladimir Kozlov wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
On Wed, 25 Nov 2020 17:05:15 GMT, Aleksey Shipilev wrote:
>> I've applied open comments. Please let me know if this is ok to merge.
>
> Still looks fine to me. Merge from master to get the fixes for GH actions
> failures, #1427
Thanks, Jorn. The split looks good.
-
PR:
On Wed, 25 Nov 2020 12:09:07 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was
On Wed, 25 Nov 2020 09:47:19 GMT, Erik Österlund wrote:
>> src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 123:
>>
>>> 121:
>>> 122: ins_encode %{
>>> 123: if (barrier_data() != 0) { // barrier could be elided by
>>> ZBarrierSetC2::analyze_dominating_barriers()
>>
>> Maybe keep a bit
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
>
On Wed, 25 Nov 2020 07:58:42 GMT, Aleksey Shipilev wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
>> reviews. For this reasons, I'm attaching a webrev which contains only the
>> differences between this PR and the memory access PR. I will be periodically
>> uploading new webrevs, as new iterations come out, to try and make the life
>> of reviewers as simple as possible.
>>
&
On Thu, 19 Nov 2020 01:07:12 GMT, Paul Sandoz wrote:
> Refactor the vector conversions tests to improve performance and reduce
> explicit test methods (using data providers).
> +463, -37,019
Impressive improvement, Paul! :-)
-
Marked as reviewed by vlivanov (Reviewer).
PR:
>> reviews. For this reasons, I'm attaching a webrev which contains only the
>> differences between this PR and the memory access PR. I will be periodically
>> uploading new webrevs, as new iterations come out, to try and make the life
>> of reviewers as simple as possible.
>>
&
On Fri, 6 Nov 2020 08:35:17 GMT, Roland Westrelin wrote:
>> This change add 3 new methods in Objects:
>>
>> public static long checkIndex(long index, long length)
>> public static long checkFromToIndex(long fromIndex, long toIndex, long
>> length)
>> public static long checkFromIndexSize(long
On Mon, 19 Oct 2020 19:43:13 GMT, Paul Sandoz wrote:
> The zero methods on `IntVector` and all other specializations are missing
> documentation.
Looks good.
-
Marked as reviewed by vlivanov (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/748
/panama/vector/jep338/hotspot.shared/webrev.01
Incremental changes:
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00
Best regards,
Vladimir Ivanov
Older webrev links for your reference:
Shared Hotspot:
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338
/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad
\
Best regards,
Vladimir Ivanov
On 7/8/20 3:05 PM, Yang Zhang wrote:
Hi Andrew
I have updated this patch. Could you please help to review it again?
In this patch, the following changes are made:
1. Separate newly added NEON instructions to a new ad
methods anymore and it helps with getting EA
in C2 to eliminate the allocation.
Best regards,
Vladimir Ivanov
[1]
$ javap -verbose -private
target/classes//org/openjdk/ea/StringCompositeKeyBenchmark.class
public java.lang.Object
compositeKey(org.openjdk.ea.StringCompositeKeyBenchmark$Data
over (vmTrustedFinal/isVMTrustedFinalField).
But I'm fine with keeping the patch as is.
Best regards,
Vladimir Ivanov
On 16.06.2020 00:58, Mandy Chung wrote:
This patch is joint contribution from Christoph Dreis [1] and me.
Webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8247444/w
Looks good.
Best regards,
Vladimir Ivanov
On 27.05.2020 20:25, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8245874/webrev.00
8 lines changed: 2 ins; 0 del; 6 mod;
Hi all,
could you please review this small and trivial cleanup in TEST.ROOT files of
test/jdk/ and test
compiler change to treat
Thread.currentThread() as a well-known constant - which helps a lot
in the confinement checks (thanks Vlad!)
FTR it is tracked by JDK-8235143 [1] and the patch is under review [2].
Should I remove this from the patch then?
Yes, please.
Best regards,
Vladimir Ivanov
] and the patch is under review [2].
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8235143
[2]
https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-December/036295.html
* various Buffer-related changes; these changes are needed because the
memory access API
Thank you, John.
Best regards,
Vladimir Ivanov
On 30.11.2019 02:30, John Rose wrote:
Reviewed.
On Nov 29, 2019, at 7:55 AM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8234923/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8234923
initialized.
Testing: tier1-6
Best regards,
Vladimir Ivanov
[1]
https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/036019.html
[2] https://hg.openjdk.java.net/jdk/jdk/rev/a6e25566cb56#l1.26
Access API and the API shouldn't wait for it to be released.
After there's more data available from ABI experiments, we'll be in a
better position to decide how to proceed (either add it to Memory Access
API, build a separate API on top, or even drop it).
Best regards,
Vladimir Ivanov
Thanks for review, Paul.
Best regards,
Vladimir Ivanov
On 19.11.2019 21:25, Paul Sandoz wrote:
+1
On Nov 19, 2019, at 10:12 AM, Vladimir Ivanov
wrote:
Thanks, Paul.
CallSite:
public class CallSite {
- // The actual payload of this call site:
+ // The actual payload of this call site
here we could
move it into ConstantCallSite?
Sure, if you prefer to see it on ConstantCallSite side, we can move it
there.
By putting it in CallSite near the call site update, I wanted to stress
there's a CallSite.target update happening on partially published
instance.
Best regards,
Vladimir Ivano
the wrong version (with some leftovers from last-minute failed
experiment). Updated in place.
Best regards,
Vladimir Ivanov
On Nov 19, 2019, at 8:53 AM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8234401/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8234401
http://cr.openjdk.java.net/~jvernee/8233920/webrev.04/
Looks good.
Best regards,
Vladimir Ivanov
On 13/11/2019 11:28, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~jvernee/8233920/webrev.03/
I like how the patch shapes. Looks good.
In addition, you can encapsulate the following
;
case L_TYPE: return Opcodes.POP;
default:
throw new InternalError("unknown type: " + type);
}
Best regards,
Vladimir Ivanov
As long as Claes is okay with it, I think we should go for that one
since the code/doc is simpler. I can file an RFE for
Looks good.
Best regards,
Vladimir Ivanov
On 05/09/2019 17:41, Claes Redestad wrote:
Hi,
I noticed some unused methods in java.lang.invoke.MethodTypeForm and
ended up with a rather substantial cleanup after pulling that particular
thread for a bit:
http://cr.openjdk.java.net/~redestad
on {@code
-XX:+ShowHiddenFrames} to
40 * always show "hidden" frames.
41 */
Best regards,
Vladimir Ivanov
On 18/01/2019 16:18, dean.l...@oracle.com wrote:
Thanks for fixing this.
Some copyright dates weren't updated. Comment for Hidden.java still
says TODO.
dl
On 1/18/19
1 - 100 of 457 matches
Mail list logo
