Re: Hotswap patch?
On Sep 13, 2009, at 12:22 AM, Patrick Wright wrote: I just saw that you pushed a changeset from Thomas Wuerthinger related to expanding hotswap--from the unit tests included, it looks pretty nice--add/remove fields and methods etc. Anything you can tell us about it, status etc? I didn't know anyone was working on this in the Da Vinci Machine. The design of the hotswap patch is described in the PDF linked from this page: http://wikis.sun.com/display/mlvm/HotSwap I believe (under correction from you, Thomas!) that the patch is the initial result of a research project that he did earlier this year at JKU Linz, that he is now working on other things, and that he doesn't have specific plans (yet) to extend it further. See the message below. Thomas will be talking about this work at Sun on Wednesday, and InfoQ will be taping the talk (like most of the talks at the Summit). -- John Begin forwarded message: From: Thomas Wuerthinger Date: April 1, 2009 8:49:07 AM PDT To: c...@sun.com Subject: Dynamic Code Evolution - Patch and Documentation Hi! This is the first (pre-alpha) version of the dynamic code evolution implementation. The attachment contains: - A patch that can be used upon jdk7-b51 with the sources for dynamic code evolution as well as the test cases (37 of 41 should be OK); please consider that it is still a prototype implementation. - A high-level technical description of the implementation with pointers to the source code and TODO sections that inform about future plans. Any kind of feedback most welcome! Let me know if you have any issues compiling the code or running the test cases. - thomas ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [jsr-292-eg] updated RI code and API javadoc
(Getting a round of EG work in before the Summit, so we'll have more to talk about. :-) On Jul 15, 2009, at 6:02 AM, Daniel Heidinga wrote: Regarding keeping MHs.methodType, it seems cleaner to keep the MethodHandles factory and the MethodType factory separate. The static import concerns can be addressed by renaming MethodType's make() methods to have a more descriptive name such as methodType(). It'll look a little silly for people not using static import (MethodType.methodType()), but I can live with that. That seems like a good compromise. I'll add those methods and deprecate the others, and see what comments we get. I think the factory pattern "SomeType.make" makes less sense in a Java world with static import. I guess the adjusted pattern "SomeType.someType" is better. I'm open to other suggestions... I'm glad that you agree that we should remove the _# from the MHs.invoke() methods. Using invokeVarargs rather than invokeWithArguments is fine. Good. It looks much better that way. Regarding the LDC proposal, it came to my attention that JSR 294 (Modularity) is planning to add new ConstantPool types as well. This makes me very opposed to the idea of trying to overload the existing CONSTANT_* rather than adding CONSTANT_MethodHandleref_info and CONSTANT_MethodTyperef_info. That seems right. Let's talk about this at the Summit. The advantage of using constants rather than reflective factory methods is the ability of tools (or the JVM) to see ahead of time how the app. is going to link itself. There may also be compactness benefits. Dan Heidinga J9 VM Software Developer IBM Ottawa Lab 613-356-5036 daniel_heidi...@ca.ibm.com Thanks a lot for the detailed comments. I've forwarded it to a couple observer lists. To deal with API bloat, instead of getting rid of MHs.methodType, I'd prefer to get rid of MethodType.make. Now that we have static import in the language, I'd like to profit from it, and methodType is a much more reasonable thing to import than "make". I like your idea about getting rid of invoke_2. Since "varargs" is the Java term, let's make the varargs guy "invokeVarargs". Many more responses later. -- John On Jul 8, 2009, at 1:39 PM, Daniel Heidinga wrote: > We've taken a look through the Javadoc and have some comments. > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [jsr-292-eg] updated RI code and API javadoc
Le 16/09/2009 02:56, John Rose a écrit : (Getting a round of EG work in before the Summit, so we'll have more to talk about. :-) [...] Regarding the LDC proposal, it came to my attention that JSR 294 (Modularity) is planning to add new ConstantPool types as well. This makes me very opposed to the idea of trying to overload the existing CONSTANT_* rather than adding CONSTANT_MethodHandleref_info and CONSTANT_MethodTyperef_info. That seems right. Let's talk about this at the Summit. The advantage of using constants rather than reflective factory methods is the ability of tools (or the JVM) to see ahead of time how the app. is going to link itself. There may also be compactness benefits. Knowing the method handle before runtime will allow, by example, to avoid the method type check in case of MethodHandle.invoke(). Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
List of things I think we should talk
Here is the list of points that I think we should talk during the submit :) - method handle invocation - john: check == againt method type - fredrik: allow all conversions described in MHs.convertArguments() - rémi: allow all already existing JVM conversions parameter types covariance, return type contravariance - JavaMethodHandle constructors describe an uncommon method lookup algorithm - revisit all adapters like spread/collect and allow conversions for all - slim call site to store only the target mh and the declaring class (let bootstrap method as is, if language developer need method name, etc. it can subclass CallSite) and the declaring class should be a Class not an Object - remove one-to-one limitation between invokedynamic and its CallSite, many CallSite are allowed (allow instruction splitting) - remove CallSite.nameComponents() or specify it - specify the type used for the signature of Lookup.findVirtual()/bind(), and MethodHandles.insertArguments() if type is not accessible. - bootstrap method can be called by multiple thread at the same time for a same callsite, what is the exact semantics - have a CallSite constructor that take the target MH - provide access to field/object creation without using reflection. minor improvements: - MethodHandle.combine() last parameter should be a int... Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Hotswap patch?
> The design of the hotswap patch is described in the PDF linked from > this page: > http://wikis.sun.com/display/mlvm/HotSwap > > I believe (under correction from you, Thomas!) that the patch is the > initial result of a research project that he did earlier this year at > JKU Linz, that he is now working on other things, and that he doesn't > have specific plans (yet) to extend it further. See the message below. > > Thomas will be talking about this work at Sun on Wednesday, and InfoQ > will be taping the talk (like most of the talks at the Summit). Yes - during the talk I will also outline future directions that I am currently considering and I would be happy about any kind of feedback! - thomas ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
