To get into this faster it would be nice if the new private fields (or the existing ones for that matter) had a comment describing what they were for, e.g.
+ private final byte[] localTypes; + private final Class<?>[] localClasses; I can figure it out from the code, but it would have been a better starting point. If that there are new apparent performance regressions caused by, e.g. profile pollusion from reusing existing method handles, I am fine with this. +1 /M On 14 Mar 2014, at 14:17, Vladimir Ivanov <vladimir.x.iva...@oracle.com> wrote: > Paul, > > You are looking at the other fix (8037210). > The correct link is [1]. > > Best regards, > Vladimir Ivanov > > [1] > http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html > > On 3/14/14 4:38 PM, Paul Sandoz wrote: >> >> On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov >> <vladimir.x.iva...@oracle.com <mailto:vladimir.x.iva...@oracle.com>> 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 changes in: >> >> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html >> >> to say MethodHandleImpl.ArrayAccessor: >> >> static final class ArrayAccessor { >> /// Support for array element access >> static final HashMap<Class<?>, MethodHandle> GETTER_CACHE = new >> HashMap<>(); // TODO use it >> static final HashMap<Class<?>, MethodHandle> SETTER_CACHE = new >> HashMap<>(); // TODO use it >> >> Paul. >> >>> If there are any objections, I can back the caching logic out and >>> include it into one of upcoming changes. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 3/14/14 3:45 PM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8037209 >>>> 440 lines changed: 313 ins; 67 del; 60 mod >>>> >>>> This is a cleanup of JSR292 code to improve bytecode assembly code for >>>> lambda forms. >>>> >>>> Contributed-by: john.r.r...@oracle.com >>>> >>>> Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby >>>> >>>> Configs: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30} >>>> -D...PROFILE_LEVEL={0,1} >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-...@openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-...@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>
