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

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 >

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

Re: Switch vs if ?

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 AM, fo...@univ

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

tation bug, #2 seems to be the right solution. > > Rémi > > De: "John Rose" <john.r.r...@oracle.com> > À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net> > Envoyé: Mercredi 3 Janvier 2018 20:37:42 > Objet: Re: Writing a compiler to handles, but

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

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

[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.) —

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

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

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

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

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

Re: the End of History in the constant pool

On May 18, 2017, at 12:55 PM, John Rose <john.r.r...@oracle.com> 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.

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,

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

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

Re: Ephemerons for Java

On Jan 9, 2017, at 5:27 PM, John Rose <john.r.r...@oracle.com> 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 mai

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

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

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

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

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

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

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

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

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

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

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

] http://mail.openjdk.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

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

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

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

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 >

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

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

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 give up and generate less effici

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

Re: MethodHandles.Lookup and modules

dly useful 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 <john.r.r...@oracle.com> Subject: Re: MethodHandles.Lookup and modules Date: December 18, 2015 at 12:20:08 AM PST To: Alex Bu

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:

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

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

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

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

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

Re: invokespecial-super-init

de is 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 this c

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

invokespecial-super-init

The invokespecial-super-init dance is the thing MH's can't quite do, the super call every constructor (except Object.init). 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

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

On Aug 26, 2015, at 6:06 AM, Rémi Forax fo...@univ-mlv.fr 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

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

On Feb 25, 2015, at 6:29 PM, John Rose john.r.r...@oracle.com 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 init returns void

Re: ClassLoader leak in MethodHandle.asType()

On Apr 24, 2015, at 3:24 PM, Peter Levart peter.lev...@gmail.com 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

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 vladimir.x.iva...@oracle.com 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

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 fcas...@gmail.com wrote: On Thu, Apr 16, 2015 at 8:19 PM, John Rose john.r.r...@oracle.com mailto:john.r.r

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

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 vladimir.x.iva...@oracle.com wrote:

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

On Apr 2, 2015, at 9:17 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

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

On Apr 1, 2015, at 1:56 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

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

On Mar 18, 2015, at 3:59 AM, Paul Sandoz paul.san...@oracle.com 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

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 vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8074548/webrev.00/

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 vladimir.x.iva...@oracle.com 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: What can we improve in JSR292 for Java 9?

On Mar 6, 2015, at 5:30 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

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

On Mar 4, 2015, at 2:47 PM, Charles Oliver Nutter head...@headius.com wrote: Busy week, finally circling back to this thread... On Wed, Feb 25, 2015 at 8:29 PM, John Rose john.r.r...@oracle.com wrote: * A loop handle :-) Given a body and a test, run the body until the test is false. I'm

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

On Mar 3, 2015, at 8:23 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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,

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

On Feb 25, 2015, at 4:02 PM, Charles Oliver Nutter head...@headius.com 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

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

On Feb 25, 2015, at 5:09 PM, Mark Roos mr...@roos.com 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

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 john.r.r...@oracle.com 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

Re: Invokedynamic and recursive method call

On Jan 7, 2015, at 8:13 AM, Remi Forax fo...@univ-mlv.fr 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

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 vladimir.x.iva...@oracle.com 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 http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03-04/hotspot

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

Good. On Jan 28, 2015, at 9:22 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: The fix is to use adapted MethodHandle to construct LambdaForm. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net

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

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 vladimir.x.iva...@oracle.com wrote: What do you think about the following version? http://cr.openjdk.java.net/~vlivanov/8063137/webrev.02 http://cr.openjdk.java.net/~vlivanov/8063137/webrev.02 As you suggested, I reified MHI::profileBranch on

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

On Jan 22, 2015, at 9:56 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

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 vladimir.x.iva...@oracle.com 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

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

On Jan 21, 2015, at 9:31 AM, Remi Forax fo...@univ-mlv.fr 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

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 vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8063137/webrev.00/hotspot/ 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 vladimir.x.iva...@oracle.com 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

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 vladimir.x.iva...@oracle.com wrote: In src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java 366

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 vladimir.x.iva...@oracle.com wrote: John, thanks for the feedback! See my answers inline. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net

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

On Sep 15, 2014, at 9:48 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

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 vladimir.x.iva...@oracle.com 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

Re: Unloading LambdaForm bytecode

On Sep 9, 2014, at 12:11 AM, Martin Traverso mtrave...@gmail.com 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

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

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

On Jul 16, 2014, at 1:50 AM, Paul Sandoz paul.san...@oracle.com wrote: Why not make the second parameter be DirectMethodHandle mh ? Good suggestion; thanks. Makes the restrictReceiver logic less magic. — John ___ mlvm-dev mailing list

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

On Sep 3, 2014, at 10:35 AM, Mark Roos mr...@roos.com 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

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

On Sep 3, 2014, at 8:46 AM, Morris Meyer morris.me...@oracle.com 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

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

On Aug 28, 2014, at 7:38 AM, Paul Sandoz paul.san...@oracle.com wrote: On Jul 8, 2014, at 9:09 PM, John Rose john.r.r...@oracle.com 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

Re: The Great Startup Problem

On Aug 22, 2014, at 1:08 PM, Charles Oliver Nutter head...@headius.com wrote: Marcus coaxed me into making a post about our indy issues. Our indy issues mostly surround startup and warmup time, so I'm making this a general post about startup and warmup. This is a vigorous and interesting

Re: Defining anonymous classes

On Aug 15, 2014, at 5:03 AM, Florian Weimer fwei...@redhat.com wrote: On 08/14/2014 10:15 PM, Mark Roos wrote: Look into sun.Misc.Unsafe [and at defineAnonymousClass(Class, byte[], Object[])] Thanks. Could we turn this into a supported API, with a suitable security manager check? Hi

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

On Jul 9, 2014, at 3:14 AM, Paul Sandoz paul.san...@oracle.com wrote: I quickly verified the fold up does as you expect. Also, if i do the following the null check goes away: ... void testLoop() { for (int i = 0; i 100; i++) { testLoopOne(a);

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

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, we lean heavily on MH types to guarantee a priori

Re: [9] RFR (XS): 8046903: VM anonymous class members can't be statically invocable

Reviewed. — John On Jun 16, 2014, at 9:50 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8046903/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8046903 j.l.i.InvokerBytecodeGenerator::isStaticallyInvocable doesn't distinguish between VM

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

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 call in the framing code, and likewise with most of the

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

On Apr 3, 2014, at 6:33 PM, Christian Thalinger christian.thalin...@oracle.com wrote: Of course they are popular because these are the type names. There is no type L; it’s an object. I don’t understand why we have to use different names just because they are used in other namespaces.

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

On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Thanks for the feedback. What do you think about the following: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ That looks nice. Strong typing; who woulda' thunk it. :-) The uses of .ordinal() are

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

On Mar 18, 2014, at 1:36 PM, Christian Thalinger christian.thalin...@oracle.com wrote: Why are we not using an Enum instead of an untyped byte? Byte is moderately typed, in the sense (which I rely on during development) that you can't assign an int or char to a byte w/o a cast. That's why it

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

Reviewed. – John On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Chris, thanks for the review. John suggested an elegant way to fix the problem - use asFixedArity. Updated fix: http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/ Best regards,

Re: Signature of MethodHandleInfo.reflectAs is not specific enough

On Feb 25, 2014, at 3:13 AM, Ali Ebrahimi ali.ebrahimi1...@gmail.com wrote: I know, this is too late, but I want to share my suggestion: public T extends AccessibleObjectAnnotatedElement T reflectAs(Class? super T expected, MethodHandles.Lookup lookup) Isn't this the same as public T

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

On Feb 26, 2014, at 3:44 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Maybe use invokeWithArguments with target and catcher? That at least is a one-liner, and probably more efficient. Yes, that's a good idea! At least, it considerably simplifies the code. Updated webrev:

Re: RFR (S): 8033666: Make sure @ForceInline is everywhere it needs to be in sun.misc and java.lang.invoke

On Feb 25, 2014, at 4:16 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: As an interim fix, I moved castReference method into java.lang.invoke.MethodHandleImpl class and added new entry point ValueConversions::cast which accepts a method handle to a method which should be used for

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

On Feb 20, 2014, at 9:57 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: 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. I changed LF representation a bit and added

Re: problems with step debugging

On Feb 4, 2014, at 4:21 AM, Jochen Theodorou blackd...@gmx.org wrote: If I know how it is supposed to look like, I can change our compiler to emit the line number information exactly where suggested and then see if it works. But for that I missing that information :( Here is the information

  1   2   3   4   5   6   7   8   >