Re: Making the loop combinator fast !

_ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Te

Re: MethodHandle loop body parameters and Stream.reduce accumulator parameters are not in the same order

dex, array); > instead of >value = body(index, value, array); > > the other loop combinators do not be to be changed. > > cheers, > Rémi > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.ja

Re: Isolated Methods JEP

ud reappearance in the form of a valid entry point table. We don't want arbitrary jumps into the middle of things. :-) Best, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform

Re: Isolated Methods JEP

enalty) by default IMs should have an appearance in the stack trace. However, it may make sense to suppress their appearance in cases similar to those that can be used for LambdaForms (the @Hidden annotation comes to mind). This would depend strongly on the use case, and exposing this feature might

Re: Isolated Methods JEP

exceptions. > I do like the fiber ideas. It would be interesting to try to make the fiber > idea a standard > feature. This seems like a way to get stack manipulation as well even > without reification. > > Ah yes, mission creep. I would be happy with a fast defineClass with the

Re: Isolated Methods JEP

l an IM "anonymous" because it should be given a name. If it is supposed to appear in a stack trace, that would be most helpful. The class to be displayed in this case can be the "host", but it should be displayed differently than usual to avoid the notion of class membershi

Re: Isolated Methods JEP

us. ;-) Best, Michael [1] https://en.wikipedia.org/wiki/Gargantua_and_Pantagruel -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG |

Re: ClassValue perf?

2/webrev.04.2.bench_results.txt > > > Regards, Peter -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schif

Re: ClassValue perf?

Hi Peter, the internal tests look good. I'll assign the issue over to you. Thanks! Best, Michael > Am 26.05.2016 um 14:42 schrieb Michael Haupt <michael.ha...@oracle.com>: > > Hi Peter, > > thank you for this wonderful piece of work. > >> Am 26.05.2016

Re: ClassValue perf?

118.095 104.374 CVEB.redeployPartition N/A N/A 392.969 445.776 370.319 345.316 CVEB.redeployPartition N/A N/A 464.723 419.487 252.764 146.739 CVEB.redeployPartition N/A N/A 1646.825 1553.961 773.508 428.923 -- Dr. Michael Haupt | Principal Member of Technical StaffPhone: +49 331 200 7277 |

Re: ClassValue perf?

Hi Aleksey,thanks; comments inlined.Am 19.05.2016 um 15:57 schrieb Aleksey Shipilev <aleksey.shipi...@oracle.com>:On 05/19/2016 03:32 PM, Michael Haupt wrote:It may well be that running the bechmark so few times does not deliver astable enough result. I'd like Aleksey to c

Re: ClassValue perf?

unknown16ss 16 825.090 ± 95.535 ms/op Am 08.05.2016 um 17:18 schrieb Peter Levart <peter.lev...@gmail.com>: Hi Michael, On 05/06/2016 04:48 PM, Michael Haupt wrote: Hi Peter, thank you. I've run th

Re: ClassValue perf?

so don’t worry too > much about it. IIRC Graal has adopted static field storage for its single-value case. Beating that with a solution that has to have the flexibility of multiple values as well? Fat chance. :-) Thanks for confirming, Michael -- <http://www.oracle.com/> Dr. Michae

Re: ClassValue perf?

evaluate further. Best, Michael > Am 05.05.2016 um 17:21 schrieb Peter Levart <peter.lev...@gmail.com>: > > Hi Michael, > > > On 05/04/2016 06:02 PM, Michael Haupt wrote: >> Hi Peter, >> >> thank you for chiming in again! :-) I'll look at this in d

Re: ClassValue perf?

Hi Peter, thank you for chiming in again! :-) I'll look at this in depth on Friday. Best, Michael > Am 04.05.2016 um 17:50 schrieb Peter Levart <peter.lev...@gmail.com>: > > Hi, > > On 04/29/2016 10:28 AM, Michael Haupt wrote: >> All, >> >> see htt

Re: ClassValue perf?

Hi again, I've uploaded a reformatted results file (and an Excel sheet in case that's interesting) that show the results side by side. Best, Michael > Am 02.05.2016 um 10:38 schrieb Michael Haupt <michael.ha...@oracle.com>: > > Hi Jochen, > > thanks for clarifying. I'

Re: ClassValue perf?

> <http://cr.openjdk.java.net/~mhaupt/8031043/benchmark/ClassValueBench.java> > contains some numbers, but I cannot tell if they compare or not. At least it > does not contain the numbers I would expect > > bye Jochen > > On 29.04.2016 15:21, Michael Haupt wrote: >&

Re: ClassValue perf?

Hi Jochen, > Am 29.04.2016 um 14:42 schrieb Jochen Theodorou <blackd...@gmx.org>: > On 29.04.2016 13:19, Michael Haupt wrote: >> Hi Jochen, >> >>> Am 29.04.2016 um 12:17 schrieb Jochen Theodorou <blackd...@gmx.org >>> <mailto:blackd...@gmx.org&g

Re: ClassValue perf?

long as there is only one value associated with a class. As soon as a second value comes in, the ClassValue will transition to the usual map storage. Please let me know if this is a response to your concern. Best, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Mem

Re: ClassValue perf?

given the additional data that must be kept around to make transition to map storage safe. Opinions? Best, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTool

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

s intentional (result type = loop variable type, rather than result type = loop variable). > I guess in the future there may be ample opporunity to specialize the generic > “loop” mechanism with LambdaForms? Yep: https://bugs.openjdk.java.net/browse/JDK-8143211 Best, Michael -- <h

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

d > loop combinators in InvokerBytecodeGenerator to compile them in more > efficient bytecode shapes. If yes, please, file corresponding RFEs. Absolutely; this is on my to-do list anyway. https://bugs.openjdk.java.net/browse/JDK-8143211 Best, Michael -- <http://www.oracle.com

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

Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8139885 Corresponding JEP: https://bugs.openjdk.java.net/browse/JDK-8130227 Webrev: http://cr.openjdk.java.net/~mhaupt/8139885/webrev.00/ Thanks, Michael -- <http://www.oracle.com/> Dr. Michael

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

mel case. ;-) I see your point, and wasn't happy with my original proposal either. > Perhaps a note in the javadoc that this is the preferred method for internal > use would be sufficient? We can't make a reference from public method to the > package-private one in javadoc though. That's a g

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

appear before first > `@run' Yes. The test is also marked as ignored until another issue is fixed, so that can be ignored. Other than the above remark/suggestion, this looks fine. I'll defer to an upper-case Reviewer, though. Best, Michael -- <http://www.oracle.com/> Dr. Michael

Re: ClassValue rooting objects after it goes away?

a WeakReference into the ClassValue it seriously diminishes its utility to us. - Charlie -- http://www.oracle.com/ Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V

Re: [9] RFR: 8060717: [TESTBUG] Improve test coverage of MethodHandles.explicitCastArguments()

/8060717/webrev.00/ note that mine is a lower-case review and does not count, but: thumbs up. The level of detail at which the API is tested improves significantly with these changes. Best, Michael -- http://www.oracle.com/ Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49

hg: mlvm/mlvm/jdk: meth-lazy: removed obsolete DataBinding interface and commented-out code

Changeset: 4d38d18ba364 Author:mhaupt Date: 2012-07-13 10:45 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4d38d18ba364 meth-lazy: removed obsolete DataBinding interface and commented-out code ! meth-lazy-7023639.xbmh.patch

Re: Testing out latest work

that always triggered the dreaded NCDFE. Wonderful! Can you say some more about the performance? How much slower is it? Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. Co. KG

Re: review request (M): 6711908: JVM needs direct access to some annotations

with payload (none of the annotations introduced by our work do this). @@ -2560,10 +2727,11 @@ TempNewSymbol sde_symbol is never used. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. Co. KG

hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding

Changeset: 79c955d995f0 Author:mhaupt Date: 2012-07-11 22:07 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/79c955d995f0 meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding ! meth-lazy-7023639.xbmh.patch

Re: hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding

so the cast near the end of the method can be removed. I'd like to keep that to make really clear what Class type instances are expected. (There are places where Class? would just feel very wrong.) Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200

hg: mlvm/mlvm/jdk: meth-lazy: refactorings, made test more stressful

Changeset: 0a120a3124fe Author:mhaupt Date: 2012-07-12 00:47 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/0a120a3124fe meth-lazy: refactorings, made test more stressful ! meth-lazy-7023639.xbmh.patch ___ mlvm-dev mailing list

Re: hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding

Hi, Am 12.07.2012 um 00:26 schrieb Rémi Forax: Or perhaps you can use asSubClass() ? asSubclass() it is. :-) Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. Co. KG

hg: mlvm/mlvm/jdk: meth-lazy: more robust XBMH creation/cloning, refactoring

Changeset: 0045d0c0a3d2 Author:mhaupt Date: 2012-07-10 13:46 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/0045d0c0a3d2 meth-lazy: more robust XBMH creation/cloning, refactoring ! meth-lazy-7023639.xbmh.patch ___ mlvm-dev

hg: mlvm/mlvm/jdk: meth: avoid binding of Unsafe instances and superfluous nulls in field getters/setters; provide immediate literal binding facility rudiment

Changeset: 9413fdf424cd Author:mhaupt Date: 2012-07-02 10:12 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9413fdf424cd meth: avoid binding of Unsafe instances and superfluous nulls in field getters/setters; provide immediate literal binding facility rudiment !

hg: mlvm/mlvm/jdk: meth: BMH refactorings

Changeset: bc14db7367b6 Author:mhaupt Date: 2012-07-02 13:29 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/bc14db7367b6 meth: BMH refactorings ! meth-lazy-7023639.xbmh.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net

hg: mlvm/mlvm/jdk: meth: BMH meta-data, refactorings

Changeset: 71c151b678c1 Author:mhaupt Date: 2012-06-27 14:28 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/71c151b678c1 meth: BMH meta-data, refactorings ! meth-lazy-7023639.xbmh.patch ___ mlvm-dev mailing list

hg: mlvm/mlvm/hotspot: meth: removed unnecessary (empty) BMH patch

Changeset: f9ab85493169 Author:mhaupt Date: 2012-06-25 17:00 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f9ab85493169 meth: removed unnecessary (empty) BMH patch - meth-lazy-7023639.xbmh.patch ___ mlvm-dev mailing list

hg: mlvm/mlvm/hotspot: 2 new changesets

Changeset: a8cf2f000298 Author:mhaupt Date: 2012-06-25 22:28 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a8cf2f000298 meth: fixed series file ! series Changeset: c6b2a28687f5 Author:mhaupt Date: 2012-06-25 22:29 +0200 URL:

Re: hg: mlvm/mlvm/hotspot: rebase to current hsx/hotspot-comp (except .jit and .xbmh patches)

John, Am 20.06.2012 um 05:51 schrieb john.r.r...@oracle.com: Changeset: 67a314048583 Author:jrose Date: 2012-06-19 20:51 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/67a314048583 rebase to current hsx/hotspot-comp (except .jit and .xbmh patches) with nochain

Re: meth-lazy bug in bytecode generation?

to true to have all LFI (NFI, EI) class files serialised. This also enables unique numbering. The dumped class files contain textual descriptions of the respective LFs as well, so it's easier to see what the problem is all about. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical