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
tialization is 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/jdk
11,
javac doesn't emit bridge 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.
H)/gc/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 n
/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
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
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 f
>> 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: http
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
;
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 exa
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
y break an instance in such a way it becomes permanently
unusable.
PS: converted CallSite.target to final along the way and made some other
minor refactorings.
Testing: regression test, tier1-2
Best regards,
Vladimir Ivanov
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
ce 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,
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
allocation is not a prerequisite for
Memory 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
being 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
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
1] 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
y_call.cpp - this one is a JIT 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.
>> 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 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.
>>
>
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.
>
> Tested
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 reserved
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 ca
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: https://git
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.
>>
>>
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: https
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 o
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).
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
ntil 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.
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 was
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 through
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 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 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: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, Vladimi
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, 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 ki
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 V
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. `VectorS
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 V
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 se
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 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 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 se
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 se
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 se
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: Loca
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 slice/uns
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 cha
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 o
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] - https://openjd
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] - https://openjd
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 with
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* ma
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] - https://openjd
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 (SVM
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) T
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 suspen
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 en
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
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 purpos
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
`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
de
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 `Unsafe::sho
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 s
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 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
The fix 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 s
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
The fix 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 s
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
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, 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 perform
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 mis
The fix 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 s
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
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 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 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 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 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
> c
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 fra
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 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`.
>>
>> Ther
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 th
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 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 chan
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 we'r
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 t
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(),
>>> dst.first
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
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 w
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 special
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 chan
1 - 100 of 487 matches
Mail list logo