Re: Getting back into indy...need a better argument collector!

Hi Charlie, Thanks for the details. I quickly logged: https://bugs.openjdk.java.net/browse/JDK-8264288 I don’t have time to dive into the details right now. Perhaps next week, or hopefully someone else can. Paul. > On Mar 25, 2021, at 9:25 PM, Charles Oliver Nutter > wrote: > > JRuby bra

Re: Why is "checkcast MethodHandle" necessary in methodHandleInvokeLinkerMethod?

Place the MH in a static final, then the JIT can constant fold. You might find the following helpful: https://wiki.openjdk.java.net/display/HotSpot/Method+handles+and+invokedynamic https://wiki.openjdk.java.net

Re: Performance of non-static method handles

At some point in the future it may be possible, with the constant folding work, to express the declaration of a MH locally but it gets stuffed in the constant pool (see amber constant-folding) if what the MH is derived from is constant. e.g. think of a language compiler intrinsic for ldc. That m

Re: LinearProbeHashtable Re: ClassValue perf?

Hi Peter, > On 27 May 2016, at 12:41, Peter Levart wrote: > > Hi Paul, > > On 05/26/2016 01:20 PM, Paul Sandoz wrote: >> Hi Peter, >> >> Opportunistically if your LinearProbeHashtable works out then i am wondering >> if

LinearProbeHashtable Re: ClassValue perf?

Hi Peter, Opportunistically if your LinearProbeHashtable works out then i am wondering if we could replace the use of CHM within MethodType.ConcurrentWeakInternSet, which only uses get/putIfAbsent/remove. Thereby CHM can use VarHandles without inducing a circular dependency. Paul. > On 26 May

Re: RFR [9] 8150829: Enhanced drop-args, identity and default constant, varargs adjustment

Hi, Just minor comments, below. Paul. MethodHandle — 972 /** 973 * Adapts this method handle to be {@linkplain #asVarargsCollector variable arity} 974 * if the boolean flag is true, else {@linkplain #asFixedArity fixed arity}. 975 * If the method handle is already o

Re: RFR(L): 8139885: implement JEP 274: enhanced method handles

> On 19 Nov 2015, at 22:16, Michael Haupt wrote: > > Hi John, Paul, > > thanks for your reviews - they have helped me polish the code and > documentation some more and add some more tests. The result is at > http://cr.openjdk.java.net/~mhaupt/8139885/webrev.02 >

Re: RFR(L): 8139885: implement JEP 274: enhanced method handles

HI Michael, Nice work, not easy this area! It may be worth considering, as a separate issue, updating the example section in JavaDoc to be under @apiNote. I have a mild preference to maintain the 80 char limit for JavaDoc, to me it’s easier to read. For code i don’t mind a 100 or more limit.

Re: JFokus VM Tech Day 2016

> On 12 Nov 2015, at 02:37, John Rose wrote: > > On Nov 11, 2015, at 12:35 AM, Marcus Lagergren wrote: >> >> bare silicone magic > > That extra E moves the venue from Santa Clara to Las Vegas. LOL :-) "So now, less than five years later, you can go up on a steep hill in Las Vegas and look

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

> On 25 Sep 2015, at 17:19, Peter Levart wrote: > > Hi Paul, > > Thanks for looking into this. > Apologies for the late reply. > On 09/25/2015 04:07 PM, Paul Sandoz wrote: >> Hi, >> >> This looks like a partial dup of >> https://bugs.openjdk.

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

Hi, This looks like a partial dup of https://bugs.openjdk.java.net/browse/JDK-8076596 The changes look ok, but I am concerned post initialization there may be code paths taken that require the system class loader to be used but instead the boot stream class loader is used instead. Is that a le

Re: [9] RFR (XS): 8059455: LambdaForm.prepare() does unnecessary work for cached LambdaForms

On Apr 23, 2015, at 5:12 PM, Vladimir Ivanov wrote: > https://bugs.openjdk.java.net/browse/JDK-8059455 > http://cr.openjdk.java.net/~vlivanov/8059455/webrev.00/ > > LambdaForm.compileToBytecode() does unnecessary work (constructs invokerType > & check an assertion) before ensuring that Lambda

Re: Implementing VarHandle

On Apr 20, 2015, at 4:40 PM, Remi Forax wrote: > > On 04/20/2015 11:06 AM, Paul Sandoz wrote: >> Hi Peter, >> >> We did consider supporting field and method literals in 9, leveraging the >> same syntax as for method references combined with target typing. But, w

Re: Implementing VarHandle

Hi Peter, We did consider supporting field and method literals in 9, leveraging the same syntax as for method references combined with target typing. But, we have currently concluded it would be best to punt it to post-9. As a result there is currently no compelling need to support VarHandles

Re: Implementing VarHandle

Hi Remi, I am always impressed by the ability of MHs, and your ability to use them :-) With the API you have defined in the VarHandle2 class located in j.l.invoke i strongly suspect you do not need to use method handles. The public methods could directly use casts/null-checks and Unsafe. Roland

Re: The curious case of MHS.Lookup.unreflect on MethodHandle.invoke/invokeExact

On Mar 17, 2015, at 8:24 PM, Vladimir Ivanov wrote: > Paul, >> A call to the following: >> >> Object o = rmh.invokeExact((MethodHandle) null, new Object[]{}); >> >> Will result in a: >> >> java.lang.UnsupportedOperationException: cannot reflectively invoke >> MethodHandle >> >> However

The curious case of MHS.Lookup.unreflect on MethodHandle.invoke/invokeExact

Hi, I am wondering if people can help shed some light on the MHS.Lookup.unreflect implementation for the MethodHandle.invoke/invokeExact. It's clear that one should not be able to operate reflectively on polysig methods and when doing do a USO is throw (as specified), but the implementation se

Re: [9] RFR (XS): 8073644: Assertion in LambdaFormEditor.bindArgumentType is too strict

On Feb 26, 2015, at 7:14 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8073644/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8073644 > > After JDK-8069591 [1] which introduced LambdaForm customization, the assert > in LambdaFormEditor.bindArgumentType became too str

Re: [9] RFR (M): 8067344: Adjust java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent changes in java.lang.invoke

On Jan 12, 2015, at 7:06 PM, Vladimir Ivanov wrote: > Paul, > > Thanks for the review! > Look good, +1, Paul. > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8067344/webrev.02 > >> 70 TestMethods testCase = getTestMethod(); >> 71 if (testCase == TestMetho

Re: [9] RFR (M): 8067344: Adjust java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent changes in java.lang.invoke

Hi 70 TestMethods testCase = getTestMethod(); 71 if (testCase == TestMethods.EXACT_INVOKER || testCase == TestMethods.INVOKER) { 72 // Invokers aren't collected. 73 return; 74 } Can you just filter those test cases out

Re: [9, 8u40] RFR (XXS): 8066746: MHs.explicitCastArguments does incorrect type checks for VarargsCollector

On Dec 9, 2014, at 12:47 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8066746/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8066746 > Looks ok. Curiously, is there a reason why you chose to use MH.invokeWithArguments rather than MH.invoke/invokeExact? Paul. >

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

On Dec 6, 2014, at 1:30 PM, Peter Levart wrote: > Now what scares me (might be that I don't have an intimacy with LambdaForm > class like you do). There is a situation where you publish LambdaForm > instances via data race. > > One form of LambdaForm.transformCache is an array of Transform obje

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

On Dec 2, 2014, at 5:20 PM, Vladimir Ivanov wrote: > Thanks, Paul! > Updated webrev in place. +1. Paul. signature.asc Description: Message signed with OpenPGP using GPGMail ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.ja

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

On Dec 1, 2014, at 5:58 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057020 > That LambdaFormEditor.putInCache method just got more gnarly :-) Generally looks good. In src/java.base/share/classes/java/lang/i

Re: RFR(S) : 8039953 : [TESTBUG] Timeout java/lang/invoke/MethodHandles/CatchExceptionTest.java

Hi Igor, This looks ok. I like how you have factored out things into TimeLimitedRunner. Do you plan in a future patch to update lambda form test code that uses similar functionality? Is the adjustment "timeout *= 0.9" necessary? does reduction by 10% make a difference? Paul. On Nov 29, 2014

Re: [9, 8u40] RFR (XXS): 8059880: Get rid of LambdaForm interpretation

On Nov 19, 2014, at 11:24 AM, Vladimir Ivanov wrote: > Aleksey, Duncan, thanks for the review and the confirmation that it doesn't > break stuff for you. > > Any Reviews, please? :-) > Looks good. > Best regards, > Vladimir Ivanov > > On 11/19/14, 2:23 PM, MacGregor, Duncan (GE Energy Man

Re: [9, 8u40] RFR (M): 8063135: Enable full LF sharing by default

On Nov 19, 2014, at 10:30 AM, Vladimir Ivanov wrote: > Hm, I remember I fixed that long time ago... Seems like I chose a stale > patch. Sorry for that. Updated webrev in place. > +1 Paul. signature.asc Description: Message signed with OpenPGP using GPGMail

Re: invoking a interface default method from within an InvocationHandler

On Oct 18, 2014, at 6:59 PM, Peter Levart wrote: > > Hi Paul, Remi, > > The complete solution will require new API, but the java.lang.reflect.Proxy > API could be improved a bit too. With introduction of default interface > methods it is somehow broken now. Default interface methods enable in

Re: invoking a interface default method from within an InvocationHandler

On Oct 16, 2014, at 12:43 PM, Remi Forax wrote: > > On 10/15/2014 06:54 PM, Paul Sandoz wrote: >> Hi Remi, >> >> I did some brief evaluation of this area. >> >> MethodHandleProxies.asInterfaceInstance currently does not support proxying >> to defaul

Re: [9] Review request : JDK-8059070: [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout

On Oct 16, 2014, at 10:43 AM, Konstantin Shefov wrote: > Gently reminder > > On 14.10.2014 16:58, Konstantin Shefov wrote: >> Hello, >> >> Please review the test bug fix >> https://bugs.openjdk.java.net/browse/JDK-8059070 >> Webrev is http://cr.openjdk.java.net/~kshefov/8059070/webrev.00/ >>

Re: invoking a interface default method from within an InvocationHandler

Hi Remi, I did some brief evaluation of this area. MethodHandleProxies.asInterfaceInstance currently does not support proxying to default methods. An InternalError will be thrown if a default method is invoked. It should be possible to fix using a trusted internal IMPL_LOOKUP to look up MHs th

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

On Oct 14, 2014, at 8:54 PM, Vladimir Ivanov wrote: > Paul, > > Thanks for the feedback! > > Updated version: > http://cr.openjdk.java.net/~vlivanov/8059877/webrev.01/ > >>> http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8059877 >>> >> >

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

On Oct 10, 2014, at 9:08 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059877 > Generally looks ok. - MethodHandleImpl 786 if (wrapper.unblock()) { 787 // Reached invocation thre

Re: [9] Review request : JDK-8058728: TEST_BUG: Make java/lang/invoke/LFCaching/LFGarbageCollectedTest.java skip arrayElementSetter and arrayElementGetter methods

On Sep 19, 2014, at 11:54 AM, Vladimir Ivanov wrote: > Looks good. > Small typo in the comment: s/filed/field Otherwise +1, Paul. > Best regards, > Vladimir Ivanov > > On 9/19/14, 1:50 PM, Konstantin Shefov wrote: >> Hello, >> >> Please review the test bug fix >> https://bugs.openjdk.jav

Re: [9] Review request : JDK-8057719: Develop new tests for LambdaForm Reduction and Caching feature

> please see inline answers. > > Igor > > On 09/11/2014 05:12 PM, Paul Sandoz wrote: >> >> On Sep 5, 2014, at 7:52 PM, Konstantin Shefov >> wrote: >> >>> Hello, >>> >>> Please review the new tests for the feature "Lambda

Re: [9] Review request : JDK-8057719: Develop new tests for LambdaForm Reduction and Caching feature

On Sep 5, 2014, at 7:52 PM, Konstantin Shefov wrote: > Hello, > > Please review the new tests for the feature "Lambda Form Reduction and > Caching" https://bugs.openjdk.java.net/browse/JDK-8046703 > > JBS task: https://bugs.openjdk.java.net/browse/JDK-8057719 > > Webrev: http://cr.openjdk.j

Re: [9] RFR (S): 8057657: Annotate LambdaForm parameters with types

+1 to both. On Sep 9, 2014, at 3:22 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8057657/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8057657 >>> >> >> - BoundMethodHandle >> >> 57 assert(speciesData() == speciesData(form)); >> >> I am missing som

Re: [9] RFR (L): Improve LambdaForm sharing by using LambdaFormEditor more extensively

On Sep 9, 2014, at 3:39 PM, Vladimir Ivanov wrote: > Paul, thanks for review! > +1 Paul. > Updated webrev in place. > >>> http://cr.openjdk.java.net/~vlivanov/8057922/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8057922 >>> >>> Introduce more sharing on LambdaForm level by rewr

Re: [9] RFR (L): Improve LambdaForm sharing by using LambdaFormEditor more extensively

On Sep 9, 2014, at 12:51 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057922/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8057922 > > Introduce more sharing on LambdaForm level by rewriting most of the MH > combinators using LambdaFormEditor. > > The new code is

Re: [9] RFR (S): 8057657: Annotate LambdaForm parameters with types

On Sep 5, 2014, at 12:12 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057657/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057657 > - BoundMethodHandle 57 assert(speciesData() == speciesData(form)); I am missing some context here as to how that asser

Re: [9] RFR (S) 8057656: Improve MethodType.isCastableTo() & MethodType.isConvertibleTo() checks

On Sep 5, 2014, at 6:42 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8057656 >>> >> >> 854 if (!canConvert(returnType(), newType.returnType())) >> 855 return false; >> 856 Clas

Re: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles

On Sep 5, 2014, at 3:15 PM, Vladimir Ivanov wrote: >> >> Looks good, just one comment. >> >> MethodHandles.restrictReceiver >> >> This method has: >> >> 1578 private MethodHandle restrictReceiver(MemberName method, >> MethodHandle mh, Class caller) throws IllegalAccessException { >>

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On Sep 5, 2014, at 1:25 PM, Vladimir Ivanov wrote: > Paul, thanks for review. > >> Generally looks good (re: Peter's observation of continue/break). >> >> - LambdaFormEditor >> >> 61 private static final class Transform { >> 62 final long packedBytes; >> 63 final by

Re: [9] RFR (S) 8057656: Improve MethodType.isCastableTo() & MethodType.isConvertibleTo() checks

On Sep 5, 2014, at 10:23 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057656 > 854 if (!canConvert(returnType(), newType.returnType())) 855 return false; 856 Class[] srcTypes = n

Re: [9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

On Sep 5, 2014, at 10:09 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057654 > +1 Paul. signature.asc Description: Message signed with OpenPGP using GPGMail ___ m

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On Sep 2, 2014, at 3:59 PM, Vladimir Ivanov wrote: > Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00 > Generally looks good (re: Peter's observation of continue/break). - LambdaFormEditor 61 private static final class Transform { 62 final long packedBytes; 6

Re: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator

On Sep 1, 2014, at 12:29 PM, Vladimir Ivanov wrote: > Thanks, Paul. > > There's no need to add @ForceInline on selectAlternative. > It is used only during LF interpretation. There's an intrinsic for GWT > combinator, which encodes it as a branch (see > InvokerBytecodeGenerator.emitSelectAlte

Re: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator

On Aug 29, 2014, at 7:20 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8056926/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8056926 > > Cache GuardWithTest per erased to basic types signature. > > GWT shape is made friendly to sharing: > * GWT MH is implemented a

Re: DMH to fields, casts and type profiling Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Aug 29, 2014, at 12:45 AM, John Rose wrote: > On Aug 28, 2014, at 7:38 AM, Paul Sandoz wrote: > >> On Jul 8, 2014, at 9:09 PM, John Rose wrote: >> >>> Regarding the extra cast in accessor logic that Paul picked up on: That >>> may be a left-over fr

DMH to fields, casts and type profiling Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Jul 8, 2014, at 9:09 PM, John Rose wrote: > Regarding the extra cast in accessor logic that Paul picked up on: That may > be a left-over from obsolete versions of the code, or it may cover for some > corner cases, or it could possibly be a re-assurance to the JIT. > I had some enlightenin

Redundant null checks due to casts Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

I have logged the following issue for redundant null checks: https://bugs.openjdk.java.net/browse/JDK-8054492 Paul. signature.asc Description: Message signed with OpenPGP using GPGMail ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.op

Re: [9] RFR (M): 8050877: Improve code for pairwise argument conversions and value boxing/unboxing

On Jul 18, 2014, at 4:02 AM, Vladimir Ivanov wrote: >> ValueConversions >> >> I can see why an EnumMap is used for convenience mapping the Wrapper to MH. >> IIUC it means the MH ref values are not @Stable? I guess it would be easy to >> unpack into an explicit array and index from the wrapper

Re: [9] RFR (S): 8050887: Intrinsify constants for default values

On Jul 16, 2014, at 6:57 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050887/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050887 > > Intrinsify MethodHandles.constant() for default values. > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w

Re: [9] RFR (M): 8050884: Intrinsify ValueConversions.identity() functions

On Jul 16, 2014, at 6:44 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050884/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050884 > > Replace ValueConversions.identity() functions with intrinsics. > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn,

Re: [9] RFR (M): 8050877: Improve code for pairwise argument conversions and value boxing/unboxing

On Jul 16, 2014, at 6:28 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050877/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050877 > > Improved MethodHandleImpl.makePairwiseConvert & ValueConversions.unbox and > small cleanups in related code. > > Also, improved

Re: [9] RFR (M): 8050166: Get rid of some package-private methods on arguments in j.l.i.MethodHandle

On Jul 16, 2014, at 12:53 PM, Vladimir Ivanov wrote: > Paul, thanks for review. > > On 7/16/14 12:34 PM, Paul Sandoz wrote: >> >> On Jul 14, 2014, at 4:04 PM, Vladimir Ivanov >> wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8050166/webrev.00

Re: [9] RFR (M): 8050200: Make LambdaForm intrinsics detection more robust

On Jul 14, 2014, at 7:10 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050200/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050200 > > Replace pattern matching sequences of LambdaForm names during compilation > with explicit marks on MethodHandles. Intrinsic ID i

Re: [9] RFR (M): 8050057: Improve caching of MethodHandle reinvokers

On Jul 14, 2014, at 5:17 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050057/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050057 > > Cache MethodHandle reinvokers per basic type. > For BoundMethodHandles, rebinding is no-op unless underlying LF is too > complex

Re: [9] RFR (XS): 8050174: Support overriding of isInvokeSpecial flag in WrappedMember

On Jul 14, 2014, at 4:47 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050174/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050174 > > Support overriding of isInvokeSpecial flag in WrappedMember. > > Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn,

Re: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles

On Jul 14, 2014, at 4:37 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050173 > > Added j.l.i.MethodHandle.copyWith(MethodType, LambdaForm) and provided > implementation for all subclasses. > > Also, some clea

Re: [9] RFR (M): 8050166: Get rid of some package-private methods on arguments in j.l.i.MethodHandle

On Jul 14, 2014, at 4:04 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050166/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8050166 > > Get rid of the following methods in j.l.i.MethodHandle: > * convertArguments(MethodType newType) > * bindArgument(int pos, Basi

Re: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code

On Jul 15, 2014, at 3:42 PM, Vladimir Ivanov wrote: > Another update: > http://cr.openjdk.java.net/~vlivanov/8050052//webrev.01/ > > Tentative diff: > http://cr.openjdk.java.net/~vlivanov/8050052/webrev.diff.01-02/ > +1 Paul. signature.asc Description: Message signed with OpenPGP using GP

Re: [9] RFR (M): 8050053: Improve caching of different invokers

On Jul 15, 2014, at 3:48 PM, Vladimir Ivanov wrote: > Update: http://cr.openjdk.java.net/~vlivanov/8050053/webrev.01 > Diff: http://cr.openjdk.java.net/~vlivanov/8050053/webrev.diff.00-01/ > > Got rid of varargs & spread invokers. > +1 Paul. signature.asc Description: Message signed with

Re: [9] RFR (M): 8050053: Improve caching of different invokers

On Jul 11, 2014, at 6:35 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050053/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050053 > > Improve sharing of different invokers: basic, generic & exact invokers, > uninitialized call site invoker and NamedFunction invoker

Re: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code

On Jul 11, 2014, at 6:18 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050052 > > Numerous small code cleanups in java.lang.invoke package. > > Testing: jtreg, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD

Re: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke

On Jul 11, 2014, at 2:21 PM, Vladimir Ivanov wrote: > Igor, thanks for the hint! Yes, much better. > Updated version: > http://cr.openjdk.java.net/~vlivanov/8049555/webrev.01/ > +1 Paul. signature.asc Description: Message signed with OpenPGP using GPGMail _

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Jul 9, 2014, at 8:04 PM, John Rose wrote: > On Jul 9, 2014, at 3:14 AM, Paul Sandoz wrote: > >> >> I quickly verified the fold up does as you expect. Also, if i do the >> following the null check goes away: >> >> ... >> >> void tes

Re: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke

On Jul 10, 2014, at 1:57 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8049555/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8049555 > > Code cleanup: > - moved varargsArray(Class,int) & varargsArray(int) from > sun.invoke.util.ValueConversions to java.lang.invoke.

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Jul 8, 2014, at 9:09 PM, John Rose wrote: > Regarding the extra cast in accessor logic that Paul picked up on: That may > be a left-over from obsolete versions of the code, or it may cover for some > corner cases, or it could possibly be a re-assurance to the JIT. > > Generally speaking,

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov wrote: > I'd like to revive this review thread. > > Updated version: > http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/ > Seems ok. I don't claim to be knowledgable enough in the finer points of conversion/casting/verification but i could se

Re: [9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors

On Jul 8, 2014, at 12:40 PM, Paul Sandoz wrote: > > On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov > wrote: > >> I'd like to revive review this review thread. >> >> Updated version: >> http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/ >&

Re: [9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors

On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov wrote: > I'd like to revive review this review thread. > > Updated version: > http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/ > +1 Paul. signature.asc Description: Message signed with OpenPGP using GPGMail __

Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method

On Jun 6, 2014, at 11:31 AM, Vladimir Ivanov wrote: > John, Paul, > > I always welcome valuable suggestions, so here's an update :-) > http://cr.openjdk.java.net/~vlivanov/8032400/webrev.02/ > > IMO, the test is much cleaner now. > Yes, I like it, easier to understand. Paul. signature.as

Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method

On Jun 6, 2014, at 1:17 AM, John Rose wrote: > Reviewed. > > This is not a requirement, but I would prefer (in general) to see less test > logic in ASM-generated bytecode and more in Java. I am guessing that the > invokeExact call could have been replaced by a simple weakly-typed invoke > c

Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method

On Jun 4, 2014, at 5:25 PM, Vladimir Ivanov wrote: > https://bugs.openjdk.java.net/browse/JDK-8032400 > http://cr.openjdk.java.net/~vlivanov/8032400/webrev.00/ > > Consider the following hierarchy: > class T1{int m() { return 1; }} > class T2 extends T1 { static int m() {

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

On Apr 25, 2014, at 12:04 PM, Peter Levart wrote: > This is a ping for any Reviewer and also a question for Vladimir. > > Hello Vladimir, > > What do you think about the classloader issue in the resolving of classes in > MemberName.getMethodType() described below? > I looked a bit more clos

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

Hi Peter, IMHO such security manager usage by the test is v. fragile and we should try and find a safer alternative if possible. However, there may also be an issue with lambda form code. (About a month ago i too was looking, internally, at this kind of issue and thought there was a questionab

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Apr 8, 2014, at 1:53 AM, Vladimir Ivanov wrote: > Thanks, Chris. > > I have to do one more iteration: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.05/ > > I have to revert changes related to BMH::reinvokerTarget. > > Removal of reinvokerTarget in generated concrete BMH classes in

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Apr 2, 2014, at 4:16 PM, Paul Sandoz wrote: > >>>> Regarding redundant null check, do you have a test case so I can play with >>>> it myself? >>>> >>> >>> I will send something to you later today or tomorrow. >>> > &g

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Apr 1, 2014, at 6:21 PM, Vladimir Ivanov wrote: > On 4/1/14 7:29 PM, Paul Sandoz wrote: >> >> On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov >> wrote: >> >>> Paul, >>> >>> Unfortunately, additional profiling doesn't work for Accesso

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Apr 1, 2014, at 3:57 PM, Vladimir Ivanov wrote: > Paul, thanks for review. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.04/ > +1 Paul. signature.asc Description: Message signed with OpenPGP using GPGMail ___ mlvm-

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov wrote: > Paul, > > Unfortunately, additional profiling doesn't work for Accessor.checkCast case. > The problem is Accessor.checkCast is called from multiple places, so type > profile is very likely to be polluted. And it kills the benefits. > So

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Mar 14, 2014, at 5:36 PM, Vladimir Ivanov wrote: >> Doh! crossed webrevs, thanks. >> >> Just had a quick look, this looks like a really nice improvement to the >> array setter/getter support, definitely simplified. IIUC the mh.viewAsType >> will now handle the appropriate casting. I believe

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

Hi Vladimir, This looks good. Minor stuff below. I too prefer *_TYPE instead of Int/Float/Void etc as those are not v. friendly for static imports. Paul. LambaForm: -- private static int fixResult(int result, Name[] names) { if (result == LAST_RESULT) result = names.le

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Mar 14, 2014, at 2:17 PM, Vladimir Ivanov wrote: > Paul, > > You are looking at the other fix (8037210). > The correct link is [1]. > Doh! crossed webrevs, thanks. Just had a quick look, this looks like a really nice improvement to the array setter/getter support, definitely simplified.

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov wrote: > FYI, this change isn't limited to only bytecode assembly improvements, but > also contains caching of lambda forms for setters/getter of typed arrays. > Do you mean for MethodHandles.arrayElementGetter/Setter? If so i don't see relevant

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

On Feb 20, 2014, at 6:57 PM, Vladimir Ivanov wrote: > Paul, > > Thanks for the feedback! See my answers inline. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/ > > I finally figured out how to make caching work. This webrev contains these > changes. > +

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

Hi Vladimir, I know just enough about this area to be dangerous src/share/classes/java/lang/invoke/BoundMethodHandle.java 865 private static final SpeciesData[] SPECIES_DATA_CACHE = new SpeciesData[4]; Only 3 elements are stored in the above array? src/share/classes/java/lang/inv

Re: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585

On Jan 31, 2014, at 1:58 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8033278 > > The fix for 8032585 [1] introduced a regression: in some cases access check > on a reference class is omitted. > > The fix is t

Re: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585

On Jan 31, 2014, at 3:21 PM, Vladimir Ivanov wrote: > Paul, > > The transformation you suggest is equivalent, but I reluctant to apply it. > IMO, it doesn't add much value and current version is easier to read. OK, i guess we will just have to agree to disagree on that small point as i thin