Re: guardIfConstant, the constant sniffer combinator

This is very similar to a "growable switch" combinator, which would call the provider for each distinct selector value. A key difference is that non-constant values go through the fallback, where a "growable switch" doesn't need a fallback, since the provider MH is always free to just return a sta

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

On Apr 9, 2018, at 1:17 PM, Ioi Lam wrote: > > So why is this first argument not declared as a MethodHandle? > The short answer is to simplify the plumbing of lambda forms. Method handles are strongly typed but the underlying IR of lambda forms is weakly typed. This keeps the IR simple. To ma

Re: Strange observation: MethodHandle.invokeWithArguments() would not work, whereas Method.invoke() would with the very same arguments

On Feb 12, 2018, at 11:59 AM, Rony G. Flatscher wrote: > > While testing a rather complex one (an adaption of the JavaFX address book > example enhanced with a > BarChart, [1]), that exhibits a very strange behavior: when setting the > values for the CategoryAxis > supplying an ObservableList o

Re: Performance of non-static method handles

Vladimir Ivanov did some work a few years ago on MH customization for hot MH instances. It’s in the system. That should get better results than what you show. I wonder why it isn’t kicking in. You are using invokeExact right? > On Feb 2, 2018, at 1:26 PM, Charles Oliver Nutter wrote: > > Hey f

Re: Switch vs if ?

(like HashMap). It can have special sub-implementations for integral types (esp. if the actual traffic is dense) or for Comparables (using TreeMap). I suppose the harder question is how to deal with key weakness. Maybe the combinator is given a Map class or factory? — John On Jan 19, 2018, at 8:52

Re: Writing a compiler to handles, but filter seems to executed in reverse

nment (build 8.0.5.7 - > pxa6480sr5fp7-20171216_01(SR5 FP7)) > IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References > 20171215_373586 (JIT enabled, AOT enabled) > OpenJ9 - 5aa401f > OMR - 101e793 > IBM - b4a79bf) > > so it's an implementation bug, #2 seems t

Re: Writing a compiler to handles, but filter seems to executed in reverse

On Jan 2, 2018, at 12:35 PM, Charles Oliver Nutter wrote: > > Is there a good justification for doing it this way, rather than having > filterArguments start with the *last* filter nearest the target? No, it's a bug. The javadoc API spec. does not emphasize the ordering of the filter invocation

Re: Writing a compiler to handles, but filter seems to executed in reverse

On Jan 2, 2018, at 12:36 PM, Charles Oliver Nutter wrote: > > An alternative workaround: I do the filters myself, manually, in the order > that I want them to executed. Also gross. (Under the theory that the spec. is ambiguous, leading to implementor's choice, this would be your only option.) _

[BSM-RETURNS-MH] allow invokedynamic BSM to return MethodHandle instead of CallSite

As we use BSMs more and more, we will want to dispense with the CallSite infrastructure, in many cases. I filed an RFE to track this. If we can agree on specification, it will be fairly easy to implement. (I am CC-ing this to valhalla-spec-experts, for visibility to non-OpenJDK people.) — John

Re: constant-dynamic specification, updated

On Jun 25, 2017, at 3:00 PM, Per Bothner wrote: > > That will be difficult as long as constant pool indexes and various > other fields are limited to 16 bits. Yep; that's a challenge, until we break the glass and make a completely new class file format that integrates a var-int format. (My favor

Re: constant-dynamic specification, updated

On Jun 25, 2017, at 12:47 PM, Mark Roos wrote: > > I was looking for boot strap args to allow byte[] constants from the > constantPool. > > Is that planned? Yes; there are two more CP types planned: 1. CONSTANT_Data = arbitrary blob of octets 2. CONSTANT_Group = series of constant specifier

Fwd: constant-dynamic specification, updated

Date: June 24, 2017 at 4:52:04 PM PDT To: valhalla-spec-expe...@openjdk.java.net I have updated the javadoc API that is relevant to the proposed JVM features for dynamic constants and more powerful bootstrap methods. http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html Here is a rough

Re: the End of History in the constant pool

On May 18, 2017, at 6:55 PM, Mark Roos wrote: > > Does this allow the use of a byteArray as one or more of the bootstrap > constants? > > I seem to recall that was something I wished for when I did a similar effort > with > constant call sites. Yes, it does. The byte array would be its ow

Re: the End of History in the constant pool

On May 18, 2017, at 2:13 PM, fo...@univ-mlv.fr wrote: > > uses invokeinterface then the spec was rebooted, the second version has it's > own bytecode 186, There was another in between that used invokeinterface and reified a CallSite with patchable state. I did a really nasty design for this w/

Re: the End of History in the constant pool

On May 18, 2017, at 12:55 PM, John Rose wrote: > > I'll post some info about that in a moment. Here's what we are thinking about doing with condy in the short term. Comments are welcome. This work is landing in branches of the Amber project. — John Just as the linkage of

the End of History in the constant pool

(I'm moving an amber-dev conversation about condy to mlvm-dev.) We are working on a condy JEP and spec. as well as a prototype, which is good progress. I'll post some info about that in a moment. On May 18, 2017, at 12:16 PM, Remi Forax wrote: > > I would prefer 17 to 21, because 21 is already

Re: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class

On May 5, 2017, at 5:44 AM, Vladimir Ivanov wrote: > > In other words, LF specialization influence how many classes for compiled LFs > are loaded, but doesn't change what actually happen during MH invocation. (No > inlining on bytecode level is needed during specialization. JIT will already >

Re: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class

On May 3, 2017, at 9:37 PM, Wenlei Xie wrote: > > Thank you Vladimir for the help ! I see the point why MH.bindTo() is not a > good fit for implementing lambda capturing. A simple rule for using MHs is that they are designed to be another form of code. Creating many of them at a high rate is

Re: Ephemerons for Java

On Jan 9, 2017, at 5:27 PM, John Rose wrote: > Thanks! That's a great start. Should be a JEP. — John P.S. You got me. I filed https://bugs.openjdk.java.net/browse/JDK-8172476 to help track this. ___ mlvm-dev mailing list

Re: Ephemerons for Java

On Jan 9, 2017, at 4:55 PM, Florent Guillaume wrote: > > Peter Levart discussed a prototype for Ephemerons a year ago: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038094.html > > > Florent

Re: Ephemerons for Java

On Jan 9, 2017, at 4:36 PM, Jochen Theodorou wrote: > > Hi all, > > This is kind of a feature request... What I would like to have is a new > Reference variant that allows me to keep an instance alive for as long as the > class of the object is alive, without the instance keeping the class ali

Re: Leaking LambdaForm classes?

Could be LF caching gone rogue. Does the user create many LF shapes, e.g. one per datum? – John > On Jan 6, 2017, at 9:32 AM, Charles Oliver Nutter wrote: > > Anyone else encountered this? > > https://github.com/jruby/jruby/issues/4391 > > We have a user reporting metaspace getting filled up

Re: EXT: Re: series of switchpoints or better

On Oct 5, 2016, at 12:45 PM, Charles Oliver Nutter wrote: > > It is also good to hear that the old "once invalidated, it will not optimized > again - ever" is no longer valid. > > And hopefully it will stay that way as long as we keep making noise :-) Go ahead, be that way!___

Re: series of switchpoints or better

On Oct 5, 2016, at 7:00 AM, Charles Oliver Nutter wrote: > > I will say that using SwitchPoints is FAR better than our alternative > mechanism: pinging the (meta)class each time and checking a serial number. This makes my day! That's exactly what SwitchPoints are designed to deliver. They ar

Re: A fast JSON serializer

On Sep 14, 2016, at 3:03 PM, Remi Forax wrote: > > Another idea from the JVM Summit, > because the JDK9 now uses fast string concatenation by default, a JSON > serializer based on reflection can be outperformed by a hand written code. > > The following code is a small JSON serializer that use

Re: Isolated Methods JEP

On Aug 12, 2016, at 2:56 PM, Michael Haupt wrote: > > Hi Mark, > >> Am 05.08.2016 um 12:13 schrieb Mark Roos > >: >> Good to see this. > > thanks. :-) > >> What is the philosophy for code annotations, line numbers and stack maps? >> >> Would they be some form of consta

Re: Isolated Methods JEP

On Aug 12, 2016, at 2:56 PM, Michael Haupt wrote: > > Hi Martijn, > >> Am 09.08.2016 um 00:15 schrieb Martijn Verburg > >: >> Love the overall idea. A few thoughts (feel free to ignore as I'm by no >> means an expert in the VM). > > thank you. As this JEP span

Re: Isolated Methods JEP

On Aug 12, 2016, at 2:57 PM, Michael Haupt wrote: > > Hi Peter, > > thanks for your feedback! I'm responding to both your messages in one. > >> Am 09.08.2016 um 05:05 schrieb Peter Levart > >: >> In the JEP's description you write: >> >> "The loadCode method crea

Re: FTR: JSR 292 RFEs from yesterday's Indy Support Group

On Aug 4, 2016, at 9:11 AM, Mark Roos wrote: > > With respect to general data in constant pools > > Adding raw bytes as a constant type would be a good thing. I currently > have to encode my object serialization as hex utf8 which is not nice. +1 > As for the use of a MH to instantiate the

Re: Threaded interpreter in Java

On Aug 3, 2016, at 1:22 PM, Remi Forax wrote: > > Charles ask if we can make a fast register interpreter in Java, > here is my take on a threaded-like interpreter > > https://gist.github.com/forax/f38b533e089217cfc4d0ae3c6e2de9c9 Nicely done. We were talking last night at dinner about making b

FTR: good old paper on quasi-quotation

Related to some discussion at the JVMLS about quasi-constants (templates, constants with holes), here is the early history of quasi-quoting in computing, as reported by someone who was there. Alan Bawden, Quasiquotation in Lisp (1999) http://repository.readscheme.org/ftp/papers/pepm99/bawden.pdf

Re: FTR: JSR 292 RFEs from yesterday's Indy Support Group

And one more (mention in my BSMs Everywhere segment): general data in constant pools https://bugs.openjdk.java.net/browse/JDK-8161256 On Aug 2, 2016, at 2:27 PM, John Rose wrote: > > some frameworks need access delegation via MethodHandles.lookup > https://bugs.openjdk.java.net/b

FTR: JSR 292 RFEs from yesterday's Indy Support Group

some frameworks need access delegation via MethodHandles.lookup https://bugs.openjdk.java.net/browse/JDK-8162494 some frameworks want to advise method handle optimization https://bugs.openjdk.java.net/browse/JDK-8163006 CallSites should support polymorphic inline caches https://bugs.openjdk.java.

Re: JVMLS indy support group provisional agenda

Thanks, to those who were present, for a very lively conversation! Here are the slides as presented today: http://cr.openjdk.java.net/~jrose/pres/201608-IndySupportGroup.pdf I would like to add notes to the end of the deck, to summarize what we actually discussed. I could use some help with

Re: JVMLS indy support group provisional agenda

njdk.java.net/pipermail/mlvm-dev/2015-February/006292.html > > > On 7/31/16 10:13 PM, John Rose wrote: >> Tomorrow at the JVMLS we will have an hour-long workshop to discuss indy >> and MHs. >> I plan to run this as a Q/A and (if we are in good form) a >> brain-storming ses

JVMLS indy support group provisional agenda

Tomorrow at the JVMLS we will have an hour-long workshop to discuss indy and MHs. I plan to run this as a Q/A and (if we are in good form) a brain-storming session. Here are the discussion topics that pop quickly to the top of my list. Any more suggestions? — John Provisional Agenda: API §API

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

On Jul 24, 2016, at 3:41 PM, Mark Roos wrote: > > A few questions on implementation. > > My old prototype looks like: > private RtObject[] _mDicts = new RtObject[8]; // array of > method dicts > private MethodHandle[] _methods = new MethodHandle[8]; // the >

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

On May 31, 2016, at 12:41 PM, Mark Roos wrote: > > It looks like, from some fine timing, that each time the Smalltalk class > changes there is a large amount > of time added to the call. Which I would expect if there was a deopt > whenever a different GWT triggered. > There are 6 GWTs in thi

binding to indy with an annotation-driven reweaver

Inspired in part by a recent exchange between Remi and Charlie[1], I've been thinking recently, again, about binding Java APIs to indy. [1]: https://groups.google.com/forum/#!topic/jvm-languages/IjIEzDc_d3U I think I have a way to make it work, and (what is more) I think the end result looks pret

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

Quick comment. In this: >MethodHandle h0= constant(boolean.class, true); …there should a space between h0 and =. > On Apr 13, 2016, at 5:12 AM, shilpi.rast...@oracle.com wrote: > > Thank You Paul for the suggestions. > > Please review the updated webrev > http://cr.openjdk.java.net/~sra

Re: Packages and source paths.

On Mar 30, 2016, at 5:17 AM, MacGregor, Duncan (GE Energy Connections) wrote: > > I’ve been doing some work on getting useful coverage information from Jacoco > for Magik, and some of the same issues probably apply to other JVM language > implementations such as JRuby and Nashorn, so I thought

Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode

On Jan 20, 2016, at 4:13 AM, Remi Forax wrote: > > I understand that having the VM that may always recompile may be seen as a > bug, > but having the VM that bailout and stop recompiling, or more generally change > the compilation strategy is a bug too. As you can guess from my previous messag

Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode

throttle the recompilation > (e.g., long-running application with indy-based dynamic tracing). Maybe > there's a place for a new CallSite flavor to clearly communicate application > expectations to the JVM? Either always recompile (thus eventually reaching > peak performance) or

Re: MethodHandles.Lookup and modules

l with the new API point Lookup.findClass, which uses the lookupClass as a starting point for name resolution. — John Begin forwarded message: From: John Rose Subject: Re: MethodHandles.Lookup and modules Date: December 18, 2015 at 12:20:08 AM PST To: Alex Buckley Cc: jigsaw-...@openjdk.java.n

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

On Nov 13, 2015, at 8:39 AM, Michael Haupt wrote: > > 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/ >

Re: JFokus VM Tech Day 2016

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.___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Proposed API for JEP 259: Stack-Walking API

On Oct 31, 2015, at 12:54 PM, Vitaly Davidovich wrote: > John, is there a link for more info on "true polymorphism" It's what's in Valhalla, if you ignore the value types. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net

Re: Proposed API for JEP 259: Stack-Walking API

On Oct 31, 2015, at 12:51 PM, John Rose wrote: > > modules, true polymorphism, value types, native interconnect P.S. Project refs: Jigsaw, Valhalla (List), Valhalla, Panama.___ mlvm-dev mailing list mlvm-dev@openjdk.java.ne

Re: Proposed API for JEP 259: Stack-Walking API

On Oct 31, 2015, at 11:50 AM, Remi Forax wrote: > > I think most of the runtime language developers, myself included will kill to > have this feature included into the JDK. > There are several features of dynamic languages that are currently hard to > implement like type specialization, stack r

Re: invokespecial-super-init

On Sep 17, 2015, at 10:10 AM, Michael Haupt wrote: > > ummm ... this seems to imply I can remove the findSuperConstructor() proposal > from the Indy JEP. Incidentally, it's on my list for this week - and less > work is always good. ;-) Even if, in this case, it leads to disappointment. I > agr

Re: invokespecial-super-init

s supposed to. Since the wrapper constructors are marked private, it is impossible for untrusted parties to inject malicious MH code. The MH could be replaced by a private instance method, if there is no need to have a different MH at different construction sites.) What do you think? Is th

invokespecial-super-init

The invokespecial-super-init dance is the thing MH's can't quite do, the "super" call every constructor (except Object.). It very hard to secure this pattern; just ask anybody who has worked on (de-)serialization security. But, we can look at it from a more limited point of view which might imp

Re: What can we improve in JSR292 for Java 9?

On Aug 26, 2015, at 6:06 AM, Rémi Forax wrote: > > it's less powerful but it seems you can encode all your examples of loops too. No, I don't think so. Multiple pred/fini pairs implement multiple loop exits. Any loop with an "if-return" in it has an exit distinct from the loop's main test. And

Re: What can we improve in JSR292 for Java 9?

On Feb 25, 2015, at 6:29 PM, John Rose wrote: > > Maybe this is general enough: > >MHs.loop(init, predicate, body)(*a) >=> { let i = init(*a); while (predicate(i, *a)) { i = body(i, *a); } > return i; } > > ...where the type of i depends on init, and if

Re: ClassLoader leak in MethodHandle.asType()

On Apr 24, 2015, at 3:24 PM, Peter Levart wrote: > > Anyway. The inexact invoke() always transforms a specific MH to a generic one > (Object, Object, ...)Object, right? Yes. > So using inexact invoke() on any MH can't trigger the leak. It's just that if > someone attempts to transform a gener

Re: ClassValue perf?

On Apr 24, 2015, at 5:38 AM, Charles Oliver Nutter wrote: > > Hey folks! > > I'm wondering how the performance of ClassValue looks on recent > OpenJDK 7 and 8 builds. JRuby 9000 will be Java 7+ only, so this is > one place I'd like to simplify our code a bit. > > I could measure myself, but I'm

Re: ClassLoader leak in MethodHandle.asType()

Good point. Are you seeing a leak in practice? The cache is important, especially to inexact MH.invoke. — John On Apr 24, 2015, at 9:14 AM, Peter Levart wrote: > > I think there is a Class(Loader) leak in MethodHandle.asType() > implementation. If for example some MH (say mhX) is long lived (b

Re: [9] RFR (XS): 8078290: Customize adapted MethodHandle in MH.invoke() case

Reviewed. Nice find. – John > On Apr 21, 2015, at 10:37 AM, Vladimir Ivanov > wrote: > > http://cr.openjdk.java.net/~vlivanov/8078290/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8078290 > > Customization logic introduced in [1] doesn't work as expected for > MH.invoke() when asTyp

Re: comment from James Gosling on multi-language VM

If you look closely at the date of the question, you'll see that it is almost exactly 20 years old, as is James' answer. — John > On Apr 17, 2015, at 10:40 AM, Fernando Cassia wrote: > > > On Thu, Apr 16, 2015 at 8:19 PM, John Rose <mailto:john.r.r...@oracle.com>

comment from James Gosling on multi-language VM

James made some relevant comments on the JVM as a multi-language engine. It was just a little while ago, as I noticed going through some old files. Folks are still working on specialized allocation (aka. value types) and continuations (aka. coroutines & tailcall). Also, C is no longer "right ou

Re: [9] RFR (XXS): 8077054: DMH LFs should be customizeable

Looks good. Would you please also check the number of distinct LFs compiled when running standard benchmarks? (With and without the change.) The number should go up, but only slightly. Thanks! — John On Apr 9, 2015, at 11:44 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vliva

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

On Apr 2, 2015, at 3:08 PM, Vladimir Ivanov wrote: > > Member access permission check isn't performed if caller and member owner > class are loaded by the same class loader (which is the case with > CallSite$DependencyContext and CallSite classes). Heh! And I thought I had compiled the refle

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

On Apr 2, 2015, at 9:17 AM, Vladimir Ivanov wrote: > >> >> I recommend putting CONTEXT_OFFSET into CallSite, not the nested class. >> For one thing, your getDeclaredField call will fail (I think) with a >> security manager installed. >> You can load it up where TARGET_OFFSET is initialized. >

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

On Apr 1, 2015, at 1:56 PM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/hotspot/ > http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/jdk/ > https://bugs.openjdk.java.net/browse/JDK-8057967 Impressive work. Question: How common is state 2 (context-fre

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

On Mar 18, 2015, at 3:59 AM, Paul Sandoz wrote: > > Perhaps such method handles were originally cached to avoid an explosion > (deliberate or otherwise) of class generation of LFs, but now there is more > sophisticated LF caching in place this is not necessary.? That's probably correct. Per-M

Re: [9] RFR (S): 8075263: MHI::checkCustomized isn't eliminated for inlined MethodHandles

Reviewed. — John On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot > http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk > https://bugs.openjdk.java.net/browse/JDK-8075263 ___

Re: [9] RFR (S): 8074548: Never-taken branches cause repeated deopts in MHs.GWT case

Good fix, thanks. — John P.S. I noticed a typo: "it's" (contraction of "it is") should be "its" (genitive of "it"). On Mar 16, 2015, at 11:26 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8074548/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8074548 > > Metho

Re: What can we improve in JSR292 for Java 9?

On Mar 4, 2015, at 2:47 PM, Charles Oliver Nutter wrote: > > Busy week, finally circling back to this thread... > > On Wed, Feb 25, 2015 at 8:29 PM, John Rose wrote: >>> * A loop handle :-) >>> >>> Given a body and a test, run the body until the test is

Re: What can we improve in JSR292 for Java 9?

On Mar 6, 2015, at 5:30 AM, Vladimir Ivanov wrote: > >>> * try/finally as a core atom of MethodHandles API. >>> >>> Libraries like invokebinder provide a shortcut API To generating the >>> large tree of handles needed for try/finally, but the JVM may not be >>> able to optimize that tree as wel

Re: Lost perf between 8u40 and 9 hs-comp

On Mar 3, 2015, at 3:21 PM, Vladimir Ivanov wrote: > > Ah, I see now. > > You suggest to conditionally insert uncommon trap in MHI.profileBoolean when > a count == 0, right? > > Won't we end up with 2 checks if VM can't fold them (e.g. some action in > between)? Maybe; that's the weak point

Re: Lost perf between 8u40 and 9 hs-comp

On Mar 3, 2015, at 8:23 AM, Vladimir Ivanov wrote: > >> Suggestion: Instead of have the intrinsic expand to nothing, have it expand >> to an uncommon trap (on the slow path), with the uncommon trap doing the >> profile update operation (as currently coded). > Right now, VM doesn't care about

Re: Lost perf between 8u40 and 9 hs-comp

On Mar 2, 2015, at 12:00 PM, Vladimir Ivanov wrote: > > Charlie, I found the root cause. > > So, the problem is never-taken branches indeed. > The way how branch profiling for GWT (JDK-8063137 [1]) is performed doesn't > work well. > > I hoped that profile collection and injection actions can

Re: What can we improve in JSR292 for Java 9?

On Feb 25, 2015, at 5:09 PM, Mark Roos wrote: > > I would like to see some form of PIC (polymorphic inline cache ) support that > jits (inlines) well and transitions from mono to bi to multi(4,5) to mega > nicely. What would be the starting points for such a thing? It seems to be like Charl

Re: What can we improve in JSR292 for Java 9?

On Feb 25, 2015, at 4:02 PM, Charles Oliver Nutter wrote: > > After talking with folks at the Jfokus VM Summit, it seems like > there's a number of nice-to-have and a few need-to-have features we'd > like to see get into java.lang.invoke. Vladimir suggested I start a > thread on these features. >

Re: FYI: LambdaForm-based java.lang.invoke implementation overview

Oops, as it turns out, that was for FTPR = For The Public Record. I neglected to Reply-Single; apologies for the noise, everyone. — John On Feb 21, 2015, at 3:54 PM, John Rose wrote: > > Here's copy of my Skype comments to you, FTR. — John _

Re: FYI: LambdaForm-based java.lang.invoke implementation overview

Here's copy of my Skype comments to you, FTR. — John Great slide deck! Error on slide 12: invokespecial *has* a receiver. While I'm tweaking, I suppose you could say "single dispatch (via table)" vs. "single dispatch (via search)", but that's a matter of debate. Slide 13: optional static argum

Re: Invokedynamic and recursive method call

On Jan 7, 2015, at 8:13 AM, Remi Forax wrote: > > But if fibo is called through an invokedynamic, instead of emitting a direct > call to fibo, > the JIT generates a code that push the method handle on stack and execute it > like if the metod handle was not constant > (the method handle is consta

Re: [9] RFR (XS): 8071787: Don't block inlining when DONT_INLINE_THRESHOLD=0

Good. Consider fixing the typo in 'makeBlockInlningWrapper'. — John On Jan 28, 2015, at 9:12 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8071787/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8071787 > > For testing & performance measurements, sometimes it's us

Re: [9] RFR (XXS): 8071788: CountingWrapper.asType() is broken

Good. On Jan 28, 2015, at 9:22 AM, Vladimir Ivanov wrote: > > The fix is to use adapted MethodHandle to construct LambdaForm. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

On Jan 28, 2015, at 1:00 AM, Vladimir Ivanov wrote: > I polished the change a little according to your comments (diff against v03): > http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03-04/hotspot > +1 Glad to see the AndI

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

Looking very good, thanks. Ship it! Actually, can you insert a comment why the injected counts are not scaled? (Or perhaps they should be??) Also, we may need a followup bug for the code with this comment: // Look for the following shape: AndI (ProfileBoolean) (ConI 1)) Since profileBoolean

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

On Jan 26, 2015, at 8:41 AM, Vladimir Ivanov wrote: > > What do you think about the following version? > http://cr.openjdk.java.net/~vlivanov/8063137/webrev.02 > > > As you suggested, I reified MHI::profileBranch on LambdaForm level and

Re: [9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

On Jan 23, 2015, at 8:00 AM, Vladimir Ivanov wrote: > > Good idea, Peter! +1 > Updated version: > http://cr.openjdk.java.net/~vlivanov/8069591/webrev.02/ > Yes, that's good, and you can count me as a reviewer. — John P.S. One could

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

On Jan 20, 2015, at 11:09 AM, Vladimir Ivanov wrote: > >> What I'm mainly poking at here is that 'isGWT' is not informative about >> the intended use of the flag. > I agree. It was an interim solution. Initially, I planned to introduce > customization and guide the logic based on that property.

Re: [9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

On Jan 22, 2015, at 9:56 AM, Vladimir Ivanov wrote: > > Remi, John, thanks for review! > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8069591/webrev.01/ > > This time I did additional testing (COMPILE_THRESHOLD > 0) and spotted a > problem with MethodHandle.copyWith(): a MethodHan

Re: [9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

On Jan 21, 2015, at 9:31 AM, Remi Forax wrote: > > in Invokers.java, I think that checkCustomized should take an Object and not > a MethodHandle > exactly like getCallSiteTarget takes an Object and not a CallSite. The use of erased types (any ref => Object) in the MH runtime is an artifact of

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

On Jan 16, 2015, at 9:16 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8063137/webrev.00/hotspot/ > > http://cr.openjdk.java.net/~vlivanov/8063137/webrev.00/jdk/ >

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

Reviewed. — John > On Dec 8, 2014, at 3:47 PM, Vladimir Ivanov > wrote: > > http://cr.openjdk.java.net/~vlivanov/8066746/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8066746 > > Recent changes (8057656 [1]) broke MHs.explicitCastArguments for > VarargsCollector case. It introduced a

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

Reviewed. I sympathize with Paul's "gnarly" comment. Nice bit of stream-ology (rheology) in the test code. Regarding: > On Dec 2, 2014, at 8:20 AM, Vladimir Ivanov > wrote: >> >> In src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java >> >> 366 lambdaForm.

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

Good, I'm happy. Reviewed. — John On Oct 28, 2014, at 12:04 PM, Vladimir Ivanov wrote: > John, thanks for the feedback! > See my answers inline. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-

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

On Oct 15, 2014, at 8:21 AM, Vladimir Ivanov wrote: >>> Updated version: >>> http://cr.openjdk.java.net/~vlivanov/8059877/webrev.01/ The algorithm looks fine, as long as the count is small. (Otherwise we might want to spend effort recompiling the DontInline LF. Call it CountingWrapper, sin

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

On Oct 10, 2014, at 2:20 PM, Remi Forax wrote: > I have another question about inOptimizer(), > thinkint a little about it, if there is a code like > if (unsafe.inOptimizer()) { > ... > } > > this code will always trigger a recompilation, at least once, because in the > interpreter, the

Re: [9] RFR (S): 8058291: Missing some checks during parameter validation

Reviewed. Nice tuning of the asserts. — John On Sep 15, 2014, at 9:03 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8058291/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8058291 > > 8057656 & 8050166 changes accidentally removed some checks during argument > vali

Re: [9] RFR (S): 8058293: Bit set computation in MHs.findFirstDupOrDrop/findFirstDrop is broken

On Sep 15, 2014, at 9:48 AM, Vladimir Ivanov wrote: > https://bugs.openjdk.java.net/browse/JDK-8058293 > http://cr.openjdk.java.net/~vlivanov/8058293/webrev.00 > > Bit set computation in MHs.findFirstDupOrDrop/findFirstDrop is incorrect due > to widening primitive conversions (int -> long) tak

Re: Unloading LambdaForm bytecode

On Sep 9, 2014, at 12:11 AM, Martin Traverso wrote: > Hi John, > > Thanks for the detailed explanation. > > I ran a few additional experiments after I wrote a simpler program to try to > reproduce the issue. I don't see the permgen leak, so something else must be > causing it in Presto. I do

Re: Unloading LambdaForm bytecode

Hi Martin. A few LFs are cached in 8u20, and many more will be in 8u40; those will not be unloaded. A non-cached LF can be viewed as customized, to the exact MH that caused its creation. It should be the case that a LF that is customized to LFs will be unloaded (with its bytecodes) as soon as

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

On Sep 5, 2014, at 7:07 AM, Morris Meyer wrote: > That assert in a static method could be pulled out to a static block. > > Regarding the asserts in the LambdaForms code, my feeling is that in code > that is still in the process of being refactored, that they are critical to > maintain integri

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

On Jul 16, 2014, at 1:50 AM, Paul Sandoz wrote: > Why not make the second parameter be "DirectMethodHandle mh" ? Good suggestion; thanks. Makes the restrictReceiver logic less magic. — John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://

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

On Sep 3, 2014, at 8:46 AM, Morris Meyer wrote: > src/share/classes/java/lang/invoke/BoundMethodHandle.java > > Could we keep /* */ comment style consistent throughout? > > @Override // there is a default binder in the super class, for 'L' > types only > /*non-public*/ Most co

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

On Sep 3, 2014, at 10:35 AM, Mark Roos wrote: > From Morris > > All that assert laden code is nice to see. > > I just finished watching a video from Doug Lea where he mentioned that having > asserts can > inhibit inlining due to the additional byte codes. So he sadly does not use

  1   2   3   4   5   6   7   8   9   10   >